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

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

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

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

③集群：一個特定領(lǐng)域的軟件部署在多臺服務(wù)器上并作為一個整體提供一類服務(wù)，這個整體稱為集群。

如 Zookeeper 中的 Master 和 Slave 分別部署在多臺服務(wù)器上，共同組成一個整體提供集中配置服務(wù)。

在常見的集群中，客戶端往往能夠連接任意一個節(jié)點獲得服務(wù)，并且當(dāng)集群中一個節(jié)點掉線時，其他節(jié)點往往能夠自動的接替它繼續(xù)提供服務(wù)，這時候說明集群具有高可用性。

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

⑤正向代理和反向代理：系統(tǒng)內(nèi)部要訪問外部網(wǎng)絡(luò)時，統(tǒng)一通過一個代理服務(wù)器把請求轉(zhuǎn)發(fā)出去，在外部網(wǎng)絡(luò)看來就是代理服務(wù)器發(fā)起的訪問，此時代理服務(wù)器實現(xiàn)的是正向代理。

當(dāng)外部請求進(jìn)入系統(tǒng)時，代理服務(wù)器把該請求轉(zhuǎn)發(fā)到系統(tǒng)中的某臺服務(wù)器上，對外部請求來說，與之交互的只有代理服務(wù)器，此時代理服務(wù)器實現(xiàn)的是反向代理。

簡單來說，正向代理是代理服務(wù)器代替系統(tǒng)內(nèi)部來訪問外部網(wǎng)絡(luò)的過程，反向代理是外部請求訪問系統(tǒng)時通過代理服務(wù)器轉(zhuǎn)發(fā)到內(nèi)部服務(wù)器的過程。

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

單機架構(gòu)

以淘寶作為例子：在網(wǎng)站最初時，應(yīng)用數(shù)量與用戶數(shù)都較少，可以把 Tomcat 和數(shù)據(jù)庫部署在同一臺服務(wù)器上。

瀏覽器往 www.taobao.com 發(fā)起請求時，首先經(jīng)過 DNS 服務(wù)器(域名系統(tǒng))把域名轉(zhuǎn)換為實際 IP 地址 10.102.4.1，瀏覽器轉(zhuǎn)而訪問該 IP 對應(yīng)的 Tomcat。

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

***次演進(jìn)：Tomcat 與數(shù)據(jù)庫分開部署

Tomcat 和數(shù)據(jù)庫分別獨占服務(wù)器資源，顯著提高兩者各自性能。隨著用戶數(shù)的增長，并發(fā)讀寫數(shù)據(jù)庫成為瓶頸。

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

在 Tomcat 同服務(wù)器上或同 JVM 中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的 HTML 頁面等。

通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉，大大降低數(shù)據(jù)庫壓力。

其中涉及的技術(shù)包括：使用 Memcached 作為本地緩存，使用 Redis 作為分布式緩存，還會涉及緩存一致性、緩存穿透/擊穿、緩存雪崩、熱點數(shù)據(jù)集中失效等問題。

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

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

在多臺服務(wù)器上分別部署 Tomcat，使用反向代理軟件(Nginx)把請求均勻分發(fā)到每個 Tomcat 中。

此處假設(shè) Tomcat 最多支持 100 個并發(fā)，Nginx 最多支持 50000 個并發(fā)，那么理論上 Nginx 把請求分發(fā)到 500 個 Tomcat 上，就能抗住 50000 個并發(fā)。

其中涉及的技術(shù)包括：Nginx、HAProxy，兩者都是工作在網(wǎng)絡(luò)第七層的反向代理軟件，主要支持 HTTP 協(xié)議，還會涉及 Session 共享、文件上傳下載的問題。

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

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

把數(shù)據(jù)庫劃分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的數(shù)據(jù)同步到讀庫，對于需要查詢***寫入數(shù)據(jù)場景，可通過在緩存中多寫一份，通過緩存獲得***數(shù)據(jù)。

其中涉及的技術(shù)包括：Mycat，它是數(shù)據(jù)庫中間件，可通過它來組織數(shù)據(jù)庫的分離讀寫和分庫分表，客戶端通過它來訪問下層數(shù)據(jù)庫，還會涉及數(shù)據(jù)同步，數(shù)據(jù)一致性的問題。

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

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

