互聯(lián)網(wǎng)產(chǎn)品常常面臨龐大的用戶量，日均數(shù)十億PV的高并發(fā)，PB級別的數(shù)據(jù)存儲等問題的挑戰(zhàn)，同時(shí)要求保證系統(tǒng)的高可用和彈性伸縮，并且能夠根據(jù)需要進(jìn)行快速迭代擴(kuò)展，這些都對于系統(tǒng)架構(gòu)提出了很高的要求。

互聯(lián)網(wǎng)架構(gòu)從簡到繁的演進(jìn)經(jīng)歷了單體架構(gòu)-集群架構(gòu)-分布式架構(gòu)-微服務(wù)架構(gòu)以及最新的service mesh的演進(jìn)過程。

01. 簡單架構(gòu)

網(wǎng)站架構(gòu)的發(fā)展也是由簡到繁，早期互聯(lián)網(wǎng)產(chǎn)品用戶量少，并發(fā)量低，數(shù)據(jù)量小，多數(shù)只需要單個(gè)應(yīng)用服務(wù)器可以滿足需要，而數(shù)據(jù)庫和文件服務(wù)部署在外部單個(gè)服務(wù)器上，這就是最早互聯(lián)網(wǎng)架構(gòu)，架構(gòu)圖如下所示。

image

在該架構(gòu)所有業(yè)務(wù)邏輯均由單個(gè)server處理。并且文件和數(shù)據(jù)庫只部署在外部的單個(gè)server中，該架構(gòu)中存在的問題也比較明顯，server應(yīng)用、文件服務(wù)、數(shù)據(jù)庫均為單體服務(wù)，缺乏故障轉(zhuǎn)移，在升級維護(hù)中必須進(jìn)行停機(jī)，可用性低。在現(xiàn)在的業(yè)務(wù)場景中已經(jīng)不再適用。

02.緩存與讀寫分離

隨著訪問量的激增，數(shù)據(jù)量的快速膨脹，對應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器的IO性能要求也越來越高。單體服務(wù)總是資源有限，而單個(gè)數(shù)據(jù)庫的數(shù)據(jù)流量越來越大，數(shù)據(jù)的訪問性能也明顯下降。 為了進(jìn)一步降低數(shù)據(jù)庫的訪問壓力，對數(shù)據(jù)庫進(jìn)行讀寫分離、分庫分表等優(yōu)化。 讀寫分離即將數(shù)據(jù)庫分為主從數(shù)據(jù)庫，從庫實(shí)時(shí)同步主庫的更新內(nèi)容。寫請求訪問主數(shù)據(jù)庫，讀請求訪問從數(shù)據(jù)庫。分庫分表即是把原本存儲于一個(gè)庫的數(shù)據(jù)分塊存儲到多個(gè)庫上，把原本存儲于一個(gè)表的數(shù)據(jù)分塊存儲到多個(gè)表上。不論是讀寫分離還是分庫分表都有效分解了數(shù)據(jù)庫訪問壓力。

基于二八定律，即大部分的業(yè)務(wù)數(shù)據(jù)只集中于數(shù)據(jù)中的一小部分，而有些數(shù)據(jù)是需要經(jīng)常讀取，但是更新很少，或是訪問量非常大的數(shù)據(jù)塊，這些情況下我們就需要引入緩存層, 如果訪問命中緩存，既能減小數(shù)據(jù)庫的訪問壓力，又可以提高數(shù)據(jù)訪問性能。緩存的發(fā)展也是由簡單到復(fù)雜，由單體到緩存集群，由單點(diǎn)到高可用。本地緩存的特點(diǎn)就是可以提供快速訪問，但無法實(shí)現(xiàn)共享，無法保證高可用。而緩存集群可以提供高可用、可共享、大容量的存儲，緩存層降低數(shù)據(jù)庫的讀寫IO，有效提升系統(tǒng)響應(yīng)能力。

image

03.動靜分離

隨著業(yè)務(wù)的進(jìn)一步爬坡，需要能夠進(jìn)一步降低服務(wù)器的壓力，這時(shí)候可以采用動靜分離技術(shù)。動靜分離技術(shù)是將服務(wù)的靜態(tài)資源與后臺應(yīng)用進(jìn)行分開部署，提高用戶訪問靜態(tài)資源的速度，降低對后臺的訪問壓力。

