作者 |  阿里云微服務(wù)團隊

一、從一個典型的案例談起

1.微服務(wù)開發(fā)不簡單

隨著微服務(wù)技術(shù)的發(fā)展，微服務(wù)(MicroServices) 的概念早已深入人心，越來越多的公司開始使?微服務(wù)架構(gòu)來開發(fā)業(yè)務(wù)應(yīng)用。

如果采?得當(dāng)，微服務(wù)架構(gòu)可以帶來?常?的優(yōu)勢。微服務(wù)架構(gòu)的最大的好處是它可以提升開發(fā)效率和系統(tǒng)整體的穩(wěn)定性：

• 開發(fā)和部署相對簡單：單個微服務(wù)的功能可以更快地更改，因為可以獨立部署，影響范圍更小，啟動和調(diào)試單個微服務(wù)的時間成本相比于單體應(yīng)用也大大減少。
• 橫向擴展簡單：根據(jù)業(yè)務(wù)的高峰低谷周期快速的橫向擴展非常簡單，因為單個微服務(wù)通常很小，可以隨著系統(tǒng)整體負載的變化更快地啟動和停止。
• 架構(gòu)升級靈活：單個微服務(wù)的內(nèi)部架構(gòu)可以迅速升級，因為微服務(wù)之間是松散耦合的，只面向定義好的通訊接口進行編程。這使開發(fā)團隊能夠基于自身的技術(shù)背景和偏好靈活選擇，而不會直接影響其他應(yīng)用程序、服務(wù)或團隊。
• 更好的容錯性：微服務(wù)之間可以實現(xiàn)更好的故障隔離，單個服務(wù)內(nèi)的內(nèi)存泄露等故障不容易影響其他服務(wù)，相比單體應(yīng)用?個組件故障會拖垮整個系統(tǒng)。

但是微服務(wù)在實施過程中，也很容易遇到一些難點。如果微服務(wù)治理得不恰當(dāng)，反而有可能適得其反，不僅不能享受到微服務(wù)架構(gòu)帶來的好處，反而會因為微服務(wù)帶來的系統(tǒng)復(fù)雜性，造成開發(fā)、運維部署的復(fù)雜度增加，進而影響開發(fā)迭代的速度，甚至影響系統(tǒng)的整體穩(wěn)定性。

我們總結(jié)了?些微服務(wù)開發(fā)實施過程中常見的問題：

• 服務(wù)之間使用遠程調(diào)用進行通訊，這比進程內(nèi)的直接調(diào)用復(fù)雜很多。由于通訊鏈路的復(fù)雜性，可能會出現(xiàn)很多不確定的問題，會出現(xiàn)遠程調(diào)用不可用或者延遲較高的情況，開發(fā)?員需要能夠處理這些偶發(fā)問題，避免影響業(yè)務(wù)。
• 隨著業(yè)務(wù)的發(fā)展，微服務(wù)之間的拓撲圖開始變得復(fù)雜，排查問題變得困難，搭建完整的開發(fā)測試環(huán)境成本也越來越大。
• 當(dāng)功能涉及到多個微服務(wù)模塊時，迭代時需要謹慎地協(xié)調(diào)多個開發(fā)團隊的迭代排期，才能保證迭代能夠按時交付，達到敏捷開發(fā)的效果。

2.?個微服務(wù)成功落地的典型案例

觀察了阿里云眾多客戶之后，我們總結(jié)了?個微服務(wù)成功落地的典型案例，某公司借助于微服務(wù)架構(gòu)的紅利，實現(xiàn)了業(yè)務(wù)快速增長：主要會分析在業(yè)務(wù)發(fā)展的不同階段，該公司在微服務(wù)實施過程遇到的問題，以及如何通過微服務(wù)治理來解決這些問題，從而享受到了微服務(wù)帶來的開發(fā)效率和業(yè)務(wù)穩(wěn)定性提升的紅利，進而促進業(yè)務(wù)快速發(fā)展。

（1）業(yè)務(wù)孵化期

