Java系統和PHP系統相互調用

1、HTTP JSON方式的缺點

1. JSON序列化效率低
2. 多語言服務治理功能低

2、關於RPC框架

RPC 框架大體分爲兩類，一種是偏重服務治理，另外一種側重跨語言調用

2.1 服務治理型

特色

功能豐富，提供高性能的遠程調用、服務發現及服務治理能力，適用於大型服務的服務解耦及服務治理，對於特定語言(Java)的項目能夠實現透明化接入。缺點是語言耦合度較高，跨語言支持難度較大。

經常使用框架

• Dubbo
• Motan

2.2 跨語言調用型

特色

側重於服務的跨語言調用，可以支持大部分的語言進行語言無關的調用，很是適合多語言調用場景。但這類框架沒有服務發現相關機制，實際使用時須要代理層進行請求轉發和負載均衡策略控制。

經常使用框架

• Thrift
• gRPC

3、如何提供服務給PHP系統

Dubbo(阿里開源)

3.1 Dubbo + dubbo-php-framework

特色

能夠實現php調用php，php調用java(dubbo)，java(dubbo)調用php，Java調Java，真正的跨語言

缺點

開發活躍程度極低，社區小，資料少，沒有release版本

3.2 Dubbo Restful（合併自Dubbox）

特色

顯著簡化企業內部的異構系統之間的（跨語言）調用。
服務消費場景：

1. 非dubbo的消費端調用dubbo的REST服務（non-dubbo --> dubbo）
2. dubbo消費端調用dubbo的REST服務 （dubbo --> dubbo）
3. dubbo的消費端調用非dubbo的REST服務 （dubbo --> non-dubbo）

問題

1. Dubbo REST的服務能和Dubbo註冊中心、監控中心集成嗎？

   能夠的，並且是自動集成的，也就是你在dubbo中開發的全部REST服務都會自動註冊到服務冊中心和監控中心，能夠經過它們作管理。
   可是，只有當REST的消費端也是基於dubbo的時候，註冊中心中的許多服務治理操做才能徹底起做用。而若是消費端是非dubbo的，天然不受註冊中心管理，因此其中不少操做是不會對消費端起做用的。

2. Dubbo REST中如何實現負載均衡和容錯（failover）？

   若是dubbo REST的消費端也是dubbo的，則Dubbo REST和其餘dubbo遠程調用協議基本徹底同樣，由dubbo框架透明的在消費端作load balance、failover等等。
   若是dubbo REST的消費端是非dubbo的，甚至是非java的，則最好配置服務提供端的軟負載均衡機制，目前可考慮用LVS、HAProxy、 Nginx等等對HTTP請求作負載均衡。

montan（微博開源）

3.3 motan + motan-php

Java系統使用motan提供服務，php系統使用Motan-PHP（PHP client）調用服務。

特色

motan暫不支持以服務注入方式引用yar 服務（使用motan做爲yar client）。
目前yar協議主要解決java與php互通的問題，當java做爲服務端，php做爲client端，php能夠在不作任何修改的狀況下經過yar 協議使用java的服務。
而使用php作server、java作client的場景下（通常這種場景比較少），php的yar server不支持註冊服務等功能，因此java做爲client 時也沒有必要經過motan調用服務。yarclient是個單獨的小模塊，是個相似httpclient這樣的簡易客戶端，只能經過域名或ip訪問yar服務。

缺點

只支持PHP系統調用Java系統，沒有stable release版本，文檔不多，社區小，開發活躍程度低。總體不如Dubbo+dubbo-php-framework方式

3.4 motan Restful

模仿Dubbo Restful，很相似，從文檔上對比，不如Dubbo Restful

3.5 Client + Agent(還未徹底開源)

大概是使用motan + motan-go(agent)等實現。朝着weibo mesh的服務化方向，將 Motan Agent定位爲統一服務管理的執行節點。

實現方式

爲不一樣語言提供很是輕量的 Client，只實現與 Agent 的交互和必要的請求序列化能力；提供一個 local 的 Agent 代理，可以提供不一樣 RPC 協議交互能力，以及統一的服務治理能力與標準，服務治理的絕大部分功能都在語言無關的 Agent 中實現。經過使用 Agent，能夠爲相似 PHP 這樣的解釋型語言提供長連接複用能力，提升請求性能。

4、跨語言服務化

阿里Dubbo和微博motan都稱本身框架有多語言服務化功能，都在開發中，都還不夠成熟

