1. Введение

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

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

2. Услуги

2.1 Зачем нужны услуги

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

архитектура единого приложенияКогда трафик веб-сайта невелик, требуется только одно приложение, и все функции развертываются вместе, чтобы уменьшить количество узлов развертывания и затраты. В настоящее время этот метод используется для упрощения работы по добавлению, удалению, изменению и проверкеПлатформа доступа к данным (ORM)это ключ.
Вертикальная архитектура приложенийКогда количество посещений постепенно увеличивается, ускорение, вызванное добавлением одного приложения к машине, становится все меньше и меньше, и приложение делится на несколько приложений, которые не связаны друг с другом для повышения эффективности. На данный момент используется для ускорения разработки страниц интерфейса.Веб-фреймворк (MVC)это ключ.
Распределенная сервисная архитектураКогда вертикальных приложений становится все больше, взаимодействие между приложениями становится неизбежным, основной бизнес выделяется как самостоятельный сервис, и постепенно формируется стабильный сервисный центр, чтобы фронтенд-приложения быстрее реагировали на меняющиеся запросы рынка. В настоящее время он используется для улучшения повторного использования и интеграции в бизнесе.Платформа распределенных служб (RPC)это ключ.
Архитектура мобильных вычисленийКогда сервисов становится все больше и больше, постепенно появляются такие проблемы, как оценка емкости и растрата небольших сервисных ресурсов, необходимо добавить диспетчерский центр для управления емкостью кластера в режиме реального времени на основе давления доступа для улучшения использования кластера. В настоящее время для улучшения использования машиныЦентр планирования ресурсов и управления (SOA)это ключ.

Платформа растет вместе с бизнесомИз среды «Все в одном»Это может удовлетворить потребности бизнеса (в Java это может быть решено только одним или двумя военными пакетами);Чтобы разделить несколько приложений и принять способ MVCРазделение фронтенда и бекенда для повышения эффективности разработки; когда разрабатывается все больше и больше сервисов, нам приходитсяНекоторые основные или общие службы разделены, обеспечение мониторинга потока и вычислений в реальном времени и т. д. На самом деле, на данном этапе, если служба достаточно тонко разделена и работает независимо, это, по крайней мере, может быть возможно в это время.Поймите это как архитектуру SOA (сервисно-ориентированная архитектура)..

2.2 Проблемы, связанные с услугами

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

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

Несколько методов передачи вызова: метод HTTP, метод WebService;

Зависимости вызова службы: ручные записи, анализ кода просмотра;

Мониторинг производительности вызова службы: ведение журнала, время просмотра вручную;

Тесно связанный сервис и приложение: сервис зависает, а приложение невозможно использовать;

Конфигурация загрузки сервисного кластера: Конфигурация Nginx, есть одна проблемная точка;

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

Поддержка текущих потребностей бизнеса, это самое основное условие;

Сервис позволяет избежать проблем с одной точкой и является децентрализованным;

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

Обобщение обслуживания, поддержка разнородных системных вызовов;

Самообслуживание и визуализация сервисных зависимостей;

Самостоятельная статистика и визуализация мониторинга производительности сервиса;

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

Разработчики уделяют большое внимание, быстро приступают к работе, просты и легки, с минимальным вмешательством;

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

2.3 Будущие тенденции услуг

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

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

Микросервисы более совершенны, чем SOA, микросервисы существуют больше в виде самостоятельных процессов и никак не влияют друг на друга;

Интерфейс, предоставляемый микросервисами, более общий., такие как метод HTTP RESTful, который может вызываться различными терминалами, независимо от ограничений языка и платформы;

Микросервисы, как правило, более распределены и децентрализованы., что больше подходит для сценариев интернет-бизнеса;

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

Функции	SOA	Микросервисы
размер компонента	куски бизнес-логики	Отдельные задачи или небольшие кусочки бизнес-логики
связь	Обычно слабо связаны	всегда слабо связаны
структура компании	любой тип	Небольшие межфункциональные команды
управлять	Сосредоточьтесь на централизованном управлении	Сосредоточьтесь на децентрализованном управлении
Цель	Убедитесь, что приложение может взаимодействовать	Внедряйте новые функции и быстро увеличивайте команду разработчиков

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

3. Рамки

В настоящее время в отрасли существует множество зрелых сервисных фреймворков, таких как Hessian, CXF, Dubbo, Dubbox, Spring Cloud, gRPC, thrift и другие технические реализации, все из которых можно вызывать удаленно. , пожалуйста, обратитесь к следующему анализу, который также специфичен для технологии. Важной основой в процессе выбора программы.

3.1 Сравнение сервисных фреймворков

DubboЭто высокопроизводительная и превосходная сервисная платформа Java с открытым исходным кодом от Alibaba, которая позволяет приложениям реализовывать функции вывода и ввода сервисов с помощью высокопроизводительного RPC и может быть легко интегрирована со средой Spring. Тем не менее, немного жаль, что говорят, что внутри Taobao у dubbo есть конкурентные отношения с другим подобным фреймворком HSF (не с открытым исходным кодом) на Taobao, поэтому команда dubbo была распущена, но вместо этого это расширенная версия Dangdang.comDubboxОн все еще развивается и цветет внутри стен и благоухает снаружи стен. Некоторые другие известные компании электронной коммерции, такие как Dangdang и Gome, поддерживают свои собственные филиалы или разрабатывают на основе dubbo, но официальные библиотеки не поддерживаются, а связанные с ними зависимости, такие как Spring и Netty, все еще являются очень старыми версиями (Spring 3.2. 16.RELEASE, netty 3.2.5.Final), но некоторые пользователи сети написали плагины для обновления Spring и Netty.

DubboxПо сути, это то же самое, что и Dubbo. Значение названия расширяет Dubbo. Следующие расширенные функции также являются важными моментами для рассмотрения при выборе Dubbox.

Поддержка удаленного вызова в стиле REST (HTTP + JSON/XML);

Поддержка эффективной реализации сериализации Java на основе Kryo и FST;

Поддержка сериализации JSON на основе Jackson;

Поддержка системы удаленного взаимодействия HTTP на основе встроенного Tomcat;

Обновите Spring до 3.x;

Обновите клиент ZooKeeper;

Поддерживает конфигурацию Dubbo, полностью основанную на коде Java;

Spring Cloudполностью основано наSpring Boot, это очень новый проект, версия релиза 1.0 была запущена в 2016 году, а скорость обновления на Github очень высокая.Хотя Spring Cloud имеет самое короткое время по сравнению с RPC-фреймворками, такими как Dubbo, Spring Cloud предоставляет полный набор распределенных системные решения.Spring Cloud предоставляет разработчикам инструменты для быстрого встраивания распределенных систем (управление конфигурацией, обнаружение сервисов, прерыватель цепи, маршрутизация, микропрокси, шина управления, одноразовый токен, глобальные мелочи, выборы лидера, распределенный сеанс, состояние кластера), разработчики с помощью Spring Cloud можно быстро запускать сервисы или создавать приложения. Они будут работать в любой распределенной среде, включая собственные ноутбуки разработчиков, физические центры обработки данных и облачные платформы управления, такие как Cloud Foundry. В будущем мы возглавим разработку этой микросервисной архитектуры и предоставим набор стандартных отраслевых решений для микросервисной архитектуры.

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

На следующем рисунке показано сравнение Spring Cloud и Dubbo:

MotanЭто среда Java с открытым исходным кодом Sina Weibo. Он родился относительно поздно, начиная с 2013 года и с открытым исходным кодом в мае 2016 года. Motan широко используется на платформе Weibo, ежедневно совершая около 100 миллиардов звонков в сотни сервисов. По сравнению с Dubbo, Motan не так обширен с точки зрения функций и не реализует особенно много расширений. Его используют немногие, а его функционирование и стабильность еще предстоит выяснить.Плохая поддержка межъязыковых вызовов, в основном java.

HessianиспользуетсяДвоичный протокол RPC, подходящий для отправки двоичных данных. Но это также и структура веб-службы, обеспечивающая поддержку вызовов RPC с простыми функциями и удобным использованием.Передача по протоколу Http. Предоставление удаленных услуг через сервлеты. Запросы инициируются через API, предоставляемый самим Hessain. Ответчик принимает запросы в соответствии с API, предоставленным Hessian.

Преимущества Гессена:

Вся банка маленькая и легкая;

Простая конфигурация;

Мощный, отложите soap (простой протокол доступа к объектам), ejb и используйте бинарники для передачи объектов;

rpcxЭто Dubbo языковой экосистемы Go.Он легче, чем Dubbo, и реализует многие функции Dubbo.Отличные функции параллелизма и лаконичный синтаксис языка Go позволяют реализовать распределенные службы RPC с меньшим количеством кода..

gRPCЭто высокопроизводительная инфраструктура RPC общего назначения с открытым исходным кодом, разработанная Google. Она в основном разработана Google для разработки мобильных приложений и разработана на основе стандарта протокола HTTP / 2. Она разработана на основе ProtoBuf (Protocol Buffers). ) протокол сериализации и поддерживает множество языков разработки. Он не распространяется сам по себе, поэтому для реализации функций вышеуказанного фреймворка требуется дальнейшее развитие.

thriftЭто межъязыковая высокопроизводительная сервисная структура Apache, которая также широко используется.

Сравнение вышеуказанных функций инфраструктуры RPC:

Функции	Hessian	Montan	rpcx	gRPC	Thrift	Dubbo	Dubbox	Spring Cloud
Язык разработки	кросс язык	Java	Go	кросс язык	кросс язык	Java	Java	Java
Распределенный (Управление услугами)	×	√	√	×	×	√	√	√
Поддержка нескольких фреймворков сериализации	hessian	√(поддержка Hessian2, Json, расширяемая)	√	× поддерживает только protobuf)	×(экономный формат)	√	√	√
Несколько реестров	×	√	√	×	×	√	√	√
центр управления	×	√	√	×	×	√	√	√
по языкам программирования	√	× (поддержка php-клиента и C-сервера)	×	√	√	×	×	×
Поддержка ОТДЫХА	×	×	×	×	×	×	√	√
Внимание	Низкий	середина	Низкий	середина	середина	середина	высокий	середина
Трудно начать	Низкий	Низкий	середина	середина	середина	Низкий	Низкий	середина
Стоимость эксплуатации и обслуживания	Низкий	середина	середина	середина	Низкий	середина	середина	середина
организация с открытым исходным кодом	Caucho	Weibo	Apache	Google	Apache	Alibaba	Dangdang	Apache

Выбор в реальных сценариях

Spring Cloud: Весеннее семейное ведро, очень удобное в использовании, только без него не придумаешь, без него не обойтись. Жаль, что из-за относительно позднего релиза более удачных кейсов в Китае не было.Большинство пробуют воду, но ведь Spring индоссирован, так что оптимистичнее.

Dubbox: По оценкам, по сравнению с Dubbo, поддерживающей REST, это одна из важных причин, по которой многие компании выбирают Dubbox. Однако, если используется метод вызова RPC Dubbo, между службами по-прежнему будут сильные зависимости API. Каждый из них имеет свои преимущества. и недостатки.

Thrift: Если вы в стороне, вы можете создать абстрактный пользовательский фреймворк на основе Thrift.

Montan: Может быть, потому что он вышел относительно поздно, за исключением тех, что были опубликованы на Sina Weibo в начале 2016 года.

Hessian: Если это начинающая компания или количество систем не превышает 5, то рекомендуется выбирать эту, ведь она относительно легкая и простая с точки зрения скорости разработки, стоимости эксплуатации и сопровождения, сложности получения Даже если в будущем он будет перенесен на SOA, это будет бесшовная миграция.

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

3.2 RPC vs REST(JAX-RS)

Поскольку Dubbo является базовым фреймворком, разумно ли содержание его реализации для реализации микросервисной архитектуры, нам также необходимо рассмотреть вопрос о том, следует ли модифицировать его в соответствии с нашими собственными потребностями.Например, сервисные вызовы Dubbo реализуются через RPC, но если вы внимательно прочитали книгу Мартина Фаулераmicroservicesодна статья,Определенная межсервисная связь — это REST API протокола HTTP.. Так в чем разница между ними?

Интерфейс между поставщиком услуг и вызывающим абонентом слишком зависим

Мы определяем свой собственный абстрактный интерфейс службы для каждой микрослужбы и публикуем его в частном репозитории посредством непрерывной интеграции.Вызывающее приложение сильно зависит от абстрактного интерфейса, предоставляемого микрослужбой, поэтому независимо от среды разработки, тестирования и интеграции, требуются строгие требования. Ряд проблем, таких как несоответствие между сервером и вызывающей стороной, не приведет к успешной компиляции приложения, и это также напрямую повлияет на требования среды локальной разработки. Часто приложение верхнего уровня, которое зависит на многих сервисах нужно компилировать каждый день, последующую разработку можно вести только после обновления большого количества кода и его установки.Без строгой системы управления версиями или разработки некоторых средств автоматизации такие зависимости могут стать кошмаром для команды разработчиков..Интерфейс REST более легкий, чем RPC.Зависимость между поставщиком услуг и вызывающей стороной зависит только от контракта, и на уровне кода нет сильной зависимости., конечно, у интерфейса REST тоже есть болевые точки,Поскольку определение интерфейса слишком легкое, легко вызвать несоответствие между документом определения и фактической реализацией, что приведет к проблемам во время интеграции службы., но проблема решается легко, просто нужно интегрировать swagger через каждый сервис,Ее можно решить, интегрировав код и документацию каждого сервиса.. Таким образом, в распределенной среде зависимости службы на основе REST более гибкие, чем зависимости на основе RPC.
Сервисы зависят от платформы и их сложно использовать повторно.

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

Я считаю, что эти болевые точки также являются одной из причин, по которой Dangdang добавил поддержку REST в dubbox (расширение с открытым исходным кодом, основанное на Dubbo).

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

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

4. Что дает Dubbox

4.1 Управление сервисом Дуббо

характеристика	описывать
прозрачный удаленный вызов	Вызывайте удаленные методы точно так же, как и локальные, только простая настройка без вмешательства API;
механизм балансировки нагрузки	LB на стороне клиента, который может заменить аппаратные балансировщики нагрузки, такие как F5, в интрасети;
Отказоустойчивый механизм повторных попыток	Сервисные фиктивные данные, количество повторных попыток, механизм тайм-аута и т.д.;
Обнаружение автоматической регистрации	Центр регистрации запрашивает IP-адрес поставщика услуг на основе имени интерфейса и может плавно добавлять или удалять поставщиков услуг;
Мониторинг журнала производительности	Мониторинг центра мониторинга времени вызова и времени вызова статистической службы;
Центр управления услугами	Правила маршрутизации, динамическая конфигурация, снижение качества обслуживания, контроль доступа, корректировка веса, балансировка нагрузки и другие ручные настройки.
Центр автоматического управления	Нет, например: механизм ограничения тока предохранителя, автоматическая регулировка веса и т. д.;

4.2 Расширенные возможности Dubbox

Поддержка удаленного вызова в стиле REST (HTTP + JSON/XML);

Поддержка эффективной реализации сериализации Java на основе Kryo и FST;

Поддержка сериализации JSON на основе Jackson;

Поддержка системы удаленного взаимодействия HTTP на основе встроенного Tomcat;

Обновите Spring до 3.x;

Обновите клиент ZooKeeper;

Поддерживает конфигурацию Dubbo, полностью основанную на коде Java;

5. Ссылки и рекомендуемая литература

Соревнование по производительности распределенной среды RPC
Какие базовые фреймворки нам нужны для реализации микросервисов?
Кое-что о микросервисах
Сравнение основных подпроектов микросервисного фреймворка Spring Cloud и фреймворка RPC
Микросервисы, SOA и API: друг или враг?
Сравнение практического применения микросервисов и SOA
Базовый выбор фреймворка для микросервисной архитектуры: Spring Cloud или Dubbo?
Микросервисы и архитектура SOA
REST против RPC в практике веб-сервисов
Что лучше: RPC или RESTful?
Интерфейс Rpc и Rest, Rpc микросервисов
В веб-разработке лучше использовать JSON-RPC или RESTful API?