Разбиение на сервисы¶

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

• Разбиение по бизнес-возможностям
• Разбиение по поддоменам

Методические рекомедации по декомпозиции.¶

При работе с микросервисами важно помнить также о двух приципах из объектно-ориентированного проектирования.

• принцип единственной ответственности
  Если применить SRP к микросервисной архитектуре, каждый сервис получится небольшим, согласованным и с одной обязанностью (и, как следствие, с одной причиной для изменения)
• принцип согласованного изменения
  CCP можно применить при разработке микросервисной архитектуры, объединяя компоненты, изменяющиеся по одной причине, в единый сервис. Это позволит минимизировать количество сервисов, которые нужно изменить при изменении какого-нибудь требования. В идеале такое изменение должно затронуть только одну команду и один сервис. CCP — противоядие от антишаблона распределенного монолита.

Трудности и проблемы при разбиении на сервисы¶

• Латентность сети. Иногда при разбиении обнаруживается, что некоторые сервисы вынуждены часто обмениваться данными, что снижает общую производительность. Иногда может помочь реализация пакетного API, позволяющего получать несколько объектов за один запрос. В тяжёлом случае придётся объединять разные сервисы.
• Синхронное взаимодействие ухудшает доступность. Если один из сервисов в цепочке запросов окажется недоступным, это приведет к отказу всей цепочки. В зависимости от ситуации можно либо смириться с этим, либо использовать асинхронный обмен сообщениями.
• Обеспечение согласованности данных между сервисами. Так как в микросервисной архитектуре мы не можем использовать традиционную транзакционную модель, лучше применять шаблон “повествование”.
• Получение согласованного представления данных. Микросервисная архитектура не позволяет получить согласованное представление данных, несмотря на то, что БД каждого отдельного сервиса согласована.
• Божественные классы препятствуют декомпозиции. У большинства приложений есть по крайней мере один такой класс, представляющий центральную концепцию той или иной проблемной области. Можно упаковать такой класс в библиотеку и собирать сервисы с использованием этой библиотеки. Однако, это приведет к жесткому связыванию. Другой подход связан с инкапсуляцией класса в отдельный сервис, однако в таком случае может возникнуть ситуация, когда такой сервис имел бы слабую доменную модель с минимальным количеством логики или без нее. Куда более удачным решением будет применение принципов DDD, когда божественный класс разбивается на части в зависимости от поддомена.

Комментарии

Комментарии