Intro

從最早的 html 的學習到現(xiàn)在從單體應用遷移到微服務架構(gòu)，所經(jīng)歷的網(wǎng)站架構(gòu)也一直在變化，于是想寫一篇關(guān)于網(wǎng)站架構(gòu)變遷的文章。

單服務器

最早的我們的網(wǎng)站只有一臺服務器，網(wǎng)站應用 + 數(shù)據(jù)庫 + 網(wǎng)站文件 都在同一臺服務器上，有的時候一臺服務器上也會有多個網(wǎng)站。

這個階段的服務器上除了 Web Server，還會裝一個數(shù)據(jù)庫服務器，網(wǎng)站文件一般是放在網(wǎng)站目錄下保存的

數(shù)據(jù)庫服務器 + 網(wǎng)站服務器

數(shù)據(jù)庫和應用分離，數(shù)據(jù)庫使用獨立的數(shù)據(jù)庫服務器，網(wǎng)站服務器上只有網(wǎng)站，不在安裝數(shù)據(jù)庫服務器。

一般的網(wǎng)站服務器的瓶頸在于內(nèi)存和CPU，而數(shù)據(jù)庫服務器瓶頸大多是在IO方面，所以分離之后對于網(wǎng)站服務器我們在擴容的時候可以更加關(guān)注于加大服務器內(nèi)存，加多核處理器，而數(shù)據(jù)庫服務器在可以更加關(guān)注于提高服務器 IO。

數(shù)據(jù)庫服務器 + 網(wǎng)站服務器 + 文件服務器

這個階段在上一階段的基礎上進一步把文件分離出來了，這樣網(wǎng)站遷移起來就不需要再遷移網(wǎng)站上傳的文件了，而且文件服務器升級的時候往往是提高存儲的容量

網(wǎng)站集群 + 負載均衡

網(wǎng)站發(fā)展到一定的規(guī)模，我們就可能會遇到一些系統(tǒng)瓶頸，除了升級服務器的配置外，我們也可以做網(wǎng)站集群，因為單一服務器配置升級到一定程度之后再想升級成本就會很高，相比之下做網(wǎng)站集群性價比會更高一些，可擴展性更好，而且做集群的話可以防止單點故障導致網(wǎng)站不可用，

既然是集群，多臺服務器同時工作就會遇到一個請求交由哪個服務來處理的問題，一般的我們會在網(wǎng)站集群前加一個負載均衡器，由負載均衡器根據(jù)一定的負載均衡算法選擇要處理的網(wǎng)站服務器

網(wǎng)站集群 + 負載均衡 + 分布式緩存

上面我們引入了網(wǎng)站集群+負載均衡，對于服務器 Session 可以指定使用 IP_Hash 或類似的負載均衡策略，但是如果不支持 IP_Hash 類的負載均衡算法，就需要支持分布式 Session 的支持，一般的分布式的 Session 我們可以借助分布式緩存來實現(xiàn)，而且可能會有一些內(nèi)存緩存，如果使用網(wǎng)站服務集群的話，就要考慮使用分布式緩存了，否則會導致數(shù)據(jù)的不一致，一臺服務器的緩存數(shù)據(jù)更新了，其他的緩存數(shù)據(jù)還是舊數(shù)據(jù)，就會造成很多問題，所以分布式緩存就很有必要引入了

網(wǎng)站集群 + 負載均衡 + 分布式緩存 + 數(shù)據(jù)庫讀寫分離

數(shù)據(jù)達到一定的規(guī)模之后，數(shù)據(jù)庫容易成為系統(tǒng)的瓶頸，除了引入緩存來解決之外，我們可以讓數(shù)據(jù)庫做讀寫分離，讀操作走從庫，寫操作走主庫

服務化架構(gòu)

上面的模式，對于網(wǎng)站應用來說，都是一個單體應用，從服務化架構(gòu)開始，開始真正的從單體架構(gòu)遷移到分布式架構(gòu)

單體應用發(fā)展到一定程度，應用的復雜度越來越高，代碼耦合度也會逐漸增加，從項目的角度來說，項目越來越大，項目維護也會變得越來越難，沖突也會越來越多，項目加載編譯運行需要的時間也越來越長，從部署的角度來說，不同的 API 之間會相互影響，我只改了某一個 API 但是部署的話只能全部更新。

于是服務化就應運而生，服務化將原來的單體架構(gòu)拆分成了分布式架構(gòu)，每一個服務只負責自己相關(guān)的業(yè)務邏輯，每一個服務都是一個小單體