把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫中，使業(yè)務(wù)之間的資源競爭降低，對于訪問量大的業(yè)務(wù)，可以部署更多的服務(wù)器來支撐。

這樣同時導(dǎo)致跨業(yè)務(wù)的表無法直接做關(guān)聯(lián)分析，需要通過其他途徑來解決，但這不是本文討論的重點，有興趣的可以自行搜索解決方案。隨著用戶數(shù)的增長，單機的寫庫會逐漸達(dá)到性能瓶頸。

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

比如針對評論數(shù)據(jù)，可按照商品 ID 進(jìn)行 Hash，路由到對應(yīng)的表中存儲;針對支付記錄，可按照小時創(chuàng)建表，每個小時表繼續(xù)拆分為小表，使用用戶 ID 或記錄編號來路由數(shù)據(jù)。

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

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

但是這只是一個邏輯的數(shù)據(jù)庫整體，數(shù)據(jù)庫里不同的組成部分是由不同的組件單獨來實現(xiàn)的。

如分庫分表的管理和請求分發(fā)，由 Mycat 實現(xiàn)，SQL 的解析由單機的數(shù)據(jù)庫實現(xiàn)，讀寫分離可能由網(wǎng)關(guān)和消息隊列來實現(xiàn)，查詢結(jié)果的匯總可能由數(shù)據(jù)庫接口層來實現(xiàn)等等，這種架構(gòu)其實是 MPP(大規(guī)模并行處理)架構(gòu)的一類實現(xiàn)。

目前開源和商用都已經(jīng)有不少 MPP 數(shù)據(jù)庫，開源中比較流行的有 Greenplum、TiDB、Postgresql XC、HAWQ 等，商用的如南大通用的 GBase、睿帆科技的雪球 DB、華為的 LibrA 等等。

不同的 MPP 數(shù)據(jù)庫的側(cè)重點也不一樣，如 TiDB 更側(cè)重于分布式 OLTP 場景，Greenplum 更側(cè)重于分布式 OLAP 場景。

這些 MPP 數(shù)據(jù)庫基本都提供了類似 Postgresql、Oracle、MySQL 那樣的 SQL 標(biāo)準(zhǔn)支持能力，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機器上并行執(zhí)行，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進(jìn)行返回。

也提供了諸如權(quán)限管理、分庫分表、事務(wù)、數(shù)據(jù)副本等能力，并且大多能夠支持 100 個節(jié)點以上的集群，大大降低了數(shù)據(jù)庫運維的成本，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴(kuò)展。

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

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

由于瓶頸在 Nginx，因此無法通過兩層的 Nginx 來實現(xiàn)多個 Nginx 的負(fù)載均衡。

圖中的 LVS 和 F5 是工作在網(wǎng)絡(luò)第四層的負(fù)載均衡解決方案，其中 LVS 是軟件，運行在操作系統(tǒng)內(nèi)核態(tài)，可對 TCP 請求或更高層級的網(wǎng)絡(luò)協(xié)議進(jìn)行轉(zhuǎn)發(fā)。

因此支持的協(xié)議更豐富，并且性能也遠(yuǎn)高于 Nginx，可假設(shè)單機的 LVS 可支持幾十萬個并發(fā)的請求轉(zhuǎn)發(fā);F5 是一種負(fù)載均衡硬件，與 LVS 提供的能力類似，性能比 LVS 更高，但價格昂貴。

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

可使用 Keepalived 軟件模擬出虛擬 IP，然后把虛擬 IP 綁定到多臺 LVS 服務(wù)器上，瀏覽器訪問虛擬 IP 時，會被路由器重定向到真實的 LVS 服務(wù)器。

當(dāng)主 LVS 服務(wù)器宕機時，Keepalived 軟件會自動更新路由器中的路由表，把虛擬 IP 重定向到另外一臺正常的 LVS 服務(wù)器，從而達(dá)到 LVS 服務(wù)器高可用的效果。

此處需要注意的是，上圖中從 Nginx 層到 Tomcat 層這樣畫并不代表全部 Nginx 都轉(zhuǎn)發(fā)請求到全部的 Tomcat。

