Микросервисы / распределенные системы
Сложности Эволюционный взгляд позволяет увидеть, что нового привнесли микросервисы и какие принципы и концепции SOA все еще применимы. Сложности дизайна Несмотря на лавинообразное распространение микросервисов (microservitization), авторы указывают на недостаток…
Сложности разработки
Большинство микросервисов сегодня взаимодействуют посредством RESTful HTTP (заявление актуально на 2015 год). Взаимодействие посредством сообщение выглядит многообещающим, но имеет слабую распространенность (а это актуально и сегодня, почти 8 лет спустя). API становится своего рода контрактом, увеличивающим связанность (coupling) и нарушение которого ведет к невозможности взаимодействия сервисов друг с другом.
Таким образом можно выделить две сложности со взаимодействием сервисов:
– Одновременная поддержка нескольких версий API в процессе разработки
– Обратная совместимость и/или поддержка старых версий API в проде
В статье рекомендуется посмотреть на OpenAPI (весьма ценная рекомендация 🙂 ).
Другая сложность – согласованность данных вследствие того, что база данных может быть частью реализации микросервиса. Один из вариантов решения – eventual consistency, несмотря на неприменимость в некоторых доменах и сложность реализации. Так же распределенная природа данных в микросервисах усложняет распределенные транзакции и запрос данных при необходимости собрать данные из нескольких сервисов.
На 2022 год у обеих сложностей есть подходящие решения. Мы проектируем решение таким образом, чтобы в нем не было необходимости в распределенной транзакции. Обычно такая транзакция – это следствие нарушения cohesion на уровне всей системы, то есть когда неделимое целое с точки зрения целостности данных разделили на несколько «независимых» частей. Для решения сложности запроса данных можно использовать паттерны Backend For Frontend и/или CQRS.
В статье авторы так же указывают на сложность тестирования из-за распределения бизнес-логики по независимо, эволюционно развивающимся отдельным сервисам. Необходимым становится использование фреймворков для тестирования надежности[1] и автоматизированного, повторно используемого приемочного тестирования[2].
[1] V. Heorhiadi, S. Rajagopalan, H. Jamjoom, M.K. Reiter, V. Sekar, Gremlin: systematic resilience testing of microservices, in 2016 IEEE 36th International Conference on Distributed
[2] M. Rahman, J. Gao, A reusable automated acceptance testing architecture for microservicesin behavior-driven development, in 2015 IEEE Symposium on Service-Oriented System
#msaevolutionwspub6 #msaevolutionwspub #перевод
Большинство микросервисов сегодня взаимодействуют посредством RESTful HTTP (заявление актуально на 2015 год). Взаимодействие посредством сообщение выглядит многообещающим, но имеет слабую распространенность (а это актуально и сегодня, почти 8 лет спустя). API становится своего рода контрактом, увеличивающим связанность (coupling) и нарушение которого ведет к невозможности взаимодействия сервисов друг с другом.
Таким образом можно выделить две сложности со взаимодействием сервисов:
– Одновременная поддержка нескольких версий API в процессе разработки
– Обратная совместимость и/или поддержка старых версий API в проде
В статье рекомендуется посмотреть на OpenAPI (весьма ценная рекомендация 🙂 ).
Другая сложность – согласованность данных вследствие того, что база данных может быть частью реализации микросервиса. Один из вариантов решения – eventual consistency, несмотря на неприменимость в некоторых доменах и сложность реализации. Так же распределенная природа данных в микросервисах усложняет распределенные транзакции и запрос данных при необходимости собрать данные из нескольких сервисов.
На 2022 год у обеих сложностей есть подходящие решения. Мы проектируем решение таким образом, чтобы в нем не было необходимости в распределенной транзакции. Обычно такая транзакция – это следствие нарушения cohesion на уровне всей системы, то есть когда неделимое целое с точки зрения целостности данных разделили на несколько «независимых» частей. Для решения сложности запроса данных можно использовать паттерны Backend For Frontend и/или CQRS.
В статье авторы так же указывают на сложность тестирования из-за распределения бизнес-логики по независимо, эволюционно развивающимся отдельным сервисам. Необходимым становится использование фреймворков для тестирования надежности[1] и автоматизированного, повторно используемого приемочного тестирования[2].
[1] V. Heorhiadi, S. Rajagopalan, H. Jamjoom, M.K. Reiter, V. Sekar, Gremlin: systematic resilience testing of microservices, in 2016 IEEE 36th International Conference on Distributed
[2] M. Rahman, J. Gao, A reusable automated acceptance testing architecture for microservicesin behavior-driven development, in 2015 IEEE Symposium on Service-Oriented System
#msaevolutionwspub6 #msaevolutionwspub #перевод