Привет, Хабр! В ближайшее время читайте пост о русском переводе долгожданной книги" Создание микросервисов Сэма Ньюмана, который уже разошелся по магазинам.
А пока предлагаем прочитать перевод статьи Аруна Гупты, автор которой описывает наиболее интересные паттерны проектирования, применимые в микросервисной архитектуре.
Основные характеристики микросервисных приложений описаны в статье « Микросервисы, монолиты и NoOps ".
Этими характеристиками являются функциональная декомпозиция или доменно-ориентированное проектирование, четко определенные интерфейсы, явно опубликованный интерфейс, принцип единой ответственности и потенциальный многоязычие.
Каждый сервис является полностью автономным и полнофункциональным.
Соответственно, изменение реализации одного Сервис не влияет на остальные, но обмен информацией происходит через четко определенные интерфейсы.
Такое приложение имеет ряд преимуществ, но они есть.
не дают бесплатно , но требуют серьезной работы, связанной с NoOps. Но давайте предположим, что вы понимаете масштаб этой работы, хотя бы частично, что вам действительно хочется создать такое приложение и посмотреть, что получится.
Что делать? Какова будет архитектура такого приложения?
Существуют ли шаблоны проектирования, оптимизирующие взаимодействие микросервисов? 
Чтобы создать хорошую микросервисную архитектуру, вам необходимо четко разделить функции в вашем приложении и команде.
Таким образом вы можете добиться слабой связи (интерфейсы REST) и сильной связи (несколько служб могут быть объединены вместе для определения служб или приложения более высокого уровня).
Создание «глаголов» (например, Checkout) или «существительных» (Product) как части приложения — один из эффективных способов декомпозиции существующего кода.
Например, товар, каталог и оформление заказа можно реализовать как три отдельных микросервиса, а затем взаимодействовать друг с другом, обеспечивая полную функциональность корзины покупок.
Функциональная декомпозиция обеспечивает гибкость, масштабируемость и другие преимущества, но наша задача — создать приложение.
Итак, если отдельные микросервисы идентичны, как их объединить для реализации функциональности приложения? Об этом пойдет речь в статье.
Шаблон агрегатора Первый и, пожалуй, самый распространенный шаблон проектирования при работе с микросервисами — это «агрегатор».
В простейшем виде агрегатор — это обычная веб-страница, вызывающая множество сервисов для реализации необходимого в приложении функционала.
Поскольку все службы (Служба A, Служба B и Служба C) предоставляются с использованием облегченного механизма REST, веб-страница может извлекать данные и обрабатывать/отображать их по мере необходимости.
Если требуется некоторая обработка, например применение бизнес-логики к данным, полученным от отдельных служб, вы можете использовать компонент CDI, который преобразует данные так, чтобы их можно было отобразить на веб-странице.
Агрегатор также можно использовать в тех случаях, когда нет необходимости отображать что-либо, а только составной микросервис более высокого уровня, который может использоваться другими сервисами.
В этом случае агрегатор просто соберет данные со всех отдельных микросервисов, применит к ним бизнес-логику, а затем опубликует микросервис как конечную точку REST. В этом случае при необходимости он может быть использован другими сервисами, которым он нужен.
Этот шаблон соответствует принципу DRY. Если имеется множество сервисов, которым требуется доступ к сервисам A, B и C, то рекомендуется абстрагировать эту логику в составной микросервис и агрегировать ее как отдельный сервис.
Преимущество абстракции на этом уровне заключается в том, что отдельные сервисы, скажем A, B и C, могут развиваться независимо, в то время как бизнес-логика продолжает выполняться составным микросервисом.
Обратите внимание, что каждый отдельный микросервис (необязательно) имеет свои собственные уровни кэширования и базы данных.
Если агрегатор представляет собой составной микросервис, то у него могут быть такие уровни.
Агрегатор также может самостоятельно масштабироваться как по горизонтали, так и по вертикали.
То есть, если мы говорим о веб-странице, то к ней можно присоединить дополнительные веб-серверы, а если это составной микросервис, использующий Java EE, то к нему можно присоединить дополнительные экземпляры WildFly для удовлетворения растущих потребностей.
Посредник шаблонов (прокси) Паттерн «посредник» при работе с микросервисами — это вариант агрегатора.
В этом случае агрегация должна происходить на клиенте, но в зависимости от бизнес-требований может быть вызван дополнительный микросервис.
Как и агрегатор, реселлер может независимо масштабироваться по горизонтали и вертикали.
Это может быть необходимо в ситуации, когда каждую отдельную услугу нужно не предоставлять потребителю, а запускать через интерфейс.
Посредником может быть формальный (тупой), в данном случае он просто делегирует запрос одному из сервисов.
Он может быть интеллектуальный (умный), в этом случае данные перед отправкой клиенту подвергаются той или иной трансформации.
Например, уровень представления для различных устройств может быть инкапсулирован в интеллектуальный посредник.
Шаблон проектирования «Цепочка» Шаблон проектирования микросервиса «Цепочка» создает единый консолидированный ответ на запрос.
В этом случае Служба A получает запрос от клиента, связывается со Службой B, которая, в свою очередь, может связаться со Службой C. Все эти службы, скорее всего, будут обмениваться синхронными сообщениями запроса/ответа через HTTP. 
Здесь самое главное помнить, что клиент блокируется до тех пор, пока не будет завершена вся цепочка коммуникаций запросов и ответов, т.е.
сервис <-> Сервис Б и Сервис Б <-> Сервис C. Запрос от Сервиса B к Сервису C может выглядеть совершенно иначе, чем ответ от Сервиса A к Сервису B. Аналогично, ответ от Сервиса B к Сервису A может выглядеть принципиально отличным от ответа от Сервиса C к Сервису B. Это является наиболее важным во всех случаях, когда коммерческая ценность нескольких услуг суммируется.
Здесь также важно понимать, что не следует делать цепочку слишком длинной.
Это критично, поскольку цепочка по своей природе синхронна, и чем она длиннее, тем дольше клиенту придется ждать, особенно если ответ предполагает отображение веб-страницы на экране.
Существуют способы обойти этот блокирующий механизм запросов и ответов, и они обсуждаются в следующем шаблоне.
Цепочка, состоящая из одного микросервиса, называется одноэлементной цепочкой.
Позже его можно будет расширить.
Шаблон проектирования ветвей Паттерн проектирования микросервисов «Ветвь» расширяет паттерн «Агрегатор» и обеспечивает одновременную обработку ответов от двух цепочек микросервисов, которые могут быть взаимоисключающими.
Этот шаблон также можно использовать для вызова разных цепочек или одной и той же цепочки, в зависимости от ваших потребностей.
Сервис А, будь то веб-страница или составной микросервис, может одновременно вызывать две разные цепочки, и в этом случае он будет напоминать агрегатор.
В другом случае сервис А может вызвать только одну цепочку в зависимости от того, какой запрос он получит от клиента.
Такой механизм можно настроить путем реализации маршрутизации конечных точек JAX-RS, и в этом случае конфигурация должна быть динамической.
Общий шаблон данных Одним из принципов проектирования микросервисов является автономность.
Это означает, что сервис является полнофункциональным и контролирует все компоненты — пользовательский интерфейс, промежуточное программное обеспечение, постоянство, транзакции.
В этом случае сервис может быть многоязычным и решать каждую проблему, используя наиболее подходящие инструменты.
Например, если при необходимости вы можете использовать хранилище данных NoSQL, то лучше сделать это, а не запихивать эту информацию в базу данных SQL. Однако типичная проблема, особенно при рефакторинге существующего монолитного приложения, связана с нормализацией базы данных — чтобы в каждом микросервисе было строго определенное количество информации, ни больше, ни меньше.
Даже если монолитное приложение использует только базу данных SQL, ее денормализация приводит к дублированию данных и, возможно, к несогласованности.
На этапе перехода в некоторых приложениях может быть очень полезно использовать шаблон общих данных.
В этом шаблоне несколько микросервисов могут работать в цепочке и совместно использовать кеш и хранилище базы данных.
Это целесообразно только в том случае, если между двумя службами существует прочная связь.
Некоторые могут счесть это антишаблоном, но в некоторых деловых ситуациях такой шаблон действительно уместен.
Это определенно будет антишаблоном в приложении, которое изначально создано как микросервис.
Его также можно рассматривать как промежуточный этап, который необходимо преодолеть, пока микросервисы не станут полностью автономными.
Шаблон асинхронного обмена сообщениями Каким бы распространенным и понятным ни был паттерн REST, он имеет важное ограничение: он синхронен и, следовательно, блокирует. Асинхронность обеспечить можно, но в каждом приложении это делается по-разному.
Поэтому некоторые архитектуры микросервисов могут использовать очереди сообщений, а не модель запросов/ответов REST. 
В этом шаблоне Служба A может синхронно вызывать Службу C, которая затем будет асинхронно взаимодействовать со Службами B и C, используя общую очередь сообщений.
Связь Служба A -> Служба C может быть асинхронной, например, с использованием веб-сокетов; Так достигается желаемая масштабируемость.
Для достижения этих целей также можно использовать сочетание модели запроса/ответа REST и обмена сообщениями издателя/подписчика.
Также рекомендую прочитать статью Связывание против автономии в микросервисах , в котором описывается, какие шаблоны взаимодействия удобно использовать с микросервисами.
Теги: #программирование #Микросервисы #проектирование и рефакторинг #отдых #книги #книги #паттерны проектирования #масштабируемость #масштабируемость #обмен сообщениями
-
Оценка Идей Стартапа (Часть 2)
19 Oct, 24 -
Наш Долгий Путь К Команде Мечты
19 Oct, 24 -
Вопрос Про Соцсети Для Туристов
19 Oct, 24 -
Страницы Github Переезжают На Github.io
19 Oct, 24
