Руководство по выбору стека технологий микросервисной архитектуры

Микросервисы GitHub открытый источник продукт
Автор｜Ян Бо Редактор｜Го Лэй Введение

2014 год можно считать первым годом микросервисов 1.0.В этом году было несколько знаковых событий: во-первых, Мартин Фаулер опубликовал в своем блоге статью «Микросервисы», официально предложив стиль микросервисной архитектуры, крупномасштабную производственную проверку и, наконец, абстрагируясь для формирования набора базовых компонентов микросервиса с открытым исходным кодом, вместе именуемых NetflixOSS, успешный опыт Netflix начал признаваться и уважаться в отрасли; в-третьих, Pivotal интегрировала компоненты микросервиса с открытым исходным кодом NetflixOSS в свою систему Spring и запустила разработку Spring Cloud Microservice. стек технологий.

Три года пролетели как один миг,Экосистема микросервисных технологий претерпела большие изменения, Containers, PaaS, Cloud Native, gRPC, ServiceMesh, Serverless и другие новые технологии и новые концепции, вы будете петь, а я появлюсь, и, прежде чем вы это узнаете, мы подошли к эпохе микросервисов 2.0.

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

2. Критерии выбора

Для выбора технологии лично у меня есть много критериев, из которых наиболее важными являются следующие три:

1. Класс производства

Стек технологий, который мы выбираем, предназначен для решения реальных бизнес-задач и предотвращения потока трафика в производстве (небрежный выбор может привести к несчастным случаям на уровне производства), а не просто для создания POC или демонстрационного дисплея, поэтому уровень производства (Production Ready), эксплуатация и обслуживание (Ops Ready), управляемая, зрелая и стабильная технология — наш первый выбор;

2. Целевые продукты интернет-компаний первого эшелона

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

3. Активность сообщества с открытым исходным кодом

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

Кроме того, для компаний с разным объемом бизнеса и размером команды критерии выбора технологий часто отличаются, а критерии выбора технологий для компаний-стартапов и компаний уровня BAT могут быть совершенно разными. Эта статья в основном ориентирована на компании с ежедневным трафиком более 10 млн человек и командой R&D не менее 50. Если она меньше этого размера, предлагаю серьезно оценить, действительно ли необходимо внедрять микросервис. архитектура. Учитывая популярность языка Java в Китае и мой личный опыт, эта статья в основном предназначена для предприятий, использующих стек технологий Java. В этой статье также предполагается самостоятельная микросервисная инфраструктура. Некоторые продукты фактически имеют соответствующие облачные сервисы, которые можно использовать напрямую. Самостоятельно созданные и внедренные облачные сервисы имеют свои преимущества и недостатки. Архитекторы должны всесторонне взвесить их в соответствии с контекстом сценарий.

Редактор здесь настоятельно рекомендует видеокурс Ян Бо по архитектуре микросервисов в «Geek Time App». Он использует диаграмму и 6 минут, чтобы объяснить ключевые концепции микросервисной архитектуры простыми словами. Это первый сезон, за ним следует второй. Заинтересованные пользователи, пожалуйста, нажмите на ссылку в конце статьи, чтобы прочитать исходный текст для деталей.

3. Ключевые моменты микросервисной инфраструктуры

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

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

В-четвертых, выбор структуры обслуживания

Сервисные платформы — относительно зрелая область со слишком большим количеством вариантов. Spring Boot/Cloud [Приложение 12.1] Благодаря влиянию сообщества Spring и одобрению Netflix в настоящее время его можно считать стандартом сообщества для создания микросервисов Java.В настоящее время Spring Boot имеет более 20 тысяч звезд на GitHub.

Фреймворк на основе Spring по сути можно рассматривать как фреймворк RESTful (а не фреймворк RPC).Протокол сериализации в основном использует текстовый JSON, а протокол связи обычно основан на HTTP. Платформа RESTful, естественно, поддерживает кросс-языковость, и любой язык может получить доступ к вызову, пока есть HTTP-клиент, но обычно клиенту необходимо проанализировать полезную нагрузку самостоятельно. В настоящее время фреймворк Spring также поддерживает контрактную модель программирования Swagger, которая может генерировать строго типизированные клиенты на различных языках на основе контракта, что значительно облегчает доступ приложений к различным языковым стекам. инфраструктура RESTful и спецификация Swagger, различные сгенерированные. Существует еще много подводных камней в области взаимодействия языковых клиентов.