初創(chuàng)公司在剛起步時，雖然業(yè)務(wù)量比較小、業(yè)務(wù)模式比較簡單，但是為了在后續(xù)的快速發(fā)展中能夠快速迭代，同時公司的人才儲備也滿足微服務(wù)開發(fā)的條件，于是在初創(chuàng)期就選擇了使用微服務(wù)架構(gòu)進行業(yè)務(wù)開發(fā)。

在技術(shù)選型方面，如果公司創(chuàng)始員工是技術(shù)出身，那么會比較傾向于使用自己擅長的微服務(wù)框架，如創(chuàng)始人是 Dubbo 的 contributor ，或者是 Spring Cloud 社區(qū)的大咖或者 Spring Cloud Alibaba 的contributor，又或者是 Service Mesh 社區(qū)的大咖，?般都會選用自己所擅長的微服務(wù)框架類型。還有一種選擇是選用市面上最流行的微服務(wù)框架，如 Java 體系，會選擇 Spring Cloud 和 Dubbo。在目前的招聘市場上也容易招聘到熟悉相關(guān)領(lǐng)域的人，從初學(xué)者到專家級的候選人都能很容易招聘到。

選定了技術(shù)選型后，基于開源的框架，很容易就能開發(fā)好最初的業(yè)務(wù)應(yīng)用系統(tǒng)，跑通業(yè)務(wù)流程。這?階段組件也很簡單。簡單的兩三個應(yīng)用，用戶系統(tǒng)、業(yè)務(wù)系統(tǒng)、支持系統(tǒng)，再加上注冊中心、數(shù)據(jù)庫、緩存，就可以開發(fā)完全部的應(yīng)用。

對于一個生產(chǎn)級別的系統(tǒng)來說，在將整套系統(tǒng)部署上線之前，還需要建設(shè)監(jiān)控報警系統(tǒng)。監(jiān)控報警系統(tǒng)能夠幫助我們實時監(jiān)控機器和應(yīng)用的狀態(tài)。我們可以配置預(yù)設(shè)的報警規(guī)則，在出現(xiàn)機器資源不足，業(yè)務(wù)出現(xiàn)異常報錯時這些情況時主動報警，提醒我們盡快處理系統(tǒng)中的風(fēng)險和異常。保留問題的現(xiàn)場，并幫助我們快速地定位和排查問題也同樣重要，阿里云應(yīng)用實時監(jiān)控服務(wù) ARMS 和日志服務(wù) SLS 能夠在這些場景提供很大的幫助。

采用 ARMS + SLS 完成監(jiān)控報警系統(tǒng)建設(shè)之后，將業(yè)務(wù)系統(tǒng)部署上線，完成第一次成功上線，業(yè)務(wù)開始正常運行起來了。

但是業(yè)務(wù)的開發(fā)和運營從來都不是?帆風(fēng)順的，在這個過程中，肯定也會遇到很多問題，我們先總結(jié)?下這個階段常見的問題及應(yīng)對方案：

1） 因為代碼本身邏輯出錯導(dǎo)致業(yè)務(wù)異常：這時可以通過 SLS 查詢?nèi)罩?，結(jié)合 ARMS 分析錯誤堆棧找到根因，修改完代碼后，重新發(fā)布來修復(fù)問題。

2） 遇到性能瓶頸：則直接擴容操作，如水平擴容應(yīng)用，或者升級數(shù)據(jù)庫。

3） 發(fā)布新版本影響到用戶：因為用戶數(shù)和請求數(shù)都不算多，很容易就可以找到業(yè)務(wù)低峰期，在業(yè)務(wù)低峰期進行發(fā)布。

4）如何確保新版本的正確性：因為業(yè)務(wù)場景不復(fù)雜，內(nèi)部測試就能覆蓋所有的場景，測試通過就可以直接上線。那如何識別自身的業(yè)務(wù)是否處于這個階段呢?有?系列典型的特征：應(yīng)用不超過 4 個，應(yīng)用節(jié)點總數(shù)不超過 10 個，最高峰時候的 QPS 不超過 10。

（2）業(yè)務(wù)快速發(fā)展期

