1.1 分布式系統的架構演變過程

互聯網悄然改變了世界，改變了人們對事務的認知，縮短了人與人之間的距離。無論你是否愿意承認，互聯網已經完全影響并融入我們的生活中。筆者的母親從來就不是一個喜歡追趕潮流的人，但她早已智能設備從不離身，每天早上起床的第一件事情就是拿起智能手機，刷刷朋友圈、看看時事政治、做回“吃瓜群眾”八卦下娛樂新聞，甚至衣食住行也幾乎都是通過互聯網這個載體一鍵搞定的，如圖1-1所示。既然互聯網能夠使我們的生活變得更美好，那就請張開雙臂緊緊擁抱它。

擁有互聯網的夜晚是明亮的，當然為這寂靜夜空點燃光明的正是聚集在各個互聯網企業內部的技術團隊，正是這些家伙晝夜顛倒的辛勤付出（無數的通宵、會議、功能迭代、體驗優化、架構升級），才換來今日互聯網的光彩奪目。很多電商網站為了吸引用戶流量，往往都會以極低的價格作為誘餌，但是當促銷活動正式開始后，峰值流量卻遠遠超出了系統所能夠承受的處理能力，這必然只會產生一種結果——宕機。如何幫助企業順利走出困境，打造真正具備高性能、高可用、易擴展、可伸縮，以及安全的網站架構才是架構師、技術大牛們應該重點思考的問題和責任，哪怕是系統宕機，也要盡最大努力做到“死而不僵”，用技術支撐業務的野蠻生長，活下去才會有更美好的明天。

通常來說，網站由小變大的過程，幾乎都需要經歷單機架構、集群架構、分布式架構、分布式多活數據中心架構。伴隨著業務系統架構一同演變的還有各種外圍系統和存儲系統，比如關系數據庫的分庫分表改造、從本地緩存過渡到分布式緩存等。當系統架構演變到一定階段且逐漸趨向于穩定和成熟后，架構師們需要對技術細節追本溯源，如果現有的技術或者框架不能有效滿足業務需要，就需要從“拿來主義”的消費者角色轉變為自行研發的生產者角色。當然，在這條技術之路離你和你所在的企業還很遙遠的時候，盡管未雨綢繆利大于弊，但這卻并不是你現階段的工作重點。在此大家需要注意，對技術由衷的熱愛和癡迷本身并沒有什么不對，但是千萬不能過于沉醉而選擇刻意忽略掉業務，任何技術的初衷都是更好地服務業務，一旦脫離業務，技術必然會失去原有的價值和意義，切勿舍本逐末。

1.1.1 單機架構

任何一個網站在上線初期幾乎都不可能立馬就擁有龐大的用戶流量和海量數據，都是在不停的試錯過程中一步一步演變其自身架構，滿足其自身業務。所以我們常說，互聯網領域幾乎沒有哪一個網站天生就是大型網站，因為往往系統做大與業務做大是呈正比的，大型網站都是從小型網站逐漸演變過來的，而不是被刻意設計出來的。試想一下，如果業務不見起色，一味地追求大型網站架構又有何意義呢？

對于一個剛上線的項目，我們往往會將WebServer、文件服務器和數據庫全都部署在同一臺物理服務器上，并將所有的業務邏輯全都耦合在同一個單體應用中，這樣做的好處只有一個——省錢，如圖1-2所示。

資金緊張且用戶流量相對較小的網站，采用這樣的架構進行部署確實非常實惠，畢竟用戶流量上不去，自然就沒有必要考慮更多的問題，哪怕是系統宕機，影響范圍也不大。當然，一旦業務開始加速發展，用戶逐漸增多，系統瓶頸便會開始暴露，這時架構師們就可以考慮對現有網站架構做出以下四點調整：

● 獨立部署，避免不同的系統相互之間爭奪共享資源（比如CPU、內存、磁盤等）；

● WebServer集群，提高容錯性；

● 部署分布式緩存系統，使查詢操作盡可能在緩存命中；

● 數據庫實施讀/寫分離改造，實現HA（High Availability，高可用性）架構。

1.1.2 集群架構

一旦用戶體量增加，并發流量上來后，為了讓用戶擁有更好的操作體驗，我們不得不對單機系統架構做出調整和優化，因此在這個階段主要需要解決的問題就是提升業務系統的并行處理能力，降低單機系統負載，以便支撐更多用戶訪問。