靜態(tài)資源一般放在CDN上，部署在網(wǎng)絡(luò)提供商的機(jī)房。用戶在訪問靜態(tài)資源時(shí)，可以很好的利用CDN的優(yōu)點(diǎn)，從距離自己最近的網(wǎng)絡(luò)提供商機(jī)房獲取數(shù)據(jù)。

動靜分離后，帶來的優(yōu)點(diǎn)是顯而易見的：后端應(yīng)用更為服務(wù)化，只需要提供api接口即可，前端可以通過更加專業(yè)的技術(shù)提高訪問效率。但同時(shí)靜態(tài)文件的緩存更新以及前后端的更新成本都是動靜分離所帶來的問題。

image

04.集群化高可用架構(gòu)

隨著用戶規(guī)模和業(yè)務(wù)量的不斷上漲，單個(gè)應(yīng)用服務(wù)器將出現(xiàn)性能瓶頸，對于PB級的數(shù)據(jù)和高并發(fā)用戶大流量訪問，單一或者主備的數(shù)據(jù)庫、文件系統(tǒng)都已經(jīng)不能滿足需求，需要集群化來分擔(dān)負(fù)載。當(dāng)數(shù)據(jù)規(guī)模達(dá)到一定規(guī)模，傳統(tǒng)關(guān)系型數(shù)據(jù)庫性能下滑非常嚴(yán)重，通過分庫分表也難以應(yīng)對，為了支撐海量數(shù)據(jù)和流量，出現(xiàn)了NoSql數(shù)據(jù)庫，它關(guān)注對數(shù)據(jù)高并發(fā)地讀寫和對海量數(shù)據(jù)的存儲。

同時(shí)應(yīng)用服務(wù)器從單體變?yōu)榧?，客戶端也不再是直接接入后端?yīng)用，而是轉(zhuǎn)而通過負(fù)載均衡設(shè)備代理后端多個(gè)服務(wù)器集群，一方面將訪問壓力分?jǐn)偟搅硕鄠€(gè)后端應(yīng)用上，單個(gè)應(yīng)用不再是性能瓶頸，另一方面可以實(shí)現(xiàn)服務(wù)路由，以及異常熔斷等特性。

為了進(jìn)一步降低服務(wù)端壓力，降低客戶端訪問延遲，客戶端與負(fù)載均衡設(shè)備之間加入CDN對靜態(tài)資源進(jìn)行緩存加速，利用GSLB調(diào)度體系，將用戶請求精準(zhǔn)調(diào)度至最優(yōu)接入節(jié)點(diǎn)。以達(dá)到最優(yōu)的訪問性能。

image

05.業(yè)務(wù)拆分與分布式

同時(shí)隨著業(yè)務(wù)場景的復(fù)雜化，存儲規(guī)模越來越龐大。將業(yè)務(wù)進(jìn)行拆分并分而治之成為更好的選擇。大型的業(yè)務(wù)場景被細(xì)分為單個(gè)更小的業(yè)務(wù)子場景，按照系統(tǒng)業(yè)務(wù)功能進(jìn)行劃分，例如對于電商系統(tǒng)，按功能維度我們可以拆分為商品中心，訂單中心，用戶中心，購物車，結(jié)算等功能模塊。每一個(gè)子模塊由不同的業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)。每個(gè)子業(yè)務(wù)模塊進(jìn)行獨(dú)立開發(fā)、部署、運(yùn)維。

隨著對業(yè)務(wù)場景越來越細(xì)的劃分，模塊越來越多，整個(gè)應(yīng)用的復(fù)雜度也越來越高，大量的獨(dú)立子應(yīng)用對數(shù)據(jù)庫的獨(dú)立訪問，導(dǎo)致后端數(shù)據(jù)庫的壓力越來越大，需要將各個(gè)子應(yīng)用的重疊邏輯再進(jìn)行抽取為獨(dú)立子服務(wù)，子應(yīng)用服務(wù)之間通過RPC或者消息系統(tǒng)進(jìn)行相互通信，因此出現(xiàn)了分布式應(yīng)用, 到目前為止的分布式架構(gòu)已經(jīng)能夠應(yīng)對大部分高并發(fā)，大流量的業(yè)務(wù)場景。

image

06.SOA

分布式架構(gòu)出現(xiàn)之后，隨著應(yīng)用的更細(xì)力度的拆分，逐漸呈現(xiàn)了一個(gè)相互依賴、公共的模塊，這些模塊大都依賴于相同的邏輯或者功能代碼。這時(shí)候就需要把這些應(yīng)用的公用模塊提出來，采用獨(dú)立部署統(tǒng)一管理的方式，提高重用度，這就是服務(wù)導(dǎo)向架構(gòu)（SOA）。

