国产一区二区在线导航,大香蕉久操,台湾精品在线看,天天搡天天狠天干天啪,福利在线观看,狠狠干狠狠色,美女日逼视频网站,成人高清免费观看MV

各位雙十一養(yǎng)貓了嗎??

又是一年雙十一，今天是是個(gè)科普帖。以設(shè)計(jì)淘寶網(wǎng)的后臺架構(gòu)為例，介紹下一百個(gè)并發(fā)到千萬級并發(fā)情況下服務(wù)端的架構(gòu)的 14 次演進(jìn)過程，同時(shí)列舉出每個(gè)演進(jìn)階段會遇到的相關(guān)技術(shù)。

基本概念

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

1）什么是分布式？

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

2）什么是高可用？

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

3）什么是集群？

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

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

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

4）什么是負(fù)載均衡？

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

5）什么是正向代理和反向代理？

系統(tǒng)內(nèi)部要訪問外部網(wǎng)絡(luò)時(shí)，統(tǒng)一通過一個(gè)代理服務(wù)器把請求轉(zhuǎn)發(fā)出去，在外部網(wǎng)絡(luò)看來就是代理服務(wù)器發(fā)起的訪問，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是正向代理；當(dāng)外部請求進(jìn)入系統(tǒng)時(shí)，代理服務(wù)器把該請求轉(zhuǎn)發(fā)到系統(tǒng)中的某臺服務(wù)器上，對外部請求來說，與之交互的只有代理服務(wù)器，此時(shí)代理服務(wù)器實(shí)現(xiàn)的是反向代理（推薦閱讀：什么是正向代理和反向代理）。

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

純真年代：單機(jī)架構(gòu)

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

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

第一次演進(jìn)

Tomcat 與數(shù)據(jù)庫分開部署

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

架構(gòu)瓶頸：隨著用戶數(shù)的增長，并發(fā)讀寫數(shù)據(jù)庫成為瓶頸。

第二次演進(jìn)

引入本地緩存和分布式緩存

在 Tomcat 同服務(wù)器上或同 JVM 中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品信息或熱門商品的 html 頁面等。通過緩存能把絕大多數(shù)請求在讀寫數(shù)據(jù)庫前攔截掉，大大降低數(shù)據(jù)庫壓力。

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

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

第三次演進(jìn)

引入反向代理實(shí)現(xiàn)負(fù)載均衡

在多臺服務(wù)器上分別部署 Tomcat，使用反向代理軟件把請求均勻分發(fā)到每個(gè) Tomcat 中。此處假設(shè) Tomcat 最多支持 100 個(gè)并發(fā)，Nginx?最多支持 50000 個(gè)并發(fā)，那么理論上?Nginx?把請求分發(fā)到 500 個(gè)Tomcat上，就能抗住 50000 個(gè)并發(fā)。

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

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

第四次演進(jìn)

數(shù)據(jù)庫讀寫分離

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

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

架構(gòu)瓶頸：業(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ù)器來支撐。這樣同時(shí)導(dǎo)致跨業(yè)務(wù)的表無法直接做關(guān)聯(lián)分析，需要通過其他途徑來解決，但這不是本文討論的重點(diǎn)，有興趣的可以自行搜索解決方案。

架構(gòu)瓶頸：隨著用戶數(shù)的增長，單機(jī)的寫庫會逐漸會達(dá)到性能瓶頸。

第六次演進(jìn)

把大表拆分為小表

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