集群（Cluster）技術可以將多臺獨立的服務器通過網絡相互連接組合起來，形成一個有效的整體對外提供服務，使用集群的意義就在于其目標收益遠高于所付出的實際成本和代價。互聯網領域存在一個共識，那就是當一臺服務器的處理能力接近或已超出其容量上限時，不要企圖更換一臺性能更強勁的服務器，通常的做法是采用集群技術，通過增加新的服務器來分散并發訪問流量，1臺不夠就擴到2臺，2臺不夠就擴到4臺，只要業務系統能夠隨意支持服務器的橫向擴容，那么從理論上來說就應該無懼任何挑戰，從而實現可伸縮性和高可用架構。

如圖1-3所示，對于無狀態的WebServer節點來說，通常我們會使用Nginx來實現負載均衡調度，但是在線上環境中，Nginx也應該具備高可用性，這可以依靠DNS輪詢來實現，或者如果你所在企業使用的是云主機，則可以使用云服務商提供的SLB服務。總之，在集群環境中，WebServer節點的數量越多，并行處理能力和容錯性就越強，哪怕其中某些節點因為種種原因宕機，也不會導致系統不可用。

伴隨著WebServer集群改造的還有分布式緩存和數據庫，對于查詢操作我們應當盡可能在緩存中命中，從而降低數據庫的負載壓力。盡管緩存技術可以分擔數據庫的大部分查詢壓力，但是寫入操作和無法在緩存命中的數據仍然需要頻繁地對數據庫進行讀/寫操作，因此對數據庫實施讀/寫分離改造也迫在眉睫。

業務發展到一定階段后必然會變得更加復雜，用戶規模也會線性上升，這時架構師就可以考慮對現有網站架構做出以下兩點調整：

● 利用CDN加速系統響應；

● 業務垂直化，降低耦合，從而實現分而治之的管理。

由于中國的網絡環境相對比較復雜，跨網絡、跨地域的用戶訪問網站時，速度有較大差別，因此，當用戶流量增大之后，我們需要考慮將系統中的一些靜態資源數據（如圖片、音頻、視頻、腳本文件及HTML網頁等）緩存在CDN節點上，因為CDN正在變得越來越廉價，如圖1-4所示。由于用戶的請求并不會直接落到企業的數據中心，而是請求到離用戶最近的ISP（Internet Service Provider，互聯網服務提供商）上，因此可以大幅提升系統整體的響應速度。

1.1.3 垂直拆分業務子系統

盡管業務系統可以通過集群技術來提升并行處理能力和實現高可用架構，但是一般到了這個階段，不僅用戶規模暴增，業務需求也變得更加復雜。在單體應用中，業務邏輯全部耦合在一起，并且部署在同一個WebServer中，這必然會導致系統中不同業務之間的耦合過于緊密，除了擴展和維護困難，在生產環境中極有可能會因為某個業務功能不可用而影響系統整體服務不可用，因此在這個階段主要需要解決的問題就是降低業務耦合，實現高內聚低耦合，提升系統容錯性，避免牽一發而動全身的風險。

下面為大家分享筆者親身經歷過的一次真實生產事故。

在一次限時搶購活動中，我們預計零點開搶時的那一撥峰值流量肯定會遠高于平時，因此在幾天前運維部門的同學就提前擴容了上百臺服務器來應對“雙11”。在活動開始前，大家摩拳擦掌，屏住呼吸緊盯著電腦屏幕“觀賞”流量監控曲線圖時，“悲劇”發生了，隨著倒數結束，活動正式開始，流量曲線居然沒有太大的起伏，這讓當時在場的小伙伴們瞬間懵掉了，緊急排查故障后發現，前端App在每一次業務請求提交之前都會先將客戶端埋點數據上報到專門用于數據采集的WebServer上（后期需要利用大數據平臺對埋點數據進行一些用戶行為的實時/離線分析），然后再請求到業務系統上執行邏輯處理。但因為我們的疏忽，負責數據采集的WebServer和核心業務系統使用的是同一個Nginx服務器進行請求轉發，由于沒有對數據采集的機器做擴容，導致Nginx日志中出現大量的請求超時異常，從而嚴重影響了核心業務的正常運轉。據不完全統計，這次活動至少導致了2/3的用戶無法正常訪問，而那些“僥幸”正常訪問并下單的用戶，也因為在指定時間內無法順利完成支付而導致大量的訂單回流。這次慘痛的教訓說明，細節決定成敗的重要性不言而喻。當然，既然踩坑了，吸取經驗教訓避免悲劇重現才是最重要的。

