# 單體架構（all in one） - 所有模組都在一起，技術也不分層。 - 在單機上部署所有的應用程式和軟體。 - 所有的程式碼都寫在JSP裡面，所有程式碼都寫在一起，這種方式稱為all in one。 **特點：** 1.不具備程式碼的可維護性。 2.容錯性差。（容錯性是指軟體檢測應用程式所執行的軟體和硬體中發生的錯誤並從錯誤中恢復的能力，可以從系統的可靠性，可用性，可測性等幾個方面衡量） 因為所有程式碼都寫在JSP頁面裡，當因為使用者或某些原因發生異常時：使用者可以直接看到異常錯誤資訊；異常會導致伺服器宕機。 - **單體地獄：** 只需一個應用，將所有功能部署在一起，以減少部署節點和成本。 ## 解決方案 1.分層開發：解決單體架構容錯性差的問題，同時提高了程式碼的維護性。 2.MVC架構（Web應用程式的設計模式） 3.伺服器的部署分離。 **特點：** 1.MVC分層開發：解決容錯性問題。 2.資料庫和專案部署分離。 **問題：** 1.高併發：隨著使用者訪問量的持續增加，單臺伺服器無法滿足使用者訪問需求。 **解決方案：** 1.叢集 ## 叢集操作可能遇到的問題 #### 高可用 - 高可用HA（High Availability）是分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。假設系統一直能夠提供服務，我們說系統的可用性是100%。 - 如何保證高可用：避免單點。 #### 高併發 - 高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。 - 高併發相關常用的一些指標 - 響應時間（Response Time）：系統對請求做出響應的時間。 - 吞吐量（Throughput）：單位時間內處理的請求數量。 - QPS（Query Per Second）：每秒響應請求數。 - 併發使用者數：同時承載正常使用系統功能的使用者數量。 **提高系統的併發能力** 1.垂直擴充套件：提升單機處理能力。 - 增強單機硬體效能 - 提升單機架構效能 2.水平擴充套件 - 只要增加伺服器數量，就能線性擴充系統性能。 #### 高效能 ## 叢集操作 - 叢集：同一個業務，部署在多個伺服器上。 **特點：** - 專案採用多臺伺服器（叢集）部署。 **優點：** 1.支援高併發 2.支援高可用 **問題1：** session資料如何共享？ - RedisCluster叢集方案-讀取session，獲取session **問題2：** 這些叢集的伺服器，使用者的請求怎麼轉發？ -用nginx伺服器來完成分發請求，實現負載均衡策略機制。 ### 叢集操作中的高併發導致資料庫壓力增加 - 叢集方案nginx+tomcat將應用層的效能進行有效的提升，但是資料庫的負載壓力慢慢增加，如何提高資料庫的負載的解決方案： ##### 讀寫分離 - 讀寫分離：主從資料庫之間進行資料同步。master（寫）負責資料庫的增刪改操作，slave（讀）負責資料庫的查詢操作。 - MySQL提供了master-slave的方式完成主從複製功能。 ##### 使用搜索引擎緩解資料庫訪問壓力，提高資料庫能力 - 資料庫在進行讀取資料庫的查詢操作時，資料庫本身對模糊查詢的功能支援不是特別好。例如電商類網站，搜尋功能是非常核心的功能模組，即使做了讀寫分離，也不能解決電商網站查詢（分詞技術）等，針對這樣的問題，引入搜尋引擎技術作為解決方案。 - 目前主流的搜尋引擎技術： 1.solr 2.elasticsearch 3.whoosh（阿里） ##### 引入快取機制減輕資料庫的訪問壓力 - 隨著訪問量的持續增加，即便做了主從複製，資料庫的訪問壓力還是越來越大。對於熱點資料的查詢，使用者需要頻繁地訪問，如果每次都要到資料庫中查詢，包括很多的通用查詢功能，資料庫中的資料不宜都放在記憶體中。例如手機登入的驗證碼操作，為了IP限制頻繁訪問伺服器等。 - 使用**Redis**實現快取機制。 ##### 資料庫的水平/垂直拆分 - 伺服器的垂直擴充套件能力有限。 - **表：垂直拆分** 1.資料庫表字段的分離成新表。 2.熱資料/冷資料的分離成新表。 - **表：水平拆分** 1.資料庫表資料的分離成新表。 2.按照時間，地區，**業務邏輯**進行水平資料拆分成新表。 - **分庫分表** 1.採用第三方資料庫中介軟體 - mycat - sharding-jdbc - drds（阿里） ### 叢集狀態特點 - 通過叢集設計，不斷對伺服器擴容可以保證高可用、高併發。 - **問題：** 1.伺服器成本高，包括伺服器維護成本，人工維護成本。 2.應用可維護性差。 3.應用可擴充套件性差，元件重用性低。 4.協同開發困難，會修改相同的業務程式碼，容易造成程式碼衝突錯誤。 5.單體架構，隨著業務的不斷增加，程式碼變得越來越多，導致服務部署時，檔案變得越來越大。 # 水平分層架構 - 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆分成互不相干的幾個應用，以提升效率。此時用於加速前端頁面開發的Web框架-MVC是關鍵。
- **水平拆分：** - **按照業務對系統進行劃分:** 比如原來的系統中包括了交易,運營兩大類,按照水平拆分的原則進行拆分.系統可以拆分成:交易系統,運營系統 - **優點:** 不同業務,往往效能要求,以及請求量是不一樣的.拆分後保證業務之間的可用性影響最小化 - **缺點:** 拆分過程中,多個系統中可能存在重複的輪子,難於維護 - 拆分完成後對拆分的專案進行**聚合**，提出概念**父工程**。 **IDEA示例** - 在pom.xml中：dependencies-直接使用，dependencyManagement-宣告作用（子類不需要再依賴版本號，統一管理開發版本）。 - 利用maven做模組的拆分和聚合 - **解決問題：** 1.模組複用 2.解決伺服器部署的內容變少 3.閒置出大量的伺服器，可以用於當用戶對某個層訪問量過大時，只需要將該層業務部署在較多的伺服器上即可；利用閒置伺服器作為其他服務，例如雲伺服器，阿里雲，百度雲等等；
- **垂直拆分：** 拆分的各個小應用之間相互獨立,互不影響 - **將同樣的系統按照應用場景(呼叫方)進行拆分:** 比如一個交易系統的支付模組,上游有使用者支付和商家支付兩個呼叫流程.按照垂直拆分的規則就可以將支付模組拆分為使用者支付和商家支付 - **優點:** 按需配給(預估呼叫方的流量,配置對應的機器數),各個垂直呼叫之間相互不影響,通過配置可以進行上游呼叫降級 - **缺點:** 幾乎完全重複的輪子 - **特點：** 1.維護性強：如果想要做需求變更，只需要調整某個應用某塊即可。 2.功能擴充套件性好：隨著業務的不斷增加，只需要建立新的應用模組即可。 3.協同開發方便：不同的團隊修改不同的業務。 4.部署內容靈活，效能擴充套件好：只需要對訪問量大的模組多部署伺服器。 **問題：** 1.前端頁面變化變大：當用戶對頁面的要求變高時，需要頻繁修改頁面，由於每個應用的各個層次都是完整的，如果要對頁面進行修改，應用服務需要重新部署。 2.各個模組間的業務互動困難：隨著業務的不斷增加，應用模組越來越多，各個模組間的業務互動變得困難。 # 分散式服務架構 - **分散式**：將一個業務拆分成多個子業務，部署在不同的伺服器上。 - **分散式服務架構**：當分層應用越來越多，應用之間的互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能夠更快速的響應多變的市場需求。此時用於提高業務複用以及整合的分散式服務框架**RPC**是關鍵。 - **解決方案**： 1.前端頁面變化變大：當用戶對頁面的要求變高時，需要頻繁修改頁面，由於每個應用的各個層次都是完整的，如果要對頁面進行修改，應用服務需要重新部署。 **分散式解決方案**：介面和業務邏輯實現分離，也就是前後端分離開發，水平拆分。 2.各個模組間的業務互動困難：隨著業務的不斷增加，應用模組越來越多，各個模組間的業務互動變得困難。 **問題分析**：在一臺伺服器上時，各個模組之間可以通過依賴完成呼叫（程序）；不同的應用部署在不同的伺服器上時，要通過服務與服務之間完成呼叫。 **分散式解決方案**： - RPC：Remote Procedure Call-遠端過程呼叫，是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。 - HTTP - **分散式帶來的技術問題：** 1.分散式事務問題 2.分散式鎖問題 3.分散式session問題 4.分散式日誌管理問題 - **問題：** 1.當服務越來越多，服務和服務之間的呼叫會變得異常混亂 2.當服務越來越多，容量的評估，小服務資源浪費等問題逐漸顯現 # 面向服務架構（SOA） - 當服務越來越多，容量的評估，小服務資源浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集的利用率。此時，用於提高機器利用率的資源排程和治理中心**SOA**是關鍵。 - **服務管理中介軟體：** - Dubbo - SpringCloud - **基於訪問壓力實時管理叢集容量，提高叢集的利用率。** - **SOA架構特點:** - 底層基於**SOAP**或者ESB**訊息匯流排**實現 - 底層使用**http協議**+**重量級資料交換格式**進行通訊 # 微服務架構 - 微服務：單體應用拆分成互不相干的小應用，每個小應用稱為微服務 - 微服務體現更加**輕量級**的架構 - **RESTful API**:Http協議+json格式 - 更適合**敏捷開發,快速迭代產品** - 通過**RPC遠端呼叫**,服務與服務之間都是可以**相互實現通訊** - 微服務架構從SOA架構演變而來 - 服務化功能在SOA層已經實現 - 微服務在單獨服務層進行細分服務 - **問題：** 1.**微服務架構與SOA架構的區別?** ``` - 微服務架構基於SOA架構演變而來,繼承SOA架構的優點.微服務去除了SOA架構中的ESB訊息匯流排, 採用http+json(RESTful)輕量級資料通訊 - 微服務架構比SOA架構的粒度更加精細,目的是為了提高效率.每個服務與服務之間互不影響, 在微服務架構中,每個服務必須獨立部署,微服務架構更加輕巧,輕量級 - SOA架構中可能會共享資料庫.微服務架構強調單獨每個服務都是單獨資料庫,保證每個服務與服務之間互不影響 - 微服務專案粒度更加精細,比SOA架構更適合公司敏捷開發,快速迭代版本 ``` 2.構建單體應用時，需要進行相關配置，例如SSM專案：web.xml,相應的所有jar包，相應的配置檔案。因而在拆分構建微服務時，需要進行大量的服務專案的建立。 **解決方案:** SpringBoot。 ## SpringBoot - SpringBoot：一個簡化Spring開發的框架。用來監護Spring應用開發，約定大於配置，去繁就簡，快速應用開發。 - 目的：為了簡化程式碼的初始化和開發配置。 ## 微服務優點 - 服務化的拆分粒度變得更細，服務的複用性強。提高開發效率。 - 可根據需求自定義優化方案，選擇最新技術進行微服務模組的開發修改。 - 適合網際網路專案，開發效率高，迭代週期短。 ## 微服務缺點 - 微服務過多，服務的管理成本高。 - 不利於服務的部署。部署不方便，部署成本高。Docker（映象/容器），k8s - 技術難點增加，例如分散式事務，分散式鎖，分散式Session，分散式日誌管理 - 對團隊技術能力要求高，Dubbo，SpringCloud ## 雲服務 - **IaaS**： Infrastructure as a Service，即基礎設施即服務。消費者通過Internet 可以從完善的計算機基礎設施獲得服務。這類服務稱為基礎設施即服務。基於 Internet 的服務（如儲存和資料庫）是 IaaS的一部分。 - **PaaS**： Platform as a Service，即平臺即服務。雲端計算時代相應的伺服器平臺或者開發環境作為服務進行提供。 - **SaaS**：Software-as-a-Service，即軟體即服務，通過網路提供軟體服務。 # 服務網格架構（Service Mesh） - 服務網格作為服務間通訊的基礎設施層，可以比作是應用程式或者說微服務間的 TCP/IP，負責服務間的網路呼叫、熔斷、限流和監控。 - 使用服務網格我們也就不需要關心服務間的那些原來是由應用程式或者其他框架實現的事情 **特點：** - 應用程式間通訊的中間層。 - 輕量級網路代理。 - 應用程式無感知。 - 解耦應用程式的重試/超時、監控、追蹤和服務