1.1 登錄安全
1.1.1 密碼認證
當用戶登錄發送用戶名和密碼給 后，不做認證，直接轉發給 認證。這樣 實現簡單，也不存在泄漏密碼風險。流程如下：
讓用戶管理密碼增加了用戶負擔和密碼泄漏風險。隨著云服務的普及，用戶可以不管理密碼，只需要提供可信的身份認證信息就可以了， 在螞蟻內部做了類似功能，舉個例子：
App 和 部署在同一個 k8s 的 安全 POD 內， 信任App，App訪問數據庫，只需要傳輸用戶名，不傳輸密碼， 向KMS（密鑰管理服務)請求對應用戶名的密碼，和 登錄認證時傳輸用戶名和從 KMS 獲取到的密碼。這樣的好處有兩點：
此外，在使用 時，有兩個賬號大家需要特殊關注下：
這兩個密碼大家在一些文檔和部署配置中應該見過，經過這次講解大家應該就熟悉了。
1.1.2 IP白名單
IP白名單指允許訪問 集群的IP列表，默認為空，表示都允許訪問。 的白名單有以下特點：
為了安全起見建議大家定期維護白名單。使用 root@ 賬號登錄 ，白名單操作方式如下：
MySQL [(none)]> select * from white_list;
Query OK, 0 rows affected (0.00 sec)
# 增加租戶tenant1的白名單
MySQL [(none)]> replace into white_list(cluster_name, tenant_name, name, value) values('cluster1', 'tenant1', 'ip_list', '182.168.1.1');
Query OK, 0 rows affected (0.02 sec)
# 查詢所有白名單內容
MySQL [(none)]> select cluster_name, tenant_name, name, value from white_list;
+--------------+-------------+---------+-------------+
| cluster_name | tenant_name | name | value |
+--------------+-------------+---------+-------------+
| cluster1 | tenant1 | ip_list | 182.168.1.1 |
+--------------+-------------+---------+-------------+
如果只設置集群級別， 語句不加入 即可，全局級別類似， 語句不加入 和 。這里大家需要注意使用網絡號時要填寫正確，如192.168.15.0/16就是錯誤的格式，第三位不應該為15，應該為0。
1.1.3 最大連接數
通過配置項ns控制客戶端最大連接數。因為分布式系統連接較多，我們舉例說明下。
從整個鏈路看數據庫功能分析圖，存在4個連接：App 和 有一個， 和 有三個。但從 App 角度去看，只有一個連接。因此配置項就是對 App 和 之間的連接數做限制， 和 之間的連接不計算在內。
當 的客戶端連接數超過限制后，客戶端再次建連會登陸失敗， 會給客戶端返回 ERROR 報文，報錯信息為 of 。
1.2 傳輸加密
1.2.1 實現原理
通過 SSL 對數據傳輸進行加密。在實現上有兩種方案：
方案一
方案二
大家可以看到，方案一 只做 SQL 轉發，不感知報文內容，實現簡單。方案二中， 會重新加解密數據，并分析請求報文和響應報文的內容。方案二相比方案一更加復雜，但這樣的優點是：
除了優點，方案二也有一些缺點， 需要加解密數據，對性能有一定損耗。那么影響有多大呢？基于 優秀的異步和多線程模型，即使全鏈路都開 SSL，性能影響也在 3% 以內，大家可以放心使用。
1.2.2 使用案例
想要使用SSL功能還是比較復雜的一件事情。需要滿足下面條件：
我們以 某公有云客戶使用 SSL 為例說明。
我們從控制流和數據流兩個角度說下上面內容。
控制流： 不直接對接密鑰服務，對外提供 SQL 端口供設置證書和密鑰。OCP對接不同的KMS服務，并給 發送 SQL 設置密鑰相關信息。
數據流：業務 App 發送的數據跨越 VPC，進行加密傳輸。 和 在同一個 VPC 內，首先得到了 VPC 保護， 接收到數據后，可以給 發送加密數據或者非加密數據，給 App 回包時，會對數據加密后再傳輸。
1.2.3 SSL配置
想要使用 SSL 能力，還需要對各個組件進行配置，本節介紹 如何配置SSL。方法如下圖所示。
# 配置密鑰和證書
replace into ssl_config (cluster_name, tenant_name, name, value) values('*', '*', 'key_info', '{"sourceType" : "FILE", "CA" : "certs/ca.pem", "publicKey" : "certs/server-cert.pem", "privateKey" : "certs/server-key.pem"}');
# 開啟客戶端和OBProxy之間的SSL
replace into proxy_config(name, value, config_level) values('enable_client_ssl', 1, 'LEVEL_GLOBAL');
# 開啟OBProxy和OBServer之間的SSL
replace into proxy_config(name, value, config_level) values('enable_server_ssl', 1, 'LEVEL_GLOBAL');
這里介紹一下上面配置的含義，對于表，字段含義如下：
對于表，字段含義如下：
這里需要注意一點：打開SSL配置并不代表一定使用SSL，比如客戶端不支持的話， 開啟SSL能力也沒作用。
是否走了加密，客戶端可以通過\s命令確認（關注SSL一行，下圖為 in use is ECDHE-RSA--GCM-）。
MySQL [test]> \s
--------------
mysql Ver 15.1 Distrib 5.5.64-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 3221487953
Current database: test
Current user: root@127.0.0.1
SSL: Cipher in use is ECDHE-RSA-AES256-GCM-SHA384
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MySQL
Server version: 5.7.25 OceanBase 4.0.0.0 (r1-a06adb022eaa434bb5210294830a20003a5753a8) (Built Apr 7 2022 23:30:49)
Protocol version: 10
Connection: 127.1 via TCP/IP
Server characterset: utf8mb4
Db characterset: utf8mb4
Client characterset: utf8mb4
Conn. characterset: utf8mb4
TCP port: 33041
Active --------------
這里需要注意，上面內容只能確定客戶端和 是否開啟了 SSL， 和 是否開啟需要查詢 的內部表確定。
2. 協議
大家都知道，使用開源 MySQL 驅動就可以連接 使用了，這是因為 支持了 MySQL 協議。其實， 總共支持三種協議，見下圖。
使用 MySQL 協議，使用 MySQL 生態的客戶端即可。使用 2.0協議和 RPC 協議，需要使用專屬客戶端。對于 RPC 協議，在 OBKV 的產品形態下提供，本文不做詳細介紹。MySQL 協議大家都很熟悉，所以重點介紹一下2.0協議。
2.0協議是 團隊自研的協議。設計時考慮了兼容性、安全性和擴展性幾個方面，整體格式如下：
ceanBase 2.0 Protocol Format：
? 0 1 2 3 4 Byte
+-----------------+----------------------+
| Magic Num | Version |
+-----------------+----------------------+
| Connection Id |
+-----------------------------+----------+
| Request Id | Seq |
+-----------------------------+----------+
| PayLoad Length |
+----------------------------------------+
| Flag |
+-----------------+----------------------+
| Reserved |Header Checksum(CRC16)|
+-----------------+----------------------+
| ... PayLoad Data ... |----------+
+----------------------------------------+ |
| Tailer PayLoad Checksum (CRC32) | |
+----------------------------------------+ |
|
|
+--------------------------+
|
|
v
+-------------------+-------------------+-------------------------------------+
| Extra Len(4Byte) | Extra Info(K/V) | Basic Info(Standard MySQL Packet) |
+-------------------+-------------------+-------------------------------------+
每個字段含義不在此作介紹，我們說明下設計考慮。
OB 4.0版本已經發布，默認使用2.0協議，后續我們也會基于2.0協議開發更多功能，如全鏈路診斷、分布式事務路由等，大家也會慢慢發現2.0協議的好處。
3. 監控
對于監控信息， 的設計理念是和開源產品最對接，讓大家使用門檻更低。目前 支持了監控。監控系統的設計如下。
要做的就是實現圖中左下角 的功能，對 提供監控數據。 使用2884端口供 訪問。如下圖通過 curl -L 127.0.0.1/2884/ 獲得了監控數據：
在 監控界面可以展現的更加清楚（下圖是RT和QPS監控信息）：
總結
除了分布式特性， 也結合流行的云原生技術、安全技術等，提供面向用戶的功能。
本文從安全和監控角度，介紹了登錄安全、IP白名單、連接數、普羅米修斯監控等一些大家耳熟能詳的功能。對于協議部分，大家可以看到 本身是一個協議轉換器，支持了 MySQL協議、2.0協議和RPC協議，使 支持OBKV、融入MySQL 生態、擴展自身能力。
團隊也在關注現有的云原生等技術，在螞蟻公司內部做了云原生 Mesh 形態的功能并廣泛使用，后續我們會更深入結合云產品和流行技術，為大家提供更好的服務。
課后互動 上期互動答案
問：當 和 某個 節點發生網絡故障后，但 內部沒有網絡故障。此時如果要保證 RTO < 30s，那么 探測的周期、探測連續失敗次數和探測超時時間該如何配置？
答：大家需要了解探測周期、探測超時時間和探測連續失敗次數之間的關系，經驗上看，連續失敗次數不能為1，不然一次網絡抖動就會導致探測失敗，周期要在秒級別，不能太頻繁也不能太長。對于RTO < 30 s數據庫功能分析圖，可以設置周期為5s，連續失敗次數為4次，超時時間為5s，那么在25s~30s之間就可以發現故障。
本期互動
問：客戶端發給 加密數據，那么 發給 的一定是加密數據嗎？