對于單塊架構(gòu)的系統(tǒng),初始的技術(shù)選型嚴(yán)重限制將來采用不同語言或框架的能力。如果想嘗試新的編程語言或者框架,沒有完備的功能測試集,很難平滑的完成替換,而且系統(tǒng)規(guī)模越大,風(fēng)險(xiǎn)越高?;谖⒎?wù)架構(gòu),使我們更容易在遺留系統(tǒng)上嘗試新的技術(shù)或解決方案。譬如說,可以先挑選風(fēng)險(xiǎn)最小的服務(wù)作為嘗試,快速得到反饋后再決定是否試用于其他服務(wù)。這也意味著,即便對一項(xiàng)新技術(shù)的嘗試失敗,也可以拋棄這個(gè)方案,并不會對整個(gè)產(chǎn)品帶來風(fēng)險(xiǎn)。
該圖引用自Martin Fowler的Microservices一文
獨(dú)立測試與部署
單塊架構(gòu)系統(tǒng)運(yùn)行在一個(gè)進(jìn)程中,因此系統(tǒng)中任何程序的改變,都需要對整個(gè)系統(tǒng)重新測試并部署。 而對于微服務(wù)架構(gòu)而言,不同服務(wù)之間的打包、測試或者部署等,與其它服務(wù)都是完全獨(dú)立的。對某個(gè)服務(wù)所做的改動,只需要關(guān)注該服務(wù)本身。從這個(gè)角度來說,使用微服務(wù)后,代碼修改、測試、打包以及部署的成本和風(fēng)險(xiǎn)都比單塊架構(gòu)系統(tǒng)降低很多。
按需伸縮
單塊架構(gòu)系統(tǒng)由于單進(jìn)程的局限性,水平擴(kuò)展時(shí)只能基于整個(gè)系統(tǒng)進(jìn)行擴(kuò)展,無法針對某一個(gè)功能模塊按需擴(kuò)展。 而服務(wù)架構(gòu)則可以完美地解決伸縮性的擴(kuò)展問題。系統(tǒng)可以根據(jù)需要,實(shí)施細(xì)粒度的自由擴(kuò)展。
錯(cuò)誤隔離性
微服務(wù)架構(gòu)同時(shí)也能提升故障的隔離性。例如,如果某個(gè)服務(wù)的內(nèi)存泄露,只會影響自己,其他服務(wù)能夠繼續(xù)正常地工作。與之形成對比的是,單塊架構(gòu)中如果有一個(gè)不合格的組件發(fā)生異常,有可能會拖垮整個(gè)系統(tǒng)。
團(tuán)隊(duì)全功能化
康威定律(Conway’s law)指出:一個(gè)組織的設(shè)計(jì)成果,其結(jié)構(gòu)往往對應(yīng)于這個(gè)組織中的溝通結(jié)構(gòu)(organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations)。傳統(tǒng)的開發(fā)模式在分工時(shí)往往以技術(shù)為單位,比如UI團(tuán)隊(duì)、服務(wù)端團(tuán)隊(duì)和數(shù)據(jù)庫團(tuán)隊(duì),這樣的分工可能會導(dǎo)致任何功能上的改變都需要跨團(tuán)隊(duì)溝通和協(xié)調(diào)。而微服務(wù)則倡導(dǎo)圍繞服務(wù)來分工,團(tuán)隊(duì)需要具備服務(wù)設(shè)計(jì)、開發(fā)、測試到部署所需的所有技能。
4. 微服務(wù)快速開發(fā)實(shí)踐
隨著團(tuán)隊(duì)對業(yè)務(wù)的理解加深和對微服務(wù)實(shí)踐的嘗試,數(shù)個(gè)微服務(wù)程序已經(jīng)成功構(gòu)建出來。不過,問題同時(shí)也出現(xiàn)了:對于這些不同的微服務(wù)程序而言,雖然具體實(shí)現(xiàn)的代碼細(xì)節(jié)不同,但其結(jié)構(gòu)、開發(fā)方式、持續(xù)集成環(huán)境、測試策略、部署機(jī)制以及監(jiān)控和告警等,都有著類似的實(shí)現(xiàn)方式。那么如何滿足DRY原則并消除浪費(fèi)呢?帶著這個(gè)問題,經(jīng)過團(tuán)隊(duì)的努力,Stencil誕生了。 Stencil是一個(gè)幫助快速構(gòu)建Ruby微服務(wù)應(yīng)用的開發(fā)框架,主要包括四部分:Stencil模板、代碼生成工具,持續(xù)集成模板以及一鍵部署工具。
Stencil模板
Stencil模板是一個(gè)獨(dú)立的Ruby代碼工程庫,主要包括代碼模板以及一組配置文件模板。
代碼模板使用Webmachine作為Web框架,RESTful和JSON構(gòu)建服務(wù)之間的通信方式,RSpec作為測試框架。同時(shí),代碼模板還定義了一組Rake任務(wù),譬如運(yùn)行測試,查看測試報(bào)告,將當(dāng)前的微服務(wù)生成RPM包,使用Koji給RPM包打標(biāo)簽等。
除此之外,該模板也提供了一組通用的URL,幫助使用者查看微服務(wù)的當(dāng)前版本、配置信息以及檢測該微服務(wù)程序是否健康運(yùn)行等。
[
{
rel: "index",
path: "/diagnostic/"
},
{
rel: "version",
path: "/diagnostic/version"
},
{
rel: "config",
path: "/diagnostic/config"
},
{
rel: "hostname",
path: "/diagnostic/hostname"
},
{
rel: "heartbeat",
path: "/diagnostic/status/heartbeat"
},
{
rel: "nagios",
path: "/diagnostic/status/nagios"
}
]
配置文件模板主要包括NewRelic配置,Passenger配置、Nagios配置、Apache配置以及Splunk配置。通過定義這些配置文件模板,當(dāng)把新的微服務(wù)程序部署到驗(yàn)收環(huán)境或者產(chǎn)品環(huán)境時(shí),我們立刻就可以使用Nagios、NewRelic以及Splunk等第三方服務(wù)提供的功能,幫助我們有效的監(jiān)控微服務(wù),并在超過初始閾值時(shí)獲得告警。