现阶段而言，容器听起来可能很酷，但这种现状或许不会持续太久。可以预见的是，容器将来也仅仅是一种基础设施。经验丰富的开发人员对部署应用程序的方法和其它几种类型的基础设施可能已经很熟悉了。容器对他们来说没什么大不了的。
然而，通过容器架构应用程序，能为基础设施带来新机遇，并且市场前景巨大，这就是为什么微服务应用程序中的服务比其运行的容器化基础设施要重要得多。
模块化一直是应用程序架构的目标，如今，微服务的设想已成为可能，如何构建这些服务最终决定了它们将在哪里运行以及它们将以何种方式部署。应用程序的功能通过服务满足用户需求，其价值也通过服务来实现。
这就是为什么如果你想充分利用容器，那你应该考虑的不应该仅仅只是容器。你必须关注服务，因为它们是容器启用的关键。
服务和容器
为了便于对话，服务和容器是可以互换使用的，因为容器化应用程序的理想用例是解构到服务中，每个服务都被部署为一个或多个容器。
但是，策略不尽相同。服务是一种隐含的基础设施，更重要的是应用程序体系结构。当您谈到作为应用程序一部分的服务时，该服务是持久性的。例如，在没有登录页面或购物车的情况下，你无法临时拥有一个应有程序，还指望其进展顺意。
另一方面，容器的生命周期在设计之初就被限定在极短的范围内。理想情况下, 在每次部署或还原时, 一旦新的部署生效并且流量被路由到该容器就被终止。因此容器并不持久。如果交货链正常运行，那根本就不重要。只要新部署已存在并且通信流路由到该容器, 就会立即将其杀死。所以容器不是持久的。如果交付链正常运行, 即使容器终止也无关紧要。
微服务，既是一个应用程序，也是一个基础设施术语，它有一些与之相关联的独特元素，从而使它进一步分化。
单个服务可以部署在多个区域。
每个区域都可以有多个版本——例如，A / B测试或Canary版本。
每个服务可能具有不同的生命周期。特定于后端的服务可能比前端服务部署的要少。
它甚至不一定意味着一个服务等于一个容器或一个主机。该服务是来自应用程序中功能的逻辑抽象，并不直接与任何基础设施相关。
以服务为中心意味着什么?
专注于您的服务意味着开发人员不会花时间优化或修改容器编排或配置。如果最终版本的镜像已经准备好，开发者只要关心提交他们的代码就可以了。如果开发人员还需要把容器也纳入考虑范围，那就会打破某种平衡。
开发人员只有在开发环境中才需要考虑容器相关的事宜。开发环境和生产环境之间的平衡非常重要。要确保开发人员正在对正确的Docker镜像进行测试，并能够访问其他服务，而左移QA是缓解“它在我的机器上明明能正常工作”这一问题的唯一途径。这是通过强大的容器镜像仓库实现的。
然而，即使是开发环境也应该被放在最末来考虑。
如何实现以服务为中心的工作流
我希望我可以说，专注于服务是一项独立的开发任务，但其实不是。开发人员已着眼于正在构建的功能，如果他们因容器和业务流程而分心，那也是因为他们是技术狂人，他们想要修补问题，而不是因为他们觉得这是他们的主要职责。
以服务为中心，是团队中的每个人的责任。包括如何架构交付链——不仅要快，而且要避免更广泛的团队需要与之进行交互。因此，“以服务为中心”需要从管理开始，下放到传递链(或DevOps)，再到工具，最终，开发人员要么保留基础设施包，要么可以自由工作。以下是服务重点的三个关键原则:
- 规范开发环境。您可以通过找到一个强大的容器镜像仓库、审查图像和标准化开发人员在其框中的工具来执行此操作。由于服务是独立开发的，其中一个挑战是在整个应用程序的服务中看到新的功能。因此，开发人员每次提交都可以部署的按需集成环境就显得尤为重要。
- 保持不可变，不要只是挂在嘴边。要想要以服务中心，你必须将“基础设施不可变”付诸实践，而不仅仅是嘴上说说。这意味着在部署容器后将不得再进行更改，只能选择运行或删除。严格禁止Snowflake镜像或配置，除了服务本身所需功能之外，不允许访问单个容器。
- 创建可见性。基于服务的应用程序确实有多个单片应用程序的移动部件。这意味着创建可见性并为所有涉众提供访问权限至关重要。可见性还应支持基础设施和应用程序可见性。团队应该能够查看整个应用程序及其中的所有服务，并能检查单个容器。因此对开发团队来说，应用程序的可见性是最重要的。
为避免发生重大故障，DevOps团队还需要尽可能地减少网络和安全性的影响，其目标是尽可能多地卸载编排工具。
专注于服务的目标是避免分心，只专注于服务功能。如果开发人员专注于构建一个伟大的产品，而DevOps则专注于构建***的交付链，那么工具链和流程将会随之就绪以提供支持——如今，这种伟大的产品诞生了，那就是容器和强大的编排工具。
用户总是倾向于使用更优质的应有程序，这就促使公司更加精益求精、日臻完善，至于达到这一目标的机制，并非问题的关键所在。因此，下次您再谈论到容器时，不妨考虑把重点放在如何构建更好的服务上。
