1. Введение
В начале «Романа о трех королевствах» говорилось: «Говоря об общем веянии мира, если он будет разделен на долгое время, то он будет объединен, а если он будет объединен на долгое время, он будет разделен. ...". На самом деле, большинство вещей имеют такие правила, и при проектировании программных систем они также будут подвергаться такой итеративной эволюции. Занимаясь проектированием и практикой микросервисной архитектуры более двух лет, автор столкнулся с разделением огромной единой системной архитектуры приложений на множество различных микросервисных приложений, а затем повторным объединением различных микросервисных приложений в среду, которую можно повторно использовать. цель состоит в том, чтобы лучше поддерживать развитие бизнеса и повысить эффективность и качество разработки программного обеспечения. В этой статье мы в основном хотим разобраться с некоторыми базовыми знаниями об архитектуре микросервисов, чтобы каждый мог получить всестороннее и систематическое представление об архитектуре микросервисов.
2. Монолитная архитектура и микросервисная архитектура
2.1 Определение архитектуры программного обеспечения
Архитектура программного обеспечения — это набор структур, необходимых для создания прикладной системы, включая программные элементы, отношения между элементами и их атрибуты. Как декомпозировать программные элементы и взаимосвязь между этими элементами становится очень важным. Хорошая архитектура программного обеспечения имеет две характеристики:
- Разумно распределять производственные отношения и производительность, чтобы люди с разными профессиональными знаниями и технологическими стеками могли участвовать в разработке программных систем и эффективно работать вместе;
- Он позволяет каждому программному элементу иметь четкие определения и обязанности, а также набор хороших и эффективных механизмов взаимодействия.
2.2 Монолитная архитектура приложения
Разработка приложений использует монолитную архитектуру, все коды управляются в репозитории кода и, наконец, упаковываются в пакет развертывания, который запускается в процессе. Существуют две типичные трехуровневые архитектуры приложений и шестиугольные архитектуры приложений.
На ранней стадии проекта монолитная архитектура действительно обеспечит беспрецедентное повышение эффективности разработки.Монолитная архитектура имеет следующие преимущества:
- Разработка приложения проста, в основном все коды хранятся на складе;
- Очень удобно вносить масштабные изменения;
- Легко протестировать, просто нужно написать несколько сквозных тестов;
- Развертывание простое, а горизонтальное масштабирование очень простое.
Однако с расширением бизнеса количество бизнес-модулей и объем кода будет резко увеличиваться, в это время постепенно выделяются недостатки монолитной архитектуры:
- Сложность продолжает расти, связь между модулями становится все выше и выше, а стоимость обслуживания высока;
- Цикл итерации обновления становится длиннее, а цикл от отправки кода до фактического развертывания удлиняется, и иногда он не может быть доставлен;
- Его сложно расширять и итеративно развивать, а модернизировать с использованием устаревших технологических стеков или компонентов невозможно.
2.3 Микросервисная архитектура
Прежде чем мы поговорим об архитектуре микросервисов, мы должны поговорить о классической теории куба масштабирования, которая определяет три различных способа масштабирования приложения:
- Масштабирование по оси X обеспечивает балансировку нагрузки запросов между несколькими идентичными экземплярами;
- Масштабирование по оси Y разбивает приложения на сервисы в зависимости от их функциональности;
- Расширение оси Z направляет запросы на основе запрошенных атрибутов.
На самом деле микросервисную архитектуру можно понимать как расширение «модульного дизайна», но эти «функциональные модули» работают в своих собственных процессах в виде отдельных пакетов развертывания. Таким образом, каждая служба независима друг от друга и имеет свою собственную базу данных, и они могут взаимодействовать друг с другом только через API.
Эволюция от монолитной к микросервисной архитектуре также дает следующие преимущества:
- С точки зрения управления кодом каждая служба относительно невелика, и большинство из них состоит из более чем дюжины интерфейсов или методов службы, которые очень легко поддерживать;
- С точки зрения управления эксплуатацией и обслуживанием каждую услугу можно развертывать независимо, что очень легко расширяется;
- С точки зрения управления командой можно лучше разделить сферу ответственности;
- С общей точки зрения разработки программного обеспечения программная система может непрерывно поставляться и развертываться.
Аналогичным образом, архитектура микросервисов имеет следующие недостатки:
- Трудно разделить и определить услуги;
- Увеличивает сложность системы, усложняя разработку, тестирование и развертывание;
- При развертывании функций для нескольких сервисов необходимо координировать команду разработчиков.
3. Определение и состав микросервисной архитектуры
Модель принятия решений, которую необходимо учитывать в архитектуре микрослужб, состоит из нескольких шаблонов. На уровне его можно условно разделить на три уровня: относящийся к приложениям, относящийся к приложениям и относящийся к инфраструктуре.
- Шаблоны, связанные с приложением: разделение сервисов, архитектура базы данных, поддержание согласованности данных, связанные с тестированием;
- Применение шаблонов, связанных с инфраструктурой: проблемы с границами, безопасность, обмен транзакционными сообщениями, стили общения, надежность, возможность мониторинга;
- Шаблоны, связанные с инфраструктурой: развертывание приложений/служб, обнаружение служб и т. д.
3.1 Разделение услуг
На самом деле сложно разложить исходную монолитную систему приложений на ряд сервисов, поэтому можно следовать двум следующим стратегиям разложения:
- Декомпозируется по бизнес-возможностям
- Разбить по субдоменам
3.2 Способ связи
Приложение, использующее микросервисную архитектуру, представляет собой распределенную систему, важной частью которой является межпроцессное взаимодействие.Существуют следующие режимы взаимодействия:
- Стиль общения: какой механизм межпроцессного взаимодействия используется;
- Обнаружение службы: как клиент получает реальный IP-адрес конкретного экземпляра;
- Надежность: как обеспечить надежную связь между службами в случае недоступности службы;
- Транзакционные сообщения: как интегрировать транзакции базы данных для отправки сообщений, публикации событий и обновления бизнес-данных;
- Внешний API: как клиенты приложений взаимодействуют со службой.
3.3 Режим согласованности данных
В микросервисной архитектуре каждый сервис имеет свою независимую базу данных Механизм транзакций 2PC в архитектуре одного приложения больше не применим в микросервисной архитектуре Для обеспечения согласованности данных требуется промежуточное ПО, аналогичное распределенным транзакциям.
3.4 Наблюдаемость
В микросервисной архитектуре запрос часто проходит через несколько экземпляров службы, а проблемы с производительностью, связанные с приложениями, такие как высокая задержка, трудно наблюдать и решать.Для разработки набора отслеживаемых служб требуются следующие шаблоны:
- API проверки работоспособности. Каждому приложению микрослужбы требуется API, который может возвращать состояние работоспособности.
- Агрегация журналов: запись всех журналов серверных узлов на централизованный сервер журналов, на котором можно выполнять поиск журналов и выдавать аварийные сигналы на основе условий журналов.Типичное решение — путь к журналу + контейнер + ES;
- Отслеживание распределенных ссылок: присваивайте уникальный идентификатор каждому внешнему запросу для отслеживания внешних запросов между сервисами, newlic/skywalking;
- Метрики приложения: сохраняйте используемые метрики, такие как количество вызовов;
- Журнал аудита: запись поведения пользователя;
3.5 Шаблоны, связанные с развертыванием
Развертывание монолитного приложения — относительно интуитивно понятная операция, но развертывание приложения на основе микросервисов гораздо сложнее и обычно состоит из десятков или даже сотен сервисов. Традиционный метод развертывания приложений, основанный на ручном копировании на сервер, больше не подходит для микросервисной архитектуры, и требуется высокоавтоматизированная инфраструктура развертывания, такая как платформа развертывания, которая может управлять задачами по запросу, изменениями кода и средой ресурсов сервера.
3.6 Безопасность
В микросервисной архитектуре работа по проверке личности пользователя и разрешений обычно выполняется шлюзом.Распространенным решением является режим токена доступа протокола Outh2.Шлюз передает токен доступа сервису, проверяет токен и получает данные о пользователе. связанная информация информация.
3.7 Тесты
Метод и направленность тестирования монолитной архитектуры отличаются от таковых для микросервисной архитектуры.По мере уменьшения детализации сервисов архитектура микросервисов упрощает тестирование.Фокус состоит в том, чтобы проверить, работают ли разные сервисы вместе, используя сложные и медленные тесты. несколько сервисов с ненадежными сквозными тестами, следующие шаблоны могут упростить рабочую нагрузку тестирования и повысить эффективность тестирования за счет индивидуального тестирования сервисов:
- Тестирование, ориентированное на потребителя: убедитесь, что сервис соответствует функциональным возможностям, ожидаемым клиентом;
- Тест контракта на стороне потребителя: убедитесь, что клиент службы может нормально взаимодействовать со службой;
- Тестирование сервисных компонентов: тестирование сервисов в изолированной среде.
3.8 Соответствующие модели инфраструктуры и вопросы границ
В микросервисной архитектуре каждый сервис должен реализовывать множество функций, связанных с инфраструктурой, таких как режим наблюдения, режим обнаружения сервисов, режим внешней конфигурации и т. д. Необходимо разработать инфраструктурную базу для микросервисной архитектуры, чтобы при разработке новый микросервисный бизнес, вы можете быстро получить доступ и развиваться на базе.
4. Разделение услуг
В то время вся серверная система также столкнулась с проблемой «единого ада», поэтому было решено разделить ее на несколько доменных микросервисов, чтобы облегчить ряд проблем при разработке/развертывании, в основном следуя следующим стратегиям и рекомендациям по разделению.
4.1 Стратегия разделения
Все отправные точки - это бизнес. Сначала мы должны разобраться с функциональными требованиями или пользовательскими историями для определения системных операций, а затем преобразовать системные операции в полные запросы. В соответствии с запросом мы можем изначально определить конкретные обязанности и границы сервиса, а затем переопределить интерфейс и взаимодействие между службами.
Существует две основы для разделения услуг: одна заключается в агрегировании границ возможностей и ответственности от бизнес-возможностей до услуг, а другая — в разделении услуг в соответствии с поддоменами в структуре домена DDD.
4.4 Рекомендации по разделению
- Единая ответственность (SRP): изначально относится к каждому классу, несущему только одну ответственность, в архитектуре микрослужб это означает, что каждая микрослужба должна быть как можно меньше, сплоченной и может независимо выполнять бизнес-поддержку с обратной связью.
- Принцип закрытия (CPP): определение состоит в том, что все классы в пакете должны быть набором изменений одного типа.Если пакет изменен, все классы, которые необходимо обновить, должны быть в этом пакете.В микросервисной архитектуре , это относится к Когда требования меняются, объем компонентов службы, которые необходимо изменить, можно контролировать. Лучше всего быть службой, и лучше всего выполнять ее в команде разработчиков.
4.5. Трудности разделения монолитных сервисов приложений
- Сетевая задержка, после того, как запрос будет перенаправлен через уровни службы, канал связи увеличится в N раз, естественно, связь будет задержана;
- Межпроцессное взаимодействие приводит к снижению доступности, а трафик сети, в которой находится микросервисный кластер, увеличится, даже в локальной сети доступность будет снижена из-за сетевого джиттера или точек доступа;
- Чтобы поддерживать согласованность данных между службами и получать согласованное представление данных, трудно реализовать транзакции разных экземпляров базы данных.
5. Связь между процессами
5.1 Способ общения
- Один к одному: каждый запрос клиента обрабатывается одним экземпляром службы;
- Один ко многим: каждый запрос клиента обрабатывается несколькими экземплярами службы;
- Синхронный режим: клиентские запросы требуют ответа от сервера в реальном времени, и клиент может заблокироваться в ожидании времени ответа;
- Асинхронный режим: клиентские запросы не будут блокировать процесс, а ответы сервера могут быть не в реальном времени;
5.2 Связь на основе шаблона синхронного удаленного вызова процедур
Принцип работы удаленного вызова процедур заключается в том, что бизнес-логика в клиенте вызывает прокси-интерфейс, который реализуется классом адаптации прокси-сервера удаленного вызова процедур, а прокси-сервер вызова отправляет запрос в службу, которая обрабатывается удаленным Класс адаптации сервера вызова процедур.Класс вызывает бизнес-логику службы через интерфейс, а затем отправляет ответ обратно прокси-серверу вызова процедур, который возвращает результат бизнес-логике клиента.
В течение всего процесса удаленного вызова клиентский запрос может не выполниться из-за тайм-аута сети, превышения сервером количества обработанных запросов и т. д. Для решения этих проблем и обеспечения высокой доступности сервиса можно использовать компонент hystrix. в зависимости от режима автоматического выключателя он относится к типу «Обучение позже», чтобы реализовать обнаружение службы, в основном существует два режима обнаружения: служба приложения и служба платформы.
- Режим обнаружения клиента: экземпляры службы используют реестр службы для регистрации своих сетевых расположений, а клиент получает список доступных экземпляров службы из реестра и выполняет балансировку нагрузки между ними;
- Режим обнаружения службы уровня платформы: многие контейнеры развертывания, такие как Docker и Kubernetes, имеют встроенный реестр служб и механизм обнаружения служб.Платформа развертывания предоставляет DNS-имя, виртуальный IP-адрес и DNS-имя для каждой службы.Имя и виртуальный IP-адрес делают запрос , и платформа развертывания автоматически направляет его в один из доступных экземпляров службы.
5.3 Связь на основе шаблона асинхронных сообщений
При использовании механизма сообщений связь между службами осуществляется путем асинхронного обмена сообщениями. Бизнес-логика отправителя вызывает интерфейс отправки, который инкапсулирует базовый механизм связи, а отправляющая сторона реализуется классом адаптера отправки информации, который отправляет сообщения получателю через канал сообщений. Класс адаптера обработчика сообщений в приемнике вызывается для обработки сообщения. Он вызывает интерфейс получателя, реализованный бизнес-логикой получателя. Любое количество отправителей может отправлять сообщения в канал сообщений, и аналогично любое количество получателей может получать сообщения из канала сообщений.
6. Резюме
Эта статья в основном представляет собой систематическое введение в архитектуру микросервисов, сравнение преимуществ и недостатков архитектуры монолитных приложений и архитектуры микросервисов, а также акцентирование внимания на аспектах, которые необходимо учитывать при проектировании архитектуры микросервисов, таких как разделение служб, режим связи, наблюдаемость, безопасность, связанные с развертыванием и другие связанные режимы, и, наконец, кратко опишите принципы работы двух основных режимов межпроцессного взаимодействия, стратегию и руководящие принципы разделения службы, удаленного вызова процедур и взаимодействия сообщений.
использованная литература
- «Шаблоны проектирования микросервисной архитектуры»
-----------------------------------------------------------------------------------------
Спасибо за Ваше внимание! Публичный аккаунт WeChat (цвет кода).