正如敏捷開發能夠解決工程技術瓶頸，微服務則能夠解決架構層面的瓶頸。

2014年出現的“微服務”理念仿佛一道閃電，讓技術人員意識到這一全新架構風格的重要意義。面向服務架構崛起又復衰落，微服務架構與SOA有何不同？事實上，了解得越多，我越是意識到微服務這一表述并未抓住這場全新軟件革命的精髓。

[[167106]]

微服務的定義已經被眾多既有經驗所限定，Amazon、Netflix、SoundCloud以及Gilt（如今已經被HBC Digital所收購）的實際方案皆屬在此列。企業中的應用隨著時間推移由整體式被拆分為多項具體服務，并通過RESTful API及其它網絡消息收發協議進行彼此通信。

然而，這一理念并不局限于架構模式。各微服務先鋒企業還共享了一套通用型軟件開發方案，其具備類似的組織結構及文化實踐，同時共享云基礎設施與自動化機制的容納能力。伴隨微服務的成功，許多企業都開始遵循類似的方向滿足自身對速度及可擴展性的需求。

敏捷進程

2001年初，一群軟件專家們發布了Agile Manifesto，即敏捷宣言，旨在通過聲明改進軟件開發方式。盡管基本理念并不新鮮——相當于***編程、并發、精簡等元素的結合——但這次統一發聲無疑引起了業界關注。就從那時開始，微服務架構往往被定義為整體型架構的反義詞，宣言本身也區分了敏捷軟件開發與“文檔驅動型重量級軟件開發流程”間的差異。敏捷方案希望利用小型工作增量、頻繁迭代與原型設計等手段同用戶協作，進而擺脫大規模軟件開發中的成本與風險。敏捷方法也伴隨著這一宣言逐漸被行業所認可并接納。

敏捷方法的普及也讓持續集成（簡稱CI）在軟件行業中掀起一股浪潮，而其正是***編程的一種常見實踐方式。CI主張在生命周期早期即引入軟件組件，從而盡可能降低代碼集成給用戶帶來的影響。然而，很多早期采納者發現，這種方式雖然能夠解決編碼瓶頸，但卻帶來了軟件發布難題。而SaaS在部署領域的持續升溫又進一步加劇了這種矛盾。

為了成功實現軟件的頻繁發布，持續交付（簡稱CD）理念于2006年出現，其繼承CI概念并立足于外部軟件交付視角進行應用。CD著重強調以質量為先的“潛在產品增量”思路，將部署流程定義為盡可能快地在產品中引入變更。虛擬化與云計算技術幫助CD獲得了實現這一思路的基礎，而新工具的不斷涌現更是推動了CD實踐潮流。敏捷與CD的結合亦沒有讓人失望，切實改善了生產速度與軟件質量。

然而瓶頸仍然存在。敏捷思路的主要適用范圍在于軟件開發，而CD的出現將范圍進一步擴展至生產部署。在大多數企業中，開發與運維屬于兩種相互獨立的任務定位。2009年，John Allspaw與Paul Hammond做出了一次意義深遠的演講，他們結合自身經驗拿出了解決辦法——從根本上轉變企業文化的DevOps運動。

企業發現，將開發與運維職責結合至同一團隊能夠帶來更理想的實踐交付效率。其中開發者負責設計解決方案，而運維人員則利用工程方法解決程序處理需求。如此一來，日常任務自動化機制將擁有更出色的系統穩定性與彈性。Netflix公司的Simian Army方案就是生產系統彈性測試中的一個典型示例。

遵循“敏捷進程”指引——包括處理軟件開發到部署再到組織的整個體系——的企業現在已經取得了實際成果。但隨著業務復雜性與規模的不斷增長，這些敏捷先驅企業又發現以往將應用作為個體單位的作法會影響系統彈性并缺少穩定的規模伸縮能力。與此同時，其它一些企業則發現，將整體應用拆分開來，從而確保以業務為中心的服務設計理念更加符合敏捷交付與DevOps文化的實際要求。而這，正是微服務架構的真正來源。換言之，微服務屬于敏捷開發的實際體現。

微服務代表敏捷發展進程中的架構構建階段。

尋求敏捷軟件架構

在2013年的一篇博文中，軟件架構師Simon pown談到了未來的敏捷軟件架構發展方向。他指出，敏捷架構并非天然誕生于敏捷開發實踐當中。相反，我們需要主動尋求合適的架構選項。請注意，他在描述中將敏捷軟件架構視為微服務架構的一種契合點：

審視敏捷軟件架構的特點，我們會發現其傾向于使用小型、松散耦合的組件/服務，并以協作方式滿足最終目標。這種架構風格能夠從多種角度帶來敏捷效果。小型、松散耦合的組件/服務可以獨立進行構建、修改與測試，甚至根據要求的變化而調整及替換。這類架構還能夠很好地提供高靈活性及適應性的部署模式，因為新型組件及服務可隨時根據需求進行添加/移除與規模伸縮。

Amazon、Netflix、SoundCloud以及Gilt在達到一定規模水平時也遇到了類似的架構瓶頸。而根據pown的主張，這些企業最終選擇了微服務作為解決方案。

在敏捷發展進程中，我們有必要立足于架構層面汲取經驗教訓。首先，敏捷軟件開發、持續交付、DevOps文化以及微服務架構全部圍繞著同一類目標存在：在盡可能滿足客戶需求的同時，維持良好的軟件質量與系統可用性。各階段在行業中需要一定時間及次序方可過渡完成，而且不同企業所需要的實現途徑亦有所區別。舉例來說，Amazon選擇的架構專注于其組織變化。相比之下，SoundCloud則不斷演進交付方法并針對團隊結構及架構做出調整。

原文標題：Microservice architecture is agile software architecture

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