前面我們認識了兩個常用文本類的 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，表示方法名是三個字符
- 0x92，表示有兩個參數。其實這里存的應該是 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 包的依賴和管理問題