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

前言

只有光頭才能變強。

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

回顧上一篇：

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

這週週末讀了第四章，如今過來作作筆記，但願能幫助到你們。

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

1、服務框架的設計

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

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

這時候，你能想到什麼？一定是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、服務框架的技術實現思路

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

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

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

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

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

• interfaceName— 肯定調用的是哪個接口
• version— 若是接口進行升級了，可使用version來進行區分和隔離
• group— 對遠程服務的機器進行分組，那麼調用的時候就能夠選擇不一樣的分組來調用（調用者對統一服務的調用進行隔離）

2.2 其餘

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

最後

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

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

以爲個人文章寫得不錯，點贊！