概述

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

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

單機(jī)架構(gòu)（原始）

以淘寶為例子戏罢，在網(wǎng)站最初的時候，應(yīng)用數(shù)量與用戶數(shù)量都比較少脚囊，可以把Tomcat和數(shù)據(jù)庫部署在同一個臺服務(wù)器上龟糕。瀏覽器往www.taobao.com發(fā)起請求時，首先經(jīng)果DNS服務(wù)器（域名系統(tǒng)）把域名轉(zhuǎn)換成實(shí)際IP地址10.102.4.1悔耘，瀏覽器轉(zhuǎn)而訪問該IP對應(yīng)的Tomcat讲岁。

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

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

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

但是隨著用戶數(shù)量的增長阶淘，并發(fā)讀寫數(shù)據(jù)庫成為了性能的瓶頸。

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

在Tomcat同服務(wù)器或同JVM中增加本地緩存互妓，并在外部增加分布式緩存溪窒，緩存熱門商品信息或熱門商品的HTML頁面等。通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉冯勉，大大降低數(shù)據(jù)庫壓力澈蚌。其中涉及的技術(shù)包括：使用Memcached作為本地緩存，使用Redis作為分

布式緩存灼狰，還會涉及到緩存一致性宛瞄、緩存穿透/擊穿、緩存雪崩交胚、熱點(diǎn)數(shù)據(jù)集中失效等問題份汗。

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

第三次演進(jì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ò)第七層（最高層、應(yīng)用層）的反向代理軟件或衡，主要支持HTTP協(xié)議焦影，還會涉及Session共享，文件上傳封断、下載的問題斯辰。

雖然反向代理使應(yīng)用服務(wù)器可以支持的并發(fā)量大大增加，但是并發(fā)量的增加也意味著更多請求穿透到數(shù)據(jù)庫坡疼，單機(jī)的數(shù)據(jù)庫最終會稱為性能瓶頸彬呻。

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

把數(shù)據(jù)庫劃分為讀庫和寫庫，讀庫可以有多個柄瑰，通過同步機(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)分析糠爬，需要通過其他途徑來解決寇荧，有興趣的可以去搜索相關(guān)的解決方案。

但是隨著用戶數(shù)量的增長执隧，單機(jī)的寫庫會逐漸達(dá)到性能瓶頸揩抡。

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

比如針對評論數(shù)據(jù)，可以按照商品的ID進(jìn)行Hash镀琉，路由到對應(yīng)的表中存儲峦嗤；針對支付記錄，可以按照支付的小時創(chuàng)建表屋摔，每個小時表繼續(xù)拆分為小表烁设，使用用戶ID或記錄編號來路由數(shù)據(jù)。只要實(shí)時操作的表數(shù)據(jù)量足夠小钓试，請求能夠足夠均勻地分發(fā)到多臺服務(wù)器上的小表装黑，那數(shù)據(jù)庫就能通過水平擴(kuò)展的方式來提升性能。其中前面提到的Mycat也支持在大表拆分為小表的情況下進(jìn)行訪問控制弓熏。

這種做法顯著地增加了數(shù)據(jù)庫運(yùn)維的難度曹体，對DBA的要求較高。當(dāng)數(shù)據(jù)庫設(shè)計到這種結(jié)構(gòu)時硝烂，已經(jīng)可以稱為分布式數(shù)據(jù)庫箕别，但是這只是一個邏輯的數(shù)據(jù)庫整體，數(shù)據(jù)庫里不同的組成部分是由不同的組件單獨(dú)來實(shí)現(xiàn)的滞谢，比如分庫分表的管理和請求分發(fā)由Mycat實(shí)現(xiàn)串稀，SQL的解析由單機(jī)的數(shù)據(jù)庫實(shí)現(xiàn)，讀寫分離可能由網(wǎng)關(guān)和消息隊(duì)列來實(shí)現(xiàn)狮杨，查詢結(jié)果的匯總可能由數(shù)據(jù)庫接口層來實(shí)現(xiàn)等母截，這種架構(gòu)其實(shí)是MPP（大規(guī)模并行處理）架構(gòu)的一類實(shí)現(xiàn)。