在實際使用時，可能會是幾個 Nginx 下面接一部分的 Tomcat，這些 Nginx 之間通過 Keepalived 實現(xiàn)高可用，其他的 Nginx 接另外的 Tomcat，這樣可接入的 Tomcat 數(shù)量就能成倍的增加。

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

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

在 DNS 服務(wù)器中可配置一個域名對應(yīng)多個 IP 地址，每個 IP 地址對應(yīng)到不同的機房里的虛擬 IP。

當(dāng)用戶訪問 www.taobao.com 時，DNS 服務(wù)器會使用輪詢策略或其他策略，來選擇某個 IP 供用戶訪問。

此方式能實現(xiàn)機房間的負(fù)載均衡，至此，系統(tǒng)可做到機房級別的水平擴(kuò)展，***到億級的并發(fā)量都可通過增加機房來解決，系統(tǒng)入口處的請求并發(fā)量不再是問題。

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

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

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

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

因此需要針對特定的場景，引入合適的解決方案。如對于海量文件存儲，可通過分布式文件系統(tǒng) HDFS 解決。

對于 Key Value 類型的數(shù)據(jù)，可通過 HBase 和 Redis 等方案解決，對于全文檢索場景，可通過搜索引擎如 ElasticSearch 解決，對于多維分析場景，可通過 Kylin 或 Druid 等方案解決。

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

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

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

按照業(yè)務(wù)板塊來劃分應(yīng)用代碼，使單個應(yīng)用的職責(zé)更清晰，相互之間可以做到獨立升級迭代。

這時候應(yīng)用之間可能會涉及到一些公共配置，可以通過分布式配置中心 Zookeeper 來解決。

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

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

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

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

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

不同服務(wù)的接口訪問方式不同，應(yīng)用代碼需要適配多種訪問方式才能使用服務(wù)。

此外，應(yīng)用訪問服務(wù)，服務(wù)之間也可能相互訪問，調(diào)用鏈將會變得非常復(fù)雜，邏輯變得混亂。

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

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

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

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

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

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

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

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

Docker 鏡像可理解為一個能運行你的應(yīng)用/服務(wù)的最小的操作系統(tǒng)，里面放著應(yīng)用/服務(wù)的運行代碼，運行環(huán)境根據(jù)實際的需要設(shè)置好。

把整個“操作系統(tǒng)”打包為一個鏡像后，就可以分發(fā)到需要部署相關(guān)服務(wù)的機器上，直接啟動 Docker 鏡像就可以把服務(wù)起來，使服務(wù)的部署和運維變得簡單。

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

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

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

系統(tǒng)可部署到公有云上，利用公有云的海量機器資源，解決動態(tài)硬件資源的問題。

在大促的時間段里，在云平臺中臨時申請更多的資源，結(jié)合 Docker 和 K8S 來快速部署服務(wù)，在大促結(jié)束后釋放資源，真正做到按需付費，資源利用率大大提高，同時大大降低了運維成本。

所謂的云平臺，就是把海量機器資源，通過統(tǒng)一的資源管理，抽象為一個資源整體，在之上可按需動態(tài)申請硬件資源(如 CPU、內(nèi)存、網(wǎng)絡(luò)等)，并且之上提供通用的操作系統(tǒng)。

提供常用的技術(shù)組件(如 Hadoop 技術(shù)棧，MPP 數(shù)據(jù)庫等)供用戶使用，甚至提供開發(fā)好的應(yīng)用，用戶不需要關(guān)系應(yīng)用內(nèi)部使用了什么技術(shù)，就能夠解決需求(如音視頻轉(zhuǎn)碼服務(wù)、郵件服務(wù)、個人博客等)。

在云平臺中會涉及如下幾個概念：

• IaaS：基礎(chǔ)設(shè)施即服務(wù)。對應(yīng)于上面所說的機器資源統(tǒng)一為資源整體，可動態(tài)申請硬件資源的層面。
• PaaS：平臺即服務(wù)。對應(yīng)于上面所說的提供常用的技術(shù)組件方便系統(tǒng)的開發(fā)和維護(hù)。
• SaaS：軟件即服務(wù)。對應(yīng)于上面所說的提供開發(fā)好的應(yīng)用或服務(wù)，按功能或性能要求付費。

至此，以上所提到的從高并發(fā)訪問問題，到服務(wù)的架構(gòu)和系統(tǒng)實施的層面都有了各自的解決方案。