度過初創(chuàng)期之后，公司的業(yè)務(wù)很受用戶和市場的歡迎，注冊的用戶越來越多，用戶使用的時長和功能點也越來越多，日活數(shù)越來越大，甚至市場中還出現(xiàn)了其他競爭者開始抄襲公司的業(yè)務(wù)，一些巨頭還親自下場參與競爭。公司業(yè)務(wù)發(fā)展得非常順利，這也意味著系統(tǒng)進入了快速發(fā)展時期。

市場發(fā)展很迅速，注冊用戶數(shù)、日活這些數(shù)據(jù)也是節(jié)節(jié)攀升，所有統(tǒng)計報表的數(shù)字都是一片向好。但是帶來的挑戰(zhàn)也越來越大，這個時期也是最危險的時期：在業(yè)務(wù)快速發(fā)展中，既要保證好已有業(yè)務(wù)的穩(wěn)定性，又要快速地迭代新功能，還要克服團隊招聘節(jié)奏跟不上業(yè)務(wù)發(fā)展的問題。

這個階段典型的特征是應(yīng)用個數(shù)在 5 到 50 個，QPS 在 10 到 1000。這個時期經(jīng)常會遇到的問題概括起來就是兩個：穩(wěn)定性問題和開發(fā)效率問題。

穩(wěn)定性的問題：用戶數(shù)多起來之后，系統(tǒng)的穩(wěn)定性就顯得比較重要，無論是用戶在某段時間遇到異常報錯增多，還是某?個功能點持續(xù)性地報錯，再大到系統(tǒng)有?段時間完全不可用，這些都會影響產(chǎn)品在用戶中的口碑，最后這種完全不可用的場景，甚至還可能成為微博等社交網(wǎng)絡(luò)上的輿論熱點。

開發(fā)效率的問題：隨著用戶的增多，相應(yīng)的需求也越來越多，業(yè)務(wù)場景也越來越復(fù)雜，在這個時候測試可不是內(nèi)部測試就能覆蓋所有的場景，需要加大在測試上的投入。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經(jīng)出現(xiàn)了競爭者，如果他們抄得快，新功能也上得快，業(yè)務(wù)有可能會競爭不過，特別是當(dāng)巨頭親自下場的時候，更需要跑得更快，開發(fā)節(jié)奏要快，測試節(jié)奏要快，發(fā)版節(jié)奏也要快。

那么如何去解決這兩個場景的痛點呢，這時候可以要借助微服務(wù)治理的能力來解決。

1）開發(fā)測試提效

a.【開發(fā)環(huán)境隔離】傳統(tǒng)的多套開發(fā)環(huán)境，需要使用多套的物理環(huán)境，才能實現(xiàn)多套環(huán)境各自獨立互不干擾，但是多套物理環(huán)境的隔離的機器成本是很高的，基本上不?能接受。但通過全鏈路灰度這種邏輯隔離的方式實現(xiàn)開發(fā)環(huán)境隔離，可以在不增加成本的情況下增加多套開發(fā)測試環(huán)境，助你實現(xiàn)敏捷開發(fā)。

b.【自動化回歸測試】自動化回歸測試功能，可以將多個測試用例串聯(lián)成測試用例集，將上?條測試的返回值作為下?跳測試入?yún)?，串?lián)成具體的業(yè)務(wù)場景并沉淀到自動化回歸測試中，在每?次的發(fā)版之前都跑?次自動化回歸來驗證功能的正確性，這樣就可以大大節(jié)省測試的人力成本。更進?步，還可以通過流量錄制回放功能，將線上的真實流量錄制下來，并沉淀成自動化回歸用例集，在測試環(huán)境進行流量回放，更進?步地提升測試 case 的覆蓋率。

c.【服務(wù)契約】功能越來越多，迭代越來越快，API 越來越復(fù)雜，團隊之間溝通的效率越來越低，API 文檔嚴重過期。如果自動生成服務(wù)契約，可以有效地避免文檔腐化造成的開發(fā)效率低下的問題。