目前開源和商用都已經(jīng)有不少M(fèi)PP數(shù)據(jù)庫橄教，開源中比較流行的有Greenplum清寇、TiDB、 Postgresql XC护蝶、HAWQ等华烟，商用的如南大通用的GBase、睿帆科技的雪球DB持灰、華為的LibraA等盔夜，不同的MPP數(shù)據(jù)庫的側(cè)重點(diǎn)也不一樣，比如TiDB側(cè)重于分布式OLTP場景，Greenplum側(cè)重于分布式OLAP場景喂链，這些MPP數(shù)據(jù)庫基本都提供了類似Postgresql返十、Oracle、MySQL那樣的SQL標(biāo)準(zhǔn)支持能力椭微，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機(jī)器上并行執(zhí)行洞坑，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進(jìn)行返回，也提供了注入權(quán)限管理蝇率、分庫分表检诗、事務(wù)、數(shù)據(jù)副本等能力瓢剿，并且大多能夠支持100個節(jié)點(diǎn)以上的集群，大大降低了數(shù)據(jù)庫運(yùn)維的成本悠轩，并且使數(shù)據(jù)庫也能夠水平擴(kuò)展间狂。

雖然數(shù)據(jù)庫和Tomcat都能夠水平擴(kuò)展，可以支撐的并發(fā)量大幅提升火架，但是隨著用戶量的增長鉴象，最終單機(jī)的Nginx會稱為性能上的瓶頸。

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

由于性能瓶頸在Nginx何鸡，因此無法通過兩層的Nginx來實(shí)現(xiàn)多個Nginx的負(fù)載均衡纺弊。LVS和F5是工作在網(wǎng)絡(luò)第四層的負(fù)載均衡解決方案，其中LVS是軟件骡男，運(yùn)行在操作系統(tǒng)內(nèi)核態(tài)淆游，可對TCP請求或更高層級的網(wǎng)絡(luò)協(xié)議進(jìn)行轉(zhuǎn)發(fā)，因此支持的協(xié)議更豐富隔盛，并且性能也遠(yuǎn)高于Nginx犹菱，可假設(shè)單機(jī)的LVS可支持幾十萬個并發(fā)的請求轉(zhuǎn)發(fā)；F5是一種負(fù)載均衡硬件吮炕，與

LVS提供的能力類似腊脱，性能比LVS更高，但價格昂貴龙亲。由于LVS是單機(jī)版的軟件陕凹，若LVS所在服務(wù)器宕機(jī)則會導(dǎo)致整個后端系統(tǒng)都無法訪問，因此需要有備用節(jié)點(diǎn)鳄炉《虐遥可使用keepalived軟件模擬出虛擬IP，然后把虛擬IP綁定到多臺LVS服務(wù)器上拂盯，瀏覽器訪問虛擬IP時泥技，會被路由器重定向到真實(shí)的LVS服務(wù)器，當(dāng)主LVS服務(wù)器宕機(jī)時，keepalived軟件會自動更新路由器中的路由表珊豹，把虛擬IP重定向到另外一臺正常的LVS服務(wù)器簸呈，從而達(dá)到LVS服務(wù)器高可用的效果。

此處需要注意的是店茶，上圖中從Nginx層到Tomcat層這樣畫并不代表全部Nginx都轉(zhuǎn)發(fā)請求到全部的Tomcat蜕便，在實(shí)際使用時，可能會是幾個Nginx下面接一部分的Tomcat贩幻，這些Nginx之間通過keepalived實(shí)現(xiàn)高可用轿腺，其他的Nginx接另外的Tomcat，這樣可接入的Tomcat數(shù)量就能成倍的增加丛楚。

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

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

在DNS服務(wù)器中可配置一個域名對應(yīng)多個IP地址，每個IP地址對應(yīng)到不同的機(jī)房里的虛擬IP舶替。當(dāng)用戶訪問www.taobao.com時令境，DNS服務(wù)器會使用輪詢策略或其他策略，來選擇某個IP供用戶訪問顾瞪。此方式能實(shí)現(xiàn)機(jī)房間的負(fù)載均衡舔庶，至此，系統(tǒng)可做到機(jī)房級別的水平擴(kuò)展陈醒，千萬級到億級的并發(fā)量都可通過增加機(jī)房來解決栖茉，系統(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ù)需要同步蒲肋，需要考慮數(shù)據(jù)一致性的問題蘑拯，需要有更多的運(yùn)維手段來管理這些組件等。

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

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

