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

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

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

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

▲

流程考慮：

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密鑰，需要安全和謹慎地進行管理。隨著它們的激增，傳統的解決方案，如在部署時手動插入，不起作用。坦白說，管理的密鑰太多了，微服務需要自動化。

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

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

10. SSL將在哪里終止?

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

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

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

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