微服务的流程和组织，终于有人讲明白了( 二 ) _微服务

平均恢复时间：从生产环境问题中恢复的时间。

变更失败率：导致生产环境问题的变更提交百分比。

在传统组织中，部署频率低，交付的时间很长。特别是开发人员和运维人员通常都会在维护窗口期间熬夜到最后一刻。相比之下，DevOps组织经常发布软件，通常每天多次发布，生产环境问题要少得多。例如，亚马逊在2014年每隔11.6秒就将代码更改部署到生产环境中，Netflix的一个软件组件的交付时间为16分钟。

03 采用微服务架构时的人为因素采用微服务架构以后，不仅改变了技术架构，也改变了组织结构和开发的流程。归根到底，这是对工作环境中的人（正如之前提到的，情绪化的生物）进行的一系列改变。如果忽略人们的情绪，那么采纳微服务架构将会是一个非常纠结和折腾的过程。FTGO的首席技术官玛丽和其他的管理层，正面临着如何改变FTGO软件开发方式的挑战。
畅销书《Managing Transitions》介绍了转型（transition）的概念，其中阐述了人们如何对变化做出情绪化的反应。它包括以下三个阶段。

结束、失落和放弃：当人们被告知某种变化，这类变化会把他们从舒适区中拉出，这类情绪开始滋生和蔓延。人们会念叨失去之前的种种好处。例如，当被重组到一个新的跨职能团队时，人们会想念他们之前的同事。再比如，对于负责全局数据建模的团队来说，每个服务团队负责自己的数据建模，这对他们是一种威胁。
中立区：处理新旧工作方式交替过程中，人们普遍会对新的工作方式无所适从。人们开始纠结并必须要学习处理新工作的方式。
新的开始：最终阶段，人们开始发自内心地热情拥抱新的工作方式，并且开始体验到新工作方式所带来的种种好处。

本书介绍了如何管理转型过程中每个阶段的问题，提高转型的成功率。FTGO显然正在单体地狱中煎熬，急切地需要转型到微服务架构。他们也需要对组织结构和开发流程做出调整。为了成功地实现这一切，FTGO必须认真面对这些转型模式和所有可能的情绪化反应。

总结

单体架构模式将应用程序构建为单个可部署单元。
微服务架构模式将系统分解为一组可独立部署的服务，每个服务都有自己的数据库。
单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好选择。
微服务架构使小型自治团队能够并行工作，从而加快软件开发的速度。
微服务架构不是银弹：它存在包括复杂性在内的诸多弊端。
微服务架构模式语言是一组模式，可帮助你使用微服务架构构建应用程序。它可以帮助你决定是否使用微服务架构，如果你选择微服务架构，模式语言可以帮助你有效地应用它。
你需要的不仅仅是通过微服务架构来加速软件交付。成功的软件开发还需要DevOps和小而自治的团队。
不要忘记采纳微服务过程中的人性层面。你需要考虑员工的情绪才能成功转换到微服务架构。

关于作者：克里斯·理查森（Chris Richardson），世界十大软件架构师之一，《POJOS in Action》等技术名著的作者，也是著名开源项目 Cloud Foundry 和 Eventuate 的创始人。他的研究领域包括微服务架构设计、分布式数据管理、事件驱动的应用架构、领域驱动设计、持续交付、Spring 框架、Scala、NoSQL 数据库等。

本文摘编自《微服务架构设计模式》，经出版方授权发布。