正如敏捷開發(fā)能夠解決工程技術(shù)瓶頸，微服務則能夠解決架構(gòu)層面的瓶頸。

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

[[167106]]

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

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

敏捷進程

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

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

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

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

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

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

微服務代表敏捷發(fā)展進程中的架構(gòu)構(gòu)建階段。

尋求敏捷軟件架構(gòu)

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

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

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

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

原文標題：Microservice architecture is agile software architecture

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