專注服務，而非容器
現階段而言，容器聽起來可能很酷，但這種現狀或許不會持續太久?？梢灶A見的是，容器將來也僅僅是一種基礎設施。經驗豐富的開發人員對部署應用程序的方法和其它幾種類型的基礎設施可能已經很熟悉了。容器對他們來說沒什么大不了的。
然而，通過容器架構應用程序，能為基礎設施帶來新機遇，并且市場前景巨大，這就是為什么微服務應用程序中的服務比其運行的容器化基礎設施要重要得多。
模塊化一直是應用程序架構的目標，如今，微服務的設想已成為可能，如何構建這些服務最終決定了它們將在哪里運行以及它們將以何種方式部署。應用程序的功能通過服務滿足用戶需求，其價值也通過服務來實現。
這就是為什么如果你想充分利用容器，那你應該考慮的不應該僅僅只是容器。你必須關注服務，因為它們是容器啟用的關鍵。
服務和容器
為了便于對話，服務和容器是可以互換使用的，因為容器化應用程序的理想用例是解構到服務中，每個服務都被部署為一個或多個容器。
但是，策略不盡相同。服務是一種隱含的基礎設施，更重要的是應用程序體系結構。當您談到作為應用程序一部分的服務時，該服務是持久性的。例如，在沒有登錄頁面或購物車的情況下，你無法臨時擁有一個應有程序，還指望其進展順意。
另一方面，容器的生命周期在設計之初就被限定在極短的范圍內。理想情況下, 在每次部署或還原時, 一旦新的部署生效并且流量被路由到該容器就被終止。因此容器并不持久。如果交貨鏈正常運行，那根本就不重要。只要新部署已存在并且通信流路由到該容器, 就會立即將其殺死。所以容器不是持久的。如果交付鏈正常運行, 即使容器終止也無關緊要。
微服務，既是一個應用程序，也是一個基礎設施術語，它有一些與之相關聯的獨特元素，從而使它進一步分化。
單個服務可以部署在多個區域。
每個區域都可以有多個版本——例如，A / B測試或Canary版本。
每個服務可能具有不同的生命周期。特定于后端的服務可能比前端服務部署的要少。
它甚至不一定意味著一個服務等于一個容器或一個主機。該服務是來自應用程序中功能的邏輯抽象，并不直接與任何基礎設施相關。
以服務為中心意味著什么?
專注于您的服務意味著開發人員不會花時間優化或修改容器編排或配置。如果最終版本的鏡像已經準備好，開發者只要關心提交他們的代碼就可以了。如果開發人員還需要把容器也納入考慮范圍，那就會打破某種平衡。
開發人員只有在開發環境中才需要考慮容器相關的事宜。開發環境和生產環境之間的平衡非常重要。要確保開發人員正在對正確的Docker鏡像進行測試，并能夠訪問其他服務，而左移QA是緩解“它在我的機器上明明能正常工作”這一問題的唯一途徑。這是通過強大的容器鏡像倉庫實現的。
然而，即使是開發環境也應該被放在最末來考慮。
如何實現以服務為中心的工作流
我希望我可以說，專注于服務是一項獨立的開發任務，但其實不是。開發人員已著眼于正在構建的功能，如果他們因容器和業務流程而分心，那也是因為他們是技術狂人，他們想要修補問題，而不是因為他們覺得這是他們的主要職責。
以服務為中心，是團隊中的每個人的責任。包括如何架構交付鏈——不僅要快，而且要避免更廣泛的團隊需要與之進行交互。因此，“以服務為中心”需要從管理開始，下放到傳遞鏈(或DevOps)，再到工具，最終，開發人員要么保留基礎設施包，要么可以自由工作。以下是服務重點的三個關鍵原則:
- 規范開發環境。您可以通過找到一個強大的容器鏡像倉庫、審查圖像和標準化開發人員在其框中的工具來執行此操作。由于服務是獨立開發的，其中一個挑戰是在整個應用程序的服務中看到新的功能。因此，開發人員每次提交都可以部署的按需集成環境就顯得尤為重要。
- 保持不可變，不要只是掛在嘴邊。要想要以服務中心，你必須將“基礎設施不可變”付諸實踐，而不僅僅是嘴上說說。這意味著在部署容器后將不得再進行更改，只能選擇運行或刪除。嚴格禁止Snowflake鏡像或配置，除了服務本身所需功能之外，不允許訪問單個容器。
- 創建可見性。基于服務的應用程序確實有多個單片應用程序的移動部件。這意味著創建可見性并為所有涉眾提供訪問權限至關重要?？梢娦赃€應支持基礎設施和應用程序可見性。團隊應該能夠查看整個應用程序及其中的所有服務，并能檢查單個容器。因此對開發團隊來說，應用程序的可見性是最重要的。
為避免發生重大故障，DevOps團隊還需要盡可能地減少網絡和安全性的影響，其目標是盡可能多地卸載編排工具。
專注于服務的目標是避免分心，只專注于服務功能。如果開發人員專注于構建一個偉大的產品，而DevOps則專注于構建***的交付鏈，那么工具鏈和流程將會隨之就緒以提供支持——如今，這種偉大的產品誕生了，那就是容器和強大的編排工具。
用戶總是傾向于使用更優質的應有程序，這就促使公司更加精益求精、日臻完善，至于達到這一目標的機制，并非問題的關鍵所在。因此，下次您再談論到容器時，不妨考慮把重點放在如何構建更好的服務上。
