應(yīng)用架構(gòu)經(jīng)過(guò)不同階段，逐漸由單一發(fā)展至分布式，由功能化發(fā)展至服務(wù)化，主要的幾類架構(gòu)如下：

單一應(yīng)用架構(gòu)（ORM）-> 垂直應(yīng)用架構(gòu)（MVC）-> ?分布式服務(wù)架構(gòu)（RPC）-> 流動(dòng)計(jì)算架構(gòu)（SOA）

應(yīng)用架構(gòu)演進(jìn)

以電商系統(tǒng)為例，按演變階段介紹各個(gè)應(yīng)用架構(gòu)。該系統(tǒng)功能：用戶模塊、商品模塊以及交易模塊。

Phase 1：?jiǎn)螜C(jī)構(gòu)建網(wǎng)站

單機(jī)構(gòu)建網(wǎng)站，是一個(gè)高內(nèi)聚版本，所有功能部署在一起。通過(guò)一個(gè)容器和JSP/Servlet技術(shù)或通過(guò)一些開(kāi)源的框架如SSM以及SSH，通過(guò)數(shù)據(jù)庫(kù)管理系統(tǒng)來(lái)存儲(chǔ)數(shù)據(jù)。

單機(jī)下的系統(tǒng)結(jié)構(gòu)如下：

單機(jī)

優(yōu)點(diǎn)：

1. 成本比較低，適合功能少又簡(jiǎn)單的應(yīng)用場(chǎng)景。

缺點(diǎn)：

1. 無(wú)法適應(yīng)高流量

2. 部署成本高

Phase 2：?數(shù)據(jù)庫(kù)應(yīng)用服務(wù)器分離

隨著訪問(wèn)量上升，服務(wù)器的負(fù)載也隨之逐漸提高，相較于單機(jī)系統(tǒng)的無(wú)法適應(yīng)高流量，提升網(wǎng)站的負(fù)載能力成為了首要課題。若代碼層面難以優(yōu)化，通過(guò)增加機(jī)器的數(shù)量是提升整體性能一個(gè)方式。

優(yōu)點(diǎn)：

1. 提高系統(tǒng)的負(fù)載能力

2. 較高的性價(jià)比

通過(guò)增加機(jī)器的數(shù)量，將數(shù)據(jù)庫(kù)服務(wù)器和web服務(wù)器拆分開(kāi)來(lái)。

優(yōu)點(diǎn)：

1. 提高單機(jī)的負(fù)載能力

2. 提高單機(jī)的容災(zāi)能力

此架構(gòu)下的系統(tǒng)結(jié)構(gòu)：

多機(jī)

Phase 3：分布式服務(wù)器

雖然我們已經(jīng)將服務(wù)和存儲(chǔ)分離，但隨著訪問(wèn)量繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器也無(wú)法滿足需求。在假設(shè)數(shù)據(jù)庫(kù)服務(wù)器沒(méi)有壓力的情況下，此時(shí)通過(guò)將服務(wù)器部署至更多的機(jī)器，即應(yīng)用服務(wù)器從一臺(tái)變成多臺(tái)，把用戶的請(qǐng)求分散到不同的服務(wù)器中進(jìn)響應(yīng)，進(jìn)而提高負(fù)載能力。

而服務(wù)器之間不存在直接交互，所有的服務(wù)器都是依賴數(shù)據(jù)庫(kù)各自對(duì)外提供服務(wù)。此架構(gòu)下系統(tǒng)結(jié)構(gòu)如下：

?分布式服務(wù)器

此階段有4個(gè)問(wèn)題隨之而來(lái)：

1. 負(fù)載均衡的問(wèn)題？

通常有以下幾種解決方案：

1.1?HTTP重定向

即應(yīng)用層的請(qǐng)求轉(zhuǎn)發(fā)。當(dāng)用戶的請(qǐng)求到了HTTP重定向負(fù)載均衡服務(wù)器，服務(wù)器根據(jù)算法要求用戶重定向，用戶收到重定向請(qǐng)求后，再次請(qǐng)求真正的集群。

優(yōu)點(diǎn)：簡(jiǎn)單易用

