境外業務性能優化實踐
「文末高能」
編輯 | 哈比
一、前言
1. 性能問題簡介
應用性能是產品用戶體驗的基石，性能優化的終極目標是優化用戶體驗。
當我們談及性能，最直觀能想到的一個詞是 「快」，Strangeloop 在對眾多的網站做性能分析之後得出了一個著名的 3s 定律 「頁面載入速度超過 3s，57% 的訪客會離開」。
可見頁面載入速度對於互聯網產品的重要性。
速度在 Google、百度等搜索引擎的 PR 評分中也佔有一定的比例，會影響到網站的 SEO 排名。「天下武功、唯快不破」，套在性能上面也非常適用。
1.1 性能指標
性能優化是個系統性工程，涉及到後端、前端、移動端、系統網路及各種基礎設施，每一塊都需要做各自的性能優化。當我們系統的分析性能問題時，可以通過以下指標來衡量：
1）Web 端：首屏時間、白屏時間、可交互時間、完全載入時間等；
首屏時間是指從用戶打開網頁開始到瀏覽器第一屏渲染完成的時間，是最直接的用戶感知體驗指標，也是性能領域公認的最重要的核心指標。
首屏時間 = DNS 時間 + 建立連接時間 + 後端響應時間 + 網路傳輸時間 + 首屏頁面渲染時間。
2）移動端：Crash 率、內存使用率、FPS（Frames Per Second，每秒傳輸幀數）、端到端響應時間等；
Native 相比於 H5 在交互體驗方面有更多的優勢，FPS 是體現頁面順暢程度的一個重要指標，另外端上的開發同學還需要關注 App 進程的 CPU 使用率、內存使用率等系統性能指標。
端到端響應時間是衡量一個 API 性能的關鍵指標，比純後端響應時間更全面，它會受到 DNS、網路帶寬、網路鏈路、HTTP payload 等多個因素的影響。
端到端響應時間是 DNS 解析時間、網路傳輸時間及後端響應時間的總和。
3）後端：響應時間（RT）、吞吐量（TPS）、並發數等。
後端系統響應時間是指系統對請求做出響應的時間（應用延遲時間）。對於面向用戶的 Web 服務，響應時間能很好度量應用性能，會受到資料庫查詢、RPC 調用、網路 IO、邏輯計算複雜度、JVM 垃圾回收等多方面因素影響。
對於高並發的應用和系統，吞吐量是個非常重要的指標，它與 request 對 CPU、內存資源的消耗，調用的外部介面及 IO 等緊密關聯。
1.2 影響性能的因素
互聯網產品是創意、研發、系統、網路、硬體、維護等眾多資源相互交織的集合體，性能受多方面因素影響。
猶如一隻木桶，木桶能盛多少水，並不取決於最長的那塊木板，而是缺與最短的那塊木板，也可稱之為短板效應。
影響產品性能的因素有：
1）產品邏輯與用戶行為
產品邏輯過於複雜、功能交互過於豐富、產品設計過於絢麗、頁面元素素材過多等都會影響產品性能。
2）基礎網路
中國的基礎網路是世界上最複雜的基礎網路，國內的網路運營商眾多且各自為政，互聯互通成本很高。
對於境外業務來說更是要面對國內國際網路交互的情況，再加上 GFW 的存在，網路延遲、丟包現象非常嚴重。
3）代碼及應用
開發語言瓶頸、代碼質量及系統架構等都會影響系統性能，常見的代碼及應用問題有：
架構不嚴謹，業務發展超越架構支撐能力而導致系統負荷過載，進而導致出現系統奔潰、響應超時等現象；
不合理、不適用的架構必將影響速度，如單點、無 Cache、應用混部署、沒有考慮分散式、集群化等；
研發 「功力」 和經驗不足，開發的 App、Server 效率和性能較低、不穩定也是常見的事情；
沒有性能意識，業務上量後系統出現連鎖反應，導致性能問題疊加，直接影響用戶體驗；
多數的性能問題發生在資料庫上，由慢 SQL、過多查詢等原因造成的資料庫瓶頸，沒有做讀寫分離、分庫分表等。
4）移動端環境
移動互聯網時代，移動端的環境的複雜性對產品的性能影響也很大，比如用戶的設備類型、設備性能、操作系統類型、系統版本及網路類型（電信 / 移動 / 聯通 , wifi/4G/3G/2G）等。
5）伺服器及雲環境
硬體的發展遵循著摩爾定律，硬體的生命周期一般都很短，伺服器老化或其他硬體問題經常會導致應用故障。
IDC、機架、伺服器、內存、磁碟、網卡等不同硬體和操作系統上運行的應用性能差距可以達到數十倍之多。
2. 境外業務的特點
境外業務與其他境內業務相比，區別主要表現在以下及方面：
1）用戶在境外訪問
境外業務很大一部分流量來自境外訪問，國外網路情況十分複雜，一些國家的網路基礎設施很差。
以越南泰國等東南亞國家為例，很多國家 4G 覆蓋率很低，從國外訪問國內機房，不僅網路鏈路長，還涉及到跨網跨運營商跨 GFW 的訪問情況，訪問延遲、網路丟包等情況非常嚴重。
2）大量使用 Hybrid 實現
由於業務發展很快，業務新增及變更也相對頻繁，為適應業務的快速發展，我們大量採用的是 H5 方式實現，大量使用 Hybrid 模式。
3）與境外商家對接
除了用戶在境外訪問，境外業務還會和很多境外商家、供應商或代理商有合作對接，同樣面臨著跨國網路訪問的問題。
基於以上背景，如何產品性能，做到像國內業務一樣，其中面臨了很多的技術挑戰。
本文將從網路優化、前端優化、後端優化等角度來介紹境外業務在性能優化方面的做過的一些事情。
二、網路優化
影響網路性能的問題有很多，常見的網路問題有以下幾類。
1. 問題一：DNS 問題
DNS 問題最容易被大家所忽視，而實際上 DNS 出問題的概率非常大，DNS 問題主要有 2 類：
1） DNS 解析慢或解析失敗
我們統計過一些數據，我們的域名在國內 DNS 解析耗時大概在 30-120ms 之間，而國外網路下耗時達到 200-300ms 左右，在 2G/3G 等弱網環境下，DNS 解析失敗非常常見，DNS 對於首次網路訪問的耗時及網路成功率會有很大的影響。
下圖是我們利用頁面測速工具（gtmatrix）在加拿大溫哥華節點測試的一個頁面首次訪問時的網路請求情況，可以看出當用戶在加拿大第一次訪問且運營商 LocalDNS 無 NS 緩存記錄時，DNS 解析是非常慢的。
2）DNS 劫持或失效
烏雲（WooYun）上曾報過多起因域名服務商安全漏洞被黑客利用導致網站 NS 記錄被篡改的 case。而更多的 DNS 劫持確實來自於網路運營商的作惡，主要有以下幾種：
本地緩存，各運營商確保網內訪問，同時減少跨網結算，運營商在網內搭建了內容緩存伺服器，通過把域名強行指向內容緩存伺服器；
內容劫持，有部分 LocalDNS 會把部分域名解析指向內容緩存，並替換成第三方廣告聯盟的廣告；
解析轉發，運營商的 LocalDNS 還存在解析轉發的形象。指運營商自身不進行域名遞歸解析，而是把域名解析請求轉發到其他運營商的遞歸 DNS 上，解析請求的來源 IP 成了其他運營商的 IP，從而導致用戶請求跨網訪問，性能變差。
2. 問題二：網路鏈路問題
鏈路過長、請求經過的路由轉發跳數過多、跨網訪問等都是影響網路傳輸性能的關鍵因素。
另外網路攻擊（主要是 DDos、CC 攻擊等洪水攻擊）流量也影響著網路鏈路的穩定性。據統計，骨幹網上每天有數百 G 的流量為攻擊流量。
3. 問題三：傳輸 Payload 大小
移動設備的網路在非 Wi-Fi 環境下時通常不太穩定，再加上有 TCP 擁塞策略的限制，數據傳輸量越大傳的就越慢，我們需要盡量的減少數據傳輸量。
通常的做法有：數據壓縮、圖片壓縮、選擇更高效的序列化演算法（比如 protocol Buffer）等。
我們在網路優化方面主要做了以下幾件事情：
CDN 優化：海外 CDN 加速、CDN 緩存預熱；
DNS Prefetch：DNS 預熱，刷新移動設備系統 /VM 的 DNS 緩存；
長連接：」 代理長連接 「Shark，專線鏈路優化，並且有效解決了 DNS 的瓶頸問題；
網路鏈路優化：通過專線和代理，解決公網鏈路長及網路抖動不穩定的問題。
3. CDN 優化
CDN 服務的好壞主要取決於節點部署的覆蓋程度、帶寬以及調度演算法。
對國內業務而言，使用藍汛、網宿、帝聯等老牌 CDN 服務商或騰訊雲、阿里雲、UPYUN 等雲 CDN 服務商性能都很好，但這些 CDN 服務商在境外的節點就很少了。
為了提升境外的靜態資源加速效果，我們嘗試對接了很多國外的知名 CDN 服務商（每一家在不同區域的服務能力不一樣，但都很貴！）。
通過智能 DNS 解析用戶的 IP 來源，如果是境外訪問則 CNAME 到國外 CDN，國內訪問時仍然走的是國內 CDN。
CDN 也是一種緩存，是緩存就不得不談命中率的問題。 如果用戶在境外訪問時 CDN 未命中，靜態資源從境外回源到國內源站獲取，成本非常高。
為了提升緩存命中率，我們的做法是在香港搭了一個 CDN 中間源，在前端資源發布時會調用 cdn 的 push 介面把資源預熱到中間源，保證當境外邊緣節點緩存未命中時無需再回源到國內 IDC，只需從中間源獲取。
4. DNS Prefetch
由於 DNS 的種種問題，騰訊推出了 HTTPDNS 服務，使用 HTTP 協議向 DNS 伺服器的 80 埠進行請求，代替傳統的 DBS 協議向 DNS 伺服器的 53 埠進行請求，繞開 Local DNS，避免網路劫持和跨網訪問等問題。
但 HTTPDNS 需要能夠獲取 CDN 邊緣節點的 IP，這就限制了只有像騰訊、阿里這種有自建 CDN 的大廠才能實現。
另外 W3C 也提供了 DNS 預讀的方案，可以通過在伺服器端發送 X-DNS-Prefetch-Control 報頭，或是在文檔中使用值為 http-equiv 的 標籤：
這種方式打開瀏覽器的 DNS 預讀取功能，但是該 API 功能目前在移動端瀏覽器內核中實現支持的較少。
我們採取的是一種輕量級的方案，如下：
利用 APP 啟動時的 config 介面，下發 DNS Prefetch 的配置參數：開關、時間間隔、需要進行 prefetch 的域名列表等；
監聽 APP 啟動、網路變化、定位城市變化、配置文件變化、前後台切換等事件，在獨立的線程中執行 DNS Prefetch 的邏輯；
如果開關打開，且上次 prefetch 的時間距離當前的時間大於閾值，則刷新 DNS，粗發操作系統 /VM 層的緩存功能。
DNS Prefetch 上線後我們海外域名解析時間 RT90 從 350ms 下降至 250ms 左右。
5. 長連接
HTTP 請求重度依賴 DNS，DNS 劫持、移動端網路不穩定導致建連失敗以及公網鏈路質量差等因素導致移動端的網路成功率一直不高。
HTTP 2.0 可以通過 SSE、WebSocket 等方式與服務端保持長連接，並且可以做到請求多路復用，但 HTTP 2.0 對運維、前端、後端的改造成本非常高。
基於此背景公司架構組推出了 Shark，一種 「代理長連接」 的模式，主要用於解決移動設備網路通信質量差的問題。
Shark 在國內和境外部署了多個接入點，類似於 CDN 的就近訪問，用戶可以就近連接到 Shark 節點；
Shark 各節點的 ip 會在 APP 啟動時載入到設備，客戶端通過 「跑馬測試」（ping 各節點）的方式選擇最優節點，建立並保持 TCP 長連接；
Shark 節點和 IDC 之間通過內網專線打通，從而保證了網路鏈路的質量；
客戶端 Shark 的網路層會攔截 APP 內的 HTTP 請求，通過特定的協議格式將 HTTP 請求信息轉化成 TCP 包傳到 Shark 節點，Shark 節點再將 TCP 請求 「還原」 成 HTTP，再通過專線請求後端服務；
當 Shark 通道出問題的時候，可以 failover 到普通的 HTTP 模式，從而實現高可用。
這種 「代理長連接」 的模式，對後端業務是無感知的，業務無需做任何改造。另外也巧妙的繞開了 DNS、公網質量差等問題，極大的提升了 native api 請求的網路成功率。
5.1 Ajax 接長連
目前美團點評大部分的 APP 都接入了 Shark SDK 基礎網路庫，Native API（我們內部叫 Mobile API，MAPI）的網路請求由 Shark SDK 統一解決，使用的是自定義的序列化方式（內部稱 DPObject，比 json 效率高）。
但對於 H5 頁面中的 Ajax 請求，是沒法直接享受到 Shark 帶來的 「福利」 的。先看一下 Hybrid 模式下一次 Ajax 請求的過程：
上圖可以看出，一次普通的 Ajax 請求會由 WebView 的內置瀏覽器內核來發送接受請求，一般是 json 格式的數據，和 PC 瀏覽器的一次 HTTP 請求過程差別不大，都是要經過 DNS、TCP 建連以及要面對公網鏈路差的問題。
另外 Ajax 請求服務復用 TCP 連接，意味著每次請求都要重新建連。有了 MAPI 的經驗，我們很容易想到，能否像 MAPI 一樣利用長連通道來提升性能呢？
一種方式是在 WebView 中攔截頁面的 HTTP 請求，在容器層做請求代理並處理序列化反序列化等事情。
這種方式對業務比較友好，業務方几乎不需要做什麼事情。但 WKWebView 的限制比較多，所以方案一目前很難推行。
另一種方式是通過 JsBridge 來實現，缺點是對業務侵入性較高，業務方需要手動控制橋 API 的調用，一期我們選擇的是 「較笨拙」 的方案二。
6. 網路鏈路優化6.1 用戶境外訪問
Ajax 接長連解決了 App 內的 H5 場景，而對於 App 外的入口場景，如 M 站、微信朋友圈分享等，我們沒法使用到 Shark 長連接，跨網跨國訪問的問題依然存在。
這種情況下我們目前的優化主要是 「利用專線」：
我們的後台應用和數據部署在上海機房，在香港機房內部署了一組 SLB（七層負載均衡，基於 tenginx 實現）；
利用專線連上海和香港的機房，解決 GFW 攔截過濾、跨境網路訪問及公網鏈路差的問題；
當用戶在境外訪問時，智能 DNS 會解析出香港機房的 ip，請求經香港 slb 走專線轉發到境內伺服器；而當用戶在境外訪問時，則直接請求到上海的機房。
6.2 境外直連對接
另一個場景是，我們和很多的境外供應商有直連對接，通過 HTTPClient 的方式後端發起調用對方的 Open API 介面，這種場景優化前介面延遲及網路成功率都非常不理想（很多和國外對接的業務應該都遇到過類似的問題）。
我們的優化方案是：在香港部署一個正向代理 squid，請求先由內網專線轉發到香港的 squid 伺服器，再從香港機房的網路出口出去。
以與香港迪士尼的對接為例，優化前的 api 介面 rt95：9s+（迪士尼介面傳輸的數據非常多），優化後降到 2.3s，效果非常明顯。
6.3 CDN 動態加速
除了專線方案，我們還測試 CDN 動態加速。
CDN 不僅可以用來對靜態資源做緩存加速，也可以對動態數據介面起加速作用，原理如下：
用戶請求耗時 = 用戶和邊緣交互的時間 + 1*RTT（邊緣到源站） + 源站處理時間。
HTTP 請求中，建連是個非常耗時的事，普通 HTTP 請求 TCP 3 次握手要消耗 2 個 RTT 時間。
如果用戶和伺服器位置很遠，比方說用戶在美國，服務在中國，請求走海底光纜的話一次 RTT 理論值是 150ms 左右（光波信號傳輸速度結合物理距離計算得出），實際肯定大於理論值。
CDN 動態加速主要在以下幾方面起到優化效果：
用戶與伺服器的建連改成與 CDN 邊緣節點建連（就近訪問），縮短了建連時間，同時也提升了建連成功率；
CDN 與源站之間通信相比公網網路鏈路質量有保證；
CDN 節點和源站的連接可復用。
我們實測下來 CDN 動態加速在部分國家和地區有明顯的加速效果，但整體的效果不夠明顯，所以最終未投入規模使用。
三、前端優化
前端優化我們主要做的幾件事情：
前後端分離；
圖片優化；
域名收斂、減少請求；
離線化；
首屏 node 後端同構渲染。
1. 前後端分離
在之前的項目中，頁面是由 Java 後端項目中通過 FTL 模板引擎拼裝，前端團隊會維護另外一個前端的項目，存放相應的 CSS 和 JS 文件，最後通過公司內部的 Cortex 系統打包發布。
這個流程的問題在於前端對於整個頁面入口沒有控制力，需要依賴後端的 FTL 拼裝，頁面的內容需要更改時，前後端同學就要反覆溝通協調，整體效率比較差，容易出錯，也不方便實現前端相關的優化。
前後端分離的關鍵點在於前端擁有完整獨立的開發、測試、部署的流程，與後端完全分離。
我們把頁面的組裝完全放置到了前端項目，後端只提供 Ajax 的介面用於獲取和提交數據。
前端頁面完全靜態化，構建完畢之後連同相應的靜態資源通過 CI 直接發布到 CDN。這樣的好處有：
前後端同學的開發工作解耦，只需要約定好 API，兩邊即可並行開發；
後端 API 可以做到多端復用，比如 PC、H5、M 站、小程序等；
前端主文檔 HTML 頁面可以利用 CDN 加速。
2. 圖片優化
在一些重體驗的網頁上，圖片資源的佔比通常較大，一些高清大圖動則幾十上百 K 大小。 針對圖片這塊我們主要做了以下幾點優化：
2.1 圖片尺寸按屏幕大小自適應
原先我們圖片的尺寸都是由後端控制，由服務在代碼中寫死下發給前端，這樣帶來問題是：
不同設備不同大小的屏幕上使用的圖片尺寸一樣，無法滿足所有設備；
一些沒經驗的開發同學經常亂用尺寸，比如我們 POI 列表頁的商戶頭圖只需要 200 200 就夠了，而新手工程師可能使用的是 800 800 的圖片，導致頁面載入慢、用戶流量白白被浪費且客戶端還需要做圖片壓縮剪裁。
美團雲的圖片服務提供了實時剪裁功能，後端在下發圖片 URL 時不需要指定尺寸，由客戶端根據屏幕尺寸做自適應計算，這樣可保證每台設備上的圖片都 「剛好合適」。
2.2 CDN 加速
前面 CDN 優化章節已介紹，通過接入境外 CDN 服務商及 CDN 預熱的方式做 CDN 加速。
2.3 圖片壓縮
境外業務內部已在全面使用 WebP，經測試 WebP 格式能夠優化圖片大小 25-50%，清晰度基本沒有影響。
2.4 懶載入
圖片資源通常比較大，選用懶載入可有效縮短頁面可交互時間。
3. 域名收斂、減少請求
域名過多會帶來以下問題：
DNS 解析成本高；
CDN 加速一般都是按域名來做配置，過多的域名無形增加了 CDN 接入的成本；
瀏覽器的並發載入數限制，瀏覽器對單域名的並發度是有限的，超過限制的請求需要等待串列載入，頁面載入速度會變慢。
我們做了以下幾件事:
去掉一些直接引入的第三方腳本，將腳本直接打包到我們的代碼中（可以利用 CDN）；
所有靜態資源共用一個域名；
將一些尺寸較小的腳本和 CSS 構建過程中內聯到主文檔中。
通過域名收斂 / 減少請求數，我們商品詳情頁的頁面請求數從 8 個減少到 4 個、域名數也減少一半，頁面完全載入時間下降了約 1000ms。
4. 離線化
離線化可以減少網路請求，加速頁面載入速度。另外當用戶網路不穩定或斷網時也可以訪問已被緩存的頁面和資源，我們先後使用了 2 種離線化方案：
1）AppCache（HTML Application Cache API）
在前端項目構建流程中，通過分析頁面資源依賴關係，自動生成資源 manifest 文件，這樣就能夠確保頁面及資源發生變更時，manifest 文件內容同步更新。
當瀏覽器監測到 manifest 文件有更新時，會自動重新下載 manifest 裡面的文件。AppCache 的一個缺點是緩存文件會越來越多，緩存不容易清理。
AppCache 未來會逐步被 Service Worker 所取代，無論從靈活性還是可擴展性而言，SW 都更勝一籌。
2）離線包框架
目前在使用的是公司平台自研的離線包框架，相比於 AppCache，離線包框架在資源更新，離線配置，內存管理等方面都做了很大的改善。
另外 AppCache 對於用戶第一次載入頁面是沒有加速效果的，因為只有第一次訪問之後才會把資源緩存下來。
而離線包框架則可以做到真正的預載入，它會監聽 APP 正常啟動事件，當 APP 啟動後即可開始載入更新離線資源。
5. Node 服務端同構渲染
同構渲染，主要用來解決首屏載入的問題。相比於服務端，移動端設備的性能較弱，頁面在服務端渲染比在前端渲染會快很多。
配合上 Ajax 長連等網路優化技術，node 同構首屏後端渲染提升了首屏載入速度。
node 同構直出和一開始的 java freemark 後端渲染最大的區別在於：node 項目可由前端同學來維護，用的是前端工程師熟悉的 js 語言。
另外前端生態較好，React、Vue 等框架都提高了豐富的渲染模板供前端工程師選擇。
四、後端優化
後端優化的思路相對比較比較通用，和境外業務的特點關係性並不大，穩重的前言部分 「影響性能的因素」 章節有簡單描述。
本文將不對各種後端優化手段做詳細介紹 , 只挑幾件我們做過的事情做下簡單介紹。
1. 硬體升級
硬體問題對性能的影響不容忽視，早期的時候，我們的一個 DB 集群經常有慢 SQL 報警，業務排查下來發現 SQL 都很簡單，該做的索引優化也都做了。
後來 DBA 同學幫忙定位到問題是硬體過舊導致，將機械硬碟升級成固態硬碟之後報警立馬消失了，效果立竿見影 !
2. 緩存化
緩存可以稱的上是性能優化的利器，使用緩存時需要考慮緩存命中率、緩存更新、數據一致性、緩存穿透及雪崩、value 過大等問題，可以通過 mutiGet 將多次請求合併一次、非同步訪問等方式來提升緩存讀取的性能。
3. 邏輯優化
舉個例子，我們的商家系統有一個商家導出歷史訂單的功能，介面經常超時。排查下來是由於功能上默認是導出商家的全部歷史訂單，數據量過大導致。
而實際業務上幾個月之前已完成的訂單對商家來說並沒有什麼意義，如果是要看統計數據我們有專門的統計功能。後來和 PM 商量後在導出時增加了時間段選擇項，默認只會導出最近 3 個月的訂單，超時問題順利解決。
4. 服務化
我們做服務化最基礎的是按業務做服務拆分，避免跨業務間的互相影響，數據和服務同時拆分。同一個業務內部我們還按計算密集型 /IO 密集型的服務拆分、C 端 /B 端服務拆分、核心 / 非核心服務拆分、高頻服務單獨部署等原則做拆分。
5. 非同步化
非同步化可以利用線程池、消息隊列等方式實現。使用線程池的時候一定要注意核心參數的設置，可以通過監控工具去觀測實際創建、活躍、空閑的線程數，結合 CPU、內存的使用率情況來做線程池調優。
另一種是通過 NIO 實現非同步化，一切網路 IO 皆可非同步：RPC 框架、Servlet3.0 提供的非同步技術、Apache HttpAsyncClient、緩存非同步介面等等。
6. 搜索引擎
複雜查詢以及一些聚合計算不適合在資料庫中做，可以利用搜索引擎來實現，另外搜索引擎還可以幫我們很好的解決跨庫、跨數據源檢索的場景。
7. 服務架構
美團點評有上海、北京兩地都有機房，以商品服務為例，我們的商品服務會同時被上海和北京的兩側的應用依賴和調用。
一開始我們的服務只部署在上海機房，由於上海、北京兩地機房距離間隔較遠（北京-上海專線 ping 延遲 30ms 左右），當北京的應用調服務時就會有較高的延遲，為此我們做了如下的緩存雙集群加異地部署：
商品靜態信息全緩存，緩存未命中時再查 DB；
DB 以主從的方式部署，北京機房也部署了一套從庫；
緩存數據更新使用 DataBus，基於 binglog 數據同步的方式，保障 DB 和 Redis 數據的 「准實時」 同步；
服務、緩存、DB 均兩地部署，調用方就近訪問（RPC、cache、dal 等基礎組件支持就近路由）；
緩存更新利用 Client 的雙寫模式，Databus 監聽到數據更新後，消費程序會往兩個緩存集群同時寫入。
通過這種雙緩存加異地部署的 「異地多活」 模式（實際是異地只讀），提升了我們服務在跨地域場景下調用時的性能。
五、總結
結合境外業務特點，本文從網路優化、前端優化、後端優化幾個角度介紹了境外業務在性能優化上的一些實踐，重點篇幅放在了網路優化部分。
性能優化是一個系統性工程，需要 RD、FE、SRE 的配合協作才能做好。
得益於公司強大的高性能前端框架、BGP 網路、高性能應用組件、雲平台等基礎設施，以及在靠譜的運維保障 SRE 團隊、基礎架構團隊以及平台團隊支持下，我們境外業務的性能優化取得了階段性的成果，後續還要繼續努力！
TAG:GitChat技術雜談 |