但同時也應(yīng)該意識到，在上面的介紹中，其實是有意忽略了諸如跨機房數(shù)據(jù)同步、分布式事務(wù)實現(xiàn)等等的實際問題，這些問題以后有機會再拿出來單獨討論。

架構(gòu)設(shè)計總結(jié)

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

不是的，以上所說的架構(gòu)演變順序只是針對某個側(cè)面進(jìn)行單獨的改進(jìn)，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達(dá)到瓶頸的是另外的方面，這時候就應(yīng)該按照實際問題實際解決。

如在政府類的網(wǎng)站并發(fā)量可能不大，但業(yè)務(wù)可能很豐富的場景，高并發(fā)就不是重點解決的問題，此時優(yōu)先需要的可能會是豐富需求的解決方案。

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

對于單次實施并且性能指標(biāo)明確的系統(tǒng)，架構(gòu)設(shè)計到能夠支持系統(tǒng)的性能指標(biāo)要求就足夠了，但要留有擴(kuò)展架構(gòu)的接口以便不備之需。

對于不斷發(fā)展的系統(tǒng)，如電商平臺，應(yīng)設(shè)計到能滿足下一階段用戶量和性能指標(biāo)要求的程度，并根據(jù)業(yè)務(wù)的增長不斷的迭代升級架構(gòu)，以支持更高的并發(fā)和更豐富的業(yè)務(wù)。

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

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

如數(shù)據(jù)采集有 Flume、Sqoop、Kettle 等，數(shù)據(jù)存儲有分布式文件系統(tǒng) HDFS、FastDFS，NoSQL 數(shù)據(jù)庫 HBase、MongoDB 等，數(shù)據(jù)分析有 Spark 技術(shù)棧、機器學(xué)習(xí)算法等。

總的來說大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求，整合各種大數(shù)據(jù)組件組合而成的架構(gòu)，一般會提供分布式存儲、分布式計算、多維分析、數(shù)據(jù)倉庫、機器學(xué)習(xí)算法等能力。

而服務(wù)端架構(gòu)更多指的是應(yīng)用組織層面的架構(gòu)，底層能力往往是由大數(shù)據(jù)架構(gòu)來提供。

④有沒有一些架構(gòu)設(shè)計的原則?

設(shè)計原則如下：

• N+1 設(shè)計。系統(tǒng)中的每個組件都應(yīng)做到?jīng)]有單點故障。
• 回滾設(shè)計。確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應(yīng)能有辦法回滾版本。
• 禁用設(shè)計。應(yīng)該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能。
• 監(jiān)控設(shè)計。在設(shè)計階段就要考慮監(jiān)控的手段。
• 多活數(shù)據(jù)中心設(shè)計。若系統(tǒng)需要極高的高可用，應(yīng)考慮在多地實施數(shù)據(jù)中心進(jìn)行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用。
• 采用成熟的技術(shù)。剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的 Bug，出了問題沒有商業(yè)支持可能會是一個災(zāi)難。
• 資源隔離設(shè)計。應(yīng)避免單一業(yè)務(wù)占用全部資源。
• 架構(gòu)應(yīng)能水平擴(kuò)展。系統(tǒng)只有做到能水平擴(kuò)展，才能有效避免瓶頸問題。
• 非核心則購買。非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購買成熟的產(chǎn)品。
• 使用商用硬件。商用硬件能有效降低硬件故障的機率。
• 快速迭代。系統(tǒng)應(yīng)該快速開發(fā)小功能模塊，盡快上線進(jìn)行驗證，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風(fēng)險。
• 無狀態(tài)設(shè)計。服務(wù)接口應(yīng)該做成無狀態(tài)的，當(dāng)前接口的訪問不依賴于接口上次訪問的狀態(tài)。

作者：歐仕華

簡介：在大數(shù)據(jù)領(lǐng)域具有多年的開發(fā)經(jīng)驗，對常用大數(shù)據(jù)技術(shù)都有所了解，在架構(gòu)設(shè)計、高并發(fā)、分布式等方面具有一定經(jīng)驗。喜歡學(xué)習(xí)新技術(shù)，樂于分享，歡迎關(guān)注我的 SegmentFault 博客：huashiou。