《大型網站系統與Java中間件》讀書筆記 （中）

前言

只有光頭才能變強。

文本已收錄至我的GitHub倉庫，歡迎Star：https://github.com/ZhongFuCheng3y/3y

回顧上一篇：

• 《大型網站系統與Java中間件》讀書筆記（一）

這周周末讀了第四章，現在過來做做筆記，希望能幫助到大家。

註：在看這篇文章之前，強烈建議先看看我之前寫過的一篇SpringCloud入門文章：外行人都能看懂的SpringCloud，錯過了血虧！。看完再回頭看這篇文章，你會發現：這本書講的設計與實現在SpringCloud中幾乎都有對應的組件支持。

一、服務框架的設計

從上一篇我們講到，應用拆開了以後，不同功能/模塊之間的調用不再單純通過本機調用，引入了遠程的服務調用。

而遠程的服務調用這個東東會很難嗎？說白了，不就是兩台伺服器之間通信嗎？

這時候，你能想到什麼？必定是Socket吧。沒錯，我們通過Socket肯定是可以完成兩個系統之間的通信的問題的。（Socket相信大家在學習基礎的時候已經寫過Demo了，這我就不多BB了）

一兩個系統的Socket寫起來沒啥，但我們應用拆分之後，系統可是會變得很多很多。

系統很多的情況下，我們在寫遠程調用代碼的時候就可能要考慮到以下的問題：

1. 我們肯定是不希望每次遠程調用的時候都貼上重覆的Socket代碼，要是調用遠程方法像調用本地方法一樣簡單就好了。
2. 某個服務應用為了實現高可用，集群了（多台機器部署同一套應用）。那我遠程調用的時候選擇哪一臺機器進行調用？
3. 網路之間的傳輸協議用現成的HTTP呢？還是自定義一套通信協議呢？
4. 因為我們想調用遠程方法像調用本地方法一樣，那麼在網路上就需要傳輸Java對象，要傳輸Java對象，就必須得對其進行序列化和反序列化的處理。能實現序列化的操作也有很多，選擇哪一種方式呢？
5. 網路之間的通訊也有bio、nio、以及aio這幾種模式，一般來說我們會選擇哪種比較多？如果不瞭解nio的同學，可以閱讀我以前寫過的筆記（nio你瞭解多少？）
6. ….等等等

由於系統之間的調用會非常多，我們自然是不希望寫重覆的代碼的，所以服務框架（也可以說是RPC框架）就應運而生了【說白了就是專門處理遠程服務調用的框架】。有了服務框架，我們就可以實現多個系統之間以統一的方式來進行遠程調用了。

• 推薦閱讀：RPC太太太太太太太容易理解啦！

一個服務框架需要考慮的問題其實遠不止上面所列出的那些，比如說：

• 服務框架與Web應用和Web容器的關係是什麼？服務框架和應用是綁定在一起嗎？（服務框架作為Web應用的一個依賴包），還是說服務框架只是Web應用的一個擴展（沒有和Web應用打包綁定在一起）
• 服務框架的jar包和Web應用的jar包衝突了怎麼辦？
• 為了保證系統的穩定性，流量控制也應該要考慮到
• 在遠程調用的時候，需不需要以更細粒度的方式來進行選擇（之前說的是選擇哪台機器，但可以細粒度到機器下的介面或者方法）
• ....等等

二、服務框架的技術實現思路

在書中給出了設計服務框架時需要考慮的問題的同時也給出了一些實現思路，我摘錄一些我覺得比較有參考意義的說說。

2.1 像本地一樣調用遠程服務

比如服務消費方在執行orderService.buy("HHKB鍵盤")時，實質上調用的是遠端的服務。

這用到啥技術？明顯就是動態代理（給女朋友講解什麼是代理模式）

在實現的時候有三個基礎屬性可以參考一下：

• interfaceName— 確定調用的是哪一個介面
• version— 如果介面進行升級了，可以使用version來進行區分和隔離
• group— 對遠程服務的機器進行分組，那麼調用的時候就可以選擇不同的分組來調用（調用者對統一服務的調用進行隔離）

2.2 其他

1. 當遠程調用服務的時候，不需要每次都要去註冊中心查找可用的地址，而是把地址緩存在調用方。當服務有變化的時候，主動告訴調用者就行了。
2. 流量控制一般會基於兩個維度去考慮：一、自身的介面和方法。二、請求的來源
3. 並不是所有的請求都要經過服務提供者。像走緩存這樣頻繁的操作（而且大多數都是會成功的），直接在調用方調用就ok了

最後

總的來說，書的第四章主要是在講解在設計服務框架的時候應該要考慮到哪些方面，可以以什麼方案來解決，看得還是非常過癮的（這隻是我的個人筆記，書上還有很多的內容）。強烈建議配合我之前寫過的一篇SpringCloud入門文章：外行人都能看懂的SpringCloud，錯過了血虧！食用。

樂於輸出乾貨的Java技術公眾號：Java3y。公眾號內有200多篇原創技術文章、海量視頻資源、精美腦圖，關註即可獲取！

覺得我的文章寫得不錯，點贊！