Как стартап-единорог в Японии использовал возможности микросервисов

Об этой статье

Привет, народ. Меня зовут Шо Огихара. Я технический руководитель [Американской платформы микросервисов Mercari] (https://www.mercari.com/careers/?gh_jid=5579362002#job-detail). Мы известны как первый стартап-единорог в Японии, а также известны рекламой Суперкубка в США. У меня более 7 лет опыта работы в этой компании, но я скоро уйду, чтобы стать фрилансером. Сегодня я хотел бы написать о своем опыте использования Mercari US с благодарностью.

Мы начали бизнес в 2013 году, и когда я присоединился к нам в конце 2014 года, нашим бэкэндом был традиционный стек PHP и MySQL (LAMP). Но сейчас делаем архитектуру микросервисов kubernetes, istio, gRPC, golang, Prometheus и так далее. Если вас интересует наш текущий стек технологий, посетите наш инженерный блог. Там много фантастических постов.

Как мы могли бы модернизировать нашу серверную систему? За 7-летним ростом было много изменений. Но пожалуйста, помните, что это НЕ официальная версия и больше соответствует моему мнению и опыту. Этот пост является лишь одной точкой зрения и может содержать много ошибок. Тем не менее, я надеюсь, что этот опыт будет полезен для других инженеров.

Мокап (<=2014)

Я слышал, что наше приложение изначально было создано Ruby on Rails для макета. Однако он был полностью переписан на PHP. Это звучит безумно, потому что RoR был одним из самых популярных фреймворков в то время, примерно в 2014 году.

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

Старомодная ЛАМПА (2014\~2015)

Наше приложение было выпущено с использованием фреймворка PHP под названием dietcake, который вдохновлен CakePHP, но тоньше и проще в освоении. Он предназначен для того, чтобы новички могли разрабатывать новую конечную точку API с самого первого дня присоединения.

На этом этапе уникальным было то, что конечные точки API были разработаны специально для экранов iOS и Android. Например, предположим, что конечная точка GET /items/:id. В общем дизайне REST эта конечная точка будет возвращать такой объект:

```javascript

"id": "m1000",

"имя": "iPhone 13 про макс",

"цена": "1000",

"статус": "продано",

"id_покупателя": 12345,

Однако наш ответ API был разработан специально так:

```javascript

"вещь": {

"id": "m1000",

"имя": "iPhone 13 про макс",

"цена": "1000",

"статус": "продано"

"покупатель": {

"идентификатор": 12345,

"имя": "покупатель-12345",

"icon": "https://icon-url"

"Вам также может понравиться": [

"имя": "iPhone 12",

"цена": 900,

"статус": "в продаже"

Как видите, все связанные объекты включены в один ответ. Например, клиентам не нужно вызывать другой API, чтобы получить подробную информацию о «покупателе». Этот дизайн может отличаться от хорошо известной передовой практики REST. На самом деле, мы можем видеть аналогичную идею GraphQL сегодня.

Я бы не сказал, что REST неверен, а подход GraphQL лучше. Я хочу сказать, что этот дизайн был своего рода свидетельством того, что ментальная модель бэкенд-разработчиков близка к экрану мобильного приложения. Независимо от позиции, мы хорошо обсудили спецификацию приложения. Это может быть дольше, чем обсуждение дизайна серверной системы. В то время нами руководил дизайн самого приложения. И я думаю, что это очень важно, особенно для стартапов.

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

Много попыток, стало сложнее (2015\~2017)

Хотя наше приложение изначально было запущено в Японии, мы хотели как можно раньше бросить вызов мировому рынку. Версия для США была выпущена очень быстро, всего через год после версии для Японии. Причина, по которой мы смогли выпустить так быстро, заключается в том, что мы не добавили слишком много локализаций, за исключением доставки, оплаты и обмена сообщениями i18n. Думаю, это было сделано специально, потому что мы были уверены в продукте. Facebook и Twitter не меняют приложение по регионам, верно? Наша идея была примерно такой. Кроме того, скорость была самым важным, как мы испытали. Мы должны выпустить приложение и увидеть реакцию рынка как можно скорее, а не тратить слишком много времени на расследование. Таким образом, внутренний код API был общим для Японии и США.

Однако рынок оказался не таким простым, как мы ожидали. Мы делаем приложение для электронной коммерции, поэтому было важно, чтобы доставка сильно отличалась от Японии. Кроме того, создать новую команду, как всегда, непросто. Особенно, когда это происходит в других странах, и если участники начинают там новую жизнь. Собственно, я был одним из них. Теперь Mercari — довольно глобальная компания и [имеет много поддержки] (https://careers.mercari.com/support/). Но не так было с самого начала.

В конце концов, компания решила на время потратить все ресурсы участников продукта на версию для США. Поскольку многие участники внезапно начали вносить свой вклад в версию для США, в результате в коде было создано много «if region == US». Мы знали, что такая практика не годится, но других вариантов не было, потому что спецификация буквально должна была решить проблемы в США. Независимо от того, какую технику кодирования мы используем, полностью избежать ее невозможно. На самом деле «если регион == США» было не единственным. Чтобы адаптироваться к новому рынку, мы попробовали множество функций. Абсолютно хорошо пробежать спринт много раз быстро, методом проб и ошибок. Но к тому времени, когда мы это заметили, половина конечных точек не использовалась в производственной среде. Я чувствую, что наша гибкость разработки была снижена в эту эпоху.

Запустить микросервисы (2017\~2018)

Нам нужно было что-то для прорыва. На следующий день после Дня Благодарения наш директор по маркетингу объявил о запуске проекта «двойной», который исходил из цели удвоить коэффициент удержания. Изюминкой этого проекта было создание совершенно другого приложения с нуля. Даже цвет темы приложения был изменен с красного на фиолетовый, а также изменен логотип. Был буквально с нуля, и решил все переписать на iOS и Android.

В отличие от клиентов, серверную часть невозможно полностью очистить, потому что слишком сложно отказаться от существующих пользователей и элементов. Вместо этого мы решили поставить новый шлюз перед предыдущим бэкендом. В этом шлюзе мы использовали новые технологии, такие как kubernetes, gRPC, golang и другие. Это основы, которые мы обычно используем сегодня. И мы решили реализовать новые функции в виде микросервисов в новом мире шлюзов. Обзор архитектуры выглядел так.

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

Когда мы находим проблемы в коде, есть два подхода к их решению: рефакторинг или переписывание. Рефакторинг — это исправление кода без изменения поведения. Это хороший подход, если проблема заключается в том, «как писать».

Но в то время нашей проблемой было «что писать». Наш код истощался из-за множества проблем. Мы должны переосмыслить то, что действительно было необходимо для нашего приложения. Если нам нужно изменить поведение кода, то это не рефакторинг, а переписывание. Обычно бэкенду сложно это сделать, потому что бэкенд API должен заботиться о совместимости. У нас есть редкий шанс сделать это. Если вы являетесь архитектором бэкенда и рассматриваете рефакторинг, я хотел бы предложить рассмотреть спецификацию как она есть. Это самый мощный способ очистить спецификацию, чтобы очистить код.

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

Запустить платформу микросервисов (2018\~2021)

У нас только что появилось новое место для написания микросервисов. Следующим шагом было ускорение этой архитектуры. Мы работали над многими решениями для этого. Позвольте мне представить некоторые из них.

Первый заключался в том, чтобы проанализировать наиболее часто используемые классы PHP в предыдущей кодовой базе монолита, а затем реализовать их в виде микросервисов. Такие классы, как User, Item, Payment и т. д., являются основой нашего приложения. Без этих классов сложно реализовать какие-либо функции. В противном случае нам пришлось бы продолжать реализацию большинства функций в устаревшей кодовой базе.

Кроме того, мы могли бы получить знания о разработке микросервисов, реализуя такие виды микросервисов основных объектов. Хотя у нас была политика разделения пространств имен kubernetes по микросервисам, кроме этого, у нас было не так много идей для дизайна кода, мониторинга, сетей и так далее. Эти микросервисы стали хорошими экспериментами для размышлений о наших практиках.

Кстати, это не по теме, но на завершение статической аналитики для устаревшей кодовой базы PHP ушло около недели, хотя я использовал машину, которую мы обычно используем для машинного обучения. Сгенерированный SVG-файл графа зависимостей невозможно было открыть в веб-браузере. Я узнал, как невозможно понять нашу кодовую базу, узнав людей.

Получив знания от некоторых микросервисов, мы создали инструмент под названием starter-kit, который представляет собой модуль terraform и шаблон микросервисов. На самом деле это разработано командой JP, а не нами, идея описана в этой [презентации] (https://speakerdeck.com/b4b4r07/terraform-ops-for-microservices). Этот инструмент используется как в JP, так и в микросервисах США.

Я думаю, что одна из самых важных идей стартового набора — разъяснить владельцам микросервисов. На самом деле, для меня микросервисы — это не только способ разработки программного обеспечения, но и способ проектирования человеческих организаций. Когда мы думаем о узком месте развития, чаще всего это общение с другими. Чем больше заинтересованных сторон у разработчиков, тем больше они разочарованы. Микросервисы абстрагируют связь от интерфейса API и абстрагируют проблемы от уровня успешности и задержки. Единственное, что мы должны сделать, это говорить по тому же протоколу (мы используем gRPC). Когда мы разрабатываем такую ​​коммуникацию команд, самым важным условием является прояснение, кто является владельцами.

Еще одной серьезной проблемой после стартового комплекта было перенести устаревший PHP в среду kubernetes. Я знаю, что у некоторых людей аллергия на PHP. Для них PHP кажется сразу злом и его нужно стереть как можно скорее. Но, по моему мнению, настоящее зло — это сложность кода. Это происходит независимо от того, какие языки программирования мы используем. Причем это происходит независимо от того, микросервис это или нет.

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

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

Затем мы начали проект по миграции монолита, который работал на виртуальных машинах, в kubernetes. Все началось с контейнеризации, и на завершение всех процессов ушло около 1 года. Подробности этого проекта написаны здесь. Пожалуйста, проверьте это.

Заворачивать

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

За более чем 7 лет работы в этой компании одним из самых важных уроков для меня стало то, что мы должны относиться к программному обеспечению как к человеческому телу. Поскольку вещи не могут быть совершенными с рождения, мы должны позволить программному обеспечению циркулировать, как тело заменяет клетку каждый день. Я считаю, что одна из причин, по которой мы смогли стать лучшей компанией электронной коммерции в Японии, заключается в том, что мы быстро обновили наше приложение. Хотя у нас были некоторые трудности из-за этого, мы смогли преодолеть это, переместив микросервисы. Мне нравятся слова Чарльза Дарвина:

Выживает не самый сильный из видов и не самый умный. Это тот, который наиболее приспособлен к изменениям.

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

• Наконец, как было сказано в начале, со следующего месяца я стану фрилансером. Пожалуйста, не стесняйтесь обращаться к gon.gong.gone@gmail, если вы заинтересованы во мне.*