Как выбрать 5 видов реестра микросервисов? Эти размеры говорят вам!

1. Введение

В настоящее время существует четыре основных центра регистрации микросервисов:

• Zookeeper
• Eureka
• Consul
• Kubernetes

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

Это первая часть рубрики «Spring Cloud Advanced».ЧетыреСтатьи, предыдущие статьи следующие:

• Пятьдесят пять картинок расскажут вам, насколько силен Nacos, перевозчик душ микросервисов?
• Смертельная серия из 9 вопросов от openFeign, кто выдержит это?
• Али спросил в интервью: Как выбрать центры конфигурации Nacos, Apollo и Config? Эти 10 измерений говорят вам!

2. Зачем нужен регистрационный центр?

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

Детали продукта необходимо назватьМаркетинг,Заказ,в наличииТри сервиса, есть проблемы:

• Возможны адреса всех трех служб: Маркетинг, Заказы и Инвентаризация.динамичныйЕсли изменение происходит, то оно требует частых изменений только в виде конфигурации, если же оно прописано в файле конфигурации, то его также необходимо изменить.перезагрузить систему, что слишком недружественно к производству

• Услуга в виде развертывания кластера Как реализовать балансировку нагрузки на вызывающем

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

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

3. Как реализовать центр регистрации?

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

1. Когда мы ищем товары, товары и услуги являются поставщиками;
2. Когда мы запрашиваем информацию о продукте, поставщик услуг также является потребителем услуг, а потребление — это заказ, запасы и другие услуги; Поэтому нам нужно ввести три роли: средний уровень (центр регистрации), производитель и потребитель, как показано на следующем рисунке:

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

1. Когда служба запускается, поставщик службы автоматически регистрирует свою собственную службу в реестре через клиентское приложение внутреннего реестра, включаяадрес хоста,наименование услугии т.д. информация;

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

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

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

1. модель публикации-подписки: потребители службы могут отслеживать состояние обновлений службы в режиме реального времени, обычно используя прослушиватели и механизмы обратного вызова.Классический случайZookeeper;

2. Стратегия активного вытягивания: потребитель службы периодически обращается к интерфейсу получения службы, предоставленному реестром, чтобы получить последний список служб и обновить локальный кэш.Классический случай:Eureka;

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

4. Как решить проблему балансировки нагрузки?

Существует два способа реализации балансировки нагрузки:

1. Балансировка нагрузки на стороне сервера;

2. Балансировка клиентской нагрузки; Схема реализации по сути та же, но носители разные, один сервер, а другой клиент, как показано на следующем рисунке:

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

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

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

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

1. Метод опроса

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

2. Случайный метод

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

3. Алгоритм хеширования

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

4. Метод взвешенного опроса

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

5. Взвешенный случайный метод

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

6. Метод минимального количества подключений

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

5. Как выбрать регистрационный центр?

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

Прежде чем представить это, вам нужно знать некоторые вещи:CAP,Paxos, ПлоталгоритмЯ не буду вдаваться в подробности здесь. Начните внедрять вышеперечисленные 5 способов реализации центра регистрации.

1. Зоопарк

Интересно, что чиновник не говорит, что он центр регистрации, но многие отечественные сценарии Dubbo используют Zookeeper для выполнения функций центра регистрации.

Конечно, на это есть много исторических причин.Мы не будем возвращаться к этому.Позвольте мне рассказать о производительности Zookeeper, когда он используется в качестве реестра.

Основные понятия зоопарка

1. Три роли

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

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

Роль наблюдателя: аналогично подписчику, но без права голоса.

2. Четыре вида узлов

PERSISTENT - постоянный узел: узел всегда существует в Zookeeper, если он не удален вручную.

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

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

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

3. Механизм

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

Как Zookeeper реализует реестр?

Короче говоря, Zookeeper может действовать как реестр услуг (Service Registry), позволяя нескольким поставщикам услуг формировать кластер, позволяя потребителям услуг получать определенные адреса доступа к услугам (ip + порты) через реестр услуг для доступа к конкретным поставщикам услуг. Как показано ниже:

Каждый раз, когда поставщик услуг развертывается, он должен зарегистрировать свою собственную службу по определенному пути в zookeeper:/{service}/{version}/{ip:port}.