SOA其實(shí)是一種理念，它的主要特性：面向服務(wù)的計(jì)算，服務(wù)之間松散耦合，支持服務(wù)的封裝，服務(wù)注冊和自動發(fā)現(xiàn)。但是SOA并沒有定義出具體的實(shí)現(xiàn)方式，目前一種主要的實(shí)現(xiàn)方式是企業(yè)服務(wù)總線（Enterprise Service Bus，ESB），ESB的根本目標(biāo)是解決異構(gòu)系統(tǒng)的連通性，通過協(xié)議轉(zhuǎn)換、消息解析、消息路由把服務(wù)提供者的數(shù)據(jù)傳遞到服務(wù)消費(fèi)者。所以SOA的中心化雖然重，但是會解決一些公用邏輯的問題。

image

07.微服務(wù)

基于SOA的系統(tǒng)架構(gòu)實(shí)現(xiàn)了松耦合，系統(tǒng)之間通過服務(wù)接口（Service API）和中心化管理的企業(yè)服務(wù)總線（ESB）進(jìn)行交互, 但這種拆分往往是業(yè)務(wù)系統(tǒng)的一種垂直拆分，拆分的子系統(tǒng)隨著業(yè)務(wù)的復(fù)雜耦合仍然面臨難以開發(fā)和維護(hù)的問題。因此更細(xì)粒度的拆分變得必要，將子系統(tǒng)功能進(jìn)一步拆分，變成一項(xiàng)項(xiàng)的服務(wù)。系統(tǒng)分布式架構(gòu)，服務(wù)去中心化實(shí)現(xiàn)，也即微服務(wù)的思想。

敏捷開發(fā)專家Martin Fowler 在2014年定義了微服務(wù)架構(gòu)。微服務(wù)架構(gòu)風(fēng)格是一個(gè)系統(tǒng)，由一套獨(dú)立運(yùn)行的微服務(wù)組成， 這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，服務(wù)關(guān)注單一業(yè)務(wù)，服務(wù)間采用輕量級的通信機(jī)制（通常是HTTP資源的API），可以全自動獨(dú)立部署，可以使用不同的編程語言和數(shù)據(jù)存儲技術(shù)。

微服務(wù)架構(gòu)通過業(yè)務(wù)拆分實(shí)現(xiàn)服務(wù)組件化，通過組件組合快速開發(fā)系統(tǒng)，業(yè)務(wù)單一的服務(wù)組件又可以獨(dú)立部署，使得整個(gè)系統(tǒng)變得清晰靈活。但是大量的分布式服務(wù)又使得架構(gòu)實(shí)現(xiàn)面臨問題，如服務(wù)注冊發(fā)現(xiàn)，服務(wù)統(tǒng)一接入和權(quán)限控制，服務(wù)的負(fù)載均衡，服務(wù)配置的集中管理，服務(wù)熔斷，服務(wù)監(jiān)控等。所以在微服務(wù)架構(gòu)中除了業(yè)務(wù)服務(wù)組件外通常會引入服務(wù)注冊發(fā)現(xiàn)組件來進(jìn)行服務(wù)治理，引入服務(wù)網(wǎng)關(guān)組件來提供統(tǒng)一入口和權(quán)限控制，引入負(fù)載均衡組件來提供客戶端或服務(wù)器端的負(fù)載均衡，引入集中配置組件來提供服務(wù)集中管理，引入熔斷器組件來提供服務(wù)熔斷，引入服務(wù)追蹤組件來提供服務(wù)監(jiān)控等。因此微服務(wù)架構(gòu)是由這些基礎(chǔ)的服務(wù)組件和業(yè)務(wù)微服務(wù)組件共同組成?；镜奈⒎?wù)架構(gòu)如圖所示：

image

微服務(wù)架構(gòu)在業(yè)界已經(jīng)有了很多成熟的實(shí)踐， Netflix推出了經(jīng)過生產(chǎn)驗(yàn)證的NetflixOSS， Pivotal 將 NetflixOSS 開源微服務(wù)組件集成到其 Spring 體系，推出 Spring Cloud，阿里推出了服務(wù)治理能力豐富的生產(chǎn)級分布式服務(wù)框架Dubbo，谷歌推出了基于 protobuf 的強(qiáng)契約編程模型的 RPC 框架gRPC。 服務(wù)發(fā)現(xiàn)組件除dubbo外還有Eureka，Consul和Zookeeper, 服務(wù)網(wǎng)關(guān)組件有Spring Cloud體系的Zuul，基于 Nginx/OpenResty 的 API 網(wǎng)關(guān) Kong， 配置中心組件有Spring Cloud 自帶 Spring Cloud Config和攜程的Apollo，服務(wù)監(jiān)控組件有Zipkin、Pinpoint和CAT，服務(wù)熔斷組件有Netflix 的 Hystrix等。

