Обучение дизайну микросервисов (1) О микросервисах и моделировании сервисов

предисловие

С широкомасштабным доступом к Интернету в начале 21 века Интернет превратился из бизнес-модели Web 1.0, основанной на одностороннем выпуске информации на основе кликов по трафику и прибыли, в бизнес-модель Web 2.0, в которой доминируют пользователи и создание контента. Таким образом, объем доступа и данных, которые необходимо обработать системе интернет-приложений, быстро растет, и внутренняя техническая архитектура также сталкивается с огромными проблемами.

Большинство серверных архитектур Интернета на этапе Web 2.0 прошли через процесс постепенного перехода от архитектуры монолитных приложений «Все в одном» к более гибкой распределенной архитектуре приложений, а архитектура разработки Интернета начала стремиться к более высокому качеству и эффективность.

С появлением смартфонов и популяризацией стандартов 4G интернет-приложения быстро переместились с ПК на более бесплатные мобильные устройства. Мобильные устройства полностью изменили образ жизни современных людей в плане путешествий, онлайн-покупок и платежей благодаря удобству ношения и позиционирования. С точки зрения технологии, чтобы справиться с большим масштабом кластера, чисто распределенную систему было трудно контролировать.Таким образом, технологический круг открыл эру концептуального взрыва — SOA, DevOps, контейнеры, CI/CD, микросервисы, Service Mesh и другие концепции появляются бесконечным потоком, а ряд продуктов, таких как Docker, Kubernetes, Mesos, Spring Появились Cloud, gRPC и Istio, ознаменовав приход облачной эры.

Эта статья (или эта серия статей) — это то, что я сделал после прочтения книги Сэма Ньюмана «Проектирование микросервисов», связанной с другими статьями, связанными с проектированием микросервисов, «От службы к облаку» и другими книгами.

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

Надеюсь, это поможет вам при закреплении учебы.

1. О микросервисах

1.1 Что такое микросервисы

Микросервисы — это небольшие автономные сервисы, которые работают вместе.

Ключевые слова: маленький и автономный

"маленький"

Понятие «маленький» отражается в сплоченности микросервисов с одной стороны.

Сплоченность также можно назвать принципом единой ответственности:Объединяйте вещи, которые меняются по одной и той же причине, и разделяйте вещи, которые меняются по разным причинам."
Тем не менее, микросервисы должны сосредоточиться на выполнении одной задачи.
Граница услуги определяется границей бизнеса

С другой стороны, это отражается на размере кодовой базы Вот несколько справочных стандартов или принципов.

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

автономия

Концепция «автономии» подчеркивает, что микросервис — это независимая сущность. Это отражается в слабой связи между службами.

Золотое правило: можно ли изменить один сервис и развернуть его, не затрагивая другие сервисы?

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

1.2 Преимущества микросервисов

Большинство преимуществ микросервисов относятся к архитектурам распределенных систем, но микросервисы доводят эти преимущества до предела.

технологическая неоднородность
- Различные сервисы используют разные технические архитектуры в соответствии с бизнес-сценариями, требованиями к производительности и функциональными требованиями.
- Быстрая практика новых технологий и быстрый рост технических команд
Устойчивость / антихрупкость
- понижение уровня обслуживания
- Служба аварийного восстановления, сервисный предохранитель
расширять
- Традиционные монолитные системы не могут расширять локальные функции.
- Масштабирование определенных микросервисов в зависимости от конкретных потребностей бизнеса
- Экономия средств за счет архитектуры
Упрощенное развертывание
- Традиционные монолитные приложения, даже если изменена одна строка кода, необходимо повторно развернуть целиком. Слишком большой риск.
- Микросервисная архитектура, развертывание каждого сервиса независимо друг от друга
  - Гибкие методы публикации
  - быстрый откат
  - низкий риск
Архитектура соответствует организационной структуре
- Связанные знания: Закон Конвея
Многоразовые и компонуемые сервисы
Взаимозаменяемость сервисов, быстрая перезапись

1.3 Сервис-ориентированная архитектура

SOA (сервисно-ориентированная архитектура, сервис-ориентированная архитектура) — это метод проектирования, который включает в себя несколько сервисов, и сервисы в конечном итоге будут обеспечивать ряд функций посредством сотрудничества. Служба обычно существует как отдельная форма в процессе операционной системы. Службы взаимодействуют через сетевые вызовы, а не внутрипроцессные вызовы.