такие как нашиHelloWorldServiceРазверните на две машины, тогда в Zookeeper будут созданы две директории:

• /HelloWorldService/1.0.0/100.19.20.01:16888

• HelloWorldService/1.0.0/100.19.20.02:16888.

Это описание немного сложно понять, следующее изображение более интуитивно понятно,

В Zookeeper регистрация службы фактически создает узел Znode в Zookeeper, в котором хранятся IP-адрес, порт, метод вызова (протокол, метод сериализации) и т. д. службы.

Этот узел несет наибольшую ответственность.Он создается поставщиком услуг (при публикации услуги), чтобы потребитель услуги мог получить информацию в узле, чтобы определить реальный IP-адрес поставщика услуг и инициировать вызов. . Установить как временный узел по IP, тогда данные узла не будут постоянно храниться на сервере ZooKeeper.

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

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

Поэтому Zookeeper не может гарантировать доступность службы.

2. Эврика

Netflix, я чувствую, что назревает что-то лучшее, давайте сосредоточимся на дизайне, связанном с Ereka 1.x.

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

Базовая архитектура Eureka состоит из 3 ролей:1. Эврика сервер

Предоставлять функции регистрации и обнаружения услуг;

2. Поставщик услугПоставщик услуг регистрирует свой собственный сервис в Eureka, чтобы потребитель услуги мог его найти;

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

Эврика создана, чтобы следоватьAPВ принципе, Eureka Server может запускать несколько экземпляров для создания кластеров и решения отдельных проблем. Экземпляры могут регистрироваться друг с другом для повышения доступности. Это децентрализованная архитектура. -peer, каждый узел можно считать копией других узлов.

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

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

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

По умолчанию, если Eureka Server не получает пульс экземпляра службы в течение определенного периода времени (период по умолчанию — 30 секунд), Eureka Server отключит экземпляр (по умолчанию — 90 секунд, eureka.instance.lease-expiration -duration -в секундах для пользовательской конфигурации).

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

В кластере Eureka, пока доступна одна Eureka, служба регистрации может быть гарантированно доступна, но найденная информация может быть не самой последней (строгая согласованность не гарантируется).

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

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

3. Накос

Nacos легко поддерживает некоторые основные экосистемы с открытым исходным кодом, как показано ниже:

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

Nacos помогает создавать, поставлять и управлять платформами микросервисов более гибко и легко. Nacos — это сервисная инфраструктура для создания современных архитектур приложений, основанных на «сервисах» (таких как парадигма микросервисов, облачная парадигма).

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

Накос Особенности

Обнаружение служб и мониторинг работоспособности служб

Nacos поддерживает обнаружение сервисов на основе DNS и RPC. После того как поставщик услуг зарегистрирует Службу с помощью собственного SDK, OpenAPI или отдельного агента TODO, потребитель службы может использовать DNS TODO или HTTP&API для поиска и обнаружения службы.

Nacos обеспечивает проверку работоспособности сервисов в режиме реального времени, предотвращая запросы к неработоспособным хостам или экземплярам сервисов. Nacos поддерживает проверки работоспособности транспортного уровня (PING или TCP) и прикладного уровня (например, HTTP, MySQL, определяемые пользователем). Для проверки работоспособности сервисов в сложных облачных средах и средах с топологией сети (таких как VPC, пограничные сети и т. д.) Nacos предлагает два режима проверки работоспособности: режим отчетов агента и активное обнаружение сервера. Nacos также предоставляет единую панель проверки работоспособности, которая поможет вам управлять доступностью услуг и трафиком в зависимости от состояния работоспособности.

Служба динамической настройки

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

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

Централизованное управление конфигурацией упрощает внедрение служб без сохранения состояния и упрощает гибкое масштабирование служб по запросу.

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

Служба динамического DNS

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

Nacos предоставляет несколько простых API-интерфейсов DNS TODO, которые помогут вам управлять доменами, связанными с вашей службой, и доступным списком IP:PORT.

Службы и управление их метаданными

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

Nacos поддерживает управление плагинами Что касается хранения данных Nacos, поддерживаются как временные, так и постоянные.

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

4. Консул

Consul – это инструмент с открытым исходным кодом, запущенный HashiCorp. Consul разработан на языке Go и очень прост в развертывании. Для него требуется всего несколько исполняемых программ и файлов конфигурации, он экологически чистый и легкий. Consul — это распределенная, высокодоступная, горизонтально масштабируемая служба обнаружения и настройки для распределенных систем.

Особенности Консула

Обнаружение службы

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

Проверка здоровья

Клиент Consul может обеспечить любое количество проверок работоспособности, связанных либо с данной службой («Вернул ли веб-сервер 200 OK»), либо с локальным узлом («Использование памяти ниже 90%»). Операторы могут использовать эту информацию для мониторинга работоспособности кластера, а компоненты обнаружения служб могут использовать эту информацию для направления трафика от неработоспособных хостов.

Хранение ключей/значений

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

Безопасная служебная связь

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

Несколько центров обработки данных

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

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

В едином дата-центре Консул делится на две ноды: Клиент и Сервер (все ноды также называются Агентами), нода Сервер хранит данные, а Клиент отвечает за проверку работоспособности и пересылку запросов данных на Сервер, нода Сервер имеет Лидера и несколько Последователей, а узлы Лидер будут синхронизировать данные с Последователями.Рекомендуемое количество Серверов – 3 или 5. Когда Лидер умирает, активируется механизм выборов для создания нового Лидера.

Узлы Consul в кластере поддерживают членство через протокол сплетен (gossip protocol). Протокол сплетен для одного центра обработки данных использует для связи как TCP, так и UDP, и оба используют порт 8301. Протокол сплетен в центрах обработки данных также использует для связи как TCP, так и UDP, используя порт 8302.

Запросы на чтение и запись данных в кластере могут быть либо отправлены непосредственно на сервер, либо перенаправлены на сервер через RPC через клиента.Запрос в конечном итоге достигнет узла-лидера.Если задержка данных разрешена, запрос на чтение может также выполняться на обычном серверном узле. Чтение, запись и копирование данных в кластере осуществляется через TCP-порт 8300.

На самом деле Consul тоже можно зарегистрировать в приложении, а в качестве нагрузки потом будет использоваться бакет семейства Spring Cloud.

Давайте поговорим о регистрации вне приложения для Консула здесь:

На приведенном выше рисунке есть два основных компонента, а именно Registrator и Consul Template.Далее мы представим, как эти два компонента можно объединить для реализации обнаружения и регистрации служб при разработке приложений.

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

Consul Template: регулярно получать последний список узлов поставщика услуг с сервера реестра и обновлять конфигурацию LB (например, вышестоящего Nginx), чтобы потребители услуг могли получить доступ к последней информации о поставщике услуг, используя Nginx для достижения динамической балансировки нагрузки.

Общая схема архитектуры может выглядеть так:

Мы используем Регистратор для мониторинга состояния каждого Сервера. При запуске нового Сервера Регистратор регистрирует его в реестре Consul.

Поскольку Consul Template подписался на служебное сообщение в реестре, реестр Consul передаст новую информацию о сервере в Consul Template, а Consul Template изменит файл конфигурации nginx.conf, а затем позволит Nginx перезагрузить конфигурацию. с целью автоматического изменения балансировки нагрузки.

5. Кубернет

Kubernetes — это легкая и расширяемая платформа с открытым исходным кодом для управления контейнерными приложениями и службами. Автоматическое развертывание и масштабирование приложений можно выполнять через Kubernetes.

В Kubernetes контейнеры, из которых состоит приложение, объединяются в логическую единицу для упрощения управления и обнаружения. Kubernetes основан на 15-летнем опыте работы с рабочими нагрузками в качестве производственной среды Google и включает в себя лучшие идеи и практики сообщества.

После нескольких лет бурного развития Kubernetes сформировал большую экологическую среду, Google сделал Kubernetes проектом с открытым исходным кодом в 2014 году. Ключевые особенности Kubernetes включают в себя:

• Автоматическая упаковка: автоматическое развертывание контейнеров на основе требований к ресурсам контейнера и ограничений без ущерба для доступности. В то же время, чтобы улучшить использование и сэкономить больше ресурсов, объедините критические и оптимальные рабочие нагрузки.
• способность к самовосстановлению: при сбое контейнера контейнер будет перезапущен; при возникновении проблемы с развернутым узлом узла контейнер будет повторно развернут и перепланирован; когда контейнер не пройдет проверку мониторинга, контейнер будет закрыт; пока контейнер не заработает нормально , услуги будут предоставляться извне.
• Горизонтальное расширение: масштабирование приложений можно увеличивать и уменьшать с помощью простых команд, пользовательского интерфейса или в зависимости от использования ЦП.
• Обнаружение служб и балансировка нагрузки. Разработчики могут выполнять обнаружение служб и балансировку нагрузки на основе Kubernetes без использования дополнительных механизмов обнаружения служб.
• Автоматический выпуск и откат: Kubernetes может программно публиковать приложения и связанные с ними конфигурации. Если с релизом возникнут проблемы, Kubernetes сможет откатить произошедшие изменения.
• Управление конфиденциальностью и конфигурацией: развертывание и обновление безопасности и конфигурации приложений без перестроения образа.
• Организация хранения: системы хранения с автоматическим подключением, которые могут поступать от локальных поставщиков общедоступных облачных хранилищ (например, GCP и AWS), сетевых хранилищ (например, NFS, iSCSI, Gluster, Ceph, Cinder, Floker и т. д.).

Kubernetes относится к распределенной архитектуре master-slave, состоящей в основном из Master Node и Worker Node, а также включает клиентский инструмент командной строки Kubectl и другие дополнительные элементы.

Master Node: Как управляющий узел, он планирует и управляет кластером.Мастер в основном состоит из трех частей:

1. Api ServerЭквивалентно шлюзу K8S, все запросы команд должны проходить через сервер Api;

2. Планировщик Kubernetes, используйте алгоритм планирования, чтобы запланировать ресурс запроса на узел Node;

3. Контроллер, поддерживать объекты ресурсов K8S (CRUD: добавлять, удалять, обновлять, изменять);

4. объект хранилища etcd(может сервис регистрации, обнаружения и т.д.);

Worker Node: как настоящий рабочий узел, контейнер для запуска бизнес-приложений; рабочий узел в основном состоит из пяти частей:

1. Docker — это базовая среда для запуска контейнеров, контейнерный движок;

2. Kuberlet выполняет операции с ресурсами на узлах Node, Scheduler отправляет запрос в Api, а затем Api Sever сохраняет данные информационных инструкций в ETCD, поэтому Kuberlet сканирует ETCD и получает запрос инструкции, а затем выполняет его;

3. Kube-proxy — это прокси-сервис, который играет роль в балансировке нагрузки;

4. Fluentd собирает логи;

5. Под: базовая единица (наименьшая единица), управляемая Kubernetes, а внутри пода находится контейнер. Kubernetes не управляет контейнерами напрямую, он управляет подами;

6. Резюме

1. Высокая доступность

Во всех этих продуктах с открытым исходным кодом рассматривается создание кластера высокой доступности, но есть некоторые различия;

2. Выбор СР или АП

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

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

3. Техническая система

Для языков мы все являемся стеками технологий Java.С этой точки зрения мы больше склоняемся к Eureka и Nacos.

Если в компании есть выделенное промежуточное ПО или команда по эксплуатации и сопровождению, можно использовать Consul и Kubernetes.Ведь за Kubernetes будущее.Мы преследуем цель решать эти проблемы в рамках фреймворка, а не вовлекать бизнес-разработку в приложение У нас на самом деле есть последний, но он может не достичь уровня самостоятельных исследований и разработок, поэтому вы можете только попросить себя пойти дальше.

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

Что касается выбора между Эврикой и Накосом, этот выбор сделать проще.То, что заставляет меня делать меньше, это то, что я выбираю.Очевидно, что Накос помог нам сделать больше вещей.

4. Продуктовая активность

Эти продукты с открытым исходным кодом относительно активны в целом.

7. Последнее слово

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

Если интересно, можете обратить внимание на официальный аккаунт Чен Моу:Колонка технологий Code Ape