Использование нового поколения микросервисных архитектур

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

В последние годы термин "микросервис" стал популярным в программной архитектуре, а также представляет собой большое понятие. Разные люди по-разному его понимают. Даже в ранней микросервисной архитектуре появилась группа продуктов микросервисной архитектуры. Внедрить простотуSpring Boot,Spring CloudСервисы приложений, такие как фреймворки, также называются микросервисными архитектурами, но это всего лишь сервис.WebПросто контейнер.

С ростом популярности микросервисов все больше и больше команд начинают практиковать, а микросервисы внедряются и запускаются в производство. Однако по мере того, как масштабы микросервисов продолжают расти, каждый дополнительный микросервис может добавлять некоторую зависимую инфраструктуру и сторонние конфигурации, такие какKafka,Redisпримеры и т.д., соответствующиеCI/CDКонфигурация также будет увеличена или скорректирована. В то же время с увеличением количества микросервисов, ростом сложности бизнеса и разнообразием требований (например, стыковка со сторонними разнородными системами и т. д.) связь между сервисами усложняется, и микросервисы раздуваться шаг за шагом.Управление услугами также сложнее, и эти проблемы легко решить в монолитной архитектуре. По этой причине некоторые люди начали сомневаться в разумности выбора микросервисов и даже подумывали о возвращении к традиционным монолитным приложениям.

Как показано на рисунке ниже,PPTМикросервисы в Китае всегда хороши, но на самом деле микросервисы — это бардак, если вы хотите избавиться от них, чем больше вы на них смотрите, тем хуже вам становится. Неужели нет пути?

1. Проблемы, с которыми сталкивается традиционная микросервисная архитектура

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

• Слишком привязан к конкретному стеку технологий.При столкновении с гетерогенными системами требуется много усилий для преобразования кода, и разные гетерогенные системы могут подвергаться различным преобразованиям.
• Уровень проникновения кода слишком высок.Разработчикам часто приходится тратить много энергии на размышления о том, как взаимодействовать с фреймворком илиSDKКомбинация и более глубокая интеграция в бизнес — это сложный процесс обучения для большинства разработчиков.
• Многоязычная поддержка ограничена.Микросервисы выступают за то, чтобы различные компоненты можно было разрабатывать с использованием наиболее подходящего для них языка, но традиционные микросервисные фреймворки, такие какSpring CloudявляетсяJavaВ мире многоязычная поддержка очень затруднена. Это также приводит к беспомощности перед стыковкой разнородных систем или выбором следующего лучшего решения.
• Старые системы трудно поддерживать.Столкнувшись со старой системой, трудно добиться унифицированного обслуживания, управления, мониторинга и т. д. В переходный период часто требуется несколько команд для управления ими по отдельности, что усложняет обслуживание.

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

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

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

1.1 Ступень сопряжения

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

Хотя это решение легко реализовать, оно имеет определенные недостатки с точки зрения дизайна.

• Инфраструктурные функции (такие как обнаружение сервисов, балансировка нагрузки, автоматический выключатель и т. д.) тесно связаны с бизнес-логикой.
• Каждый микросервис повторяет код, реализующий одну и ту же функциональность.
• Управление сложное. Если баланс нагрузки службы изменяется, все связанные службы, вызывающие ее, должны обновить изменения.
• Разработчики не могут сосредоточиться только на разработке бизнес-логики.

1.2 SDK публичной библиотеки

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

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

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

1.3 Режим коляски

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

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

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

• Регистрация службы.Помогите службе зарегистрироваться в соответствующем реестре служб и выполните соответствующие проверки работоспособности службы.
• Сервисная маршрутизация.Когда служба приложения вызывает другие службы,SidecarЭто может помочь найти соответствующий адрес службы из обнаружения службы и выполнить функцию маршрутизации службы.
• Управление услугами. SidecarОн может полностью перехватывать входящий и исходящий трафик службы и выполнять соответствующие операции, такие как отслеживание цепочки вызовов, прерывание цепи, переход на более раннюю версию, мониторинг журнала и т. д., а также фокусировать функцию управления службой наSidecarреализовано в.
• Централизованное управление.Все сервисы в рамках всей системы микросервисной архитектуры могут проходить черезSidecarДля осуществления централизованного управления и контроля, полного управления потоком услуг, в автономном режиме и так далее.

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

1.4 Service Mesh

ПучокSidecarШаблон полностью применяется к огромной системе микросервисной архитектуры, развертывая по одному для каждой службы приложения.SidecarАгент завершает сложную связь между службами и, наконец, получает топологию сети, как показано на рисунке ниже, т.е.Service Mesh, также известный как «сервисная сетка».

К настоящему моменту появилось новое поколение микросервисной архитектуры.Service Mesh, что полностью решает проблемы, с которыми сталкиваются традиционные микросервисные архитектуры.