大家一定要具備大系統小做的意識，所謂拆系統其實指的就是業務垂直化，簡而言之，架構師可以根據系統業務功能的不同拆分出多個業務模塊（一般大型電商網站都會拆分出首頁、用戶、搜索、廣告、購物、訂單、商品、收益結算等子系統），再由不同的業務團隊負責承建，分而治之，獨立部署，如圖1-5所示。

在此大家需要注意，拆分粒度越細，耦合越小，容錯性越好，每個業務子系統的職責就越清晰。但是如果拆分粒度過細，維護成本將是一個不小的挑戰。對業務系統完成拆分后，就意味著系統已經過渡到分布式系統了，這也為企業實施服務化改造和數據庫分庫分表改造提前做好了準備。關于數據庫分庫分表的相關知識點，大家可以直接閱讀本書的第5章。

1.1.4 服務化架構演進

在大部分互聯網企業的系統架構演變過程中，不得不提到的就是服務化改造，那么究竟為什么要實現服務化架構呢？

隨著用戶規模逐漸龐大，需求更加復雜，我們一定會對耦合在一個Web容器中的單體應用進行垂直化改造，以業務功能為維度拆分出多個子系統，這樣做就是為了能夠更清晰地規劃和體現出每個子系統的職責，降低業務耦合，以及提升容錯性。但是在多元化的業務需求下，子系統中一定會存在較多的共享業務，這些共享業務肯定會被重復建設，產生較多的冗余業務代碼。而且，業務系統中數據庫連接之類的底層資源必然會限制業務系統所允許橫擴的節點數量，因為在橫擴過程中，連接數是機器數的平方。除了共享業務重復建設和資源連接受限，還有一個不容忽視的問題，當業務做大時，技術團隊的人員規模也開始膨脹，太多人共同維護一個系統肯定會壞事，尤其是那些“手潮”的同學，經常會導致版本沖突。因此為了避免這些問題，服務化架構（Service-Oriented Architecture，SOA）改造刻不容緩，如圖1-6所示。

當然，如果你現階段并不滿足上述任何一個條件，筆者其實是不建議實施服務化改造的，因為這顯然會提升系統的復雜度和維護成本，甚至還需要提前規劃一些服務化場景下才需要考慮的技術難題，比如服務治理、分布式事務等。

1.1.5 服務化與微服務架構的區別

實施服務化改造后，原本耦合在WebServer中的業務邏輯被剝離，因此這些子系統從某種意義上來說僅僅只是充當著控制層（Controller）的角色，由于無須處理任何復雜的業務邏輯，因此吞吐量相對會有所提升，但是業務的邏輯處理由獨立部署的服務負責，所以架構師需要認真思考如何有效提升整體的服務質量。近幾年，微服務這個概念被炒得火熱，就連Spring也借機推出了Spring Cloud服務治理平臺。那么究竟什么是微服務？它和服務化之間的區別在哪？

其實，當筆者第一次聽說微服務這個概念的時候，盡管查閱了非常多的文獻資料，卻仍然不清楚它和服務化架構之間究竟有何區別，但從本質上來說，微服務和服務化這2個概念完全就是一回事，所謂的微服務架構，從宏觀上來看，無非就是細化了服務拆分過程中的粒度，粒度越細，業務耦合越小，容錯性就越好，并且后期擴展也會越容易。

那么服務到底應該如何拆分才稱得上“微服務”呢？通常來說，筆者建議大家以子系統為維度來進行拆分，這樣的拆分粒度適中，所付出的成本與實際收益會相對等價，否則粒度過細不僅會提升維護成本，還會影響排查問題時的效率，更重要的是，業務開發同學很難梳理清楚服務之間的依賴關系。

1.1.6 集群與分布式的區別

截至目前，筆者已經對單機架構、集群架構，以及分布式架構進行了深入介紹，相信大家對此已經有了一定的認識。在本書的第一版上市后，筆者曾收到許多讀者來信，其中不乏有一些初入職場的同學容易混淆集群和分布式二者概念，在此筆者就簡單對其進行闡述，以便讓大家能夠更好地理解。

