什么是架構
架構的第一性原理：降本增效
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 只對數據訪問層可見，對業務邏輯層不可見