架構設計(一) 架構演變
什麼是架構
架構的第一性原理：降本增效
1. 對業務場景抽象後得出的支撐骨架
2. 架構因業務場景而生被業務場景所拋棄
3.架構沒有最好只有最合適
- 研發的技術能力 - 業務的複雜度 - 資料規模大小 - 時間成本 - 運維能力
4.最合適的架構都是業務場景Balance的結果
場景驅動架構增長，架構是天時地利人和的融合結果
網際網路軟體架構演變
單體架構
客戶端
APP, H5，小程式
服務端
1. App端請求發給單體服務
2.單體服務接受請求
3.單體服務從資料庫讀取資料
4.單體服務對資料庫返回的資料進行邏輯處理
5.單體服務對返回的結果進行封裝，返回結果給App端
例子：查詢個人主頁 - 獲取個人詳細資訊
單體架構的優點
1.開發簡單 2.測試簡單 3.釋出簡單 4.擴容簡單 - 單體應用可以結合Nginx部署多個節點實現擴容
單體架構的使用場景
1. 業務場景簡單，功能不復雜，研發人員較少
- O2O
2.創業公司初期
3.效能要求及其苛刻
- 量化交易
- 高頻交易
- 股票 債券 外匯交易
單體架構的弊端
耦合-所有服務都放在一起（如下圖：使用者服務，商品服務，交易服務全都放在一起）
如何解決？
- 資料庫儲存量大/請求量大拆分
1.垂直拆分（分庫）
2.水平拆分（分表）- 單表資料量比較大 ～ 取模演算法
- 拆分架構
1.垂直方向拆分(業務維度)
2.水平拆分（功能維度）
面向服務架構
SOA - 按照業務將單體應用垂直拆分
1個程序變3個程序
SOA架構
- 多個獨立的服務 - 通過ESB互動
SOA缺點
- 業務方向垂直拆分 1.每個服務還是單體服務
水平分層架構
水平方向拆分
按請求的功能進行拆分
分層設計原則
前後端分離的架構
1.資料服務與業務邏輯服務分離 2.業務邏輯服務與閘道器服務分離 3.閘道器服務與展示服務分離
閘道器層功能（業務無關）
功能1： 請求鑑權 - 釋出商品，登陸鑑權 功能2：資料完整性檢查 - 資料包定長Header和變長Body 1.定長Header: 資料的屬性欄位有沒有缺失 功能3： 協議轉換- JSON to HashMap(String, Object) 1.FastJson 2.Jackson 3.Mapstruct 功能4：路由轉發 - 根據CMD轉發到不同的業務邏輯層 功能5：服務治理 - 限流，降級，熔斷等
業務邏輯層功能
功能1：業務邏輯判斷 - 案例：微信黑名單檢查 - 案例：微信好友刪除
資料訪問層功能
功能1：CRUD
- 業務增刪改查介面（批量）
功能2：ORM
- JPA
功能3：Sharding(分表分庫)
- Shardingsphere分庫分表（NewSQL時代分庫分表已經過時了）
功能4： 遮蔽底層儲存差異性
- PostgreSQL/MongoDB
- Redis
同步架構 OR 非同步架構
非同步目地： 提升吞吐量 非同步手段： 訊息佇列（Kafka, RocketMQ） 場景1：請求型別 - 寫請求 （不關注語義結果,讀請求應為要返回結果，所以不適合非同步） 場景2：業務型別 - 充值，轉帳不適合非同步場景
層次劃分
同步架構（四層） -閘道器層 -業務邏輯層 -資料訪問層 -資料儲存層 非同步架構（五層） -閘道器層 -非同步訊息佇列層 -業務邏輯層 -資料訪問層 -資料儲存層
水平拆分架構的缺點
每層粒度過粗
微服務架構
微服務架構 = SOA架構 + 水平拆分的架構
簡而言之，微服務體系結構風格是一種將單個應用程式開發為一組小型服務的方法，每個服務在自己的流程中執行，
並與輕量級機制(通常是HTTP資源API)通訊。這些服務是圍繞業務功能構建的，並且可以通過完全自動化的部署機制獨立部署。
這些服務可以用不同的程式語言編寫，使用不同的資料儲存技術，對這些服務進行去中心化的集中管理。
下面link是微服務的完整定義：https://martinfowler.com/articles/microservices.html
業務的垂直拆分 + 功能水平拆分
經典的微服服架構 閘道器層 1個 業務邏輯層 多個 資料訪問層 多個 DB/Cache 多個
微服務架構本質
1.兩個維度的拆分（垂直拆分，水平拆分）
2.業務架構 3.組織架構 -信用卡事業部 -基金事業部 -貸款事業部
微服務架構適用場景
1.需求層面
- 需求不斷變更（如果需求半年或一年變化一次則不適合微服務架構） 2.效能層面
- 提升吞吐量
- RT要求苛刻的場景不適用微服務架構 3.資料一致性層面
- 最終一致性
微服務架構適用目的
1.專案的快速迭代 2.專案的持續交付
完整的微服務架構
1.DNS解析 2.靜態資源 3.動態介面資料
微服務架構弊端
1.業務服務需要關注非業務的功能
- 業務迭代速度變慢
2.基礎設施元件升級困難（一般以Jar包的形式引入）
- 影響基礎設施團隊的交付能力和交付速度
3.多編成語言之間的通訊問題
- 業務每種語言一套基礎設施，成本大
微服務架構演進
1.業務團隊專注於業務邏輯本身 2.服務通訊交給基礎團隊 3.物理解耦業務研發團隊和基礎設施團隊 4.一套基礎設施支援多語言開發 5.基礎設施能力從應用程式下推 6.真正做到快速迭代快速交付
服務網格架構
ServiceMesh的定義
服務網格是一個基礎設施層，用於處理服務間通訊。元原生應用有著複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞。
在實踐中，服務網格通常實現為一組輕量級網路代理，它們與應用程式部署在一起，而對應用程式透明。
ServiceMesh架構
實現業務服務與基礎服務解耦，業務團隊僅僅關注業務開發即可，基礎服務交給基礎服務團隊完成
ServiceMesh優點
1.ServiceMesh獨立程序，獨立升級 2.業務團隊專注於業務邏輯本身 3.一套基礎設施支援多語言開發 4.業務團隊和基礎設施團隊物理解耦
Istio總體架構
1.Istio服務網格邏輯上分為資料面板（執行者）和控制面板（指揮者）
2.資料面板由一組智慧代理（Envoy）組成，代理部署為Sidecar,調解和控制微服務之間所有的網路通訊
3.控制面板負責管理和配置代理來路由流量，以及在執行執行策略
完整的服務網格架構
案例： 微服務的演進
微服務1.0
開發初期人力受限
1.閘道器層 1個 2.業務邏輯層 1個 3.資料訪問層 多個 4.DB/ Cache 多個
微服務1.0存在問題
業務邏輯層 1.粒度粗 -所有業務邏輯耦合在一個物理程序內部 2.迭代效率低下
解決方式：
業務邏輯垂直拆分
微服務2.0
微服務2.0存在問題
公共邏輯層 1.組建化 -引用jar，導致迭代效率下降 （應該將其服務化 -下沉為獨立服務，提供相容介面）
解決方式：
水平方向拆分
微服務3.0
1. 3.0 架構中，所有的到用都是從上到下的呼叫，不允許同層呼叫，避免交叉調用出現
2. DB 只對資料訪問層可見，對業務邏輯層不可見