使用上面三點之后，可以在低成本的條件下支持多套開發(fā)測試環(huán)境，實現(xiàn)自動化回歸測試，實現(xiàn)開發(fā)節(jié)奏和測試節(jié)奏的大大提效。

2）安全發(fā)布

a.【無損下線】無損下線問題的根本原因是開源的微服務(wù)體系沒有確保應(yīng)用提供者節(jié)點在停止服務(wù)前確保已經(jīng)通知到所有消費者不再調(diào)用自己，也無法確保在處理完所有請求之后再停?應(yīng)用。所以新發(fā)版的應(yīng)用，即使業(yè)務(wù)代碼沒有任何問題，也可能在發(fā)布過程影響用戶的體驗。

b.【無損上線】無損上線問題出現(xiàn)的原因是因為在某些場景下服務(wù)提供者，需要經(jīng)過?段時間才能正常地接收大流量的請求并成功返回。同時在 K8s 場景下，還需要和 K8s 中的 readiness 、滾動發(fā)布等?命周期緊密結(jié)合，才能確保應(yīng)用發(fā)布過程中能不出現(xiàn)業(yè)務(wù)報錯。

c.【全鏈路灰度】新功能上線之后，可以通過灰度規(guī)則控制哪些?戶可以使用。這樣可以先選擇讓內(nèi)部用戶使用，測試新功能的正確性。當(dāng)內(nèi)部用戶驗證通過后，再漸漸地擴大灰度范圍，確保每個功能都經(jīng)過充分驗證后再全量開放給客戶，屏蔽掉發(fā)布新功能的風(fēng)險。而且當(dāng)出現(xiàn)問題時，可以通過修改灰度規(guī)則來實現(xiàn)快速回滾，做到新版本發(fā)版時幾乎無風(fēng)險。

使用以上幾點之后，可以確保新版本的發(fā)布不出問題，而且可以做到白天在大流量場景下也輕松發(fā)布，在實現(xiàn)白天輕松發(fā)布之后，?天就可以發(fā)布多次，提升發(fā)布時候的穩(wěn)定性和發(fā)版的效率。

3）屏蔽偶發(fā)異常導(dǎo)致的風(fēng)險

a.【離群實例摘除】對于這些偶發(fā)的異常問題，離群摘除功能可以智能判斷應(yīng)用中的服務(wù)提供者某個出現(xiàn)了問題，智能地在?段時間內(nèi)屏蔽掉這個服務(wù)提供者，保證業(yè)務(wù)的正常，等這個服務(wù)提供者恢復(fù)過來之后再進行調(diào)用。可以在應(yīng)用節(jié)點出現(xiàn)偶發(fā)異常時，智能屏蔽掉此節(jié)點，以免影響業(yè)務(wù)，等此節(jié)點恢復(fù)后再繼續(xù)提供服務(wù)，從而屏蔽偶發(fā)異常導(dǎo)致的風(fēng)險。

據(jù)統(tǒng)計數(shù)據(jù)顯示，有將近 90% 的線上故障是由于發(fā)版過程中出現(xiàn)的，剩下的 10% 左右的線上問題，可能是由于?些偶然的原因?qū)е碌摹Ｈ缗既坏木W(wǎng)絡(luò)故障、機器 I/O 出現(xiàn)問題、或者是某臺機器負載過高等。在解決了發(fā)布時候的穩(wěn)定性問題和偶發(fā)異常導(dǎo)致的風(fēng)險后，基本能夠確保線上業(yè)務(wù)不會出現(xiàn)災(zāi)難性的問題。

在業(yè)務(wù)快速發(fā)展的生死存亡期，需要借助于這些微服務(wù)治理能力，確保業(yè)務(wù)能夠又快又穩(wěn)地增長，度過這段生死存亡期，成為這個領(lǐng)域的重要玩家。

（3）業(yè)務(wù)成熟期

當(dāng)業(yè)務(wù)進入成熟期之后，業(yè)務(wù)的開發(fā)進入了新的階段，這時候，雖然快速發(fā)展過程中的問題仍舊存在，但是會因為業(yè)務(wù)量上來之后，遇到新的問題。