這種做法顯著的增加了數(shù)據(jù)庫運(yùn)維的難度，對 DBA 的要求較高。數(shù)據(jù)庫設(shè)計(jì)到這種結(jié)構(gòu)時(shí)，已經(jīng)可以稱為分布式數(shù)據(jù)庫，但是這只是一個(gè)邏輯的數(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)有不少 MPP 數(shù)據(jù)庫，開源中比較流行的有 Greenplum、TiDB、Postgresql XC、HAWQ 等，商用的如南大通用的 GBase、睿帆科技的雪球 DB、華為的 LibrA 等等，不同的 MPP 數(shù)據(jù)庫的側(cè)重點(diǎn)也不一樣，如 TiDB 更側(cè)重于分布式 OLTP 場景，Greenplum 更側(cè)重于分布式 OLAP 場景，這些 MPP 數(shù)據(jù)庫基本都提供了類似 Postgresql、Oracle、MySQL 那樣的 SQL 標(biāo)準(zhǔn)支持能力，能把一個(gè)查詢解析為分布式的執(zhí)行計(jì)劃分發(fā)到每臺機(jī)器上并行執(zhí)行，最終由數(shù)據(jù)庫本身匯總數(shù)據(jù)進(jìn)行返回，也提供了諸如權(quán)限管理、分庫分表、事務(wù)、數(shù)據(jù)副本等能力，并且大多能夠支持 100 個(gè)節(jié)點(diǎn)以上的集群，大大降低了數(shù)據(jù)庫運(yùn)維的成本，并且使數(shù)據(jù)庫也能夠?qū)崿F(xiàn)水平擴(kuò)展。

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

第七次演進(jìn)

使用 LVS 或 F5 來使多個(gè)?Nginx?負(fù)載均衡

由于瓶頸在 Nginx，因此無法通過兩層的 Nginx 來實(shí)現(xiàn)多個(gè) 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 可支持幾十萬個(gè)并發(fā)的請求轉(zhuǎn)發(fā)；F5 是一種負(fù)載均衡硬件，與 LVS 提供的能力類似，性能比 LVS 更高，但價(jià)格昂貴。由于 LVS 是單機(jī)版的軟件，若 LVS 所在服務(wù)器宕機(jī)則會導(dǎo)致整個(gè)后端系統(tǒng)都無法訪問，因此需要有備用節(jié)點(diǎn)。可使用 keepalived 軟件模擬出虛擬 IP，然后把虛擬 IP 綁定到多臺 LVS 服務(wù)器上，瀏覽器訪問虛擬 IP 時(shí)，會被路由器重定向到真實(shí)的 LVS 服務(wù)器，當(dāng)主 LVS 服務(wù)器宕機(jī)時(shí)，keepalived 軟件會自動(dòng)更新路由器中的路由表，把虛擬 IP 重定向到另外一臺正常的 LVS 服務(wù)器，從而達(dá)到 LVS 服務(wù)器高可用的效果。

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

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

第八次演進(jìn)

通過 DNS 輪詢實(shí)現(xiàn)機(jī)房間的負(fù)載均衡

在 DNS 服務(wù)器中可配置一個(gè)域名對應(yīng)多個(gè) IP 地址，每個(gè) IP 地址對應(yīng)到不同的機(jī)房里的虛擬 IP。當(dāng)用戶訪問 www.taobao.com 時(shí)，DNS 服務(wù)器會使用輪詢策略或其他策略，來選擇某個(gè) IP 供用戶訪問。此方式能實(shí)現(xiàn)機(jī)房間的負(fù)載均衡，至此，系統(tǒng)可做到機(jī)房級別的水平擴(kuò)展，千萬級到億級的并發(fā)量都可通過增加機(jī)房來解決，系統(tǒng)入口處的請求并發(fā)量不再是問題。

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

第九次演進(jìn)

引入 NoSQL 數(shù)據(jù)庫和搜索引擎等技術(shù)

當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)多到一定規(guī)模時(shí)，數(shù)據(jù)庫就不適用于復(fù)雜的查詢了，往往只能滿足普通查詢的場景。對于統(tǒng)計(jì)報(bào)表場景，在數(shù)據(jù)量大時(shí)不一定能跑出結(jié)果，而且在跑復(fù)雜查詢時(shí)會導(dǎo)致其他查詢變慢，對于全文檢索、可變數(shù)據(jù)結(jié)構(gòu)等場景，數(shù)據(jù)庫天生不適用。因此需要針對特定的場景，引入合適的解決方案。如對于海量文件存儲，可通過分布式文件系統(tǒng) HDFS 解決，對于 key value 類型的數(shù)據(jù)，可通過 HBase 和 Redis 等方案解決，對于全文檢索場景，可通過搜索引擎如 ElasticSearch 解決，對于多維分析場景，可通過 Kylin 或 Druid 等方案解決。

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

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

第十次演進(jìn)

大應(yīng)用拆分為小應(yīng)用

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

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

