《大型網站系統與Java中介軟體》讀書筆記 （中）
前言
只有光頭才能變強。
文字已收錄至我的GitHub倉庫，歡迎Star：https://github.com/ZhongFuCheng3y/3y
回顧上一篇：
這週週末讀了第四章，現在過來做做筆記，希望能幫助到大家。
注：在看這篇文章之前，強烈建議先看看我之前寫過的一篇SpringCloud入門文章：外行人都能看懂的SpringCloud，錯過了血虧！。看完再回頭看這篇文章，你會發現：這本書講的設計與實現在SpringCloud中幾乎都有對應的元件支援。
一、服務框架的設計
從上一篇我們講到，應用拆開了以後，不同功能/模組之間的呼叫不再單純通過本機呼叫，引入了遠端的服務呼叫
而遠端的服務呼叫這個東東會很難嗎？說白了，不就是兩臺伺服器之間通訊嗎？
這時候，你能想到什麼？必定是Socket吧。沒錯，我們通過Socket肯定是可以完成兩個系統之間的通訊的問題的。（Socket相信大家在學習基礎的時候已經寫過Demo了，這我就不多BB了）
一兩個系統的Socket寫起來沒啥，但我們應用拆分之後，系統可是會變得很多很多。
系統很多的情況下，我們在寫遠端呼叫程式碼的時候就可能要考慮到以下的問題：
- 我們肯定是不希望每次遠端呼叫的時候都貼上重複的Socket程式碼，要是呼叫遠端方法像呼叫本地方法一樣簡單就好了。
- 某個服務應用為了實現高可用，叢集了（多臺機器部署同一套應用）。那我遠端呼叫的時候選擇哪一臺機器進行呼叫？
- 網路之間的傳輸協議用現成的HTTP呢？還是自定義一套通訊協議呢？
- 因為我們想呼叫遠端方法像呼叫本地方法一樣，那麼在網路上就需要傳輸Java物件，要傳輸Java物件，就必須得對其進行序列化和反序列化的處理。能實現序列化的操作也有很多，選擇哪一種方式呢？
- 網路之間的通訊也有bio、nio、以及aio這幾種模式，一般來說我們會選擇哪種比較多？如果不瞭解nio的同學，可以閱讀我以前寫過的筆記（nio你瞭解多少？）
- ….等等等
由於系統之間的呼叫會非常多，我們自然是不希望寫重複的程式碼的，所以服務框架（也可以說是RPC框架）就應運而生了【說白了就是專門處理遠端服務呼叫的框架】。有了服務框架，我們就可以實現多個系統之間以統一
- 推薦閱讀：RPC太太太太太太太容易理解啦！
一個服務框架需要考慮的問題其實遠不止上面所列出的那些，比如說：
- 服務框架與Web應用和Web容器的關係是什麼？服務框架和應用是繫結在一起嗎？（服務框架作為Web應用的一個依賴包），還是說服務框架只是Web應用的一個擴充套件（沒有和Web應用打包繫結在一起）
- 服務框架的jar包和Web應用的jar包衝突了怎麼辦？
- 為了保證系統的穩定性，流量控制也應該要考慮到
- 在遠端呼叫的時候，需不需要以更細粒度的方式來進行選擇（之前說的是選擇哪臺機器，但可以細粒度到機器下的介面或者方法）
- ....等等
二、服務框架的技術實現思路
在書中給出了設計服務框架時需要考慮的問題的同時也給出了一些實現思路，我摘錄一些我覺得比較有參考意義的說說。
2.1 像本地一樣呼叫遠端服務
比如服務消費方在執行
orderService.buy("HHKB鍵盤")時，實質上呼叫的是遠端的服務。
這用到啥技術？明顯就是動態代理（給女朋友講解什麼是代理模式）
在實現的時候有三個基礎屬性可以參考一下：
- interfaceName— 確定呼叫的是哪一個介面
- version— 如果介面進行升級了，可以使用version來進行區分和隔離
- group— 對遠端服務的機器進行分組，那麼呼叫的時候就可以選擇不同的分組來呼叫（呼叫者對統一服務的呼叫進行隔離）
2.2 其他
- 當遠端呼叫服務的時候，不需要每次都要去註冊中心查詢可用的地址，而是把地址快取在呼叫方。當服務有變化的時候，主動告訴呼叫者就行了。
- 流量控制一般會基於兩個維度去考慮：一、自身的介面和方法。二、請求的來源
- 並不是所有的請求都要經過服務提供者。像走快取這樣頻繁的操作（而且大多數都是會成功的），直接在呼叫方呼叫就ok了
最後
總的來說，書的第四章主要是在講解在設計服務框架的時候應該要考慮到哪些方面，可以以什麼方案來解決，看得還是非常過癮的（這只是我的個人筆記，書上還有很多的內容）。強烈建議配合我之前寫過的一篇SpringCloud入門文章：外行人都能看懂的SpringCloud，錯過了血虧！食用。
樂於輸出乾貨的Java技術公眾號：Java3y。公眾號內有200多篇原創技術文章、海量視訊資源、精美腦圖，關注即可獲取！
覺得我的文章寫得不錯，點