摘要：今天小數(shù)又漂洋過(guò)海給大家運(yùn)來(lái)一篇干貨，在今天的文章中，我們將一同了解如何在上規(guī)劃一套成功的微服務(wù)架構(gòu)。通過(guò)在基于的微服務(wù)之前安裝反向代理，輸入的請(qǐng)求可被正確分發(fā)至多主機(jī)上的任意數(shù)量容器實(shí)例當(dāng)中。規(guī)劃技巧四安裝反向代理及或管理平臺(tái)。

今天小數(shù)又漂洋過(guò)海給大家運(yùn)來(lái)一篇干貨，在今天的文章中，我們將一同了解如何在Docker上規(guī)劃一套成功的微服務(wù)架構(gòu)。

Docker的人氣仍然持續(xù)升溫，這主要?dú)w功于其易于打包且能夠在任意環(huán)境下實(shí)現(xiàn)代碼分發(fā)的強(qiáng)大能力。而在結(jié)合微服務(wù)架構(gòu)的前提下，Docker足以幫助開(kāi)發(fā)者們利用小型模塊化組件構(gòu)建軟件，并充分發(fā)揮各組件功能以應(yīng)對(duì)各類復(fù)雜難題。

不過(guò)要真正實(shí)現(xiàn)微服務(wù)架構(gòu)，我們需要通過(guò)前期規(guī)則避免將其誤解為分布式整體應(yīng)用，否則碎片化問(wèn)題也將隨之而來(lái)。從服務(wù)設(shè)計(jì)到部署再到監(jiān)控，利用Docker進(jìn)行微服務(wù)架構(gòu)部署中存在著多個(gè)需要認(rèn)真考量的關(guān)鍵點(diǎn)。

為每套容器設(shè)計(jì)一項(xiàng)服務(wù)

在創(chuàng)建新的微服務(wù)時(shí)，在單一容器內(nèi)部署多項(xiàng)服務(wù)似乎是種頗具吸引力的優(yōu)化方式。然而，存在于同一容器實(shí)例中時(shí)，各服務(wù)將無(wú)法獨(dú)立實(shí)現(xiàn)規(guī)模伸縮。

規(guī)劃技巧一: 采取每個(gè)容器一項(xiàng)服務(wù)的做法能夠有效支持微服務(wù)的按需規(guī)模伸縮，且無(wú)需面對(duì)由多服務(wù)容器帶來(lái)的內(nèi)存與CPU過(guò)度占用問(wèn)題。

建立服務(wù)發(fā)現(xiàn)方案

為了實(shí)現(xiàn)規(guī)模化與高可用性要求，微服務(wù)需要跨越多臺(tái)Docker主機(jī)進(jìn)行分布。請(qǐng)注意，千萬(wàn)不要在服務(wù)當(dāng)中使用硬編碼形式的主機(jī)名稱或者容器IP地址。相反，大家應(yīng)當(dāng)在代碼以及負(fù)責(zé)管理一個(gè)或者多個(gè)容器實(shí)例的Docker基礎(chǔ)設(shè)施當(dāng)中建立服務(wù)發(fā)現(xiàn)機(jī)制，即根據(jù)名稱進(jìn)行服務(wù)定位。

規(guī)劃技巧二: 選定一項(xiàng)服務(wù)發(fā)現(xiàn)策略，并確保其能夠根據(jù)容器實(shí)例的規(guī)模伸縮進(jìn)行自動(dòng)調(diào)整。具體選項(xiàng)包括：ZooKeeper、Consul、Etcd、Eureka或者使用內(nèi)部DNS策略。

通過(guò)CDN實(shí)現(xiàn)共享資產(chǎn)分發(fā)

