1. 概述

本文以淘寶作為例子，介紹從一百個(gè)到千萬(wàn)級(jí)并發(fā)情況下服務(wù)端的架構(gòu)的演進(jìn)過(guò)程。同時(shí)列舉出每個(gè)演進(jìn)階段會(huì)遇到的相關(guān)技術(shù)，讓大家對(duì)架構(gòu)的演進(jìn)有一個(gè)整體的認(rèn)知。文章最后匯總了一些架構(gòu)設(shè)計(jì)的原則。

特別說(shuō)明：本文以淘寶為例僅僅是為了便于說(shuō)明演進(jìn)過(guò)程可能遇到的問(wèn)題，并非是淘寶真正的技術(shù)演進(jìn)路徑。

2. 基本概念

在介紹架構(gòu)之前，為了避免部分讀者對(duì)架構(gòu)設(shè)計(jì)中的一些概念不了解，下面對(duì)幾個(gè)最基礎(chǔ)的概念進(jìn)行介紹：

分布式：系統(tǒng)中的多個(gè)模塊在不同服務(wù)器上部署，即可稱為分布式系統(tǒng)。如 Tomcat 和數(shù)據(jù)庫(kù)分別部署在不同的服務(wù)器上，或兩個(gè)相同功能的 Tomcat 分別部署在不同服務(wù)器上；

高可用：系統(tǒng)中部分節(jié)點(diǎn)失效時(shí)，其他節(jié)點(diǎn)能夠接替它繼續(xù)提供服務(wù)，則可認(rèn)為系統(tǒng)具有高可用性；

集群：一個(gè)特定領(lǐng)域的軟件部署在多臺(tái)服務(wù)器上并作為一個(gè)整體提供一類服務(wù)，這個(gè)整體稱為集群。如 ZooKeeper 中的 Master 和 Slave 分別部署在多臺(tái)服務(wù)器上，共同組成一個(gè)整體提供集中配置服務(wù)。在常見(jiàn)的集群中，客戶端往往能夠連接任意一個(gè)節(jié)點(diǎn)獲得服務(wù)，并且當(dāng)集群中一個(gè)節(jié)點(diǎn)掉線時(shí)，其他節(jié)點(diǎn)往往能夠自動(dòng)接替它繼續(xù)提供服務(wù)。這時(shí)候說(shuō)明集群具有高可用性；

負(fù)載均衡：請(qǐng)求發(fā)送到系統(tǒng)時(shí)，通過(guò)某些方式把請(qǐng)求均勻分發(fā)到多個(gè)節(jié)點(diǎn)上，使系統(tǒng)中每個(gè)節(jié)點(diǎn)能夠均勻處理請(qǐng)求負(fù)載，則可認(rèn)為系統(tǒng)是負(fù)載均衡的；

正向代理和反向代理：系統(tǒng)內(nèi)部要訪問(wèn)外部網(wǎng)絡(luò)時(shí)，統(tǒng)一通過(guò)一個(gè)代理服務(wù)器把請(qǐng)求轉(zhuǎn)發(fā)出去。在外部網(wǎng)絡(luò)看來(lái)就是代理服務(wù)器發(fā)起的訪問(wèn)，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是正向代理。當(dāng)外部請(qǐng)求進(jìn)入系統(tǒng)時(shí)，代理服務(wù)器把該請(qǐng)求轉(zhuǎn)發(fā)到系統(tǒng)中的某臺(tái)服務(wù)器上。對(duì)外部請(qǐng)求來(lái)說(shuō)，與之交互的只有代理服務(wù)器，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是反向代理。簡(jiǎn)單來(lái)說(shuō)，正向代理是代理服務(wù)器代替系統(tǒng)內(nèi)部來(lái)訪問(wèn)外部網(wǎng)絡(luò)的過(guò)程，反向代理是外部請(qǐng)求訪問(wèn)系統(tǒng)時(shí)通過(guò)代理服務(wù)器轉(zhuǎn)發(fā)到內(nèi)部服務(wù)器的過(guò)程。

3. 架構(gòu)演進(jìn)

3.1 單機(jī)架構(gòu)

