如何規劃基于Docker的微服務？

用微伺服器替代整體應用程式，或者建立新的應用程式，是開發團隊日益增長的考慮因素，這些開發團隊希望提高靈活性，疊代速度更快，并跟上市場變化。通過在不同團隊之間提供更大的自主權，允許他們并行工作，在更短的時間内實作更多的功能，微伺服器提供的代碼不那麼脆弱，進而更容易進行更改，測試和更新。

docker容器适合微服務，因為它們具有自主性，自動化和便攜性。具體來說，docker以其封裝特定應用程式元件及其所有依賴關系的能力而聞名，進而使團隊能夠獨立工作，而無需底層基礎架構或底層基礎來支援其正在使用的每一個元件。

此外，docker使得建立輕量級的隔離容器非常容易，它們可以輕巧。因為應用程式與底層架構解耦，是以它十分輕便并易于使用。而且很容易建立一套新的容器;docker編排解決方案(如docker swarm，kubernetes或aws ecs)可輕松地加速由多個容器組成的新服務，并全部以全自動的方式進行。是以，docker非常适合微服務。

在建構基于docker的微服務解決方案時，有幾個過程和技術設計要考慮。以下10個考慮，有助于開發團隊少走彎路。

如何規劃基于docker的微服務？

▲

流程考慮：

1.現有的微服務将如何更新?

開發人員使用微服務的根本原因是加快開發速度，進而增加對微服務進行更新的頻次。要充分利用微服務，這個過程是至關重要的。

但是，有幾個組成部分組成這個過程，并且在程序的每一步都有決定。讓我們借助三個例子來解釋一下。首先，是否設定連續部署或設定人員按下儀表闆的按鈕來部署新版本。權衡是更高的靈活性，持續部署，或采用手動觸發部署的更嚴格的管理。自動化可以允許以靈活性實作安全性，并允許共同存在的好處。開發人員需要決定他們的工作流程，以及他們需要什麼自動化，以及在哪裡部署。

第二，企業要考慮實際容器建設的重要性。它會在基于本地建立，推送和通過管道嗎?或者将實際代碼首先轉換成産品，然後轉換為一直到生産的docker鏡像?如果使用容器在管道中建造的解決方案，重要的是要考慮将要建立的位置，以及要使用的工具。

第三，要考慮實際部署政策。具體來說，可以通過藍綠色的部署設定來更新微服務體系結構，其中一組新的容器被分離出來，然後删除舊的容器。或者，可以選擇滾動更新，當通過多個服務容器，建立一個新的容器，并将其投入使用。這些決定是多方面的，需要考慮幾個因素，包括目前流量，營運商的技能水準以及技術方向。

2.開發商如何開始全新的服務?

開展新服務是微服務的基本要求。是以，開展全新服務的過程應盡可能簡單。在這方面，一個重要的問題是，“如何讓開發人員以自助服務方式啟動新服務，而不會影響安全性和治理?”它需要通過審批流程，如送出it請求?或者，這将是一個完全自動化的過程?

盡管我建議使用盡可能多的自動化，但這絕對是開發團隊想要提前思考的點，以確定他們正确平衡安全性，治理和自助服務的需求。

3.服務如何配置設定url?

這個問題真的與開創全新的服務緊密相連。需要在每次建立新的url或子上網(例如myurl.com/myservice)時将其配置設定給新服務，并且配置設定它們的過程應該理想地自動化。選項可以包括一個用于手動配置設定url的自助服務門戶或一個程序，其中url被自動配置設定并從docker容器的名稱和應用于docker容器的任何标簽中提取。

再次，就像啟動一項新服務一樣，我建議在盡可能多地使用自動化，是以需要提前花費大量時間思考這個重要的設計點。

4.如何檢測和處理容器故障?

基礎設施的一個關鍵要求是，它不需要“保姆”，如果下降，它可以自我修複和自我恢複。是以，有一個過程來檢測故障是最重要的，以及一個計劃，當它發生時将如何處理。例如，無論是通過網絡檢查還是日志解析，都必須有一個預定義的過程來檢測不再運作的容器應用程式。另外，應該有一個定義的過程，用一個新的替換容器作為一個可能的解決方案。雖然這個過程有許多方法，但設計點是通過自動化來確定滿足要求。