Точно так же, как думать о XP или Scrum как об особом методе гибкой разработки программного обеспечения.Микросервисная архитектура — это особый подход к SOA..

Проблемы, возникающие при внедрении SOA:

Протокол связи (SOAP или REST)
Выбор стороннего промежуточного ПО
Отдел детализации обслуживания
......

Мышление и резюме

У микросервисов действительно есть много преимуществ: «анти-хрупкость», отказоустойчивость, независимое развертывание и масштабирование, архитектурная абстракция, техническая изоляция. Но это не означает, что внедрение микросервисов происходит само собой с этими функциями.

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

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

Теоретически микросервисы могут увеличить скорость разработки, но при создании организационных зависимостей "Microservice Premium" может замедлить скорость разработки.

Таким образом, для внедрения микросервисной архитектуры требуется несколько предварительных условий, в том числе надлежащий конвейер непрерывного выпуска, компетентные команды DevOps и Ops, разумные границы обслуживания и многое другое. Кроме того, важны тщательное тестирование и шаблоны интеграции.

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

Я думаю, именно поэтому существует общая тенденция перехода от сервис-ориентированного к облачному, потому что только путем объединения облачной платформы «контейнер + оркестрация и планирование» микросервисы могут максимизировать свои преимущества. Что касается знаний об облаке, то это следующий контент.

Расширенное чтение статьи Мартина Фаулера

Комиссия микросервисаWoohoo.Martin Fowler.com/B далеко от i/micro…

2. Как смоделировать услугу

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

2.1 Несколько концепций

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

Здесь автор цитирует концепции из книги Эрика Эванса «Дизайн, управляемый доменом» (настоятельно рекомендуется к прочтению):ограниченный контекст.

Любой заданный домен содержит несколько ограниченных контекстов, и материал в каждом ограниченном контексте (Эрик чаще использует слово «модель», что должно быть намного лучше, чем «материал») разделен на две части, одна из которых не нуждается в общении с внешним миром. мир, другая часть требуется. Каждый контекст имеет явный интерфейс, определяющий, какие модели он предоставляет другим контекстам. Используя клетки в качестве аналогии:«Клетки существуют, потому что клеточная мембрана определяет, что находится внутри клетки, что снаружи клетки, и определяет, что может пройти через клеточную мембрану».

Общие и скрытые модели

В то же время упоминается понятие разделяемой модели и скрытой модели.

Общая модель — это модель взаимодействия между контекстами в приведенной выше метафоре, а скрытая модель — это модель, которой не нужно взаимодействовать с внешним миром.

О том, как запускать микросервисы, точка зрения автора в книге и Мартина Фаулера, который тоже в TW, есть точка зрения:"MonolithFirst"- Монолитное приложение в первую очередь.

В основном из следующих соображений:

Yagni Принципы. Лучший способ определить, полезна ли идея программного обеспечения, — это создать упрощенную версию и посмотреть, как она работает. На данном этапе важнее всего скорость, и этот принцип позволяет сократить цикл обратной связи и избежать комиссий микросервиса.
четкоКоллекция ограниченного контекста- Микросервисы могут эффективно функционировать только при наличии хороших и стабильных границ для сервиса. Однако функциональный рефакторинг между любыми микрослужбами сложнее, чем в монолитной архитектуре.Даже опытные архитекторы в знакомой им области испытывают трудности с правильным определением границ с самого начала и созданием первого.Монолитное приложение упрощает четкие функциональные границы.

Расширенное чтениеWoohoo. Martin Fowler.com/B оставь i/mono впереди…

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

Я больше склоняюсь к этому методу, поэтому вычерпал и изучил этот метод.

2.2 Точки моделирования

Не разделяйте раньше времени

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

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

Размышляя об ограниченном контексте, вы должны начать с бизнес-функции, сначала спросить себя, «для чего нужен этот контекст», а затем подумать, «какие данные ему нужны».
пошаговый контекст

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

контекст верхнего уровня

Думать и подводить итоги

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

Эта часть может быть связана с книгами, посвященными изучению концепций DDD.