這一篇主要從數據交換的維度闡明數據交換的過程如何影響到線上流量;最后會引入兩個常用的防范措施：全鏈路壓測和安全生產演練。我們先來說說數據交換部分：

數據

當流量在應用集群中流轉完畢之后，他行至的終點一般是將數據與各種類型的數據服務進行交換，如：從緩存讀取數據返回、將訂單記錄存儲在數據庫中、將交易數據與外圍的支付服務進行數據交換等。但是只要是和外面的服務進行數據訪問，就會出現外圍服務不可用的情況，常見的一些情況比如：因為被依賴過重或數據過載而導致雪崩，因為數據中心整體不可用導致大面積癱瘓。比如最近一個比較有名的事件就是 Meta 公司的大規模宕機事件，其原因正是下發了一條錯誤的配置切斷了數據中心之間的主干路由。

1. 常用解決方案：分庫分表

針對國內互聯網公司海量數據的場景，當我們的業務成長到一定的階段就會帶來緩存或者 DB 的容量問題，以 MySQL 舉例子，當單表的容量在千萬級別的時候，如果這張表還需要和其他表進行關聯查詢，就會出現數據庫在 IO、CPU 各方面的壓力。此時就需要開始考慮分庫分表的方案。但是分完了之后并不是一蹴而就，他會引入諸如分布式事務、聯合查詢、跨庫 Join 等新的問題，每個問題如果人肉去搞定會更加的棘手，不過好在市面上針對這些領域也出現了很多優秀的框架，比如社區的 Sharding JDBC，阿里云剛剛開源的 PolarDB-X 等。

2. 常用解決方案：數據中心容災

為防止數據中心出現整體不可用的情況，一個常規的思路是需要針對性建設好容災多活的高可用能力，數據中心級別的容災常見的是同城和異地，但一個數據中心部署的服務很可能是分布式服務，針對每一個分布式服務的容災策略都略有不同，本篇以常見的 MySQL 來舉例子說一些常見的思路。

容災的核心是需要解決 CAP 中的兩個問題，即：C(數據一致性)、A(服務可用性)，但是根據 CAP 理論我們只能保 CP 和 AP 中的一個，所以這里到底選擇什么樣子的策略，其實是需要根據業務形態來制定的。對于同城 IDC 級別的容災而言，由于他的 RT 一般都很小，數據一致性上能最大的得以滿足。只是在 Paxos(MySQL 中的一致性算法)的 Master 節點所在的機房如果掛掉的情況下，會面臨再次選主，如果集群較大可能會因為選主造成的幾十秒級別 DB 不可用的情況。而對于異地場景而言，由于數據鏈路太長的問題，他的數據一致性基本上不可能滿足，所以業務必須配合改造，做到業務級別的橫向切分，如：華南數據中心服務華南客戶群體，華北數據中心服務華北客戶群體。而分片的數據再通過數據同步的方式做到最終一致性。

防范

到這里基本上說完了在線上應用的四個核心環節中，尤其提及了容易由于架構設計、基礎設施脆弱等原因而造成的流量有損的點，也列舉了對應場景下的解決方案。不過站在安全生產的角度上，一切安全生產的目的都是防范于未然。在互聯網的系統中相比較于傳統的軟件產品，我們推薦兩個在生產級別進行防范的方法：全鏈路壓測和安全生產線上演練(也叫故障演練)。

1. 全鏈路壓測

在軟件產品的生產體系中，任何一個即將上線的系統，我們都會進行各種目標的測試，其中就包括壓力測試，即：使系統處于一個頗為嚴苛的環境中，來觀看系統的表現。而一般的壓力測試，只會針對性的構造相應的接口對線下部署的環境服務進行相應的壓力測試，而且測試報告不出意外都是很完美的;但這樣的壓力測試會有幾個問題：

• 由于線上線下的依賴環境差異很大，而評估不到真實的線上系統容量。
• 壓測過程的數據不豐富，覆蓋面窄而造成場景遺漏。
• 由于壓測的流量或者工具不夠健全，只能評估到單臺機器或服務，而非整個生產集群。

如果要做到全面、系統、且真實的流量評估，我們推薦直接使用生產環境針對性的進行性能壓測，但要想做到這樣的全鏈路的壓力測試，有很多的技術瓶頸需要突破，其中包括：

• 有一套能力強大能構建出豐富場景的工具體系或產品。
• 整體服務鏈路上，支持從流量入口開始的壓測標示傳遞。
• 系統中使用的中間件能識別正常流量與壓測流量。
• 業務需要針對壓測流量作出業務改造(如影子表)，以免壓測數據影響到線上的真實數據。

但是在執行過程中，由于全鏈路的影響面太大，在正式開始大流量的壓測之前，需要逐步實施前期的準備工作，其中包括：壓測方案制定、預跑驗證、壓測預熱，最后才是正式壓測。壓測完畢還需要針對壓測結果進行分析，以確保整個系統符合預先設定的目標。

2. 安全生產演練

與全鏈路壓測的思路類似，為了盡可能的貼近生產環境，安全生產演練我們也是推薦在線上完成。演練的目的是檢驗系統在各種不可預知的服務不可用、基礎實施故障或者依賴失效的情況下，來檢驗系統的行為表現是否依然健壯。通常演練的范圍從單應用到服務集群，甚至到整機房基礎設施依次上升。演練場景可以從進程內(如：請求超時)、進程級別(如：FullGC)、容器(如：CPU 高)，再到 Kubernetes 集群(如：Pod驅逐、ETCD 故障等)各個場景疊加，根據業務系統的反脆弱能力，針對性的作出選擇。

結語

文中很多場景和技術點都是來源于真實的線上系統的真實故障。我們將這些年在每一個環節中的相應解決方案，以產品化的方式沉淀到企業級分布式應用服務(EDAS)中。EDAS 致力于解決在線應用的全流程流量無損，經過 6 年的精細打磨，已經在流量接入與流量服務兩個關鍵位置為我們的客戶提供了流量無損的關鍵能力，我們接下來的主要目標也是將這一能力貫穿應用的全流程，讓您的應用默認能具備全流程的流量無損，極力保障商業能力的可持續性。