Автор | Цао Шэнли Apache Dubbo PMC

Управляемое чтение: Стереотип о Dubbo как о высокопроизводительной среде Java RPC давно глубоко укоренился в сердцах людей.С точки зрения выбора архитектуры Cloud Native, Spring Cloud может быть предпочтительным выбором в отрасли. Фактически, Dubbo незаметно превратилась в инфраструктуру Cloud Native, не только унаследовав славу прошлой эпохи RPC, но и улучшив отсутствие существующей инфраструктуры. С появлением на сцене контейнеров и K8 это поставило перед исходной областью RPC большие проблемы.В этой статье в основном обсуждаются проблемы, возникающие в области RPC, и некоторые мысли о том, как RPC может использовать K8.

Введение в K8s

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

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

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

Связь между приложением, контейнером и модулем

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

Service

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

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

Служба по умолчанию получает запись через IP-адрес кластера. Однако иногда необходимо вернуть список всех IP-адресов Pod, соответствующих условиям, и в этом случае Headless Services можно использовать напрямую.

Ссылаться на:kubernetes.io/

Рекомендуемые книги:kubernetes in action

Введение и анализ RPC

С ростом популярности микросервисов существует достаточно зрелых решений для связи между приложениями.

• После того, как в 2011 году исходный код Dubbo был открыт, его приняло большое количество малых и средних компаний;
• После запуска Spring Boot Spring постепенно показал свою вторую пружину, а затем был запущен Spring Cloud, постепенно занимающий рынок и борющийся с Dubbo на китайском рынке;
• gRPC — это инструмент сквозной связи, основанный на Http2, запущенный Google, и постепенно занимает доминирующее положение на рынке K8s, например, etcd, Istio и т. д. — все они используют gRPC в качестве средства связи;
• Концепция Service Mesh с самого начала была горячей, и теперь она постепенно становится зрелой;
• Istio + Envoy (другие коляски) постепенно начали выходить на сцену.

Точка зрения разработчика приложений

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

• реализация услуги
• Экспозиция службы (аннотация или конфигурация)
• Сервисный вызов (аннотация или конфигурация)
• Управление услугами и т. д.

С точки зрения выбора следует обратить внимание на следующие моменты:

• Простота использования (простота разработки и готовность к работе)
• представление
• Функции
• Расширяемость и т.д.

Точка зрения разработчика фреймворка

Ключевой процесс:

• сервисное воздействие
• регистрация службы
• обнаружение службы
• сервисный звонок
• Служба управления

Ключевые точки знаний:

• Сериализация
• Телекоммуникации
• сервисная маршрутизация
• балансировки нагрузки
• Лимит сервисного тока
• предохранитель
• Управление услугами, например переход на более раннюю версию

Внедрение основных технологий

Dubbo / HSF

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

Примечания: Большинство механизмов Dubbo и HSF схожи, поэтому Dubbo используется в качестве решения для обсуждения ниже.

SpringCloud

Spring Cloud совершает сетевые вызовы в виде Rest. Разработчики приложений могут создавать свои собственные открытые сервисы Rest, такие как springmvc.

Регистрация службы в Spring Cloud является измерением приложения (Eureka), и клиент и сервер взаимодействуют согласованным образом.

Spring Cloud предоставляет набор стандартных API, из которых Netflix является лучшим среди них.Этот API был реализован.Большинство разработчиков могут напрямую полагаться на Netflix и использовать его, поэтому можно сказать, что Netflix предоставляет ядро Весеннее облако. Однако, как коммерческая компания, инвестиции в открытый исходный код часто изменчивы, например, Eureka систематически поддерживается.

gRPC

gRPC — это инфраструктура RPC, разработанная на основе протокола HTTP/2, который использует Protobuf в качестве IDL. Как сквозное коммуникационное решение, gRPC может решить текущую проблему многоязычия.

Сам gRPC не предоставляет функции регистрации и управления услугами. Но теперь видно, что у gRpc есть амбиции расширяться в этом направлении.

K8s

В системе K8s нет среды честного общения, и в качестве основы RPC обычно рекомендуется gRPC.

По умолчанию в системе K8s IP-адрес модуля меняется, поэтому существует несколько способов связи между модулем и модулем:

• Сервис+DNS: Чтобы создать новый Сервис, вы можете выбрать набор списков Pod через метки.Этот Сервис соответствует неизменному IP-адресу кластера, клиент получает доступ к IP-адресу кластера через DNS или напрямую. Этот кластерный IP примерно равен реализации балансировки нагрузки (режим iptable);
• Услуги без головы: разница между безголовой службой и вышеупомянутой службой заключается в том, что он не предоставляет кластер IP, но получает набор списков IP в виде хостов имен хоста, и клиент решает, какой POD к доступу.

Istio + Envoy

Уровень управления Istio будет запрашивать и отслеживать информацию о модулях, сервисную информацию и другую информацию с сервера K8s API. Таким образом, у Istio есть полная информация о подах, сервисах и т. д. во всем кластере K8s. При изменении информации в кластере K8s Istio также может получить уведомление и обновить соответствующую информацию.

В качестве примера кратко представлен Envoy, одна из наиболее распространенных реализаций Proxy. Envoy динамически обнаруживает ресурсы, запрашивая файлы или серверы управления. Соответствующая служба обнаружения и соответствующие API называются xDS. Содержание соглашения включает LDS, RDS, CDS и так далее.

использованная литература:

Введение в Service Mesh:woohoo.info Q.capable/article/pat…Istio
Правила маршрутизации:это TiO.IO/docs/tasks/…

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

резюме

Возникшие проблемы и вызовы

Симбиоз Spring Cloud и Dubbo

Dubbo по умолчанию основан на TCP-соединении, а Spring Cloud в основном основан на запросах Rest. В процессе коммерциализации Alibaba Cloud было обнаружено, что большому количеству компаний нужны приложения Spring Cloud для связи с Dubbo, и сообщество в основном полагается на добавление уровня шлюза в Dubbo для решения проблемы.

Существует ли решение для унифицированного обнаружения регистрации службы и вызова службы?

Основная теория может относиться к:

Особенно Aliyun.com/articles/58…

Задача Даббо на сцене K8s

IP-адрес Pod под K8s является переменным (по умолчанию), и управление услугами Dubbo сильно зависит от IP-адреса.

Регистрация службы K8s завершается определением пода, а обнаружение службы — это фактически процесс поиска подов. Поды и приложения имеют определенное соответствие, которое не соответствует модели обнаружения регистрации службы измерения интерфейса в Dubbo.

Жилое пространство Даббо в сцене Service Mesh

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

Если компания уже развертывает инфраструктуру RPC и ей необходимо внедрить Service Mesh в настоящее время, есть ли хороший план перехода?

сортировка проблем

определение услуги

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

Услуга соответствует функции в функциональном измерении, например, запрос сведений о приобретенном заказе. В Dubbo он соответствует методу под интерфейсом, в Spring Cloud и gRPC — http-запросу.

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

Объясните с точки зрения Dubbo: Dubbo — это удаленная связь для программирования интерфейса, поэтому Dubbo — это сервисно-ориентированное программирование.Если вы хотите вызвать сервис, вы должны ввести его через интерфейс, а затем вызвать сервис в интерфейс. Функция запроса службы, представленная в Dubbo Ops, на самом деле не запрашивает одну службу, а получает определенные методы (службы) после запроса интерфейса (набора служб).

В мире Spring Cloud поставщик услуг регистрирует информацию о своем приложении (IP+port) в качестве экземпляра под приложением, а потребитель услуг и поставщик услуг делают запросы на отдых в согласованной форме. Каждому запросу соответствует услуга.

Отличие от Сервиса в K8s

Служба в K8s на самом деле соответствует набору списков pod+port, которые тесно связаны с DNS, что выражается простым для понимания способом: поддерживается сопоставление отношений набора pod. Упомянутые выше услуги представляют собой два понятия, которые относятся к разным сценариям.

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

Детализация регистрации службы

Приложение содержит множество интерфейсов, а интерфейс содержит множество служб (Dubbo) или приложение содержит множество служб (Spring Cloud). Проанализируйте преимущества и недостатки регистрации измерения приложения и измерения интерфейса. Будет отдельная статья, объясняющая схему применения регистрации размеров.

Регистрация измерения интерфейса

преимущество:

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

недостаток:

• Это не соответствует модели основных платформ, таких как K8s;
• Объем регистрируемых данных очень велик, и существует определенный риск производительности.

применить измерение

преимущество:

• Совместим с K8s, Spring Cloud и другими моделями;
• Производительность может быть значительно снижена.

недостаток:

• Когда приложение разделено или объединено, клиент должен это воспринимать (если вы хотите быть невидимым, разработчику фреймворка необходимо поддерживать хранилище интерфейса и отношения отображения приложения);
• Если вы хотите сохранить исходный запрос измерения интерфейса Dubbo для пользователей, вам потребуется дополнительная рабочая нагрузка;
• Для пользователя меньше прозрачности, и в OPS должны быть предоставлены некоторые другие инструменты. Например, разработчики приложений могут проверить, предоставляет ли конкретный IP-адрес услугу, и так далее.

Даббо и Весеннее облако

Цель:

• Унифицировать сервисное обнаружение Dubbo и Spring Cloud;
• Dubbo и Spring Cloud могут звонить друг другу.

Унифицированное обнаружение сервисов

Dubbo трансформируется в сервисную регистрацию приложений. (Специфика не будет расширена, и будет объяснена в следующей статье)

Пройти вызов

В реализации Dubbo поддержка будет представлена ​​в протоколе Rest и распознана Spring Cloud.

Dubbo + K8s

Как объяснялось в K8s, далее также предполагается, что приложение развернуто в контейнере, а контейнер развернут в поде.

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

Служба управления

Управление службами в оригинальной системе Dubbo сильно зависит от IP.Когда настроен набор правил управления службами, он в конечном итоге основывается на одном или нескольких IP-адресах.

После входа в систему K8s следует учитывать, что IP Pod не зафиксирован. Таким образом, текущие правила маршрутизации не могут соответствовать условиям, и будет создано много ненужных данных правил. В системе K8s поиск подов через сервисы основан на селекторах меток; управление подами через развертывания фактически основано на селекторах меток подов. Таким образом, селектор меток пода является более общим решением в упражнениях K8.

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

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

Как приложение получает информацию о текущем поде

• Pod определяет переменные среды, и приложение получает их; Dubbo обеспечивает поддержку чтения переменных среды. Pod должен установить конкретную информацию о модуле в соответствии с переменными среды, определенными Dubbo.

• Передача информации Pod через API Downward; Dubbo должен обеспечить чтение каталога для Downward, и соответствующую конфигурацию нисходящего направления необходимо настроить в Pod.

• Получайте данные через API-сервер; это самый мощный способ, но приложения должны в значительной степени полагаться на API-сервер.

Как приложения получают информацию от других модулей

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

• Получение данных через сервер API; очень мощный, но увеличивает зависимость от сервера API.

Регистрация и обнаружение службы

В системе K8s обнаружение службы RPC имеет следующие методы:

• Механизм регистрации: записываем IP в центр регистрации, сохраняем соединение с сердцебиением, когда сердцебиение прекращается, удаляем его из центра регистрации;

• Используя Сервис + DNS: Создать новый Сервис, вы можете выбрать набор списков Pod через метки, этот Сервис соответствует неизменному IP-адресу кластера, клиент обращается к IP-адресу кластера через DNS или напрямую. Этот кластерный IP примерно равен реализации балансировки нагрузки (режим iptable);

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

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

Получив IP-адрес или хост сервера, клиент может инициировать запросы http или другого протокола.

Ниже приведены возможные решения, соответствующие Dubbo:

1. Dubbo + Zookeeper pod cluster (HSF+CS cluster)

Это самый простой способ, а сам Dubbo не требует каких-либо модификаций. Проблема в том, что обслуживание Zookeeper увеличено, в то же время это решение не является облачным и не имеет ничего общего с системой K8s.

Мозговой штурм

В приведенной выше схеме в качестве центра регистрации используется ZooKeeper, так можно ли использовать сервис в K8s в качестве центра регистрации? Создайте службу для каждого интерфейса в Dubbo, обновите информацию о конечной точке в процессе запуска каждого экземпляра приложения и установите связь между Службой->Конечная точка->Список IP-адресов.

В этом решении определение службы K8s было преобразовано, и определено слишком много служб, поэтому обслуживание и управление службами представляет собой сложную проблему.

Сценарии на основе K8s

В традиционном домене RPC службы делятся на регистрацию службы и обнаружение службы. В области K8s между модулями и приложениями существует связь один к одному.K8s сам предоставляет возможность поиска модулей, поэтому в определенной степени регистрация службы может не существовать, а требуется только обнаружение службы. Но на самом деле это требует предпосылки:

Dubbo необходимо преобразовать детализацию обнаружения регистрации службы в измерение приложения. > На уровне эксплуатации и обслуживания напишите app=xxx (имя приложения) в метке модуля.

2. Dubbo + K8s DNS

Если служба K8s предоставляет IP-адрес кластера, то Dubbo отвечает только за вызов IP-адреса кластера, а логика маршрутизации и балансировки нагрузки передается для завершения прокси-серверу K8s. Это решение уменьшает основные возможности Dubbo. Далее мы обсудим возможности, предоставляемые безголовым сервисом.

Инициируйте запрос на получение списка IP-адресов, запросив ..svc.. IN A, но он должен постоянно получать обновленный список IP-адресов путем опроса.

Функции, связанные с управлением службами, должны независимо поддерживаться в вышеуказанном разделе управления службами.

Ссылаться на:GitHub.com/Это так особенно/…

3. Dubbo + Api Server

Для приложения Dubbo, развернутого в контейнере Pod, процесс регистрации службы может быть удален напрямую.Функция обнаружения службы взаимодействует с сервером Api, чтобы получить информацию о Pod и службе и одновременно отслеживать изменения модуля и службы. Таким образом, информацию, связанную с управлением службами, также можно получить непосредственно через сервер Api.

4. Dubbo + Istio + Envoy

Dubbo может напрямую использовать указанный ip+port для вызова Envoy из того же модуля (это также может быть Envoy того же узла). Dubbo делегирует Istio и Envoy правила маршрутизации, балансировку нагрузки, автоматические выключатели и другие функции. Envoy должен поддерживать пересылку протокола Dubbo.

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

5. Dubbo + Istio

• Приложения Dubbo больше не полагаются на Envoy как на вспомогательный инструмент, а напрямую взаимодействуют с Istio, используя Istio в качестве реестра и центра конфигурации для управления услугами;
• Dubbo должен предоставить аналогичный протокол xDS и преобразовать экземпляр службы в формат протокола dubbo в пилотной версии;
• Dubbo также необходимо адаптировать к некоторым функциям istio, таким как проверка работоспособности и логика, связанная с безопасностью. Для конкретной реализации, пожалуйста, обратитесь к реализации Envoy.

6. Вариантов сосуществования Dubbo и Istio под системой K8s множество, предлагаю всем на размышление две идеи:

• Вся регистрация служб осуществляется через механизм k8s, а все обнаружение служб осуществляется через службу Headless. В процессе создания коляски необходимо обновить исходный сервис K8s;

• Nacos выступает в качестве регистрационного центра Dubbo и должен частично передавать данные в K8s. Dubbo, зарегистрируйте службу в Nacos в измерении приложения, Istio Pilot необходимо идентифицировать данные Nacos; операционный механизм Istio в основном не изменился, а данные экземпляра службы K8s необходимо записать в nacos для вызова Dubbo.

7. Сосуществование облачных и внеоблачных сред и многокластерных сред в облаке

Istio предоставляет кросс-кластерные решения и решения «облако в облаке», а kubeFed также может играть роль кросс-кластерного решения K8s.

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

Сервисный запрос

Выбросьте три способа, чтобы все подумали.

Дуббо оригинальный способ

Исходный служебный запрос Dubbo предназначен для интерфейсов, и у каждого интерфейса есть номер версии и группа. Имя интерфейса + номер версии + группа определяют уникальный набор услуг. В этом наборе услуг есть соответствующие поставщики услуг и потребители услуг (зависимости на уровне интерфейса). Поставщик услуг — это набор списков IP+портов, а потребитель услуг — это также список групповых IP+портов.

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

Поддерживает только запрос приложения

Подобно Spring Cloud, он поддерживает запросы приложений. После запроса конкретного приложения список ip+port включается в сведения о приложении.Каждый ip+port фактически является экземпляром приложения. Нажмите, чтобы открыть каждый экземпляр приложения, вы можете просмотреть подробную информацию о каждом приложении, включая услуги, предоставляемые экземпляром.

Интерфейс + баланс запроса приложения

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

После нажатия на конкретное приложение в списке приложений он перейдет к сведениям о приложении.

Суммировать

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

Тенденцию использования облачных технологий остановить невозможно, и еще слишком рано говорить о том, какое решение в конечном итоге победит в области RPC. Я верю, что и Service Mesh, и традиционный RPC (Dubbo/gRPC) найдут свое место, пусть время даст нам ответ.

«Официальная учетная запись Alibaba Cloud Native WeChat (идентификатор: Alicloudnative) фокусируется на микросервисах, бессерверных технологиях, контейнерах, Service Mesh и других технических областях, фокусируется на популярных тенденциях облачных технологий, практиках крупномасштабного внедрения облачных технологий и является самый знающий облачный разработчик. Технический публичный аккаунт».