微服務(wù)是如何演變的

微服務(wù)的概念產(chǎn)生是順應(yīng)這樣的需求：為了開(kāi)發(fā)出速度更快、更有彈性且用戶體驗(yàn)更佳的應(yīng)用。這個(gè)概念等同于具有可擴(kuò)展性的自動(dòng)化系統(tǒng)，在簡(jiǎn)單的商業(yè)化架構(gòu)上運(yùn)行軟件。應(yīng)用快速開(kāi)發(fā)的需求影響到了全部公司，以及如何看待歷來(lái)業(yè)務(wù)安排的方式。來(lái)自微服務(wù)的新實(shí)踐代表著需要小型團(tuán)隊(duì)以對(duì)于公司來(lái)說(shuō)陌生的方式——自上而下進(jìn)行迭代。這意味著企業(yè)運(yùn)作的方式將獲得徹底的改變。

現(xiàn)在在針對(duì)應(yīng)用架構(gòu)與微服務(wù)的新思考方面，容器生態(tài)系統(tǒng)逐漸成為核心主題。根據(jù)Battery Ventures技術(shù)人員Adrian Cockcroft的說(shuō)法：關(guān)于微服務(wù)有一些基本的原則需要思考。首先，如今構(gòu)建軟件的價(jià)格更為低廉，容器的出現(xiàn)降低了成本。Docker被所有人納入藍(lán)圖——從軟件供應(yīng)商到終端用戶，所有人都在嘗試找出容器的用法，因?yàn)橛盟湍芗涌燔浖慕桓豆?jié)奏。不過(guò)這也代表著要安裝的系統(tǒng)是應(yīng)用級(jí)別的，也就是說(shuō)在應(yīng)用的開(kāi)發(fā)、部署與管理方面出現(xiàn)了不同的需求。

舉個(gè)例子，對(duì)于要處理服務(wù)與堆棧范圍增長(zhǎng)的公司來(lái)說(shuō)，監(jiān)控比以往更加重要。要想解決問(wèn)題，必須對(duì)數(shù)據(jù)日志進(jìn)行分析，而這些日志很可能橫跨臨時(shí)節(jié)點(diǎn)與多項(xiàng)服務(wù)。由于需要細(xì)化監(jiān)控與加強(qiáng)工具，從業(yè)人員能更好地掌握這些構(gòu)建模塊對(duì)于應(yīng)用所依賴的許多潛在微服務(wù)的影響。

那么起作用的是什么呢？從公司與API開(kāi)始：基于微服務(wù)的產(chǎn)品團(tuán)隊(duì)與另一個(gè)基于終端的平臺(tái)團(tuán)隊(duì)之間靠API連接，通過(guò)API調(diào)用以及企業(yè)基礎(chǔ)架構(gòu)持續(xù)作出相應(yīng)的回應(yīng)來(lái)生效。

微服務(wù)被定義為特定背景下松耦合、面向服務(wù)的架構(gòu)，允許在無(wú)需理解其他部件運(yùn)作原理的情況下進(jìn)行更新。整個(gè)服務(wù)是跨公司構(gòu)建的，但所有權(quán)卻在同一個(gè)地方。微服務(wù)架構(gòu)提供了更多系統(tǒng)間的點(diǎn)對(duì)點(diǎn)調(diào)用。消息形式必須靈活，所有部件在無(wú)論哪個(gè)版本中都能運(yùn)作。這意味著在構(gòu)建微服務(wù)架構(gòu)時(shí)，我們需要一些工具來(lái)配置、探索、輸送流量、觀察與構(gòu)建系統(tǒng)。

IBM杰出的工程師兼IBM云計(jì)算中心的CTO Andrew Hately作出了類比：15年前人們可能需要每周查看一下自己的銀行余額，而互聯(lián)網(wǎng)允許人們實(shí)時(shí)查看余額甚至做出進(jìn)一步操作，也許隨著智能手機(jī)的發(fā)展，很多事情都發(fā)生的改變。如今，人們可以即時(shí)訪問(wèn)自己的賬戶收支信息。這種速度與即時(shí)性代表著：在過(guò)去的5-10年內(nèi)，企業(yè)提供服務(wù)的發(fā)展速度必須跟得上社交網(wǎng)絡(luò)與搜索公司發(fā)展的速度。公司必須處理員工、消費(fèi)者、系統(tǒng)與所有可能組合之間的持續(xù)互動(dòng)——就像Hately所說(shuō)的完全互聯(lián)與持續(xù)可用。這意味著企業(yè)流程需要重建，需要將所有東西連接起來(lái)。如果公司不進(jìn)行這方面的嘗試，也無(wú)法提供相應(yīng)功能的話，很快就會(huì)面臨收入減少甚至出局的局面。

