предисловие
Как интегрировать микросервисы, возможно, является одним из самых важных знаний в технологиях, связанных с микросервисами. В частности, это может быть выражено как метод вызова, протокол связи, протокол сериализации и т. д. между службами. Если интеграция сервисов сделана хорошо, ваши микросервисы могут поддерживать максимальную автономию, вы можете модифицировать и выпускать их независимо друг от друга, наоборот, это принесет вам катастрофу, если это не будет хорошо продумано заранее.
Эта статья — вторая статья из цикла обучения дизайну микросервисов (с момента выхода последней статьи прошло больше месяца, мне стыдно).
Добро пожаловать в предыдущую серию:
1. Ожидания от интегрированной технологии
Способы и средства интеграции сервисов настолько разнообразны, как выбрать наиболее подходящий среди множества технологий?
Во-первых, нам нужно знать, чего мы хотим от этих интегрированных технологий? Какой эффект мы ожидаем. Таким образом, мы можем выбирать с целью. Хотя в зависимости от бизнеса будут разные соображения, мы всегда надеемся получить следующие преимущества:
1. Избегайте разрушительных изменений
Мы не хотим, чтобы когда мы изменяем и публикуем сервис, потребители сервиса тоже должны изменять и публиковать. Мы хотим выбрать метод, который минимизирует деструктивные изменения. Например, если микрослужба добавляет поле в ответ, это не должно повлиять на существующих потребителей.
2. Технологическая независимость служебной связи
Те из нас, кто занимается нашим бизнесом, должны лучше знать, что единственная константа в этой области — постоянные изменения.
Постоянно появляются новые инструменты, фреймворки, языки. Например, если вы сейчас Java-разработчик, возможно, через несколько лет вы захотите попробовать язык Go, который больше подходит для облачных приложений, для создания микросервисов.
Гибкие и открытые характеристики микросервисов обусловлены их конструкцией.технологическая неоднородностьОднако неправильный выбор технологии интеграции ограничит конкретную технологию реализации микросервисов. Очень важно обеспечить технологическую независимость способа взаимодействия микросервисов. Это означает, что не стоит выбирать метод интеграции, имеющий ограничения по конкретной технологии реализации микросервисов.
3. Услуга проста в использовании для потребителей
Потребители должны иметь возможность легко пользоваться нашими услугами. Неважно, насколько прекрасен микросервис, если потребителям пользоваться сервисом сложнее, чем небом.
В идеале потребитель должен иметь возможность использовать любую технологию для реализации, с другой стороны, предоставление клиентской библиотеки также может упростить использование потребителем. Но обычно такая библиотека несовместима с другими вещами, которые мы хотим получить. Например, использование клиентской библиотеки удобно для потребителей, но увеличивает связанность.
(Этот пункт часто конфликтует с первыми двумя пунктами)
4. Скрыть детали внутренней реализации
Детали внутренней реализации сервиса должны быть максимально скрыты и не выставлены напоказ. Это также с точки зрения развязки.
Не следует использовать все методы, которые раскрывают детали внутренней реализации.
2. Способ связи службы
Путь между сервисами можно разделить на два пути: синхронное общение и асинхронное общение.
При синхронной связи после вызова удаленной службы вызывающая сторона блокируется и ожидает завершения всей операции. Такие какRPC,HTTPпередача.
При асинхронной связи вызывающая сторона может вернуться, не дожидаясь завершения операции, и может даже не заботиться о ее завершении. Такие какMQ.
Среди двух режимов связи кооперативный режим синхронной связи являетсяответ на запросметод, клиент инициирует запрос, а затем ожидает ответа. Этот шаблон хорошо согласуется с шаблоном синхронной связи, но асинхронная связь также может использовать этот шаблон. Я могу сделать запрос, а затем зарегистрировать обратный вызов, который будет вызван после завершения работы сервера.
Основным методом сотрудничества асинхронной связи являетсяоснованный на событииметод, клиент не инициирует запрос, а публикует событие, а затем ожидает, что другие соавторы получат сообщение и обработают его.
Системы, основанные на событиях, по своей сути асинхронны. Вся система умная, то есть бизнес-логика не сосредоточена в одном ядре мозга, а равномерно распределена между разными соавторами.Сотрудничество на основе событий имеет низкую связанность. Клиент публикует событие, но ему не нужно знать, кто или что на него отреагирует,Это также означает, что вы можете добавлять новых подписчиков на событие, не затрагивая клиентов..
Дальнейшее чтение:Шаблон микросервиса — синхронный и асинхронный, в котором более подробно рассматривается архитектура взаимодействия микрослужб. На изображение выше также ссылаются.
Вообще говоря, использование совместной работы на основе событий может эффективно снизить степень связанности системы, и вы можете более гибко модифицировать существующую систему. Однако для межсервисного мониторинга бизнес-процессов требуется дополнительная работа.
Здесь следует учитывать несколько факторов. Синхронные вызовы проще, и легко понять, правильно ли работает весь процесс. Если вам нужна семантика стиля запрос/ответ, но вы также хотите избежать дилеммы трудоемкого бизнеса, вы можете использовать метод асинхронного запроса и обратного вызова. С другой стороны, использование асинхронного режима способствует реализации совместных решений, тем самым значительно уменьшая связь между службами, что является именно той функцией, которую мы преследуем для независимой публикации служб.
Конечно, в большинстве производственных сценариев то, что мы видим, должно быть сочетанием различных методов, основанных на потребностях бизнеса или по каким-то другим причинам.
3. RPC или REST
Давайте сначала рассмотрим несколько популярных схем интеграции:
- RPC
- REST over HTTP
- Передача сообщений через брокеры сообщений, такие как промежуточное ПО сообщений.
В этом разделе в основном обсуждаются RPC (удаленный вызов процедур) и REST (передача репрезентативного состояния).
RPC
Удаленный вызов процедур (RPC) — это метод межсетевого взаимодействия, который позволяет программам вызывать методы или функции других серверов в общей сети, защищая разработчиков приложений от технических деталей удаленных вызовов. RPC должен быть максимально простым, эффективным и прозрачным. Клиентское приложение может напрямую вызывать объектный метод серверного приложения на другом сервере так же, как вызов локального объектного метода.
RPC — это техническая идея, а не спецификация. Протокол определяет только процесс вызова «точка-точка» между клиентом и сервером, включая заглушку, протокол связи, анализ сообщений RPC и т. д. В практических приложениях также необходимо учитывать такие вопросы, как высокая доступность и балансировка нагрузки служб.
Две проблемы, которые должен решить RPC:
- Решите проблему вызова между службами в распределенной системе.
- При совершении удаленного звонка он должен быть таким же удобным, как и локальный звонок, чтобы звонящий не мог понять логику удаленного звонка.
ядроПротокол связи, структура сериализации и вызова.
Популярные на сегодняшний день реализации RPC будут генерировать для вас серверные и клиентские заглушки, что позволит вам быстро приступить к написанию кода. Мне почти не требуется времени, чтобы взаимодействовать с контентом между сервисами. Это часто является одним из основных преимуществ RPC:легко использовать. Теоретически возможность просто использовать обычные вызовы методов и игнорировать другие детали является огромным преимуществом для программистов.
(Распространенные фреймворки RPC: Java RMI, gRPC, Thrift, Dubbo и т. д.)
Однако некоторые реализации RPC имеют некоторые проблемы, такие как иСильные связующие характеристики технологииНапример, Java RMI. На этом этапе некоторые фреймворки RPC будут решать проблему (например, Dubbo) через клиент на разных языках, а также поддерживать различные языки программирования, генерируя код через общий сервисный контракт, такой как GRPC.
Разговор о REST и RPC
Есть много статей и книг, которые объединят эти два понятия.В инерционном мышлении реализация REST основана на HTTP, а протокол связи RPC, как правило, TCP, но RPC также может реализовывать службы в стиле REST, только необходимо определить свои собственные глаголы (GET, POST, PUT, DELETE). RPC также может быть реализован с использованием HTTP, используя только некоторые функции HTTP, в то время как глаголы и коды ошибок HTTP игнорируются.
Самое главное, я думаюДва не являются размерной концепцией, Когда я читал некоторые статьи и сравнивал их вместе давным-давно, я всегда выглядел немного сбитым с толку.
Я думаю, что RPC ориентирован на процесс (для удаленных вызовов сервисных функций), а REST ориентирован на ресурсы. Например, если вы предоставляете интерфейс для запросов пользователей в стиле RPC, вы можете написать:
/queryUser?userId=123
用Restful风格呢？
Get
/user?userId=123
再精炼一点，甚至可以这样：
Get
/user/123
Идея RPC заключается в том, чтобы сопоставить локальные функции с API, то есть API соответствует функции, у меня есть локальный getAllUsers, и удаленный также может вызвать этот getAllUsers через определенный протокол. Неважно, является ли этот протокол Socket, HTTP или чем-то еще;
PS: Внедрить RPC не сложно, но как реализовать высокопроизводительный и высоконадежный фреймворк RPC
Что касается REST, это архитектурный стиль. Стиль REST содержит много принципов и ограничений.Я думаю, что ключевым моментом является спецификация, такая как использование кода состояния HTTP в качестве кода ошибки, использование HTTP METHOD для выражения действия, которое должно быть выполнено в этом запросе, так что различные бизнес-системы имеют можно сослаться на «унифицированную» спецификацию.
Но так ли уж унифицирована эта унифицированная спецификация?
Я лично считаю, что в реальной разработке бизнеса дизайнерская идея REST нелогична для программистов, потому что в локальном бизнес-коде все еще есть функции и действия, но в виде интерфейсов, они полностью в форме ресурсов. Точно так же, как объектно-ориентированная теория «все есть объект» кажется очень неуклюжей в глазах программистов, привыкших к чисто процессно-ориентированной разработке: мой код изначально выполняется последовательно, цикл, ветвь, почему он должен быть очень clear Структура инкапсулирует интерфейс подкласса базового класса слой за слоем, но также преднамеренно дает двум функциям одно и то же имя, какое из них следует использовать при вызове? При использовании идеи «все является ресурсом» для написания API-интерфейса в реальном проекте наиболее распространенный вопрос: «Что это за ресурс?.. Забудьте об этом, я просто напишу это напрямую». , неважно в каком стиле"
В основном, чтобы проиллюстрировать, что RESTful API непрактичны во многих практических проектах. Поэтому, если вы действительно делаете проект и проектируете интерфейс, вы можете обнаружить, что для определения интерфейса можно использовать только HTTP+JSON, а семантика и дизайн API не могут строго следовать стилю REST.(JSON+HTTP!= ОТДЫХ)
Могут ли они сосуществовать? Да, SpringCloud использует компоненты Feign для инкапсуляции интерфейсов REST в вызовы RPC, не так ли? Здесь ваш интерфейс приложения SpringBoot может быть RESTful, но компоненты Feign представляют собой сервис-ориентированную упаковку.
Я лично считаю, что REST более ценен в сценарии, когда внешний и внутренний интерфейсы разделены или когда служба может быть интегрирована несколькими клиентами (веб-страницами, мобильными терминалами, другими службами), унифицированная «спецификация» REST показывает, что его ценность.
Если это только внутренняя служба, то, по крайней мере, то, что я знаю, является более зрелой инфраструктурой RPC, ** потому что зрелая инфраструктура RPC более инкапсулирована «обнаружение службы», «балансировка нагрузки», «переход на более раннюю версию». Класс расширенного обслуживания -ориентированные функции. **Можно понять, что инфраструктура RPC представляет собой более продвинутую сервис-ориентированную инкапсуляцию, как в случае со SpringCloud в Java, так и с Dubbo.
Что касается концепций между REST, RPC и HTTP, я обнаружил, что многие статьи в Интернете на самом деле не очень ясны.
я тоже читал эту статьюDebunking the Myths of RPC & RESTПосле этого я медленно понял концепцию между этими тремя. Рекомендую прочитать~
Если вам трудно понять английский язык, вы можете прочитать это, очень простое:RPC-и-Restful
Стиль REST содержит много контента, я настоятельно рекомендую вам взглянутьМодель зрелости Ричардсона, в котором есть сравнение различных уровней зрелости REST.
ОТДЫХ - это как говорить о мандаринском, благо всем понятно, никто говорить не будет.
RPC похоже на разговоры о черных словах, преимущества могут быть более оптимизированными, более секретностью, более настраиваемыми, недостатки - спросить «сказать», «Аргот из этой партии (сторона клиента) должен понимать, и как только все говорят - черный Для того, что это не может сложно.
Приведенное выше обсуждение RPC и REST, хоть я и давно об этом думал, но все же мнение семьи.Очень надеюсь, что коллеги со стажем и стажем смогут указать на свои разные мнения.
резюме
По причинам времени и энергии, эта статья не требует слишком много обсуждения этого метода передачи сообщений через прокси. Но здесь необходимо повторить, что REST, RPC и обмен сообщениями брокера не являются взаимоисключающими, все они могут работать вместе в вашей архитектуре микросервисов. Крупные корпоративные системы (облачные) в той или иной степени используют эти подходы. Самое главное — выбрать подходящую технологию в соответствии с бизнес-сценарием, а также определить границы области обслуживания и метод анализа для различных методов связи.
Для более подробного обсуждения RPC/REST/Brokered Messaging рекомендуется эта статья.REST, RPC, and Brokered Messaging
Выше приведены некоторые из моих знаний о технологии интеграции микросервисов. Надеюсь вдохновить и помочь вам.
Если эта статья была вам полезна, я надеюсь, что вы можете поставить лайк, это самая большая мотивация для меня.