4.1 挑戰

HTTP RESTful API

HTTP 自己就是語言無關的協議，通常由服務提供方與使用方經過文檔來進行服務約定。這也是目前使用很是普遍的跨語言交互方式，HTTP服務的服務治理能力通常依賴於代理層和服務調用方本身實現，通常代理服務須要單獨部署，全部請求流量經由代理服務進行轉發。例如使用 nginx 提供基礎的負載均衡與流量控制等治理能力就是最簡單的跨語言服務治理方案。

HTTP的跨語言服務化，有些方案選擇了爲特定語言實現強大服務治理能力，對其餘語言提供兼容能力，例如Spring Cloud爲Java 服務提供完整的服務治理能力，包括服務發現、路由器、過濾器、配置管理、熔斷器等等。但很難爲不一樣語言提供統一的服務治理能力，特別是在 Client 側的一些服務治理能力，不一樣語言都須要作相同功能的開發。

還有一些方案使用本機代理的方式，例如envoy、linkerd等能夠部署到單機的 HTTP 代理服務，在代理服務中集成統一服務發現與治理能力。這種方案可以作到不一樣語言的Client和 Server 都提供相同的服務治理能力，但服務治理的功能很難作到前一種方案那麼強大。

RPC

使用 RPC 做爲服務調用方式時，跨語言與服務治理也很難同時知足，對於跨語言型的 RPC 協議，例如 gRPC 等，都可以提供不一樣語言交互的能力，可是相關的服務治理功能尚未那麼完善，作到了’交互’，但還沒法作到’治理’。使用跨語言型 RPC 框架時通常會選擇使用 HTTP（HTTP2）做爲通訊協議，這樣能夠直接應用 HTTP 方式的服務治理功能；

對於服務治理型RPC，因爲選擇了在 Client 端進行服務發現與治理，若是要實現不一樣語言統一的服務治理能力，須要在不一樣語言的一側都實現相同的功能。實現起來也至關的困難。所以大部分服務治理型 RPC 專一與爲特定語言提供完善的治理能力。

4.2 方式

1. 兼容HTTP協議，增長HTTP RESTful協議

例如Dubbo Restful和motan Restful。這種方案將 Java 語言的 RPC 調用方式與其餘語言獨立開來，只針對 Java Server 端提供，沒有爲其餘語言提供服務治理能力。因爲只須要作 Java 協議的開發，這種方案研發和維護成本很低，不過可以提供的統一服務治理能力就很低了。

2. 爲不一樣語言提供RPC模塊

例如Dubbo + dubbo-php-framework方式。這種方案能作到最貼近不一樣語言的使用習慣，能夠爲不一樣語言提供徹底一致的服務治理能力，不管是做爲 Server 端仍是 Client 端。但這種方式也是成本最高的，包括開發不一樣語言的版本，以及後續的功能升級與版本維護代價都很是高。

3. 開發一個 Agent 模塊，實現絕大部分的服務治理能力

例如motan Client + Agent方式。Agent在不一樣服務的Server或Client側運行。而後爲不一樣語言開發一個很輕量的 Client 與 Agent 進行交互，因爲 Client 只實現必要的交互功能，下降了不一樣語言版本的開發量與維護的成本。

5、可考慮的方案

1. （若是是JSON效率低）考慮使用Google Protocol Buffers, thrift, Hessian等更高效序列化方式。
2. （若是是服務治理功能低）保持原來HTTP+JSON方式不變，優化服務治理功能
3. 本身基於已有開源框架二次開發(參考motan Client + Agent思路)
4. 使用Dubbo Restful

6、參考資料

1. 微博輕量級RPC框架Motan正式開源：支撐千億調用
2. 微博開源的Motan RPC最新進展：新增跨語言及服務治理支持
3. 跨語言統一治理、Golang，談談另闢蹊徑的開源RPC框架Motan
4. 在Dubbo中開發REST風格的遠程調用（RESTful Remoting）
5. https://github.com/weibocom/motan/issues/186#issuecomment-243055131
6. 跨語言統一治理、Golang，談談另闢蹊徑的開源RPC框架Motan

7、其餘相關資料

1. 貝聊系統架構服務化之路
2. 逆天：蘑菇街下單平臺演進，從PHP到Java
3. 服務化框架技術選型實踐
4. 餓了麼分佈式服務治理及優化經驗
5. 微博平臺的RPC服務化實踐
6. 多語言支持