以淘寶作為例子。在網(wǎng)站最初時(shí)，應(yīng)用數(shù)量與用戶數(shù)都較少，可以把 Tomcat 和數(shù)據(jù)庫(kù)部署在同一臺(tái)服務(wù)器上。瀏覽器往 www.taobao.com 發(fā)起請(qǐng)求時(shí)，首先經(jīng)過(guò) DNS 服務(wù)器（域名系統(tǒng)）把域名轉(zhuǎn)換為實(shí)際 IP 地址 10.102.4.1，瀏覽器轉(zhuǎn)而訪問(wèn)該 IP 對(duì)應(yīng)的 Tomcat。

隨著用戶數(shù)的增長(zhǎng)，Tomcat 和數(shù)據(jù)庫(kù)之間競(jìng)爭(zhēng)資源，單機(jī)性能不足以支撐業(yè)務(wù)。

3.2 第一次演進(jìn)：Tomcat 與數(shù)據(jù)庫(kù)分開(kāi)部署

Tomcat 和數(shù)據(jù)庫(kù)分別獨(dú)占服務(wù)器資源，顯著提高兩者各自性能。

隨著用戶數(shù)的增長(zhǎng)，并發(fā)讀寫(xiě)數(shù)據(jù)庫(kù)成為瓶頸。

3.3 第二次演進(jìn)：引入本地緩存和分布式緩存

在 Tomcat 同服務(wù)器上或同 JVM 中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的 HTML 頁(yè)面等。通過(guò)緩存能把絕大多數(shù)請(qǐng)求在讀寫(xiě)數(shù)據(jù)庫(kù)前攔截掉，大大降低數(shù)據(jù)庫(kù)壓力。其中涉及的技術(shù)包括：使用 Memcached 作為本地緩存，使用 Redis 作為分布式緩存，還會(huì)涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點(diǎn)數(shù)據(jù)集中失效等問(wèn)題。

緩存抗住了大部分的訪問(wèn)請(qǐng)求。隨著用戶數(shù)的增長(zhǎng)，并發(fā)壓力主要落在單機(jī)的 Tomcat 上，響應(yīng)逐漸變慢。

3.4 第三次演進(jìn)：引入反向代理實(shí)現(xiàn)負(fù)載均衡

在多臺(tái)服務(wù)器上分別部署 Tomcat，使用反向代理軟件（Nginx）把請(qǐng)求均勻分發(fā)到每個(gè) Tomcat 中。此處假設(shè) Tomcat 最多支持 100 個(gè)并發(fā)，Nginx 最多支持 50000 個(gè)并發(fā)。那么，理論上 Nginx 把請(qǐng)求分發(fā)到 500 個(gè) Tomcat 上，就能抗住 50000 個(gè)并發(fā)。其中涉及的技術(shù)包括：Nginx、HAProxy，兩者都是工作在網(wǎng)絡(luò)第七層的反向代理軟件，主要支持 HTTP 協(xié)議，還會(huì)涉及 Session 共享、文件上傳下載的問(wèn)題。

反向代理使應(yīng)用服務(wù)器可支持的并發(fā)量大大增加，但并發(fā)量的增長(zhǎng)也意味著更多請(qǐng)求穿透到數(shù)據(jù)庫(kù)，單機(jī)的數(shù)據(jù)庫(kù)最終成為瓶頸。

3.5 第四次演進(jìn)：數(shù)據(jù)庫(kù)讀寫(xiě)分離

把數(shù)據(jù)庫(kù)劃分為讀庫(kù)和寫(xiě)庫(kù)，讀庫(kù)可以有多個(gè)，通過(guò)同步機(jī)制把寫(xiě)庫(kù)的數(shù)據(jù)同步到讀庫(kù)，對(duì)于需要查詢最新寫(xiě)入數(shù)據(jù)場(chǎng)景，可通過(guò)在緩存中多寫(xiě)一份，通過(guò)緩存獲得最新數(shù)據(jù)。其中涉及的技術(shù)包括 Mycat。它是數(shù)據(jù)庫(kù)中間件，可通過(guò)它來(lái)組織數(shù)據(jù)庫(kù)的分離讀寫(xiě)和分庫(kù)分表。客戶端通過(guò)它來(lái)訪問(wèn)下層數(shù)據(jù)庫(kù)，還會(huì)涉及數(shù)據(jù)同步，數(shù)據(jù)一致性的問(wèn)題。

