網(wǎng)站架構(gòu)變遷

Intro

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

單服務(wù)器

最早的我們的網(wǎng)站只有一臺(tái)服務(wù)器，網(wǎng)站應(yīng)用 + 數(shù)據(jù)庫(kù) + 網(wǎng)站文件都在同一臺(tái)服務(wù)器上，有的時(shí)候一臺(tái)服務(wù)器上也會(huì)有多個(gè)網(wǎng)站。

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

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)化架構(gòu)

上面的模式，對(duì)于網(wǎng)站應(yīng)用來(lái)說(shuō)，都是一個(gè)單體應(yīng)用，從服務(wù)化架構(gòu)開(kāi)始，開(kāi)始真正的從單體架構(gòu)遷移到分布式架構(gòu)

單體應(yīng)用發(fā)展到一定程度，應(yīng)用的復(fù)雜度越來(lái)越高，代碼耦合度也會(huì)逐漸增加，從項(xiàng)目的角度來(lái)說(shuō)，項(xiàng)目越來(lái)越大，項(xiàng)目維護(hù)也會(huì)變得越來(lái)越難，沖突也會(huì)越來(lái)越多，項(xiàng)目加載編譯運(yùn)行需要的時(shí)間也越來(lái)越長(zhǎng)，從部署的角度來(lái)說(shuō)，不同的 API 之間會(huì)相互影響，我只改了某一個(gè) API 但是部署的話只能全部更新。

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

微服務(wù)架構(gòu)

微服務(wù)架構(gòu) 1.0

在服務(wù)化的基礎(chǔ)上進(jìn)一步演化出來(lái)了微服務(wù)架構(gòu)，微服務(wù)是服務(wù)化的進(jìn)一步發(fā)展，微服務(wù)是去 "ESB" 的更細(xì)致的服務(wù)化

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

當(dāng)項(xiàng)目進(jìn)行服務(wù)化改造的時(shí)候，這個(gè)過(guò)程并不是一蹴而就，一拍腦袋就成功了。要把項(xiàng)目服務(wù)化，需要解決很多的問(wèn)題，例如：

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

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

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

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

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

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

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

服務(wù)調(diào)用出現(xiàn)問(wèn)題怎么處理？當(dāng)一個(gè)服務(wù)因?yàn)楦鞣N原因停止響應(yīng)時(shí)，調(diào)用方通常會(huì)等待一段時(shí)間，然后超時(shí)或者收到錯(cuò)誤返回。如果調(diào)用鏈路比較長(zhǎng)，可能會(huì)導(dǎo)致請(qǐng)求堆積，整條鏈路占用大量資源一直在等待下游響應(yīng)。怎么解決呢？【服務(wù)熔斷，降級(jí)，限流】

微服務(wù)架構(gòu) 2.0

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

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

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

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