Я поделился им на конференции Gopher 2020 и записал основное содержание для справки после публикации.
Huawei создала Cloud BU в 2016 году и представила такие проекты CNCF, как kubernetes и prometheus. Большинство этих программ написаны на языке Go, и команда R&D, естественно, начала внедрять язык Go для создания облачных сервисов.Однако в то время экология Go не была идеальной, поэтому необходимо было с самого начала писать модули базовых возможностей. до конца для внедрения различных облачных приложений.
Сначала посмотрите на его процесс реализации из простого облачного приложения.
Простая служба регистрации и обнаружения, Service Center, аналогична eureka, и ее обязанности здесь не повторяются.
Динамическое и статическое разделение
Чтобы уменьшить объем информации о данных, публичная часть извлекается для унифицированного управления, а атрибуция экземпляра делится на статическую информацию. Таким образом, микрослужба и экземпляр микрослужбы представляют собой сопоставление 1-к-n, а имя микрослужбы, версия, описание и другая информация извлекаются в общедоступную часть, а сетевые накладные расходы снижаются за счет сокращения избыточности, такой как «описание», например информация не передается в сети, и в то же время может учитывать возможности управления микросервисом и стандартизировать модель микросервиса. Например, микросервис должен иметь информацию о версии. Однако на самом деле в кеш микросервиса отправляется гораздо меньше информации об экземпляре, многие поля предназначены для просмотра людьми, а не для машинного исполнения.
На рисунке видно, что статическая информация микросервиса содержит схему, связанную с документом контракта, связанным с микросервисом, который также является отношением отображения 1-к-n. Документы могут быть загружены вручную или автоматически сгенерированы кодом.Документы микросервиса можно просмотреть в реестре, и документы привязаны к номеру версии микросервиса.После загрузки изменения не допускаются. Так зачем же ставить документацию на первое место?
Неправильный путь: команда разработки клиента ждет, пока будет написана серверная служба, прежде чем начинать разработку интеграции.
Правильный способ: на основе документа клиент и сервер разрабатываются одновременно, и клиент использует mock для удаления зависимости от сервера.
Кроме того, если документация не будет рассмотрена своевременно, могут произойти очень плохие вещи. Например, непоследовательные соглашения об именах, похожие определения API и плохая масштабируемость — любое из этих обстоятельств значительно увеличивает затраты на НИОКР. Важное значение имеет раннее обнаружение и предотвращение. Вот почему в реестр добавлены возможности загрузки документов и запросов.
Межсервисное управление зависимостями
Слишком высокий уровень вызовов вызовет трудности с позиционированием и снижение производительности. Разумным уровнем является то, что 3 вызова сервисов a->b->c могут завершить один вызов.
Двум службам, которые зависят друг от друга, потребуется больше времени для анализа влияния обновления или изменения функции. Например, ab и ab зависят друг от друга, а новая функция включает в себя два изменения, так как же они могут работать в сети одновременно?
Также простые зависимости облегчают тестирование и анализ системы. Это дает архитекторам хороший способ взглянуть на зависимости между микросервисами и вовремя внести коррективы в архитектуру.
механизм кэширования
В самом Сервисном центре нет постоянных данных. Если у etcd произойдет сетевой сбой, Сервисный центр будет недоступен. Однако для достижения высокой доступности etcd требуется 3 разных компьютерных зала, например, узлы 2, 2 и 1 распределены по 3 центрам обработки данных, что, очевидно, стоит дорого.
Мы должны использовать мягкие средства, чтобы уклониться и получить определенную надежность. Поэтому Service Center вводит механизм асинхронного кэширования, в начале запуска Service Center будет устанавливать длительное соединение с etcd, то есть смотреть. Чтобы предотвратить изменение установленного временного окна просмотра, каждый раз, когда производится просмотр, создается уровень защиты, и перед просмотром выполняется полный объем запросов. Во время запущенного процесса изменения ресурсов, полученные по запросу, будут кэшироваться локально в Центре обслуживания, а затем выполняться асинхронный цикл, который не только повышает доступность при низких затратах, но и повышает производительность.
Реализация Консула - это фактически интеграция вычислений и хранения, а не разделение. Я думаю, что объем бизнеса не увеличился. Такая архитектура имеет низкие затраты на эксплуатацию и обслуживание и является хорошим выбором. Однако может ли она поддерживать более крупные микросервисы. ? Сумма под вопросом, поэтому я одержим разделением вычислений и хранения и практики.В то же время сервисный центр поддерживает встроенный etcd, что означает, что он также поддерживает интеграцию вычислений и хранения, чтобы помочь вы снижаете затраты на управление на ранней стадии.
Резюме: мы использовали различные средства для повышения эффективности исследований и разработок микросервисов, снижения нагрузки на сеть и повышения производительности и надежности за счет асинхронного кэширования.Эти возможности мы накопили в этом сервисе. Это делает компонент обнаружения регистрации более удобным для технических менеджеров, что может помочь архитекторам постоянно улучшать архитектуру и управлять ею. Однако облачные приложения выходят далеко за рамки предоставления бизнес-функций.
То, что мы только что видели, — это айсберг над водой, и под айсбергом скрыто множество базовых способностей, которые нужно написать. Начнем с архитектуры Сервисного центра
центр обслуживания облачных сервисов
Этот компонент в основном отвечает за регистрацию и обнаружение микросервисов и предоставляет API-интерфейсы для отдыха.
Он состоит из четырех основных модулей:
-
Обнаружение регистрации службы: полная осведомленность о топологии службы посредством обнаружения регистрации
-
Обнаружение контракта: у каждой службы есть запись контракта, поддерживающая несколько форматов, таких как Open API, прототип gRPC.
-
RBAC: управление доступом на основе ролей, администраторы могут управлять учетными записями и распределять учетные записи между микросервисами или разными людьми.
-
Управление службами: вводите правила управления для микрослужб, такие как повторные попытки, ограничение тока, автоматический выключатель, политика маршрутизации и т. д.
Предоставление облачных услуг — это гораздо больше, чем предоставление бизнес-функций, но при этом необходимо учитывать все аспекты безопасности, отказоустойчивости, конфиденциальности, возможностей O&M и т. д. Конечно, мы можем передать некоторые возможности некоторому промежуточному программному обеспечению, например шлюзам. Однако по-прежнему существует множество функций, которые необходимо написать сами по себе и которые можно повторно использовать в каждом микросервисе.Это первоначальный замысел написания базовой библиотеки возможностей.
-
Управление квотами: облачные ресурсы управляются в соответствии с квотами арендаторов, а ресурсы, которые могут использовать арендаторы, строго ограничены.
-
Оповещение: когда в микросервисе возникает критическая проблема, о ней следует сообщать напрямую в систему оповещения, а не устанавливать политики оповещений, такие как пороговые значения, через облачные сервисы.
-
Безопасность: сертификаты шифрования и дешифрования, пароли
-
Генерация идентификатора: алгоритм генерации идентификатора для создания идентификаторов микросервисов, идентификаторов экземпляров и т. д.
-
Разнообразный middleware: процесс звонка нужно аудировать, цепочку звонков отслеживать, генерируемый индикатор отслеживать и т.д.
адрес проектаGitHub.com/Apache/CailV…
Для этих возможностей недостаточно извлечь обычные библиотечные функции, такие как гибридное облако, общедоступное облако и проекты с открытым исходным кодом, поэтому должны быть достигнуты следующие возможности:
-
Подключаемый: то есть он вводится во время компиляции по мере необходимости (ограничен возможностями языка go), например, конкретная реализация системы квот не нужна в сообществе
-
Гетерогенная система: то есть функция должна иметь несколько конкретных реализаций, таких как аудит.В общедоступном облаке есть система аудита, которую необходимо подключить, в то время как сообщество печатает локальный журнал.
-
Разные алгоритмы: инструменты дешифрования, генераторы идентификаторов, разные сценарии доставки или требования безопасности — все они должны заменить алгоритмы разными реализациями. Например, генерация идентификатора может быть снежинкой, UUID. Используемые алгоритмы шифрования и дешифрования — AES или другие общедоступные алгоритмы. Вы также можете рассмотреть алгоритм ядра с закрытым исходным кодом, а затем написать простой алгоритм в виде нового плагина и открыть его вместе со всем проектом, чтобы сообщество могло помочь улучшить периферийные возможности и защитить конкурентоспособность своего коммерческого продукта. версия
Платформа разработки шасси Go
Как мы должны столкнуться
-
Подключаемый: вводится во время компиляции по мере необходимости.
-
Гетерогенные службы: фоновая служба может иметь несколько конкретных реализаций.
-
Разные алгоритмы: инструменты дешифрования, генераторы идентификаторов, разные сценарии доставки или требования безопасности — все они должны заменить алгоритмы разными реализациями.
-
Распределенными системами трудно управлять: фреймворки могут помочь с облачными приложениями, как реализовать такой фреймворк
Чтобы быть в состоянии справиться с разнообразием требований, и все вновь запланированные компоненты также могут извлечь выгоду из быстрой разработки, нам нужна унифицированная структура и стандарты для ускорения разработки, что является процессом рождения платформы разработки Go шасси.
Из рисунка видно, что бизнес-логика — это бизнес-код, написанный пользователем, затем сам фреймворк — это уровень протокола, средний уровень и набор подключаемых модулей, а часть управления — это облачный сервис. Разработанная инфраструктура может использоваться без восприятия этих облачных возможностей. Например:
-
Зарегистрируйтесь и узнайте, что плагин может подключаться к сервисному центру и кубенетам.
-
Плагин управления квотами можно подключить к сервису управления квотами облачных сервисов.
-
ПО промежуточного слоя, такое как стыковка мониторинга индикаторов с prometheus
Итак, как мы можем ускорить нашу разработку с помощью этой структуры.
Подход 1. Используйте серверную службу в качестве плагина
общий бэкенд
-
Управление квотами
-
Служба аутентификации и аутентификации
-
Служба хранения объектов
Одним из элементов облачных технологий является обращение с серверными службами как с дополнительными ресурсами. Как определить, что считать внутренним сервисом, то есть те сервисы, которые не разрабатываются и не эксплуатируются вашей собственной организацией, от среды выполнения приложения до невидимого для инфраструктуры бессерверного API-сервера, для вас это черный ящик оказание услуг.
Когда мы называем эти серверные сервисы, они на самом деле не входят в систему управления микросервисами.Учитывая тестируемость (например, фиктивное тестирование) и заменяемость (бизнес может быть непрерывным, а более качественные сервисы могут быть заменены в любое время, необходимо иметь дело с изменениями в требованиях и т. д.), нам нужно подключить их, чтобы гибко выбрать замену или удаление.
После разработки вашего плагина и его установки в фреймворк вы можете подтянуть его и вызвать по конфигурации.
Подход 2: предварительное определение базового уровня спроса
Прежде чем мы сможем предоставлять какие-либо услуги, нам необходимо выполнить основные требования, такие как:
-
Тело запроса должно быть ограничено по размеру
-
API должен быть ограничен
-
Пароли нельзя хранить в открытом виде
-
Доступ для аутентификации
-
Нет единой точки отказа
-
аудит доступа
-
Возможности эксплуатации и обслуживания
Затем мы должны сначала стандартизировать вызов среды выполнения, поскольку у разных отделов могут быть требования к частному протоколу, а затем управление службами передается основной структуре для завершения. Бизнес-подразделение самостоятельно разрабатывает или интегрирует существующие протоколы. Когда вы обнаружите, что разные отделы внутри компании разрабатывают свои собственные протоколы для управления собственными службами, будет очень сложно объединить бизнес в одну архитектуру и одну цепочку инструментов.
Мы используем модель вызова для нормализации непротоколов, чтобы их можно было обрабатывать в единой цепочке обработки.
Дизайн цепочки обработки аналогичен идее АОП, то есть добавление логики кода до и после бизнес-обработки для специальной обработки, такой как аудит пользовательских операций и сбор данных индикатора запроса.
ResponseCallBack используется для принятия результатов, возвращаемых последующими обработчиками, поэтому каждый обработчик может определить свой собственный ResponseCallBack по мере необходимости для получения результатов выполнения последующих обработчиков или даже кода бизнес-логики. Помогает полностью разделить общую логику (т.е. промежуточное ПО) и бизнес-логику.
Вы можете взглянуть на промежуточное ПО, которое поддерживается сейчас.Независимо от текущего лимитирования, слияния, балансировки нагрузки, проверки подлинности и проверки подлинности, а также аудита, мы используем этот механизм для реализации: всей цепочки инструментов компании, методов управления услугами, соблюдения требований безопасности. и т. д. В цепочке обработки скорость исследований и разработок может быть быстро увеличена, а стандартизация может быть унифицирована для снижения нагрузки на управление.
Платформа предоставляет возможности императивного вызова, такие как сбор индикаторов, что является типичной возможностью.Она также предоставляет декларативные методы использования, такие как управление трафиком, и текущие возможности ограничения на основе характеристик трафика.Декларативное использование также поддерживает канареечную публикацию.
Панорама возможностей плагина:
Видно, что поддерживается множество экосистем, а для различных серверных систем предоставляются абстрактные интерфейсы, помогающие приложениям быстро развиваться.
Затем с помощью такой структуры мы можем позволить бизнес-команде сосредоточиться на разработке бизнес-кода, не понимая сложности серверной части и других нефункциональных требований. Преимущества заключаются в следующем
-
Пробное тестирование может быть выполнено для огромных систем, чтобы улучшить качество доставки.
-
Работа с различными сценариями доставки
-
Гарантированная заменяемость серверной части
-
Разделение интерфейса ответственности НИОКР
С точки зрения архитектуры или развития бизнеса, технологии, используемые в серверной части, развиваются быстро.Нам необходимо обеспечить, чтобы системы и продукты могли развиваться во времени за счет быстрой замены серверных услуг, поэтому дизайн интерфейса должен считаться. . Заменяемость важнее возможности повторного использования. Это также удовлетворяет инверсии зависимостей принципов программирования, когда мы разрабатываем новый микросервис, нам нужно только реализовать его бизнес-логику.
Подход 3: управление конфигурацией
прямая ссылкаGitHub.com/go-chassis/…
Подход 4: удобство использования
Это означает, что они могут быть включены или выключены мгновенно. Мы не будем здесь говорить о быстром старте, потому что язык go + docker runtime и контейнерная платформа могут справиться с таким сценарием, мы говорим о неожиданной обработке.
Этот протокольный сервер обычно представляет собой протокол, или это может быть определенная модель программирования, такая как http, модель программирования, такая как beego, gin имеет пример конфигурации фреймворка, что означает, что два порта http и служба портов grpc
После получения системного сигнала он будет проходить и останавливать каждый сервер
Кроме того, пользовательская функция плавного отключения, предоставленная разработчиками сообщества, может позволить пользователям перехватывать процесс обработки сигнала и отключения, а также настраивать процесс обработки до и после.
Подход 5: облегченные ядра
По сути, есть только необходимые библиотеки prometheus, opentracing, jwt, k8s client и go-restful. Обнаружение регистров также является подключаемым.
Различные возможности предоставляются в другом репозитории в виде ряда расширений. Например, протокол grpc, реестр kubernetes и т. д. могут быть введены по запросу. Расширение chrome, к которому относится имя.
Мы можем построить такое легкое ядро благодаря трехзубчатому топору, который также является основной концепцией шасси go:
-
Промежуточное ПО: цепочка обработчиков обрабатывает запросы
-
bootstrap: произвольная замена реализации и логики выполнения по умолчанию
-
Подключаемый: Произвольная замена бэкэндов и реализаций.
Собственные восстановленные колеса
Именно это и хотят передать название и логотип платформы разработки ходовых шасси, шасси есть шасси. Логотип выполнен в виде шины.
Мы часто слышим, как люди изобретают велосипед, а другие критикуют его. Я думаю, это потому, что открытая конструкция существующей схемы все еще недостаточна, и каждая команда внедрила слишком много проектов или проектов в период разработки проекта.Тень бизнеса заставляет всех повторять изготовление собственных колес.
Мы должны описать и внедрить более абстрактную и определенную парадигму и создать возможности на основе этого шасси. Вы представляете и улучшаете это самое оригинальное колесо, чтобы сделать его более подходящим для вас.Хотите ли вы колесо для бездорожья или снега, вы можете сделать и отрегулировать его самостоятельно. Мы абстрагируем возможности, накопленные нашей командой R&D, в множество интерфейсов и плагинов, чтобы не повторять изготовление колес, а перестраивать на основе существующих колес, чтобы продукты проекта работали быстрее, а все расширенные функции родные совместимы. Это самое большое улучшение производительности для команды R&D. В настоящее время я предпочитаю называть это колесо колесом разработки облачных сервисов, что очень подходит для нашей команды, занимающейся облачными сервисами. Вы можете увидеть это из следующего примера.
кейс
Фон видеовызова для таких терминалов, как мобильные телефоны Huawei Honor и смарт-экраны
Публичное облако Huawei было запущено, поддерживая терминальную компанию Changlian Call с сотнями миллионов зарегистрированных пользователей и управление услугами на основе шасси и сервисного центра.
граничные вычисления
§ Разработать базу управления услугами на базе go-шасси
§ Управлял почти 100 000 пограничных узлов в 29 провинциях и автономных регионах по всей стране и развернул более 500 000 пограничных приложений. Он поддерживает непрерывную настройку и обновление процесса сбора информации о портальных станциях на более чем 10 000 пунктов взимания платы и обеспечивает ежедневный сбор более 300 миллионов единиц информации.
§ Обеспечивает хорошую поддержку платформы для развития инновационного бизнеса, такого как сотрудничество между автомобилем и дорогой и автономное вождение в будущем.
GitHub.com/crying be edge/crying…
Shoppe
Эта конференция Gopher также пригласила Shopee рассказать об использовании ходового шасси на их платформе цепочки поставок. Вы можете обратиться к их совместному использованию
Суммировать
1. Определите свой протокол связи для разработки приложений Компания, две очень важные вещи Корпоративная культура и кодекс поведения, это две вещи, которые лидеры каждой компании должны определить в первую очередь, это «протокол связи», гарантирующий, что компания работает хорошо. Таким образом, лидеры не должны быть практическими. Очевидно, очень важно определить набор коммуникационных «протоколов». Шасси Go — это протокол связи нашей команды Go R&D. Каждый микросервис разрабатывается небольшой командой, которая может быть одной командой или разными командами.Мы создали структуру, чтобы определить этот набор протоколов связи, чтобы снизить стоимость исследований и разработок, принимая во внимание масштабируемость. Не иметь переходных ограничений на разработку. Сначала мы стандартизируем API для проверки дизайна API, полагаемся на руководство для проверки разумных отношений обслуживания и предусматриваем, что все возможности должны быть реализованы в виде подключаемых модулей и промежуточного программного обеспечения и т. д., чтобы определить «протокол связи» для разработки и управления облаком. услуги команды R&D.
2. Роль Go в новой инфраструктуре Мы все знаем, что эпоха 5g позволяет подключать больше устройств.Мы видим, что первое поколение эволюции Интернета — это эпоха взаимосвязи ПК, второе поколение — мобильные телефоны, а третье Поколение — это Интернет всего, а устройства меньшего размера неизбежно приведут к новым полупроводникам, новым операционным системам (таким как Hongmeng от Huawei), а это неизбежно потребует нового языка и соответствующего фреймворка. Сам язык go для этого очень подходит. не буду здесь распространяться об этом, потому что все также знают сцену, для которой подходит сам язык го. Распределенным устройствам также нужна структура для управления, и шасси Go будет играть здесь важную роль. Скорее всего, он станет базой разработки в области инфраструктуры, что видно по использованию шасси go для kubeedge, видеооблака и других проектов.
Приглашаем всех принять участие в сообществе, адрес проекта с открытым исходным кодом:
Приглашаю всех оставить сообщение и сказать мне, какую часть углубленного анализа мне нужно расширить.
Если вы найдете мой контент полезным, пожалуйста, добавьте звезду в наш сервисный центр проекта и перейдите на шасси, спасибо.
Добро пожаловать, чтобы отсканировать код и подписаться на мой личный номер подписки