按照業(yè)務(wù)板塊來劃分應(yīng)用代碼，使單個應(yīng)用的職責(zé)更清晰熟吏，相互之間可以做到獨(dú)立升級迭代距糖。這時候應(yīng)用之間可能會涉及到一些公共配置，可以通過分布式配置中心Zookeeper來解決牵寺。

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

第十一次演進(jìn)：復(fù)用的功

如用戶管理趣斤、訂單、支付黎休、鑒權(quán)等功能在多個應(yīng)用中都存在浓领，那么可以把這些功能的代碼單獨(dú)抽取出來形成一個單獨(dú)的服務(wù)來管理，這樣的服務(wù)就是所謂的微服務(wù)势腮，應(yīng)用和服務(wù)之間通過HTTP联贩、TCP或RPC請求等多種方式來訪問公共服務(wù)，每個單獨(dú)的服務(wù)都可以由單獨(dú)的團(tuán)隊(duì)來管理捎拯。此外泪幌，可以通過Dubbo、SpringCloud等框架實(shí)現(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ù)單獨(dú)抽取出來來管理涨醋，并使用企業(yè)消息總線來解除服務(wù)之間耦合問題的架構(gòu)，就是所謂的SOA（面向服務(wù)）架構(gòu)逝撬，這種架構(gòu)與微服務(wù)架構(gòu)容易混淆浴骂，因?yàn)楸憩F(xiàn)形式十分相似。個人理解宪潮，微服務(wù)架構(gòu)更多是指把系統(tǒng)里的公共服務(wù)抽取出來單獨(dú)運(yùn)維管理的思想溯警，而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ù)還要解決運(yùn)行環(huán)境沖突的問題喳挑。此外，對于如大促這類需要動態(tài)擴(kuò)縮容的場景滔悉，需要水平擴(kuò)展服務(wù)的場景蟀悦，就需要在新增的服務(wù)器上準(zhǔn)備運(yùn)行環(huán)境，部署服務(wù)等氧敢，運(yùn)維將變得十分困難日戈。

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

目前最流行的容器化技術(shù)是Docker，最流行的容器管理服務(wù)是Kubernetes(K8S)孙乖，應(yīng)用/服務(wù)可以打包為Docker鏡像浙炼，通過K8S來動態(tài)分發(fā)和部署鏡像份氧。Docker鏡像可理解為一個能運(yùn)行你的應(yīng)用/服務(wù)的最小的操作系統(tǒng)，里面放著應(yīng)用/服務(wù)的運(yùn)行代碼弯屈，運(yùn)行環(huán)境根據(jù)實(shí)際的需要設(shè)置好蜗帜。把整個“操作系統(tǒng)”打包為一個鏡像后，就可以分發(fā)到需要部署相關(guān)服務(wù)的機(jī)器上资厉，直接啟動Docker鏡像就可以把服務(wù)起起來厅缺，使服務(wù)的部署和運(yùn)維變得簡單。

在大促的之前宴偿，可以在現(xiàn)有的機(jī)器集群上劃分出服務(wù)器來啟動Docker鏡像湘捎，增強(qiáng)服務(wù)的性能，大促過后就可以關(guān)閉鏡像窄刘，對機(jī)器上的其他服務(wù)不造成影響（在之前窥妇，服務(wù)運(yùn)行在新增機(jī)器上需要修改系統(tǒng)配置來適配服務(wù)，這會導(dǎo)致機(jī)器上其他服務(wù)需要的運(yùn)行環(huán)境被破壞）娩践。但是雖然使用容器化技術(shù)后服務(wù)動態(tài)擴(kuò)縮問題得以解決活翩，但是機(jī)器還是需要公司自身來管理，在非大促的時候翻伺，還是需要閑置著大量的機(jī)器資源來應(yīng)對大促材泄，機(jī)器自身成本和運(yùn)維成本都極高，資源利用率低吨岭。

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

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

