網站架構變遷 Intro 從最早的 html 的學習到現在從單體應用遷移到微服務架構，所經歷的網站架構也一直在變化，於是想寫一篇關於網站架構變遷的文章。 單伺服器 最早的我們的網站只有一臺伺服器，網站應用 + 資料庫 + 網站文件 都在同一臺伺服器上，有的時候一臺伺服器上也會有多個網站。 這個階段的 ...
網站架構變遷
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
