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

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

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

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

為每套容器設(shè)計一項服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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