網站架構變遷

網站架構變遷

Intro

從最先的 html 的學習到如今從單體應用遷移到微服務架構，所經歷的網站架構也一直在變化，因而想寫一篇關於網站架構變遷的文章。

單服務器

最先的咱們的網站只有一臺服務器，網站應用 + 數據庫 + 網站文件 都在同一臺服務器上，有的時候一臺服務器上也會有多個網站。

這個階段的服務器上除了 Web Server，還會裝一個數據庫服務器，網站文件通常是放在網站目錄下保存的

數據庫服務器 + 網站服務器

數據庫和應用分離，數據庫使用獨立的數據庫服務器，網站服務器上只有網站，不在安裝數據庫服務器。

通常的網站服務器的瓶頸在於內存和CPU，而數據庫服務器瓶頸大可能是在IO方面，因此分離以後對於網站服務器咱們在擴容的時候能夠更加關注於加大服務器內存，加多核處理器，而數據庫服務器在能夠更加關注於提升服務器 IO。

數據庫服務器 + 網站服務器 + 文件服務器

這個階段在上一階段的基礎上進一步把文件分離出來了，這樣網站遷移起來就不須要再遷移網站上傳的文件了，並且文件服務器升級的時候每每是提升存儲的容量

網站集羣 + 負載均衡

網站發展到必定的規模，咱們就可能會遇到一些系統瓶頸，除了升級服務器的配置外，咱們也能夠作網站集羣，由於單一服務器配置升級到必定程度以後再想升級成本就會很高，相比之下作網站集羣性價比會更高一些，可擴展性更好，並且作集羣的話能夠防止單點故障致使網站不可用，

既然是集羣，多臺服務器同時工做就會遇到一個請求交由哪一個服務來處理的問題，通常的咱們會在網站集羣前加一個負載均衡器，由負載均衡器根據必定的負載均衡算法選擇要處理的網站服務器

網站集羣 + 負載均衡 + 分佈式緩存

上面咱們引入了網站集羣+負載均衡，對於服務器 Session 能夠指定使用 IP_Hash 或相似的負載均衡策略，可是若是不支持 IP_Hash 類的負載均衡算法，就須要支持分佈式 Session 的支持，通常的分佈式的 Session 咱們能夠藉助分佈式緩存來實現，並且可能會有一些內存緩存，若是使用網站服務集羣的話，就要考慮使用分佈式緩存了，不然會致使數據的不一致，一臺服務器的緩存數據更新了，其餘的緩存數據仍是舊數據，就會形成不少問題，因此分佈式緩存就頗有必要引入了

網站集羣 + 負載均衡 + 分佈式緩存 + 數據庫讀寫分離

數據達到必定的規模以後，數據庫容易成爲系統的瓶頸，除了引入緩存來解決以外，咱們可讓數據庫作讀寫分離，讀操做走從庫，寫操做走主庫

服務化架構

上面的模式，對於網站應用來講，都是一個單體應用，從服務化架構開始，開始真正的從單體架構遷移到分佈式架構

單體應用發展到必定程度，應用的複雜度愈來愈高，代碼耦合度也會逐漸增長，從項目的角度來講，項目愈來愈大，項目維護也會變得愈來愈難，衝突也會愈來愈多，項目加載編譯運行須要的時間也愈來愈長，從部署的角度來講，不一樣的 API 之間會相互影響，我只改了某一個 API 可是部署的話只能所有更新。

因而服務化就應運而生，服務化將原來的單體架構拆分紅了分佈式架構，每個服務只負責本身相關的業務邏輯，每個服務都是一個小單體

微服務架構

微服務架構 1.0

在服務化的基礎上進一步演化出來了微服務架構，微服務是服務化的進一步發展，微服務是去 "ESB" 的更細緻的服務化

「微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間相互協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務和服務之間採用輕量級的通訊機制相互溝通（一般是基於HTTP的Restful API).每一個服務都圍繞着具體的業務進行構建，而且可以被獨立的部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構"---- Martin Fowler的博客

當項目進行服務化改造的時候，這個過程並非一蹴而就，一拍腦殼就成功了。要把項目服務化，須要解決不少的問題，例如：

服務之間怎麼調用？訂單服務想要調用到商品服務的數據，怎麼調用？怎麼調用更加的穩定，更加高效？【服務調用技術】

服務之間怎麼負載均衡？訂單服務要調用商品服務，商品服務可能有不少個，怎麼負載均衡【負載均衡技術】

服務怎麼被管理？服務怎麼定位？有故障了怎麼處理？【服務註冊與發現技術】

故障怎麼監控？微服務系統中業務模塊不少，組件也不少，不一樣組件的指標不一樣，那麼這些組件怎麼進行監控【監控技術】

故障怎麼定位？微服務架構中，一個用戶的請求會涉及到多個內部服務的調用，那麼如何定位問題呢？【鏈路追蹤技術】

日誌怎麼分析處理？業務模塊多了，日誌也就多了，直接查看日誌文件已經變的不顯示了，那麼如何對日誌進行分析查找呢？【日誌分析技術】

權限管理？微服務拆分服務以後，會有不少服務對外暴露接口，這些接口如何進行統一的權限處理呢？【網關技術】

服務調用出現問題怎麼處理？當一個服務由於各類緣由中止響應時，調用方一般會等待一段時間，而後超時或者收到錯誤返回。若是調用鏈路比較長，可能會致使請求堆積，整條鏈路佔用大量資源一直在等待下游響應。怎麼解決呢？【服務熔斷，降級，限流】

微服務架構 2.0

基於 Kubernetes + ServiceMesh 的雲原生微服務架構

微服務 2.0 更多的注重服務的治理，2.0 階段，微服務架構引入了 ServiceMesh（服務網格）的概念經過 SideCar(側邊車)的方式實現一些對應用無侵入的管理，
使得服務治理更加通用，藉助 Service Mesh 能夠更方便的管理服務間調用，更好的作流量控制等

追本溯源，服務網格從無到有可分爲三個演化階段（參見下圖）。
第一個階段，每一個服務各顯神通，自行處理對外通信。
第二個階段，全部服務使用統一的類庫進行通信。
第三個階段，服務再也不關心通信細節，通通交給邊車進程，就像在TCP/IP協議中，應用層只需把要傳輸的內容告訴TCP層，由TCP層負責將全部內容原封不動的送達目的端，整個過程當中應用層並不須要關心實際傳輸過程當中的任何細節。

Kubernetes 讓微服務更簡單，使用 Kubernetes 就無需關注服務的註冊發現了，服務部署自動服務註冊發現，無需在應用代碼裏向服務中心註冊，kubernetes 讓微服務的縮放更爲簡單，你也能夠配置根據應用的 CPU 等指數來實現應用的動態擴容，壓力大的時候自動擴容，增長節點，壓力小的時候自動縮放，減小服務節點。

More

一切脫離業務的架構設計，都是耍流氓。

架構不是一蹴而就的，架構是演化出來的。

筆者經驗有限，文中若是有錯誤，還望指出，萬分感謝

Reference

• https://www.zhihu.com/question/37808426
• https://www.zhihu.com/question/65502802
• https://juejin.im/entry/5bd6846ee51d452f7110cfeb
• https://zhuanlan.zhihu.com/p/35179248
• https://www.infoq.cn/article/microservices-post-kubernetes