Dubbo [Приложение 12.2] — это техническое воплощение многолетнего опыта Alibaba по созданию распределенных микросервисов производственного уровня. Он обладает очень богатыми возможностями управления сервисами и имеет большое влияние в местном техническом сообществе. В настоящее время на github насчитывается более 16 000 звезд. Dubbo, по сути, представляет собой набор RPC-фреймворков на основе Java.Dangdang Dubbox расширяет возможности Dubbo по поддержке интерфейса RESTful.

Dubbo в основном ориентирован на стек технологий Java.Отсутствие межъязыковой поддержки является одной из его слабых сторон.Кроме того,из-за своих богатых возможностей управления этот фреймворк относительно тяжеловесен,и порог для полноценного использования этого фреймворка относительно высок Однако, если ваше предприятие в основном инвестирует в стек технологий Java, выбор Dubbo позволит вам занять более высокую стартовую позицию в структуре обслуживания.Будь то производительность или возможности управления услугами на уровне предприятия, Dubbo проделала большую работу. Motan с открытым исходным кодом от Sina Weibo (GitHub 4k stars) тоже хорош, его функции аналогичны Dubbo, его можно рассматривать как облегченную адаптированную версию Dubbo.

gRPC [Приложение 12.3] — это новый набор RPC-фреймворков, представленный Google в последние годы. Основанный на строгой модели контрактного программирования protobuf, он может автоматически генерировать клиентов на разных языках и гарантировать совместимость. Поддержка HTTP2 является отличительной чертой gRPC, а производительность коммуникационного уровня значительно выше по сравнению с HTTP. Protobuf — это высокопроизводительный протокол сериализации с долгой историей и хорошей репутацией в сообществе, в сочетании с одобрением Google и влиянием сообщества. В настоящее время gRPC также относительно популярен: более 13,4 тыс. звезд на GitHub.

В настоящее время gRPC больше подходит для внутренних сервисных вызовов друг к другу. Можно выставлять RESTful-интерфейсы извне, но это более проблематично (требуется сотрудничество с gRPC Gateway), поэтому может потребоваться введение второй RESTful-инфраструктуры. в качестве дополнения для внешних сценариев API. В целом, gRPC все еще является относительно новым, и сообщество еще не сформировало консенсус относительно преимуществ, которые дает HTTP 2. Рекомендуется осторожно инвестировать и проводить некоторые пилотные проекты.

Пять, выбор службы поддержки во время выполнения

Службы поддержки во время выполнения в основном включают три продукта: реестр служб, шлюз маршрутизации служб и центр централизованного конфигурирования.

Для реестра услуг, если будет принята система Spring Cloud, лучше всего подойдет Eureka [Приложение 12.4]. Eureka была проверена в Netflix для крупномасштабного производства и поддерживает несколько центров обработки данных. Клиент может реализовать гибкую мягкую загрузку клиента с помощью Ribbon.Eureka В настоящее время на GitHub более 4,7 тыс. звезд, Consul [Приложение 12.5] также является хорошим выбором. Он, естественно, поддерживает кросс-дата-центры, а также поддерживает хранилище модели KV и гибкие возможности проверки работоспособности. более 11 тысяч звезд на GitHub.

Сервисный шлюз также является относительно зрелой областью с множеством вариантов. Если система Spring Cloud будет принята, лучше всего подойдет Zuul [Приложение 12.6]. Zuul был проверен крупномасштабным производством в Netflix, поддерживает гибкий механизм сценариев динамического фильтра и имеет недостаточную асинхронную производительность (асинхронный Zuul на основе Netty не имеет уже давно запущено официальное издание). Zuul Gateway в настоящее время имеет более 3,7 тыс. звезд на github. Kong [Приложение 12.7], шлюз API на основе Nginx/OpenResty, в настоящее время популярен на github с более чем 14,1 тыс. звезд. из-за использования Ядро Nginx, Kong обладает высокой асинхронной производительностью, кроме того, механизм подключаемых модулей на основе lua более гибкий, а подключаемые модули сообщества также богаты, начиная от безопасности и заканчивая текущим ограничением и слиянием, а также существует множество средств управления с открытым исходным кодом. интерфейсы, которые могут централизованно управлять кластерами Kong.

