Резюме

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

Микросервисное подразделение

анализ проблемы

В предыдущей статье мы в начале представили стандарт сервисного подразделения.

Правило «Один домен — одна услуга»разделять,

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

в то же времяПродолжать расширяться, мы резервируем микросервис в качестве сервисного инкубатора. Для тех, у кого неясные поля (например, для большинства новых предприятий), они инкубируются в этой услуге, а затем разделяются, когда поле становится достаточно большим.

Некоторые типичные проблемы становятся более заметными после практики

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

Зависимость от сервиса слишком серьезна Неважно какие потребности написаны, нужно написать несколько приложений, один сервис домена, если на переднем плане ПК, то его нужно разрабатывать на сервисе ПК, а мобильный терминал нужно отображать и развивать в мобильном услуга. Вызовы между службами должны писать клиентский интерфейс rpc и должны выпускать версию, потому что одновременно разрабатывается много людей, часто возникает путаница версий и проблемы с зависимостями. Выход в интернет тоже головная боль: чтобы изменить небольшое требование, нужно развернуть несколько сервисов. Очень важным моментом микросервисов является разделение и независимое развертывание. Очевидно, что дополнительный уровень пользовательского интерфейса в качестве микросервиса не подходит.

Проблема деления поля Один домен и одна служба, степень детализации слишком мала, и некоторые вещи не знают, какую службу вставить, например, любимый блог пользователя, поместить ли его в пользовательскую службу или в поле блога.

Три более важные проблемы отражают общую проблему, которая

Границы услуг не ясны

Границы микросервисов не ясны, причина должна быть в том, что стандартное определение недостаточно точно
Больше зависимостей между сервисами

Важной особенностью микросервисов является автономия, если зависимых сервисов больше, то мы не можем пользоваться преимуществами микросервисов, а можем только плохо себя чувствовать микросервисы.

Решение

Чтобы решить вышеуказанные проблемы, мы обдумали наши критерии классификации и провели углубленные обсуждения в группе. Все согласны с тем, что для реализации DDD мы преждевременно провели крупномасштабное разделение микросервисов без глубокого обдумывания. вызвал много проблем. Хотя это было оптимальным решением в обстоятельствах того времени, проблемы, которые оно создавало, также были очень заметными.Когда лучше всего разделить микросервисы?? Поскольку теоретическое обучение и познание не имеют конца, только практика может дать истинное знание. Вместо того, чтобы зацикливаться на прошлых ошибках, мы перечитываем теорию DDD. На этот раз у меня была другая идея.

В DDD есть стратегический дизайн,Разделите домен, найдите ограниченный контекст, определите основной домен. Тогда есть тактический дизайн, моделирующий домен, Совокупные корни, объекты, объекты стоимости, доменные услуги, мероприятия домена и т. Д. Стратегический дизайн обычно является направляющей идеологией, а тактический дизайн - это специфическая игра. Мы изначально предположили, что Сначала есть руководящая идеология, а затем есть определенная игра. Теперь мы обнаруживаем, что мы ошибаемся, руководящая идеология не достигается в одночасье, и не неизменна. Когда вначале нет стандарта, он должен прийти из реальной игры. В то же время необходимо постоянно обобщать, пересмотреть и улучшить направляющую идеологию в процессе практики.

Так что мы снова расчесываем наш общий бизнес

Функция стойки регистрации

Разбираем фронтальные функции всех наших терминалов и рисуем картинку

Панорама деловой архитектуры

В соответствии с внешними функциями, дальнейшая организация и абстрагирование панорамы бизнес-архитектуры.

вырезать контекст

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

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

Новый стандарт секционирования микросервисов

Мы предлагаем новый критерий разделения микросервисов

Определение критериев разграничения микросервисов по ограниченному контексту

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

Так как раньше мы брали микросервис в качестве полевого инкубатора, это было фактически отказом от общего познания бизнеса и размышлений о новых потребностях. Наш новый бизнес не является новым продуктом, все они Это все же решение для определенного вида бизнеса. Только брать средства не те. Поэтому нам нужно вникнуть в его природу и поместить в существующий контекст. Каждый контекст — это микросервис, соответствующий развитию Владельца, который отвечает за вещи в этой области. У каждого такого сервиса есть новый люк поля.

Пример

Возьмем, к примеру, электронную коммерцию, если это только начинающая компания, невозможно иметь такую же структуру, как у Alibaba, с сотнями услуг. Но проблему, решаемую в сфере электронной коммерции, можно абстрагировать.

ограниченный контекст

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

Отдел микросервисов

Извлекая микросервисы из ограниченного контекста, микросервис содержит несколько доменов.

Кроме того, мы отказались от предыдущего сервиса пользовательского интерфейса, а также на стойке регистрации на стойке регистрации все микросэтаменты, которые могут эффективно снижать службы зависимости напрямую. Только когда несколько областей объединены, мы пишем новую комбинацию услуг [UI] внутри

Кроме того, ограниченный контекст не является постоянным слоем.Например, товарный маркетинг представляет собой поле.Когда бизнес простой, корреляция с товаром относительно велика, и он помещается в товарную область. Когда вам нужно делать маркетинг для магазина и пользователей одновременно, очевидно, что он не должен быть в контексте товара, поэтому его можно выделить как независимый ограниченный контекст: маркетинговый контекст.

Связанное Чтение

Landable DDD(1) - Обсуждение цели

Landable DDD (2) — почему инженерная архитектура MVC устарела

Landable DDD (3) — Как использовать DDD для разделения микросервисов

Обратите внимание на [Храм аббата], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом.