Долгое время я не мог разобраться в разнице между RPC (то есть удалённым вызовом процедуры) и HTTP-вызовами. Позвольте мне посмеяться здесь~Наивно! В этой статье кратко представлены две формы архитектуры C/S, прежде всего, их самое существенное различие: RPC в основном основан на протоколе TCP/IP, а HTTP-сервис — на протоколе HTTP; все мы знаем, что протокол HTTP стоит поверх протокола транспортного уровня TCP, поэтому с точки зрения эффективности RPC, конечно, лучше! Давайте подробнее поговорим о RPC-сервисах и HTTP-сервисах.
Семиуровневая модель сети OSI
Прежде чем говорить о различии между RPC и HTTP, я считаю необходимым разобраться в семиуровневой модели сетевой структуры OSI (хотя на практике она состоит из пяти уровней), которую можно разделить на следующие уровни: (сверху вниз)
- Первый слой — прикладной слой. Определены интерфейсы для связи и передачи данных в сети;
- Второй слой — слой представления. Определить формат передачи, спецификации кодирования и декодирования данных в различных системах и т.д.;
- Третий слой — слой разговора. Управление пользовательскими сессиями и контроль установления и прерывания логических соединений между пользователями.
- Четвёртый слой — транспортный слой. Он управляет сквозной передачей данных в сети;
- Уровень 5: сетевой уровень. Определите, как данные передаются между сетевыми устройствами;
- Шестой слой: слой связи. Пакеты данных сетевого уровня выше инкапсулируются в кадры данных для облегчения передачи физического уровня.
- Слой 7: Физический уровень. Этот слой в основном предназначен для передачи этих двоичных данных.
На практике в пятиуровневой структуре протокола отсутствует уровень презентации и сессии. Стоит отметить, что они сливаются с прикладным уровнем. Нужно сосредоточиться на уровне приложений и транспортном уровнях. Потому что HTTP — это протокол прикладного уровня, а TCP — протокол транспортного уровня. Теперь, когда мы знаем модель сетевого слоёв, мы лучше понимаем, почему RPC-сервисы лучше, чем HTTP-сервисы!
Услуги RPC
Сервисы RPC представлены с трех точек зрения: архитектура RPC, синхронные асинхронные вызовы и популярные фреймворки RPC.
Архитектура RPC
Давайте поговорим о базовой архитектуре сервисов RPC. Позвольте мне стыдно украсть картину~ Мы ясно видим, что полная архитектура RPC содержит четыре основных компонента: клиент, сервер, клиентский заглушка и серверная заглушка, которые можно понимать как заглушки. Давайте поговорим о этих компонентах отдельно:
- Клиент, звонящий на службу.
- Сервер — настоящий поставщик услуг.
- Заглушка клиента хранит адресное сообщение сервера, затем упаковывает параметры запроса клиента в сетевое сообщение и отправляет его стороне сервиса удалённо через сеть.
- Серверная заглушка принимает сообщения, отправленные клиентом, распаковывает их и вызывает локальные методы.
RPC в основном используется в крупных предприятиях, поскольку крупные предприятия имеют множество систем, сложные бизнес-направления, а преимущества по эффективности имеют большое значение. Это реализуется в реальной разработке, а проекты обычно управляются с помощью Maven. Например, у нас есть системный сервис, который обрабатывает заказы, сначала объявляет все свои интерфейсы (здесь конкретно интерфейс на Java), а затем упаковывает весь проект в jar-пакет. Зачем это делать? Основная цель — уменьшить размер упаковки банки на стороне клиента, потому что каждый раз, когда пакет выпускается, слишком много упаковок всегда влияет на эффективность. Это также отделяет связь между клиентом и сервером для повышения портативности кода.
Синхронные и асинхронные вызовы
Что такое синхронный вызов? Что такое асинхронный вызов? Синхронный вызов — это когда клиент ждёт завершения выполнения вызова и возвращает результат. Асинхронные вызовы означают, что клиент не ждёт выполнения вызова и возврата результата, но всё равно может получать уведомление о возврате через функцию обратного вызова. Если клиенту всё равно на результат, это может превратиться в односторонний звонок. Этот процесс отчасти похож на вызываемые и загружаемые интерфейсы в Java: при асинхронном выполнении, если нам нужно узнать результат выполнения, мы можем использовать вызываемый интерфейс и получить информацию о результатах асинхронного выполнения через класс Future. Если вас не волнует результат выполнения, можно просто использовать интерфейс для запуска, потому что он не возвращает результат, конечно, возможно и вызываемое приложение, нам не нужно получать будущее.
Популярный фреймворк RPC
Существует множество популярных открытых фреймворков RPC. Вот три главных момента:
- gRPC — это недавно анонсированное открытое программное обеспечение от Google, основанное на новейшем протоколе HTTP 2.0, поддерживающее множество распространённых языков программирования. Мы знаем, что HTTP 2.0 — это обновлённая версия протокола HTTP, основанного на бинарном файле, и крупные браузеры сейчас поддерживают его с высокой скоростью. Этот фреймворк RPC основан на протоколе HTTP, а основной вариант использует поддержку фреймворка Netty.
- Thrift — это проект с открытым исходным кодом для Facebook, в основном кросс-языковой фреймворк для разработки сервисов. Он имеет генератор кода для автоматической генерации сервисного кода для определенного IDL-файла. Пользователям нужно выполнить только вторичную разработку перед этим, и базовая коммуникация RPC прозрачна. Однако для пользователей всё равно существует определённая стоимость изучения языка определённой области.
- Dubbo — это хорошо известный фреймворк RPC с открытым исходным кодом от группы Alibaba, который широко используется во многих интернет-компаниях и корпоративных приложениях. Можно подключать как протоколы, так и фреймворки сериализации. Тот же удалённый интерфейс основан на Java-интерфейсе и опирается на фреймворк spring для удобства разработки. Его можно легко упаковать в один файл и запустить независимо, что соответствует современной концепции микросервисов.
Тайно скажу тебе, что группа уже редко использует дуббо,То, что сейчас используется чаще, называется HSF, также известный как «так комфортно». Возможно, позже появится open source, так что подождём и посмотрим.
HTTP-сервис
На самом деле, давным-давно я всегда описывал модель корпоративной разработки как разработку HTTP-интерфейсов, что мы часто называем сервисными интерфейсами в стиле RESTful. Действительно, это метод коммуникации, часто используемый на ранних этапах решения информационных островков при небольшом числе интерфейсов и меньшем взаимодействии между системами; Преимущества просты, прямолинейны и просты в развитии. Используйте готовый HTTP-протокол для передачи. Мы помним, что когда мы занимались фоновой разработкой в компании, мы в основном разрабатывали интерфейсы, а также писали большой интерфейсный документ, строго указывающий, какие входные и выходные данные. Объясните метод запроса каждого интерфейса и вопросы, на которые нужно обратить внимание в параметрах запроса. Например, следующий пример:
ПОМЕСТИТЬhttp://www.httpexample.com/restful/buyer/info/share
Интерфейс может возвращать JSON-строку или XML-документ. Затем клиент обрабатывает полученную информацию, что позволяет ускорить разработку. Однако для крупных предприятий, при множестве внутренних подсистем и множества интерфейсов, преимущества фреймворка RPC проявляются: во-первых, это длинная связь, и нет необходимости каждый раз пожимать руку, как с http, что снижает сетевые накладные расходы; во-вторых, структура RPC обычно включает регистрационный центр и богатый мониторинг и управление; Публикация, офлайн-интерфейсы, динамическое расширение и т.д. — это невоспринимаемые и унифицированные операции для вызывающего.
сводка
В целом, RPC-сервисы в основном предназначены для крупных предприятий, тогда как HTTP-сервисы — для малых предприятий, поскольку RPC более эффективен, а разработка HTTP-сервисов будет быстрее. Короче говоря, выбор фреймворка определяется не тем, что популярно на рынке, а от полной оценки всего проекта, чтобы тщательно сравнить влияние двух фреймворков на весь проект и, наконец, определить, что наиболее подходит для проекта. Мы не должны использовать RPC для каждого проекта ради использования RPC, а адаптироваться к местным условиям и анализировать конкретную ситуацию.
|
Опубликовано 01.04.2019 14:02:45
|
|
|
|