Редактор здесь настоятельно рекомендует видеокурс Ян Бо по архитектуре микросервисов в «Geek Time App». Он использует диаграмму и 6 минут, чтобы объяснить ключевые концепции микросервисной архитектуры простыми словами. Это первый сезон, за ним следует второй. Заинтересованные пользователи, пожалуйста, нажмите на ссылку в конце статьи, чтобы прочитать исходный текст для деталей.

В центре конфигурации Spring Cloud поставляется с Spring Cloud Config [Приложение 12.8] (GitHub 0,75 тыс. звезд), который, по моему личному мнению, не соответствует производственному уровню, и многие возможности управления отсутствуют.Можно попробовать мелкомасштабные сценарии. Лично я рекомендую Центр конфигурации Apollo [Приложение 12.9] от Ctrip, который был проверен на производственном уровне на Ctrip.Он имеет высокую доступность, конфигурация вступает в силу в режиме реального времени (комбинация push-pull), аудит конфигурации и управление версиями, а также мульти- Поддержка нескольких кластеров в среде. Рекомендуется использовать функции производственного уровня. Широкомасштабное внедрение на предприятии, требующее управления централизацией конфигурации. В настоящее время у Apollo более 3,4 тысячи звезд на github.

Шесть, выбор службы мониторинга

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

В настоящее время ELK можно считать стандартом для мониторинга журналов с готовыми полными функциями.ElasticSearch [Приложение 12.10] в настоящее время имеет более 28,4 тыс. звезд на GitHub. Elastalert [Приложение 12.11] (GitHub 4k stars) — это модуль уведомления Yelp с открытым исходным кодом для ELK.

В настоящее время основным направлением мониторинга цепочки вызовов в сообществе является Comment CAT [Приложение 12.12] (GitHub 4,3 тыс. звезд), Twitter с открытым исходным кодом Zipkin [Приложение 12.13] (GitHub 7,5 тыс. звезд) и Naver с открытым исходным кодом Pinpoint [Приложение 12.14] ( GitHub 5,3 тысячи звезд). Лично я рекомендую CAT с открытым исходным кодом от Dianping. В Dianping и многих отечественных интернет-компаниях есть случаи посадки. Функции и возможности управления на уровне производства относительно полны. Кроме того, CAT имеет собственный модуль сигнализации. Ниже приведена моя предыдущая форма оценки трех продуктов для справки.

Мониторинг показателей в основном опирается на базу данных временных рядов (TSDB), более зрелым продуктом является OpenTSDB на основе HBase [Приложение 12.15], открытый исходный код StumbleUpon (KariosDB на основе Cassandra [Приложение 12.16] также является опцией, GitHub 1.1k звезд, в основном это модифицированная версия OpenTSDB для Cassandra).OpenTSDB имеет распределенные возможности и может масштабироваться горизонтально, но он относительно тяжелый и подходит для средних и крупных предприятий.OpenTSDB в настоящее время находится на GitHub. 2,9к звезд.

Сама OpenTSDB не предоставляет модуль сигналов тревоги. Argus [Приложение 12.17] (звезда GitHub 0.29k) — это унифицированная платформа мониторинга и сигналов тревоги на основе OpenTSDB с открытым исходным кодом для Salesforce. дополнение к сигналам тревоги OpenTSDB. В последние годы также появились некоторые облегченные TSDB, такие как InfluxDB [Приложение 12.18] (12,4 тыс. звезд на GitHub) и Prometheus [Приложение 12.19] (14,3 тыс. звезд на GitHub).Эти продукты имеют широкие возможности создания отчетов и поставляются с модулями оповещения, но распределенная Недостаточная мощность, подходящая для малых и средних предприятий. Графана [Приложение 12.20] (19,9 тыс. звезд на GitHub) — это стандарт сообщества для отображения отчетов о показателях.