所謂的云平臺埋凯，就是把海量機(jī)器資源点楼，通過統(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ù)切端、個人博客等）彻坛。在云平臺中會涉及如下幾個概念：

1.IaaS：基礎(chǔ)設(shè)施即服務(wù)。對應(yīng)于上面所說的機(jī)器資源統(tǒng)一為資源整體踏枣，可動態(tài)申請硬件資源的層面昌屉。

2.PaaS：平臺即服務(wù)。對應(yīng)于上面所說的提供常用的技術(shù)組件椰于，方便系統(tǒng)的開發(fā)與維護(hù)怠益。

3.SaaS：軟件即服務(wù)。對應(yīng)于上面所說的提供開發(fā)好的應(yīng)用或服務(wù)瘾婿，按功能或性能要求付費(fèi)蜻牢。

至此，上面所提到的從高并發(fā)訪問問題偏陪，到服務(wù)的架構(gòu)和系統(tǒng)實(shí)施的層面都有了各自的解決方案抢呆。但是同時也應(yīng)該意識到，在上面的介紹中笛谦，其實(shí)是有意地忽略了諸如跨機(jī)房數(shù)據(jù)同步抱虐、分布式事務(wù)實(shí)現(xiàn)等等的實(shí)際問題，這些問題的解決方案可以去查找相關(guān)的資料去了解饥脑。

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

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

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

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

對于單次實(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í)是海量數(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ù)棧、機(jī)器學(xué)習(xí)算法等娃磺”∈總的來說大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求，整合各種大數(shù)據(jù)組件組合而成的架構(gòu)偷卧，一般會提供分布式存儲豺瘤、分布式計算、多維分析听诸、數(shù)據(jù)倉庫坐求、機(jī)器學(xué)習(xí)算法等能力。而服務(wù)端架構(gòu)則更多指的是應(yīng)用組織層面上的架構(gòu)蛇更，底層能力往往是由大數(shù)據(jù)架構(gòu)來提供的瞻赶。

有沒有一些架構(gòu)設(shè)計的原則赛糟？

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

2.回滾設(shè)計璧南。確保系統(tǒng)可以向前兼容掌逛，在系統(tǒng)升級時應(yīng)能有辦法回滾版本。

3.禁用設(shè)計司倚。應(yīng)該提供控制具體功能是否可用的配置豆混，在系統(tǒng)出現(xiàn)故障的情況下能夠快速下線功能篓像。

4.監(jiān)控設(shè)計。在設(shè)計階段就要考慮監(jiān)控的手段皿伺。

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

6.采用成熟的技術(shù)。剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的Bug妒穴，除了問題沒有商業(yè)支持可能會是一個災(zāi)難宋税。

7.資源隔離設(shè)計。避免單一業(yè)務(wù)占用全部資源讼油。

8.架構(gòu)應(yīng)提供水平擴(kuò)展的能力杰赛。系統(tǒng)只有做到能水平擴(kuò)展，才能有效避免性能瓶頸矮台。

9.非核心則購買乏屯。如果非核心功能的開發(fā)需要占用大量的研發(fā)資源才能解決，應(yīng)考慮購買成熟的產(chǎn)品瘦赫。

10.使用商用硬件瓶珊。商用硬件能有效降低硬件故障的幾率。

11.快速迭代耸彪。系統(tǒng)應(yīng)該快速開發(fā)小功能模塊伞芹，盡快上線進(jìn)行驗(yàn)證，早日發(fā)現(xiàn)問題蝉娜，大大降低系統(tǒng)交付的風(fēng)險唱较。

12.無狀態(tài)設(shè)計庞呕。服務(wù)接口應(yīng)該做成無狀態(tài)的劫灶，當(dāng)前接口的訪問不依賴接口上次訪問的狀態(tài)。

最后

本文到此就結(jié)束了厌秒，喜歡的朋友記得?“點(diǎn)贊收藏加關(guān)注”?在這小編也整理了微服務(wù)相關(guān)的學(xué)習(xí)資料和文檔需要的可在后臺私信小編領(lǐng)扔拧汉形！祝大家學(xué)習(xí)愉快！