Как Мы Пишем Микросервисы И Почему Не Делаем Это Быстро

Как мы пишем микросервисы и почему не делаем это быстро

Истории о распиливании монолита часто похожи одна на другую.

У команды был здоровенный, неповоротливый монолит, его решили разрезать на россыпь правильных и шустрых микросервисов, всё стало круто.

Истории различаются лишь степенью ужаса «до», радости «после» и рядом второстепенных характеристик.

В RBK.money также есть микросервисы.

Но мы подошли к ним немного иначе, чем большинство.

У нас все было еще хуже, чем у монолита – на старте все было просто плохо.

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

Итак, все было плохо.

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

И сразу по микросервисам.

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

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

Никто не хочет краснеть за свой код или архитектуру проекта, это так себе история.

Быстро против хорошо

В идеальном мире всегда хочется писать код быстро и хорошо.

Ну, это типа: «Лучше быть богатым и здоровым, чем бедным и больным».

Поэтому микросервисы стали отличным выходом из ситуации.

Процесс кодирования был построен на бизнес-задачах.

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

Этот функционал превращается в микросервис под кодовым названием Accounter, отвечающий за учет средств.

Та же история и с другими микросервисами.

Главное здесь было сделать так, чтобы каждый бизнес-функционал был настолько специфичным, чтобы его мог написать один человек.

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

Нам это удалось сделать, это сразу даёт пару хороших существенных преимуществ.

Во-первых, это обеспечивает большую распараллеливание разработки.

На старте у нас было около 10 человек, и нам удалось одновременно написать большой объём кода (и написать его хорошо).

Во-вторых, это дает возможность полностью вращаться.

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

Если один человек постоянно работает над одним и тем же микросервисом, он может начать генерировать дерьмовый код. И это не столько вопрос профессионализма, сколько вопрос времени.

Через 7-8 месяцев людям надоест поддерживать один и тот же микросервис, они посмотрят вокруг - а жизнь есть, за зимой пришла весна, у коллег какое-то движение, опять новый айфон вышел, а ты все еще сидит на том же микросервисе.

Так рождается монолит с единственной точкой отказа в виде этого уставшего мужчины с мешками под глазами.

Как мы пишем микросервисы и почему не делаем это быстро

Или вообще человек начинает думать, что все зависит только от него.

Он попытается сделать себя незаменимым, окружив свою работу кучей «тайных знаний» и странных процедур.

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

Например, нужно было запустить один сервис.

Как вы обычно представляете себе что-то вроде этого:

Запустите службу.

Как это было:

Зайдите в реестр Windows.
Найдите там конкретный ключ.
Измените его на 1.
Запустите службу.
Сбросьте значение ключа на 0.

Это классический пример сложности ради сложности и «Здесь ничего не работает без меня».

На самом деле все работает и без этого.

Только быстрее и лучше.

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

Точно так же мы поддерживаем постоянный обмен знаниями внутри команды.

Код протокола

Как мы пишем микросервисы и почему не делаем это быстро

Если вы возьмете какое-либо техническое задание из бизнеса, тщательно переведете его на человеческий язык, стряхнете шелуху и выпарите, вы получите протокол, язык, посредством которого будет общаться машина.

То есть мы берем бизнес-задачу, понимаем для себя, что именно и как мы будем делать, и превращаем ее в спецификацию, используя бережливость или развязность (микросервисы внутри себя общаются с помощью бережливости).

Первым шагом является детальное описание всего: что будет делать микросервис, какие типы данных он будет принимать, как реагировать, какие у него будут структуры и т. д. Этот протокол проходит первую проверку теми, кто четко понимает, как все работает. (де-факто архитекторы).

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

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

Пишем на трёх языках — JS, Java, Erlang. Главное — не торопить кого-либо с ревью или написанием кода.

Да, бизнесу всегда и везде нужно быстро и круто.

Но как технический директор я редко тороплю ребят, потому что хорошо понимаю, что они хотят сделать.

В результате получается ситуация, что меня часто поощряют бизнес-заказчики за сроки.

Но повода краснеть за качество практически нет. Мы поспешили только один раз, когда сорвался джекпот — суперклиент и чрезвычайно срочные сроки как раз создавали наш Кошелек.

Тогда да, мы опустили рукава и сделали всё быстрее, чем планировали (и хуже, чем хотели, да).

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

Это оказался кусок монолита.

Преимущество ситуации в том, что мы еще раз поняли, что торопиться не надо.

А сам сервис мы потихоньку разбираем на отдельные микросервисы, как и хотели.

Как мы пишем микросервисы и почему не делаем это быстро

В RBK Money 50 микросервисов, написанных примерно 20 людьми.

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

А если бы я выпустил бережливость в чистом виде, меня бы обозвали плохими словами.

Поэтому мы ничего не придумывали — у нас бодро торчит остальной JSON, простой и понятный, плюс OpenAPI. Чтобы иметь возможность принимать эти запросы извне, их необходимо проверить, авторизовать, а затем запустить внутри платформы другими микросервисами.

А еще мы написали все это дело как независимый микросервис, который:

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

Удобно ли писать платежную систему с использованием микросервисов? Разумеется — тут и распараллеливание работы, и поддержание заинтересованности сотрудников, и отсутствие единой точки отказа.

Если сломается один микросервис или вдруг уйдет человек, который это делал вчера — не проблема, можно быстро что-то исправить, а на место пилота поставить нового человека на время нового спринта.

Как мы пишем микросервисы и почему не делаем это быстро

Но бытует мнение, что если один человек довольно долго сидит и аккуратно вырезает конкретный микросервис, то он это точно делает хорошо.