缺點(diǎn)：性能較差?

1.2?DNS域名解析負(fù)載均衡

即在用戶請(qǐng)求DNS服務(wù)器，獲取域名對(duì)應(yīng)的IP地址時(shí)，DNS服務(wù)器直接給出負(fù)載均衡后的服務(wù)器IP。

優(yōu)點(diǎn)：交給DNS處理，無(wú)需人為維護(hù)負(fù)載均衡服務(wù)器

缺點(diǎn)：

1. 當(dāng)一個(gè)應(yīng)用服務(wù)器出現(xiàn)問(wèn)題，無(wú)法及時(shí)通知DNS

2. DNS負(fù)載均衡的控制權(quán)在域名服務(wù)商，不利于管理

1.3?反向代理服務(wù)器

在用戶的請(qǐng)求到達(dá)反向代理服務(wù)器時(shí)，由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。

優(yōu)點(diǎn)：部署簡(jiǎn)單

缺點(diǎn)：代理服務(wù)器可能成為性能瓶頸，針對(duì)大文件

1.4?IP層負(fù)載均衡

在請(qǐng)求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過(guò)修改請(qǐng)求的目的IP地址，從而實(shí)現(xiàn)請(qǐng)求的轉(zhuǎn)發(fā)，做到負(fù)載均衡。

優(yōu)點(diǎn)：性能更好

缺點(diǎn)：負(fù)載均衡器的寬帶成為瓶頸

1.5?數(shù)據(jù)鏈路層負(fù)載均衡

在請(qǐng)求到達(dá)負(fù)載均衡器后，負(fù)載均衡器通過(guò)修改請(qǐng)求的MAC地址，從而做到負(fù)載均衡，與IP負(fù)載均衡不一樣的是，當(dāng)請(qǐng)求訪問(wèn)完服務(wù)器之后，直接返回客戶。而無(wú)需再經(jīng)過(guò)負(fù)載均衡器。

2. 調(diào)度的算法和策略？

常用的集群調(diào)度算法如下：

2.1?rr輪詢調(diào)度算法

輪詢分發(fā)請(qǐng)求。

優(yōu)點(diǎn)：容易實(shí)現(xiàn)

缺點(diǎn)：未考慮每臺(tái)服務(wù)器的處理能力

2.2?wrr加權(quán)調(diào)度算法

為每個(gè)服務(wù)器設(shè)置權(quán)值Weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。

優(yōu)點(diǎn)：考慮不同服務(wù)器處理能力不同

2.3?sh原地址散列算法

提取用戶IP，根據(jù)散列函數(shù)得出一個(gè)key，再根據(jù)靜態(tài)映射表，查處對(duì)應(yīng)的value，即目標(biāo)服務(wù)器IP。過(guò)目標(biāo)機(jī)器超負(fù)荷，則返回空。

優(yōu)點(diǎn)：實(shí)現(xiàn)同一個(gè)用戶訪問(wèn)同一個(gè)服務(wù)器

2.4?lc最少連接算法

優(yōu)先把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。

優(yōu)點(diǎn)：使集群中各個(gè)服務(wù)器的負(fù)載更加均勻

2.5?dh目標(biāo)地址散列算法

原理同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來(lái)做哈希。

優(yōu)點(diǎn)：實(shí)現(xiàn)同一個(gè)用戶訪問(wèn)同一個(gè)服務(wù)器

2.6?wlc加權(quán)最少連接算法

在lc的基礎(chǔ)上，為每臺(tái)服務(wù)器加上權(quán)值。算法為：（活動(dòng)連接數(shù) * 256 + 非活動(dòng)連接數(shù)） ÷ 權(quán)重，計(jì)算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。

優(yōu)點(diǎn)：根據(jù)服務(wù)器的能力分配請(qǐng)求

2.7 sed最短期望延遲算法

其實(shí)sed跟wlc類似，區(qū)別是不考慮非活動(dòng)連接數(shù)。算法為：（活動(dòng)連接數(shù) +1 ) * 256 ÷ 權(quán)重，同樣計(jì)算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。

