Comments 5
Микросервисы способны превратить любую бизнес проблему в проблему распределённых транзакций.
Особенно такие радикальные, как в этой статье.
Как по мне, то слишком идеализированы требования к МСА, причём включают в себя ещё и требования к процессам разработки в динамике. По пунктам:
Позволяет ли ваша система независимо перезапускать сервисы?
Пожалуй, это единственное с которым согласен на 100%. Если при рестарте сервиса нужно рестартовать и те, для которых он является зависимостью, то сложно это назвать МСА
Можете ли вы независимо развертывать сервисы?
Вот тут уже есть нюансы. По-моему, МСА или нет особо не влияет проходит развёртывание какого-то сервиса указанием его версии в каком-то конфиге в его личном репозитории или в каком-то глобальном мета или даже моно репозитории, где описан текущий состав и схема всей системы.
Если релиз происходит, например, раз в 2 недели, то вполне может быть, что при релизе все сервисы развернутся заново, но это ещё не повод считать систему не МСА, если это произошло лишь потому, что за эти две недели были изменения во всех. Тут система развёртывания должна определять что нужно развёртывать заново, а что нет. Например по наличию коммитов с прошлого развёртывания или по изменившумуся номеру версии.
Может ли модификация повлечь необходимость выполнить синхронизированные модификации других сервисов?
Это уже больше не к архитектуре, а к процессам разработки. Обеспечение обратной совместимости отдельных модулей в процессе разработки это тактические решения на каждой задаче, главное чтобы архитектура в принципе это поддерживала, а необходимость определяется локально, стоит ли овчинка выделки. И сильно зависит от сложности коммуникаций, согласований с разработчиками клиентов твоего сервиса. Если ты сам можешь провести все изменения малой кровью, и зарелизить не только новую версию своего сервиса, но и всех его клиентов, то почему бы и нет.
Можете ли вы обновить зависимость или версию Java в единственном сервисе?
Неоднозначный вопрос. Это всегда можно сделать в принципе, если не стараться запретить это специально. Вопрос в том сколько времени займёт. Может оказаться, что дольше чем во всей системе одновременно и/или следующий релиз других сервисов будет вынужден тоже обновится. Это вопрос решаемый на уровне проектирования и напрямую к МСА отношения не имеет по-моему. Вполне могут быть пулы микросервисов, использующих одну версию зависимостей, хотя предусмотреть возможность относительно простого перевода из одного пула в другой полезно. Вот тут у нас используется Java 8 или какая там типа LTS, а тут 10. Минорные апдейты пулов проводятя одноврменно, плюс постепенно мигрируем сервисы из старого пула в новый.
Вызывает ли отказ единственного сервиса отказ всей системы?
Точно не показатель МСА. Есть такое бизнес-требование — надо его реализовывать. Нет — вполне могут быть даже несколько точек глобального отказа типа сервиса аутентификации, авторизации или API Gateway
Есть ли в вашей системе какая-либо разделяемая составляющая?
С трудом представляю систему без таковой. Вернее с трудом представляю себе набор полностью независимых сервисов, которые представляют собой систему, а не кучу.
С трудом представляю систему без таковой. Вернее с трудом представляю себе набор полностью независимых сервисов, которые представляют собой систему, а не кучу.
Речь не про то что между сервисами не должно быть зависимостей, а про shared libraries. Например когда у вас один сервис вызывается из десятка других и все сервисы написаны на одном языке, то возникает желание один раз написать клиентскую библиотеку и использовать ее в 10 сервисах, вместо дублирования/генерирования клиента. Если сервисов много а разработчиков/команд мало — то кажется что это частая ситуация.
www.microservices.com/talks/dont-build-a-distributed-monolith
www.infoq.com/presentations/netflix-play-api
А вы уверены, что пользуетесь микросервисами?