微服務(wù)的交付除了依賴成熟的框架構(gòu)建系統(tǒng)外，自動化部署也需要自動化部署工具的支持。容器化技術(shù)已經(jīng)成為自動化部署微服務(wù)的一種理想手段。Docker 和其他類似的 Linux 容器技術(shù)使得軟件開發(fā)和持續(xù)交付變得很容易，大大降低了微服務(wù)運(yùn)維的難度，也使得系統(tǒng)宕機(jī)風(fēng)險(xiǎn)大大降低。

采用微服務(wù)架構(gòu)后，項(xiàng)目可以快速迭代與持續(xù)交付。但是也帶了一些弊端，開發(fā)人員除了需要關(guān)注業(yè)務(wù)邏輯實(shí)現(xiàn)外還需要考慮業(yè)務(wù)的一系列問題，比如服務(wù)注冊，服務(wù)發(fā)現(xiàn)，服務(wù)通訊，負(fù)載均衡，服務(wù)熔斷，服務(wù)超時(shí)等，這些是非常重要的。大多數(shù)時(shí)候，我們需要依賴第三方庫或者組件來提供這些服務(wù)，像上文提到的Hystrix, Eureka這些組件，在其服務(wù)組織中起到了廣泛的應(yīng)用。但這些組件的使用是侵入式的，這要求開發(fā)人員需要額外的精力去關(guān)注一些非業(yè)務(wù)邏輯層面的事情。而服務(wù)網(wǎng)格架構(gòu)（Service Mesh）的出現(xiàn)，讓業(yè)務(wù)開發(fā)人員得以真正解脫。

服務(wù)網(wǎng)格架構(gòu)是在微服務(wù)架構(gòu)盛行的今天的必然產(chǎn)物，服務(wù)網(wǎng)格架構(gòu)可以說是微服務(wù)架構(gòu)的一種實(shí)現(xiàn)，將開發(fā)人員從服務(wù)之間的交互中釋放出來，專心維護(hù)業(yè)務(wù)邏輯。服務(wù)網(wǎng)格是一個(gè)基礎(chǔ)設(shè)施層，用于代理服務(wù)間的通信，來負(fù)責(zé)消息直接按需傳遞，開發(fā)人員不需要在考慮服務(wù)發(fā)現(xiàn)等非業(yè)務(wù)邏輯，服務(wù)的治理也上升到統(tǒng)一的層面。服務(wù)網(wǎng)格對業(yè)務(wù)是相對透明的，與業(yè)務(wù)始終部署在一起。

image

上圖是一個(gè)簡單的服務(wù)網(wǎng)格例子，不同的業(yè)務(wù)之間通過服務(wù)網(wǎng)格進(jìn)行通訊，服務(wù)網(wǎng)格根據(jù)預(yù)先定義好的規(guī)則進(jìn)行流量治理：可以配置A/B測試，金絲雀發(fā)布，同樣也可以根據(jù)服務(wù)網(wǎng)格的進(jìn)行流量的統(tǒng)計(jì)。

image

借用服務(wù)網(wǎng)格的一個(gè)經(jīng)典的圖例，在微服務(wù)大量部署之后，每個(gè)服務(wù)節(jié)點(diǎn)的sidecar進(jìn)程自然就形成了一個(gè)網(wǎng)格。

總而言之，微服務(wù)架構(gòu)實(shí)現(xiàn)了業(yè)務(wù)的解耦，使系統(tǒng)具備了良好的擴(kuò)展性和伸縮性，單個(gè)服務(wù)組件可以獨(dú)立部署，便于組件的開發(fā)測試部署和維護(hù)，服務(wù)自治也可以將數(shù)據(jù)管理去中心化，容器化部署平臺也降低了測試、部署和運(yùn)維的難度，使軟件開發(fā)迭代更加敏捷快速，但分布式系統(tǒng)固有的難題（如分布式事務(wù)等）在微服務(wù)架構(gòu)中也依然存在。