文章中的許多場景和技術(shù)點(diǎn)都來自于真實(shí)的在線系統(tǒng)的真實(shí)故障。我們以產(chǎn)品化的方式將多年來各環(huán)節(jié)的相應(yīng)解決方案沉淀到企業(yè)分布式應(yīng)用服務(wù)中（EDAS）中。
本文主要從數(shù)據(jù)交換的維度闡述了數(shù)據(jù)交換過程如何影響在線流量；最后，將引入兩種常見的預(yù)防措施：全鏈路壓力測試和安全生產(chǎn)演練。讓我們從數(shù)據(jù)交換部分開始：
數(shù)據(jù)
當(dāng)流量在應(yīng)用集群中流通時，他的終點(diǎn)通常是與各種類型的數(shù)據(jù)服務(wù)交換數(shù)據(jù)，如從緩存中讀取數(shù)據(jù)返回、在數(shù)據(jù)庫中存儲訂單記錄、交易數(shù)據(jù)和外圍支付服務(wù)進(jìn)行數(shù)據(jù)交換等。然而，只要數(shù)據(jù)訪問外部服務(wù)，外部服務(wù)就不可用。一些常見的情況，如過度依賴或數(shù)據(jù)過載，導(dǎo)致雪崩，因?yàn)檎麄€數(shù)據(jù)中心不可用，導(dǎo)致大面積癱瘓。例如，最近一個著名的事件是 Meta 公司大規(guī)模停機(jī)的原因是發(fā)布了切斷數(shù)據(jù)中心之間主要路由的錯誤配置。
1. 常用解決方案:分庫分表
對于國內(nèi)互聯(lián)網(wǎng)公司大量數(shù)據(jù)的場景，當(dāng)我們的業(yè)務(wù)發(fā)展到一定階段時，它會帶來緩存或 DB 容量問題，以 MySQL 例如，當(dāng)單表的容量達(dá)到1000萬級時，如果此表需要與其他表相關(guān)聯(lián)，則會出現(xiàn) 數(shù)據(jù)庫IO、CPU 各方面的壓力。在這個時候，我們需要開始考慮分庫和分表的計(jì)劃。然而，分割后不是一蹴而就的。他將介紹分布式事務(wù)、聯(lián)合查詢、跨庫 Join 和其他新問題，如果人肉解決每個問題會更困難，但幸運(yùn)的是，市場上有許多優(yōu)秀的框架，如社區(qū) Sharding JDBC，剛剛開源的阿里云 PolarDB-X 等。
2. 常用解決方案:數(shù)據(jù)中心容災(zāi)
為了防止數(shù)據(jù)中心整體不可用，一個傳統(tǒng)的想法是建立高可用性，數(shù)據(jù)中心水平的災(zāi)難是常見的城市和不同的地方，但數(shù)據(jù)中心部署服務(wù)可能是分布式服務(wù)，每個分布式服務(wù)災(zāi)難戰(zhàn)略略略有所不同，本文是常見的 MySQL 舉例說一些常見的想法。
容災(zāi)的核心是需要解決 CAP 有兩個問題，即：C(數(shù)據(jù)一致性)，A(服務(wù)可用性)，但根據(jù) CAP我們只能保護(hù) 理論CP 和 AP 之一，所以這里選擇什么樣的策略，其實(shí)需要根據(jù)業(yè)務(wù)形式來制定。對于同城 IDC 級容災(zāi)，因?yàn)樗?RT 一般很小，最大限度地滿足數(shù)據(jù)一致性。Paxos(MySQL Master 如果節(jié)點(diǎn)所在的機(jī)房掛斷，將面臨重新選擇主人。如果集群較大，可能會導(dǎo)致選擇主人的幾十秒級 DB 不可用的情況。對于不同的場景，由于數(shù)據(jù)鏈路太長，其數(shù)據(jù)一致性基本不能滿足，因此業(yè)務(wù)必須配合轉(zhuǎn)型，實(shí)現(xiàn)業(yè)務(wù)水平的水平劃分，如：華南數(shù)據(jù)中心為華南客戶群服務(wù)，華北數(shù)據(jù)中心為華北客戶群服務(wù)。通過數(shù)據(jù)同步實(shí)現(xiàn)最終一致性。

防范
這里基本完成了在線應(yīng)用的四個核心環(huán)節(jié)，特別是由于架構(gòu)設(shè)計(jì)、基礎(chǔ)設(shè)施脆弱等原因，也列出了相應(yīng)場景下的解決方案。然而，從安全生產(chǎn)的角度來看，所有安全生產(chǎn)的目的都是在萌芽狀態(tài)下進(jìn)行預(yù)防。在互聯(lián)網(wǎng)系統(tǒng)中，與傳統(tǒng)的軟件產(chǎn)品相比，我們推薦兩種生產(chǎn)水平的預(yù)防方法：全鏈路壓力測試和安全生產(chǎn)在線演習(xí)（也稱為故障演習(xí)）。
1. 全鏈路壓測
在軟件產(chǎn)品的生產(chǎn)系統(tǒng)中，我們將測試任何即將出的系統(tǒng)進(jìn)行各種目標(biāo)測試，包括壓力測試，即使系統(tǒng)處于一個非常嚴(yán)格的環(huán)境中，以觀察系統(tǒng)的性能。一般壓力測試只能構(gòu)建相應(yīng)的線下部署環(huán)境服務(wù)接口，測試報(bào)告境服務(wù)，測試報(bào)告壓力測試會有幾個問題：
由于線上線下依賴環(huán)境差異較大，無法評估真實(shí)的線上系統(tǒng)容量。
壓力測量過程數(shù)據(jù)不豐富，覆蓋面窄，導(dǎo)致場景遺漏。
由于壓力測量的流量或工具不完善，只能評估單臺機(jī)器或服務(wù)，而不是整個生產(chǎn)集群。
如果要實(shí)現(xiàn)全面、系統(tǒng)、真實(shí)的流量評估，我們建議直接使用生產(chǎn)環(huán)境進(jìn)行有針對性的性能壓力測試，但有許多技術(shù)瓶頸需要突破，包括：
能夠構(gòu)建豐富場景的工具體系或產(chǎn)品。
在整體服務(wù)鏈路上，支持從流量入口開始的壓測標(biāo)志傳輸。
系統(tǒng)中使用的中間件可以識別正常流量和壓測流量。
業(yè)務(wù)需要對壓測流量進(jìn)行業(yè)務(wù)改造(如影子表)，以免壓測數(shù)據(jù)影響在線真實(shí)數(shù)據(jù)。
然而，在實(shí)施過程中，由于整個鏈路的影響太大，在正式開始大流量壓力測試之前，需要逐步實(shí)施初步準(zhǔn)備工作，包括：壓力測試方案的制定、預(yù)跑驗(yàn)證、壓力測試預(yù)熱，最后是正式的壓力測試。壓力測試結(jié)束后，還需要分析壓力測試結(jié)果，以確保整個系統(tǒng)符合預(yù)設(shè)目標(biāo)。
2. 安全生產(chǎn)演練
類似于全鏈路壓力測試的想法，為了盡可能接近生產(chǎn)環(huán)境，我們也建議在線完成安全生產(chǎn)演習(xí)。演習(xí)的目的是檢查系統(tǒng)的行為性能是否仍然強(qiáng)大，以檢查各種不可預(yù)測的服務(wù)是否不可用、基礎(chǔ)實(shí)施故障或依賴故障。通常，演習(xí)的范圍從單一應(yīng)用到服務(wù)集群，甚至整個機(jī)房的基礎(chǔ)設(shè)施依次上升。演習(xí)場景可以從過程請求加班）、過程級別（如：FullGC)、容器(如：CPU 高)，再到 Kubernetes 集群(如:Pod驅(qū)逐、ETCD 故障等)各個場景疊加，根據(jù)業(yè)務(wù)系統(tǒng)的反脆弱能力，針對性的作出選擇。
結(jié)語
文章中的許多場景和技術(shù)點(diǎn)都來自于真實(shí)的在線系統(tǒng)的真實(shí)故障。我們以產(chǎn)品化的方式將多年來各環(huán)節(jié)的相應(yīng)解決方案沉淀到企業(yè)分布式應(yīng)用服務(wù)中(EDAS)中。EDAS 致力于解決在線應(yīng)用的全過程流量無損，經(jīng)過 6 年的精細(xì)拋光，在流量接入和流量服務(wù)兩個關(guān)鍵位置為客戶提供流量無損的關(guān)鍵能力，我們的下一個主要目標(biāo)是通過整個應(yīng)用過程，讓您的應(yīng)用默認(rèn)流量無損，確保業(yè)務(wù)能力的可持續(xù)性。

熱點(diǎn)：ETC 數(shù)據(jù)