最近，有許多微服務(wù)領(lǐng)域的討論，但是這些討論大多都是關(guān)于如何從頭開(kāi)始構(gòu)建微服務(wù)應(yīng)用的，Mark Little認(rèn)為，微服務(wù)的初衷在于改造已有的應(yīng)用，提高其敏捷性，他討論了在這種場(chǎng)景下，實(shí)現(xiàn)微服務(wù)的最佳實(shí)踐。

Mark Little博士是Red Hat中間件部門(mén)的工程副總裁，他領(lǐng)導(dǎo)著JBoss的技術(shù)方向和研究/開(kāi)發(fā)工作。在此之前，他曾經(jīng)擔(dān)任過(guò)SOA技術(shù)開(kāi)發(fā)的主管，并負(fù)責(zé)標(biāo)準(zhǔn)的制訂。

在Mark Little最新的一篇博客文章中，他回顧了自己從事微服務(wù)相關(guān)的一些經(jīng)歷和對(duì)微服務(wù)的認(rèn)識(shí)，他依然愿意在這個(gè)領(lǐng)域不斷思考，并與其團(tuán)隊(duì)成員進(jìn)行交流，從而推動(dòng)行業(yè)思想的發(fā)展。

在這個(gè)過(guò)程中，有些困擾他的問(wèn)題變得逐漸清晰。長(zhǎng)期以來(lái)，人們思考的可能是微服務(wù)與SOA、分布式系統(tǒng)以及DevOps的關(guān)系，而且也有很多的項(xiàng)目和產(chǎn)品來(lái)幫助開(kāi)發(fā)基于（微）服務(wù)的架構(gòu)。但是，除Red Hat以外，大多數(shù)關(guān)于微服務(wù)的文章都是從頭開(kāi)始構(gòu)建的。這其實(shí)也反映了大多數(shù)開(kāi)發(fā)工作的關(guān)注點(diǎn)：從頭（Greenfield）開(kāi)發(fā)，重新對(duì)系統(tǒng)進(jìn)行架構(gòu)，然后完全重建。

不過(guò)，微服務(wù)最初并不是這樣的，如果讀一下最初的文獻(xiàn)的話(huà)，尤其是來(lái)自Netflix的文章，就會(huì)發(fā)現(xiàn)微服務(wù)的理念（或者Adrian Cockcroft最初所說(shuō)的“Adrian Cockcroft”）是與已有系統(tǒng)息息相關(guān)的，它致力于將它們重構(gòu)為組件（服務(wù)），這些組件能夠獨(dú)立地部署、版本化和發(fā)布。這里的理念在于為已有的系統(tǒng)（brownfield）構(gòu)建微服務(wù)。Mark Little雖然一開(kāi)始就知道這些背景，但是一直以來(lái)他始終認(rèn)為這種方式與從頭開(kāi)始構(gòu)建所使用的過(guò)程、工具以及方式都是完全相同的。直到最近，他才意識(shí)到中間的差別。

有些團(tuán)隊(duì)會(huì)基于已有的系統(tǒng)進(jìn)行改造，實(shí)現(xiàn)微服務(wù)，這是很有價(jià)值的。大多數(shù)人所面臨的都是已有的應(yīng)用，就像Netflix那樣，因此這種方式更具有實(shí)用性。它不需要我們好高騖遠(yuǎn)，每次只需進(jìn)步一點(diǎn)點(diǎn)即可，這方面是作者以前所沒(méi)有太多關(guān)注的。為了支持這些微服務(wù)，也需要對(duì)基礎(chǔ)設(shè)施進(jìn)行一些很重要的簡(jiǎn)化。

在一個(gè)樣例中，他們所面臨的是單體應(yīng)用中的已有組件。因?yàn)閳F(tuán)隊(duì)是基于Java EE的，所以具體的表現(xiàn)形式就是多個(gè)WAR（Web Archive）或JAR（Java Archive），這些文件會(huì)放到一個(gè)EAR（Enterprise Archive）中，但是這個(gè)例子本身與編程語(yǔ)言和框架是無(wú)關(guān)的。在這個(gè)例子中，目標(biāo)是將單個(gè)組件拆分為微服務(wù)，這樣當(dāng)某個(gè)WAR中的內(nèi)容發(fā)生變化的時(shí)候就不需重新創(chuàng)建整個(gè)EAR包了。

如果從完全重建的角度來(lái)看，這其實(shí)沒(méi)有實(shí)質(zhì)性的不同。不過(guò)，在分布式場(chǎng)景方面，我們可以采取一些變化，至少可以進(jìn)行簡(jiǎn)化，這里不需要命名服務(wù)（或類(lèi)似的機(jī)制）來(lái)定位各種各樣的服務(wù)所在的位置，同時(shí)也不需要SLA。實(shí)際上，因?yàn)槲覀冎婪?wù)的API，并且這里的目標(biāo)在于提升開(kāi)發(fā)過(guò)程的敏捷性，所以，可以將API硬編碼到“客戶(hù)端”中（應(yīng)用的其他部分）。從事后來(lái)看，很多地方都是可以硬編碼的。可以借助地址綁定或底層的網(wǎng)絡(luò)，如REST/HTTP使用URL來(lái)表示服務(wù)的名稱(chēng)/地址，當(dāng)然，這樣的話(huà)需要DNS實(shí)現(xiàn)綁定。

到目前為止，這是可行的，到一定程度之后，就會(huì)引入傳統(tǒng)分布式系統(tǒng)的復(fù)雜性了，不過(guò)，我們還沒(méi)到那一步。團(tuán)隊(duì)的關(guān)注點(diǎn)在于：“作為開(kāi)發(fā)人員，我該從哪里開(kāi)始擁抱微服務(wù)呢，在不開(kāi)發(fā)、不安裝過(guò)多基礎(chǔ)設(shè)施的前提下，該如何取得成功呢？”。Mark Little認(rèn)為這種方式的簡(jiǎn)化/硬編碼/依賴(lài)基礎(chǔ)設(shè)施能夠在一定程度上提供幫助。

當(dāng)提到微服務(wù)時(shí)，我們經(jīng)常讀到的內(nèi)容就是中心化的日志、事件驅(qū)動(dòng)方式、協(xié)作（orchestration）以及部署技術(shù)，但是，當(dāng)面臨預(yù)先定義的組件/服務(wù)時(shí)，如果我們想借助微服務(wù)來(lái)提升敏捷性的話(huà)，這些技術(shù)其實(shí)并沒(méi)有那么重要。借助硬編碼以及一些自動(dòng)化的方式，完全就能實(shí)現(xiàn)。

這是一種新型的微服務(wù)嗎？事實(shí)上并非如此，這是一種不斷演化的方式，其實(shí)與之前的CORBA和Java EE應(yīng)用并無(wú)分別，我們會(huì)通過(guò)硬編碼、接口的方式進(jìn)行手動(dòng)編碼，隨著分布式應(yīng)用復(fù)雜性的不斷增長(zhǎng)，開(kāi)發(fā)人員需要基礎(chǔ)設(shè)施和工具的更多幫助。所以，這種方式毫無(wú)疑問(wèn)也是微服務(wù)，因?yàn)樗哪繕?biāo)依然是讓團(tuán)隊(duì)更加靈活、具有獨(dú)立的生命周期，只不過(guò)它更加聚焦于某一點(diǎn)，或者說(shuō)更加實(shí)用。

在將已有的系統(tǒng)往微服務(wù)架構(gòu)改造的過(guò)程中，Mark Little所述的這些觀(guān)點(diǎn)，應(yīng)該會(huì)對(duì)我們提供一些借鑒和幫助。