Hately表示：“工具非常關(guān)鍵?！?有數(shù)百家網(wǎng)站不支持代碼，收到反饋后，在下一組測(cè)試用例中消費(fèi)者就能使用它了。這種嚴(yán)格的開(kāi)發(fā)過(guò)程提供了一種企業(yè)工作方式，也為微服務(wù)發(fā)展提供了思考方式。DevOps中的ops也會(huì)執(zhí)行這樣的工作。如果你有一小段代碼并為其定義指標(biāo)的話，就能細(xì)分出哪些會(huì)成功，哪些會(huì)失敗。

IBM通過(guò)為消費(fèi)者及內(nèi)部團(tuán)隊(duì)構(gòu)建反饋通道與成功標(biāo)準(zhǔn)，在敏捷、DevOps、精益生產(chǎn)與其他迭代進(jìn)程中結(jié)合最佳實(shí)踐，創(chuàng)建了名為IBM Bluemix Garage Method方法的企業(yè)方法論。IBM Bluemix Garage Method方法將企業(yè)解決方案的可靠性及可測(cè)試性與最新開(kāi)放社區(qū)在規(guī)模質(zhì)量上的最佳實(shí)踐結(jié)合起來(lái)，持續(xù)創(chuàng)新、創(chuàng)建持續(xù)交付渠道并在云平臺(tái)上進(jìn)行部署。這種方法很有價(jià)值，向所有人開(kāi)放資源能夠提高個(gè)人、團(tuán)隊(duì)與全公司的DevOps技能，以及管理與監(jiān)控能力。

軟件相關(guān)的契約

第一代的容器管理平臺(tái)支持這些速度更快的開(kāi)發(fā)進(jìn)程。Docker的產(chǎn)品高級(jí)VP Scott Johnston表示，在Docker Compose中，微服務(wù)促進(jìn)了工具發(fā)展，YAML文件扮演了描述不同組件的清單（manifest）。Compose讓開(kāi)發(fā)人員得以用抽象的方式描述多容器應(yīng)用，它可以描述web容器、數(shù)據(jù)庫(kù)容器、負(fù)載均衡及其間的邏輯關(guān)系，無(wú)需連網(wǎng)或部署存儲(chǔ)。

Engine Yard的Matt Butcher表示：微服務(wù)是軟件相關(guān)的契約。有些人會(huì)辯稱微服務(wù)是正確執(zhí)行的面向服務(wù)架構(gòu)（SOA）。開(kāi)發(fā)者想要的是有用、功能豐富且結(jié)構(gòu)優(yōu)雅的架構(gòu)。微服務(wù)使得軟件開(kāi)發(fā)回歸Unix的根源——將一件事完成得很好。用Unix可以任意輸出命令。微服務(wù)不止在如何優(yōu)秀地完成工作方面，同時(shí)在如何與環(huán)境互動(dòng)方面也表現(xiàn)出契約性。如果運(yùn)行良好，它所做的工作就像是優(yōu)秀的Unix shell腳本。

舉個(gè)例子，Kubernetes清單文件格式扮演著契約的角色，這個(gè)清單提供了所需的來(lái)源細(xì)節(jié)、存儲(chǔ)卷定義、存儲(chǔ)需求等，扮演了強(qiáng)大的DevOps類契約。它讓開(kāi)發(fā)者和運(yùn)營(yíng)者了解想要的內(nèi)容。開(kāi)發(fā)者與運(yùn)營(yíng)者之間的關(guān)系不再如同之前那樣——開(kāi)發(fā)者被迫只管自己的一攤工作。

一張清單可能會(huì)包括應(yīng)用元數(shù)據(jù)，加上具體版本的描述性參數(shù)，其中可能還有多個(gè)清單。也許是一個(gè)實(shí)例、一個(gè)pod清單、一個(gè)復(fù)制控制器（replication controller）或者一個(gè)服務(wù)定義，還有組成文件的已知來(lái)源位置。任意標(biāo)簽可能由圖表中所包括的組件來(lái)定義。

Butcher表示：“應(yīng)用開(kāi)發(fā)者在這方面的體驗(yàn)夠深刻了。一旦出現(xiàn)典型問(wèn)題，就會(huì)說(shuō)丟過(guò)墻去，各管各的，反正有DevOps來(lái)負(fù)責(zé)生產(chǎn)環(huán)境中的運(yùn)行事宜，開(kāi)發(fā)者只負(fù)責(zé)開(kāi)發(fā)，總有一個(gè)切換過(guò)程，往往會(huì)成為各掃門前雪的后果?！?/p>

