Недавно во время стажировки я столкнулся с самостоятельно разработанной сервисной структурой JSF JD.com, именуемой "Джефф". В настоящее время нижестоящие интерфейсы, вызываемые в некоторых новых функциях, которые я написал, предоставляются Джеффом. Существует много эффективных сервисных фреймворков, таких как Dubbo от Alibaba и ZooKeeper от Apache, так почему же JD разработала собственный сервисный фреймворк JSF? Итак, глядя на историю развития JSF на JD.com, я должен вздохнуть, что хорошая архитектура не может быть достигнута за одну ночь, а развивается постепенно.
1. Комбинация Dubbo и Zookeeper
Dubbo — это высокопроизводительная сервисная платформа с открытым исходным кодом от Alibaba.Dubbo позволяет приложениям реализовывать вывод и ввод сервисов с помощью высокопроизводительного RPC и может быть легко интегрирована со средой Spring. Мы можем взглянуть на дорожную карту архитектуры Dubbo: от архитектуры одного приложения → вертикальная архитектура приложения → архитектура распределенных сервисов → архитектура потоковых вычислений, вы также можете увидеть мою другую статью«Методология разделения услуг»:
Как видно из приведенного выше рисунка, эволюция архитектуры Интернета прошла через архитектуру единого приложения, вертикальную архитектуру приложений, архитектуру распределенных услуг и архитектуру мобильных вычислений. Гранулярность сервисов становится все более и более точной, и несколько сервлетов Tomcat вызывают друг друга, и управление сервисом особенно важно, поэтому отличная архитектура может решить для нас проблему вызовов между сервисами, а также обеспечить высокую доступность, даже достижение Балансировка нагрузки. Так появился фреймворк Dubbo, обеспечивающий три основные возможности: ориентированный на интерфейс удаленный вызов методов, интеллектуальную отказоустойчивость и балансировку нагрузки, а также автоматическую регистрацию и обнаружение сервисов.
Ниже представлена диаграмма архитектуры фреймворка Dubbo:
| узел | иллюстрировать |
|---|---|
| Provider | Поставщик услуг, предоставляющий услугу |
| Consumer | Потребитель службы, вызывающий удаленную службу |
| Registry | Реестр для регистрации и обнаружения служб |
| Monitor | Центр мониторинга, который подсчитывает сервисные вызовы и время вызова |
| Container | работающий сервисный контейнер |
Сначала используйте контейнер Container, чтобы запустить нашего поставщика услуг через Docker. Сам Dubbo не использует никакого регистрационного центра, а использует прямое подключение. Однако на самом деле во многих случаях используется Dubbo + Zookeeper, а zookeeper используется в качестве центра регистрации, и вызывающий абонент службы Comsumer обращается в центр регистрации, чтобы подписаться на услуги, связанные с подпиской. Реестр асинхронно отправит вам Notify список адресов служб, которые нужны потребителям. Потребители будут кэшировать весь список адресов локально, и когда возникнет потребность в бизнесе, они будут использовать адреса в списке адресов для запроса соответствующих сервисных программ. Что касается монитора, как следует из названия, это значение монитора, Потребители и поставщики будут регулярно отправлять монитору количество вызовов службы и количество вызовов. Варианты использования Dubbo и Zookeeper здесь не рассматриваются, вы можете обратиться к«Достаточно статьи в Даббо: от поступления до реального боя».
2. Подходит ли Zookeeper в качестве реестра?
Когда мы задаем вопрос "Подойдет ли Zookeeper в качестве регистрационного центра", первое соображение - это конкретный сценарий использования. Я хочу сказать, что Zookeeper действительно не подходит для JD.com!
Излишне говорить о важности реестра служб, реестр эквивалентен проводнику между поставщиками служб и вызывающими службами.Его роль в управлении службами чрезвычайно важна.Реестр должен быть высокодоступным и обладать высокой стабильностью. Итак, как выбрать реестр сервера? Вот несколько основных моментов, которые следует учитывать в качестве реестра:
- Регистрация службы: Как получить регистрационную информацию
- Подписка на услугу: способ возврата информации о подписке, push или pull
- Обнаружение статуса: определение статуса выживания сервера
Определение статуса особенно важно, потому что, если определение будет неточным, это вызовет неправильную оценку и приведет к серьезным последствиям. Например, Zookeeper строго непротиворечив. Zookeeper выполняет определение статуса в соответствии с временными узлами, зарегистрированными сервером. Если сеть между узлами сервер и Zookeeper прерываются, в результате чего Zookeeper считает, что сервер мертв, и удаляет узел; но на самом деле прямая сеть между клиентом и сервером в порядке, поэтому можно удалить все узлы, в результате чего нет доступных узлы.
Если вы выбираете платформу с открытым исходным кодом, вам также необходимо учитывать:
- Зрелость: включая стоимость обучения, популярность в сообществе, количество документов (слепое преследование не обязательно является наиболее подходящим)
- Стоимость обслуживания: обслуживание реестра
- Структура данных: можно ли быстро найти результат и можно ли его пройти
- производительность и стабильность
- Принцип CAP: CP (согласованность) или AP (доступность)
Давайте сравним два известных мне реестра.
| ZooKeeper | Eureka | |
|---|---|---|
| последовательность | сильная консистенция | слабая консистенция |
| структура данных | Tree | K/V |
| Протокол | TCP | HTTP |
| клиент | ZKClient | Eureka-client |
| принцип ЕСП | CP | AP |
Резюме выбора регистрационного центра:
- Выберите CP для небольшого масштаба, структура RPC может напрямую обращаться к источнику данных.
- Выберите AP для большого масштаба, инфраструктура RPC не может напрямую обращаться к источнику данных.
- Существует кросс-машинный зал, старайтесь не выбирать регистрационный центр с жестким соглашением о согласованности для кросс-региональных
- Платформа RPC должна иметь стратегию аварийного восстановления, при которой реестр недоступен.
- Определение статуса службы очень важно
Поговорив о выборе и характеристиках регистрационного центра, проанализируем, подходит ли Zookeeper в качестве сервисного регистрационного центра в Цзиндуне.Неподходящий. Zookeeper не подходит в качестве реестра в сценариях с высоким трафиком, поскольку Zookeeper не предназначен для обеспечения высокой доступности.
Из-за необходимости аварийного восстановления в компьютерных залах многие системы фактически необходимо развертывать в компьютерных залах. Из соображений рентабельности мы обычно позволяем нескольким компьютерным комнатам работать одновременно, не создавая N-кратное резервирование. Другими словами, один компьютерный зал не может поддерживать полный трафик. Поскольку кластер Zookeeper может иметь только один главный узел, в случае сбоя соединения между компьютерными залами главный узел Zookeeper может заботиться только об одном компьютерном зале, а бизнес-модули, работающие в других компьютерных залах, могут быть остановлены только из-за отсутствия главного узла. . Таким образом, весь трафик концентрируется в компьютерной комнате с мастером, поэтому система выходит из строя.Это основная причина, по которой JD.com потерпел неудачу в Центре регистрации Double Eleven в 2015 году. После перезапуска серверной службы контейнера кэшированный список адресов службы теряется, и служба не может быть вызвана. Более того, Zookeeper не имеет возможности динамического горизонтального масштабирования.Как реестр, Zookeeper называют узким местом в сценариях с высоким параллелизмом, таких как Double Eleven.
Даже в одной аппаратной из-за разных сетевых сегментов иногда возникает изоляция сетевых сегментов при настройке переключателей в аппаратной. На самом деле корректировки сегментов подсети, такие как кратковременная изоляция сети, происходят практически каждый месяц в компьютерном зале. Zookeeper будет недоступен в этот момент. Если вся бизнес-система основана на Zookeeper (например, каждый бизнес-запрос должен обращаться к Zookeeper для получения главного адреса бизнес-системы), доступность системы будет очень хрупкой. Поскольку Zookeeper чрезвычайно чувствителен к сетевой изоляции, Zookeeper бурно отреагирует на любое нарушение в сети. Это увеличивает время сбоя службы Zookeeper, а недоступность Zookeeper приведет к недоступности всей системы.
3. Какова идеальная структура обслуживания
Интерфейс управления документами
Предоставьте запись для управления документами интерфейса и запроса интерфейса, которая может быть общедоступной WIKI или независимой системой и т. д. Здесь вы можете определить документы интерфейса, включая описания интерфейса, определения методов и определения полей. Можно определить SLA интерфейса, включая число поддерживаемых параллелизма и рекомендуемую конфигурацию. Существует также вход некоторых запросов, таких как лицо, отвечающее за интерфейс.
Центр конфигурации
Обеспечьте место для управления конфигурацией. Упомянутая здесь конфигурация в основном относится к некоторой конфигурации, связанной со службой. Конфигурация включает конфигурацию группировки, политику маршрутизации, черный и белый список, переключатель понижения версии, информацию о текущем лимите, время ожидания, количество повторных попыток и т. д. Любые данные, которые можно динамически изменять. Таким образом, поставщики услуг и вызывающие службы могут напрямую вносить изменения в конфигурацию без перезапуска своих приложений. Центр конфигурации может быть независимым от центра регистрации или объединен с центром регистрации.
Центр мониторинга
Служба мониторинга обращает внимание на измерение интерфейса и данные экземпляра (например, экземпляр JVM, в котором он расположен). Платформа RPC может регулярно сообщать о количестве вызовов, затратах времени, исключениях и другой информации. Центр мониторинга может подсчитывать информацию о качестве обслуживания, а также может осуществлять мониторинг и сигнализацию.
Распределенная трассировка
В отличие от центра мониторинга, обслуживание осуществляется в режиме цепочки вызовов. Как естественная скрытая точка распределенной системы отслеживания, структура RPC может хорошо выполнять вывод данных.
Служба управления
Я перечислил здесь общие функции управления услугами, такие как:
-
Маршрутизация услуг:
- Вес: Например, машина с высокой конфигурацией имеет большой вес, а машина с низкой конфигурацией имеет малый вес;
- IP-маршрутизация: например, определенные машины могут настраивать только определенные машины;
- Маршрутизация пакетов: например, автоматическая настройка определенной группы в соответствии с конфигурацией;
- Маршрутизация параметров: например, классификация чтения и записи в соответствии с именем метода или переход к разным узлам в соответствии с параметрами;
- Маршрутизация компьютерного зала: например, ходите только в один и тот же компьютерный зал или предпочтительно в один и тот же компьютерный зал.
-
Авторизация звонков:
- Авторизация приложений: только авторизованные приложения могут вызывать эту группу служб.
- токен: Только пара токенов может настроить эту группу сервисов.
- Черный и белый список: Только разрешенные списком могут настраивать эту группу услуг.
-
Динамическая группировка:
- Группировка на стороне сервера: в зависимости от ситуации с группировкой на поставщике услуг может выполняться планирование динамической группировки;
- Разделение клиентов на группы: групповое планирование может быть выполнено для вызывающего абонента.
-
Ограничение тока вызова:
- Ограничение тока на стороне сервера. Текущее ограничение на стороне сервера основано на модели корзины маркеров или дырявой корзины;
- Текущий лимит клиента: ограничение количества вызовов на основе личности клиента.
-
Развертывание в оттенках серого:
- Оттенки серого онлайн: начните сначала и предоставьте услуги после проверки;
- Идентификатор предварительной версии: указывает, что служба является предварительной службой;
- Тест интерфейса: удобно предоставить функцию тестирования функции автоматизации интерфейса.
-
Понижение службы:
-
Mock: в случае отклонения от нормы или тестовой ситуации вернуть фиктивные данные;
-
Предохранитель: тайм-аут клиента или тайм-аут сервера;
-
Отказ в обслуживании: когда сервер находится под большой нагрузкой, он автоматически откажет в обслуживании, чтобы защитить себя.
шлюз
-
Большинство сценариев фреймворка RPC вызываются сами собой Когда нужен шлюз?
Шлюз может выполнять следующие функции:
- Единая служба аутентификации;
- Токоограничивающие услуги;
- Преобразование протокола: внешний протокол в единый внутренний протокол;
- Mock: тестирование сервиса, даунгрейд и т. д.;
- Некоторая другая унифицированная логика обработки (например, разбор запросов, упаковка ответов).
4. Итерация JSF JD.com
Прототип JSF — ASF
Сначала JSF назывался ASF, и в то время выбор был следующим:
- Структура RPC: на основе dubbo2.3.2 для расширения конфигурации и расширения функций, включая: отдых (resteasy), веб-сервис (cxf), сериализацию kryo/thrift, сжатие вызовов и т. д.;
- Центр регистрации: Zookeeper, инфраструктура RPC напрямую обращается к источнику данных;
- Центр мониторинга: сервис мониторинга + HBase;
- Платформа управления: читайте Zookeeper как платформу управления, предоставляющую основные функции, такие как онлайн и офлайн, черные и белые списки и т. д.
Текущий состав JSF
Текущий JSF почти полностью разработан самостоятельно.
- Фреймворк RPC: облегченный, с лучшей производительностью, совместимый со старыми версиями протокола;
- Центр регистрации: на основе БД в качестве источника данных, служба предварительного индексирования, поддержка десятикратного объема доступа, часть логики размещается в центре регистрации, чтобы уменьшить нагрузку на клиента;
- Центр мониторинга: служба мониторинга прокси + InfluxDB (после 2015 г. заменена на ElasticSearch);
- Терминал управления: основанный на БД, он имеет более мощные функции и предоставляет полные функции управления управлением услугами, открывает платформу управления приложениями Jingdong и обеспечивает сортировку зависимостей приложений;
- HTTP-шлюз: на основе Netty он поддерживает межъязыковые вызовы.
Текущий JSF основан на окончательной согласованности данных, сделанных БД, то есть системой AP. Центр регистрации в основном реализует такие функции, как регистрация и подписка на список услуг, получение и распространение конфигурации услуг, а также просмотр статуса услуги в режиме реального времени. Узлы реестра не имеют состояния и масштабируются по горизонтали. Все точки реестра во всем кластере реестра эквивалентны.
Оптимизация и функции JSF
-
Познакомить с концепцией службы индексирования: эта служба является простейшей службой HTTP, которая используется для поиска узла центра регистрации (тот же компьютерный зал или наименьшая нагрузка или другие специфические сценарии), которую можно рассматривать как службу, которая не будет зависать, и инфраструктура RPC будет отдавать приоритет этой службе.Адрес реестра, преимущество этого в том, что после изменения адреса реестра инфраструктуре RPC не нужно изменять какие-либо настройки;
-
В реестре есть полный кеш списков сервисов, и он гарантированно доступен для чтения, даже если он не подключен к базе данных;
-
Структура данных базы данных больше подходит для отображения различных измерений, фильтрации, анализа и т. д., например, в соответствии с различными измерениями, такими как группировка/IP/приложение/компьютерный зал;
-
Центр регистрации — это сервис JSF, и он может динамически расширяться по горизонтали при отслеживании давления, и не будет аварий, подобных Double Eleven в 2015 году;
-
Улучшение логики отправки списка услуг: например, исходные 100 провайдеров теперь добавляют 1 узел, предыдущий SAF должен доставить 101 узел, определить, какой узел добавлен, и установить длинную ссылку; текущее улучшение: изменить его для доставки событие add сообщает инфраструктуре RPC добавить узел, а инфраструктура RPC устанавливает длинную ссылку, что значительно уменьшает объем передаваемых данных;
-
Реестр и инфраструктура RPC могут взаимодействовать различными способами: реестр и инфраструктура RPC представляют собой длинные ссылки, а JSF поддерживает обратный вызов. конфигурация, и настроить волосы и так далее.