本專(zhuān)題所寫(xiě)所感所得，來(lái)自轉(zhuǎn)轉(zhuǎn)首席架構(gòu)師和字節(jié)架構(gòu)團(tuán)隊(duì)，此致，敬禮。。
一、引言
鄧寧-克魯格效應(yīng)是指的是能力欠缺的人在自己欠考慮的決定的基礎(chǔ)上得出錯(cuò)誤結(jié)論，但是無(wú)法正確認(rèn)識(shí)到自身的不足，辨別錯(cuò)誤行為，是一種認(rèn)知偏差現(xiàn)象。這些能力欠缺者們沉浸在自我營(yíng)造的虛幻的優(yōu)勢(shì)之中，常常高估自己的能力水平，卻無(wú)法客觀(guān)評(píng)價(jià)他人的能力。
這種現(xiàn)象稱(chēng)為「鄧寧克魯格效應(yīng)」。
鄧寧將這種效應(yīng)歸納為：「如果你沒(méi)有能力，你就不會(huì)知道自己沒(méi)有能力?！?/p>
中國(guó)的絕大多數(shù)研發(fā)人員處于第一階段，不知道高層級(jí)的架構(gòu)知識(shí)自己不知道。本專(zhuān)題的目的是把架構(gòu)師從愚昧之巔推向絕望之谷，之后能到哪里，全是造化全是命，師傅領(lǐng)進(jìn)門(mén)，修行靠個(gè)人。。
本場(chǎng) Chat 主要內(nèi)容：
- 互聯(lián)網(wǎng)發(fā)展三階段
- 互聯(lián)網(wǎng)架構(gòu)演進(jìn)之路
- 單體架構(gòu)設(shè)計(jì)與實(shí)踐
- 水平分層架構(gòu)設(shè)計(jì)與實(shí)踐
- 面向服務(wù)架構(gòu)設(shè)計(jì)與實(shí)踐
- 微服務(wù)架構(gòu)設(shè)計(jì)與實(shí)踐
- 服務(wù)網(wǎng)格架構(gòu)設(shè)計(jì)與實(shí)踐
- 千億級(jí)真實(shí)案例實(shí)踐
二、互聯(lián)網(wǎng)發(fā)展三個(gè)階段
2.1 概念
- PC互聯(lián)網(wǎng)（靜態(tài)化）
讓數(shù)據(jù)可以在一定范圍內(nèi)在線(xiàn)化。 - 移動(dòng)互聯(lián)網(wǎng)（動(dòng)態(tài)化）
讓人越來(lái)越多的數(shù)據(jù)被記錄被聯(lián)通，讓數(shù)據(jù)智能成為可能。 - 物聯(lián)網(wǎng)（萬(wàn)物連接）
讓網(wǎng)絡(luò)協(xié)同從人到萬(wàn)物。
2.2 場(chǎng)景
以互動(dòng)形式作為三個(gè)階段的場(chǎng)景為例：
2.3 特點(diǎn)
- 業(yè)務(wù)功能越來(lái)越多、越來(lái)越復(fù)雜
- 萬(wàn)物互聯(lián)數(shù)據(jù)量越來(lái)越大
- 請(qǐng)求量越來(lái)越大、更高的用戶(hù)體驗(yàn)要求
- 業(yè)務(wù)快速迭代持續(xù)交付的能力
三、互聯(lián)網(wǎng)架構(gòu)演進(jìn)
互聯(lián)網(wǎng)架構(gòu)演進(jìn)經(jīng)歷了單體架構(gòu)、水平架構(gòu)、面向服務(wù)架構(gòu)、微服務(wù)架構(gòu)、服務(wù)網(wǎng)格架構(gòu)等演進(jìn)過(guò)程。大致的演進(jìn)方向如下圖所示：
本文按照演進(jìn)的模型順序來(lái)介紹架構(gòu)的演進(jìn)。
3.1 單體架構(gòu)
以某一商業(yè)系統(tǒng)為例，它接受客戶(hù)的訂單，驗(yàn)證庫(kù)存和貨款，然后發(fā)貨。系統(tǒng)大致可以分為三個(gè)核心模塊（賬戶(hù)模塊、庫(kù)存模塊、配送運(yùn)輸模塊）。將三個(gè)核心模塊封裝到一個(gè)war包內(nèi)部署。
3.1.1 優(yōu)點(diǎn)
- 開(kāi)發(fā)簡(jiǎn)單
- 測(cè)試簡(jiǎn)單
- 部署簡(jiǎn)單
- 擴(kuò)展簡(jiǎn)單
3.1.2 適用場(chǎng)景
- 業(yè)務(wù)場(chǎng)景簡(jiǎn)單、功能不復(fù)雜、研發(fā)人員少
- 創(chuàng)業(yè)公司初期
- 性能要求極其苛刻
3.1.3 缺點(diǎn)
- 系統(tǒng)耦合性高
- 技術(shù)選型單一
- 開(kāi)發(fā)效率越來(lái)越低下
3.1.4 問(wèn)題改進(jìn)
數(shù)據(jù)庫(kù)數(shù)據(jù)量大，查詢(xún)效率低腫么辦？
答：拆分。垂直拆分(分庫(kù))、水平拆分(分表)
業(yè)務(wù)邏輯逐漸復(fù)雜，系統(tǒng)臃腫腫么辦？
答：拆分。垂直方向拆分(業(yè)務(wù)緯度)、水平拆分(功能緯度)
3.2 水平分層架構(gòu)
水平分層架構(gòu)按功能緯度水平分層，每層之間邏輯解耦。可分為網(wǎng)關(guān)層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪(fǎng)問(wèn)層、數(shù)據(jù)存儲(chǔ)層。
3.2.1 網(wǎng)關(guān)層
網(wǎng)關(guān)層主要提供通用的功能，與業(yè)務(wù)邏輯相關(guān)性不強(qiáng)。大致分為以下幾個(gè)功能：
- 請(qǐng)求鑒權(quán)
登陸鑒權(quán)、黑白名單等 - 數(shù)據(jù)完整性檢查
數(shù)據(jù)包header、body完整性、正確性檢查，是否被竄改等 - 協(xié)議轉(zhuǎn)換
json->hashmap、pb->json等 - 路由轉(zhuǎn)發(fā)
根據(jù)cmd轉(zhuǎn)發(fā)到不同的業(yè)務(wù)邏輯層 - 服務(wù)治理
限流、降級(jí)、熔斷等
3.2.1.1 網(wǎng)關(guān)實(shí)現(xiàn)
IO模型詳解參考：Linux IO模式及 select、poll、epoll詳解
3.2.2 業(yè)務(wù)邏輯層
- 庫(kù)存模塊
庫(kù)存量加減、庫(kù)存是否充足判斷、是否需要補(bǔ)充庫(kù)存等。 - 配送模塊
配送管理、訂單管理、物流信息等。
3.2.3 數(shù)據(jù)訪(fǎng)問(wèn)層
3.2.3.1 CURD
程序員日常工作，業(yè)務(wù)的增刪改查
3.2.3.2 ORM
對(duì)象關(guān)系映射（Object Relational Mapping，簡(jiǎn)稱(chēng)ORM）模式是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫(kù)存在的互不匹配的現(xiàn)象的技術(shù)。簡(jiǎn)單的說(shuō)，ORM是通過(guò)使用描述對(duì)象和數(shù)據(jù)庫(kù)之間映射的元數(shù)據(jù)，將程序中的對(duì)象自動(dòng)持久化到關(guān)系數(shù)據(jù)庫(kù)中。
| 對(duì)比緯度 | mybatis | hibernate |
|---|---|---|
| 難易度 | 相對(duì)容易上手 | 重量級(jí)，掌握難度大些 |
| 工作量 | 手寫(xiě)SQL，需要維SQL和結(jié)果映射 | 封裝、簡(jiǎn)潔 |
| 可移植性 | SQL是依賴(lài)數(shù)據(jù)庫(kù)書(shū)寫(xiě)的，所以擴(kuò)展性差，可移植性比較差 | 可移植性強(qiáng)，Hibernate與數(shù)據(jù)庫(kù)具體的關(guān)聯(lián)都在XML配置中 |
| 緩存機(jī)制 | 緩存機(jī)制不佳，臟數(shù)據(jù)會(huì)給系統(tǒng)帶來(lái)很大的隱患 | Hibernate用戶(hù)無(wú)需關(guān)心SQL，二級(jí)緩存出現(xiàn)臟數(shù)據(jù)系統(tǒng)會(huì)報(bào)錯(cuò) |
| 使用場(chǎng)景 | 都適用 | 單一業(yè)務(wù)高并發(fā)下不建議使用 |
3.2.3.3 分庫(kù)分表
| 對(duì)比緯度 | Mycat | Sharding-JDBC | Sharding-Proxy | Sharding-Sidecar |
|---|---|---|---|---|
| 官方文檔 | Mycat 權(quán)威指南 | 官方文檔 | 官方文檔 | 官方文檔 |
| 開(kāi)發(fā)語(yǔ)言 | Java | Java | Java | Java |
| 開(kāi)源協(xié)議 | GPL-2.0/GPL-3.0 | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| 數(shù)據(jù)庫(kù) | MySQL、Oracle、SQL Server、PostgreSQL、DB2、MongoDB、SequoiaDB | MySQL、Oracle、SQLServer、PostgreSQL、任何遵循 SQL92 標(biāo)準(zhǔn)的數(shù)據(jù)庫(kù) | MySQL/PostgreSQL | MySQL/PostgreSQL |
| 連接數(shù) | 低 | 高 | 低 | 高 |
| 應(yīng)用語(yǔ)言 | 任意 | Java | 任意 | 任意 |
| 代碼入侵 | 無(wú) | 需要修改代碼 | 無(wú) | 無(wú) |
| 性能 | 損耗略高 | 損耗低 | 損耗略高 | 損耗低 |
| 無(wú)中心化 | 否 | 是 | 否 | 是 |
| 靜態(tài)入口 | 有 | 無(wú) | 有 | 無(wú) |
| 管理控制臺(tái) | Mycat-web | Sharding-UI | Sharding-UI | Sharding-UI |
| 分庫(kù)分表 | 單庫(kù)多表/多庫(kù)單表 | ?? | ?? | ?? |
| 多租戶(hù)方案 | ?? | -- | -- | -- |
| 讀寫(xiě)分離 | ?? | ?? | ?? | ?? |
| 分片策略定制化 | ?? | ?? | ?? | ?? |
| 分布式主鍵 | ?? | ?? | ?? | ?? |
| 標(biāo)準(zhǔn)化事務(wù)接口 | ?? | ?? | ?? | ?? |
| XA強(qiáng)一致事務(wù) | ?? | ?? | ?? | ?? |
| 柔性事務(wù) | -- | ?? | ?? | ?? |
| 配置動(dòng)態(tài)化 | 開(kāi)發(fā)中 | ?? | ?? | ?? |
| 編排治理 | 開(kāi)發(fā)中 | ?? | ?? | ?? |
| 數(shù)據(jù)脫敏 | -- | ?? | ?? | ?? |
| 可視化鏈路追蹤 | -- | ?? | ?? | ?? |
| 彈性伸縮 | 開(kāi)發(fā)中 | 開(kāi)發(fā)中 | 開(kāi)發(fā)中 | 開(kāi)發(fā)中 |
| 多節(jié)點(diǎn)操作 | 分頁(yè)、去重、排序、分組、聚合 | 分頁(yè)、去重、排序、分組、聚合 | 分頁(yè)、去重、排序、分組、聚合 | 分頁(yè)、去重、排序、分組、聚合 |
| 跨庫(kù)關(guān)聯(lián) | 跨庫(kù) 2 表 Join ER Join、基于 caltlet 的多表 Join | -- | -- | -- |
| IP 白名單 | ?? | -- | -- | -- |
| SQL 黑名單 | ?? | -- | -- | -- |
| 存儲(chǔ)過(guò)程 | ?? | -- | -- | -- |
放棄吧，小伙伴，分庫(kù)分表多麻煩呀，有條件的話(huà)，直接上ti-db吧
3.2.3.4 屏蔽底層存儲(chǔ)差異性
- mysql／mongodb
- redis/memcached
- leveldb/rocksdb/hbase
- ti-db
3.2.4 同步架構(gòu) or 異步架構(gòu)
3.2.4.1 同步架構(gòu)
同步架構(gòu)是以串行的方式實(shí)現(xiàn)業(yè)務(wù)服務(wù)的響應(yīng)。
全流程解析如下圖：
3.2.4.2 異步架構(gòu)
異步架構(gòu)是通過(guò)消息隊(duì)列mq異步提高吞吐量。
3.2.5 分層設(shè)計(jì)
水平分層設(shè)計(jì)過(guò)多或者過(guò)少有啥缺點(diǎn)？
答：
1.過(guò)多：請(qǐng)求路徑變長(zhǎng)、平均響應(yīng)延時(shí)變高、定位問(wèn)題復(fù)雜、運(yùn)維成本高。
2.過(guò)少：變成單體架構(gòu)了。
水平分層設(shè)計(jì)幾層合適？
答：
1.同步架構(gòu)(四層)：網(wǎng)關(guān)層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪(fǎng)問(wèn)層、數(shù)據(jù)存儲(chǔ)層。
2.異步架構(gòu)(五層)：網(wǎng)關(guān)層、異步消息隊(duì)列層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪(fǎng)問(wèn)層、數(shù)據(jù)存儲(chǔ)層。
3.3 面向服務(wù)架構(gòu)(SOA)
面向服務(wù)架構(gòu)是垂直分層。不同功能模塊通過(guò)定義好的接口關(guān)聯(lián)，接口采用中立的方式定義，獨(dú)立于硬件平臺(tái)、操作系統(tǒng)、編譯語(yǔ)言。其主要特點(diǎn)是：
- 多個(gè)獨(dú)立服務(wù)
-
通過(guò)esb交互
SOA
3.3.1 缺點(diǎn)
- 業(yè)務(wù)垂直，每個(gè)服務(wù)都是一個(gè)單體架構(gòu)
- 嚴(yán)重依賴(lài)于esb消息總線(xiàn)
3.4 微服務(wù)架構(gòu)
微服務(wù)架構(gòu)是微服務(wù)可以在“自己的程序”中運(yùn)行，并通過(guò)“輕量級(jí)設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運(yùn)行。通過(guò)這一點(diǎn)我們就可以將服務(wù)公開(kāi)與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個(gè)API）區(qū)分開(kāi)來(lái)。在服務(wù)公開(kāi)中，許多服務(wù)都可以被內(nèi)部獨(dú)立進(jìn)程所限制。如果其中任何一個(gè)服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程的架構(gòu)。
說(shuō)人話(huà)：就是把水平分層架構(gòu)的每一次再拆分出更細(xì)粒度的微服務(wù)。
3.4.1 舉個(gè)例子
服務(wù)被拆分成醬紫：
- 網(wǎng)關(guān)層
1個(gè) - 業(yè)務(wù)邏輯層
N個(gè) - 數(shù)據(jù)訪(fǎng)問(wèn)層
N個(gè) -
DB/Cache
N個(gè)
微服務(wù)架構(gòu)
3.4.2 缺點(diǎn)
各個(gè)大廠(chǎng)都在用，優(yōu)點(diǎn)太多，罄竹難書(shū)，不講了。咱們反而道而行之，只講缺點(diǎn)：
-
迭代速度變慢
業(yè)務(wù)需關(guān)注服務(wù)間通信，所以迭代速度變慢。
-
基礎(chǔ)組件升級(jí)困難
-
存在多語(yǔ)言通信問(wèn)題，業(yè)務(wù)每種語(yǔ)言有一套基礎(chǔ)設(shè)施，成本大
3.5 服務(wù)網(wǎng)格架構(gòu)(service mesh)
服務(wù)網(wǎng)格是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌?wù)網(wǎng)格保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧?。在?shí)際應(yīng)用當(dāng)中，服務(wù)網(wǎng)格通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。
3.5.1 優(yōu)點(diǎn)
- 獨(dú)立進(jìn)程、獨(dú)立升級(jí)
- 業(yè)務(wù)只關(guān)注業(yè)務(wù)邏輯本身
- 一套基礎(chǔ)設(shè)施支持多語(yǔ)言開(kāi)發(fā)
- 業(yè)務(wù)團(tuán)隊(duì)和基礎(chǔ)設(shè)施團(tuán)隊(duì)物理解耦
3.5.2 Istio
要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的實(shí)踐，今天說(shuō)說(shuō)Istio是干啥的。
- Istio服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)面、控制面。
- 數(shù)據(jù)面由一組智能代理(Envoy)組成，代理部署為sidecar，調(diào)解和控制微服務(wù)所有的網(wǎng)絡(luò)通信。
- 控制面負(fù)責(zé)管理和配置代理來(lái)路由，以及運(yùn)行時(shí)策略。
3.5.2.1 數(shù)據(jù)面Envoy
Envoy的核心職責(zé)是高效轉(zhuǎn)發(fā)，主要有以下功能：
（1）服務(wù)發(fā)現(xiàn)
（2）負(fù)載均衡
（3）安全傳輸
（4）多協(xié)議支持，例如HTTP/2，gRPC
（5）斷路器(Circuit breakers)
（6）健康檢查
（7）百分比分流路由
（8）故障注入(Fault injection)
（9）系統(tǒng)度量
3.5.2.1.1 請(qǐng)求路由
3.5.2.1.2 服務(wù)發(fā)現(xiàn)和負(fù)載均衡
三種負(fù)載平衡模式：輪循、隨機(jī)、帶權(quán)重。
3.5.2.1.3 斷路器
它是軟件架構(gòu)設(shè)計(jì)中，一個(gè)服務(wù)自我保護(hù)，或者說(shuō)降級(jí)的設(shè)計(jì)思路。
舉個(gè)例子：當(dāng)系統(tǒng)檢測(cè)出某個(gè)接口有大量超時(shí)時(shí)，斷路器策略可以終止對(duì)這個(gè)接口的調(diào)用（斷路器打開(kāi)），經(jīng)過(guò)一段時(shí)間后，再次嘗試調(diào)用，如果接口不再超時(shí)，則慢慢恢復(fù)調(diào)用（斷路器關(guān)閉）。
主要功能包括
- 超時(shí)
- 帶超時(shí)預(yù)算有限重試
- 并發(fā)連接數(shù)和上有服務(wù)請(qǐng)求數(shù)限制
- 健康檢查
3.5.2.1.4 故障注入
它是軟件架構(gòu)設(shè)計(jì)中，一種故意引入故障，以擴(kuò)大測(cè)試覆蓋范圍，保障系統(tǒng)健壯性的方法，主要用于測(cè)試。
故障注入的兩種類(lèi)型：
- 延遲：計(jì)時(shí)故障，模擬增加網(wǎng)絡(luò)延時(shí)或過(guò)載的上游服務(wù)。
- 中止：模擬上游服務(wù)的崩潰故障。中止通用以http錯(cuò)誤代碼或者tcp連接失敗形式表現(xiàn)。
3.5.2.2 控制面
3.5.2.2.1 Mixer
Mixer的一些核心能力是：
（1）跨平臺(tái)，作為其他組件的adapter，實(shí)現(xiàn)Istio跨平臺(tái)的能力；
（2）和Envoy通訊，實(shí)時(shí)各種策略
（3）和Envoy通訊，收集各種數(shù)據(jù)
Mixer的設(shè)計(jì)核心在于“插件化”，這種模型使得Istio能夠適配各種復(fù)雜的主機(jī)環(huán)境，以及后端基礎(chǔ)設(shè)施。
3.5.2.2.2 Pilot
Pilot作為非常重要的控制平面組件，其核心能力是：
（1）為Envoy提供服務(wù)發(fā)現(xiàn)能力；
（2）為Envoy提供各種智能路由管理能力，例如A/B測(cè)試，灰度發(fā)布；
（3）為Envoy提供各種彈性管理能力，例如超時(shí)，重試，斷路策略；
Pilot的設(shè)計(jì)核心在于“標(biāo)準(zhǔn)化”，它會(huì)將各種流控的控制命令轉(zhuǎn)化為Envoy能夠識(shí)別的配置，并在運(yùn)行時(shí)，將這些指令擴(kuò)散到所有的Envoy。Pilot將這些能力抽象成通用配置的好處是，所有符合這種標(biāo)準(zhǔn)的Envoy都能夠接入到Pilot來(lái)。
潛臺(tái)詞是，任何第三方可以實(shí)現(xiàn)自己的proxy，只要符合相關(guān)的API標(biāo)準(zhǔn)，都可以和Pilot集成。
3.5.2.2.3 Citadel
Citadel組件，它提供終端用戶(hù)身份認(rèn)證，以及服務(wù)到服務(wù)的訪(fǎng)問(wèn)控制?？傊?，這是一個(gè)和安全相關(guān)的組件。
3.6 實(shí)踐
以某知名互聯(lián)網(wǎng)公司架構(gòu)演進(jìn)為例。
3.6.1 服務(wù)架構(gòu)1.0
服務(wù)被拆分為：
- 網(wǎng)關(guān)層
1個(gè) - 業(yè)務(wù)邏輯層
1個(gè) - 數(shù)據(jù)訪(fǎng)問(wèn)層
N個(gè) -
DB/Cache
N個(gè)
服務(wù)架構(gòu)1.0
娘耶，業(yè)務(wù)邏輯層粒度太粗，所有業(yè)務(wù)邏輯耦合到一起，開(kāi)發(fā)效率也低。拆遷隊(duì)準(zhǔn)備就位，垂直方向拆拆拆。。
3.6.2 服務(wù)架構(gòu)2.0
服務(wù)被拆分為：
- 網(wǎng)關(guān)層
1個(gè) - 業(yè)務(wù)邏輯層
N個(gè) - 數(shù)據(jù)訪(fǎng)問(wèn)層
N個(gè) -
DB/Cache
N個(gè)
服務(wù)架構(gòu)1.0->服務(wù)架構(gòu)2.0
這下好了吧，但公共邏輯和業(yè)務(wù)邏輯混合在一起，沒(méi)有解耦。
公共邏輯層
- 組件化：引入jar/sdk包
- 服務(wù)化：下層為獨(dú)立服務(wù)
拆遷隊(duì)繼續(xù)搞事情，水平方向拆拆拆。。
3.6.3 服務(wù)架構(gòu)3.0
服務(wù)被拆分為：
- 網(wǎng)關(guān)層
1個(gè) - 業(yè)務(wù)邏輯層
N個(gè) - 公共邏輯層
N個(gè) - 數(shù)據(jù)訪(fǎng)問(wèn)層
N個(gè) -
DB/Cache
N個(gè)
服務(wù)架構(gòu)2.0->服務(wù)架構(gòu)3.0
3.6.4 服務(wù)架構(gòu)4.0
該服務(wù)架構(gòu)的未來(lái)是service mesh，沒(méi)搞沒(méi)搞。
四、寫(xiě)在最后
以上架構(gòu)演進(jìn)都是扯淡，適合自己的才是最好的架構(gòu)。