2.8?nq永不排隊(duì)算法

改進(jìn)的sed算法。我們想一下什么情況下才能“永不排隊(duì)”，那就是服務(wù)器的連接數(shù)為0的時(shí)候，那么假如有服務(wù)器連接數(shù)為0，均衡器直接把請(qǐng)求轉(zhuǎn)發(fā)給它，無(wú)需經(jīng)過(guò)sed的計(jì)算。

3. 集群請(qǐng)求返回模式問(wèn)題？

3.1?NAT

負(fù)載均衡器接收用戶的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理請(qǐng)求返回給均衡器，均衡器再重新返回給用戶。

3.2?DR

負(fù)載均衡器接收用戶的請(qǐng)求，轉(zhuǎn)發(fā)給具體服務(wù)器，服務(wù)器處理請(qǐng)求后直接返回給用戶。

缺點(diǎn)：系統(tǒng)需支持IP Tunneling協(xié)議，不易跨平臺(tái)

3.3?TUN

同DR，但無(wú)需IP Tunneling協(xié)議，跨平臺(tái)性好，可以支持大部分系統(tǒng)都。

4. 集群Session一致性問(wèn)題

用戶如果每次訪問(wèn)到的服務(wù)器不一樣，那么如何維護(hù)session的一致性？?

4.1?Session Sticky

即把同一個(gè)用戶在某一個(gè)會(huì)話中的請(qǐng)求，都分配到固定的某一臺(tái)服務(wù)器中。

優(yōu)點(diǎn)：易于實(shí)現(xiàn)

缺點(diǎn)：應(yīng)用服務(wù)器重啟則session消失

4.2?Session Replication

即在集群中復(fù)制session，使得每個(gè)服務(wù)器都保存有全部用戶的session數(shù)據(jù)。

優(yōu)點(diǎn)：減輕負(fù)載均衡服務(wù)器的壓力

缺點(diǎn)：復(fù)制時(shí)網(wǎng)絡(luò)帶寬開(kāi)銷大，若訪問(wèn)量大的話session占用內(nèi)存大且浪費(fèi)。

4.3??Session數(shù)據(jù)集中存儲(chǔ)

即利用數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)session數(shù)據(jù)，實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

優(yōu)點(diǎn)：相比Session Replication的方案，集群間對(duì)于寬帶和內(nèi)存的壓力大幅減少

缺點(diǎn)：需要額外維護(hù)存儲(chǔ)session的數(shù)據(jù)庫(kù)

4.4?Cookie Base

即把session存在cookie中，通過(guò)瀏覽器來(lái)告知應(yīng)用服務(wù)器session，同樣實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，基本免維護(hù)

缺點(diǎn)：cookie長(zhǎng)度限制，安全性低，帶寬消耗

根據(jù)不同的場(chǎng)景，選擇不同解決方案來(lái)應(yīng)對(duì)上述這些問(wèn)題后，此時(shí)系統(tǒng)結(jié)構(gòu)：

Phase 4 ：數(shù)據(jù)庫(kù)讀寫分離化

同樣的，隨著訪問(wèn)量的增加，數(shù)據(jù)庫(kù)的負(fù)載也在慢慢增大。對(duì)于這種情況，可以先考慮使用讀寫分離和主從復(fù)制的方式。

讀寫分離后的系統(tǒng)結(jié)構(gòu)：

讀寫分離

2個(gè)問(wèn)題：

4.1 主從數(shù)據(jù)庫(kù)之間數(shù)據(jù)同步問(wèn)題

使用MySQL自帶的Master + Slave的方式實(shí)現(xiàn)主從復(fù)制。

4.2 應(yīng)用服務(wù)對(duì)數(shù)據(jù)源的選擇問(wèn)題

采用第三方數(shù)據(jù)庫(kù)中間件。螞蟻金服目前采用zdal作為數(shù)據(jù)庫(kù)分庫(kù)分表中間件。

Phase 5 ：?緩存緩解讀庫(kù)壓力

常用的緩存機(jī)制包括頁(yè)面級(jí)緩存、應(yīng)用數(shù)據(jù)緩存和數(shù)據(jù)庫(kù)緩存。

