技術乾貨 | 如何規劃基於Docker的微服務架構

今天小數又漂洋過海給你們運來一篇乾貨，在今天的文章中，咱們將一同瞭解如何在Docker上規劃一套成功的微服務架構。

Docker的人氣仍然持續升溫，這主要歸功於其易於打包且可以在任意環境下實現代碼分發的強大能力。而在結合微服務架構的前提下，Docker足以幫助開發者們利用小型模塊化組件構建軟件，並充分發揮各組件功能以應對各種複雜難題。

不過要真正實現微服務架構，咱們須要經過前期規則避免將其誤解爲分佈式總體應用，不然碎片化問題也將隨之而來。從服務設計到部署再到監控，利用Docker進行微服務架構部署中存在着多個須要認真考量的關鍵點。

爲每套容器設計一項服務

在建立新的微服務時，在單一容器內部署多項服務彷佛是種頗具吸引力的優化方式。然而，存在於同一容器實例中時，各服務將沒法獨立實現規模伸縮。

規劃技巧一: 採起每一個容器一項服務的作法可以有效支持微服務的按需規模伸縮，且無需面對由多服務容器帶來的內存與CPU過分佔用問題。

創建服務發現方案

爲了實現規模化與高可用性要求，微服務須要跨越多臺Docker主機進行分佈。請注意，千萬不要在服務當中使用硬編碼形式的主機名稱或者容器IP地址。相反，你們應當在代碼以及負責管理一個或者多個容器實例的Docker基礎設施當中創建服務發現機制，即根據名稱進行服務定位。

規劃技巧二: 選定一項服務發現策略，並確保其可以根據容器實例的規模伸縮進行自動調整。具體選項包括：ZooKeeper、Consul、Etcd、Eureka或者使用內部DNS策略。

經過CDN實現共享資產分發

對於大多數Web應用，其中都會涉及共享資產，例如圖片、樣式表以及JavaScript庫。若是你們使用的是Ruby on Rails之類的框架，那麼asset pipeline將成爲管理這一流程的有效工具。然而，其在生產環境下的管理工做仍然至關困難。由該pipeline在單一容器內生成的資產沒法爲其它容器所共享。解決方案分爲兩種：其一，確保每一個容器實例都可以生成並使用資產（不推薦）；其二，將資產推送至單一共享位置。

規劃技巧三: 利用CDN打理靜態及動態生成的資產。經過這種方式，咱們可以改進瀏覽性能，同時幫助專門設計用於處理輸入API請求的容器實例減輕負擔。其還能簡化容器基礎設施，意味着咱們再也不須要爲跨容器實例資產共享設計額外的實現方式。

外部化、監控並管理微服務

在一套典型雲原生架構當中，進來的的HTTP請求須要跨越各服務器實例進行負載均衡。然而，大多數基於雲的負載均衡器都只能將請求路由至服務器，而非單一服務器上的多個容器。經過在基於HTTP的微服務以前安裝反向代理，輸入的請求可被正確分發至多Docker主機上的任意數量容器實例當中。

除了負載均衡，基於HTTP的微服務可能還須要使用驗證、受權以及速率限制等功能。將服務開放給移動或者公衆/合做開發者時，咱們還須要預防DoS攻擊，並未來自單一外部URL結構的負載路由至內部微服務（例如http://api.example.com/products/ -> http://products.myapp.local/）。

規劃技巧四: 安裝反向代理及/或API管理平臺。目前市面上存在着多種商用及免費開源的產品供選擇，包括：3scale、Apigee、Kong等，也能夠經過nginx的定製化調整實現。

將數據庫部署在容器以外

與配備有網絡塊存儲設備的傳統雲服務器不一樣，容器自身擁有一套獨立於主機以外的隔離化文件系統。容器內的數據會在容器自己被銷燬後一併消失。另外，咱們不可能長時間將容器運行在同一主機當中。所以，在沒有作大量的額外工做的狀況下，將主機文件系統做爲外部卷並不能徹底保障生產數據的持久化。咱們須要更好的數據庫方案，來保障數據的安全和高性能。

規劃技巧五: 在容器以外設置並部署數據庫。使用數據庫即服務方案可以幫助咱們擺脫管理自有實例的困擾，固然立足於容器外創建本身的託管數據庫方案也是可行的。唯一的例外就是，若是你們的微服務中包含只讀數據，則可將其在鏡像建立過程當中打包在容器以內。