低成本創(chuàng)新：雖然發(fā)展不像原來那么迅速，但是業(yè)務(wù)創(chuàng)新探索的訴求仍舊存在，由于業(yè)務(wù)規(guī)模的擴大，創(chuàng)新的成本也在增加。這個時候不僅是需要快速開發(fā)迭代，更大的需求是用盡可能小的成本進行創(chuàng)新探索測試，有時候還需要使用上 AB 測試的手段進行實驗比較。

容災(zāi)多活：由于業(yè)務(wù)規(guī)模已經(jīng)很大了，治理中的穩(wěn)定性的訴求更加強烈，而且隨著業(yè)務(wù)范圍的擴大，應(yīng)?也開始在多個地域、多個云產(chǎn)品中進行部署。同城容災(zāi)、異地多活這類需求也開始出現(xiàn)。

問題定位：出現(xiàn)任何問題都必須徹查。雖然出現(xiàn)問題時，業(yè)務(wù)恢復(fù)仍舊排查第?位，但是業(yè)務(wù)恢復(fù)之后的問題根因定位也是不能少的，因為如果不徹查，難免后續(xù)出現(xiàn)同樣的問題。

風(fēng)險預(yù)案：緊急預(yù)案、風(fēng)險預(yù)防也變得非常重要，需要提前做好業(yè)務(wù)的保護和降級的埋點演練，在遇到絕大多數(shù)可預(yù)見問題可以緊急修復(fù)，出現(xiàn)不可控問題時，可以通過預(yù)案手段執(zhí)行預(yù)案，確保整體業(yè)務(wù)的可控性。

從這個典型的案例中，我們可以看到，微服務(wù)的成功落地和業(yè)務(wù)的快速發(fā)展，離不開微服務(wù)治理的支持。在業(yè)務(wù)發(fā)展的不同階段，會遇到不同的微服務(wù)問題，需要借助于治理的能力，為業(yè)務(wù)的又快又穩(wěn)發(fā)展保駕護航。

二、微服務(wù)治理在云原生場景下的挑戰(zhàn)

1.企業(yè)上云的四個階段

隨著云原生時代的到來，越來越多的應(yīng)用生在云上，長在云上，且隨著越來越多的企業(yè)開始上云，云原生也是企業(yè)落地微服務(wù)的最佳伴侶。我們分析了阿里云典型客戶的實踐經(jīng)歷，業(yè)務(wù)上云通常劃分為 4 個階段：云上部署、云原生部署、微服務(wù)化、服務(wù)治理。

（1）云上部署

這?階段我們解決的問題，如何把傳統(tǒng)業(yè)務(wù)，原來是跑在自建 IDC 機房的業(yè)務(wù)，能夠原封不動地遷移到云上。通常云廠商提供了豐富的計算、存儲、網(wǎng)絡(luò)等資源可供選擇，以虛擬化技術(shù)，神龍裸金屬服務(wù)為代表的硬件可以滿足企業(yè)客戶上云搬遷的豐富需求，這?階段關(guān)注的焦點是資源，對于業(yè)務(wù)并無任何的改造，只需要從本地原樣搬遷到云上即可。

（2）云原生部署

云原生是釋放云計算價值的最短路徑，以容器技術(shù)為代表，云原生提供了強大的調(diào)度、彈性等能力，極大地降低了上云的成本。這?階段我們關(guān)注的目標主要是業(yè)務(wù)進行云原生化改造，隨著 Kubernetes 作為容器編排市場的事實標準，我們需要把業(yè)務(wù)從原來的的虛擬機部署方式改造成容器化方式，部署并運行在 K8s 之上，最大限度享受到云原生帶來的技術(shù)紅利。這?階段核心關(guān)注目標以容器為核心。

（3）微服務(wù)化