對(duì)于大多數(shù)Web應(yīng)用，其中都會(huì)涉及共享資產(chǎn)，例如圖片、樣式表以及JavaScript庫(kù)。如果大家使用的是Ruby on Rails之類的框架，那么asset pipeline將成為管理這一流程的有效工具。然而，其在生產(chǎn)環(huán)境下的管理工作仍然相當(dāng)困難。由該pipeline在單一容器內(nèi)生成的資產(chǎn)無(wú)法為其它容器所共享。解決方案分為兩種：其一，確保每個(gè)容器實(shí)例都能夠生成并使用資產(chǎn)（不推薦）；其二，將資產(chǎn)推送至單一共享位置。

規(guī)劃技巧三: 利用CDN打理靜態(tài)及動(dòng)態(tài)生成的資產(chǎn)。通過(guò)這種方式，我們能夠改進(jìn)瀏覽性能，同時(shí)幫助專門(mén)設(shè)計(jì)用于處理輸入API請(qǐng)求的容器實(shí)例減輕負(fù)擔(dān)。其還能簡(jiǎn)化容器基礎(chǔ)設(shè)施，意味著我們不再需要為跨容器實(shí)例資產(chǎn)共享設(shè)計(jì)額外的實(shí)現(xiàn)方式。

外部化、監(jiān)控并管理微服務(wù)

在一套典型云原生架構(gòu)當(dāng)中，進(jìn)來(lái)的的HTTP請(qǐng)求需要跨越各服務(wù)器實(shí)例進(jìn)行負(fù)載均衡。然而，大多數(shù)基于云的負(fù)載均衡器都只能將請(qǐng)求路由至服務(wù)器，而非單一服務(wù)器上的多個(gè)容器。通過(guò)在基于HTTP的微服務(wù)之前安裝反向代理，輸入的請(qǐng)求可被正確分發(fā)至多Docker主機(jī)上的任意數(shù)量容器實(shí)例當(dāng)中。

除了負(fù)載均衡，基于HTTP的微服務(wù)可能還需要使用驗(yàn)證、授權(quán)以及速率限制等功能。將服務(wù)開(kāi)放給移動(dòng)或者公眾/合作開(kāi)發(fā)者時(shí)，我們還需要預(yù)防DoS攻擊，并將來(lái)自單一外部URL結(jié)構(gòu)的負(fù)載路由至內(nèi)部微服務(wù)（例如http://api.example.com/products/ -> http://products.myapp.local/）。

規(guī)劃技巧四: 安裝反向代理及/或API管理平臺(tái)。目前市面上存在著多種商用及免費(fèi)開(kāi)源的產(chǎn)品供選擇，包括：3scale、Apigee、Kong等，也可以通過(guò)nginx的定制化調(diào)整實(shí)現(xiàn)。

將數(shù)據(jù)庫(kù)部署在容器之外

與配備有網(wǎng)絡(luò)塊存儲(chǔ)設(shè)備的傳統(tǒng)云服務(wù)器不同，容器自身?yè)碛幸惶转?dú)立于主機(jī)之外的隔離化文件系統(tǒng)。容器內(nèi)的數(shù)據(jù)會(huì)在容器本身被銷毀后一并消失。另外，我們不可能長(zhǎng)時(shí)間將容器運(yùn)行在同一主機(jī)當(dāng)中。因此，在沒(méi)有做大量的額外工作的情況下，將主機(jī)文件系統(tǒng)作為外部卷并不能完全保障生產(chǎn)數(shù)據(jù)的持久化。我們需要更好的數(shù)據(jù)庫(kù)方案，來(lái)保障數(shù)據(jù)的安全和高性能。

規(guī)劃技巧五: 在容器之外設(shè)置并部署數(shù)據(jù)庫(kù)。使用數(shù)據(jù)庫(kù)即服務(wù)方案能夠幫助我們擺脫管理自有實(shí)例的困擾，當(dāng)然立足于容器外建立自己的托管數(shù)據(jù)庫(kù)方案也是可行的。惟一的例外就是，如果大家的微服務(wù)中包含只讀數(shù)據(jù)，則可將其在鏡像創(chuàng)建過(guò)程中打包在容器之內(nèi)。