微服務架構(gòu)

微服務架構(gòu) 1.0

在服務化的基礎上進一步演化出來了微服務架構(gòu)，微服務是服務化的進一步發(fā)展，微服務是去 "ESB" 的更細致的服務化

“微服務架構(gòu)是一種架構(gòu)模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務和服務之間采用輕量級的通信機制相互溝通（通常是基于HTTP的Restful API).每個服務都圍繞著具體的業(yè)務進行構(gòu)建，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構(gòu)"---- Martin Fowler的博客

當項目進行服務化改造的時候，這個過程并不是一蹴而就，一拍腦袋就成功了。要把項目服務化，需要解決很多的問題，例如：

服務之間怎么調(diào)用？訂單服務想要調(diào)用到商品服務的數(shù)據(jù)，怎么調(diào)用？怎么調(diào)用更加的穩(wěn)定，更加高效？【服務調(diào)用技術(shù)】

服務之間怎么負載均衡？訂單服務要調(diào)用商品服務，商品服務可能有很多個，怎么負載均衡【負載均衡技術(shù)】

服務怎么被管理？服務怎么定位？有故障了怎么處理？【服務注冊與發(fā)現(xiàn)技術(shù)】

故障怎么監(jiān)控？微服務系統(tǒng)中業(yè)務模塊很多，組件也很多，不同組件的指標不同，那么這些組件怎么進行監(jiān)控【監(jiān)控技術(shù)】

故障怎么定位？微服務架構(gòu)中，一個用戶的請求會涉及到多個內(nèi)部服務的調(diào)用，那么如何定位問題呢？【鏈路追蹤技術(shù)】

日志怎么分析處理？業(yè)務模塊多了，日志也就多了，直接查看日志文件已經(jīng)變的不顯示了，那么如何對日志進行分析查找呢？【日志分析技術(shù)】

權(quán)限管理？微服務拆分服務之后，會有很多服務對外暴露接口，這些接口如何進行統(tǒng)一的權(quán)限處理呢？【網(wǎng)關(guān)技術(shù)】

服務調(diào)用出現(xiàn)問題怎么處理？當一個服務因為各種原因停止響應時，調(diào)用方通常會等待一段時間，然后超時或者收到錯誤返回。如果調(diào)用鏈路比較長，可能會導致請求堆積，整條鏈路占用大量資源一直在等待下游響應。怎么解決呢？【服務熔斷，降級，限流】

微服務架構(gòu) 2.0

基于 Kubernetes + ServiceMesh 的云原生微服務架構(gòu)

微服務 2.0 更多的注重服務的治理，2.0 階段，微服務架構(gòu)引入了 ServiceMesh（服務網(wǎng)格）的概念通過 SideCar(側(cè)邊車)的方式實現(xiàn)一些對應用無侵入的管理，
使得服務治理更加通用，借助 Service Mesh 可以更方便的管理服務間調(diào)用，更好的做流量控制等

追本溯源，服務網(wǎng)格從無到有可分為三個演化階段（參見下圖）。
第一個階段，每個服務各顯神通，自行處理對外通訊。
第二個階段，所有服務使用統(tǒng)一的類庫進行通訊。
第三個階段，服務不再關(guān)心通訊細節(jié)，統(tǒng)統(tǒng)交給邊車進程，就像在TCP/IP協(xié)議中，應用層只需把要傳輸?shù)膬?nèi)容告訴TCP層，由TCP層負責將所有內(nèi)容原封不動的送達目的端，整個過程中應用層并不需要關(guān)心實際傳輸過程中的任何細節(jié)。

Kubernetes 讓微服務更簡單，使用 Kubernetes 就無需關(guān)注服務的注冊發(fā)現(xiàn)了，服務部署自動服務注冊發(fā)現(xiàn)，無需在應用代碼里向服務中心注冊，kubernetes 讓微服務的縮放更為簡單，你也可以配置根據(jù)應用的 CPU 等指數(shù)來實現(xiàn)應用的動態(tài)擴容，壓力大的時候自動擴容，增加節(jié)點，壓力小的時候自動縮放，減少服務節(jié)點。

More

一切脫離業(yè)務的架構(gòu)設計，都是耍流氓。

架構(gòu)不是一蹴而就的，架構(gòu)是演化出來的。

筆者經(jīng)驗有限，文中如果有錯誤，還望指出，萬分感謝