各階段架構解析（含高併發和微服務）:架構生命週期

阿新 • • 發佈：2019-12-31

簡介

web1.0時代（1996年左右）
web2.0時代（2006年左右）
網際網路時代--->網際網路+時代--->智慧城市：嘀嘀打車、餓了麼（2012年左右）
大資料+雲端計算
AI未來以來時代
......

背景演變

第一時期

1. 單一應用架構簡介

網際網路發展的最早時期，所有的程式碼、業務都寫在JSP中，也是網站初期的最早架構。
All in one：所有的模組和程式碼都放在一起，不分層（2000年左右）。
資料庫和程式碼在一個伺服器中

產生問題（維護）

程式碼放在一起不具備可維護性（程式碼都在JSP頁面中）
容錯性差，出現異常使用者可直接看到異常資訊，該錯誤可能會導致服務宕機

2. 分層階段簡介

分層開發以提高可維護性（controller、service、dao）
MVC架構（是一個基於Java Web應用的設計模式）
資料庫和應用的伺服器分離部署

產生問題（高併發）

隨著使用者訪問量的持續增加，單臺應用伺服器已無法滿足需求。

3. 叢集階段簡介

叢集：同一個業務部署在多個伺服器上。
支援高併發、高可用。

產生問題（轉發、Session）

那麼多的伺服器使用者到底訪問那個？
session儲存在哪裡？

4. Nginx、Redis階段

使用Nginx反向代理統一使用者請求地址，Niginx利用負載均衡完成使用者請求的轉發。
使用Redis Cluster

（Redis叢集）實現session共享。

產生問題（資料庫）

Nginx+Tomcat叢集帶來的高併發導致資料庫的壓力過大

5. 資料庫優化階段

主從複製

採用資料庫的主從複製，讀寫分離技術
主從資料庫之間進行資料同步：master負責增刪改操作；slave負責讀/查詢操作
mysql本身就支援master-slave功能（主從複製）

Solr/ElasticSearch

資料庫本身對大資料量查詢效率慢，對模糊查詢的支援不是很優秀。
像電商類網站，搜尋是非常核心的功能，即使做了讀寫分離，但是還有很多功能不能有效解決（分詞技術）
針對該問題，引入全文檢索伺服器功能

Redis快取

在大併發情況下對於熱點資料，請求的資料庫的次數是海量的，然而資料庫無法應對如此大的查詢請求，會導致資料庫無法對外提供服務（連線異常）
利用Redis進行快取，將熱點資料儲存在Redis中，無需每次都請求資料庫。
並且Redis的讀寫效能極好，擁有豐富的資料型別並且支援原子性

資料庫表的拆分

一張表裡面有1000條資料，查詢效能很高。
如表中有100萬資料，查詢的效能很低。
單個表效能做提升，但是提升的空間終歸還是有限的。

垂直拆分

假設一張使用者表裡面有30個欄位：id,姓名，年齡，身份證號，身高，體重，性別，手機號，家庭住址.....
熱門欄位：id，姓名，身份證號，年齡，性別，手機號
冷門欄位：其他剩餘
我們可以將熱門欄位放在user表中，冷門欄位放在userinfo表中，完成表的拆分

水平拆分

按需求拆分（省份/時間）
我們可以將一張使用者表中的資料，按照不同的省份拆成不同的表

採用第三方分庫分表的中介軟體

mycat、sharding-jdbc、drds(阿里)
通過設計可以保證高併發、高可用（通過不斷的增加伺服器）

https://blog.csdn.net/jornada_/article/details/82947677

產生的問題

伺服器很貴，存在忙閒不均的問題（就雙11那幾天訪問量大），伺服器的維護需要大量的人工成本（運維工程師）
可維護性差：一個業務的改動，每臺伺服器上都要重新部署
可拓展性差：（指的是伺服器）再增加一臺伺服器，需要重新配置環境
協同開發不方便：大家都去修改相同業務程式碼，已發生程式碼衝突/錯誤問題
單體架構：隨著業務需求的不斷增加，應用程式碼也會變的越來越多，導致部署到伺服器上時，所佔用的硬碟空間過大

第二時期

垂直應用架構概述

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。

水平拆分（橫著拆）

