0. 巨石應(yīng)用
- 巨石型應(yīng)用的好處：IDE都是為開發(fā)單個應(yīng)用設(shè)計的、容易測試——在本地就可以啟動完整的系統(tǒng)、容易部署——直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行.
- 對于大規(guī)模的復雜應(yīng)用，巨石型應(yīng)用會顯得特別笨重：要修改一個地方就要將整個應(yīng)用全部部署（PS：在不同的場景下優(yōu)勢也變成了劣勢）；編譯時間過長；回歸測試周期過長；開發(fā)效率降低等。另外，巨石應(yīng)用不利于更新技術(shù)框架，除非你愿意將系統(tǒng)全部重寫。
1. 應(yīng)用的scale cube
- 一個系統(tǒng)的擴展過程：
- （1）x軸，水平復制，即在負載均衡服務(wù)器后增加多個web服務(wù)器；
- （2）z軸擴展，是對數(shù)據(jù)庫的擴展，即分庫分表（分庫是將關(guān)系緊密的表放在一臺數(shù)據(jù)庫服務(wù)器上，分表是因為一張表的數(shù)據(jù)太多，需要將一張表的數(shù)據(jù)通過hash放在不同的數(shù)據(jù)庫服務(wù)器上）；
- （3）y軸擴展，是功能分解，將不同職能的模塊分成不同的服務(wù)。從y軸這個方向擴展，才能將巨型應(yīng)用分解為一組不同的服務(wù).
- 系統(tǒng)的服務(wù)劃分的方法: 1) 按照用例劃分; 2) 按照資源劃分.
- 分解的目標: 解決巨石應(yīng)用在業(yè)務(wù)急劇增長時遇到的問題.
2. 微服務(wù)的主要缺點
- 開發(fā)人員要處理分布式系統(tǒng)的復雜性, 設(shè)計服務(wù)之間的通信機制.
- 服務(wù)管理的復雜性(Docker).
- 應(yīng)用微服務(wù)架構(gòu)的時機如何把握? .
3. 架構(gòu)的關(guān)鍵問題
- 通信機制
- 客戶端與服務(wù)器之間的通信.
- 添加API Gateway 來講用戶的一個請求, 分解為對內(nèi)部service 的一系列調(diào)用, 從而避免了一次請求, 多次客戶端和服務(wù)器的交互.
- 內(nèi)部服務(wù)間的通信.
- 基于HTTP 的同步協(xié)議(Rest, RPC).
- 基于消息隊列的異步消息處理機制.
- 客戶端與服務(wù)器之間的通信.
- 分布式數(shù)據(jù)管理
- 處理讀請求.
- 處理更新請求.
