之前的面試經歷中，除了經常被問到 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的方案來進行開發，既可以拿來就用，後續也可以進行二次開發。