В сообществе также есть некоторые общие продукты для проверки работоспособности и оповещения, такие как Sensu [Приложение 12.21] (GitHub 2,7 тыс. звезд), которые могут отслеживать различные службы (например, конечные точки проверки работоспособности, предоставляемые Spring Boot, метрики в базах данных временных рядов). , ELK (журнал ошибок и т. д.) настраивают гибкие проверки работоспособности (проверки), а затем пользователи могут устанавливать гибкие политики оповещения о результатах проверки. У Сенсу есть дела в таких компаниях, как Yelp. Другими подобными продуктами являются открытый исходный код Esty 411 [Приложение 12.22] (GitHub 0,74 тыс. звезд) и Zalando. ZMon [Приложение 12.23] (GitHub 0,15 тыс. звезд), это продукты, запущенные в Esty и Zalando соответственно, но порог использования пользовательской конфигурации проверки и сигнализации относительно высок, а сообщество не популярно. возможности саморазвития попробовать. Серверная часть ZMon использует хранилище KairosDB.Если предприятие приняло KariosDB в качестве базы данных временных рядов, ZMon можно рассматривать как модуль оповещения о тревоге.

Редактор здесь настоятельно рекомендует видеокурс Ян Бо по архитектуре микросервисов в «Geek Time App». Он использует диаграмму и 6 минут, чтобы объяснить ключевые концепции микросервисной архитектуры простыми словами. Это первый сезон, за ним следует второй. Заинтересованные пользователи, пожалуйста, нажмите на ссылку в конце статьи, чтобы прочитать исходный текст для деталей.

Семерка, сервис отказоустойчивой селекции

Для стека технологий Java Hystrix от Netflix [Приложение 12.24] (12,4 тыс. звезд на github) инкапсулирует возможности слияния, изоляции, ограничения тока и перехода на более ранние версии компонентов, а любые зависимые вызовы (базы данных, службы, кэши) могут быть инкапсулированы в команду Hystrix. , Он автоматически становится отказоустойчивым после инкапсуляции. Hystrix возник в результате инженерного проекта устойчивости Netflix, был проверен Netflix для крупномасштабного производства и в настоящее время является стандартом сообщества для отказоустойчивых компонентов с более чем 12 тысячами звезд на GitHub. Другие языковые стеки также имеют упрощенные версии компонентов, таких как Hystrix.

Обычно Hystrix необходимо встраивать на стороне приложения или в структуру, и существуют определенные пороговые значения использования. Для компаний, которые используют централизованный обратный прокси-сервер (пограничный и внутренний) для маршрутизации услуг, вы можете сосредоточиться на обратном прокси-сервере для ограничения тока выключателя, таком как Nginx [Приложение 12.25] (GitHub 5.1k звезд) или Kong [Приложение 12.7] ( GitHub 11,4k звезд) Подобные обратные прокси, все они имеют плагины, которые поддерживают гибкую настройку ограничения тока и отказоустойчивости. Шлюзы Zuul также могут интегрировать Hystrix для реализации централизованного ограничения тока и отказоустойчивости на уровне шлюза. Централизованный обратный прокси-сервер требует определенных возможностей НИОКР, эксплуатации и обслуживания, но он может централизованно управлять ограничением тока и отказоустойчивостью, что может упростить клиент.

Восемь, выбор фоновой службы

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