業(yè)務(wù)逐漸變多，不同業(yè)務(wù)之間的訪問(wèn)量差距較大。不同業(yè)務(wù)直接競(jìng)爭(zhēng)數(shù)據(jù)庫(kù)，相互影響性能。

3.6 第五次演進(jìn)：數(shù)據(jù)庫(kù)按業(yè)務(wù)分庫(kù)

把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫(kù)中，使業(yè)務(wù)之間的資源競(jìng)爭(zhēng)降低。對(duì)于訪問(wèn)量大的業(yè)務(wù)，可以部署更多的服務(wù)器來(lái)支撐。這樣同時(shí)導(dǎo)致跨業(yè)務(wù)的表無(wú)法直接做關(guān)聯(lián)分析，需要通過(guò)其他途徑來(lái)解決。但這不是本文討論的重點(diǎn)，有興趣的可以自行搜索解決方案。

隨著用戶數(shù)的增長(zhǎng)，單機(jī)的寫(xiě)庫(kù)會(huì)逐漸會(huì)達(dá)到性能瓶頸。

3.7 第六次演進(jìn)：把大表拆分為小表

比如，

針對(duì)評(píng)論數(shù)據(jù)，可按照商品 ID 進(jìn)行 Hash，路由到對(duì)應(yīng)的表中存儲(chǔ)；

針對(duì)支付記錄，可按照小時(shí)創(chuàng)建表，每個(gè)小時(shí)表繼續(xù)拆分為小表，使用用戶 ID 或記錄編號(hào)來(lái)路由數(shù)據(jù)。

只要實(shí)時(shí)操作的表數(shù)據(jù)量足夠小，請(qǐng)求能夠足夠均勻的分發(fā)到多臺(tái)服務(wù)器上的小表，那數(shù)據(jù)庫(kù)就能通過(guò)水平擴(kuò)展的方式來(lái)提高性能。其中，前面提到的 Mycat 也支持在大表拆分為小表情況下的訪問(wèn)控制。

這種做法顯著增加了數(shù)據(jù)庫(kù)運(yùn)維的難度，對(duì) DBA的 要求較高。數(shù)據(jù)庫(kù)設(shè)計(jì)到這種結(jié)構(gòu)時(shí)，已經(jīng)可以稱為分布式數(shù)據(jù)庫(kù)。

但是這只是一個(gè)邏輯的數(shù)據(jù)庫(kù)整體，數(shù)據(jù)庫(kù)里不同的組成部分是由不同的組件單獨(dú)來(lái)實(shí)現(xiàn)的。例如，

分庫(kù)分表的管理和請(qǐng)求分發(fā)由 Mycat 實(shí)現(xiàn)；

SQL 解析由單機(jī)的數(shù)據(jù)庫(kù)實(shí)現(xiàn)；

讀寫(xiě)分離可能由網(wǎng)關(guān)和消息隊(duì)列來(lái)實(shí)現(xiàn)；

查詢結(jié)果的匯總可能由數(shù)據(jù)庫(kù)接口層來(lái)實(shí)現(xiàn)等等。

這種架構(gòu)其實(shí)是 MPP（大規(guī)模并行處理）架構(gòu)的一類實(shí)現(xiàn)。

目前開(kāi)源和商用都已經(jīng)有不少 MPP 數(shù)據(jù)庫(kù)。開(kāi)源中比較流行的有 Greenplum、TiDB、Postgresql XC、HAWQ 等。商用的如南大通用的 GBase、睿帆科技的雪球 DB、華為的 LibrA 等等。不同的 MPP 數(shù)據(jù)庫(kù)的側(cè)重點(diǎn)也不一樣。如 TiDB 更側(cè)重于分布式 OLTP 場(chǎng)景，Greenplum 更側(cè)重于分布式 OLAP 場(chǎng)景。