如果開(kāi)發(fā)者構(gòu)建容器，會(huì)存在一定的水平保證（由抽象層決定）：這些容器的運(yùn)行方式在生產(chǎn)階段與開(kāi)發(fā)階段是一樣的。這已經(jīng)緩解了讓懂得容器這個(gè)基本工具的DevOps專業(yè)人員感到頭疼的大多問(wèn)題。容器化已經(jīng)提供了這種保障，不過(guò)像Helm（Engine Yard所提供的新服務(wù)）之類的產(chǎn)品有助于進(jìn)一步規(guī)范化這種關(guān)系，具體表現(xiàn)為團(tuán)隊(duì)間的契約形式——團(tuán)隊(duì)成員不能再推卸責(zé)任，各掃門前雪了，而要全程參與。

從虛擬機(jī)與Monolith，到容器，再到微服務(wù)

根據(jù)Joyent的CTO Bryan Cantrill的說(shuō)法：容器為原生云架構(gòu)提供了基礎(chǔ)，與傳統(tǒng)的虛擬化形式相比，象征著一種新的應(yīng)用架構(gòu)形式。在使用較大的機(jī)器來(lái)進(jìn)行計(jì)算時(shí)，基于硬件的虛擬化或者傳統(tǒng)虛擬機(jī)流行過(guò)一段時(shí)間。虛擬機(jī)為運(yùn)營(yíng)團(tuán)隊(duì)提供了管理大型整體應(yīng)用的方式，就像Cantrill說(shuō)的“過(guò)于臃腫”，而硬件定義了企業(yè)架構(gòu)。虛擬機(jī)建議在底層之上，承擔(dān)了運(yùn)營(yíng)系統(tǒng)的負(fù)載。但是容器創(chuàng)建了一個(gè)全新而更敏捷的抽象。就是Cantrill的那句話：“應(yīng)用繼續(xù)減肥速成修煉?！?/p>

如今，唯一的麻煩在于如何將虛擬機(jī)和monolith換成容器和微服務(wù)。各家公司還在想方設(shè)法執(zhí)行這種轉(zhuǎn)變，因?yàn)閮煞N方式對(duì)應(yīng)用架構(gòu)、基礎(chǔ)設(shè)施還有公司自身整體的思路都是迥異的。

Cantrill表示：Joyent的開(kāi)源Triton服務(wù)，其目的就是為了簡(jiǎn)化與加速公司向容器與微服務(wù)的轉(zhuǎn)變。它允許開(kāi)發(fā)者簡(jiǎn)化架構(gòu)，只提供容器，不提供虛擬機(jī)。由于無(wú)需配置網(wǎng)絡(luò)等操作，用戶可以通過(guò)閱讀微服務(wù)手冊(cè)，在短時(shí)間內(nèi)完成部署。

Cantrill表示，Joyent公司是Docker Compose的粉絲，因?yàn)镃ompose可以用來(lái)與單獨(dú)的Docker Engine通訊。Docker的遠(yuǎn)程端點(diǎn)由Triton部署，從而虛擬化了整個(gè)數(shù)據(jù)中心。使用這些工具，很容易快速讓一個(gè)完整有彈性的運(yùn)營(yíng)服務(wù)運(yùn)轉(zhuǎn)起來(lái)。正如Cantrill所言：“這是大勢(shì)所趨。”

VMware的CTO Kit Colbert從如何沿著容器之旅前進(jìn)的角度來(lái)觀察市場(chǎng)。VMware著重運(yùn)營(yíng)領(lǐng)域?，F(xiàn)在它開(kāi)發(fā)了一種方式，來(lái)滿足新的開(kāi)發(fā)人員及其需求，不過(guò)是作為基礎(chǔ)架構(gòu)提供商存在。

對(duì)于VMware來(lái)說(shuō)，這家公司將自己視為基礎(chǔ)設(shè)施提供商，而不是以應(yīng)用為中心、面向架構(gòu)的公司。Colbert只看到了對(duì)Cloud Foundry感興趣的消費(fèi)者，不過(guò)也有人想要DIY的方法。VMware正在設(shè)法通過(guò)vSphere集成容器（VIC）與Photon平臺(tái)對(duì)應(yīng)用技術(shù)提供支持。

為了讓消費(fèi)者適應(yīng)使用容器，vSphere集成容器（VIC）讓容器化工作負(fù)載稱為vSphere的重中之重。VIC適合在開(kāi)發(fā)進(jìn)程中運(yùn)行，將容器化最有價(jià)值的一個(gè)方面應(yīng)用在容器中：靈活并具有動(dòng)態(tài)的資源界限。通過(guò)虛擬化，VMware將普通硬件轉(zhuǎn)化為簡(jiǎn)單、可取代的財(cái)產(chǎn)。同樣，通過(guò)在虛擬機(jī)中應(yīng)用Docker端點(diǎn)，vSphere集成容器創(chuàng)建了完全動(dòng)態(tài)邊界的虛擬容器主機(jī)。結(jié)果就是對(duì)傳統(tǒng)與基于微服務(wù)應(yīng)用同樣支持的基礎(chǔ)架構(gòu)，允許IT與開(kāi)發(fā)者的訪問(wèn)。

