这篇文章是在新的DZone指南的连续交付的特色。获得你的免费副本，更多的专家意见，优化你的CD管道，行业统计，等等。 随着软件组织不断投资于实现其应用程序的连续交付（CD），我们看到人们对微服务架构的兴趣与日俱增，从表面上看，微服务架构似乎是实现CD的自然选择。在微服务（或其前身"SOA"）中，业务功能被分解为一组独立的、自包含的服务，这些服务通过API相互通信。每个服务都有自己的应用程序发布周期，并且通常使用最适合工作的不同语言、技术堆栈和工具独立开发和部署。通过将单一的应用程序拆分为更小的服务并分离相互依赖性（在应用程序、开发团队、技术、环境和工具之间），微服务允许您在扩展组织生产力时获得更大的灵活性和灵活性。虽然开发方面的进展可能更快，但微服务确实会带来体系结构的复杂性和管理开销，特别是在测试和操作方面。曾经是一个具有自包含流程的应用程序，现在是通过网络连接的一组复杂的编排服务。这会对您的自动化测试、监控、治理和所有不同应用程序的合规性产生影响，等等。实现连续交付的一个关键先决条件是自动化整个管道—从代码签入，到跨不同环境的构建、测试和部署—一直到产品发布。为了更好地支持这个复杂过程的可管理性，重要的是要利用一个平台，它可以作为任何基础设施或特定工具/技术之上的一层，并能够集中管理和协调您的工具链、环境和应用程序。我想重点介绍一下微服务对您的管道的影响，以及为您的微服务驱动的应用程序启用CD的一些最佳实践。管理微服务交付管道的挑战"单/微"混合状态从零开始设计微服务是非常困难的。当您从微服务开始（作为一个提示：只有在您已经拥有可靠的CI、测试和部署自动化的情况下才考虑微服务），建议从一个单一的应用程序开始，然后逐步将其不同的功能划分为单独的服务。请记住，您可能需要在一段时间内支持这种单/微混合状态。如果您正在重新构建遗留应用程序，或者正在为具有确保安全性和法规遵从性的既定流程和要求的组织工作，则这一点尤其正确。当您重新设计应用程序时，您还需要设计您的交付管道以支持CD（稍后我将对此进行更多的扩展）。DevOps过程和自动化必须能够处理和跟踪"传统"（更长期）的应用程序发布过程，以及更小的批处理、微服务/CD发行版，这一点很重要。此外，您需要能够独立管理多个微服务（既可以独立管理，也可以作为一个集合）来管理，以便不仅能够连续地提供每个单独的服务，而且还可以提供整个服务。管道变化增加微服务的一个主要好处是，它们让开发人员有更多的自由选择最好的语言或技术来完成任务。例如，您的购物车可能是用Java编写的，但是企业消息传递总线使用Erlang。虽然这使开发人员能够"快速"并鼓励团队所有权，但是您的管道自动化需要支持的大量服务和不同的技术也在大幅增长。这种对灵活性的需求在管道的复杂性、可重用性和可重复性方面带来了挑战。您如何最大限度地发挥您的努力，并跨不同的技术和工具重用已建立的自动化工作流？确保治理和法规遵从性由于有如此多的独立团队和服务，以及工具和流程的多样性，大型组织正在努力使交付管道标准化并发布审批流程，从而在安全性、合规性和可审计性方面将微服务纳入其中。如何验证您的所有微服务都符合要求？如果有漏洞或故障，哪个服务是罪魁祸首？你如何跟踪谁签了什么，到了什么环境，为哪种服务，以及在谁的批准下？你下一次如何通过审核？服务之间的集成测试变得更加复杂当你在一个简单的测试单元中测试时，你会很好的验证你所做的事情。微服务的测试更加复杂，需要更多的协调。您需要决定如何处理其他服务的下游测试：您是否针对当前正在生产中的其他服务的版本进行测试？您是否针对尚未投入生产的其他服务的最新版本进行测试？您的管道需要允许您在服务之间进行协调，以确保您不会针对即将过时的服务版本进行测试。支持异构环境的扩散微服务通常会导致您现在需要管理的部署激增。这是由于跨不同堆栈/环境的每个服务的独立部署管道，整个管道中环境数量的增加，以及需要采用现代部署模式，如蓝色/绿色、金丝雀等。部署自动化是CD的关键先决条件之一，微服务需要你做很多。您不仅需要支持大量的部署；您的管道还必须验证环境和版本是否兼容，连接的服务是否受影响，以及基础设施是否得到适当的管理和监视。虽然不太理想，但有时您需要同时运行服务的多个版本，这样，如果某个服务需要某个版本并且与较新的版本不兼容，它可以继续运行（如果您不总是向后兼容的话）。此外，微服务似乎很适合Docker和container技术。随着开发团队变得更加独立，并在容器中部署他们的服务，Ops团队面临的挑战是如何管理容器的扩展，以及如何洞悉该容器中到底发生了什么。系统级视图和发布管理系统级可视性不仅对法规遵从性至关重要，而且对于技术和业务方面的有效发布管理也是至关重要的。对于当今微服务驱动的应用程序来说，复杂的发布版本，您需要一个单一的窗格来了解整个pathof应用程序发布过程的实时状态。这样，您就可以确保按计划、按预算和正确的功能设置。知道你的购物车服务将按时交付，如果你不能很容易地指出关键的ERP服务和所有相关的应用程序的状态，这对你没有好处。为微服务设计CD管道的最佳实践您希望将微服务作为一种更频繁地扩展和发布更新的手段，同时为操作人员提供一个平台，不仅可以支持开发人员，还可以在生产中操作代码并能够对其进行管理。因为微服务是如此的分散，所以要跟踪和管理应用程序中所有独立但又相互关联的组件就更加困难了。你的目标应该是自动化微服务驱动的应用程序的发布，这样这些应用程序才是可靠的、可重复的和尽可能无痛的。在构建管道时，请记住每个服务使用一个存储库。这种隔离将降低工程师将代码交叉填充到不同服务中的能力。每个服务都应该有独立的CI和部署管道，这样您就可以独立地构建、验证和部署。这将使设置更容易，需要更少的工具集成，提供更快的反馈和更少的测试。将您的所有工具链插入DevOps自动化平台，这样您就可以协调和"自动化所有事情"：CI、测试、配置、基础设施配置、部署、应用程序发布过程和生产反馈循环。您的解决方案必须与工具/环境无关，这样您就可以支持每个团队的工作流和工具链，无论它们是什么。您的解决方案需要灵活以支持任何工作流—从最简单的两步web前端部署到最复杂的部署（例如在复杂的测试矩阵或嵌入式软件过程的情况下）。您的系统需要扩展以服务于无数的服务和管道。持续交付和微服务需要大量的测试以确保质量。确保您的自动化平台与所有测试自动化工具和服务虚拟化集成。审计能力需要自动构建到您的管道中，这样您就可以在后台记录每个工件通过管道时的日志。您还需要知道谁签入了代码、运行了哪些测试、通过/失败的结果、在哪个环境中部署了代码、使用了哪个配置、谁批准了它等等。您的自动化平台需要使您能够尽可能地规范化您的管道。因此，请使用应用程序/环境和管道流程的参数和建模，以便可以在服务/团队之间重用管道模型和流程。为了实现可重用性，应该通过统一的UI来规划发布管道和任何配置或建模。通过绑定某些安全检查和验收测试，将符合性放入管道中，并使用infrastructu