帶你認識互聯網架構的演變過程

單體架構（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，負責服務間的網絡調用、熔斷、限流和監控。
• 使用服務網格我們也就不需要關心服務間的那些原來是由應用程序或者其他框架實現的事情
  特點：
• 應用程序間通訊的中間層。
• 輕量級網絡代理。
• 應用程序無感知。
• 解耦應用程序的重試/超時、監控、追蹤和服務發現。