Система обмена сообщениями для сценариев с низкими требованиями к надежности, таких как журналы, проект верхнего уровня Apache Kafka [Приложение 12.26] (GitHub 7.2k звезд) является стандартом для сообщества. Для бизнес-сценариев с высокими требованиями к надежности Kafka действительно подходит, но предприятиям необходимо настраивать и улучшать возможности мониторинга и управления Kafka в соответствии с конкретными сценариями Hermes с открытым исходным кодом Allegro [Приложение 12.27] (GitHub 0,3 тыс. инкапсулирует возможности управления на уровне предприятия, подходящие для бизнес-сценариев на основе Kafka. RocketMQ с открытым исходным кодом Али [Приложение 12.28] (3,5 тыс. звезд GitHub) также является хорошим выбором, с большим количеством функций, подходящих для бизнес-сценариев, и в настоящее время является проектом верхнего уровня Apache. RabbitMQ [Приложение 12.29] (GitHub 3.6k звезд) — это старый классический MQ с богатыми функциями очередей и документацией, немного более слабыми возможностями производительности и распространения, а также опциональным для сценариев малого и среднего масштаба.

Для управления кешем, если вы склонны использовать режим прямого подключения клиента (лично считаю, что прямое подключение к кешу проще и легче), кэшоблако SohuTv с открытым исходным кодом [Приложение 12.30] (GitHub 2.5k звезд) является хорошей платформой управления кешем Redis. Он предоставляет возможности управления на производственном уровне, такие как мониторинг статистики, запуск одним щелчком мыши, автоматическое переключение при сбое, онлайн-масштабирование, а также автоматическую работу и обслуживание, а его документация также обширна. Если вы склонны использовать прокси-режим среднего уровня, twemproxy с открытым исходным кодом Twitter [Приложение 12.31] (GitHub 7,5 тыс. звезд) и CodisLab с открытым исходным кодом codis [Приложение 12.32] (6,9 тыс. звезд на GitHub) — популярный вариант в сообществе.

Для уровня доступа к распределенным данным, если используется стек технологии Java, хорошим вариантом является shardingjdbc с открытым исходным кодом [Приложение 12.33] (GitHub 3,5 тыс. звезд) Логика подтаблицы подбазы данных выполняется в клиентском драйвере jdbc, и клиент напрямую. Подключение к базе данных является относительно простым и легким и рекомендуется для сценариев малого и среднего масштаба. Если вы склонны использовать режим прокси-сервера среднего уровня для доступа к базе данных, MyCAT [Приложение 12.34] (GitHub 3.6k звезд), промежуточное программное обеспечение подтаблицы подбазы данных с открытым исходным кодом, разработанное Ali Cobar, является хорошим выбором. Режим прокси имеет высокие затраты на эксплуатацию и обслуживание. Он рекомендуется для средних и крупных сценариев, и его следует использовать командам с определенными возможностями самостоятельной разработки фреймворка и эксплуатации и обслуживания.

Система планирования задач, я лично рекомендую xxl-job с открытым исходным кодом Сюй Сюэли [Приложение 12.35] (GitHub 3,4k звезд), который прост и легок в развертывании и достаточен для большинства сценариев. Elastic-job с открытым исходным кодом Dangdang [Приложение 12.36] (3,2 тысячи звезд на GitHub) также является хорошим выбором, поскольку он более мощный и сложный, чем xxl-job.

Девять, выбор службы безопасности

Что касается механизма проверки подлинности и авторизации безопасности микросервисов, хотя в отрасли существуют стандартные протоколы, такие как OAuth и OpenID connect, конкретные методы реализации каждой компании различаются.У предприятий обычно есть много специальных требований к настройке, и все сообщество еще не сформировали общий производственный уровень.Из коробки продукт. Существуют некоторые продукты сервера авторизации с открытым исходным кодом, такие как Apereo CAS [Приложение 12.37] (GitHub 3.6k звезд), JBoss keycloak с открытым исходным кодом [Приложение 12.38] (GitHub 1.9 звезд), Spring Cloud Security [Приложение 12.39]. И т. д., большинство из них являются самоуверенными (взгляд и практика) продуктами, и в то же время продукты сложны и не обладают достаточной гибкостью из-за поддержки слишком большого количества соглашений. Персональные рекомендации основаны на стандартах подключения OAuth и OpenID, на основе ссылок на некоторые продукты с открытым исходным кодом (такие как Mitre с открытым исходным кодом OpenID-Connect-Java-Spring-Server [Приложение 12.40], GitHub 0,62k звезд), пользовательские самостоятельные разработан облегченный сервер авторизации. Wso2 предлагает эталонную схему безопасности микросервисов [Приложение 12.45], которая рекомендуется для справки.Ключевые этапы схемы заключаются в следующем:

  1. Использовать сервер авторизации, поддерживающий OAuth 2.0 и стандартный протокол OpenID Connect (персональная рекомендация — настраивать и разрабатывать самостоятельно);

  2. Используйте шлюз API в качестве единого входа для обеспечения унифицированного управления безопасностью;

  3. Перед обращением к микросервису клиент авторизуется через сервер авторизации для получения токена доступа, после чего отправляет токен доступа вместе с запросом на шлюз;

  4. Шлюз получает токен доступа, проверяет токен через сервер авторизации и выполняет преобразование токена для получения токена JWT.

  5. Шлюз пересылает токен JWT вместе с запросом в фоновую микрослужбу;

  6. Информация о сеансе пользователя может храниться в JWT, и эта информация может передаваться внутренним микросервисам или между микросервисами для целей аутентификации и авторизации;

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

  8. Во всей схеме токен доступа — это токен по ссылке, который может быть напрямую представлен в общедоступной сети без информации о пользователе; токен JWT — это токен по значению, который может содержать информацию о пользователе, но не раскрывается в общедоступной сети.

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

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

Система планирования ресурсов кластера: защита сведений о контейнере, абстрагирование всего кластера в пул ресурсов контейнера, поддержка приложений и освобождение ресурсов контейнера по запросу, а также возможность автоматического перехода на другой ресурс при сбое физической машины. В настоящее время Kubernetes с открытым исходным кодом от Google [Приложение 12.41] при поддержке Google и активном продвижении сообщества фактически сформировал позицию лидера рынка.На GitHub 31,8 тыс. 12.42] (3,5 тыс. звезд на GitHub), а также swarm и другие конкурирующие продукты, поэтому в первую очередь рекомендуется планировать ресурсы контейнера. К8с. Конечно, если у вашей команды достаточно возможностей для настройки и самоанализа и она хочет глубоко контролировать лежащий в основе алгоритм планирования, вы также можете проводить индивидуальные самоисследования на основе Mesos.

