如何構建一個流量無損的線上應用架構 | 專題尾篇
簡介：我們將這些年在每一個環節中的相應解決方案，以產品化的方式沉澱到企業級分散式應用服務（EDAS）中。EDAS 致力於解決線上應用的全流程流量無損，經過 6 年的精細打磨，已經在流量接入與流量服務兩個關鍵位置為我們的客戶提供了流量無損的關鍵能力，我們接下來的主要目標也是將這一能力貫穿應用的全流程，讓您的應用預設能具備全流程的流量無損，極力保障商業能力的可持續性。
作者 | 孤弋、十眠
-全系列檢視-
前言
上兩篇我們說完了流量解析、流量接入、流量服務三大塊的內容，這一篇主要從資料交換的維度闡明資料交換的過程如何影響到線上流量；最後會引入兩個常用的防範措施：全鏈路壓測
資料
當流量在應用叢集中流轉完畢之後，他行至的終點一般是將資料與各種型別的資料服務進行交換，如：從快取讀取資料返回、將訂單記錄儲存在資料庫中、將交易資料與外圍的支付服務進行資料交換等。但是隻要是和外面的服務進行資料訪問，就會出現外圍服務不可用的情況，常見的一些情況比如：因為被依賴過重或資料過載而導致雪崩，因為資料中心整體不可用導致大面積癱瘓。比如最近一個比較有名的事件就是 Meta 公司的大規模宕機事件，其原因正是下發了一條錯誤的配置切斷了資料中心之間的主幹路由。
針對國內網際網路公司海量資料的場景，當我們的業務成長到一定的階段就會帶來快取或者 DB 的容量問題，以 MySQL 舉例子，當單表的容量在千萬級別的時候，如果這張表還需要和其他表進行關聯查詢，就會出現資料庫在 IO、CPU 各方面的壓力。此時就需要開始考慮分庫分表的方案。但是分完了之後並不是一蹴而就，他會引入諸如分散式事務、聯合查詢、跨庫 Join 等新的問題，每個問題如果人肉去搞定會更加的棘手，不過好在市面上針對這些領域也出現了很多優秀的框架，比如社群的 Sharding JDBC，阿里雲剛剛開源的 PolarDB-X 等。
2、常用解決方案：資料中心容災
為防止資料中心出現整體不可用的情況，一個常規的思路是需要針對性建設好容災多活的高可用能力，資料中心級別的容災常見的是同城和異地，但一個數據中心部署的服務很可能是分散式服務，針對每一個分散式服務的容災策略都略有不同，本篇以常見的 MySQL 來舉例子說一些常見的思路。
容災的核心是需要解決 CAP 中的兩個問題，即：C（資料一致性）、A（服務可用性），但是根據 CAP 理論我們只能保 CP 和 AP 中的一個，所以這裡到底選擇什麼樣子的策略，其實是需要根據業務形態來制定的。對於同城 IDC 級別的容災而言，由於他的 RT 一般都很小，資料一致性上能最大的得以滿足。只是在 Paxos（MySQL 中的一致性演算法）的 Master 節點所在的機房如果掛掉的情況下，會面臨再次選主，如果叢集較大可能會因為選主造成的幾十秒級別 DB 不可用的情況。
而對於異地場景而言，由於資料鏈路太長的問題，他的資料一致性基本上不可能滿足，所以業務必須配合改造，做到業務級別的橫向切分，如：華南資料中心服務華南客戶群體，華北資料中心服務華北客戶群體。而分片的資料再通過資料同步的方式做到最終一致性。
防範
到這裡基本上說完了在線上應用的四個核心環節中，尤其提及了容易由於架構設計、基礎設施脆弱等原因而造成的流量有損的點，也列舉了對應場景下的解決方案。不過站在安全生產的角度上，一切安全生產的目的都是防範於未然。在網際網路的系統中相比較於傳統的軟體產品，我們推薦兩個在生產級別進行防範的方法：全鏈路壓測和安全生產線上演練（也叫故障演練）。
在軟體產品的生產體系中，任何一個即將上線的系統，我們都會進行各種目標的測試，其中就包括壓力測試，即：使系統處於一個頗為嚴苛的環境中，來觀看系統的表現。而一般的壓力測試，只會針對性的構造相應的介面對線下部署的環境服務進行相應的壓力測試，而且測試報告不出意外都是很完美的；但這樣的壓力測試會有幾個問題：
- 由於線上線下的依賴環境差異很大，而評估不到真實的線上系統容量。
- 壓測過程的資料不豐富，覆蓋面窄而造成場景遺漏。
- 由於壓測的流量或者工具不夠健全，只能評估到單臺機器或服務，而非整個生產叢集。
如果要做到全面、系統、且真實的流量評估，我們推薦直接使用生產環境針對性的進行效能壓測，但要想做到這樣的全鏈路的壓力測試，有很多的技術瓶頸需要突破，其中包括：
- 有一套能力強大能構建出豐富場景的工具體系或產品。
- 整體服務鏈路上，支援從流量入口開始的壓測標示傳遞。
- 系統中使用的中介軟體能識別正常流量與壓測流量。
- 業務需要針對壓測流量作出業務改造（如影子表），以免壓測資料影響到線上的真實資料。
但是在執行過程中，由於全鏈路的影響面太大，在正式開始大流量的壓測之前，需要逐步實施前期的準備工作，其中包括：壓測方案制定、預跑驗證、壓測預熱，最後才是正式壓測。壓測完畢還需要針對壓測結果進行分析，以確保整個系統符合預先設定的目標。
2、安全生產演練
與全鏈路壓測的思路類似，為了儘可能的貼近生產環境，安全生產演練我們也是推薦在線上完成。演練的目的是檢驗系統在各種不可預知的服務不可用、基礎實施故障或者依賴失效的情況下，來檢驗系統的行為表現是否依然健壯。通常演練的範圍從單應用到服務叢集，甚至到整機房基礎設施依次上升。演練場景可以從程序內（如：請求超時）、程序級別（如：FullGC）、容器（如：CPU 高），再到 Kubernetes 叢集（如：Pod驅逐、ETCD 故障等）各個場景疊加，根據業務系統的反脆弱能力，針對性的作出選擇。
結語
至此，三篇關於如何構建一個流量無損的線上應用系統就全部說完了，文中很多場景和技術點都是來源於真實的線上系統的真實故障。我們將這些年在每一個環節中的相應解決方案，以產品化的方式沉澱到企業級分散式應用服務（EDAS）中。EDAS 致力於解決線上應用的全流程流量無損，經過 6 年的精細打磨，已經在流量接入與流量服務兩個關鍵位置為我們的客戶提供了流量無損的關鍵能力，我們接下來的主要目標也是將這一能力貫穿應用的全流程，讓您的應用預設能具備全流程的流量無損，極力保障商業能力的可持續性。
接下來 EDAS 將圍繞開發、測試繼續構建一個完整的技術中臺；我們也在籌備免費下載的版本，讓您可以輕鬆的在自己的任意一個環境中享受到諸多預設流量無損的能力。在交付側，將打通多叢集、多應用批量交付，打通線上公共雲、線下免費輸出以及混合雲之間的交付能力。敬請期待。
本文為阿里雲原創內容，未經允許不得轉載。