• Быстро и гибко настраиваем  наблюдаемость с помощью канонических строк логов

    • Translation

    В постах на Хабре тема структурного логирования упоминается часто, но вскользь. Поэтому, когда я наткнулся на эту подробную статью Brandur Leach из Stripe, я решил перевести её и поделиться с сообществом. 

    В Badoo мы оценили пользу структурного логирования в частности для группировки ошибок. Хеш сообщения об ошибке часто содержит динамические данные — например, id пользователя, — которые мешают корректно группировать такие сообщения. Поэтому мы перешли на структурное логирование, где текст ошибки — это некий шаблон, а вся динамическая информация передается в контексте и не влияет на группировку.

    В статье Brandur Leach предлагает идею, как открыть еще больше возможностей в структурном логировании. Есть и описание практической пользы от использования такого подхода — в Stripe даже сделали продуктовый функционал на основе данных, полученных из логов, — и детали реализации такого решения (без ухода в дебри конкретного стека технологий).

    Приятного чтения!

    Читать далее
    • +18
    • 2.1k
    • 9
  • Время высокой точности: как работать с долями секунды в MySQL и PHP

    • Tutorial


    Однажды я поймал себя на мысли, что при работе со временем в базах данных почти всегда использую время с точностью до секунды просто потому, что я к этому привык и что именно такой вариант описан в документации и огромном количестве примеров. Однако сейчас такой точности достаточно далеко не для всех задач. Современные системы сложны — они могут состоять из множества частей, иметь миллионы пользователей, взаимодействующих с ними, — и во многих случаях удобнее использовать бОльшую точность, поддержка которой уже давно существует.


    В этой статье я расскажу про способы использования времени с дробными частями секунды в MySQL и PHP. Она задумывалась как туториал, поэтому материал рассчитан на широкий круг читателей и местами повторяет документацию. Основную ценность должно представлять то, что я собрал в одном тексте всё, что нужно знать для работы с таким временем в MySQL, PHP и фреймворке Yii, а также добавил описания неочевидных проблем, с которыми можно столкнуться.


    Я буду использовать термин «время высокой точности». В документации MySQL вы увидите термин “fractional seconds”, но его дословный перевод звучит странно, а другого устоявшегося перевода я не нашёл.

    Читать дальше →
  • Courier: миграция Dropbox на gRPC

    • Translation


    Примечание переводчика


    Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:

    • использовать язык Protocol Buffers для описания взаимодействия сервисов;
    • генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
    • реализовать авторизацию между взаимодействующими компонентами;
    • использовать как синхронное, так и асинхронное взаимодействие.

    gRPC показался мне довольно интересным фреймворком, и мне было интересно узнать про реальный опыт компании Dropbox по построению системы на его основе. В статье есть масса деталей, связанных с использованием шифрования, построением надёжной, наблюдаемой и производительной системы, процессом миграции со старого RPC-решения на новое.

    Дисклеймер
    Оригинальная статья не содержит описания gRPC, и некоторые моменты могут показаться вам непонятными. Если вы не знакомы с gRPC или другими подобными фреймворками (например, Apache Thrift), рекомендую предварительно ознакомиться с основными идеями (достаточно будет прочитать две небольшие статьи с официального сайта: «What is gRPC?» и «gRPC Concepts»).

    Спасибо Алексею Иванову aka SaveTheRbtz за написание оригинальной статьи и помощь с переводом трудных мест.
    Читать дальше →
  • Конференция Velocity London от O'Reilly: обзор и слайды


      Velocity — это конференция, которая посвящена распределённым системам. Её организует издательство O'Reilly, и она проходит трижды в год: один раз в Калифорнии, один раз в Нью-Йорке и один раз в Европе (причём город меняется каждый год).


      В 2018 году конференция была в Лондоне с 30 октября по 2 ноября. Главный офис Badoo находится там же, так что у нас с коллегами было сразу два повода съездить на Velocity.


      Её устройство оказалось несколько сложнее, чем то, с каким я сталкивался на российских конференциях. Кроме достаточно привычных двух дней докладов тут было еще два дня тренингов, которые можно брать полностью, частично или не брать совсем. Всё вместе это превращается с серьёзный квест по выбору типа нужного билета.


      В этом обзоре я расскажу про те доклады и мастер-классы, которые мне запомнились. К некоторым докладам я прикладываю ссылки на дополнительные материалы. Частично это материалы, на которые ссылались авторы, а частично материалы для дальнейшего изучения, которые я нашёл сам.

      Читать дальше →
    • Как восемь человек масштабируют highload-проект. Опыт Unsplash

      • Translation

      Фото: Alex Smith | Unsplash

      Добрый день!

      Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.


      Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

      В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

      В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
      Читать дальше →
      • +46
      • 10.3k
      • 3
    • Проблемы при работе с кэшем и способы их решения

        Привет, Хабр!

        Меня зовут Виктор Пряжников, я работаю в SRV-команде Badoo. Наша команда занимается разработкой и поддержкой внутреннего API для наших клиентов со стороны сервера, и кэширование данных — это то, с чем мы сталкиваемся каждый день.

        Существует мнение, что в программировании есть только две по-настоящему сложные задачи: придумывание названий и инвалидация кэша. Я не буду спорить с тем, что инвалидация — это сложно, но мне кажется, что кэширование — довольно хитрая вещь даже без учёта инвалидации. Есть много вещей, о которых следует подумать, прежде чем начинать использовать кэш. В этой статье я попробую сформулировать некоторые проблемы, с которыми можно столкнуться при работе с кэшем в большой системе.



        Я расскажу о проблемах разделения кэшируемых данных между серверами, параллельных обновлениях данных, «холодном старте» и работе системы со сбоями. Также я опишу возможные способы решения этих проблем и приведу ссылки на материалы, где эти темы освещены более подробно. Я не буду рассказывать, что такое кэш в принципе и касаться деталей реализации конкретных систем.

        При работе я исхожу из того, что рассматриваемая система состоит из приложения, базы данных и кэша для данных. Вместо базы данных может использоваться любой другой источник (например, какой-то микросервис или внешний API).
        Читать дальше →
      • Как мы проверяем работоспособность серверного кода без мобильных клиентов


          Badoo — это сервис знакомств, который доступен в виде сайта и мобильных приложений под основные платформы. В начале прошлого года мы глобально переработали сайт, в результате чего он превратился в «толстого клиента» и стал работать так же, как и мобильные приложения: вызывать команды на сервере и получать от него ответы согласно протоколу, описывающему взаимодействие клиентской и серверной частей. Эти две части делаются разными разработчиками, и, как правило, клиентская часть делается уже после того, как серверная будет готова. При этом есть проблема: как разработчик новой фичи может убедиться, что серверная часть работает корректно, если клиента для нее пока нет и проверить ее не на чем?


          Для решения этой проблемы в любой серверной задаче у нас обязательно должны быть написаны интеграционные тесты, про которые я расскажу в этой статье.

          Читать дальше →
          • +27
          • 8.9k
          • 7
        • Как в Badoo генерируются изображения для «шаринга» в соцсетях

            Социальные сети — важный источник трафика. Нам выгодно, когда пользователи делятся контентом, и мы даем им такую возможность — у нас есть несколько видов контента, которым можно поделиться:

            • свой профиль;
            • чужой профиль (если его владелец это разрешил);
            • свой рейтинг, отражающий популярность пользователя на сайте;
            • награды, полученные пользователем за свои действия или действия других пользователей.

            Чтобы пользователю хотелось делиться всем этим, мы генерируем специальные изображения, которые называем бейджами. Вот пример бейджа, который может получить пользователь:



            Особенность бейджей состоит в том, что на них присутствуют фото самих пользователей, поэтому каждый видит и делится уникальными изображениями. В этой статье я расскажу, как мы генерируем такие изображения, с какими проблемами сталкивались и как их решали.
            Читать дальше →