Микросервисы Что такое микросервисы?

Использование микросервисов

Это первая часть серии блог-постов о микросервисах. Представляется, что в обществе существует много разночтений относительно того, чем является микросервисы; когда их нужно использовать и какой подход к ним применить.

Серия этих блог-постов, по сути, - следствие 5-летнего опыта построения и изучения природы микросервисов. Я допускаю, что не все согласятся с тем, о чем я здесь буду писать, но, я надеюсь, что не найдется столь контроверсионных положений, которые могли бы вызвать серьезные противоречия.

Часть 1. Что такое микросервисы?
Часть 2. Когда следует использовать микросервисы?
Часть 3. Почему вам не стоит использовать микросервисы?

Самое важное, что нужно уяснить, когда речь идет о микросервисах, - это убедиться в том, что когда мы говорим о микросервисах, мы отталкиваемся от одного и того же исходного положения. На протяжении своей карьеры я старался придерживаться простой философии: если не приходят к согласию двое умных людей, один из них не учитывает одного из имеющихся контекстов. Я хотел бы сейчас вспомнить, кто вложил эту мысль мне в голову; и хотя это положение не всегда утверждалось, оно, безусловно, привнесло большое благо в мои профессиональные отношения.

Цель написания этого блог-поста - это еще раз убедиться в том, что когда мы общаемся, то исходим из одного и того же контекста. Что бы мы (или конкретнее я б) хотел сделать в этой сфере, то это избежать разночтений лексических значений. Даже среди моих коллег наблюдается довольно значительная путаница в отношении к тому, чем на самом деле являются микросервисы. Насколько они макро? Насколько они сервисы.

В общем, не существует единого определения, которое бы объясняло, чем на самом деле является микросервис. Однако, я верю, что выработка унифицированного взгляда на то, чем являются микросервисы, и как они работают, очень важно, и именно для этого я пишу этот блог-пост.

Первое, что нужно четко осознать - это то, чем микросервис не является. Микросервисы - это не миллион сервисов,  которые создают один, единственный сервис (подумайте сами микро = 1000000? Это уже смешно))). Говоря серьезно, если кто-то может написать архитектуру микросервиса каждым из ПРС ресурсов, который является единственным сервисом, то это может привести к весьма неоднозначной архитектуре. Я буду говорить об этом подробнее в следующем блог-посте. Микросервисы - не являются также несколькими крупными сервисами, каждый из которых покрывает несколько функций и которые взаимосвязуются по базе данных или через КШД в больших корпоративных системах. Напротив, правда, я думаю, находится где-то посередине.

Другой важной вещью, которую следует осознать, - это то, что микросервисы обязательно должны разворачиваться индивидуально. Вместо того, чтобы фокусироваться на сервисах, которые разворачиваются индивидуально достаточно выбрать группы сервисов, которые можно развернуть индивидуально. Джеймс Левис описывает это в виде плана города и утверждает, что сервисы, которые функционируют совместно, чтобы выработать один или целый набор функционалов, могут разворачиваться индивидуально от других групп сервисов, которые предоставляют часть или целый набор функционалов.

В случае использования такой метафоры эти группы выглядят подобно кварталам в городе. Сервисы в определенном квартале необязательно должны разворачиваться индивидуально. Ведь, несутся затраты на развертывание сервисов индивидуально, а прагматичные люди избегают сервисов, которые разворачиваются индивидуально, если только это не приносит настоящей пользы. Акцентирую внимание еще раз, что мы углубимся в эту тему в следующем блог-посте.

Когда я разговаривал с Джеймсом Левис, я спросил его: "Какое определение можно дать микросервисам?" Его ответ был: "... высококачественная, отборная COA, произведенная на манеру "Юникс"." Звучит довольно однозначно. Важно помнить, что мы говорим о четко определенной части функционала, которая коммуницирует с другими четко определенными частями функционала через хорошо определенный интерфейс. Философия "Юникс" предполагает построение многих вещей, которые выполняют одну задачу; выполняют его хорошо и работают дистанционно через трубки и фильтры. Принимая во внимание эту философию и применяя ее к СОА, предполагается также выстраивание сервисов, которые фокусируются на одной части функционала и общаются с другими сервисами, чтобы выработать конкретную бизнес-стоимость.

Фактически, это продолжение принципа Боба Мартина- "Принципа единого обязательства" до уровня сервиса. На практике этого трудно достичь, но в идеальном мире - это значит, что нужно только изменить сервис (то есть он развернется), если функционал, за который он отвечает изменится. Это очень благородно, но и очень трудно, ведь разбиение системы на части может стать ночным кошмаром.

Коммуникация между этими сервисами должна быть осуществлена через четко определенный интерфейс, таки, оказывающий HTTP. К счастью, существует убедительная СOA архитектура, которая дает нам возможность наложить четко определенный интерфейс на HTTP. Про передачу репрезентативного состояния (ПРС) уже давно известно, и она хорошо удовлетворяет цели. В то время, когда невозможно достичь довольно высокой степени отграничения, которой можно достичь используя "Юникс", хорошему ПРС с гипер-медиа придется долго достигать ограничения.

Есть другие протоколы, которые могут работать в этом пространстве, и я не хочу сказать, что ПРС единственный, который соответствует модели. Во многих случаях другие протоколы трансфера более целесообразны чем HTTP. В рамках серии этих блог постов, и в целом, я считаю, что ПРС - это очень убедительная интеграционная техника, которая, если выполнена правильно, добавляет стоимости и превращает микросервисы с недостижимой мечты в реальность.

Итак, в данном контексте давайте определим микросервисы или архитектуру микросервисов следующим образом:

Система, которая строится на микросервисах - это система, выстроенная с малых "легких" сервисов, в которой каждый сервис играет свою функцию. Сервисы упорядочены в группы, индивидуально разворачиваются и общаются между собой через четко определенный интерфейс, а также сотрудничают, чтобы сгенерировать бизнес-стоимость.

Копирование этого контента разрешено только со ссылкой на источник и указанием автора материала TQM systems.

Автор Дэвид

• 
• Editor of TQM systems Olga Nikanorova
• 1/15/2021 5:32:40 PM
• articles