Довгий час я не міг розрізнити 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. Якщо вам не важливий результат виконання, можна просто використовувати інтерфейс runnable, бо він не повертає результат, звісно, також можливий виклик, нам не потрібно отримувати майбутнє.
Популярний фреймворк RPC
Досі існує багато популярних відкритих фреймворків RPC. Ось три основні моменти:
- gRPC — це нещодавно анонсоване відкрите програмне забезпечення від Google, засноване на найновішому протоколі HTTP 2.0, яке підтримує багато поширених мов програмування. Ми знаємо, що HTTP 2.0 — це оновлена версія протоколу HTTP на основі бінарного файлу, і великі браузери наразі підтримують його у швидких темпах. Цей фреймворк RPC базується на протоколі HTTP, а основний фреймворк використовує підтримку фреймворку Netty.
- Thrift — це проєкт з відкритим кодом для Facebook, переважно фреймворк для розробки крос-мовних сервісів. Він має генератор коду для автоматичної генерації фреймворку коду сервісу для ідентифікаційного файлу IDL. Користувачам потрібно лише виконати вторинну розробку, а базова комунікація RPC є прозорою. Однак для користувачів все ще існує певна вартість вивчення мови певної галузі.
- Dubbo — це відомий фреймворк RPC з відкритим кодом від Alibaba Group, який широко використовується в багатьох інтернет-компаніях та корпоративних додатках. Можна підключати як протоколи, так і фреймворки серіалізації. Той самий віддалений інтерфейс базується на Java Interface і базується на фреймворку spring для зручності розробки. Його легко упакувати в один файл і запускати незалежно, що відповідає сучасній концепції мікросервісів.
Таємно кажуть, що група вже майже не використовує dubbo,Той, що зараз більш поширений, називається HSF, також відомий як «такий комфортний». Можливо, пізніше з'явиться відкритий код, тож давайте почекаємо і подивимось.
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
|
|
|
|