5.1?頁(yè)面緩存

除了頁(yè)面緩存帶來(lái)的性能提升外，對(duì)于并發(fā)訪問(wèn)且頁(yè)面置換頻率小的頁(yè)面，應(yīng)盡量使用頁(yè)面靜態(tài)化技術(shù)。例如HTML5的localstroage或者cookie。

緩存集群的調(diào)度算法最好采用一致性哈希算，以此提高命中率。

優(yōu)點(diǎn)：減輕數(shù)據(jù)庫(kù)的壓力，大幅度提高訪問(wèn)速度

缺點(diǎn)：需要維護(hù)緩存服務(wù)器，提高了編碼的復(fù)雜性

5.2??應(yīng)用層和數(shù)據(jù)庫(kù)層的緩存

隨著訪問(wèn)量的增加，會(huì)出現(xiàn)許多用戶訪問(wèn)同一部分熱門內(nèi)容的情況，對(duì)于這些比較熱門的內(nèi)容，不需要每次都從數(shù)據(jù)庫(kù)讀取。可以通過(guò)緩存。例如，可以使用Google的開(kāi)源緩存技術(shù)Guava或者使用Memecahed作為應(yīng)用層的緩存，也可以使用Redis作為數(shù)據(jù)庫(kù)層的緩存。

加入緩存后的系統(tǒng)結(jié)構(gòu)：

緩存緩解讀庫(kù)壓力

Phase 6 ：數(shù)據(jù)庫(kù)水平拆分與垂直拆分

隨著數(shù)據(jù)庫(kù)的壓力繼續(xù)增加，數(shù)據(jù)庫(kù)數(shù)據(jù)量的瓶頸越來(lái)越突出，此時(shí)，可以采取數(shù)據(jù)垂直拆分和水平拆分兩種選擇。

6.1?數(shù)據(jù)垂直拆分

即根據(jù)不同的業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)中。

結(jié)合現(xiàn)在的例子，就是把交易、商品、用戶的數(shù)據(jù)分開(kāi)。

優(yōu)點(diǎn)：

1. 解決了原來(lái)把所有業(yè)務(wù)放在一個(gè)數(shù)據(jù)庫(kù)中的壓力問(wèn)題

2. 可以根據(jù)業(yè)務(wù)的特點(diǎn)進(jìn)行更多的優(yōu)化

缺點(diǎn)：

1. 需要維護(hù)多個(gè)數(shù)據(jù)庫(kù)的狀態(tài)一致性和數(shù)據(jù)同步。

垂直拆分同時(shí)存在著2個(gè)問(wèn)題：

6.1.1?需考慮之前跨業(yè)務(wù)的事務(wù)

解決方案：

應(yīng)該在應(yīng)用層盡量避免跨數(shù)據(jù)庫(kù)的分布式事務(wù)

6.1.2 跨數(shù)據(jù)庫(kù)的Join

解決方案：

通過(guò)數(shù)據(jù)庫(kù)中間件來(lái)解決。

垂直拆分后的系統(tǒng)結(jié)構(gòu)：

數(shù)據(jù)庫(kù)垂直拆分

6.2 數(shù)據(jù)庫(kù)水平拆分

即把同一個(gè)表中的數(shù)據(jù)拆分到兩個(gè)甚至多個(gè)數(shù)據(jù)庫(kù)中。產(chǎn)生數(shù)據(jù)水平拆分的原因是某個(gè)業(yè)務(wù)的數(shù)據(jù)量或者更新量到達(dá)了單個(gè)數(shù)據(jù)庫(kù)的瓶頸。

水平分庫(kù)存在3個(gè)問(wèn)題：

6.2.1?SQL路由

訪問(wèn)用戶信息的應(yīng)用系統(tǒng)需要解決SQL路由的問(wèn)題，因?yàn)楝F(xiàn)在用戶信息分在了兩個(gè)數(shù)據(jù)庫(kù)中，需要在進(jìn)行數(shù)據(jù)操作時(shí)了解需要操作的數(shù)據(jù)在哪里。

解決方案：

