本文以淘寶為例女蜈，介紹從一百個并發(fā)到千萬級并發(fā)下服務(wù)端架構(gòu)的演進過程持舆，同時列舉出每個演進階段遇到的相關(guān)技術(shù)，讓大家對架構(gòu)的演進有一個整體的認(rèn)知伪窖，文章最后匯總了一些架構(gòu)設(shè)計的原則逸寓。
在介紹架構(gòu)之前，為了避免部分讀者對架構(gòu)設(shè)計中的一些概念不了解覆山，下面對幾個最基礎(chǔ)的概念進行介紹：
①分布式：系統(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)外部請求進入系統(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)演進
單機架構(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ù)驾孔。
第一次演進：Tomcat 與數(shù)據(jù)庫分開部署
Tomcat 和數(shù)據(jù)庫分別獨占服務(wù)器資源，顯著提高兩者各自性能。隨著用戶數(shù)的增長助币，并發(fā)讀寫數(shù)據(jù)庫成為瓶頸浪听。
第二次演進：引入本地緩存和分布式緩存
在 Tomcat 同服務(wù)器上或同 JVM 中增加本地緩存，并在外部增加分布式緩存眉菱，緩存熱門商品信息或熱門商品的 HTML 頁面等迹栓。
通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉，大大降低數(shù)據(jù)庫壓力俭缓。
其中涉及的技術(shù)包括：使用 Memcached 作為本地緩存克伊，使用 Redis 作為分布式緩存，還會涉及緩存一致性华坦、緩存穿透/擊穿愿吹、緩存雪崩、熱點數(shù)據(jù)集中失效等問題惜姐。
緩存抗住了大部分的訪問請求犁跪，隨著用戶數(shù)的增長，并發(fā)壓力主要落在單機的 Tomcat 上歹袁，響應(yīng)逐漸變慢坷衍。
第三次演進：引入反向代理實現(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ù)庫最終成為瓶頸。
第四次演進：數(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ù)庫柜裸，相互影響性能。
第五次演進：數(shù)據(jù)庫按業(yè)務(wù)分庫
把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫中粱锐，使業(yè)務(wù)之間的資源競爭降低疙挺，對于訪問量大的業(yè)務(wù)，可以部署更多的服務(wù)器來支撐怜浅。
這樣同時導(dǎo)致跨業(yè)務(wù)的表無法直接做關(guān)聯(lián)分析铐然，需要通過其他途徑來解決，但這不是本文討論的重點恶座，有興趣的可以自行搜索解決方案锦爵。隨著用戶數(shù)的增長，單機的寫庫會逐漸達到性能瓶頸奥裸。
第六次演進：把大表拆分為小表
比如針對評論數(shù)據(jù)险掀，可按照商品 ID 進行 Hash，路由到對應(yīng)的表中存儲;針對支付記錄湾宙，可按照小時創(chuàng)建表樟氢，每個小時表繼續(xù)拆分為小表，使用用戶 ID 或記錄編號來路由數(shù)據(jù)侠鳄。
只要實時操作的表數(shù)據(jù)量足夠小埠啃，請求能夠足夠均勻的分發(fā)到多臺服務(wù)器上的小表，那數(shù)據(jù)庫就能通過水平擴展的方式來提高性能伟恶。其中前面提到的 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ù)進行返回忘伞。
也提供了諸如權(quán)限管理、分庫分表沙兰、事務(wù)氓奈、數(shù)據(jù)副本等能力，并且大多能夠支持 100 個節(jié)點以上的集群鼎天，大大降低了數(shù)據(jù)庫運維的成本舀奶，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴展。
數(shù)據(jù)庫和 Tomcat 都能夠水平擴展斋射，可支撐的并發(fā)大幅提高育勺，隨著用戶數(shù)的增長但荤，最終單機的 Nginx 會成為瓶頸。
第七次演進：使用 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é)議進行轉(zhuǎn)發(fā)。
因此支持的協(xié)議更豐富赘方，并且性能也遠高于 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ù)器邪意，從而達到 LVS 服務(wù)器高可用的效果九妈。
此處需要注意的是，上圖中從 Nginx 層到 Tomcat 層這樣畫并不代表全部 Nginx 都轉(zhuǎn)發(fā)請求到全部的 Tomcat雾鬼。
在實際使用時萌朱，可能會是幾個 Nginx 下面接一部分的 Tomcat，這些 Nginx 之間通過 Keepalived 實現(xiàn)高可用策菜，其他的 Nginx 接另外的 Tomcat晶疼，這樣可接入的 Tomcat 數(shù)量就能成倍的增加。
由于 LVS 也是單機的又憨，隨著并發(fā)數(shù)增長到幾十萬時翠霍，LVS 服務(wù)器最終會達到瓶頸，此時用戶數(shù)達到千萬甚至上億級別蠢莺，用戶分布在不同的地區(qū)寒匙，與服務(wù)器機房距離不同，導(dǎo)致了訪問的延遲會明顯不同躏将。
第八次演進：通過 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)可做到機房級別的水平擴展，千萬級到億級的并發(fā)量都可通過增加機房來解決沟沙，系統(tǒng)入口處的請求并發(fā)量不再是問題河劝。
隨著數(shù)據(jù)的豐富程度和業(yè)務(wù)的發(fā)展，檢索矛紫、分析等需求越來越豐富赎瞎，單單依靠數(shù)據(jù)庫無法解決如此豐富的需求。
第九次演進：引入 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ù)維度能夠極大擴充传泊，隨之而來的是一個應(yīng)用中包含了太多的業(yè)務(wù)代碼鼠渺，業(yè)務(wù)的升級迭代變得困難。
第十次演進：大應(yīng)用拆分為小應(yīng)用
按照業(yè)務(wù)板塊來劃分應(yīng)用代碼眷细，使單個應(yīng)用的職責(zé)更清晰拦盹，相互之間可以做到獨立升級迭代。
這時候應(yīng)用之間可能會涉及到一些公共配置溪椎，可以通過分布式配置中心 Zookeeper 來解決普舆。
不同應(yīng)用之間存在共用的模塊，由應(yīng)用單獨管理會導(dǎo)致相同代碼存在多份校读，導(dǎo)致公共功能升級時全部應(yīng)用代碼都要跟著升級沼侣。
第十一次演進：復(fù)用的功能抽離成微服務(wù)
如用戶管理、訂單歉秫、支付蛾洛、鑒權(quán)等功能在多個應(yīng)用中都存在，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務(wù)來管理雁芙。
這樣的服務(wù)就是所謂的微服務(wù)轧膘，應(yīng)用和服務(wù)之間通過 HTTP、TCP 或 RPC 請求等多種方式來訪問公共服務(wù)兔甘，每個單獨的服務(wù)都可以由單獨的團隊來管理谎碍。
此外，可以通過 Dubbo裂明、Spring Cloud 等框架實現(xiàn)服務(wù)治理椿浓、限流、熔斷闽晦、降級等功能扳碍，提高服務(wù)的穩(wěn)定性和可用性。
不同服務(wù)的接口訪問方式不同仙蛉，應(yīng)用代碼需要適配多種訪問方式才能使用服務(wù)笋敞。
此外，應(yīng)用訪問服務(wù)荠瘪，服務(wù)之間也可能相互訪問夯巷，調(diào)用鏈將會變得非常復(fù)雜，邏輯變得混亂哀墓。
第十二次演進：引入企業(yè)服務(wù)總線 ESB 屏蔽服務(wù)接口的訪問差異
通過 ESB 統(tǒng)一進行訪問協(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)擴縮容的場景，需要水平擴展服務(wù)的性能瘩例，就需要在新增的服務(wù)上準(zhǔn)備運行環(huán)境，部署服務(wù)等，運維將變得十分困難痴腌。
第十三次演進：引入容器化技術(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)擴縮容問題得以解決，但是機器還是需要公司自身來管理，在非大促的時候砖第，還是需要閑置著大量的機器資源來應(yīng)對大促撤卢，機器自身成本和運維成本都極高，資源利用率低梧兼。
第十四次演進：以云平臺承載系統(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ā)和維護衣赶。
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)整是否必須按照上述演變路徑進行?
不是的，以上所說的架構(gòu)演變順序只是針對某個側(cè)面進行單獨的改進职辨，在實際場景中盗蟆，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面舒裤，這時候就應(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)要求就足夠了，但要留有擴展架構(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ù)中心進行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用管毙。
采用成熟的技術(shù)腿椎。剛開發(fā)的或開源的技術(shù)往往存在很多隱藏的 Bug，出了問題沒有商業(yè)支持可能會是一個災(zāi)難夭咬。
資源隔離設(shè)計啃炸。應(yīng)避免單一業(yè)務(wù)占用全部資源。
架構(gòu)應(yīng)能水平擴展卓舵。系統(tǒng)只有做到能水平擴展南用，才能有效避免瓶頸問題。
非核心則購買掏湾。非核心功能若需要占用大量的研發(fā)資源才能解決裹虫，則考慮購買成熟的產(chǎn)品。
使用商用硬件忘巧。商用硬件能有效降低硬件故障的機率恒界。
快速迭代。系統(tǒng)應(yīng)該快速開發(fā)小功能模塊砚嘴，盡快上線進行驗證十酣，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風(fēng)險涩拙。
無狀態(tài)設(shè)計。服務(wù)接口應(yīng)該做成無狀態(tài)的耸采，當(dāng)前接口的訪問不依賴于接口上次訪問的狀態(tài)兴泥。
作者：歐仕華
