如何應對數千微服務組件帶來的挑戰

王剛

從幾年前某CTO的一個問題說起：“我們的系統將會擁有5 000個微服務組件，我們應該怎么做？”

一個接口是無法稱之為微服務的，接口數量達到十幾個或許才夠稱之為微服務。那么，對于包含5 000個微服務的系統而言，該如何實現和管理呢？在這樣龐大的系統背后，一定存在很大的問題。

微服務的前世今生

微服務是如何誕生的，必須了解以下4個領域。

TOGAF：全稱“開放組體系結構框架”，TOGAF在上世紀七、八十年代的時候就已經由專門組織負責開發了，直到1995年美國國防部參與之后，TOGAF才最終成型。

如今，大家手機里正在使用的產品和應用中，很多都會用到SAP、IBM或者惠普的軟件，而這些軟件公司所遵循的就是TOGAF。可以說目前全球超過50 %的企業正在使用TOGAF實踐軟件架構設計和開發。

TOGAF是一個架構體系，但并沒有提供具體的架構方法。TOGAF包含了業務架構、應用架構、數據架構、技術架構等，TOGAF有3個最為主要的支柱：

企業架構域，主要是企業信息與業務流等；

ADM一系列的架構方法論；

企業連續性，指的是在企業業務高速增長并且不斷變更的過程中，保證架構體系的連續性。

DDD：全稱為“領域驅動設計”，其包含了諸多的概念，可以用3句話進行概括：

DDD是精簡的業務，DDD首先關注的就是業務，把各種繁瑣的業務流程精簡成更細的鏈條；

DDD需要回答業務是干什么的，能夠滿足什么需求，達成什么目的；

不斷迭代，DDD的不斷迭代與TOGAF的企業連續性類似。

SOA：全稱為“面向服務架構”，理論較多，但是可以總結為以下3點：

SOA解決了信息孤島的問題；

業務重用，從業務角度將各個服務組合成一個個中間件或者服務，將其提供給用戶或者其他系統；

SOA使得系統成為互聯互通的信息群。

GRASP原則：全稱為“通用職責分配原則”，包含很多耳熟能詳的概念如低耦合、高內聚，均來自GRASP原則。它與設計模式不同，設計模式指導如何實現系統，而GRASP旨在指導如何劃分。

GRASP原則旨在指導定義業務架構以及API等相關內容和劃分服務，其理論內容也非常多，但只需記住3個關鍵：

自己干自己的事；

自己只干自己能干的事；

自己只干自己的事，強調了資源劃分。

在軟件工程的教科書上給出了微服務架構的定義：微服務架構是一種架構模式，它是將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常基于HTTP協議的RESTFul API）。每個服務都圍繞著具體業務進行構建，并且能夠被獨立地部署到生產環境、類生產環境等。另外，應當盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下游，選擇合適的語言、工具對其進行構建。

微服務帶來的優勢

我們使用微服務架構的時候，到底得到了什么東西呢？這里總結了4點最為明顯的優點：

使得開發和迭代變得更加敏捷，微服務架構使得敏捷開發成為可能；

易于擴展和收縮，一些公司基于Kubernetes、Docker等技術可以在幾秒內拉起上萬個微服務，當大型流量沖擊到達的時候，可以實現無損地承擔全部流量，同時實現用戶無感知，而當數據訪問量降低之后，又可以實現快速縮容；

多技術棧可能，目前云智慧的技術棧非常全面，雖然開發人員只有60多人，但是開發語言卻多達10多門，而使用微服務可以有效地組織各類開發人員；

高可修改性，比如實現數據庫的快速遷移，通道的快速切換等。

微服務帶來的疑問

微服務能夠帶來諸多優點，但是也存在2點疑問，第一個就是“微服務架構，你的系統變得更健壯了嗎？”；第二個則是“使用微服務讓系統變得更快了嗎？”

對于這2點而言，可能說是見仁見智的。有人說因為組件變得越來越多，可監控性就會變難，因此系統健壯性就會變得越來越差；也有人說因為將系統拆分得越來越細，因此健壯性就會越來越強。如果單體架構是串行的，那么使用微服務可以將其變成并行的和分布式的，而多個組件之間進行通信，也會使得通信成為性能瓶頸，那么使用微服務到底是變快了還是變慢了呢？這2個問題都很難以回答，作為一個架構師或者開發者需要不斷進行深入的思考。

微服務架構面臨的挑戰和思考

這里總結了在使用微服務架構的時候所需要面臨的8個挑戰和相關的思考：

小即是多

當業務從大變小的時候，也意味著業務變多了。由大變小，可以使系統變得更加容易維護和修改，但是由少變多，又會使得問題更加復雜，因此也會出現很多的挑戰。

第一個問題就是多節點、多服務和多狀態。系統中的節點、組件服務變得更多了，那么節點和服務之間的狀態也會變得更難維護，更加復雜。基于前面提到的4種知識，可以將從大變小和從少變多這2個轉變進行折中，使得其變得更加可控。而解決這個問題的關鍵在于對于服務的合理拆分，主要有3點可以考慮，即：數據資源、業務功能以及服務對象。

