淺談架構-從傳統走向分布式

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