作者 |  阿里云微服務團隊

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

1.微服務開發不簡單

隨著微服務技術的發展，微服務(MicroServices) 的概念早已深入人心，越來越多的公司開始使?微服務架構來開發業務應用。

如果采?得當，微服務架構可以帶來?常?的優勢。微服務架構的最大的好處是它可以提升開發效率和系統整體的穩定性：

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

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

我們總結了?些微服務開發實施過程中常見的問題：

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

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

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

（1）業務孵化期

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

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

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

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

采用 ARMS + SLS 完成監控報警系統建設之后，將業務系統部署上線，完成第一次成功上線，業務開始正常運行起來了。

但是業務的開發和運營從來都不是?帆風順的，在這個過程中，肯定也會遇到很多問題，我們先總結?下這個階段常見的問題及應對方案：

1） 因為代碼本身邏輯出錯導致業務異常：這時可以通過 SLS 查詢日志，結合 ARMS 分析錯誤堆棧找到根因，修改完代碼后，重新發布來修復問題。

2） 遇到性能瓶頸：則直接擴容操作，如水平擴容應用，或者升級數據庫。

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

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

（2）業務快速發展期

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

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

這個階段典型的特征是應用個數在 5 到 50 個，QPS 在 10 到 1000。這個時期經常會遇到的問題概括起來就是兩個：穩定性問題和開發效率問題。

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

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

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

1）開發測試提效

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

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

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

使用上面三點之后，可以在低成本的條件下支持多套開發測試環境，實現自動化回歸測試，實現開發節奏和測試節奏的大大提效。

2）安全發布

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

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

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

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

3）屏蔽偶發異常導致的風險

a.【離群實例摘除】對于這些偶發的異常問題，離群摘除功能可以智能判斷應用中的服務提供者某個出現了問題，智能地在?段時間內屏蔽掉這個服務提供者，保證業務的正常，等這個服務提供者恢復過來之后再進行調用。可以在應用節點出現偶發異常時，智能屏蔽掉此節點，以免影響業務，等此節點恢復后再繼續提供服務，從而屏蔽偶發異常導致的風險。

據統計數據顯示，有將近 90% 的線上故障是由于發版過程中出現的，剩下的 10% 左右的線上問題，可能是由于?些偶然的原因導致的。如偶然的網絡故障、機器 I/O 出現問題、或者是某臺機器負載過高等。在解決了發布時候的穩定性問題和偶發異常導致的風險后，基本能夠確保線上業務不會出現災難性的問題。

在業務快速發展的生死存亡期，需要借助于這些微服務治理能力，確保業務能夠又快又穩地增長，度過這段生死存亡期，成為這個領域的重要玩家。

（3）業務成熟期

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

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

容災多活：由于業務規模已經很大了，治理中的穩定性的訴求更加強烈，而且隨著業務范圍的擴大，應?也開始在多個地域、多個云產品中進行部署。同城容災、異地多活這類需求也開始出現。

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

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

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

二、微服務治理在云原生場景下的挑戰

1.企業上云的四個階段

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

（1）云上部署

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

（2）云原生部署

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

（3）微服務化

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

（4）服務治理

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

2.微服務治理在云原生下的挑戰

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

（1）在效率上面臨的挑戰

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

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

（2）在穩定上面臨的挑戰

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

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

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

（3）在成本上面臨的挑戰

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

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