債務管理

Bug、代碼缺陷、未完成的功能或者版本不兼容等問題都是債務，當服務變得越來越多的時候，債務往往就會變得更多。為了解決這些問題，有這樣的幾種策略：

單元測試，如果單元測試做的足夠好，那么代碼缺陷的可能性就會變得更低，可以將服務由少變多所造成的債務變多問題進行收斂。

集成回歸，這部分提供了很多工具去做這件事情，不用開發者自己去做。

版本管理，這里指的是靜態庫的版本管理，動態庫指的是正在變更中的庫，而靜態庫指的是不再變更的庫和配置項，這一點控制不好，就容易使得系統管理混亂。

迭代沖刺，是一種組織方式，當有很多技術債務需要進行管理時，如何將這些債務一點點處理掉或者把發散的趨勢收斂住，迭代沖刺就是一種做法。

Bug Crash，這是智慧云團隊自己發明的一個名詞，相當于是對于Bug的大掃除，無論采用傳統的還是敏捷的開發模式，都有一些Bug存在，因此定期會組織全體開發、測試和產品人員將自己的產品用一遍，進行Bug大掃除。

總之，無論采用什么開發模式，在一個迭代周期完成之后，回歸總結是少不了的，也需要通過一些方法解決新發生的問題，或者將其封閉住不使債務繼續蔓延。

復雜的服務依賴

如果只有一個或者幾個組件，那么其實不存在服務依賴問題，而如果有幾千個組件，那么服務依賴將會成為巨大的問題。舉例而言，如果用戶服務需要調用訂單服務，那么在啟動的時候需要進行一些初始化任務，那么一個服務的版本發布可能導致系統全面癱瘓，這就是復雜服務依賴問題。

為了解決這個問題首先就需要服務發現機制，比如使用 etcd或者Zookeeper等，首先服務發現中心也需要是分布式高可靠的，那么服務起來之后需要把自己的名字和調用方式告訴服務發現中心，注冊上去；對于服務調用者而言只需要從服務發現中心那里通過約定好的名字獲取服務調用地址即可。

依賴喚醒是有一個相對比較新的東西，比如大流量突然打進來的時候，A服務需要從原來的10個啟動到100個，而B肯定也是不夠用的，因此需要通過喚醒的機制將服務拉起來，而不是被動的等通知。

還有一種情況也需要使用到依賴喚醒機制，比如緩存穿透問題，正常情況下，緩存是生效的，不會存在穿透的情況，但是可能因為某種異常使得緩存不生效了，會將大量的流量打到DB里面去，使得服務變得不可用了，整個服務雪崩掉，針對這些問題一般會開發一些擋板服務，可能會給出一些固定的數據，而這些擋板服務也有可能會面臨這種突發的流量也需要通過依賴喚醒的機制實現喚醒。

此外，還有灰度發布和AB測試，這2點是相關聯的。還有多版本共存問題，對于服務的多版本也是一個技術債務問題，需要考慮如何將其舊版本拿下來。

消息通信

如果系統中包含多個語言棧，多種實現方式。那統一標準是必須的，統一一種RPC或者就使用RestFul API等。消息中心也是一種處理做法，這一點在Java中應用很多，消息中心并不是消息隊列，而是一個事件驅動的消息中心。此外，還有通信網關，這在使用微服務的時候也是一個必要點，其主要解決了監控問題，而且可以通過網關起到中控的作用，比如安全、性能以及用戶校驗等任務。

分布式事務

在實現分布式事務的時候可以采用2PC或者3PC原則來實現，2PC原則是通過全部節點投票和執行2個步驟完成的，并且是阻塞的；而3PC則不同，在一個具體的事務里面可以是阻塞的，也可以是非阻塞的。

3PC協議則是通過“Can-Pre-Do”3個步驟來實現的，其實PDU就是3PC協議在單體中的實現方式。而在分布式系統中，3PC有3種實現方式，使用分布式的事件驅動、最大通知以及兩階段補償TCC。

花式故障

很多時候，當系統出現問題時可能需要花費數周和很多人力才能找到根源所在，可能因為系統太多，使得系統架構師也無法理清系統與系統之間的關系。面對諸多的花式故障，也有多種策略可以應對，比如全鏈路追蹤，比如使用Open Tracking；主動撥測，很多用戶端的App里面內置探針，使其可以接收Server端的指令來定期探測接口和服務是否正常。

中心與去中心

中心與去中心可以算是一個永恒的話題，配置、發號、日志、調度、狀態以及預警，其實對于比較成熟的大型系統而言，這6點都是需要中心的。

組織危機

最后一個問題，也是最大的問題。要實現向微服務架構的變更的時候，最大的問題就是組織危機。這一點與開發者關系不大，但是對于Team Leader以及組織的管理人員而言，關系非常大。架構的轉變需要考慮到信任危機、過期維護、多語言棧、溝通協作、安全網關以及輪崗結對等問題。

總之，最重要的觀點有2個：微服務不是銀彈；不要讓重復的事情做2次。