Предыстория: международная компания с моделью федерации трансформируется в микросервисы из-за хронической монолитной боли. Крайне желательны автономные команды с быстрым развертыванием. Несмотря на теорию, сервисы действительно зависят друг от друга для более высокой функциональности, но они автономны (независимо разрабатываются и развертываются). Поскольку это федеративная модель и децентрализованное управление, мы не можем навязывать строгие правила — как в ООН. Без платформы управления, которая будет управлять зависимостями из-за множества версий, находящихся в производстве в разных странах, мы ожидаем неконтролируемый хаос.
Давайте назовем набор микросервисов, которые должны взаимодействовать, «набором совместимости». Службу можно развернуть, но она может не удовлетворять более высоким функциональным возможностям в своем наборе совместимости. Например, MicroService A-4.3 полностью автономен, развернут и отлично работает. Однако для соответствия требованиям BusinessFunctionality 8.6 он должен работать вместе с MicroService B-5.4 и MicroService C-2.9. Вместе (A-4.3, B-5.4 и C-2.9) они образуют «набор совместимости».
Есть два подхода к этой дилемме. Микросервис в реальной жизни, где резина отправляется в путь и начинается обучение на собственном опыте...
Подход 1) Платформа управления
Обоснование: Федеральная модель в международной компании в более чем 100 странах. Это означает, что Центральный ИТ может установить модель, но отдельные страны могут выбирать свою судьбу, и они часто так и делают. Это часто превращается в хаос, и центральная ИТ-команда оказывается на крючке. DDD — это решение для идеального мира, где несоответствия версий не нарушают функциональность, например, выпуск сервисов, которые не вписываются в набор совместимости, безупречны по отдельности, но вместе они разваливаются или приводят к ошибочной или несогласованной функциональности.
- Нет однородности, нет даже стандартизации терминологии
- Разработчики имеют смешанные навыки, многие из них являются младшими, и многие изучают реактивное программирование и облачные технологии.
- Ограниченный контекст сильно зависит от общего словарного запаса, и он может стать незаметным, но это невозможно обеспечить и наивно предположить в международном, смешанном, фрагментированном сценарии с несколькими работающими версиями.
- Стандартизация единой бизнес-модели нереалистична в такой разнородной системе (но идеальна).
Что делать центральному ИТ-отделу, когда они несут ответственность за этот хаос?
Внедрение платформы управления Создайте систему или структуру управления микросервисами, чтобы обеспечить управление зависимостями. Он проверяет и обеспечивает соблюдение зависимостей во время разработки и выполнения от конкретной микрослужбы через манифест и выполняет некоторые проверки и противовесы для проверки предлагаемых реализаций службы — «набор совместимости».
Подход 2. Проектирование, управляемое предметной областью (DDD). DDD предназначен для моделирования предметных областей, которые постоянно развиваются, при этом эксперты предметной области (обычно заинтересованные лица или, возможно, аналитики) будут работать вместе с разработчиками над проектированием системы. Внутри каждой области формируется вездесущий язык, так что в этом контексте одно и то же слово всегда означает одно и то же. Важно понимать, что в одной части вашей системы «Заказ» может означать одно, например, список продуктов. В другой части вашей системы «Заказ» может означать что-то другое, это может означать состоявшуюся финансовую транзакцию. Именно здесь модель, которую вы описываете, может упасть, если моей службе нужно получить список заказов, возможно, есть возможность, которая предоставляет список заказов, но какие это заказы? Список продуктов или финансовая операция? Попытка скоординировать как можно больше разработчиков, чтобы все они использовали один и тот же язык, — невыполнимая задача, которая обречена на провал.
В DDD вместо того, чтобы пытаться управлять этим на системном уровне и заставлять каждую службу использовать одно и то же определение Order, DDD учитывает сложность, присущую координации очень больших развертываний с участием огромного количества разработчиков, и позволяет каждой команде работать независимо. координация с другими командами по мере необходимости, а не через какую-то централизованную систему управления зависимостями. Термин, используемый в DDD, относится к ограниченным контекстам, где в одном контексте порядок означает одно, а в другом ограниченном контексте порядок может означать другое. Эти контексты могут функционировать действительно автономно — вы описываете свои службы как автономные, но если они должны соответствовать своему определению порядка со всей системой путем регистрации и предоставления зависимостей центральному реестру, то на самом деле они тесно связаны с остальными компонентами. система и то, что она считает порядком — вы в конечном итоге получите всю болезненную связь монолита, всю боль построения распределенной системы, и вы не осознаете многих преимуществ микросервисов, если попытаетесь принять это. подход.
Таким образом, подход, основанный на DDD, никогда не пытается применить жесткий подход к обеспечению зависимостей или возможностей на системном уровне, скорее, он позволяет отдельным командам работать без необходимости централизованной координации. команда, которая управляет сервисом A, будет работать с командой, которая управляет сервисом B, они могут построить интерфейс между своими ограниченными контекстами и прийти к соглашению о языке для этого интерфейса. Эти команды должны управлять своими зависимостями друг от друга, на системном уровне все может оставаться довольно непрозрачным/неосуществимым.
Слишком часто мы видим, как люди внедряют «микросервисы», но в итоге получают систему, которая такая же, если не более негибкая, а часто и более хрупкая, чем монолит. Микросервисы, также называемые «Minilith» или «Monolith 2.0», требуют полного переосмысления архитектуры и процессов разработки программного обеспечения, а также требуют не только обеспечения автономности и независимого управления сервисами, но и независимости команд, а не централизованного управления. Централизация управления зависимостями и возможностями в системе может помешать успешному построению системы на основе микросервисов.
Приглашаются интеллектуальные и практичные комментарии...
Подход 1 (управление) является прагматичным и тактическим и предназначен для решения очень реальных проблем. Вопрос в том, не подорвет ли это долгосрочную стратегическую модель DDD предприятия?
Подход 2 (DDD) идеален и оптимистичен, но он не решает очень реальных проблем, с которыми нам приходится сталкиваться прямо сейчас.
Мнения? Мысль? Комментарии?