5.每個微服務的代碼如何被組織?

我們需要一個完全自動化的流程來建構和部署新的服務。然而，如果服務的數量很大，那麼管理就會變得很麻煩。是以，應該建立多個版本的程序(每個服務一個)。在這些情況下，每個過程必須保持均勻。

一個非常重要的決定就是每個微服務的結構如何。例如，dockerfile應該始終出現在完全相同的位置，而且dockerfile應該包含該服務的特定内容。同樣，其他檔案(如docker撰寫檔案或aws ecs的任務定義)應始終放在同一個地方。跨所有服務，以便流程可以以均勻的方式一緻運作。

技術考慮：

6.将使用什麼工具在計算節點上安排容器?

排程程式是重要的工具，因為它們配置設定執行作業所需的資源，将工作配置設定給資源和業務流程，確定在需要時可以使用執行工作所需的資源。容器編排有許多工具選擇。通常考慮的是：針對aws客戶的ecs，以及docker swarm或kubernetes為那些希望與供應商無關的解決方案的客戶。企業有幾個角度來決定，包括可移植性，相容性，易于安裝，易于維護，即插即用的能力以及整體解決方案。

7.在同一服務的容器之間使用什麼工具來平衡請求?

高可用性和在環境中擁有多個容器服務的能力使得每個微服務支援多個容器至關重要。對于非叢集服務(例如，内部開發的基于web的微服務)，需要一個外部負載均衡來平衡同一伺服器上不同容器之間的流量。

這是一項重要的技術決策，應該進行徹底的評估。評估中有一些突出的設計要點：會話粘性的要求;計劃擁有的服務數量;每個服務的容器數量;以及想要的任何web負載均衡算法。

8.将使用什麼工具将流量路由到正确的服務?

此設計點與負載均衡緊密結合，因為它直接解決了應用程式負載均衡問題。如前所述，每個服務配置設定單個url或子上下文。當流量達到微服務叢集時，另一個任務是確定進入的流量被傳送到給定流量所針對的url的正确的微服務。

哪個工具最适合應用程式負載均衡。可能要求做出正确決策的兩個關鍵問題是，計劃擁有多少個微服務，以及希望的路由機制複雜度。

9.什麼工具将用于加密?

随着時間的推移，特定應用中的微服務數量增加，應用越來越多地依賴于saas擴充解決方案，安全性同時變得非常重要，更難于管理。對于微服務來進行通信，他們通常依靠證書和api密鑰來對目标服務進行身份驗證。這些api密鑰，需要安全和謹慎地進行管理。随着它們的激增，傳統的解決方案，如在部署時手動插入，不起作用。坦白說，管理的密鑰太多了，微服務需要自動化。

企業需要通過自動化方式來解決需要它們的容器的加密。為儲存加密存儲建立内部解決方案，可以即時解密，并使用環境變量将其注入容器内。

你對這個技術問題的回答取決于你的加密有多少?你期望這個數字如何增長?安全和合規需求;以及如何願意更改應用程式代碼以友善處理。

ssl将在哪裡終止?

一個經常出現的問題，特别是在服務網絡流量的微服務上，ssl應該在哪裡終止?要考慮的典型設計因素包括安全和合規要求。典型的選項是應用程式或網絡負載均衡

某些合規舉措，如hipaa，要求所有流量都被加密。是以，即使在負載均衡上進行解密，也需要在将其發送到運作應用程式的容器之前重新加密。另一方面，在負載均衡上終止的優點是你擁有處理ssl證書的中心位置。當ssl證書過期或需要改變時，以便其盡量做少的更改。

作出設計決策時要考慮的因素包括具體合規性和安全性要求;應用程式加密和解密資料的能力;容器編排平台，因為有些人能夠無縫地加密資料。所有上述的組合應該是你ssl終止決定的基礎。

正确的選擇将對企業的微型服務架構的成功具有長期的影響。設定正确規劃，基于docker的微服務是非常重要的。

本文轉自d1net（轉載）