之前的面試經歷中，除了經常被問到 HTTP 相關的知識外，還有被問過 http 與 rpc 的區別的。再加上工作中經常與公司的一些DSF應用打交道，於是我又會聯想到 dubbo，那麼今天要梳理的內容關鍵詞就有了這些： http、rpc、dsf、dubbo 。

一、HTTP 和 RPC

首先，http 與 rpc 有什麼區別這個問題不太嚴謹，因為這倆就不是一個層級的東西。

HTTP

這個大家太熟悉了吧？日常接觸最多的恐怕就是各種http協議的介面了。

沒錯，http它是一個協議。

其他在這裡就不打算鋪開了，以前整理過一些內容，有需要的可以跳轉翻翻看：

• 一、http介紹、TCP/IP 協議族
• 二、IP，TCP 和 DNS、三次握手
• 三、HTTP 協議基礎、四次揮手
• 四、HTTP 缺點
• 五、HTTPS 中的加密、證書介紹，不一直使用 HTTPS 的原因

RPC

RPC 是一種技術的代名詞，全稱是遠端過程呼叫。

遠端？那是不是也有本地過程呼叫？

沒錯，舉個例子說明一下：

• 本地過程呼叫：你的電腦上啟動了一個服務A，執行程式的時候服務A裡的各種方法的互相呼叫，就是本地了。
• 遠端過程呼叫：而隔壁小王也啟動了一個服務B，他還說他裡面提供了一個功能非常勁爆的方法，你也想去呼叫，這就是遠端了。

而至於你怎麼呼叫到小王伺服器裡的方法，那就是個實現方式的問題了。你為了簡單，直接走http協議也行。如果覺得http滿足不了需求，那麼也可以基於tcp自定義一個協議。

遠端呼叫過程

遠端呼叫過程大概就是下圖所示：

二、DSF

在工作中我發現公司有不少應用的名字是 DSF 打頭的，DSF（Distributed Service Framework）其實就是指分散式服務框架。

簡單介紹 2 個點：為什麼要用到分散式、這套DSF的包含的內容。

為什麼要用到分散式

為什麼要用到分散式服務？換個方式問那就是：分散式解決了什麼問題。

首先，分散式架構是由單體架構演進而來，我司的業務系統也不例外。業務早期為了降低開發成本，實現快速上線，通常使用單體架構，所有的業務模組都在同一個應用裡。

隨著業務規模的擴張，單體應用的缺點就暴露出來，比如：

• 系統耦合性高，當後面增加的功能越來越多，程式碼量巨增的時候，之前某個主程腦海中劃分好的模組邊界可能越來越模糊，導致呼叫關係混亂。
• 改一贈二出現越來越多，經常存在開發修改了某個功能，而導致其他的功能有問題。
• 某個功能有問題，整個一起回滾。
• 語言單一，不能根據場景選擇更合適的語言。比如其中有個模組系統主要是大資料分析，用 python 自然更加合適，因為它有豐富的類庫。
• 系統不易於拓展部署，比如系統中有一個功能流量很大，頂不住了就要加機器，那麼在新機器上還是部署整個應用，不能單獨的部署這個大流量的服務，會造成一定的資源浪費。
  。。。

為了解決這些問題，於是把之前的業務進行垂直拆分成多個系統。系統與系統之間通過網路互動來完成各項業務處理，每個系統互相獨立，可以單獨部署。這種多個元件合作對外提供服務的形式，就是分散式了。

但是分散式同樣也有它的缺點：

• 從之前的單應用呼叫，現在變成了多個應用直接的互動，呼叫鏈路變長，帶來了網路開銷，同時也給定位問題增加了難度。
• 為了讓你的應用更可靠，還有考慮其他的異常情況，比如呼叫失敗、因某些問題導致的高頻呼叫，對此還得做些 限流、熔斷之類的措施。
• 出現問題，可能會涉及多個服務的回滾，互相之間會有影響。
• 環境變複雜了，增加了測試的複雜度。
  。。。

簡單來說，分散式幫我們克服了單體帶來的瓶頸，但是為了分散式服務的穩定性，我們需要考慮更多的東西。

DSF包含的內容

那麼一套分散式服務平臺都有哪些內容，這裡簡單列舉一下（以我司自研為例）：

• 服務註冊：服務提供方上傳契約資訊，契約中包含服務組資訊、服務資訊、API資訊等。
• 服務發現：服務消費方定址，基於某種粒度可以找到需要。
• 服務呼叫：自定義超時時間、失敗重試次數等，支援同步、非同步呼叫等。
• 負載均衡：比如支援輪詢策略。
• 閘道器：還可以通過閘道器對外提供一些rest api呼叫。
• 健康檢查：對服務提供方例項進行健康檢查。
• 服務拓撲：應用呼叫的上下游鏈路拓撲圖。
• 服務監控：展示服務執行狀態、呼叫指標等。
• 報警：當某個服務的例項異常數超過閾值，觸發報警。
• 限流：用於保護系統。
• web前臺：方便檢視各種資訊，各種常用功能的入口。
  ...

三、Dubbo

對於分散式服務框架，如果有自研能力的話，可以結合公司業務實際情況進行高度定製化。如果初期不具備這樣的條件，很多公司會選擇成熟的開源框架直接使用，dubbo 就是這樣的框架。

Dubbo 是阿里巴巴 2011年開源的一個基於 Java 的 RPC 框架，它實現了面向介面的代理 RPC 呼叫，並且可以配合 ZooKeeper 等元件實現服務註冊和發現功能，並且擁有負載均衡、容錯機制等。

dubbo 架構

這是官方文件的架構圖，描述了 Dubbo 微服務元件與各個中心的互動過程。

• Registry 註冊中心：協調 Consumer 與 Provider 之間的地址註冊與發現。
• ConfigCenter 配置中心：儲存 Dubbo 啟動階段的全域性配置，保證配置的跨環境共享與全域性一致性；負責服務治理規則（路由規則、動態配置等）的儲存與推送。
• Metadata 元資料中心：接收 Provider 上報的服務介面元資料，為 Admin 等控制檯提供運維能力（如服務測試、介面文件等）；作為服務發現機制的補充，提供額外的介面/方法級別配置資訊的同步能力，相當於註冊中心的額外擴充套件。

以上三個中心並不是執行 Dubbo 的必要條件，使用者完全可以根據自身業務情況決定只啟用其中一個或多個，以達到簡化部署的目的。通常情況下，所有使用者都會以獨立的註冊中心 開始 Dubbo 服務開發，而配置中心、元資料中心則會在微服務演進的過程中逐步的按需被引入進來。

所以，如果想快速實現一個分散式服務框架，就可以基於dubbo的方案來進行開發，既可以拿來就用，後續也可以進行二次開發。