相比之下，VMware的Photon平臺(tái)是專為原生云應(yīng)用設(shè)計(jì)的。Photon平臺(tái)由最小的管理程序與控制面板組成，專為微服務(wù)提供速度與規(guī)模的服務(wù)。Photon平臺(tái)在設(shè)計(jì)時(shí)還考慮到了開(kāi)發(fā)者通過(guò)API使用時(shí)的易用性，讓這個(gè)平臺(tái)成為一個(gè)提供應(yīng)用程序與快速部署的自助服務(wù)平臺(tái)。

從VMware的角度來(lái)說(shuō)，運(yùn)營(yíng)團(tuán)隊(duì)也在推進(jìn)部署速度?，F(xiàn)在更著重于數(shù)字化體驗(yàn)或者軟件如何提供更多功能方面。很類似我們?nèi)绾慰创谥悄苁謾C(jī)上使用的應(yīng)用。供應(yīng)商可能以聲音很大的揚(yáng)聲器而聞名，不過(guò)服務(wù)的應(yīng)用是否能提供功能？

Colbert詢問(wèn)：“我能依賴它嗎？” 公司必須找出構(gòu)建應(yīng)用，為尋找高質(zhì)量應(yīng)用的消費(fèi)者提供服務(wù)的方式。想要繼續(xù)進(jìn)步，就必須找到這一點(diǎn)。很多擁有外置式、虛擬化基礎(chǔ)架構(gòu)的消費(fèi)者希望：隨著應(yīng)用開(kāi)發(fā)進(jìn)程的加快，解決公司面臨的挑戰(zhàn)。

在微服務(wù)時(shí)代的開(kāi)發(fā)

軟件開(kāi)發(fā)是迭代式的，需要持續(xù)的反饋循環(huán)才能奏效。這也是類似IBM Bluemix Garage Method所提供的工具所提供的功能。不過(guò)大多公司是根據(jù)模型來(lái)執(zhí)行的，這與開(kāi)發(fā)者工作的方式不同。開(kāi)發(fā)者不會(huì)按照銷售、市場(chǎng)推廣、財(cái)務(wù)等部門人員的方式來(lái)工作，開(kāi)發(fā)者不是按照計(jì)劃或方案來(lái)執(zhí)行工作的。軟件開(kāi)發(fā)的過(guò)程有更多的迭代，并非瀑布式自上而下的。

Pivotal的首席技術(shù)Michael Coté表示：“我不知道怎么說(shuō)，不過(guò)真實(shí)世界與軟件世界是完全不同的?！盋oté辯稱：找出軟件開(kāi)發(fā)的方式似乎非常矛盾，不過(guò)事實(shí)上確實(shí)阻止了人們想要根據(jù)一份文檔來(lái)了解一個(gè)巨大機(jī)器的所有部件的工作方式。通過(guò)遵守軟件開(kāi)發(fā)的原則，各家公司找到了自己的辦法，而不是嚴(yán)格遵守固定的計(jì)劃。

Coté認(rèn)為，沒(méi)有執(zhí)行微服務(wù)的固定道路。用微服務(wù)可以在運(yùn)行中和架構(gòu)上獲得靈活性。微服務(wù)根據(jù)簡(jiǎn)單的原則構(gòu)建出真正復(fù)雜的東西。原則越簡(jiǎn)單，所能創(chuàng)造的東西就越復(fù)雜。

不過(guò)，如果把復(fù)雜性轉(zhuǎn)移到其他地方會(huì)發(fā)生什么？Pivotal這個(gè)平臺(tái)管理著復(fù)雜程度。去掉選擇，讓消費(fèi)者無(wú)需考慮網(wǎng)絡(luò)、運(yùn)營(yíng)系統(tǒng)等問(wèn)題。它允許消費(fèi)者將復(fù)雜性放在應(yīng)用堆棧的頂層，在為終端用戶提供服務(wù)時(shí)能夠更好的區(qū)分服務(wù)。Hately表示：“在科技行業(yè)，我們看到了另一個(gè)文藝復(fù)興時(shí)期?！?/p>

同樣地，IBM Bluemix Garage Method也希望簡(jiǎn)化復(fù)雜性，以便讓開(kāi)發(fā)者的工作更有效率，能夠更好地享受自己的工作。所有這些努力都為企業(yè)提供了巨大的機(jī)會(huì)，無(wú)論在技術(shù)還是文化層面。