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

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

[[167106]]

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

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

敏捷進(jìn)程

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

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

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

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

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

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

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

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

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

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

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

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

原文標(biāo)題：Microservice architecture is agile software architecture

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