Зеркальное управление: Основанный на Docker Registry, он инкапсулирует некоторые упрощенные функции управления. Порт VMware с открытым исходным кодом [Приложение 12.43] (GitHub 3,5 тыс. звезд) — это относительно зрелый продукт корпоративного уровня в текущем сообществе. Основанный на Docker Registry, он расширяет возможности управления, такие как контроль разрешений, аудит, синхронизация образов и интерфейс управления. и можно рассмотреть.

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

Издательская платформа: ориентированная на пользователя консоль управления выпуском, поддерживающая оркестровку процесса выпуска. Он взаимодействует и взаимодействует с другими подсистемами для достижения основных возможностей публикации приложений, а также расширенных механизмов публикации, таких как сине-зеленый, канареечный и оттенки серого. В настоящее время существует очень мало продуктов с открытым исходным кодом производственного уровня.Спинакер с открытым исходным кодом от Netflix [Приложение 12.44] (github 4.2k звезд) является одним из них, но этот продукт относительно сложный и тяжелый (потому что он не только поддерживает адаптацию к различным системам CI , но также и для адаптации к различным общедоступным облакам и контейнерным облакам, что делает всю систему чрезвычайно сложной), предприятиям обычно рекомендуется настраивать самостоятельно разработанные облегченные решения в соответствии со своими собственными сценариями.

IAM: это аббревиатура управления идентификацией и доступом, которая выполняет аутентификацию личности и управление безопасным доступом для каждого компонента платформы публикации. В сообществе есть много продуктов IAM с открытым исходным кодом, наиболее известными из них являются Apereo CAS (звезды GitHub 3,6k), keycloak с открытым исходным кодом JBoss (звезды GitHub 1,9) и т. д. Однако эти продукты, как правило, сложны и тяжелы, и многие компании рассмотрят возможность индивидуальной разработки облегченных решений с учетом гибких требований к подключению различных внутренних систем.

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

Упрощенный процесс публикации выглядит следующим образом:

  1. После интеграции приложения через CI создается образ, и пользователь отправляет его в центр управления образами;

  2. Пользователи подают заявку на выпуск в центре управления активами, заполняют заявку, информацию о выпуске и квоте, а затем ждут утверждения;

  3. Утверждение релиза пройдено, и разработчик выпускает приложение через консоль релиза;

  4. Система выпуска получает информацию о спецификации выпуска, запрашивая центр управления активами;

  5. Система выпуска отправляет инструкцию для запуска экземпляра контейнера в облако контейнеров;

  6. Container Cloud извлекает образ из центра управления образами и запускает контейнер;

  7. После запуска службы в контейнере она самостоятельно регистрируется в реестре служб и поддерживает регулярное пульсирование;

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

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

