應用的架構演變（2）
- 2020 年 3 月 17 日
- 筆記
應用的架構演變圖
上圖描述了從單一應用架構-->垂直應用架構-->分散式服務架構-->流動計算架構，應用的發展演變過程
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用於簡化增刪改查工作量的數據訪問框架（ORM）是關鍵
單一應用架構圖
適用於小型網站，小型管理系統，將所有功能都部署到一個功能里，簡單易用。
缺點：
- 性能擴展都比較差
- 協同開發問題
- 不利於升級維護
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率，此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
垂直應用架構圖
當一個應用拆分為幾個小應用，部署到不同的伺服器上，並且每個小應用都是完整的，從頁面到業務邏輯到程式和DB，當某一個應該訪問量比較大的時候，可以對這個應該多增加幾個伺服器
通過切分業務來實現各個模組獨立部署，降低了維護和部署的難度，團隊各司其職更易管理性能擴展也更方便，更有針對性
缺點：
- 每個應用的完整性，比如頁面的修改都要重新部署，沒有做到介面+業務邏輯的實現分離
2.每個應用無法做到完全的獨立，比如訂單可能要用到用戶的資訊，每個應用之間有交互的需要
分散式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務復用及整合分散式服務框架（RPC）是關鍵
分散式服務架構圖
分散式服務架構拆分不同的功能業務，並且不同的功能頁面又將介面與業務邏輯分離，業務邏輯和介面是部署到不同伺服器，不同的伺服器之間的服務調用通過RPC(遠程過程調用)調用(同一台伺服器是簡稱件通訊)
分散式服務架構帶來的問題，是如何進行遠程過程調用，以及如何拆分業務提升業務的復用程度，通過RPC(分散式服務框架)可以解決遠程過程調用，但其他問題是，隨著業務拆分越來越多，可能會有成千上萬的伺服器在運行不同的服務，會出現資源浪費的情況，是否可以提高資源的利用率，通過訪問量來動態分配伺服器
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。此時，用於提高機器利用率的資源調用和治理中心(SOA)是關鍵
流動計算架構圖
流動計算架構引入調度中心，維護註冊中心的所有服務調用關係，實時管理服務集群，根據不同的服務的訪問請求量調整伺服器數量，並且根據相同服務不同伺服器請求的數量調整下次訪問哪台伺服器處理請求，以此提高集群利用率
