Close

18.10.2016

Заметка о микросервисах

Часто появляются небольшие мысли — тезисы о плюсах и минусах какой-то архитектуры.

Писать о каждой целый пост — не хочу, хочу чтобы были побольше как статьи… Я решил выложить одну , о микросервисах, которую буду дополнять новыми мыслями.

Микросервисная архитектура

Определение отсюда.

Если вкратце, микросервисная архитектура (Micro Service Architecture, MSA), это когда ваше приложение представляет собой много-много небольших (буквально несколько сотен строк кода) сервисов, взаимодействующих между собой путем обмена сообщениями. Это могут быть сообщения Erlang‘а, Cloud Haskell‘я, Akka, или же REST API, Protobuf, MessagePack и так далее.

Плюсы и минусы описаны тут и тут.

 От себя добавлю: в поставке вида «запрос-ответ» недостатков не очень много, но они слишком критичны.

Например: причинно следственные связи в таких проектах не видны; «что чем вызывается?» — ведь стектрайс уходит в процессе не туда откуда реально пришёл запрос; причинно следственные связи надо понимать, иначе хана.

В реальной жизни «чистое» разделение ролей сервисов иногда мешает на этапе интеграции и вводятся «костыли», например, с сервера возвращается JS скрипт или декларации/параметры для его вызова — эти не описанные (не запланированные) возможности начинают использоваться чаще и чаще… а они — есть супер-побочный эффект (костыль).

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

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

В центре такой системы могут встать библиотеки «RPC». Я обещаю подготовить обзор известных мне подходов в следующих статьях. RPC — достойная тема для такого обзора. коротко: все эти методы не совершенны.  Это инструмент, применение которого надо оправдать и отыграть выгодой. Его глупо применять просто потому что «пора выносить эти 5 строк в сервис т.к. у нас микросервисная архитектура».

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *