Многолетний опыт Huawei: исследование и мышление ServiceComb в области Service Mesh

задняя часть Микросервисы Архитектура Go
Многолетний опыт Huawei: исследование и мышление ServiceComb в области Service Mesh

Источник контента:27 июня 2018 г. Тянь Сяолян, архитектор микросервисов Huawei, поделился речью на тему «Мысли и практика ServiceComb ServiceMesh в облаке Huawei» на «Семинаре по микросервисам LC3 | Углубленная интерпретация ServiceComb». IT big coffee сообщил, что как эксклюзивный видео-партнер, он был выпущен с разрешения организатора и спикера.

Количество слов для чтения:3606 | 10 минут чтения

Посмотрите видео с гостевой речью и PPT,Пожалуйста, нажмите:t.cn/E2vZBkB

Резюме

Сегодня мы сосредоточимся на трех темах. Во-первых, мы поговорим о многолетней практике Service Mesh в Huawei. Кроме того, мы представим некоторые практические методы. Наконец, мы представим несколько кейсов, чтобы показать вам, как мы помогаем предприятиям. на практике Используйте Service Mesh в производственной среде.

Внутренняя эволюция Huawei

На самом деле, когда мы делаем микросервисы, нам приходится решать множество сложных проблем, вызванных микросервисной архитектурой, в течение всего процесса эволюции. Я лично реализовал Go-версию микросервисного фреймворка с открытым исходным кодом. Этот фреймворк имеет около 20 000 строк кода и доставляется в бизнес. Этот процесс занимает много времени. На самом деле у обычных компаний нет сил, чтобы поставить. , и разработчикам может потребоваться некоторое время, чтобы привыкнуть к фреймворку.

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

На самом деле это можно рассматривать так: раньше приложение работало поверх tcp ip, но теперь эти сервисы работают в сервисной сети Service Mesh, и этот процесс не требует каких-либо модификаций исходного кода.

На самом деле в Huawei уже давно много практики. В 2013 году был реализован компонент IR в платформе разработки микросервисов.Он имеет внутренний маршрут на каждом узле.Все приложения на этом узле развертываются платформой.После развертывания компонент под названием RouterAgent регистрирует приложение на платформе.На zookeeper , в то же время RouterAgent обновит таблицу маршрутизации в IR, чтобы можно было выполнить обнаружение.

Вся связь между приложениями осуществляется через Router, но реализована она nginx, поэтому есть несколько минусов. Во-первых, когда узел зависает, все приложения на узле не могут входить и выходить, и связи нет. Кроме того, масштабируемость ограничена, а экология языка не так хороша, как у языка Go Java.

В 2015 году мы сделали еще один компонент под названием sidecar, который также является компонентом большого фреймворка. Его принцип на самом деле очень похож на текущую Service Mesh.Он использует возможность нескольких контейнеров в одном модуле kubernetes.Один контейнер предназначен для бизнеса, а другой контейнер является sidecar. Все сервисные запросы должны быть отправлены и получены через sidecar, вообще говоря, эти сервисы являются HTTP-сервисами. На самом деле sidecar тоже имеет некоторые свои недостатки.Например он разработан на Java.Как мы все знаем виртуальная машина Java очень ресурсоемкая.Теперь каждому микросервису нужно иметь виртуальную машину,что в общем-то не так. достаточно ясно, поэтому коляска на самом деле не соответствует лучшим практикам Service Mesh.

Mesher

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

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

На картинке выше показана подробная архитектура Mesher. Та, что выше, представляет собой панель управления, которая поддерживает различные экосистемы, такие как -ServiceComb, Istio, Zipkin и т. д. Самая большая разница между ней и популярной в настоящее время платформой ECU заключается в том, что она может поддерживать гетерогенную инфраструктуру без привязки. развертывается в облаке, на «голом железе» и на виртуальной машине.

Зарегистрируйтесь, чтобы узнать

Такова структура нашего обнаружения регистрации.Он создает две абстракции, одна из которых называется регистратором, а другая называется обнаружением службы. Преимущество этого заключается в том, что он может поддерживать обнаружение регистрации на стороне клиента, а это означает, что если у вас нет такой платформы, как kubernetes, вы можете зарегистрироваться самостоятельно. Зарегистрируйтесь в Центре обслуживания самостоятельно, а затем используйте Service Discovery для обнаружения. При использовании такой платформы, как ECU, поскольку они помогут вам автоматически поддерживать жизненный цикл, в настоящее время нет необходимости самостоятельно регистрироваться или поддерживать пульс.В настоящее время вы можете выбрать запуск только одного обнаружения служб для адаптации к эта платформа., которая очень гибкая.

Управление маршрутами на основе метаданных микросервиса

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

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

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

Архитектура сервисного центра ServiceComb строго запрещена.

Это эволюция архитектуры Service Center, которую мы позже продвигали. Прежде всего, мы абстрагировали слой адаптера, чтобы адаптироваться к различным открытиям регистрации. Как это сделать, на самом деле, потому что центр обработки данных будет становиться все больше и больше, и мы думаем, что любой вид облака на самом деле Все ненадежны. Поэтому позже мы построили собственный частный облачный центр, а затем создали гибридное облако.Чтобы способствовать развитию архитектуры Service Centere, мы также надеемся, что он сможет поддерживать несколько облаков. В дополнение к этому значению он также может поддерживать гетерогенность, например, смешивание VM и K8S, позволяя вам видеть все центры обработки данных и микросервисы на всех гетерогенных объектах в одном месте.

комплексное решение

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

Истио Экология

Еще одна наша стратегия — использовать экосистему Istio с точки зрения открытого исходного кода. В отличие от других мест, мы интегрируем в Istio среду разработки шасси go. Одним из преимуществ этого является то, что это может повысить общую производительность службы. Потому что по сути решение Service Mesh является сервисным прокси, поэтому все данные запроса будут иметь процесс от пользователя к ядру, а потом от ядра к пользователю Весь процесс умножается на два, так что производительность фактически будет be Существует сокращение, и некоторые пользователи, чувствительные к производительности, могут быть склонны использовать навязчивые фреймворки. А Istio как раз предоставляет решение Service Mesh, поэтому мы привнесли шасси go в Istio, а также привнесли в него Mixer, который стал альтернативой data plane.

Случай пользователя

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

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

Дорожная карта технологии Mesher

Это технический маршрут Mesher.Фактически, мы выпустили первую Service Mesh коммерческого уровня в Китае в ноябре 2017 года, основываясь на нашем прошлом опыте в микросервисах и работе, аналогичной Service Mesh, выполненной несколько лет назад. Позже мы провели несколько итераций, и в ходе итераций этого года мы также помогли многим компаниям запустить Service Mesh в производство.

Одной из главных особенностей этого года является поддержка протокола GRPC и помощь пользователям в быстром внедрении Mesher в свою среду k8s. В будущем мы будем в основном связываться с SQL и сообществом открытого исходного кода.

Выше содержание сегодняшнего обмена, спасибо всем!