Архитектура микросервиса Cloudtop

Применять сцену

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

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

Описанные здесь сценарии применимы к предприятиям с высокими темпами развития бизнеса, многокомандным сотрудничеством, высоким спросом на устойчивость системы и эффективной доставкой.ZhiHua TechПредоставлять услуги по трансформации микросервисов от структурированного консультирования до внедрения импровизации, не представляя конкретные данные клиентов.

Типичные оперативные задачи

1. Узкие места в одноформенных структурах, связанные с эффективностью доставки

• Выпустить соединение:30 разработчики разделяют кодовый склад и потоковую линию CI/CD. Любая комбинация кодов может блокировать выпуск других. Срочные исправления для платежного бага, который должен ждать, пока не будет консолидировано предыдущее отставание в 5 MR и не будет завершено тестирование - эти MR не имеют ничего общего с платежным модулем.
• Испытательные взрывы.Регрессионный диапазон тестирования для одного приложения - это "полное приложение". Даже если SQL модифицирован только с одним интерфейсом запроса, для запуска полного сквозного пакета тестов требуется от 40 минут до 2 часов. Длина цикла обратной связи теста замедляет итеративную скорость.
• Технический замокВсе приложение привязано к технологическому складу (например, Java 8+ Spring), новому бизнес-сценарию, который больше подходит для Go или Node.js, но введение нового языка означает новую систему строительства, развертывания и мониторинга, и команды часто предпочитают «работать вместе».

2. Сложность, вызванная распределением

• Сеть ненадежна.Одно тело называется методом, а микросервисы связаны с сетью. Сети перегружены, разбиты, разделены — эти модели отказа, которые не существуют в одном теле, являются рутиной в структурах микросервисов. Без разумного тайм-аута, повторных испытаний и стратегий плавления услуга вибрирует как домино-домино.
• Согласованность данныхACID является основой для услуг с одним источником данных. В рамках микросервисов каждая услуга имеет свою собственную базу данных, и операции с кросс-сервисом (следующее = служба заказа + служба инвентаризации + платежная служба) должны полагаться на распределенные сервисные программы, такие как Saga или TCC, чтобы обеспечить окончательную согласованность. Этот сдвиг в мышлении - от «завершения бизнеса» до «компенсация может быть возможна на каждом шаге» - является самым трудным когнитивным порогом для команды, чтобы пересечь.
• Отладка и сдерживаниеКогда пользователь сообщает о «неудавшемся» «заказе», вам нужно столкнуться с полной цепочкой вызовов из журнала шлюза, журнала обслуживания заказов, журнала обслуживания инвентаря, журнала платежных услуг без распределенного отслеживания (например, Jaeger, SkyWalking), проблема позиционирования похожа на иглу.

3. Отсутствие инфраструктуры и мобильности

• Контейнеризация и организацияМикросервисы естественны для развертывания контейнеризации, но у самого Kubernetes есть крутая кривая обучения. Pod Network, Service Discovery, Ingress Route, ConfigMap, Secret Management, HPA Resilient sprawl - концепции, которые нулевые для традиционных команд.
• CI/CD сложностьОт линии потока до линии N (по одной для каждой услуги), зеркальная конструкция, толкание, развертывание, откат требует стандартизации. Без единого шаблона линии потока и управления продуктом фрагментация процесса доставки может быть вызвана отдельными командами.
• наблюдаемостьЗаготовка, индикаторы и отслеживание – три столпа являются одним.Под микросервисными структурами отсутствие какого-либо из столпов может привести к значительному снижению способности к выведению.

Программное проектирование мышления

1.Прогрессивный раскол вместо переписывания Большого взрыва

ZhiHua Tech настаивает на преобразовании микросервисаГанглер Фиг Паттерсон• Прогрессивное движение к функциональным модулям в новой архитектуре при сохранении нормального функционирования старой системы, которая сосуществует через слои маршрута до полной замены старой системы:

• Во-первых, мы удаляем модуль изменения HF.Приоритет отдается разделению наиболее часто используемых и независимых модулей бизнеса (например, центров пользователей, товарных центров). После их демонтажа они получают дивиденды от независимого развертывания — изменения больше не ограничиваются темпами выпуска других модулей.
• API Gateway Unified Entry (недоступная ссылка)Шлюз отвечает за распределение маршрута, аутентификацию клиренса, ограничение потока и лог-логи.Запрос на переадресацию шлюза в соответствующий моно- или микросервис путем префиксирования пути, без ощущения передней части.
• База данных разделенаКаждый отдельный микросервис имеет независимую базу данных, Schema (даже пример автономной базы данных), которая в конечном итоге согласуется с единой базой данных путем синхронизации данных или вызова API. Демонтаж поэтапно снижает риск, используя стратегию «Dub-Book + Top-Top-Read».

2.Управление связью с сетями услуг

Когда количество микросервисов превышает 10, традиционное управление сервисами SDK (SDK для каждой услуги, введённой в структуру РПК) начинает обнажать затраты на техническое обслуживание — обновление SDK требует переструктурирования и публикации всех сервисов, разные сервисы SSDK нуждаются в разной доставке и изменение стратегии управления требует изменения кода.

ZhiHua Tech рекомендует вводить после того, как масштаб обслуживания достигнет определенного уровня Service Mesh (например, Istio + Envoy)Недостаточный потенциал управления услугами для агента Sidecar:

• Управление потокамиВыпуск Grayscale (по весу / Header / Cookie-диверсии), тестирование на впрыск, запрос зеркал - эти возможности могут быть достигнуты с помощью настроек Istio Design Rule и Vital Services без необходимости изменения бизнес-кодов.
• Безопасные коммуникацииMTLS (двусторонняя аутентификация TLS) автоматически включается для межсервисных коммуникаций, выдача, ротация и отзыв сертификатов автоматически управляется Citadel, и разработчикам бизнеса не нужно воспринимать механизм безопасности снизу вверх.
• наблюдаемостьSidecar автоматически собирает данные телеметрии (задержка, успех, скорость ошибок) для всех входящих и исходящих станций и выводит на Prometheus (индикатор) + Jaeger (ссылка) + ELK (лог), образуя полный наблюдаемый треугольник.

CI/CD и линия доставки Gitoops

ZhiHua Tech помогает клиентам создавать стандартизированную систему CI/CD, основной принцип которой заключается в том, чтоШаблон, охватывающий строительство и развертывание всех услуг：

• Ватерлиния затмевающаяВсе микросервисы имеют одинаковый набор шаблонов CI/CD (Jenkinsfile или GitHub Actions workwork template), для доступа к которым требуется всего несколько переменных (язык, порт, квоты ресурсов).
• Gitops развертываниеЗаявление обо всех ресурсах Kubernetes (Развертывание, Сервис, Вход, ConfigMap) хранится в Git Repository, где ArgoCD непрерывно отслеживает изменения в Git Repository и автоматически синхронизирует их с кластерами.Любая ручная модификация кластера откатывается контроллером GitOps, чтобы гарантировать, что «Git Repository = Group Real».
• Канарские релизыПрогрессивная доставка через Argo Rollouts — новая версия Pod развёрнута на 5% первой, частота ошибок наблюдения и задержка 5 минут, а нормальное расширение индикатора до 25% 50% и 100%.Показатели на любом этапе автоматически запускают откат.

Объем системных мощностей

Зип, контейнерная база.

• Планирование кластеров KubernetesМногоэкологический (разработка/тестирование/предварительное производство/производство) дизайн кластерной архитектуры, выбор спецификации узла, выбор сетевого плагина (Calico/Cilium), дизайн программы хранения (CSI).
• Управление зеркалом PorterНиже приведены некоторые примеры последних событий в области зеркалирования: строительство частного зеркального склада в Гавани, сканирование зеркальной безопасности (Трайви), стратегия тонкости зеркал (многоуровневое строительство, базовое зеркало растворения).
• Гибкая растяжкаHPA (на основе горизонтального масштабирования CPU / RAM Pod) + Cluster Autoscaler (масштабирование уровня узла) + KEDA (на основе масштабирования на основе событий пользовательских индикаторов, таких как глубина очереди сообщений).

Управление услугами и связь

• API шлюзГармонизировать маршрут, ограничить поток, аутентификацию, журнал, обработку поперечного домена. Поддерживает расширение плагинизации для настраиваемой логики.
• Регистрация и обнаружение услугОбнаружение сервисов на основе Kubernetes DNS + Service, управление метаданными внешних сервисов совместно с Consul/Nacos.
• Конфигурация центраNacos/Apollo централизованно управляет конфигурациями среды, изменения конфигурации отправляются в режиме реального времени, поддерживая распределение и откат в серой шкале.

• Наблюдательная система

• Логично: Fluentd/Filebeat collect → Буфер Kafka → Магазин Elasticsearch → Дисплей Kibana.
• ПоказателиPrometheus + Grafana, охватывающий индикаторы инфраструктуры (узел/контейнер/под) и индикаторы приложений (QPS/задержка/неправильность/эксплуатационные показатели).
• Отслеживание ссылокOpenTelemetry + Jaeger, отображающий полную цепочку вызовов и время перехода между запрашиваемыми услугами.
• Позвони в полицию.: Alertmanager Classified Alert (срочная/предупреждение/уведомление), отправленный через Enterprise Micro-Credits/Pertification/Flying Book, с скриншотом панели Grafana.

CI/CD Доставка

• Стандартизация репозитория кода (политика филиала, CODEOWNERS, шаблон Merge Request)
• Автоматизация, модульное тестирование, сканирование кода (SonarQube), доставка зеркальной сборки
• Развертывание Gitoops (ArgoCD) + Стратегия выпуска сине-зеленых

Архитектура распределенных данных

• Разделение баз данных: Разделение по вертикали по полю + Разделение по горизонтали по времени/ID (SharingSphere). Читать и писать отдельно (основная библиотека, чтение из библиотеки).
• Дистрибьюторские услугиЭто небольшое количество местных информационных бюллетеней, основанных на полученной информации и местных информационных бюллетенях.
• Структура кэшаRedis Cluster Multi-level Cache (локальный кэш + база данных), Cache Aside / Writer Behind.

Доставляемые

Предполагаемая ориентация на ценность

• Значительный прирост эффективности при доставкеСервис самостоятельно построен, протестирован и развернут, а единый цикл выпуска сервиса снижен с «недельного» до «часового» уровня.Аварийный ремонт больше не блокируется другими модулями.
• Изоляция и эластичность по умолчаниюАвтоматическое усиление (HPA/KEDA) гарантирует, что в пиковом потоке есть достаточно ресурсов, чтобы снизить стоимость автоматического восстановления ресурсов в низких долинах.
• Технология склада свободыРазличные службы могут выбирать лучшие технологические отсеки, и внедрение новых технологий больше не потребует полной реинжиниринга.
• Наблюдаемый охватБлогер говорит, что правительство смогло «показать проблему» от «нет проблемы» до «никаких показателей аномалии, наблюдаемых на Grafana, прежде чем пользователь пожаловался».