???

 作者丨崔皓

策劃丨孫淑娟

【51CTO.com原創稿件】業務的飛速發展以及變化多端的動態組合一直推著以 IaaS、PaaS 和 SaaS 形式表現的云計算不斷發展，隨之微服務的實施方案也需要與時俱進。

放眼業內，谷歌、沃爾瑪和亞馬遜等科技巨頭都開始不同程度地使用微服務架構和方案，他們期待通過微服務提供的模塊化方案作為業務流程再造的基石，適應更加靈活復雜的商業場景。

從單體架構到微服務架構

單體軟件架構使用單一的方法和模型構建應用體系，雖然通過分成的方式將應用與應用之間進行隔離，并且在業務邏輯上面便于理解，同時具備開發周期可控的特點，但單體架構的可擴展性一直是大家詬病的缺點。

單體架構由于其自身特點對于擴展性有多種限制，例如資源可用較差、需要更長的部署周期、無法持續交付、技術棧單一無法發揮技術多樣性帶來的優勢，同時架構中單個應用的故障會影響到整體軟件。

企業期待采用模塊化和動態組合的方法來解決以上問題，因為模塊的動態組合對于靈活復雜的業務邏輯更具備業務推動力。

這正應了 Adrian Cockcroft，Battery Ventures，說的那句話：

“微服務是具備有限上下文、松散耦合、面向服務的架構。”

松耦合模塊會根據應用程序的需求進行合理組合。每個服務可以通過不同的技術棧來實現，并且可以獨立擴展，從而應對業務的調整。這就意味著服務之間是需要協同工作的，一個應用的輸出會變成另一個應用的輸入，服務之間也可以通過 API 進行有效通訊。同時，由于微服務的隔離機制，導致每個服務都可以進行有效的安全監控。例如使用 Python 開發的服務就不需要其他技術能力的支持，這種情況在微服務開發中普遍存在。

雖然服務內部的技術各有不同，到協同工作時，服務以及對外界的接口和傳輸方式卻可以統一規定。例如使用 (REST) API 的方式進行服務之間的溝通，使用 HTTP 協議傳輸數據，利用統一資源標識符 (URI) 與前端系統(Android/iOS、HTML5/JavaScript)進行溝通。

舉一個例子來說明單體服務和微服務的區別。

???

單體架構類似于希臘的石頭雕像，而微服務類似樂高積木。石雕的某個部分損壞，必須報廢整個雕像，對其進行重造。而樂高積木只需要更換部分組件即可。

顯而易見微服務在架構復雜系統時，是具備優勢的，但是在落地過程中需要平衡速度和安全性。眾所周知微服務在 DevOps 領域以及持續開發持續集成(CD/CI)方面可以提高應用開發和交付的速度，特別適用于復雜業務場景，并且提升交付速度。

但是由于微服務的服務獨立和分散的特點，我們還需要關注每個服務的安全性問題，因此在微服務架構的設計和實施方案中需要考慮通過統一的服務編寫或者實施標準來規避安全風險，這里建議創建“central key deliverable”(中心關鍵交付原則 / 標準)，所有服務都圍繞這個標準進行設計，避免各個服務各自為政。

微服務實施模型

???

第 1 階段：專注于敏捷性和響應性

在線流媒體服務 Netflix 以提供點播服務而著稱，它為用戶提供了優質的 USP 體驗。微服務的架構使得交付周期大幅縮短，開發頻率提高，同時還提供持續的服務交付。

針對應用的特性而言，每個應用所需要的資源量并不是相等的。有些應用可能比其他應用被使用的頻率更高，因此需要更多的資源作為支撐。以核心業務能力作為架構的中心，其他服務作為核心能力的擴充。比如視頻播放就是核心業務，會員點播、訂閱、積分等等就需要圍繞這個核心業務展開，這些圍繞核心業務的服務可以以微服務的形式存在，但需要與核心業務建立良好的調用接口和通訊模式。

因此可以講核心服務與企業服務從以下兩個層面進行定義：

功能層面的擴展：圍繞核心服務的其他服務作為應用功能的擴展，對于 Netflix 而言核心服務無疑是視頻的播放，而其他的周邊服務會根據用戶需求的增加或者改變進行調整。這種根據業務和用戶需求擴展的服務就需要能夠自由擴展，同時也不會影響核心服務，這里就需要使用到微服務的敏捷性特征，定義好擴展服務與核心服務的接口和協議以后，就可以針對用戶需求對服務進行擴展。

資源能力的擴展：如果說功能層面的擴展和業務掛鉤，資源能力的擴展就是和流量掛鉤。由于 Netflix 本質還是資源 / 服務的提供者，而消費資源 / 服務的用戶的數量并不是一定的，如何做到資源的伸縮是 Netflix 需要考慮的問題。在真實業務場景中，用戶的訪問量或者說網站的流量是波動的，那么 Netflix 網站提供的資源也應該隨著用戶的訪問量的變化而及時調整。在微服務架構中就可以靈活地調整這種資源的分配，Netflix 就是針對 5 個用戶使用資源作為步長進行資源擴展或者收縮，實際上在很多計算機技術中也會利用類似的思路解決資源的不確定性。例如 MySQL 中的 VARCHAR 類型也是通過變長的方式擴展字符的存儲空間的。

