我们如何衡量一个微服务实施的成功_如何判断微服务是否运行-优快云博客

本文链接：https://blog.youkuaiyun.com/byronm/article/details/83965233

本文通过分析微服务如何降低人员和技術管理成本，探讨了衡量微服务实施成功的关键指标。在人员管理上，微服务组织结构实现扁平化，降低沟通成本；在技术管理上，通过拆分应用降低复杂性，提升自动化水平，降低发布风险。微服务的成功实施表现为组织的高效运作和低管理成本。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本次介绍的案例来自于我曾经服务过的客户 R，到今天已经5年整了。2013年的国庆后，我加入了客户 R 的其中一个产品团队，这个团队有三个项目：一个项目做日常维护工作（BAU），这是一个长期项目。一个项目开发一些新的功能。另外一个项目就是将现有的 Java 遗留系统进行改造，把这个 Java 应用的一部分功能从 ESB 和内部调用的方式改成用 Sinatra (Ruby 的一个 Restful API 框架) 做的 HTTP 外部调用。

当时我还不知道我们做的东西就是微服务，只是觉得通过自动化测试和持续交付的方式把应用进行了低风险的解耦。降低了系统的复杂性，减少了需要维护代码，也使得在这个代码库上工作的其它团队不受阻碍。同时减少了生产环境的故障和发布风险。

我在这个项目上工作了 8 个月，完成了“一块功能”的拆分。当时我们并没有一个独立的 Ops 团队，所有的运维相关工作都是团队内自己完成的，那时候我们也不区分开发、测试、运维。只是不同的人去认领不同的任务，不会的就现学现用，或者请教Ops 团队。这就是我最早接触的 DevOps ：一个全功能的端到端产品团队。

在 2014 年的时候我们采用 Docker 进行部署，Docker 在当时是个很新颖的东西，所以互联网上相关的材料并不多。于是我们就自己写了一些编排工具来做 Docker 的大规模部署。同一时期，我们接触到了契约测试，并把契约测试应用于我们的微服务上面。并开始使用 Scala 和 Play 框架拆分另外的应用。通过契约测试，我们会把串行的集成测试转化为一些单元测试。由于契约的约束，使得集成测试降级成为了单元测试，大大提升了测试的效率，降低了测试的成本。

你会在各种微服务的书和相关实践中都能看到 Pact 这个工具，这是客户 R 的另外一个顾问公司开发的，也是他们定义了什么叫契约测试。到了2014年底我们把几个接口拆分出来之后，我才知道这是微服务，也理解了什么是 DevOps。

2014 年 11月份我离开了这个团队，开始把在这个团队上的经验推广给不同的客户，才慢慢深入了解了 DevOps 和微服务的概念。同时，客户 R 也开始复制我们之前的成功经验，开始在整个集团内部进行了全面的微服务化改造。

2017 年 4 月份我重新回到这个客户的项目上工作到 2018 年的 9 月份，期间和其它做微服务的团队进行了一些访谈，可以从比较直观的角度来观察这 5 年来微服务改进的效果和经验。

本系列共计 4 篇，分别是《我们如何衡量一个微服务实施的成功》，《成功微服务实施的组织演进》，《成功微服务实施的技术技术演进》，《微服务架构演进中的经验和反思》。本场 Chat 是第一篇《我们如何衡量一个微服务实施的成功》，由于保密的原因，具体的客户、项目、人员名称均为化名。