对于大型复杂的应用，微服务架构往往是一个不错的选择。然而，除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付过程方面做一些工作。图1说明了架构、流程和组织之间的关系：图1快速、频繁且可靠的大型复杂应用软件交付需要几个关键的DevOps功能，包括持续交付和持续部署、小型自治团队和微服务架构现在微服务架构说完了，再来看组织和流程。01在软件开发和交付方面的组织成功通常意味着研发团队规模的增加。一方面，这是好事，因为人多力量大。但是当团队壮大时，就像弗雷德·布鲁克斯在《人月神话》一书中提到的，沟通成本会随着团队规模的增加而以O(N^2)的速度增长。如果团队太大，团队的效率往往会因为高昂的沟通成本而降低。想一想，如果每天早上站会的规模达到20人会怎样？解决方案是将大团队分解成一系列小团队。每个团队都足够小，员工人数为8-12人。每个团队都明确负责开发并可能还运营一项或多项实现一项或多项业务功能的服务。这些团队是跨职能的。他们可以独立完成开发、测试和部署等任务，无需与其他团队频繁沟通或协调。Conway定律逆向为了在使用微服务架构时有效地交付软件，您需要考虑Conway定律，它陈述如下：设计系统的组织...通常受组织架构和设计最终结果的约束是组织通信结构的副本。-MelvinConway换句话说，应用程序的架构通常反映了开发它的组织的结构。因此，反向应用康威定律并设计您的组织，使其结构与微服务架构一一对应。通过这样做，您可以确保您的开发团队与服务??一样松耦合。几个小团队显然比一个大团队更有效率。微服务架构允许团队实现一定程度的“自治”。每个团队都可以开发、部署和扩展他们负责的服务，而无需与其他团队协调。再者，当某个服务出现故障或者不满足SLA等要求时，相应的负责人（团队）也很明确。此外，开发组织更具可扩展性。您可以通过添加团队来扩展您的组织。如果单个团队变得太大，他们将被拆分并链接到各自的服务。由于团队松散耦合，您可以避免大型团队的沟通开销。因此，您可以在不影响工作效率的情况下增加人员。02软件开发和交付流程采用微服务架构后，如果还采用瀑布式开发流程，无异于用马去法拉利跑车——我们需要充分利用微服务带来的便利。如果你想通过微服务架构完成一个应用的开发，那么采用像Scrum或看板这样的敏捷开发和部署实践是必不可少的。同时，还要积极践行持续交付和持续部署，这是DevOps中的一个关键环节。JezHumble将持续交付定义为：持续交付能够以可持续的方式安全、快速地将所有类型的变更（包括新功能、配置变更、错误修复和实验）交付给生产环境或用户。持续交付的一个关键特征是软件随时可以交付。它依赖于高水平的自动化，包括自动化测试。持续部署在自动将代码部署到生产的过程中将持续交付提升到一个新的水平。实施持续部署的高性能组织每天多次部署到生产环境，生产中断次数少得多，并且可以从发生的任何事情中快速恢复。微服务架构直接支持持续交付和持续部署。在不搞砸的情况下快速行动持续交付和持续部署（以及更普遍的DevOps）的目标是快速可靠地交付软件。评估软件开发的四个有用指标如下：部署频率：软件部署到生产中的频率。交付时间：从开发人员提交变更到部署变更的时间。平均恢复时间：从生产环境问题中恢复的时间。变更失败率：导致生产出现问题的变更提交百分比。在传统组织中，部署不频繁且交付时间长。尤其是开发人员和运维人员，经常在维护窗口期间熬到最后一分钟。相比之下，频繁（通常一天多次）发布软件的DevOps组织在生产环境中遇到的问题要少得多。例如，亚马逊在2014年每11.6秒将代码更改部署到生产环境中，而Netflix的软件组件交付时间为16分钟。03采用微服务架构时的人为因素采用微服务架构后，不仅技术架构发生了变化，组织结构和开发流程也发生了变化。归根结底，这是对工作环境中的人（如前所述，情绪生物）的一系列变化。如果忽略了人的情绪，那么采用微服务架构将是一个非常纠结和令人沮丧的过程。FTGO的CTOMary和管理团队的其他成员面临着改变FTGO软件开发方式的挑战。畅销书《Managing Transitions》引入了过渡的概念，它描述了人们如何对变化做出情绪反应。它包括以下三个阶段。结束、失落和遗弃：当人们被告知一项将他们拉出舒适区的改变时，这些情绪开始增长和蔓延。人们会谈论他们以前失去的好处。例如，当重组为一个新的跨职能团队时，人们会想念他们以前的同事。再比如，对于负责全局数据建模的团队，每个服务团队负责自己的数据建模，这对他们来说是一种威胁。中立区：在应对新旧工作方式更替的过程中，人们普遍不知道如何应对新的工作方式。人们开始挣扎，不得不学习如何处理新工作。新的开始：最后阶段，当人们以真正的热情接受新的工作方式并开始体验新工作方式的好处时。本书阐述了如何管理转型过程中各个阶段的问题，提高转型的成功率。FTGO显然在单体地狱中煎熬，急需向微服务架构转型。他们还需要对组织架构和发展流程进行调整。为了成功实现这一目标，FTGO必须认真对待这些过渡模式和所有可能的情绪反应。总结单体架构模式将应用程序构建为单个可部署单元。微服务架构模式将系统分解为一组可独立部署的服务，每个服务都有自己的数据库。单体架构是简单应用程序的不错选择，而微服务架构通常是大型复杂应用程序的更好选择。微服务架构通过支持小型自治团队并行工作来加速软件开发。微服务架构不是灵丹妙药：它有很多缺点，包括复杂性。微服务架构模式语言是一组模式，可帮助您使用微服务架构构建应用程序。它可以帮助你决定是否使用微服务架构，如果你选择微服务架构，模式语言可以帮助你有效地应用它。您需要的不仅仅是微服务架构来加速软件交付。成功的软件开发还需要DevOps和小型自治团队。不要忘记采用微服务的人性化一面。您需要考虑员工的情绪才能成功过渡到微服务架构。