通過(guò)可以解決第三方數(shù)據(jù)庫(kù)中間件，如MyCat。MyCat可以通過(guò)SQL解析模塊對(duì)SQL進(jìn)行解析，再根據(jù)我們的配置，把請(qǐng)求轉(zhuǎn)發(fā)到具體的某個(gè)數(shù)據(jù)庫(kù)。

6.2.2 主鍵的處理發(fā)生變化

例如原來(lái)自增字段，現(xiàn)在不能簡(jiǎn)單地繼續(xù)使用。

解決問(wèn)題方案：

可以通過(guò)UUID保證唯一或自定義ID方案來(lái)解決。

6.2.3 不易于分頁(yè)查詢

解決問(wèn)題方案：

可以通過(guò)第三方數(shù)據(jù)庫(kù)中間件，如?MyCat也提供了豐富的分頁(yè)查詢方案，比如先從每個(gè)數(shù)據(jù)庫(kù)做分頁(yè)查詢，再合并數(shù)據(jù)做一次分頁(yè)查詢等等。?

數(shù)據(jù)水平拆分后的結(jié)構(gòu)如下：

數(shù)據(jù)庫(kù)水平拆分

Phase 7 ：應(yīng)用的拆分

按微服務(wù)拆分應(yīng)用

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來(lái)越多，應(yīng)用越來(lái)越大。我們需要考慮如何避免讓應(yīng)用越來(lái)越臃腫。這就需要把應(yīng)用拆開(kāi)，從一個(gè)應(yīng)用變?yōu)閭z個(gè)甚至更多。

還是以上面的例子，可以把用戶、商品、交易拆分開(kāi)。變成“用戶、商品”和“用戶，交易”兩個(gè)子系統(tǒng)。

拆分后的結(jié)構(gòu)：

應(yīng)用拆分

產(chǎn)生的問(wèn)題：產(chǎn)生相同冗余的代碼

如用戶相關(guān)的代碼，商品和交易都需要用戶信息，所以在兩個(gè)系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復(fù)用是一個(gè)需要解決的問(wèn)題。

解決方案：

通過(guò)服務(wù)化SOA的解決頻繁公共的服務(wù)。

7.1?SOA服務(wù)化

為了解決上面拆分應(yīng)用后所出現(xiàn)的問(wèn)題，把公共的服務(wù)拆分出來(lái)，形成一種服務(wù)化的模式，簡(jiǎn)稱SOA。

優(yōu)點(diǎn)：

1. 相同的代碼不會(huì)散落在不同的應(yīng)用中，這些代碼實(shí)現(xiàn)放在各個(gè)服務(wù)中心，易于更好的維護(hù)

2. 把對(duì)數(shù)據(jù)庫(kù)的交互業(yè)務(wù)放在各個(gè)服務(wù)中心，讓前端web應(yīng)用更專心與瀏覽器的交互工作

可以通過(guò)引入消息中間件來(lái)解決遠(yuǎn)程的服務(wù)調(diào)用。

SOA服務(wù)化

Phase 8 ：引入消息中間件

系統(tǒng)中可能會(huì)出現(xiàn)不同語(yǔ)言開(kāi)發(fā)的子模塊和部署在不同平臺(tái)的子系統(tǒng)。此時(shí)需要一個(gè)平臺(tái)來(lái)傳遞可靠的，與平臺(tái)和語(yǔ)言無(wú)關(guān)的數(shù)據(jù)，并能夠把負(fù)載均衡透明化，能在調(diào)用過(guò)程中收集并分析調(diào)用數(shù)據(jù)，推測(cè)出網(wǎng)站的訪問(wèn)增長(zhǎng)率等等一系列需求，對(duì)于網(wǎng)站應(yīng)該如何成長(zhǎng)做出預(yù)測(cè)。

開(kāi)源消息中間件有阿里的Dubbo，可以搭配Google開(kāi)源的分布式程序協(xié)調(diào)服務(wù)Zookeeper實(shí)現(xiàn)服務(wù)器的注冊(cè)與發(fā)現(xiàn)。

引入消息中間件后的結(jié)構(gòu)：