這些 MPP 數(shù)據(jù)庫(kù)基本都提供了類似 Postgresql、Oracle、MySQL 那樣的 SQL 標(biāo)準(zhǔn)支持能力，能把一個(gè)查詢解析為分布式的執(zhí)行計(jì)劃分發(fā)到每臺(tái)機(jī)器上并行執(zhí)行，最終由數(shù)據(jù)庫(kù)本身匯總數(shù)據(jù)進(jìn)行返回。也提供了諸如權(quán)限管理、分庫(kù)分表、事務(wù)、數(shù)據(jù)副本等能力，并且大多能夠支持 100 個(gè)節(jié)點(diǎn)以上的集群。大大降低了數(shù)據(jù)庫(kù)運(yùn)維的成本，并且使數(shù)據(jù)庫(kù)也能夠?qū)崿F(xiàn)水平擴(kuò)展。

數(shù)據(jù)庫(kù)和 Tomcat 都能夠水平擴(kuò)展，可支撐的并發(fā)大幅提高。隨著用戶數(shù)的增長(zhǎng)，最終單機(jī)的 Nginx 會(huì)成為瓶頸。

3.8 第七次演進(jìn)：使用 LVS 或 F5 來(lái)使多個(gè) Nginx 負(fù)載均衡

由于瓶頸在 Nginx，因此無(wú)法通過(guò)兩層的 Nginx 來(lái)實(shí)現(xiàn)多個(gè) Nginx 的負(fù)載均衡。圖中的 LVS 和 F5 是工作在網(wǎng)絡(luò)第四層的負(fù)載均衡解決方案。

其中 LVS 是軟件，運(yùn)行在操作系統(tǒng)內(nèi)核態(tài)，可對(duì) TCP 請(qǐng)求或更高層級(jí)的網(wǎng)絡(luò)協(xié)議進(jìn)行轉(zhuǎn)發(fā)，因此支持的協(xié)議更豐富，并且性能也遠(yuǎn)高于 Nginx。可假設(shè)單機(jī)的 LVS 可支持幾十萬(wàn)個(gè)并發(fā)的請(qǐng)求轉(zhuǎn)發(fā)；F5 是一種負(fù)載均衡硬件，與 LVS 提供的能力類似。性能比 LVS 更高，但價(jià)格昂貴。

由于 LVS 是單機(jī)版的軟件，若 LVS 所在服務(wù)器宕機(jī)則會(huì)導(dǎo)致整個(gè)后端系統(tǒng)都無(wú)法訪問(wèn)，因此需要有備用節(jié)點(diǎn)。

可使用 Keepalived 軟件模擬出虛擬 IP，然后把虛擬 IP 綁定到多臺(tái) LVS 服務(wù)器上。瀏覽器訪問(wèn)虛擬 IP 時(shí)，會(huì)被路由器重定向到真實(shí)的 LVS 服務(wù)器。當(dāng)主 LVS 服務(wù)器宕機(jī)時(shí)，Keepalived 軟件會(huì)自動(dòng)更新路由器中的路由表，把虛擬 IP 重定向到另外一臺(tái)正常的 LVS 服務(wù)器，從而達(dá)到 LVS 服務(wù)器高可用的效果。

此處需要注意的是，上圖中從 Nginx 層到 Tomcat 層這樣畫(huà)并不代表全部 Nginx 都轉(zhuǎn)發(fā)請(qǐng)求到全部的 Tomcat。在實(shí)際使用時(shí)，可能會(huì)是幾個(gè) Nginx 下面接一部分的 Tomcat。這些 Nginx 之間通過(guò) Keepalived 實(shí)現(xiàn)高可用，其他的 Nginx 接另外的 Tomcat。這樣可接入的 Tomcat 數(shù)量就能成倍增加。

由于 LVS 也是單機(jī)的，隨著并發(fā)數(shù)增長(zhǎng)到幾十萬(wàn)時(shí)，LVS 服務(wù)器最終會(huì)達(dá)到瓶頸。此時(shí)用戶數(shù)達(dá)到千萬(wàn)甚至上億級(jí)別。用戶分布在不同的地區(qū)，與服務(wù)器機(jī)房距離不同，導(dǎo)致了訪問(wèn)的延遲會(huì)明顯不同。

3.9 第八次演進(jìn)：通過(guò) DNS 輪詢實(shí)現(xiàn)機(jī)房間的負(fù)載均衡

在 DNS 服務(wù)器中可配置一個(gè)域名對(duì)應(yīng)多個(gè) IP 地址，每個(gè) IP 地址對(duì)應(yīng)到不同的機(jī)房里的虛擬 IP。當(dāng)用戶訪問(wèn) www.taobao.com 時(shí)，DNS 服務(wù)器會(huì)使用輪詢策略或其他策略，來(lái)選擇某個(gè) IP 供用戶訪問(wèn)。此方式能實(shí)現(xiàn)機(jī)房間的負(fù)載均衡。