集群是指將多臺服務器集中在一起，目的是實現同一業務；而分布式是指將不同的業務分布在不同的地方，目的是實現不同的業務；前者是串聯工作，而后者是并聯工作。在此大家需要注意，分布式架構中的每一個子節點都允許構成一個集群，但集群卻并不一定就是分布式的。

再舉一個貼近生活的例子。假設你廚藝高超，聲名遠播，周末盛情邀約了幾個小伙伴來你家聚餐，你一個人負責買菜、切菜、炒菜、上菜，這便是單機架構；而某一天更多朋友來你家做客時，你發現似乎有些力不從心，這時你需要幾個人一起來協作幫忙，以便提升效率，這就是集群架構；假設你家大業大，有上百位朋友都相約你家吃飯時，你會需要更多的人來協作幫忙，并且相互之間需要明確職責分工，A組負責買菜，B組負責洗菜，C組負責炒菜，D組負責上菜，這就是分布式+集群架構。

1.1.7 前后端分離架構演進

前后端分離架構近兩年也是被社區炒得熱火朝天，無論是否是互聯網企業，幾乎都在大刀闊斧地實施前后端分離改造，包括一些大型技術峰會上也開設有諸多關于前后端分離架構的專題分享，因此，筆者將所在企業實施前后端分離改造的一些實踐經驗分享給大家。

我們的業務現狀包含H5、APP，PC-WEB 3個端。根據端的不同請求會落到不同的域名上，再由對應的接入層來負責請求的接入，WebServer充當了聚合層，負責調用下游服務執行具體的業務邏輯處理后響應請求結果，同時還耦合有前端代碼。

如圖1-7所示，早期WebServer我們是以域名為維度來進行劃分的，盡管這樣的設計并不合理，但這確實屬于歷史遺留問題，最初我們只有H5端，后來為了支撐業務的快速發展，PC-WEB和APP端是由相應的開發人員直接拷貝現有H5的WebServer代碼，并在此基礎之上快速適配修改上線的。隨著時間的逐步推移，業務需求開始變得越發復雜，所積壓的問題也越來越多，最終產生了如下4個主要痛點：

● 下游RPC接口發生變化時，上游依賴這個接口的各個端的WebServer都需要修改代碼；

● 各個端的WebServer中存在大量的代碼冗余；

● 前后端職責模糊，前端需要關心后端語法，后端需要維護模板代碼；

● 前后端聯調成本高。

其實各個端WebServer中的邏輯大致都是相似的，只存在極少數的不同（比如：數據的返回格式存在區別、入參存在區別、展示交互存在區別，以及調用下游服務的數量存在區別等），因此我們開始嘗試使用Node.js技術實施前后端分離改造來解決上述提出的諸多痛點，如圖1-8所示。

首先需要改造的是WebServer的拆分問題，不再繼續以域名為維度進行拆分，而是以子系統維度來進行拆分，這樣便可以有效解決大量代碼拷貝和冗余等問題，最終只需保留一套代碼即可。然后將耦合在WebServer中的前端模板代碼前移至Node.js中，由Node.js充當中間層來負責具體的服務端渲染和數據二次加工等任務，這樣不僅減少了耦合，同時還降低了前后端聯調成本（前端開發人員與后端開發人員約定好數據的返回格式后，不再需要等待后端一起聯調，可以自行調用Mock服務來進行驗證），以及維護成本。總之前后端分離架構在當下是趨勢，但是否有必要進行改造則還需要結合自身業務而定。

1.1.8 API網關服務

如果沒有Spring Cloud的出現，可能大部分互聯網企業至今都只能夠選擇基于Dubbo來落地服務化架構，但如今我們的武器庫中確實又多了一個非常不錯的選擇，而且基于Spring Cloud的強大生態，開發人員能夠更加專注于自身業務邏輯。關于Dubbo和Spring Cloud孰強孰弱的問題，則不在本書的討論范圍之內，不過筆者還是要闡述一個觀點，在大部分情況下，框架之間細微的性能差異并不是影響系統性能的關鍵，花心思去優化我們的業務代碼似乎更有意義，比如業務上存在一些耗時較長的操作，那么無論是使用Dubbo還是Spring Cloud結果都是一樣的。

