雲架構之微服務

開頭先介紹一下微服務的優點：實現跨團隊的解藕，實現更高的併發（目前單機只能實現c10k）不用在拷貝代碼，基礎服務能夠公用，更好的支持服務治理，可以更好的兼容雲計算平臺。

 

 

rpc:向調用本地方法同樣調用遠程函數

客戶端：通常利用動態代理生成一個接口的實現類，在這個實現類裏經過網絡把接口名稱，參數，方法序列化後傳出去，而後控制同步調用仍是異步調用，異步調用須要設置一個回調函數，客戶端還須要維護負載均衡，超時處理，鏈接池管理等，鏈接池維護了和多個server的鏈接，靠此作負載均衡，當某個服務器宕機後去除該鏈接。請求上下文維護了請求ID和回調函數，超時的請求當回覆報文到達後因爲找不到請求上下文就會丟棄。

服務端：維護鏈接，網絡收到請求後反序列化得到方法名稱，接口名稱，參數名稱後經過反射進行調用，而後將結果在傳回客戶端。

序列化的方式：一種是隻序列化字段的值，反序列化的時候從新構建對象在把值設置進去，另一種方式直接將整個對象的結構序列化成二進制，前者節省空間，後者反序列化速度快，目前的序列化框架也是在反序列化時間和佔用空間之間權衡。有點相似哈夫曼編碼，或者數據庫怎麼存儲一行一行的數據。

註冊中心

通常有三種模式，f5作集中式代理，客戶端嵌入式代理例如dubbo，還有一種是綜合上面兩種，多個客戶端共用一個代理，代理做爲一個獨立進程部署在和客戶端服務器同一臺物理機上，servicemesh就是這種模式。

 

 

配置中心

配置中心的需求：保證高可用，實時通知，灰度發佈，權限控制，一鍵回滾，環境隔離（開發 測試 生產）目前的開源實現：nacos disconf apollo。

disconf:scan模塊掃描註解和監聽器，store模塊將遠程獲取到的配置存儲到本地，本地一個job檢測配置是否有變化，有變化就通知監聽器，fetch模塊從遠程經過http獲取配置，watch模塊監聽zookeeper上節點的變化，有變化就會調用fetch進行獲取.

apollo：四個模塊：portal 做爲一個管理後臺，提供管理員操做的入口。 有獨立的數據庫。 adminservice 提供配置的修改和發佈服務的底層服務，和 configservice 公用一個數據庫configdb，每次修改配置就會往數據庫裏插入一條記錄releasemessage，configservice 用一個定時任務去掃描數據庫是否有新的releasemessage，有的話就通知客戶端，而客戶端採用定時輪詢的方式去查詢  configservice 是否有新消息，這裏採用 deferredresult 異步執行。eruka爲adminservice和configservice提供了註冊發現的服務。客戶端獲取到配置文件後也會寫入磁盤。