至此，系統(tǒng)可做到機(jī)房級(jí)別的水平擴(kuò)展。千萬(wàn)級(jí)到億級(jí)的并發(fā)量都可通過(guò)增加機(jī)房來(lái)解決，系統(tǒng)入口處的請(qǐng)求并發(fā)量不再是問(wèn)題。

隨著數(shù)據(jù)的豐富程度和業(yè)務(wù)的發(fā)展，檢索、分析等需求越來(lái)越豐富，單單依靠數(shù)據(jù)庫(kù)無(wú)法解決如此豐富的需求。

3.10 第九次演進(jìn)：引入 NoSQL 數(shù)據(jù)庫(kù)和搜索引擎等技術(shù)

當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)多到一定規(guī)模時(shí)，數(shù)據(jù)庫(kù)就不適用于復(fù)雜的查詢了，往往只能滿足普通查詢的場(chǎng)景。

對(duì)于統(tǒng)計(jì)報(bào)表場(chǎng)景，在數(shù)據(jù)量大時(shí)不一定能跑出結(jié)果。而且在跑復(fù)雜查詢時(shí)會(huì)導(dǎo)致其他查詢變慢，對(duì)于全文檢索、可變數(shù)據(jù)結(jié)構(gòu)等場(chǎng)景，數(shù)據(jù)庫(kù)天生不適用。

因此，需要針對(duì)特定場(chǎng)景引入合適的解決方案。例如，

對(duì)于海量文件存儲(chǔ)，可通過(guò)分布式文件系統(tǒng) HDFS 解決；

對(duì)于 key-value 類型的數(shù)據(jù)，可通過(guò) HBase 和 Redis 等方案解決。

對(duì)于全文檢索場(chǎng)景，可通過(guò)搜索引擎如 ElasticSearch 解決；

對(duì)于多維分析場(chǎng)景，可通過(guò) Kylin 或 Druid 等方案解決。

當(dāng)然，引入更多組件同時(shí)會(huì)提高系統(tǒng)的復(fù)雜度。不同的組件保存的數(shù)據(jù)需要同步，需要考慮一致性的問(wèn)題。需要有更多的運(yùn)維手段來(lái)管理這些組件等。

引入更多組件解決了豐富的需求，業(yè)務(wù)維度能夠極大擴(kuò)充。隨之而來(lái)的是一個(gè)應(yīng)用中包含了太多的業(yè)務(wù)代碼，業(yè)務(wù)的升級(jí)迭代變得困難。

3.11 第十次演進(jìn)：大應(yīng)用拆分為小應(yīng)用

按照業(yè)務(wù)板塊來(lái)劃分應(yīng)用代碼，使單個(gè)應(yīng)用的職責(zé)更清晰，相互之間可以做到獨(dú)立升級(jí)迭代。這時(shí)候應(yīng)用之間可能會(huì)涉及到一些公共配置，可以通過(guò)分布式配置中心 ZooKeeper 來(lái)解決。

不同應(yīng)用之間存在共用的模塊，由應(yīng)用單獨(dú)管理會(huì)導(dǎo)致相同代碼存在許多份，導(dǎo)致公共功能升級(jí)時(shí)全部應(yīng)用代碼都要跟著升級(jí)。

3.12 第十一次演進(jìn)：復(fù)用的功能抽離成微服務(wù)

例如，用戶管理、訂單、支付、鑒權(quán)等功能在多個(gè)應(yīng)用中都存在，那么可以把這些功能的代碼單獨(dú)抽取出來(lái)形成一個(gè)單獨(dú)的服務(wù)來(lái)管理。

這樣的服務(wù)就是所謂的微服務(wù)，應(yīng)用和服務(wù)之間通過(guò) HTTP、TCP 或 RPC 請(qǐng)求等多種方式來(lái)訪問(wèn)公共服務(wù)，每個(gè)單獨(dú)的服務(wù)都可以由單獨(dú)的團(tuán)隊(duì)來(lái)管理。

