前面我們講了兩個常用文本類的 RPC 協議，對于陌生人之間的溝通，用 NBA、CBA 這樣的縮略語，會使得協議約定非常不方便，
在講 CDN 和 DNS 的時候，我們講過接入層的設計，對于靜態資源或者動態資源靜態化的部分都可以做快取，但是對于下單、支付等交易場景，還是需要呼叫 API，
對于微服務的架構，API 需要一個 API 網關統一的管理，API 網關有多種實作方式，用 Nginx 或者 OpenResty 結合 Lua 腳本是常用的方式，在上一節講過的 Spring Cloud 體系中，有個組件 Zuul 也是干這個的，
資料中心內部是如何相互呼叫的？
API 網關用來管理 API，但是 API 的實作一般在一個叫作 Controller 層的地方，這一層對外提供 API，由于是讓陌生人訪問的，我們能看到目前業界主流的，基本都是 RESTful 的 API，是面向大規模互聯網應用的，
在 Controller 之內，就是咱們互聯網應用的業務邏輯實作，上節講 RESTful 的時候，說過業務邏輯的實作最好是無狀態的，從而可以橫向擴展，但是資源的狀態還需要服務端去維護，資源的狀態不應該維護在業務邏輯層，而是在最底層的持久化層，一般會使用分布式資料庫和 ElasticSearch，
這些服務端的狀態，例如訂單、庫存、商品等，都是重中之重，都需要持久化到硬碟上，資料不能丟，但是由于硬碟讀寫性能差，因而持久化層往往吞吐量不能達到互聯網應用要求的吞吐量，因而前面要有一層快取層，使用 Redis 或者 memcached 將請求攔截一道，不能讓所有的請求都進入資料庫“中軍大營”，
快取和持久化層之上一般是基礎服務層，這里面提供一些原子化的介面，例如，對于用戶、商品、訂單、庫存的增刪查改，將快取和資料庫對再上層的業務邏輯屏蔽一道，有了這一層，上層業務邏輯看到的都是介面，而不會呼叫資料庫和快取，因而對于快取層的擴容，資料庫的分庫分表，所有的改變，都截止到這一層，這樣有利于將來對于快取和資料庫的運維，
再往上就是組合層，因為基礎服務層只是提供簡單的介面，實作簡單的業務邏輯，而復雜的業務邏輯，比如下單，要扣優惠券，扣減庫存等，就要在組合服務層實作，
這樣，Controller 層、組合服務層、基礎服務層就會相互呼叫，這個呼叫是在資料中心內部的，量也會比較大，還是使用 RPC 的機制實作的，
由于服務比較多，需要一個單獨的注冊中心來做服務發現，服務提供方會將自己提供哪些服務注冊到注冊中心中去，同時服務消費方訂閱這個服務，從而可以對這個服務進行呼叫，
呼叫的時候有一個問題，這里的 RPC 呼叫，應該用二進制還是文本類？其實文本的最大問題是，占用位元組數目比較多，比如數字 123，其實本來二進制 8 位就夠了，但是如果變成文本，就成了字串 123，如果是 UTF-8 編碼的話，就是三個位元組；如果是 UTF-16，就是六個位元組，同樣的資訊，要多費好多的空間，傳輸起來也更加占帶寬，時延也高，
因而對于資料中心內部的相互呼叫，很多公司選型的時候，還是希望采用更加省空間和帶寬的二進制的方案，
這里一個著名的例子就是 Dubbo 服務化框架二進制的 RPC 方式，
Dubbo 會在客戶端的本地啟動一個 Proxy，其實就是客戶端的 Stub，對于遠程的呼叫都通過這個 Stub 進行封裝，
接下來，Dubbo 會從注冊中心獲取服務端的串列，根據路由規則和負載均衡規則，在多個服務端中選擇一個最合適的服務端進行呼叫，
呼叫服務端的時候，首先要進行編碼和序列化，形成 Dubbo 頭和序列化的方法和引數，將編碼好的資料，交給網路客戶端進行發送，網路服務端收到訊息后，進行解碼，然后將任務分發給某個執行緒進行處理，在執行緒中會呼叫服務端的代碼邏輯，然后回傳結果，
這個程序和經典的 RPC 模式何其相似啊！
如何解決協議約定問題？
接下來我們還是來看 RPC 的三大問題，其中注冊發現問題已經通過注冊中心解決了，下面我們就來看協議約定問題，
Dubbo 中默認的 RPC 協議是 Hessian2，為了保證傳輸的效率，Hessian2 將遠程呼叫序列化為二進制進行傳輸，并且可以進行一定的壓縮，這個時候你可能會疑惑，同為二進制的序列化協議，Hessian2 和前面的二進制的 RPC 有什么區別呢？這不繞了一圈又回來了嗎？
Hessian2 是解決了一些問題的，例如，原來要定義一個協議檔案，然后通過這個檔案生成客戶端和服務端的 Stub，才能進行相互呼叫，這樣使得修改就會不方便，Hessian2 不需要定義這個協議檔案，而是自描述的，什么是自描述呢？
所謂自描述就是，關于呼叫哪個函式，引數是什么，另一方不需要拿到某個協議檔案、拿到二進制，靠它本身根據 Hessian2 的規則，就能決議出來，
原來有協議檔案的場景，有點兒像兩個人事先約定好，0 表示方法 add，然后后面會傳兩個數，服務端把兩個數加起來，這樣一方發送 012，另一方知道是將 1 和 2 加起來，但是不知道協議檔案的，當它收到 012 的時候，完全不知道代表什么意思，
而自描述的場景，就像兩個人說的每句話都帶前因后果，例如，傳遞的是“函式：add，第一個引數 1，第二個引數 2”，這樣無論誰拿到這個表述，都知道是什么意思，但是只不過都是以二進制的形式編碼的，這其實相當于綜合了 XML 和二進制共同優勢的一個協議，
Hessian2 是如何做到這一點的呢？這就需要去看 Hessian2 的序列化的語法描述檔案，
看起來很復雜，編譯原理里面是有這樣的語法規則的，
我們從 Top 看起，下一層是 value，直到形成一棵樹，這里面的有個思想，為了防止歧義，每一個型別的起始數字都設定成為獨一無二的，這樣，決議的時候，看到這個數字，就知道后面跟的是什么了，
這里還是以加法為例子，“add(2,3)”被序列化之后是什么樣的呢？
H x02 x00 # Hessian 2.0 C # RPC call x03 add # method "add" x92 # two arguments x92 # 2 - argument 1 x93 # 3 - argument 2
- H 開頭，表示使用的協議是 Hession，H 的二進制是 0x48，
- C 開頭，表示這是一個 RPC 呼叫，
- 0x03，表示方法名是三個字符，
- x92，表示有兩個引數，其實這里存的應該是 2，之所以加上 0x90，就是為了防止歧義，表示這里一定是一個 int，
- 第一個引數是 2，編碼為 0x92，第二個引數是 3，編碼為 0x93，
這個就叫作自描述，
另外，Hessian2 是面向物件的，可以傳輸一個物件，
class Car {
String color;
String model;
}
out.writeObject(new Car("red", "corvette"));
out.writeObject(new Car("green", "civic"));
---
C # object definition (#0)
x0b example.Car # type is example.Car
x92 # two fields
x05 color # color field name
x05 model # model field name
O # object def (long form)
x90 # object definition #0
x03 red # color field value
x08 corvette # model field value
x60 # object def #0 (short form)
x05 green # color field value
x05 civic # model field value
首先，定義這個類，對于型別的定義也傳過去，因而也是自描述的，類名為 example.Car，字符長 11 位，因而前面長度為 0x0b，有兩個成員變數，一個是 color，一個是 model，字符長 5 位，因而前面長度 0x05,，
然后，傳輸的物件參考這個類，由于類定義在位置 0，因而物件會指向這個位置 0，編碼為 0x90，后面 red 和 corvette 是兩個成員變數的值，字符長分別為 3 和 8，
接著又傳輸一個屬于相同類的物件，這時候就不保存對于類的參考了，只保存一個 0x60，表示同上就可以了，
可以看出，Hessian2 真的是能壓縮盡量壓縮，多一個 Byte 都不傳，
如何解決 RPC 傳輸問題？
接下來，我們再來看 Dubbo 的 RPC 傳輸問題，前面我們也說了，基于 Socket 實作一個高性能的服務端，是很復雜的一件事情，在 Dubbo 里面，使用了 Netty 的網路傳輸框架，
Netty 是一個非阻塞的基于事件的網路傳輸框架，在服務端啟動的時候，會監聽一個埠，并注冊以下的事件，
- 連接事件：當收到客戶端的連接事件時，會呼叫 void connected(Channel channel) 方法，
- 當可寫事件觸發時，會呼叫 void sent(Channel channel, Object message)，服務端向客戶端回傳回應資料，
- 當可讀事件觸發時，會呼叫 void received(Channel channel, Object message) ，服務端在收到客戶端的請求資料，
- 當發生例外時，會呼叫 void caught(Channel channel, Throwable exception)，
當事件觸發之后，服務端在這些函式中的邏輯，可以選擇直接在這個函式里面進行操作，還是將請求分發到執行緒池去處理，一般異步的資料讀寫都需要另外的執行緒池參與，在執行緒池中會呼叫真正的服務端業務代碼邏輯，回傳結果，
Hessian2 是 Dubbo 默認的 RPC 序列化方式，當然還有其他選擇，例如，Dubbox 從 Spark 那里借鑒 Kryo，實作高性能的序列化，
到這里，我們說了資料中心里面的相互呼叫，為了高性能，大家都愿意用二進制，但是為什么后期 Spring Cloud 又興起了呢？這是因為，并發量越來越大，已經到了微服務的階段，同原來的 SOA 不同，微服務粒度更細，模塊之間的關系更加復雜，
在上面的架構中，如果使用二進制的方式進行序列化，雖然不用協議檔案來生成 Stub，但是對于介面的定義，以及傳的物件 DTO，還是需要共享 JAR，因為只有客戶端和服務端都有這個 JAR，才能成功地序列化和反序列化，
但當關系復雜的時候，JAR 的依賴也變得例外復雜，難以維護，而且如果在 DTO 里加一個欄位，雙方的 JAR 沒有匹配好，也會導致序列化不成功，而且還有可能回圈依賴，這個時候，一般有兩種選擇，
第一種，建立嚴格的專案管理流程，
- 不允許回圈呼叫，不允許跨層呼叫，只準上層呼叫下層，不允許下層呼叫上層，
- 介面要保持兼容性，不兼容的介面新添加而非改原來的，當介面通過監控，發現不用的時候，再下掉，
- 升級的時候，先升級服務提供端，再升級服務消費端，
第二種，改用 RESTful 的方式，
- 使用 Spring Cloud，消費端和提供端不用共享 JAR，各宣告各的，只要能變成 JSON 就行，而且 JSON 也是比較靈活的，
- 使用 RESTful 的方式，性能會降低，所以需要通過橫向擴展來抵消單機的性能損耗，
這個時候，就看架構師的選擇嘍！
小結
- RESTful API 對于接入層和 Controller 層之外的呼叫，已基本形成事實標準，但是隨著內部服務之間的呼叫越來越多，性能也越來越重要，于是 Dubbo 的 RPC 框架有了用武之地，
- Dubbo 通過注冊中心解決服務發現問題，通過 Hessian2 序列化解決協議約定的問題，通過 Netty 解決網路傳輸的問題，
- 在更加復雜的微服務場景下，Spring Cloud 的 RESTful 方式在內部呼叫也會被考慮，主要是 JAR 包的依賴和管理問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/211566.html
標籤：其他