RPC（Remote Promote Call）: 一種程序間通訊方式。允許像呼叫本地服務一樣呼叫遠端服務。

RPC框架的主要目標就是讓遠端服務呼叫更簡單、透明。RPC框架負責遮蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進位制）和通訊細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠端服務介面即可，並不需要關心底層通訊細節和呼叫過程。

RPC結構圖如下: 

 從頭開始挨個分析解釋: 

使用者訪問時是根據域名來訪問的, 光根據域名是找不到伺服器的地址的(www.baidu.com伺服器在哪?), 訪問要到達的第一個地方就是DNS伺服器, 由DNS告訴你你訪問的這個域名對應的是哪個(些)IP, 從圖中可以看到所有的訪問都會經過DNS, 所以DNS是負載最重的地方, 不過不用擔心DNS的硬體賊強(人家有錢, 就是幹這個活的), 所以DNS可以幫我們做第一次請求分發,比如把60%的請求發給一臺nginx伺服器, 剩下40%分給另一臺nginx 

防火牆是整個網際網路公司直接與外界互動的部分, 經過防火牆的篩選後請求才能進入公司內部進行求請求的處理

nginx是用來負載均衡的 , 即使nginx是C寫的效能高也有承受限度, 所以併發量過高的時候需要DNS幫忙做這個總的分發者, 分發到多臺nginx同時工作, 比如阿里雙十一的時候每秒的併發訪問量可以超億, 絕對不是一臺nginx能承受的 , nginx根據訪問的域名/IP/埠把請求發到對應的業務集群系統中

業務系統每個業務都是一個甚至多個系統叢集, 這些叢集只負責接受請求, 呼叫所需要的服務(微伺服器) 再組裝結果返回資料,這裡沒有真正的業務邏輯, 也就是SSM框架裡的controller的作用,像呼叫本地的service一樣呼叫微服務(當然呼叫的時候是要經過一些協議,申請等像zookeeper, spring cloud), 業務系統的數量視公司規模而定, 大型的網際網路公司大概有幾百個系統叢集

真正業務的邏輯分析處理是在微服務部分, 根據規模大小可能有數千個微服務,每個微服務可能有幾百個介面,也就是一個公司可能有數十萬的介面, 是不是懷疑一個公司有沒有這麼多程式設計師來開發維護這麼多介面? 以美團為例, 美團大概有1萬個程式設計師, 平均下來也就不是那麼不可能了. 微服務雖然叫微卻不一定小, 視服務的複雜度和訪問量而定, 重點的一些微服務是一臺伺服器不能承載的, 微服務也可以是像業務系統一樣的叢集 .

具體能有什麼微服務呢?

比如訊息佇列服務,當某些時段訪問量突增(如雙十一) , 伺服器不能及時處理劇增的併發訪問, 但是訪問又不斷髮來, 來不及處理又不能丟失(請求就是公司的錢吶 , 比如你點選了購買,這個請求丟失了, 又點一次又丟失了...)就需要訊息佇列來把所有請求排個隊, 即使即使處理不了 請求也不能丟, 因為請求的突增是活動導致, 隨時間會慢慢下降, 訊息佇列就像一個緩衝池一樣,來不及處理就先存著.

比如訊息推送服務, 幾乎每個網際網路公司都會給使用者推送一些訊息, 看起來簡單的功能其實非常重要也是一個叢集來處理實現, 不過現在很多公司選擇交給第三方公司來做推送, 例如極光推送, 不止訊息推送, 很多服務都是可以買的, 很多較小的公司沒有實力做一套自己的微服務, 而大公司有資源, 實力雄厚,可以拿出自己閒置的資源來賣服務, 如阿里騰訊這種量級的公司就可以賣服務給小公司, 當然也不是說買服務的都是實力不夠的公司, 對於一些不擅長的領域的服務, 完全可以交給擅長的公司來做, 因為自己從零開始搭建的成本太大, 如果不是公司的核心的話倒不如交給擅長這個領域的公司, 比如微信的語音識別用的就是科大訊飛的技術

再比如檔案儲存服務, 和快取服務, 都是服務裡的大頭, 用叢集來實現

這些服務視其重要成都而定, 對於公司來說很多資訊就是錢, 一些資訊的丟失是毀滅性的災難, 這些重要的資料理應存在持久資料庫中,但是考慮到效能,我們不可能處理一條請求再等待資料存到硬盤裡得到確認再回復結果, 我們只能把資料先存在快取中(redis),對於一些很重要的資料, 如使用者請求的訊息佇列, 必須做備份和容災(一些不可預知的災難, 斷電,火災地震海嘯隕石撞擊地球....)容災的方式有很多, 比如說建立主從快取, 兩個伺服器(叢集)在較遠的地方, 一個當機了還可以拿另一個應急

最後的資料庫就不用說了, 容災備份是必須的,資料庫也就是公司錢袋子