如今API網關已經成為微服務架構體系中的標準，簡單來說，網關層作為整個系統的入口，所有的前端請求都需要通過它來訪問后端服務，并由它統一負責處理一些公共邏輯，比如：鑒權、流控、日志記錄、安全防護、負載均衡、灰度發布等。如果是基于Spring Cloud的，那么開箱即用的Zuul組件則用于支持開發人員快速構建一個健壯的、高性能的，且具備良好伸縮性的API網關服務。遺憾的是，由于存在架構上的差異，Dubbo目前并沒有為開發人員提供成熟、易用的網關服務，因此我們通常會在服務上游構建一層WebServer用以滿足如下3個需求：

● 將外部的HTTP協議適配為內部的二進制協議；

● 聚合操作；

● 集成一些公共邏輯。

大家思考一個問題，在不引入API網關的情況下，WebServer其實也能夠實現API網關能做的所有事情，那么我們為何還需要大費周章地引入網關層呢？事實上，是否需要引入網關層是由業務復雜度來決定的，如果業務不多，且相對簡單的情況下，那么網關層就不是剛需，但如果業務眾多和復雜，在沒有引入網關層的情況下，那些耦合在WebServer中的公共邏輯的維護成本就會變得非常高，甚至一個小功能的升級，都將耗費大量的時間和人力成本，但如果引入了API網關，事情就會變得簡單起來，因為網關邏輯和業務邏輯是完全獨立的，架構團隊只需要統一對網關層進行升級即可。

筆者所在企業也是使用Dubbo來落地服務化架構的，業務初期我們也并未引入API網關，由WebServer來負責處理網關業務，但隨著業務發展到一定階段后，WebServer變得越來越重，架構團隊不得不考慮引入網關層來解決現有痛點。我們最早的解決方案是將接入層Nginx改造為網關層，但發現Lua腳本的維護成本實和實現難度較大，因此，后續我們選擇了將一些流控、灰度發布、安全防護，以及日志記錄等一些相對簡單的網關邏輯放在接入層，盡可能將流量擋在系統上游，而對于一些復雜的網關邏輯，則單獨引入了一層API網關，替換掉原本的WebServer，將聚合操作下潛至服務層，API網關通過優化后的泛化調用方式調用下游目標服務，如圖1-9所示。

關于如何在API網關中實現流控邏輯，大家可以直接閱讀本書的3.2.3小節。而本小節將會為大家介紹如何在API網關中實施灰度發布方案。在正式開始為大家講解什么是灰度發布之前，我先為大家講個故事。據史書記載，在中國古代的東漢末年三國時期，曹操為了彌補軍餉的不足，專門設立了發丘中郎將，摸金校尉等軍銜，專司盜墓取財、以貼補軍餉之用，由此開啟了倒斗的先例。據隋代醫家巢元方撰寫的《諸病源候論》一書記載“入井冢墓毒瓦斯候”，因此后來的盜墓者們在每次下墓前，都會先將幾只金絲雀放至鳥籠中，然后將鳥籠系上繩子后投放至墓中。由于金絲雀具備特殊的呼吸系統結構，使得它們天生就對空氣中含有的有害氣體十分敏感，因此，如果金絲雀被投放至墓中因為暈倒而不再鳴叫，則表示墓中含有較高濃度的有害氣體，不宜下墓，反之，就表示相對安全。這就是灰度發布（也被稱之為金絲雀發布）的起源。

隨著敏捷開發的日益普及，互聯網企業的項目發布也隨之變得越發頻繁，由于每次新版本的發布都可能伴隨著諸多不可控風險，因此我們需要一種發布機制，能夠幫助企業降低風險的影響范圍。灰度發布，簡單來說，就是通過一系列的規則和策略，先將一小部分的用戶作為“金絲雀”，讓其請求路由到新版本應用上進行觀察，待運行正常后，再逐步導流更多的用戶到灰度環境中。

當然，如果初期灰度環境的機器數量不多，為了避免系統容量被持續遞增的用戶流量撐爆而產生宕機，我們還需要實時擴容灰度環境的機器數量，以便支撐更多用戶的訪問。當所有的用戶都順利切換到新版本應用上后，再停機之前的老版本應用，即可完成灰度發布。