此外，可以通過(guò) Dubbo、SpringCloud 等框架實(shí)現(xiàn)服務(wù)治理、限流、熔斷、降級(jí)等功能，提高服務(wù)的穩(wěn)定性和可用性。

不同服務(wù)的接口訪問(wèn)方式不同，應(yīng)用代碼需要適配多種訪問(wèn)方式才能使用服務(wù)。此外，應(yīng)用訪問(wèn)服務(wù)，服務(wù)之間也可能相互訪問(wèn)。調(diào)用鏈將會(huì)變得非常復(fù)雜，邏輯變得混亂。

3.13 第十二次演進(jìn)：引入企業(yè)服務(wù)總線 ESB 屏蔽服務(wù)接口的訪問(wèn)差異

通過(guò) ESB 統(tǒng)一進(jìn)行訪問(wèn)協(xié)議轉(zhuǎn)換。應(yīng)用統(tǒng)一通過(guò) ESB 來(lái)訪問(wèn)后端服務(wù)，服務(wù)與服務(wù)之間也通過(guò) ESB 來(lái)相互調(diào)用，以此降低系統(tǒng)的耦合程度。

這種單個(gè)應(yīng)用拆分為多個(gè)應(yīng)用，公共服務(wù)單獨(dú)抽取出來(lái)來(lái)管理，并使用企業(yè)消息總線來(lái)解除服務(wù)之間耦合問(wèn)題的架構(gòu)，就是所謂的 SOA（面向服務(wù)）架構(gòu)。這種架構(gòu)與微服務(wù)架構(gòu)容易混淆，因?yàn)楸憩F(xiàn)形式十分相似。

個(gè)人理解，微服務(wù)架構(gòu)更多是指把系統(tǒng)里的公共服務(wù)抽取出來(lái)單獨(dú)運(yùn)維管理的思想，而 SOA 架構(gòu)則是指一種拆分服務(wù)并使服務(wù)接口訪問(wèn)變得統(tǒng)一的架構(gòu)思想。SOA 架構(gòu)中包含了微服務(wù)的思想。

業(yè)務(wù)不斷發(fā)展，應(yīng)用和服務(wù)都會(huì)不斷變多，應(yīng)用和服務(wù)的部署變得復(fù)雜。同一臺(tái)服務(wù)器上部署多個(gè)服務(wù)還要解決運(yùn)行環(huán)境沖突的問(wèn)題。

此外，對(duì)于如大促這類需要?jiǎng)討B(tài)擴(kuò)縮容的場(chǎng)景，需要水平擴(kuò)展服務(wù)的性能。就需要在新增的服務(wù)上準(zhǔn)備運(yùn)行環(huán)境，部署服務(wù)等，運(yùn)維將變得十分困難。

3.14 第十三次演進(jìn)：引入容器化技術(shù)實(shí)現(xiàn)運(yùn)行環(huán)境隔離與動(dòng)態(tài)服務(wù)管理

目前最流行的容器化技術(shù)是 Docker，最流行的容器管理服務(wù)是 Kubernetes（K8S）。應(yīng)用/服務(wù)可以打包為 Docker 鏡像，通過(guò) K8S 來(lái)動(dòng)態(tài)分發(fā)和部署鏡像。

Docker 鏡像可理解為一個(gè)能運(yùn)行你的應(yīng)用/服務(wù)的最小的操作系統(tǒng)。里面放著應(yīng)用/服務(wù)的運(yùn)行代碼，運(yùn)行環(huán)境根據(jù)實(shí)際的需要設(shè)置好。把整個(gè)“操作系統(tǒng)”打包為一個(gè)鏡像后，就可以分發(fā)到需要部署相關(guān)服務(wù)的機(jī)器上，直接啟動(dòng) Docker 鏡像就可以把服務(wù)起起來(lái)。使服務(wù)的部署和運(yùn)維變得簡(jiǎn)單。

在大促的之前，可以在現(xiàn)有的機(jī)器集群上劃分出服務(wù)器來(lái)啟動(dòng) Docker 鏡像，增強(qiáng)服務(wù)的性能。大促過(guò)后就可以關(guān)閉鏡像，對(duì)機(jī)器上的其他服務(wù)不造成影響（在 3.14 節(jié)之前，服務(wù)運(yùn)行在新增機(jī)器上需要修改系統(tǒng)配置來(lái)適配服務(wù)。這會(huì)導(dǎo)致機(jī)器上其他服務(wù)需要的運(yùn)行環(huán)境被破壞）。

