微服务架构、Docker容器、可编程基础架构、云计算和现代持续交付（CD）技术的新兴组合，使得通过软件开发实现业务价值的真正模式转变成为现实。

美国高德纳公司（Gartner）也实现了同样的转变，在其“2016年应用架构炒作周期”中，研究小组表示微服务架构风格处于“翘首以望的顶峰。” 因此，企业组织在选择采用微服务方面可能会面临一些困难，但是我们认为，成功采用该新型架构风格的首要步骤之一就是整理和确认CD流水线中的功能性和非功能性需求。

三思而后行：需求的可见性和编纂化

为了满足提高业务速度的需求，采用敏捷和紧凑的软件开发方法成为必然。对于仍在坚持采用这些方法的企业组织来说，价值流图和Wardley映射等技巧都是非常有价值的。事实上，许多组织尚未全面了解如何获得最初的商业构想或为最终用户改进功能。

如果没有真正了解整个运送系统中的工作程序，就可能会导致出现延迟交付的情况，而组织方面将受到牵连，其中经常受到责备的是质量保证人员（QA）。因为在软件设计完成并实施过程中，让QA担任质量“把关人”，而他们只是关注于无效的手动工作，完全忽略了交付这一部分，可见QA难辞其咎。

我们强烈支持保持工作的可见性特点，对要求进行编纂归类是可见性需求的必然结果。因为编纂要求有助于自动化，反过来还可以加快速度。只有建立在自动化的基础上，首席执行官和首席信息官才能实现通过软件更加快速地提供价值，并增加安全性的目标。而许多公司都在使用其CD流水线和工作流程中的自定义步骤来编纂和验证需求。其中行为驱动开发（BDD）对于形成和编纂业务假说和行为非常有利。自动性能和安全性测试都具有特定范围的可接受性，并被编入步骤，可以说是现代软件开发领域的重要筹码。

微服务：对用户、架构和运维所带来的宏观影响

康威定律对现代软件开发的影响已经予以很多说法，实际上，微型服务架构风格产生于独角兽公司如Netflix，Gilt Group和Spotify的重组。该过程已经被进一步细化为“反向康威操纵”，即组织故意试图操纵结构和团队协调，以促进软件内的预期架构，即形成具有明确业务目标的小型跨职能团队。自动化平台部署和运营支持应该促成基于微服务器系统的创建。

提供单个微服务并非与生俱来充满挑战，而更大的问题源自于整合。这对于轻而易举解决复杂问题的企业而言特别具有挑战性，需要很多组件一起正常运作才能实现所承诺的价值。面向服务的体系架构 SOA在第一次迭代期间，其解决方案是使用Web服务定义语言（WSDL）来指定服务功能，有效地生成了一份有关测试和验证集成的合同。虽然这是个好主意，但实际上，WSDL可能过于严格，而且跨平台也存在兼容性问题。

随着微服务架构的发展，早期的支持者已经清楚地注意到了整合SOA所面临的挑战。比如，消费者驱动合同（CDC）方法论已经出现在服务的设计和规范中，有些甚至称之为“现代架构的测试驱动设计（TDD）”; 服务虚拟化的演进促进了服务的隔离测试; 并且运行时验证通常在分段运输（或生产）阶段执行，其中新的部署方式（Canary Deployments）和综合业务会对快速路径功能和关键的非功能性要求进行持续测试。

所有这些方法都可以且应该被集成到构建途径中。作为软件顾问的凯夫林·亨尼（Kevlin Henney）建议：汽车因为有了制动，所以可以更快地行驶; 同理，将自动化验证集成到您的连续交付流程中，可以实现传递快速价值的微服务。如果在此过程中出现任何问题，系统会自动敲击部署制动器。

总结

微服务架构类型有很多优势。 Gartner警告说，我们处于“预期高涨的高峰期”。围绕这种做法的炒作不应该被忽视，但是可以通过在软件交付过程中实施持续交付（CD）的合理和结构化的方法来缓解风险。微服务的成功实施并非纯粹停留在建筑层面，而要注意培育正确的组织结构，并传播假设驱动型发展的化以产生全面效益。

最后，验证微服务系统的功能和非功能性要求无论对于个体服务还是综合系统水平都至关重要。我们坚信建立有效且持续的交付流程所带来的力量是非常强大的，并将其视为组织的核心组成部分，旨在融合微服务和现代“云原生”方式以提供有价值的软件。

更多内容推荐：>>>数据中心的消毒技巧