當(dāng)我們的業(yè)務(wù)規(guī)模逐步擴大，傳統(tǒng)單體應(yīng)用很難進?步支撐業(yè)務(wù)的發(fā)展，業(yè)務(wù)的迭代速度已經(jīng)無法滿足業(yè)務(wù)的增長，此時我們就需要進行微服務(wù)化的改造，降低業(yè)務(wù)的耦合度，提升開發(fā)迭代的效率，讓開發(fā)更加敏捷。這?階段我們聚焦以應(yīng)用為核心。

（4）服務(wù)治理

當(dāng)微服務(wù)的規(guī)模也越來越大的時候，如果對微服務(wù)不加以規(guī)范和整治，很容易出現(xiàn)問題。例如，每個微服務(wù)都有獨立的團隊來維護，他們之間如果依賴沒有整理清楚，可能會出現(xiàn)架構(gòu)上循環(huán)依賴等問題。從我們的數(shù)據(jù)觀察來看，當(dāng)微服務(wù)的節(jié)點數(shù)超過數(shù)十個的情況下，我們通常就需要引入服務(wù)治理，通常需要關(guān)注的是開發(fā)、測試、線上運維，安全等多方面考慮，這?階段我們聚焦以業(yè)務(wù)為核心，核心目標是進?步提高開發(fā)效率，提高線上業(yè)務(wù)的穩(wěn)定性。

2.微服務(wù)治理在云原生下的挑戰(zhàn)

隨著企業(yè)微服務(wù)化進程的逐深入，微服務(wù)的云原生化逐步進?深水區(qū)，在這個微服務(wù)深化的過程中，我們逐步會面臨?系列的挑戰(zhàn)，總的而言，我們將這些挑戰(zhàn)分為三個大的層面，分別是效率、穩(wěn)定和成本。我們進行微服務(wù)化，本身的使命是讓業(yè)務(wù)的迭代更加高效，但當(dāng)我們的微服務(wù)數(shù)量逐步增多，鏈路越來越長，如果不進行進?步的治理，那么引發(fā)的效率問題可能會大于微服務(wù)架構(gòu)本身帶來的架構(gòu)紅利。在微服務(wù)實施的不同階段，遇到的問題也不盡相同。目前阿里巴巴內(nèi)部的微服務(wù)節(jié)點數(shù)量是在百萬級別，在這個過程我們也積累了非常多的治理經(jīng)驗。

（1）在效率上面臨的挑戰(zhàn)

在效率方面需要追求的目標是，在開發(fā)、線上運維、SDK 升級等方面更加高效。

• 在開發(fā)階段，我們需要考慮的是，業(yè)務(wù)應(yīng)用上云之后，如何讓本地開發(fā)的應(yīng)用，很好的部署云上的業(yè)務(wù)進行聯(lián)調(diào)?通常我們的微服務(wù)不可能在本地完整的部署?整套系統(tǒng)，所以本地開發(fā)的應(yīng)用只是整個微服務(wù)鏈路的?小部分，這包括我們的流量需要能夠輕松的從云上，引導(dǎo)到本地，便于我們做開發(fā)調(diào)試，或者我們在本地能夠很方便的調(diào)用云上部署的微服務(wù)進行聯(lián)調(diào)。這在微服務(wù)上云之后，比原來在自身機房進行開發(fā)聯(lián)調(diào)更加困難。
• 在線上運維方面，我們通常需要頻繁的對微服務(wù)進行變更，這些變更通常就會引發(fā)?系列的問題，例如在白天高峰期做發(fā)布，通常都會導(dǎo)致業(yè)務(wù)流量出現(xiàn)損失，我們的研發(fā)人員不得不選擇在晚上業(yè)務(wù)低峰期做變更，這大大降低了研發(fā)人員的幸福指數(shù)，因為他們不得不面臨熬夜加班的困境。如果能在白天大流量高峰期也能進行流量無損的變更，那么這對于研發(fā)?員來說將是大大提升研發(fā)效率的事情。
• 微服務(wù)框架通常會引入服務(wù)治理的邏輯，而這些邏輯通常會以 SDK 的方式被業(yè)務(wù)代碼所依賴，而這些邏輯的變更和升級，都需要每?個微服務(wù)業(yè)務(wù)通過修改代碼的方式來實現(xiàn)，這樣的變更造成了非常大的升級成本。以阿里巴巴為例，阿里內(nèi)部?個中間件 SDK 的升級，如果要在整個集團鋪開，通常需要消耗的時間以年為單位進行統(tǒng)計，這里面也會消耗每個微服務(wù)應(yīng)用的研發(fā)、測試等龐大的資源，效率非常低下，如果能夠以無侵入的方式實現(xiàn)中間件 SDK 的升級，那么將會是?件非常高效的事情。
• 進入云原生體系之后，以 K8s 為主的云原生體系強調(diào)集群之間的靈活調(diào)度型，以 POD 為單位任意的調(diào)度資源，在被調(diào)度后 POD 的 IP 也將相應(yīng)地發(fā)?變化，傳統(tǒng)的服務(wù)治理體系，通常以 IP 為維度進行治理策略的配置，例如黑白名單策略等，但是當(dāng)進入云原生場景后，這些傳統(tǒng)的治理策略都會面臨失效的問題，因為 POD ?旦被重新調(diào)度，原來的治理策略都將不再使用，如何能讓服務(wù)治理體系更加適應(yīng)云原生體系，也是我們要面臨的?大挑戰(zhàn)。