第十一次演進(jìn)

復(fù)用的功能抽離成微服務(wù)

如用戶管理、訂單、支付、鑒權(quán)等功能在多個(gè)應(yīng)用中都存在，那么可以把這些功能的代碼單獨(dú)抽取出來形成一個(gè)單獨(dú)的服務(wù)來管理，這樣的服務(wù)就是所謂的微服務(wù)，應(yīng)用和服務(wù)之間通過 HTTP、TCP 或 RPC 請求等多種方式來訪問公共服務(wù)，每個(gè)單獨(dú)的服務(wù)都可以由單獨(dú)的團(tuán)隊(duì)來管理。此外，可以通過 Dubbo、SpringCloud 等框架實(shí)現(xiàn)服務(wù)治理、限流、熔斷、降級等功能，提高服務(wù)的穩(wěn)定性和可用性。

架構(gòu)瓶頸：不同服務(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)的耦合程度。

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

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

架構(gòu)瓶頸：業(yè)務(wù)不斷發(fā)展，應(yīng)用和服務(wù)都會不斷變多，應(yīng)用和服務(wù)的部署變得復(fù)雜，同一臺服務(wù)器上部署多個(gè)服務(wù)還要解決運(yùn)行環(huán)境沖突的問題，此外，對于如大促這類需要?jiǎng)討B(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)境隔離與動(dòng)態(tài)服務(wù)管理

目前最流行的容器化技術(shù)是 Docker(Docker 教程)，最流行的容器管理服務(wù)是 Kubernetes(K8S)，應(yīng)用/服務(wù)可以打包為 Docker 鏡像，通過 K8S 來動(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ù)起起來，使服務(wù)的部署和運(yùn)維變得簡單。

在大促的之前，可以在現(xiàn)有的機(jī)器集群上劃分出服務(wù)器來啟動(dòng) Docker 鏡像，增強(qiáng)服務(wù)的性能，大促過后就可以關(guān)閉鏡像，對機(jī)器上的其他服務(wù)不造成影響。

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

第十四次演進(jìn)

以云平臺承載系統(tǒng)

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

所謂的云平臺，就是把海量機(jī)器資源，通過統(tǒng)一的資源管理，抽象為一個(gè)資源整體，在之上可按需動(dò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ù)、個(gè)人博客等）。在云平臺中會涉及如下幾個(gè)概念：

1）IaaS：基礎(chǔ)設(shè)施即服務(wù)。對應(yīng)于上面所說的機(jī)器資源統(tǒng)一為資源整體，可動(dò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í)施的層面都有了各自的解決方案。但同時(shí)也應(yīng)該意識到，在上面的介紹中，其實(shí)是有意忽略了諸如跨機(jī)房數(shù)據(jù)同步、分布式事務(wù)實(shí)現(xiàn)等等的實(shí)際問題，這些問題以后有機(jī)會再拿出來單獨(dú)討論。

架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)小結(jié)

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

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

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

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

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

所謂的“大數(shù)據(jù)”其實(shí)是海量數(shù)據(jù)采集清洗轉(zhuǎn)換、數(shù)據(jù)存儲、數(shù)據(jù)分析、數(shù)據(jù)服務(wù)等場景解決方案的一個(gè)統(tǒng)稱，在每一個(gè)場景都包含了多種可選的技術(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)，一般會提供分布式存儲、分布式計(jì)算、多維分析、數(shù)據(jù)倉庫、機(jī)器學(xué)習(xí)算法等能力。而服務(wù)端架構(gòu)更多指的是應(yīng)用組織層面的架構(gòu)，底層能力往往是由大數(shù)據(jù)架構(gòu)來提供。

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么阿里巴巴禁止使用存儲過程？

為防止員工帶薪拉屎，快手公司推出“計(jì)時(shí)廁所”？官方稱只是為了測試！

又雙叒一個(gè)類Unix操作系統(tǒng)停止開發(fā)?。?！

21張圖揭秘在阿里、騰訊、美團(tuán)工作的區(qū)別

15 張圖，了解一下 TCP/IP 必知也必會的 10 個(gè)問題

抗住雙十一億級高并發(fā)架構(gòu)，是如何演進(jìn)的？