День шестьсот тридцать шестой. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 1/7
В 2000 году Роберт Мартин составил пять принципов объектно-ориентированного проектирования, которые Майкл Фезерс позднее объединил в аббревиатуру SOLID. С тех пор принципы SOLID для объектно-ориентированного проектирования были неоднократно описаны в книгах и стали широко известны в отрасли.
Применимы ли принципы SOLID к микросервисам? Отчасти.
Мы, как отрасль, разрабатываем и внедряем решения на основе микросервисов уже более шести лет. За это время постоянно увеличивающееся количество инструментов, фреймворков, платформ и вспомогательных продуктов создали невероятно богатый технологический ландшафт вокруг микросервисов.
Такой ландшафт может вызвать головокружение у начинающих разработчиков микросервисов из-за множества дизайнерских и технологических решений, с которыми они могут столкнуться. И в этом случае базовый набор принципов может помочь разработчикам выбрать правильные проектные решения.
Хотя некоторые принципы SOLID применимы к микросервисам, объектная ориентация - это парадигма дизайна на уровне элементов (классов, интерфейсов, иерархий и т.д.), которые принципиально отличаются от элементов в распределённых системах в целом и микросервисах в частности.
Рассмотрим следующий набор основных принципов проектирования микросервисов:
I - Разделение интерфейсов
D - Легкость развёртывания
E – Ориентированность на события
A - Доступность важнее согласованности
L - Слабая связанность
S - Единственная ответственность
Эти принципы не охватывают весь спектр проектных решений для микросервисов, но они затрагивают ключевые проблемы и факторы успеха для создания современных систем на основе сервисов.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 1/7
В 2000 году Роберт Мартин составил пять принципов объектно-ориентированного проектирования, которые Майкл Фезерс позднее объединил в аббревиатуру SOLID. С тех пор принципы SOLID для объектно-ориентированного проектирования были неоднократно описаны в книгах и стали широко известны в отрасли.
Применимы ли принципы SOLID к микросервисам? Отчасти.
Мы, как отрасль, разрабатываем и внедряем решения на основе микросервисов уже более шести лет. За это время постоянно увеличивающееся количество инструментов, фреймворков, платформ и вспомогательных продуктов создали невероятно богатый технологический ландшафт вокруг микросервисов.
Такой ландшафт может вызвать головокружение у начинающих разработчиков микросервисов из-за множества дизайнерских и технологических решений, с которыми они могут столкнуться. И в этом случае базовый набор принципов может помочь разработчикам выбрать правильные проектные решения.
Хотя некоторые принципы SOLID применимы к микросервисам, объектная ориентация - это парадигма дизайна на уровне элементов (классов, интерфейсов, иерархий и т.д.), которые принципиально отличаются от элементов в распределённых системах в целом и микросервисах в частности.
Рассмотрим следующий набор основных принципов проектирования микросервисов:
I - Разделение интерфейсов
D - Легкость развёртывания
E – Ориентированность на события
A - Доступность важнее согласованности
L - Слабая связанность
S - Единственная ответственность
Эти принципы не охватывают весь спектр проектных решений для микросервисов, но они затрагивают ключевые проблемы и факторы успеха для создания современных систем на основе сервисов.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот тридцать седьмой. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 2/7
I – Разделение Интерфейсов (Interface Segregation)
Исходный принцип разделения интерфейсов предостерегает от использования в ООП «жирных» интерфейсов. Другими словами, вместо интерфейса со всеми возможными методами, которые могут понадобиться клиентам, должны быть отдельные интерфейсы, обслуживающие конкретные потребности каждого типа клиентов.
Стиль микросервисной архитектуры - это специализация сервисно-ориентированной архитектуры (SOA), в которой дизайн интерфейсов (то есть контрактов сервисов) всегда имел первостепенное значение. С начала 2000-х, литература по SOA предписывала использовать канонические модели или канонические схемы, которым должны соответствовать все клиенты сервисов. Однако наш подход к разработке контрактов на обслуживание изменился со времен SOA. В эпоху микросервисов часто существует множество клиентских программ (фронтендов) для одной логики сервиса. Это основная мотивация применения принципа разделения интерфейсов к микросервисам.
Реализация разделения интерфейсов для микросервисов
Цель разделения интерфейсов для микросервисов состоит в том, чтобы каждый тип фронтенда получал контракт на обслуживание, который наилучшим образом соответствует его потребностям. Например: мобильное приложение хочет вызвать конечные точки, которые отвечают кратким представлением данных в формате JSON. Веб-приложение в той же системе использует полное представление объектов в JSON. Старое настольное приложение, которое вызывает ту же службу, требует полного представления, но в XML. Разные клиенты также могут использовать разные протоколы. Например, внешние клиенты могут использовать HTTP для вызова сервиса gRPC.
Вместо того, чтобы пытаться навязать один и тот же контракт (с использованием канонических моделей) для всех типов клиентов сервиса, мы «разделяем интерфейс», чтобы каждый тип клиента видел интерфейс сервиса, который ему нужен. Как это сделать? Отличным вариантом является использование шлюза API. Он может выполнять преобразование формата и структуры сообщений, преобразование протоколов, маршрутизацию сообщений и многое другое. Популярной альтернативой является шаблон Backend for Frontend (BFF). В этом случае у нас есть шлюз API для каждого типа клиента или разные BFF для каждого клиента, как показано на рисунке ниже.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 2/7
I – Разделение Интерфейсов (Interface Segregation)
Исходный принцип разделения интерфейсов предостерегает от использования в ООП «жирных» интерфейсов. Другими словами, вместо интерфейса со всеми возможными методами, которые могут понадобиться клиентам, должны быть отдельные интерфейсы, обслуживающие конкретные потребности каждого типа клиентов.
Стиль микросервисной архитектуры - это специализация сервисно-ориентированной архитектуры (SOA), в которой дизайн интерфейсов (то есть контрактов сервисов) всегда имел первостепенное значение. С начала 2000-х, литература по SOA предписывала использовать канонические модели или канонические схемы, которым должны соответствовать все клиенты сервисов. Однако наш подход к разработке контрактов на обслуживание изменился со времен SOA. В эпоху микросервисов часто существует множество клиентских программ (фронтендов) для одной логики сервиса. Это основная мотивация применения принципа разделения интерфейсов к микросервисам.
Реализация разделения интерфейсов для микросервисов
Цель разделения интерфейсов для микросервисов состоит в том, чтобы каждый тип фронтенда получал контракт на обслуживание, который наилучшим образом соответствует его потребностям. Например: мобильное приложение хочет вызвать конечные точки, которые отвечают кратким представлением данных в формате JSON. Веб-приложение в той же системе использует полное представление объектов в JSON. Старое настольное приложение, которое вызывает ту же службу, требует полного представления, но в XML. Разные клиенты также могут использовать разные протоколы. Например, внешние клиенты могут использовать HTTP для вызова сервиса gRPC.
Вместо того, чтобы пытаться навязать один и тот же контракт (с использованием канонических моделей) для всех типов клиентов сервиса, мы «разделяем интерфейс», чтобы каждый тип клиента видел интерфейс сервиса, который ему нужен. Как это сделать? Отличным вариантом является использование шлюза API. Он может выполнять преобразование формата и структуры сообщений, преобразование протоколов, маршрутизацию сообщений и многое другое. Популярной альтернативой является шаблон Backend for Frontend (BFF). В этом случае у нас есть шлюз API для каждого типа клиента или разные BFF для каждого клиента, как показано на рисунке ниже.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот тридцать восьмой. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 3/7
D – Легкость развёртывания (Deployability)
Как разработчики, мы давно осознаём важность правильной упаковки и развертывания ПО, но мы никогда не уделяли так много внимания развёртыванию и мониторингу во время выполнения, как при использовании микросервисов. Технологии и дизайнерские решения, используемые при развёртывании, критически важны для успеха микросервисов. Основная причина в том, что микросервисы резко увеличивают количество единиц развёртывания.
Разработчики микросервисов несут ответственность за обеспечение доступности ПО и его новых версий для пользователей. Легкость развёртывания включает:
1. Настройку инфраструктуры времени выполнения: контейнеры, модули, кластеры, хранилище, безопасность и сеть.
2. Масштабирование микросервисов или их перенос из одной среды выполнения в другую.
3. Ускорение процесса «внесение изменений > сборка > тестирование > развёртывание».
4. Минимизацию времени простоя при замене текущей версии.
5. Синхронизацию изменений версий связанного ПО.
6. Контроль состояния микросервисов для быстрого выявления и устранения неисправностей.
Автоматизация - ключ к эффективному развёртыванию. В этой области мы наблюдаем наибольшие изменения с момента появления микросервисов. Поэтому разработчики микросервисов постоянно должны искать новые инструменты и платформы, но всегда оценивать их преимущества и недостатки.
Вот список стратегий и технологий для улучшения развёртываемости микросервисов:
1. Контейнеризация: Контейнерные микросервисы намного проще реплицировать и развёртывать на различных платформах и в облаке.
2. Service mesh: этот вид инструментов может использоваться для мониторинга трафика, применения политик, аутентификации, маршрутизации, автоматического включения, преобразования сообщений и т.п.
3. Шлюз API: перехватывая вызовы микросервисов, шлюз API предоставляет широкий набор функций, включая преобразование сообщений и протоколов, мониторинг трафика, средства управления безопасностью, маршрутизацию, кэш, регулирование запросов и т.п.
4. Бессерверная архитектура: вы можете избежать значительной части сложности и эксплуатационных затрат, связанных с управлением контейнерами, развернув свои службы на бессерверной платформе, которая следует парадигме Функция как Услуга (FaaS).
5. Инструменты мониторинга: при наличии микросервисов, распределённых по вашей локальной и облачной инфраструктуре, возможность прогнозировать, обнаруживать и уведомлять о проблемах, связанных с работоспособностью системы, приобретает решающее значение.
6. Инструменты консолидации журналов: микросервисы могут увеличить количество единиц развёртывания на порядок. Нужны инструменты консолидации журналов с возможностью поиска, анализа и генерации предупреждений.
7. Инструменты трассировки: их можно использовать при создании микросервисов, а затем для создания, сбора и визуализации данных трассировки времени выполнения. Они помогают обнаружить проблемы с производительностью (а иногда даже помогают понять архитектуру).
8. DevOps: микросервисы работают лучше, когда команды разработчиков и DevOps общаются и тесно сотрудничают от настройки инфраструктуры до обработки инцидентов.
9. «Сине-зелёное развертывание» и «канареечный» выпуск: эти стратегии развёртывания допускают нулевое или почти нулевое время простоя при выпуске новой версии микросервиса с быстрым переключением в случае возникновения проблем.
10. Инфраструктура как код (IaC): обеспечивает минимальное вмешательство человека в цикл сборки-развёртывания, который становится более быстрым, менее подверженным ошибкам и более контролируемым.
11. Непрерывная доставка: практика сокращения интервала от внесения изменений до развёртывания при сохранении качества решений.
12. Внешняя конфигурация: этот механизм позволяет сохранять свойства конфигурации вне модуля развертывания микросервиса и легко управлять ими.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 3/7
D – Легкость развёртывания (Deployability)
Как разработчики, мы давно осознаём важность правильной упаковки и развертывания ПО, но мы никогда не уделяли так много внимания развёртыванию и мониторингу во время выполнения, как при использовании микросервисов. Технологии и дизайнерские решения, используемые при развёртывании, критически важны для успеха микросервисов. Основная причина в том, что микросервисы резко увеличивают количество единиц развёртывания.
Разработчики микросервисов несут ответственность за обеспечение доступности ПО и его новых версий для пользователей. Легкость развёртывания включает:
1. Настройку инфраструктуры времени выполнения: контейнеры, модули, кластеры, хранилище, безопасность и сеть.
2. Масштабирование микросервисов или их перенос из одной среды выполнения в другую.
3. Ускорение процесса «внесение изменений > сборка > тестирование > развёртывание».
4. Минимизацию времени простоя при замене текущей версии.
5. Синхронизацию изменений версий связанного ПО.
6. Контроль состояния микросервисов для быстрого выявления и устранения неисправностей.
Автоматизация - ключ к эффективному развёртыванию. В этой области мы наблюдаем наибольшие изменения с момента появления микросервисов. Поэтому разработчики микросервисов постоянно должны искать новые инструменты и платформы, но всегда оценивать их преимущества и недостатки.
Вот список стратегий и технологий для улучшения развёртываемости микросервисов:
1. Контейнеризация: Контейнерные микросервисы намного проще реплицировать и развёртывать на различных платформах и в облаке.
2. Service mesh: этот вид инструментов может использоваться для мониторинга трафика, применения политик, аутентификации, маршрутизации, автоматического включения, преобразования сообщений и т.п.
3. Шлюз API: перехватывая вызовы микросервисов, шлюз API предоставляет широкий набор функций, включая преобразование сообщений и протоколов, мониторинг трафика, средства управления безопасностью, маршрутизацию, кэш, регулирование запросов и т.п.
4. Бессерверная архитектура: вы можете избежать значительной части сложности и эксплуатационных затрат, связанных с управлением контейнерами, развернув свои службы на бессерверной платформе, которая следует парадигме Функция как Услуга (FaaS).
5. Инструменты мониторинга: при наличии микросервисов, распределённых по вашей локальной и облачной инфраструктуре, возможность прогнозировать, обнаруживать и уведомлять о проблемах, связанных с работоспособностью системы, приобретает решающее значение.
6. Инструменты консолидации журналов: микросервисы могут увеличить количество единиц развёртывания на порядок. Нужны инструменты консолидации журналов с возможностью поиска, анализа и генерации предупреждений.
7. Инструменты трассировки: их можно использовать при создании микросервисов, а затем для создания, сбора и визуализации данных трассировки времени выполнения. Они помогают обнаружить проблемы с производительностью (а иногда даже помогают понять архитектуру).
8. DevOps: микросервисы работают лучше, когда команды разработчиков и DevOps общаются и тесно сотрудничают от настройки инфраструктуры до обработки инцидентов.
9. «Сине-зелёное развертывание» и «канареечный» выпуск: эти стратегии развёртывания допускают нулевое или почти нулевое время простоя при выпуске новой версии микросервиса с быстрым переключением в случае возникновения проблем.
10. Инфраструктура как код (IaC): обеспечивает минимальное вмешательство человека в цикл сборки-развёртывания, который становится более быстрым, менее подверженным ошибкам и более контролируемым.
11. Непрерывная доставка: практика сокращения интервала от внесения изменений до развёртывания при сохранении качества решений.
12. Внешняя конфигурация: этот механизм позволяет сохранять свойства конфигурации вне модуля развертывания микросервиса и легко управлять ими.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот тридцать девятый. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 4/7
E – Ориентированность на события (Event-Driven)
Архитектура микросервисов предназначена для создания серверных сервисов, которые обычно активируются используя один из следующих вызовов:
1. HTTP-вызов (к REST сервису)
2. RPC-вызов, такой как gRPC или GraphQL
3. Асинхронное сообщение, которое проходит через очередь в диспетчере сообщений.
Первые два обычно являются синхронными, и HTTP-вызовы наиболее распространены. Часто сервисам необходимо вызывать другие сервисы, и во многих случаях это взаимодействие является синхронным. Если вместо этого мы создадим (или адаптируем) участвующие сервисы на подключение и получение сообщений из очереди, мы создадим архитектуру на основе событий.
Важным преимуществом такой архитектуры является улучшенная масштабируемость и пропускная способность. Это связано с тем, что отправители сообщений не блокируются в ожидании ответа, и одно и то же сообщение/событие могут использоваться параллельно несколькими получателями в режиме публикации-подписки.
Микросервис, управляемый событиями
Буква E в IDEALS советует нам стараться моделировать микросервисы, управляемые событиями, потому что они с большей вероятностью будут соответствовать требованиям масштабируемости и производительности современных программных решений. Такой дизайн также способствует слабой связанности, поскольку отправители и получатели сообщений - микросервисы - независимы и не знают друг о друге. Надёжность также повышается, потому что конструкция может справляться с временными отключениями микросервисов, которые позже могут обработать помещённые в очередь сообщения.
Но микросервисы, управляемые событиями, также известные как реактивные микросервисы, могут создавать проблемы. Обработка активируется асинхронно и происходит параллельно, возможно, требуя точек синхронизации и корреляции сообщений. Дизайн должен учитывать ошибки и потерянные сообщения: часто необходимы корректирующие события и механизмы отмены изменений данных. Кроме того, должен быть продуман пользовательский опыт в транзакциях, обращённых к пользователю, чтобы держать конечного пользователя в курсе о прогрессе или неудаче транзакции.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 4/7
E – Ориентированность на события (Event-Driven)
Архитектура микросервисов предназначена для создания серверных сервисов, которые обычно активируются используя один из следующих вызовов:
1. HTTP-вызов (к REST сервису)
2. RPC-вызов, такой как gRPC или GraphQL
3. Асинхронное сообщение, которое проходит через очередь в диспетчере сообщений.
Первые два обычно являются синхронными, и HTTP-вызовы наиболее распространены. Часто сервисам необходимо вызывать другие сервисы, и во многих случаях это взаимодействие является синхронным. Если вместо этого мы создадим (или адаптируем) участвующие сервисы на подключение и получение сообщений из очереди, мы создадим архитектуру на основе событий.
Важным преимуществом такой архитектуры является улучшенная масштабируемость и пропускная способность. Это связано с тем, что отправители сообщений не блокируются в ожидании ответа, и одно и то же сообщение/событие могут использоваться параллельно несколькими получателями в режиме публикации-подписки.
Микросервис, управляемый событиями
Буква E в IDEALS советует нам стараться моделировать микросервисы, управляемые событиями, потому что они с большей вероятностью будут соответствовать требованиям масштабируемости и производительности современных программных решений. Такой дизайн также способствует слабой связанности, поскольку отправители и получатели сообщений - микросервисы - независимы и не знают друг о друге. Надёжность также повышается, потому что конструкция может справляться с временными отключениями микросервисов, которые позже могут обработать помещённые в очередь сообщения.
Но микросервисы, управляемые событиями, также известные как реактивные микросервисы, могут создавать проблемы. Обработка активируется асинхронно и происходит параллельно, возможно, требуя точек синхронизации и корреляции сообщений. Дизайн должен учитывать ошибки и потерянные сообщения: часто необходимы корректирующие события и механизмы отмены изменений данных. Кроме того, должен быть продуман пользовательский опыт в транзакциях, обращённых к пользователю, чтобы держать конечного пользователя в курсе о прогрессе или неудаче транзакции.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот соровокой. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 5/7
A - Доступность важнее согласованности (Availability over Consistency)
Теорема CAP, по сути, это выбор: либо согласованность, либо доступность. Обычно вам предлагается вам выбрать доступность, согласившись с уровнем согласованности. Причина проста: сегодняшние конечные пользователи не будут мириться с отсутствием доступности. Представьте себе интернет-магазин во время Чёрной пятницы. Если мы обеспечим строгую согласованность между количеством товара на складе, отображаемым при просмотре товаров, и фактическими запасами, обновляемыми при покупках, изменения данных повлекут за собой значительные накладные расходы. Если сервис обновления остатков становится временно недоступен, каталог не сможет отображать информацию о запасах, и система оформления заказов перестанет работать. Если вместо этого мы выберем доступность (принимая риск случайных несоответствий), пользователи смогут совершать покупки на основе данных о запасах, которые могут быть немного устаревшими. Одна из нескольких сотен или тысяч транзакций может закончиться тем, что неудачливый пользователь позже получит электронное письмо с извинениями за отмену покупки из-за неверной информации о запасах во время оформления заказа. Тем не менее, с точки зрения пользователя (и бизнеса) этот сценарий лучше, чем когда система недоступна или очень медленная для всех пользователей, потому что пытается обеспечить строгую согласованность.
Некоторые бизнес-операции требуют строгой последовательности. Однако, когда люди сталкиваются с выбором: как следует или прямо сейчас, они обычно выбирают «прямо сейчас».
Доступность с возможной согласованностью
Для микросервисов основной стратегией, обеспечивающей доступность, является репликация данных. Могут использоваться разные шаблоны проектирования, которые можно комбинировать:
1. Паттерн Репликации Данных Сервиса (SDR): используется, когда микросервису необходимо получить доступ к данным, принадлежащим другим приложениям (а вызовы API не подходят для получения данных). Мы создаем копию этих данных и делаем её доступной для микросервиса. При этом требуется механизм синхронизации данных, который будет периодически или на основе триггера обеспечивать согласованность копий и основных данных.
2. Паттерн Разделения Ответственности Запросов и Команд (CQRS): здесь мы отделяем разработку и реализацию операций, которые изменяют данные (команды), от операций, которые только читают данные (запросы). CQRS обычно основывается на SDR для запросов для повышения производительности и автономности.
3. Паттерн Источник Событий (Event Sourcing): вместо сохранения текущего состояния объекта в базе данных мы сохраняем неизменяемую последовательность событий, которые повлияли на этот объект. Текущее состояние получается путём воспроизведения событий. Event Sourcing обычно строится на основе CQRS.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 5/7
A - Доступность важнее согласованности (Availability over Consistency)
Теорема CAP, по сути, это выбор: либо согласованность, либо доступность. Обычно вам предлагается вам выбрать доступность, согласившись с уровнем согласованности. Причина проста: сегодняшние конечные пользователи не будут мириться с отсутствием доступности. Представьте себе интернет-магазин во время Чёрной пятницы. Если мы обеспечим строгую согласованность между количеством товара на складе, отображаемым при просмотре товаров, и фактическими запасами, обновляемыми при покупках, изменения данных повлекут за собой значительные накладные расходы. Если сервис обновления остатков становится временно недоступен, каталог не сможет отображать информацию о запасах, и система оформления заказов перестанет работать. Если вместо этого мы выберем доступность (принимая риск случайных несоответствий), пользователи смогут совершать покупки на основе данных о запасах, которые могут быть немного устаревшими. Одна из нескольких сотен или тысяч транзакций может закончиться тем, что неудачливый пользователь позже получит электронное письмо с извинениями за отмену покупки из-за неверной информации о запасах во время оформления заказа. Тем не менее, с точки зрения пользователя (и бизнеса) этот сценарий лучше, чем когда система недоступна или очень медленная для всех пользователей, потому что пытается обеспечить строгую согласованность.
Некоторые бизнес-операции требуют строгой последовательности. Однако, когда люди сталкиваются с выбором: как следует или прямо сейчас, они обычно выбирают «прямо сейчас».
Доступность с возможной согласованностью
Для микросервисов основной стратегией, обеспечивающей доступность, является репликация данных. Могут использоваться разные шаблоны проектирования, которые можно комбинировать:
1. Паттерн Репликации Данных Сервиса (SDR): используется, когда микросервису необходимо получить доступ к данным, принадлежащим другим приложениям (а вызовы API не подходят для получения данных). Мы создаем копию этих данных и делаем её доступной для микросервиса. При этом требуется механизм синхронизации данных, который будет периодически или на основе триггера обеспечивать согласованность копий и основных данных.
2. Паттерн Разделения Ответственности Запросов и Команд (CQRS): здесь мы отделяем разработку и реализацию операций, которые изменяют данные (команды), от операций, которые только читают данные (запросы). CQRS обычно основывается на SDR для запросов для повышения производительности и автономности.
3. Паттерн Источник Событий (Event Sourcing): вместо сохранения текущего состояния объекта в базе данных мы сохраняем неизменяемую последовательность событий, которые повлияли на этот объект. Текущее состояние получается путём воспроизведения событий. Event Sourcing обычно строится на основе CQRS.
Продолжение следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот сорок первый. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 6/7
L - Слабая связанность (Loose coupling)
В разработке ПО связанность означает степень взаимозависимости между двумя элементами ПО. Для систем, основанных на сервисах, связанность определяется тем, как пользователи сервиса взаимодействуют с сервисом. Мы знаем, что это взаимодействие должно осуществляться через контракт на обслуживание. Кроме того, контракт не должен быть тесно связан с деталями реализации или конкретной технологией. Сервис - это распределённый компонент, который может вызываться разными программами. Иногда хозяин сервиса даже не знает, где находятся все его пользователи (часто так бывает в случае сервисов c публичным API). Таким образом, следует избегать изменения контракта. Если сервисный контракт тесно связан с сервисной логикой или технологией, то он более подвержен изменениям, по мере развития логики или технологии.
Сервисам часто необходимо взаимодействовать с другими сервисами или другими типами компонентов, создавая таким образом эфферентную связь. Это взаимодействие устанавливает зависимости времени выполнения, которые напрямую влияют на автономность службы. Чем менее автономен сервис, тем менее предсказуемо его поведение: в лучшем случае он будет настолько быстрым, надежным и доступным, как самый медленный, наименее надёжный и наименее доступный компонент, который ему нужно вызвать.
Стратегии слабой связанности для сервисов
Буква L в IDEALS советует быть внимательными к связям сервисов и, следовательно, микросервисов. Можно использовать и комбинировать несколько стратегий, чтобы способствовать слабой связанности:
1. Точка-точка и публикация-подписка: эти стандартные шаблоны обмена сообщениями и их вариации способствуют ослаблению связанности, поскольку отправители и получатели не знают друг друга; контракт реактивного микросервиса становится именем и структурой сообщения в очереди.
2. API-шлюз и BFF: промежуточный компонент, который устраняет любые несоответствия между контрактом службы и форматом сообщения или протоколом, который клиент хочет видеть, тем самым помогая их разъединить.
3. Разработка через контракт: разрабатывая контракт независимо от любого существующего кода, мы избегаем создания API-интерфейсов, тесно связанных с технологией и реализацией.
4. Гипермедиа: для сервисов REST гипермедиа помогает интерфейсам быть более независимыми от конечных точек.
5. Паттерны Фасад и Адаптер: вариации этих шаблонов GoF в микросервисных архитектурах могут предполагать наличие внутренних компонентов или даже сервисов, которые предотвращают нежелательное связывание в реализации микросервиса.
6. База данных на каждый микросервис: микросервисы не только получают автономию, но и избегают прямого подключения к общим базам данных.
Окончание следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 6/7
L - Слабая связанность (Loose coupling)
В разработке ПО связанность означает степень взаимозависимости между двумя элементами ПО. Для систем, основанных на сервисах, связанность определяется тем, как пользователи сервиса взаимодействуют с сервисом. Мы знаем, что это взаимодействие должно осуществляться через контракт на обслуживание. Кроме того, контракт не должен быть тесно связан с деталями реализации или конкретной технологией. Сервис - это распределённый компонент, который может вызываться разными программами. Иногда хозяин сервиса даже не знает, где находятся все его пользователи (часто так бывает в случае сервисов c публичным API). Таким образом, следует избегать изменения контракта. Если сервисный контракт тесно связан с сервисной логикой или технологией, то он более подвержен изменениям, по мере развития логики или технологии.
Сервисам часто необходимо взаимодействовать с другими сервисами или другими типами компонентов, создавая таким образом эфферентную связь. Это взаимодействие устанавливает зависимости времени выполнения, которые напрямую влияют на автономность службы. Чем менее автономен сервис, тем менее предсказуемо его поведение: в лучшем случае он будет настолько быстрым, надежным и доступным, как самый медленный, наименее надёжный и наименее доступный компонент, который ему нужно вызвать.
Стратегии слабой связанности для сервисов
Буква L в IDEALS советует быть внимательными к связям сервисов и, следовательно, микросервисов. Можно использовать и комбинировать несколько стратегий, чтобы способствовать слабой связанности:
1. Точка-точка и публикация-подписка: эти стандартные шаблоны обмена сообщениями и их вариации способствуют ослаблению связанности, поскольку отправители и получатели не знают друг друга; контракт реактивного микросервиса становится именем и структурой сообщения в очереди.
2. API-шлюз и BFF: промежуточный компонент, который устраняет любые несоответствия между контрактом службы и форматом сообщения или протоколом, который клиент хочет видеть, тем самым помогая их разъединить.
3. Разработка через контракт: разрабатывая контракт независимо от любого существующего кода, мы избегаем создания API-интерфейсов, тесно связанных с технологией и реализацией.
4. Гипермедиа: для сервисов REST гипермедиа помогает интерфейсам быть более независимыми от конечных точек.
5. Паттерны Фасад и Адаптер: вариации этих шаблонов GoF в микросервисных архитектурах могут предполагать наличие внутренних компонентов или даже сервисов, которые предотвращают нежелательное связывание в реализации микросервиса.
6. База данных на каждый микросервис: микросервисы не только получают автономию, но и избегают прямого подключения к общим базам данных.
Окончание следует…
Источник: https://www.infoq.com/articles/microservices-design-ideals/
День шестьсот сорок второй. #BestPractices #IDEALS
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 7/7
S - Единственная ответственность (Single Responsibility)
Исходный принцип единственной ответственности (SRP) - это согласованная функциональность в объектно-ориентированном классе. Наличие нескольких обязанностей в классе, естественно, влечёт тесную связанность и приводит к хрупким проектам, которые трудно развивать и которые могут неожиданно сломаться при внесении изменений. Идея проста, но, как заметил дядя Боб, SRP очень легко понять, но трудно правильно реализовать.
Понятие единственной ответственности может быть распространено на связанность сервисов. Архитектура микросервисов предполагает, что блок развёртывания должен содержать только один сервис или несколько связанных сервисов. Если микросервис наполнен обязанностями, то есть содержит слишком много не совсем связанных между собой сервисов, он может страдать от проблем монолита. Раздутый микросервис становится всё труднее развивать с точки зрения функциональности и технологического стека. Кроме того, непрерывная доставка становится обременительной, поскольку многие разработчики работают над несколькими меняющимися частями, входящими в одну единицу развёртывания.
С другой стороны, если микросервисы слишком специфичны, более вероятно, что многим из них потребуется взаимодействовать для выполнения запроса пользователя. В худшем случае изменения данных могут быть распределены по разным микросервисам, что может создать сценарий распределённой транзакции.
Правильный размер микросервисов
Важным аспектом зрелости в дизайне микросервисов является способность создавать микросервисы, которые не являются слишком большими или слишком мелкими. Выход здесь не в каком-либо инструменте или технологии, а скорее в правильном моделировании предметной области. Моделирование серверных сервисов и определение границ микросервисов для них можно выполнить разными способами. Подход, который стал популярным в отрасли для определения размера микросервисов, заключается в следовании принципам Предметно-Ориентированной Разработки (DDD):
1. Сервис (например, REST) может иметь размер агрегата DDD.
2. Микросервис может иметь размер ограниченного контекста DDD. Сервисы в этом микросервисе будут соответствовать агрегатам в этом ограниченном контексте.
3. Для взаимодействия между микросервисами мы можем использовать:
- события домена, когда асинхронный обмен сообщениями соответствует требованиям;
- вызовы API с использованием некоторой формы уровня защиты от повреждений, когда более подходит формат запрос-ответ;
- репликацию данных с поддержкой согласованности, когда микросервису требуется значительный объём данных из других доступных ограниченных контекстов.
Источник: https://www.infoq.com/articles/microservices-design-ideals/
Принципы Разработки Микросервисов: IDEALS вместо SOLID. 7/7
S - Единственная ответственность (Single Responsibility)
Исходный принцип единственной ответственности (SRP) - это согласованная функциональность в объектно-ориентированном классе. Наличие нескольких обязанностей в классе, естественно, влечёт тесную связанность и приводит к хрупким проектам, которые трудно развивать и которые могут неожиданно сломаться при внесении изменений. Идея проста, но, как заметил дядя Боб, SRP очень легко понять, но трудно правильно реализовать.
Понятие единственной ответственности может быть распространено на связанность сервисов. Архитектура микросервисов предполагает, что блок развёртывания должен содержать только один сервис или несколько связанных сервисов. Если микросервис наполнен обязанностями, то есть содержит слишком много не совсем связанных между собой сервисов, он может страдать от проблем монолита. Раздутый микросервис становится всё труднее развивать с точки зрения функциональности и технологического стека. Кроме того, непрерывная доставка становится обременительной, поскольку многие разработчики работают над несколькими меняющимися частями, входящими в одну единицу развёртывания.
С другой стороны, если микросервисы слишком специфичны, более вероятно, что многим из них потребуется взаимодействовать для выполнения запроса пользователя. В худшем случае изменения данных могут быть распределены по разным микросервисам, что может создать сценарий распределённой транзакции.
Правильный размер микросервисов
Важным аспектом зрелости в дизайне микросервисов является способность создавать микросервисы, которые не являются слишком большими или слишком мелкими. Выход здесь не в каком-либо инструменте или технологии, а скорее в правильном моделировании предметной области. Моделирование серверных сервисов и определение границ микросервисов для них можно выполнить разными способами. Подход, который стал популярным в отрасли для определения размера микросервисов, заключается в следовании принципам Предметно-Ориентированной Разработки (DDD):
1. Сервис (например, REST) может иметь размер агрегата DDD.
2. Микросервис может иметь размер ограниченного контекста DDD. Сервисы в этом микросервисе будут соответствовать агрегатам в этом ограниченном контексте.
3. Для взаимодействия между микросервисами мы можем использовать:
- события домена, когда асинхронный обмен сообщениями соответствует требованиям;
- вызовы API с использованием некоторой формы уровня защиты от повреждений, когда более подходит формат запрос-ответ;
- репликацию данных с поддержкой согласованности, когда микросервису требуется значительный объём данных из других доступных ограниченных контекстов.
Источник: https://www.infoq.com/articles/microservices-design-ideals/