第 2 階段：管理安全性和源代碼成熟度統一

盡管采用微服務架構每個服務都可以使用不同技術棧完成不同的業務功能，但畢竟所有的服務都是為了完成一個商業目的，同時存在于一個系統中。因此在微服務的實施過程中注重每個單獨服務的安全性管理，以貨幣交易系統為例，如果采用微服務的架構，那么其中的轉賬服務、工資發放服務、零售交易服務都需要遵從相同的安全級別。

這個在微服務實施過程中尤為重要，也是在考驗微服務架構安全管理的能力。換句話說就是針對微服務定義安全準則包括數據安全性、通訊安全性、訪問安全性。甚至提供通用的微服務包裝這些安全規則，其他的服務只需要調用對應的標準服務或者組件即可，這樣即便是使用不同技術棧的服務也能遵循同樣的安全標準。

除了安全標準，微服務還需要對代碼成熟度進行管理，需要標準化每個服務源代碼的成熟度級別，以在服務提供階段提供特定目標和解決方案。但是如果針對每個服務源代碼去定義成熟級別，顯然無法做到架構層面的統一，而且在微服務的開發過程中會有多個團隊共同參與，代碼有可能會被多個繼任團隊維護，因此需要從整個系統的高度去定義代碼成熟度的級別。

不這樣做，服務內部不僅不能應對復雜的業務變化，也無法與整體架構統一做到目標(速度 / 安全性)與系統的可擴展。因此，單個服務的源代碼變更需要與系統整體源代碼的成熟度保持一致，從而降低兩者缺乏同步的長期風險。簡單來說就是單個微服務以及整體架構的代碼成熟度需要保持一致。

眾所周知一個軟件的非功能性需求包括：高性能、可用性、擴展性、伸縮性、安全性。每個維度都可以定義成熟度的指標和級別。例如軟件安全的成熟度模型中就會從監管、構造、確認、部署等四個方面進行定義。每個類別又會分三個等級來定義成熟度的級別，這里不展開說明。

第 3 階段：確保解決方案和系統運營的可擴展性

系統實施之后的返工成本非常高，因此系統設計初期就需要考慮業務擴展以及訪問存儲量的增加，總的來說是要未雨綢繆。特別是在業務場景復雜、商業環境多變的當下，應用架構的擴展和伸縮需要和業務發展以及收入保持匹配，避免兩者出現不一致的情況。例如業務量增長了，系統無法承載高訪問量，又或者業務拓展以后在原有核心功能上增加了其他功能，而系統架構對于功能擴展反映緩慢，又或許無法擴展。

其中需要注意的是，系統的解決方案需要符合業務的擴展、向外能夠兼容第三方軟件、隨著業務增加重新部署周期保持在平均水平、系統的訪問量波動和運營成本保持一致。

另一個需要注意的是系統功能層面需要有長遠考慮，降低系統的復雜性水平，避免后續功能的引入對系統的影響。例如在系統設計初期可以根據實際業務進行接口設計，而針對當時的情況進行業務實現，這樣可以應對業務的變化。

例如創建一個中間平臺，為卡車服務和客戶之間充當中介者的角色，那么就要考慮到接入不同的卡車服務包括：個人卡車用戶、集體卡車用戶、以及平臺。同時也要考慮結算服務，針對不同的結算方式(微信、支付寶、網銀)，又或者針對同一種支付方式的不同支付實體(例如：網銀包括：工商銀行、建設銀行、招商銀行等)建立對應的接口，所有的服務是面向接口進行編程，一旦實現的對象例如支付實體從微信切換成了支付寶，又例如網銀實體從工商銀行切換成了招商銀行，只需要用新的服務實現替換就可以了，服務之間的接口并不需要進行調整。而接口的定義恰恰是在架構設計階段是可以預見的。

第 4 階段：保證單個服務的獨立性和完整性 - 服務即解決方案

整個微服務架構就是多個獨立服務組成的，每個服務就是一個獨立的解決方案，單個服務盡量不對其他服務進行依賴，如果是依賴也是對接口進行依賴。這樣的設計就好像樂高積木一樣，每個服務各司其職，也很容易被替換和擴展。

針對每個服務定義規范的功能描述和輸入輸出參數，以及消息傳送格式，并且將這些信息在系統內部公開，讓其他服務知道該服務所完成的功能和服務邊界是什么。這種方式讓服務與服務之間能夠做到無縫對接，也避免了重復造輪子的尷尬，同時也為數據中臺、服務中臺打下了基礎。

在 Walmart Labs 的案例中，系統架構每月進行多達 30,000 次更新，而這些更新是由 3000 名工程師使用 OneOps 平臺完成的。由于將服務的云化，提高了開發效率降低了開發新業務的難度，提升了組織在不同領域的競爭力。

也就是說公司面對復雜環境時可以利用哪些不變的服務組件(顆粒度足夠小)以及公司對市場以及業務的理解，通過組合、集成、擴展的方式快速高效地搭建新的應用程序，從而快速適合新的業務模式，服務客戶占領市場。

