分布式架構(gòu)演進過程
2.2 第一次演進 ：Tomcat與數(shù)據(jù)庫分開部署
2.6 第五次演進 ：數(shù)據(jù)庫按業(yè)務(wù)分庫
2.8 第七次演進 ：使用LVS或F5來使多個Nginx負載均衡
2.9 第八次演進 ：通過DNS輪詢實現(xiàn)機房間的負載均衡
2.10 第九次演進 ：引入NoSQL數(shù)據(jù)庫和搜索引擎等技術(shù)
2.11 第十次演進 ：大應(yīng)用拆分為小應(yīng)用
2.13 第十二次演進 ：引入企業(yè)服務(wù)總線ESB屏蔽服務(wù)接口的訪問差異
2.14 第十三次演進 ：引入容器化技術(shù)實現(xiàn)運行環(huán)境隔離與動態(tài)服務(wù)管理
在介紹架構(gòu)之前钓试，為了避免部分讀者對架構(gòu)設(shè)計中的一些概念不了解蚊逢，下面對幾個最基礎(chǔ)的概念進行介紹：
系統(tǒng)中的多個模塊在不同的服務(wù)器上部署，即可稱為分布式系統(tǒng)茉贡，如Tomcat和數(shù)據(jù)庫分別部署在不同的服務(wù)器上怜瞒，或兩個相同功能的Tomcat
分別部署在不同的服務(wù)器上糟需。
系統(tǒng)中部分節(jié)點失效時忘晤，其他節(jié)點能夠接替它繼續(xù)提供服務(wù)旅赢，則可認為系統(tǒng)具有高可用性齿桃。
一個特定領(lǐng)域的軟件部署在多臺服務(wù)器上并作為一個整體提供一類服務(wù)，這個整體稱為集群煮盼。如Zookeeper中的Master和Slave分別部署在多臺服務(wù)? ? ? ? ? 器上源譬，共同組成一個整體提供集中配置服務(wù)。在常見的集群中孕似，客戶端往往能夠連接任意一個節(jié)點獲得服務(wù)，并且當集群中一個節(jié)點掉線時刮刑，其他節(jié)點 ? ? 往往能夠自動的接替它繼續(xù)提供服務(wù)喉祭，這時候說明集群具有高可用性。
請求發(fā)送到系統(tǒng)時雷绢，通過這些方式把請求均勻分發(fā)到多個節(jié)點上泛烙，使系統(tǒng)中每個節(jié)點能夠均勻的處理請求負載，則可認為系統(tǒng)是負載均衡的翘紊。
系統(tǒng)內(nèi)部要訪問外部網(wǎng)絡(luò)時蔽氨，統(tǒng)一通過一個代理服務(wù)器把請求轉(zhuǎn)發(fā)出去，在外部網(wǎng)絡(luò)看來就是代理服務(wù)器發(fā)起的訪問帆疟，此時代理服務(wù)器實現(xià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ù)器的過程柬脸。
以淘寶作為例子他去。在網(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ù)。
2.2 第一次演進 ：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)逐漸變慢
在多臺服務(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ù)包括：Mycat运嗜，它是數(shù)據(jù)庫中間件，可通過它來組織數(shù)據(jù)庫
的分離讀寫和分庫分表悯舟，客戶端通過它來訪問下層數(shù)據(jù)庫担租，還會涉及數(shù)據(jù)同步，數(shù)據(jù)一致性的問題抵怎。
業(yè)務(wù)逐漸變多奋救，不同業(yè)務(wù)之間的訪問量差距較大，不同業(yè)務(wù)直接競爭數(shù)據(jù)庫反惕，相互影響性能尝艘。
2.6 第五次演進 ：數(shù)據(jù)庫按業(yè)務(wù)分庫
把不同業(yè)務(wù)的數(shù)據(jù)保存到不同的數(shù)據(jù)庫中，使業(yè)務(wù)之間的資源競爭降低姿染，對于訪問量大的業(yè)務(wù)背亥，可以部署更多的服務(wù)器來
支持。這樣同時導致業(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é)構(gòu)的匯總可能由數(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標準支持能力肠阱，能把一個查詢解析為分布式的執(zhí)行計劃分發(fā)到每臺機器上并行執(zhí)行，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進行
返回朴读，也提供了諸如權(quán)限管理屹徘、分庫分表、事物衅金、數(shù)據(jù)副本等能力噪伊，并且大多能夠支持100個節(jié)點以上的集群，大大降低了
數(shù)據(jù)庫運維的成本氮唯，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴展鉴吹。
數(shù)據(jù)庫和Tomcat都能夠水平擴展，可支撐的并發(fā)大幅提高惩琉，隨著用戶數(shù)的增長豆励，最終單機的Nginx會成為瓶頸。
2.8 第七次演進 ：使用LVS或F5來使多個Nginx負載均衡
由于瓶頸在Nginx,因此無法通過兩層的Nginx來實現(xiàn)多個Nginx的負載均衡瞒渠。圖中的LVS和F5是工作在網(wǎng)絡(luò)第四層的負載均
衡解決方案良蒸，其中LVS是軟件，運行在操作系統(tǒng)內(nèi)核態(tài)伍玖，可對TCP請求或更高層級的網(wǎng)絡(luò)協(xié)議進行轉(zhuǎn)發(fā)诚啃，因此支持的協(xié)議
更豐富，并且性能也遠高于Nginx私沮，可假設(shè)單機的LVS可支持幾十萬個并發(fā)的請求轉(zhuǎn)發(fā)始赎；F5是一種負載均衡硬件和橙，與LVS提
供的能力類似，性能比LVS更高造垛，但價格昂貴魔招。由于LVS是單機版的軟件，若LVS所在服務(wù)器宕機則會導致整個后端系統(tǒng)都
無法訪問五辽，因此需要有備用節(jié)點办斑。可使用keepalived軟件模擬出虛擬IP杆逗，然后把虛擬IP綁定到多臺LVS服務(wù)器上乡翅，瀏覽器
訪問虛擬IP時，會被路由器重定向到真實的LVS服務(wù)器罪郊，當主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ù)器機房距離不同，導致了訪問的延遲會明顯不同荣回。
2.9 第八次演進 ：通過DNS輪詢實現(xiàn)機房間的負載均衡
在DNS服務(wù)器中可配置一個域名對應(yīng)多個IP地址遭贸，每個IP地址對應(yīng)到不同的機房里的虛擬IP。當用戶訪問www.taobao.com
時心软，DNS服務(wù)器會使用輪詢策略或其他策略壕吹，來選擇每個IP供用戶訪問。此方式能實現(xiàn)機房間的負載均衡删铃，至此耳贬，系統(tǒng)可
做到機房級別的水平擴展，千萬級到億級的并發(fā)量都可通過增加機房來解決猎唁，系統(tǒng)入口處的請求并發(fā)量不再是問題咒劲。
隨著數(shù)據(jù)的豐富程度和業(yè)務(wù)的發(fā)展，檢索、分析等需求越來越豐富腐魂，單單依靠數(shù)據(jù)庫無法解決如此豐富的需求帐偎。
2.10 第九次演進 ：引入NoSQL數(shù)據(jù)庫和搜索引擎等技術(shù)
當數(shù)據(jù)庫中的數(shù)據(jù)多到一定規(guī)模時，數(shù)據(jù)庫就不適用于復雜的查詢了蛔屹，往往只能滿足普通查詢的場景削樊。對于統(tǒng)計報表場景，在
數(shù)據(jù)量大時不一定能跑出結(jié)果兔毒，而且在跑復雜查詢時會導致其他查詢變慢漫贞，對于全文檢索、可變數(shù)據(jù)結(jié)構(gòu)等場景育叁，數(shù)據(jù)庫天
生不適用迅脐。因此需要針對特定的場景，引入合適的解決方案擂红。如對于海量文件存儲仪际，可通過分布式文件系統(tǒng)HDFS解決，對于
key value類型的數(shù)據(jù)昵骤，可通過HBase和Redis等方案解決树碱，對于全文檢索場景，可通過搜索引擎如ElasticSearch解決变秦，對于
多維分析場景成榜，可通過Kylin或Druid等方案解決。
當然蹦玫，引入更多組件同時會提高系統(tǒng)的復雜度赎婚，不同的組件保存的數(shù)據(jù)需要同步，需要考慮一致性的問題樱溉，需要有更多的運維手段來管理這些組件等挣输。
引入更多組件解決了豐富的需求，業(yè)務(wù)維度能夠極大擴充福贞，隨之而來的是一個應(yīng)用中包含了太多的業(yè)務(wù)代碼撩嚼，業(yè)務(wù)的升級
迭代變得困難。
2.11 第十次演進 ：大應(yīng)用拆分為小應(yīng)用
按照業(yè)務(wù)板塊來劃分應(yīng)用代碼挖帘，使單個應(yīng)用的職責更清晰完丽，相互之間可以做到獨立升級迭代。這時候應(yīng)用之間可能會涉及到
一些公共配置拇舀，可以通過分布式配置中心Zookeeper來解決逻族。
不同應(yīng)用之間存在共用的模塊，由應(yīng)用單獨管理會導致相同代碼存在多份骄崩，導致公共功能升級時全部應(yīng)用代碼都要跟著升級
聘鳞。
如用戶管理薄辅、訂單、支付搁痛、鑒權(quán)等功能在多個應(yīng)用中都存在长搀，那么可以把這些功能的代碼單獨抽取出來形成一個單獨的服務(wù)
來管理，這樣的服務(wù)就是所謂的微服務(wù)鸡典，應(yīng)用和服務(wù)之間通過HTTP源请、TCP或RPC請求等多種方式來訪問公共服務(wù)，每個單獨服務(wù)都可以由單獨的團隊來管理彻况。此外谁尸，可以通過Dubbo、SpringCloud等框架實現(xiàn)服務(wù)治理纽甘、限流良蛮、熔斷、降級等功能悍赢，提高
服務(wù)的穩(wěn)定性和可用性决瞳。
不同服務(wù)的接口訪問方式不同，應(yīng)用代碼需要適配多種訪問方式才能使用服務(wù)左权，此外皮胡，應(yīng)用訪問服務(wù)，服務(wù)之間也可能相互
訪問赏迟，調(diào)用鏈將會變得非常復雜屡贺，邏輯變得混亂。
2.13 第十二次演進 ：引入企業(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ù)的部署變得復雜蛤克，同一臺服務(wù)器上部署多個服務(wù)還要解決運行環(huán)境沖突的問題，此外夷蚊，對于如大促這些需要動態(tài)擴縮容的場景构挤，需要水平擴展服務(wù)的性能，就需要在新增的服務(wù)上準備運行環(huán)境惕鼓，部署
服務(wù)等筋现，運維將變得十分困難。
2.14 第十三次演進 ：引入容器化技術(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ù)不造成影響（3.14節(jié)之前姻氨，服務(wù)運行在新增機器上需要修改系統(tǒng)配置來適配服務(wù)，這會導致機器上
其他服務(wù)需要的運行環(huán)境被破壞）
使用容器化技術(shù)后服務(wù)動態(tài)擴縮容問題得以解決剪验，但是機器換還是需要公司自身來管理肴焊，在非大促的時候，還是需要閑置
著大量的機器資源來應(yī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ù)梯刚、個人博客等)。在云平臺中會涉及如下幾個概念 ：
1 ：IaaS ：基礎(chǔ)設(shè)施即服務(wù)薪寓。對應(yīng)于上面所說的機器資源統(tǒng)一為資源整體亡资，可動態(tài)申請硬件資源的層面；
2 ：PaaS ：平臺即服務(wù)向叉。對應(yīng)于上面所說的提供常用的技術(shù)組件方便系統(tǒng)的開發(fā)和維護锥腻；
3 ：SaaS ：軟件即服務(wù)。對應(yīng)于上面所說的提供開發(fā)好的應(yīng)用或服務(wù)母谎，按功能或性能要求付費瘦黑。
至此，以上所提到的從高并發(fā)訪問問題奇唤，到服務(wù)的架構(gòu)和系統(tǒng)實施的層面都有了各自的解決方案幸斥，但同時也應(yīng)該意識到，在
上面的介紹中咬扇，其實是有意忽略了諸如跨機房數(shù)據(jù)同步甲葬、分布式事物實現(xiàn)等等的實際問題，這些問題以后再單獨討論懈贺。
架構(gòu)的調(diào)整是否必須按照上述演變路徑進行经窖？
不是的，以上所說的架構(gòu)演進順序只是針對某個側(cè)面進行單獨的改進梭灿，在實際場景中画侣，可能同一時間會有幾個問題需要解決，或者可能
先達到瓶頸的是另外的方面堡妒，這時候就應(yīng)該按照實際問題實際解決配乱。如在政府類的并發(fā)量可能不大，但業(yè)務(wù)可能很豐富的場景，高并發(fā)
就不是重點解決的問題宪卿，此時優(yōu)先需要的可能會是豐富需求的解決方案。
對于將要實施的系統(tǒng)万栅，架構(gòu)應(yīng)該設(shè)計到什么程度佑钾？
對于單次實施并且性能指標明確的系統(tǒng)，架構(gòu)設(shè)計到能夠支持系統(tǒng)的性能指標要求就足夠了烦粒，但要留有擴展架構(gòu)的接口以便不備之需休溶。
對于不斷發(fā)展的系統(tǒng)，如電商平臺扰她，應(yīng)設(shè)計到滿足下一階段用戶量和性能指標要求的程度兽掰，并根據(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ù)棧、機器學習算法等呕乎『秕澹總的來說大數(shù)據(jù)架構(gòu)就是根據(jù)業(yè)務(wù)的需求，整合各種大數(shù)據(jù)組件組合而
成的架構(gòu)楣嘁，一般會提供分布式存儲磅轻、分布式計算、多維分析逐虚、數(shù)據(jù)倉庫聋溜、機器學習算法等能力。而服務(wù)端架構(gòu)更多指的是應(yīng)用組織
層面的架構(gòu)叭爱，底層能力往往是由大數(shù)據(jù)架構(gòu)來提供撮躁。
有沒有 一些架構(gòu)設(shè)計的原則？
1 ：N + 1設(shè)計买雾。系統(tǒng)中的每個組件都應(yīng)做到?jīng)]有單點故障把曼；
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ù)據(jù)中心進行多活，至少在一個機房斷電的情況下系統(tǒng)依然可用苇瓣；
6 ：采用成熟的技術(shù)尉间。剛開服的或開源的技術(shù)往往存在很多隱藏的bug，出了問題沒有商業(yè)支持可能會是一個災(zāi)難击罪；
7 ：資源隔離技術(shù)乌妒。應(yīng)避免單一業(yè)務(wù)占用全部資源；
8 ：架構(gòu)應(yīng)能水平擴展外邓。系統(tǒng)只有做到能水平擴展撤蚊，才能有效避免瓶頸問題；
9 ：非核心則購買损话。非核心功能若需要占用大量的研發(fā)資源才能解決侦啸，則考慮購買成熟的產(chǎn)品；
10 ：使用商用硬件丧枪。商用硬件能有效降低硬件故障的機率光涂；
11 ：快速迭代。系統(tǒng)應(yīng)該快速開發(fā)小功能模塊拧烦，盡快上線進行驗證忘闻，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風險；
12 ：無狀態(tài)設(shè)計恋博。服務(wù)接口應(yīng)該做成無狀態(tài)的齐佳，當前接口的訪問不依賴于接口上次訪問的狀態(tài)。