情景要求

現在網站分為前臺（給使用者使用），後臺（給管理員使用），是否需要拆成2個專案獨立部署？如果需要拆的話，有一些前後臺都需要公用的程式碼，這些程式碼怎麼辦？

拆分方法

按照不同的層次進行拆分
將一個大應用查分成多個小應用

parent pom    #父工程（放所有的pom.xml)
common.jar    #公共庫 相關工具類
pojo.jar      #java bean
mapper.jar    #資料持久層
service.jar   #業務邏輯層
web.war       #web訪問層
manager.war   #後臺管理
複製程式碼

優點

獨立jar包，模組複用
減少了部署時伺服器的磁碟佔用：使用者訪問的web.war包可以多部署幾個伺服器，後臺管理的manager.war包就部署1臺伺服器

垂直拆分（豎著拆）

拆分方法

按照不同的功能進行拆分
將一個大的應用按功能拆分成多個互不相干的小應用，並且每個應用都是獨立的Web應用程式（向分散式發展）

優點

可維護性：如果需求發生變更，只需要調整某個應用模組即可
功能拓展性：增加了不同的業務需求，就增加對應的Web模組
協同開發方便：不同的小組負責不同的模組
部署效能調優：哪個模組訪問量大，就多部署幾臺負責該模組的伺服器

產生的問題

客戶對頁面的要求越來越高，需要頻繁修改頁面，但是此時前後端未分離（每一個應用從頭到尾都是完整的），每次都需要重新部署後臺應用程式。
隨著業務需求的不斷增加，多個不同的模組之間可能會產生業務互動，（不同的模組都部署在不同的伺服器上）如何解決？

第三時期

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分散式服務框架(RPC)是關鍵。
RPC：（Remote Procedure Call)是一個計算機通訊協議，該協議允許執行於一臺計算機的程式呼叫另一臺計算機的子程式，而程式設計師無需額外地為這個互動作用程式設計。RPC是一個分散式計算的CS模式，總是由Client向Server發出一個執行若干過程請求，Server接受請求，使用客戶端提供的引數，計算完成之後將結果返回給客戶端。RPC的協議有很多，比如最早的CORBA，Java RMI，Web Service的RPC風格，Hessian，Thrift，甚至Rest API

分散式架構概述

將一個業務拆分成多個子業務，部署在不同的伺服器上
採用前後端分離進行開發/部署（頁面+業務程式碼）

使用RPC、Http、HttpClient等底層技術技術解決不同模組之間的呼叫

產生的問題

分散式事務：二階段提交
分散式鎖：Redis中的Setnx key value
分散式Session：Redis叢集
分散式日誌：ELK（Elasticsearch、Logstash 和 Kibana）

當服務越來越多，服務和服務之間的呼叫非常的混亂（我都不知道你有哪些服務）（RPC）
資源的浪費問題（支付管理訪問量小，卻部署了100臺伺服器；物流管理訪問量大，但只部署了50臺伺服器）

第四時期

流動計算架構概述

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。此時，用於提高機器利用率的資源排程和治理中心(SOA)是關鍵。
SOA：Service Oriented Architecture，“面向服務的架構”:他是一種設計方法，其中包含多個服務，服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在於作業系統程式中。各個服務之間通過網路呼叫。

解決方案

分散式服務治理中介軟體：（Dubbo/SpringCloud)
舉例：

以一個公司為例：有基層員工， 有管理層， 有老闆。
最初大家都聽老闆指揮，誰幹什麼誰幹什麼，根據需要，你可能今天干A事情，明天干B事情，後來人越來越多了，事情也越來越多了，做事情的效率越來越多，管理也很混亂，
就開始做部門劃分（服務化），專門部門做專門事情的，IT部門只做研發，人事部門只做招聘； 這個時候就無法避免的發生跨部門協作（伺服器呼叫）， 但是你怎麼知道有這樣一個部門可以做這個事情呢，就要依賴行政部門（註冊中心），新成立的部門要在行政哪裡做一個備案（服務註冊），然後公佈一下，讓其他部門知道了（服務釋出），大家就可以在新的工作秩序裡面嗨皮的上班了，這個時候依然是在公司的組織架構中運轉
複製程式碼