在此大家需要注意，就算灰度期新版本應用存在問題，我們也能夠迅速將流量切換回老版本上。其實，實施灰度發布的目的就在于試錯，盡可能控制和縮小問題的影響范圍。從產品的角度來看，灰度發布的好處是，能夠通過收集用戶的使用反饋來更好地完善和改進當前產品。然而從研發的角度來看，從預發布環境到灰度環境，都是在不停地試錯，以確保最終上線的穩定，哪怕灰度期出現問題，也能夠做到快速止損，縮小問題的影響范圍，從而保證絕大多數用戶可用。

既然API網關作為整個系統的入口，那么在API網關中嵌入灰度邏輯就顯得順理成章，并且對于業務系統而言也不存在任何侵入性。剛才也強調過，我們的API網關物理上雖然是由Nginx和獨立的Gateway服務構成的，但其邏輯上仍然是作為同一個整體對外提供服務，對于灰度發布這種相對簡單的網關邏輯，我們選擇了在Nginx中嵌入Lua腳本來實現。

簡而言之，如嵌入在Nginx中的Lua腳本會首先從Header中獲取出Token并解析出用戶的UserId，再請求Redis驗證當前的UserId是否包含在白名單中，只有那些包含在白名單中的用戶，才允許訪問灰度環境中的新版本應用，如圖1-10所示。果是以白名單作為灰度策略的，那么當用戶發起HTTP請求后，

對于網關的技術選型，目前市面上開源的網關實現方案有很多選擇，比如基于Nginx的KONG、API Umbrella，基于Node.js的apigee、StrongLoop等。總之，網關層的引入并非是必需的，但是業務越復雜，網關的好處就會越明顯。

1.1.9 分布式多活數據中心架構演進

出于對災備、高可用等方面的考慮，稍微有點實力的企業都會選擇構建多個數據中心，由主數據中心負責核心業務的正常運轉，其他數據中心負責數據備份，及承擔一些邊緣業務。假設主數據中心發生重大災難，災備數據中心可以有效接管，從而減少對用戶的影響。傳統企業，比如電信、銀行一類，大多會構建“兩地三中心”架構，即：生產數據中心、同城災備中心，以及異地災備中心，如圖1-11所示。

“兩地三中心”架構盡管具備較好的容災和容錯性，但存在一個弊端，那就是會產生大量的資源浪費。因為多數據中心之間僅僅只是主/備關系，只有當災難真正不幸降臨時，災備數據中心才能派上用場和體現出它的價值，平時幾乎都是閑置狀態，這對于那些資金緊張或是互聯網企業來說，幾乎是難以接受的，前者出于資金壓力，而后者卻因為需要面對高并發、大流量，以及海量的數據的洗禮，需要充分地利用資源，所以空閑出這么多機器絕對是不能忍受的。目前越來越多的企業，正在逐步從原有的災備模式開始過渡到“分布式多活數據中心（Distributed Active/Active Data Centers）”的建設上，如圖1-12所示。

分布式多活數據中心聽上去挺高大上的，實際上就是將2個或者2個以上的數據中心同時并行對外提供服務，實現了對資源的充分利用，避免了資源利用率低下等諸多問題。當然多活數據中心的建設是非常復雜的，我們在實施分布式多活數據中心的建設時，主要需要面對如下3個難題：

● 多數據中心之間需要打通內網專線通道；

● RPC調用需要做到就近調用；

● 數據同步問題。

關于RPC就近調用的問題，大家可以直接閱讀本章的1.2.7小節。筆者所在企業的2個數據中心分布情況還是比較復雜的，一個在華東，一個在華南，首先需要打通內網專線通道，提高網絡傳輸速度盡可能降低延遲，正常情況下，運維同學給出的理論延遲率可以控制在20ms內。存儲層的數據同步既是核心同時也是難點，因為數據的實時性、一致性、沖突等問題在某些特定場景下是存在矛盾且無解的，所以分布式多活的建設需要根據實際的業務場景而定，業界幾乎并沒有完美的異地多活方案，也并非所有的業務都能夠實現分布式多活，但我們可以采取多種有效的手段，盡可能保證絕大部分核心業務能夠實現分布式多活。在此大家需要注意，就算實現了分布式多活，但因為種種原因仍然無法保證業務能夠100%可用，因為極端情況下（比如：網絡抖動、光纖被施工隊挖斷等）可能出現的數據無法同步等風險都會導致業務不可用，因此只能是犧牲小部分用戶而保證絕大多數用戶可用。