（2）在穩(wěn)定上面臨的挑戰(zhàn)

穩(wěn)定大于?切，在微服務(wù)上云之后，業(yè)務(wù)高可用是我們必須要解決的問題，因此通常會在同?個地域的多個可用區(qū)內(nèi)進行部署，在多可用區(qū)部署的情況下，跨可用區(qū)的延時就是不可忽視的問題，我們需要思考的是業(yè)務(wù)流量需要能夠盡量在同?個可用區(qū)內(nèi)進?流轉(zhuǎn)，同時也需要考慮的是如果?個可?區(qū)出現(xiàn)問題，業(yè)務(wù)流量能夠盡可能快的流轉(zhuǎn)到正常的可用區(qū)，這就對我們的微服務(wù)框架的路由能力提出了挑戰(zhàn)。

當(dāng)然，我們的業(yè)務(wù)不僅需要在同?個地域里保證高可用，也需要考慮?個地域出問題的時候，保證業(yè)務(wù)的高可用，這時我們就需要考慮業(yè)務(wù)實現(xiàn)同城雙活，甚至是異地多活，這對我們來說也是一大挑戰(zhàn)。

第三，微服務(wù)之間的調(diào)用也需要更加的安全可信，近期層出不窮的安全漏洞，?定程度上也反映出當(dāng)前上云階段在安全方便暴露出的問題還是非常多，每次安全漏洞出現(xiàn)之后，中間件 SDK 的升級也是困擾業(yè)務(wù)多年的問題;同時，?些敏感的數(shù)據(jù)，即使在數(shù)據(jù)庫層做了非常多的權(quán)限管控，由于微服務(wù)被授予了數(shù)據(jù)訪問的較高權(quán)限，如果微服務(wù)的調(diào)用被惡意攻擊，也可能會造成敏感數(shù)據(jù)的泄露。微服務(wù)之間的調(diào)用需要更加可靠可信。

（3）在成本上面臨的挑戰(zhàn)

首先，在成本方面，業(yè)務(wù)上云遇到的最?問題就是如果最低成本的把業(yè)務(wù)遷移上云，對于?個在線業(yè)務(wù)，如果要進行停機遷移，那么遷移的成本會顯得非常高，對于客戶的體驗也會收到影響，要在不中斷業(yè)務(wù)的情況下，實現(xiàn)平滑遷移上云，還是有非常大的挑戰(zhàn)的。

其次，當(dāng)我們在業(yè)務(wù)面臨極速增長的流量時，迫切的需要快速的彈性，補充更多的資源以承載業(yè)務(wù)的高峰，當(dāng)我們進入業(yè)務(wù)低峰的時候，又希望能夠縮小容量，節(jié)省資源，因此云產(chǎn)品提供的快速靈活的彈性機制，是微服務(wù)上云之后?項急需的能力。