第 5 階段：善用流程、 工具和組織結構

公司需要明白，想讓微服務成功落地就需要對系統構建過程進行改革，不同于傳統單體應用的層級開發模型。開發者工作在不同的層級上，前端、后端、H5 ，甚至在后端中還可以劃分為面向數據庫以及面向業務的開發。這種方式在微服務環境中已經不適用，必須要開發人員知道自己就是微服務的主人，你開發的微服務就是代表你的產品，它會被系統中其他的服務消費，也就是說其他服務就是你的客戶。所以，你必須成為唯一對該服務負責的人，只要和這個服務相關的一切都需要關注，這就迫使開發人員成為全棧工程師，對人、對組織、對開發流程都是較高的要求。

微服務的開發者需要把服務當作產品一樣管理，包括設計、編碼、UI 開發、同時還要保證質量交付和以及運維過程中的故障排除和調試升級。

看上去開發者的責任變大了，不過有一些 DevOps 工具通過持續集成和交付的方式協助微服務的開發，從而確保單點故障 (SPOF) 不會影響其他服務。同時也引入了容器化的部署方式，Docker 的部署方式就是很明顯的例子。Docker 的部署只針對單個服務的范圍，提高了標準化以及利用容器映像 (CI Continued Integration 持續集成) 的效率。比起傳統方式的整體發布來說，無論對發布成本和試錯成本來說，容器化的部署工具都是性價比最高的選擇。

第 6 階段：整體系統實施策略

微服務架構是近幾年隨著業務發展興起的，站在整體系統的角度如何落地微服務架構一直是架構師面臨的問題。新的系統可以完全重新開始，但是對于遺留系統而言要實施微服務架構不是一件容易的事情。

這里提供了三種策略給大家參考，如圖所示：

第一種 Cream Scoop Strategy 冰淇淋勺策略：是 Martin Flower 提出的一種策略，也被稱為扼殺者方法。可以想象有一大桶冰淇淋，這桶冰淇淋就代表現有的架構，可以用勺子從桶中挖出你們想要的冰淇淋，這個挖出的部分就是要做拆分的服務。最終可以將大桶冰淇淋挖出一個個獨立的服務，這里服務包含不同的業務邏輯。這種方式是逐漸修改原有系統，并且逐步對服務進行拆分試錯然后過度到單獨的資源上運行。每次拆分對系統的影響較小，但是整個系統的拆分和重構需要較長時間。

第二種 樂高法策略(搭積木)，把原有的系統想象成一大塊樂高積木，我們只需要往上面添加小的樂高積木模塊就行了，添加的小模塊就是一個個微服務。這樣一來就不用對老產品進行調整，新的功能通過微服務的方式實現并且集成到老的產品中。不過需要通過一種能夠讓微服務與老產品聯系的方法，這里會使用到接口編程以及適配器模式。

第三種是 nuclear 策略，和策略的名字一樣我們需要對老舊系統推到重來，重新打造微服務架構，說起來容易這里需要花費大量分析和重構的時間，這個周期比較長，成本也是較高的。

???

微服務架構實施策略

第 7 階段：調整姿態直面轉型

在微服務架構實施過程中，領導方式和公司文化都起著舉足輕重的作用，無論在何種情況下這兩點都是復雜、模糊且多變的因素。也就是沒有很好的建議和思路，只有見招拆招不斷適應業務的變化調整組織能力和領導方向。不過有一點是可以肯定的，企業需要不斷觀察和分析市場的變化傾聽客戶的聲音，將變革的頻率與市場的波動同步，打造自我學習不斷適應的企業文化。領導方式需要在企業文化的基礎上，不斷對外來需求進行評估，從而開闊視野，簡化最終結果不斷迭代，因為誰也不能保證開發出完美的系統和產品。唯有適應市場的變化，不斷提升自身能力，持續打磨系統，才能立于不敗之地。以終為始，打造領導力，調整組織結構，創建公司文化，讓利益相關者信任并參與進來，形成公司的核心競爭力。

總結

本文從業務發展說起，為了適應復雜多變的業務場景，系統從單體架構進化到了微服務架構。獨立服務、功能可擴展性以及資源的伸縮性讓微服務架構在紛繁復雜的商業環境中占領了一席之地。

但也正因為這些特性增加了微服務落地的復雜度，本文通過 7 個階段模型幫助企業落地微服務架構。包括：

1. 專注敏捷性和響應性：功能和資源層面的擴展;
2. 安全性和源代碼成熟度：創建安全和成熟度標準;
3. 解決方案和系統運營的可擴展性;
4. 服務的獨立性和完整性;
5. 善用流程、工具和組織結構;
6. 整體系統實施策略;
7. 調整姿態直面轉型。

作者介紹

崔皓，51CTO 社區編輯，資深架構師，擁有 18 年的軟件開發和架構經驗，10 年分布式架構經驗。曾任惠普技術專家。樂于分享，撰寫了很多熱門技術文章，閱讀量超過 60 萬。??《分布式架構原理與實踐》??作者。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

???