Сегодня в моде микросервисы. Так что же это такое?
Хотите верьте, хотите нет, но однозначного ответа на вопрос, что такое микросервис, не существует. Скорее ответ кроется больше в том, чем он не является.
В программном обеспечении артефакты подразделяются на две широкие категории. Один — монолит, а другой — микросервис.
Монолит — это часть программного обеспечения, в котором все компоненты объединены в одно основное приложение, и оно должно поставляться таким, какое оно есть. Если есть ошибка, вам нужно отправить новую часть программного обеспечения, чтобы заменить ее, или произвести обновление, которое вполне может потребовать переустановки всего приложения. Многие старые продукты MVC представляли собой монолитную разработку, начиная от пакета MFC и заканчивая классическими WinForms и старыми консольными приложениями. Если есть один вывод, который нужно помнить, так это то, что в монолитной архитектуре есть единая точка отказа.
В архитектуре на основе микросервисов существует несколько приложений, известных как микросервисы. В этом смысле нет единой точки отказа. Если вам нужно обновить один микросервис, вы можете сделать это, не затрагивая напрямую другие части приложения. Обновления могут быть отправлены и закреплены на месте. Элементы функциональности можно добавлять и удалять, как кусочки головоломки.
В случае сбоя микрослужбы происходит сбой этой части приложения, но остальная часть приложения по-прежнему может использоваться до некоторой степени, в зависимости от связи микрослужб. Низкая связанность предпочтительна из-за простоты замены.
Микросервисы могут знать или не знать друг о друге, даже если они существуют. Есть много примеров того, как это может работать, но для простоты я поделюсь двумя популярными подходами.
Пример 1:
Предположим, что существует множество микросервисов, работающих на отдельных портах TCP/IP, и каждый из них использует одну и ту же серверную часть базы данных, но каждый из них предоставляет совершенно не связанные друг с другом функции с UX, который легко их соединяет. Пользователь понятия не имеет, основано ли это на монолите или на микросервисах, но микросервисы могут функционировать независимо. Каждый из них может обновлять базу данных, и когда другой микросервис получает доступ к базе данных, он может делать это без какого-либо отношения к другому фрагменту кода как к зависимости.
Пример 2:
Предположим, у нас есть несколько микросервисов, работающих на разных портах TCP/IP, но бывают случаи, когда нам нужно обновить более одного одновременно для бесперебойного потока UX. Это тот случай, когда очередь сообщений может пригодиться. Существует множество систем очередей сообщений, наиболее популярными из которых являются Java Messaging Service (JMS) и Message Queue Telemetry Transport (MQTT).
Работа этих очередей сообщений заключается в том, что разные службы подписываются на очередь и прослушивают сообщения. Когда приходит сообщение, представляющее интерес для службы, она может перехватить его и использовать соответствующим образом. Каждый подписчик имеет эту возможность, оставляя отношение один ко многим в отношении обработки.
Таким образом, микросервисы могут взаимодействовать так же, как монолиты, имея возможность обновляться одновременно, но им не нужно напрямую знать о существовании друг друга, и каждый из них может свободно выполнять одну задачу.
Существуют варианты использования, которые приносят пользу как монолитной, так и микросервисной разработке, но это обсуждение выходит за рамки этой записи в блоге.
Надеюсь, это послужит хорошей отправной точкой для объяснения этого нового и часто считающегося таинственным нового архитектурного паттерна.