使用容器化技術(shù)后服務(wù)動(dòng)態(tài)擴(kuò)縮容問(wèn)題得以解決，但是機(jī)器還是需要公司自身來(lái)管理。在非大促的時(shí)候，還是需要閑置著大量的機(jī)器資源來(lái)應(yīng)對(duì)大促。機(jī)器自身成本和運(yùn)維成本都極高，資源利用率低。

3.15 第十四次演進(jìn)：以云平臺(tái)承載系統(tǒng)

系統(tǒng)可部署到公有云上，利用公有云的海量機(jī)器資源，解決動(dòng)態(tài)硬件資源的問(wèn)題。在大促的時(shí)間段里，在云平臺(tái)中臨時(shí)申請(qǐng)更多的資源，結(jié)合 Docker 和 K8S 來(lái)快速部署服務(wù)。在大促結(jié)束后釋放資源。真正做到按需付費(fèi)，資源利用率大大提高，同時(shí)大大降低了運(yùn)維成本。

所謂的云平臺(tái)，就是把海量機(jī)器資源通過(guò)統(tǒng)一的資源管理，抽象為一個(gè)資源整體。在之上可按需動(dòng)態(tài)申請(qǐng)硬件資源（如 CPU、內(nèi)存、網(wǎng)絡(luò)等）。并且之上提供通用的操作系統(tǒng)，提供常用的技術(shù)組件（如 Hadoop 技術(shù)棧，MPP 數(shù)據(jù)庫(kù)等）供用戶使用，甚至提供開(kāi)發(fā)好的應(yīng)用。用戶不需要關(guān)系應(yīng)用內(nèi)部使用了什么技術(shù)，就能夠解決需求（如音視頻轉(zhuǎn)碼服務(wù)、郵件服務(wù)、個(gè)人博客等）。

在云平臺(tái)中會(huì)涉及如下幾個(gè)概念：

IaaS：基礎(chǔ)設(shè)施即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的機(jī)器資源統(tǒng)一為資源整體，可動(dòng)態(tài)申請(qǐng)硬件資源的層面；

PaaS：平臺(tái)即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的提供常用的技術(shù)組件方便系統(tǒng)的開(kāi)發(fā)和維護(hù)；

SaaS：軟件即服務(wù)。對(duì)應(yīng)于上面所說(shuō)的提供開(kāi)發(fā)好的應(yīng)用或服務(wù)，按功能或性能要求付費(fèi)。

至此，以上所提到的從高并發(fā)訪問(wèn)問(wèn)題，到服務(wù)的架構(gòu)和系統(tǒng)實(shí)施的層面都有了各自的解決方案。但同時(shí)也應(yīng)該意識(shí)到，在上面的介紹中，其實(shí)是有意忽略了諸如跨機(jī)房數(shù)據(jù)同步、分布式事務(wù)實(shí)現(xiàn)等等的實(shí)際問(wèn)題。這些問(wèn)題以后有機(jī)會(huì)再拿出來(lái)單獨(dú)討論。

4. 架構(gòu)設(shè)計(jì)總結(jié)

架構(gòu)的調(diào)整是否必須按照上述演變路徑進(jìn)行？

不是的。

以上所說(shuō)的架構(gòu)演變順序只是針對(duì)某個(gè)側(cè)面進(jìn)行單獨(dú)的改進(jìn)。在實(shí)際場(chǎng)景中，可能同一時(shí)間會(huì)有幾個(gè)問(wèn)題需要解決，或者可能先達(dá)到瓶頸的是另外的方面。這時(shí)候就應(yīng)該按照實(shí)際問(wèn)題實(shí)際解決。如在政府類的并發(fā)量可能不大，但業(yè)務(wù)可能很豐富的場(chǎng)景，高并發(fā)就不是重點(diǎn)解決的問(wèn)題。此時(shí)優(yōu)先需要的可能會(huì)是豐富需求的解決方案。

對(duì)于將要實(shí)施的系統(tǒng)，架構(gòu)應(yīng)該設(shè)計(jì)到什么程度？