Кроме того, конвейер непрерывной доставки (CD Pipeline) также является важным звеном в выпуске микросервисов, который в основном связан с процессом НИОКР и, как правило, требует корпоративной настройки.Например, процесс управления, только образы, прошедшие тест тестовой среды могут быть обновлены и выпущены в среду UAT, и только образы, прошедшие тест среды UAT, могут быть обновлены и выпущены в производственную среду.Установив некоторые ворота качества на сборочной линии, приложение может быть доставлено в производство с высоким качеством.

Одиннадцать, напиши в конце

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

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

Эта статья только с точки зрения личного опыта, и идеи выбора только для справки. Конкретный контекст (бизнес-сценарий, организация команды, техническая архитектура и т. д.) каждого предприятия различен, и фоновый опыт каждого архитектора также различен.Каждый должен сделать выбор, исходя из реальной ситуации.Нет лучшей технологии Есть только относительно подходящие технологические стеки.Кроме того, хороший выбор технологии основан на взаимном признании или даже ПК.Вы можете обсудить и высказать свое собственное мнение о выборе стека технологий микросервиса 2.0.

12. Ссылки на приложения

  1. Spring Boot  https://github.com/spring-projects/spring-boot

  2. Alibaba Dubbo  https://github.com/alibaba/dubbo

  3. Google gRPC  https://github.com/grpc/grpc

  4. NetflixOSS Eureka  https://github.com/Netflix/eureka

  5. Hashicorp Consul  https://github.com/hashicorp/consul

  6. NetflixOSS Zuul  https://github.com/Netflix/zuul

  7. Kong  https://github.com/Kong/kong

  8. Spring Cloud Config  https://github.com/spring-cloud/spring-cloud-config

  9. CTrip Apollo  https://github.com/ctripcorp/apollo

  10. ElasticSearch  https://github.com/elastic/elasticsearch

  11. Yelp Elastalert  https://github.com/Yelp/elastalert

  12. Dianping CAT  https://github.com/dianping/cat

  13. Zipkin  https://github.com/openzipkin/zipkin

  14. Naver Pinpoint  https://github.com/naver/pinpoint

  15. OpenTSDB  https://github.com/OpenTSDB/opentsdb

  16. KairosDB  https://github.com/kairosdb/kairosdb

  17. Argus  https://github.com/salesforce/Argus

  18. InfluxDB  https://github.com/influxdata/influxdb

  19. Prometheus  https://github.com/prometheus/prometheus

  20. Grafana  https://github.com/grafana/grafana

  21. Sensu  https://github.com/sensu/sensu

  22. Esty 411  https://github.com/etsy/411

  23. Zalando ZMon  https://github.com/zalando/zmon

  24. NetflixOSS Hystrix  https://github.com/Netflix/Hystrix

  25. Nginx  https://github.com/nginx/nginx

  26. Apache Kafka  https://github.com/apache/kafka

  27. Allegro Hermes  https://github.com/allegro/hermes

  28. Apache Rocketmq  https://github.com/apache/rocketmq

  29. Rabbitmq  https://github.com/rabbitmq/rabbitmq-server

  30. Sohutv CacheCloud  https://github.com/sohutv/cachecloud

  31. Twitter twemproxy  https://github.com/twitter/twemproxy

  32. CodisLab codis  https://github.com/CodisLabs/codis

  33. Dangdang Sharding-jdbc  https://github.com/shardingjdbc/sharding-jdbc

  34. MyCAT  https://github.com/MyCATApache/Mycat-Server

  35. Xxl-job  https://github.com/xuxueli/xxl-job

  36. Dangdang elastic-job  https://github.com/elasticjob/elastic-job-lite

  37. Apereo CAS  https://github.com/apereo/cas

  38. JBoss keycloak  https://github.com/keycloak/keycloak

  39. Spring cloud security  https://github.com/spring-cloud/spring-cloud-security

  40. OpenID-Connect-Java-Spring-Server  https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server

  41. Google Kubernetes  https://github.com/kubernetes/kubernetes

  42. Apache Mesos  https://github.com/apache/mesos

  43. Vmware Harbor  https://github.com/vmware/harbor

  44. Netflix Spinnaker  https://github.com/spinnaker/spinnaker

  45. Микросервисы на практике — ключевые концепции архитектуры MSA https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/

Категории