緩存rpc框架
A. 當前主流的RPC框架有哪些
Thrift 是由 Facebook 開源的一個 RPC 框架，現在已經掛在 apache.org 下了。主要的幾個好處:
1. 支持非常多語言，包括在 WEB 開發中很常用的 PHP，以及最重要的 C++/Python/Java 等 WEB後端常用語言，當然，還包括很 cool 的 Ruby、Erlang。
2. 完整的 RPC 框架實現，用腳本生成通訊相關的框架代碼，開發者只需要集中精力處理好 業務邏輯。比如搭建一個 Hello World Service 只需要幾分鍾。
3.擁有被 Facebook、Last.fm 等不少大規模互聯網應用驗證過的性能和可用性。
Hessian是一款基於HTTP協議的RPC框架，採用的是二進制RPC協議，非常輕量級 ，且速度較快。
當然，還有Hetty，它是一款構建於Netty和Hessian基礎上的高性能的RPC框架
B. Dubbo——HTTP 協議 + JSON-RPC
Protocol 還有一個實現分支是 AbstractProxyProtocol，如下圖所示：
從圖中我們可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等協議對應的 Protocol 實現，都是繼承自 AbstractProxyProtocol 抽象類。
目前互聯網的技術棧百花齊放，很多公司會使用 Node.js、Python、Rails、Go 等語言來開發 一些 Web 端應用，同時又有很多服務會使用 Java 技術棧實現，這就出現了大量的跨語言調用的需求。Dubbo 作為一個 RPC 框架，自然也希望能實現這種跨語言的調用，目前 Dubbo 中使用「HTTP 協議 + JSON-RPC」的方式來達到這一目的，其中 HTTP 協議和 JSON 都是天然跨語言的標准，在各種語言中都有成熟的類庫。
下面就重點來分析 Dubbo 對 HTTP 協議的支持。首先，會介紹 JSON-RPC 的基礎，並通過一個示例，快速入門，然後介紹 Dubbo 中 HttpProtocol 的具體實現，也就是如何將 HTTP 協議與 JSON-RPC 結合使用，實現跨語言調用的效果。
Dubbo 中支持的 HTTP 協議實際上使用的是 JSON-RPC 協議。
JSON-RPC 是基於 JSON 的跨語言遠程調用協議。Dubbo 中的 bbo-rpc-xml、bbo-rpc-webservice 等模塊支持的 XML-RPC、WebService 等協議與 JSON-RPC 一樣，都是基於文本的協議，只不過 JSON 的格式比 XML、WebService 等格式更加簡潔、緊湊。與 Dubbo 協議、Hessian 協議等二進制協議相比，JSON-RPC 更便於調試和實現，可見 JSON-RPC 協議還是一款非常優秀的遠程調用協議。
在 Java 體系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身體積小巧，使用方便，既可以獨立使用，也可以與 Spring 無縫集合，非常適合基於 Spring 的項目。
下面先來看看 JSON-RPC 協議中請求的基本格式：
JSON-RPC請求中各個欄位的含義如下：
在 JSON-RPC 的服務端收到調用請求之後，會查找到相應的方法並進行調用，然後將方法的返回值整理成如下格式，返回給客戶端：
JSON-RPC響應中各個欄位的含義如下：
Dubbo 使用 jsonrpc4j 庫來實現 JSON-RPC 協議，下面使用 jsonrpc4j 編寫一個簡單的 JSON-RPC 服務端示常式序和客戶端示常式序，並通過這兩個示常式序說明 jsonrpc4j 最基本的使用方式。
首先，需要創建服務端和客戶端都需要的 domain 類以及服務介面。先來創建一個 User 類，作為最基礎的數據對象：
接下來創建一個 UserService 介面作為服務介面，其中定義了 5 個方法，分別用來創建 User、查詢 User 以及相關信息、刪除 User：
UserServiceImpl 是 UserService 介面的實現類，其中使用一個 ArrayList 集合管理 User 對象，具體實現如下：
整個用戶管理業務的核心大致如此。下面我們來看服務端如何將 UserService 與 JSON-RPC 關聯起來。
首先，創建 RpcServlet 類，它是 HttpServlet 的子類，並覆蓋了 HttpServlet 的 service() 方法。我們知道，HttpServlet 在收到 GET 和 POST 請求的時候，最終會調用其 service() 方法進行處理；HttpServlet 還會將 HTTP 請求和響應封裝成 HttpServletRequest 和 HttpServletResponse 傳入 service() 方法之中。這里的 RpcServlet 實現之中會創建一個 JsonRpcServer，並在 service() 方法中將 HTTP 請求委託給 JsonRpcServer 進行處理：
最後，創建一個 JsonRpcServer 作為服務端的入口類，在其 main() 方法中會啟動 Jetty 作為 Web 容器，具體實現如下：
這里使用到的 web.xml 配置文件如下：
完成服務端的編寫之後，下面再繼續編寫 JSON-RPC 的客戶端。在 JsonRpcClient 中會創建 JsonRpcHttpClient，並通過 JsonRpcHttpClient 請求服務端：
在 AbstractProxyProtocol 的 export() 方法中，首先會根據 URL 檢查 exporterMap 緩存，如果查詢失敗，則會調用 ProxyFactory.getProxy() 方法將 Invoker 封裝成業務介面的代理類，然後通過子類實現的 doExport() 方法啟動底層的 ProxyProtocolServer，並初始化 serverMap 集合。具體實現如下：
在 HttpProtocol 的 doExport() 方法中，與前面介紹的 DubboProtocol 的實現類似，也要啟動一個 RemotingServer。為了適配各種 HTTP 伺服器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 層抽象出了一個 HttpServer 的介面。
bbo-remoting-http 模塊的入口是 HttpBinder 介面，它被 @SPI 註解修飾，是一個擴展介面，有三個擴展實現，默認使用的是 JettyHttpBinder 實現，如下圖所示：
HttpBinder 介面中的 bind() 方法被 @Adaptive 註解修飾，會根據 URL 的 server 參數選擇相應的 HttpBinder 擴展實現，不同 HttpBinder 實現返回相應的 HttpServer 實現。HttpServer 的繼承關系如下圖所示：
這里以 JettyHttpServer 為例簡單介紹 HttpServer 的實現，在 JettyHttpServer 中會初始化 Jetty Server，其中會配置 Jetty Server 使用到的線程池以及處理請求 Handler：
可以看到 JettyHttpServer 收到的全部請求將委託給 DispatcherServlet 這個 HttpServlet 實現，而 DispatcherServlet 的 service() 方法會把請求委託給對應接埠的 HttpHandler 處理：
了解了 Dubbo 對 HttpServer 的抽象以及 JettyHttpServer 的核心之後，回到 HttpProtocol 中的 doExport() 方法繼續分析。
在 HttpProtocol.doExport() 方法中會通過 HttpBinder 創建前面介紹的 HttpServer 對象，並記錄到 serverMap 中用來接收 HTTP 請求。這里初始化 HttpServer 以及處理請求用到的 HttpHandler 是 HttpProtocol 中的內部類，在其他使用 HTTP 協議作為基礎的 RPC 協議實現中也有類似的 HttpHandler 實現類，如下圖所示：
在 HttpProtocol.InternalHandler 中的 handle() 實現中，會將請求委託給 skeletonMap 集合中記錄的 JsonRpcServer 對象進行處理：
skeletonMap 集合中的 JsonRpcServer 是與 HttpServer 對象一同在 doExport() 方法中初始化的。最後，我們來看 HttpProtocol.doExport() 方法的實現：
介紹完 HttpProtocol 暴露服務的相關實現之後，下面再來看 HttpProtocol 中引用服務相關的方法實現，即 protocolBindinRefer() 方法實現。該方法首先通過 doRefer() 方法創建業務介面的代理，這里會使用到 jsonrpc4j 庫中的 JsonProxyFactoryBean 與 Spring 進行集成，在其 afterPropertiesSet() 方法中會創建 JsonRpcHttpClient 對象：
下面來看 doRefer() 方法的具體實現：
在 AbstractProxyProtocol.protocolBindingRefer() 方法中，會通過 ProxyFactory.getInvoker() 方法將 doRefer() 方法返回的代理對象轉換成 Invoker 對象，並記錄到 Invokers 集合中，具體實現如下：
本文重點介紹了在 Dubbo 中如何通過「HTTP 協議 + JSON-RPC」的方案實現跨語言調用。首先介紹了 JSON-RPC 中請求和響應的基本格式，以及其實現庫 jsonrpc4j 的基本使用；接下來我們還詳細介紹了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心類，剖析了 Dubbo 中「HTTP 協議 + JSON-RPC」方案的落地實現。
C. Android源碼解析RPC系列(一)---Binder原理
看了幾天的Binder，決定有必要寫一篇博客，記錄一下學習成果，Binder是Android中比較綜合的一塊知識了，目前的理解只限於JAVA層。首先Binder是幹嘛用的？不用說，跨進程通信全靠它，操作系統的不同進程之間，數據不共享，對於每個進程來說，它都天真地以為自己獨享了整個系統，完全不知道其他進程的存在，進程之間需要通信需要某種系統機制才能完成，在Android整個系統架構中，採用了大量的C/S架構的思想，所以Binder的作用就顯得非常重要了，但是這種機制為什麼是Binder呢？在Linux中的RPC方式有管道，消息隊列，共享內存等，消息隊列和管道採用存儲-轉發方式，即數據先從發送方緩存區拷貝到內核開辟的緩存區中，然後再從內核緩存區拷貝到接收方緩存區，這樣就有兩次拷貝過程。共享內存不需要拷貝，但控制復雜，難以使用。Binder是個折中的方案，只需要拷貝一次就行了。其次Binder的安全性比較好，好在哪裡，在下還不是很清楚，基於安全性和傳輸的效率考慮，選擇了Binder。Binder的英文意思是粘結劑，Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，這個進程一般是Server端，該對象提供了一套方法用以實現對服務的請求，而它的引用卻遍布於系統的各個進程（Client端）之中，這樣Client通過Binder的引用訪問Server，所以說，Binder就像膠水一樣，把系統各個進程粘結在一起了，廢話確實有點多。
為了從而保障了系統的安全和穩定，整個系統被劃分成內核空間和用戶空間
內核空間：獨立於普通的應用程序，可以訪問受保護的內存空間，有訪問底層硬體設備的所有許可權。
用戶空間：相對與內核空間，上層運用程序所運行的空間就是用戶空間，用戶空間訪問內核空間的唯一方式就是系統調用。一個4G的虛擬地址空間，其中3G是用戶空間，剩餘的1G是內核空間。如果一個用戶空間想與另外一個用戶空間進行通信，就需要內核模塊支持，這個運行在內核空間的，負責各個用戶進程通過Binder通信的內核模塊叫做Binder驅動，雖然叫做Binder驅動，但是和硬體並沒有什麼關系，只是實現方式和設備驅動程序是一樣的，提供了一些標准文件操作。
在寫AIDL的時候，一般情況下，我們有兩個進程，一個作為Server端提供某種服務，然後另外一個進程作為Client端,連接Server端之後，就 可以使用Server裡面定義的服務。這種思想是一種典型的C/S的思想。值得注意的是Android系統中的Binder自身也是C/S的架構，也有Server端與Client端。一個大的C/S架構中，也有一個小的C/S架構。
先籠統的說一下，在整個Binder框架中，由系列組件組成，分別是Client、Server、ServiceManager和Binder驅動程序，其中Client、Server和ServiceManager運行在用戶空間，Binder驅動程序運行內核空間。運行在用戶空間中的Client、Server和ServiceManager，是在三個不同進程中的，Server進程中中定義了服務提供給Client進程使用，並且Server中有一個Binder實體，但是Server中定義的服務並不能直接被Client使用，它需要向ServiceManager注冊，然後Client要用服務的時候，直接向ServiceManager要，ServiceManager返回一個Binder的替身（引用）給Client，這樣Client就可以調用Server中的服務了。
場景 ：進程A要調用進程B裡面的一個draw方法處理圖片。
分析 ：在這種場景下，進程A作為Client端，進程B做為Server端，但是A/B不在同一個進程中，怎麼來調用B進程的draw方法呢，首先進程B作為Server端創建了Binder實體，為其取一個字元形式，可讀易記的名字，並將這個Binder連同名字以數據包的形式通過Binder驅動發送給ServiceManager，也就是向ServiceManager注冊的過程，告訴ServiceManager，我是進程B，擁有圖像處理的功能，ServiceManager從數據包中取出名字和引用以一個注冊表的形式保留了Server進程的注冊信息。為什麼是以數據包的形式呢，因為這是兩個進程，直接傳遞對象是不行滴，只能是一些描述信息。現在Client端進程A聯系ServiceManager，說現在我需要進程B中圖像處理的功能，ServiceManager從注冊表中查到了這個Binder實體，但是呢，它並不是直接把這個Binder實體直接給Client,而是給了一個Binder實體的代理，或者說是引用，Client通過Binder的引用訪問Server。分析到現在，有個關鍵的問題需要說一下，ServiceManager是一個進程，Server是另一個進程，Server向ServiceManager注冊Binder必然會涉及進程間通信。當前實現的是進程間通信卻又要用到進程間通信，這就好象蛋可以孵出雞前提卻是要找只雞來孵蛋，確實是這樣的，ServiceManager中預先有了一個自己的Binder對象（實體），就是那隻雞，然後Server有個Binder對象的引用，就是那個蛋，Server需要通過這個Binder的引用來實現Binder的注冊。雞就一隻，蛋有很多，ServiceManager進程的Binder對象（實體）僅有一個，其他進程所擁有的全部都是它的代理。同樣一個Server端Binder實體也應該只有一個，對應所有Client端全部都是它的代理。
我們再次理解一下Binder是什麼？在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Client,ServiceManager,這樣，對於Binder通信的使用者而言，不用關心實現的細節。對Server來說，Binder指的是Binder實體，或者說是本地對象，對於Client來說，Binder指的是Binder代理對象，也就是Binder的引用。對於Binder驅動而言，在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換。
簡單的總結一下，通過上面一大段的分析，一個Server在使用的時候需要經歷三個階段
1、定義一個AIDL文件
Game.aidl
GameManager .aidl
2、定義遠端服務Service
在遠程服務中的onBind方法，實現AIDL介面的具體方法，並且返回Binder對象
3、本地創建連接對象
以上就是一個遠端服務的一般套路，如果是在兩個進程中，就可以進程通信了，現在我們分析一下，這個通信的流程。重點是GameManager這個編譯生成的類。
從類的關系來看，首先介面GameManager 繼承 IInterface ，IInterface是一個介面，在GameManager內部有一個內部類Stub，Stub繼承了Binder，（Binder實現了IBinder），並且實現了GameManager介面，在Stub中還有一個內部類Proxy，Proxy也實現了GameManager介面，一個整體的結構是這樣的
現在的問題是，Stub是什麼？Proxy又是什麼？在上面說了在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Clinet，ServiceManager，為了兩個進程的通信，系統給予的內核支持是Binder,在抽象一點的說,Binder是系統開辟的一塊內存空間，兩個進程往這塊空間裡面讀寫數據就行了，Stub從Binder中讀數據，Proxy向Binder中寫數據,達到進程間通信的目的。首先我們分析Stub。
Stub 類繼承了Binder ，說明了Stub有了跨進程傳輸的能力，實現了GameManager介面，說明它有了根據游戲ID查詢一個游戲的能力。我們在bind一個Service之後，在onServiceConnecttion的回調裡面，就是通過asInterface方法拿到一個遠程的service的。
asInterface調用queryLocalInterface。
mDescriptor，mOwner其實是Binder的成員變數，Stub繼承了Binder，在構造函數的時候，對著兩個變數賦的值。
如果客戶端和服務端是在一個進程中，那麼其實queryLocalInterface獲取的就是Stub對象，如果不在一個進程queryLocalInterface查詢的對象肯定為null，因為不同進程有不同虛擬機，肯定查不到mOwner對象的，所以這時候其實是返回的Proxy對象了。拿到Stub對象後，通常在onServiceConnected中，就把這個對象轉換成我們多定義AIDL介面。
比如我們這里會轉換成GameManager，有了GameManager對象，就可以調用後querryGameById方法了。如果是一個進程，那直接調用的是自己的querryGameById方法，如果不是一個進程，那調用了就是代理的querryGameById方法了。
看到其中關鍵的一行是
mRemote就是一個IBinder對象，相對於Stub，Proxy 是組合關系（HAS-A），內部有一個IBinder對象mRemote，Stub是繼承關系(IS-A)，直接實現了IBinder介面。
transact是個native方法，最終還會回掉JAVA層的onTransact方法。
onTransact根據調用號（每個AIDL函數都有一個編號，在跨進程的時候，不會傳遞函數，而是傳遞編號指明調用哪個函數）調用相關函數；在這個例子裡面，調用了Binder本地對象的querryGameById方法；這個方法將結果返回給驅動，驅動喚醒掛起的Client進程裡面的線程並將結果返回。於是一次跨進程調用就完成了。
***Please accept mybest wishes for your happiness and success ! ***