對(duì)于單次實(shí)施并且性能指標(biāo)明確的系統(tǒng)，架構(gòu)設(shè)計(jì)到能夠支持系統(tǒng)的性能指標(biāo)要求就足夠了，但要留有擴(kuò)展架構(gòu)的接口以便不備之需。對(duì)于不斷發(fā)展的系統(tǒng)，如電商平臺(tái)，應(yīng)設(shè)計(jì)到能滿足下一階段用戶量和性能指標(biāo)要求的程度。并根據(jù)業(yè)務(wù)的增長(zhǎng)不斷的迭代升級(jí)架構(gòu)，以支持更高的并發(fā)和更豐富的業(yè)務(wù)。

服務(wù)端架構(gòu)和大數(shù)據(jù)架構(gòu)有什么區(qū)別？

所謂的“大數(shù)據(jù)”其實(shí)是海量數(shù)據(jù)采集清洗轉(zhuǎn)換、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析、數(shù)據(jù)服務(wù)等場(chǎng)景解決方案的一個(gè)統(tǒng)稱。在每一個(gè)場(chǎng)景都包含了多種可選的技術(shù)，例如

數(shù)據(jù)采集有 Flume、Sqoop、Kettle 等；

數(shù)據(jù)存儲(chǔ)有分布式文件系統(tǒng) HDFS、FastDFS，NoSQL 數(shù)據(jù)庫(kù) HBase、MongoDB 等；

數(shù)據(jù)分析有 Spark 技術(shù)棧、機(jī)器學(xué)習(xí)算法等。

總的來(lái)說(shuō)，大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求整合各種大數(shù)據(jù)組件組合而成的架構(gòu)。一般會(huì)提供分布式存儲(chǔ)、分布式計(jì)算、多維分析、數(shù)據(jù)倉(cāng)庫(kù)、機(jī)器學(xué)習(xí)算法等能力。而服務(wù)端架構(gòu)更多指的是應(yīng)用組織層面的架構(gòu)，底層能力往往是由大數(shù)據(jù)架構(gòu)來(lái)提供。

有沒(méi)有一些架構(gòu)設(shè)計(jì)的原則？

N+1設(shè)計(jì)：系統(tǒng)中的每個(gè)組件都應(yīng)做到?jīng)]有單點(diǎn)故障；

回滾設(shè)計(jì)：確保系統(tǒng)可以向前兼容，在系統(tǒng)升級(jí)時(shí)應(yīng)能有辦法回滾版本；

禁用設(shè)計(jì)：應(yīng)該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時(shí)能夠快速下線功能；

監(jiān)控設(shè)計(jì)：在設(shè)計(jì)階段就要考慮監(jiān)控的手段；

多活數(shù)據(jù)中心設(shè)計(jì)：若系統(tǒng)需要極高的高可用，應(yīng)考慮在多地實(shí)施數(shù)據(jù)中心進(jìn)行多活，至少在一個(gè)機(jī)房斷電的情況下系統(tǒng)依然可用；

采用成熟的技術(shù)：剛開(kāi)發(fā)的或開(kāi)源的技術(shù)往往存在很多隱藏的bug，出了問(wèn)題沒(méi)有商業(yè)支持可能會(huì)是一個(gè)災(zāi)難；

資源隔離設(shè)計(jì)：應(yīng)避免單一業(yè)務(wù)占用全部資源；

架構(gòu)應(yīng)能水平擴(kuò)展：系統(tǒng)只有做到能水平擴(kuò)展，才能有效避免瓶頸問(wèn)題；

非核心則購(gòu)買：非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購(gòu)買成熟的產(chǎn)品；

使用商用硬件：商用硬件能有效降低硬件故障的機(jī)率；

快速迭代：系統(tǒng)應(yīng)該快速開(kāi)發(fā)小功能模塊，盡快上線進(jìn)行驗(yàn)證，早日發(fā)現(xiàn)問(wèn)題大大降低系統(tǒng)交付的風(fēng)險(xiǎn)；

無(wú)狀態(tài)設(shè)計(jì)：服務(wù)接口應(yīng)該做成無(wú)狀態(tài)的，當(dāng)前接口的訪問(wèn)不依賴于接口上次訪問(wèn)的狀態(tài)。

審核編輯 ：李倩