0. 巨石應(yīng)用

• 巨石型應(yīng)用的好處：IDE都是為開(kāi)發(fā)單個(gè)應(yīng)用設(shè)計(jì)的、容易測(cè)試——在本地就可以啟動(dòng)完整的系統(tǒng)、容易部署——直接打包為一個(gè)完整的包，拷貝到web容器的某個(gè)目錄下即可運(yùn)行.
• 對(duì)于大規(guī)模的復(fù)雜應(yīng)用，巨石型應(yīng)用會(huì)顯得特別笨重：要修改一個(gè)地方就要將整個(gè)應(yīng)用全部部署（PS：在不同的場(chǎng)景下優(yōu)勢(shì)也變成了劣勢(shì)）；編譯時(shí)間過(guò)長(zhǎng)；回歸測(cè)試周期過(guò)長(zhǎng)；開(kāi)發(fā)效率降低等。另外，巨石應(yīng)用不利于更新技術(shù)框架，除非你愿意將系統(tǒng)全部重寫(xiě)。

1. 應(yīng)用的scale cube

• 一個(gè)系統(tǒng)的擴(kuò)展過(guò)程：
  • （1）x軸，水平復(fù)制，即在負(fù)載均衡服務(wù)器后增加多個(gè)web服務(wù)器；
  • （2）z軸擴(kuò)展，是對(duì)數(shù)據(jù)庫(kù)的擴(kuò)展，即分庫(kù)分表（分庫(kù)是將關(guān)系緊密的表放在一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上，分表是因?yàn)橐粡埍淼臄?shù)據(jù)太多，需要將一張表的數(shù)據(jù)通過(guò)hash放在不同的數(shù)據(jù)庫(kù)服務(wù)器上）；
  • （3）y軸擴(kuò)展，是功能分解，將不同職能的模塊分成不同的服務(wù)。從y軸這個(gè)方向擴(kuò)展，才能將巨型應(yīng)用分解為一組不同的服務(wù).
• 系統(tǒng)的服務(wù)劃分的方法: 1) 按照用例劃分; 2) 按照資源劃分.
  • 分解的目標(biāo): 解決巨石應(yīng)用在業(yè)務(wù)急劇增長(zhǎng)時(shí)遇到的問(wèn)題.

2. 微服務(wù)的主要缺點(diǎn)

• 開(kāi)發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性, 設(shè)計(jì)服務(wù)之間的通信機(jī)制.
• 服務(wù)管理的復(fù)雜性(Docker).
• 應(yīng)用微服務(wù)架構(gòu)的時(shí)機(jī)如何把握? .

3. 架構(gòu)的關(guān)鍵問(wèn)題

• 通信機(jī)制
  • 客戶端與服務(wù)器之間的通信.
    • 添加API Gateway 來(lái)講用戶的一個(gè)請(qǐng)求, 分解為對(duì)內(nèi)部service 的一系列調(diào)用, 從而避免了一次請(qǐng)求, 多次客戶端和服務(wù)器的交互.
  • 內(nèi)部服務(wù)間的通信.
    • 基于HTTP 的同步協(xié)議(Rest, RPC).
    • 基于消息隊(duì)列的異步消息處理機(jī)制.
• 分布式數(shù)據(jù)管理
  • 處理讀請(qǐng)求.
  • 處理更新請(qǐng)求.