Название Microservice не принесло ничего, кроме вреда прекрасной концепции, скрытой за ним.

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

Монолит

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

Учитывайте структуру своей команды

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

Компромиссы

В распределенной архитектуре вы должны быть готовы идти на компромиссы и объяснять эти компромиссы бизнесу. Почти наверняка вам придется принять возможную согласованность. Создание бизнес-отчетов будет не таким простым, как если бы все ваши данные были в одной базе данных. Жизнь уже не будет такой легкой, как с монолитной системой. Но это может окупиться. Зависит от того, что вы ищете.

Границы

Одной из самых больших проблем при разработке системы, состоящей из множества взаимодействующих подсистем, является установление границ. Мое эмпирическое правило заключается в том, что любая подсистема должна рассматриваться как независимая компания, с которой вы должны сотрудничать и договариваться о внешних интерфейсах и совместном использовании данных. Это может вызвать некоторые разногласия, но если вы хотите иметь стабильную систему, вы должны быть осторожны во всех связях между подсистемами. Сделайте их максимально развязанными. Проводите границы только там, где вы точно уверены, куда они ведут. У вас ecommerce + erp как монолит? Хорошо, сначала проведите черту между электронной коммерцией и erp. Рефакторинг. Создайте «логическое» разделение в кодовой базе, где вы не сможете просто взять что-то из другой части и бросить в другую. Создайте несколько интерфейсов. Поэкспериментируйте с асинхронной связью. Вы узнаете, как жить с границей в вашей системе. И помните, легче управлять одной границей, чем десятками. Когда вы узнаете о других границах, и увидите ценность извлечения другой подсистемы, вы сможете выполнить дальнейший рефакторинг.

Ограничение данных

Это связано с границами. Даже если у вас есть служба, которая в значительной степени разделена, в какой-то момент вам может потребоваться обмен данными между ними. Это еще одна вещь, которую вы должны принять, — обмен данными синхронно с другой системой ставит вышестоящую службу вместо обработки потенциально высокого трафика. Асинхронная синхронизация данных обеспечивает возможную согласованность. Если вы не хотите терять данные, вы должны реализовать шаблон исходящих сообщений и иметь в своей системе еще одну подсистему — какой-нибудь брокер сообщений, например RabbitMQ.

Причины

Прежде чем создавать распределенную систему, вы должны спросить себя «Почему?». На мой взгляд, причин всего несколько:

  • Стабильность. Вы хотите отделить важные части системы от менее важных. Блог часть системы не так важна, как размещение заказов, верно?
  • Системное разнообразие/масштаб. Если ваша система настолько разнообразна, что в ней есть несколько продуктов и команд, ориентированных на продукт, разделение между ними может принести много пользы.
  • Горячие дорожки. Есть часть системы, которая используется непропорционально больше, и мы можем извлечь выгоду из написания ее как отдельной системы — сделать ее более стабильной, написать на более производительном языке и т. д.

И, честно говоря, я не вижу большего, чем это.

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