微服务架构的概念，现在对于大家应该都不陌生，无论使用 Apache Dubbo、还是 Spring Cloud，都可以去尝试微服务，把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务。但是这个过程，具体应该怎么做？现有的条件下到底要不要做微服务？服务拆分成什么粒度才是合适的？遗留的老系统需要如何考虑重构改造？有哪些坑需要我们注意？系统怎么在分布式服务下实现数据的一致性和服务的高可用可伸缩？拆分的过程中系统数量增多，测试、部署、运维、监控，又应该如何处理？

本文将从这些问题的深度分析出发，阐述微服务架构落地的一些设计原则和利弊取舍，结合微服务架构过程的很多最佳实践经验，希望给读者带来一定的启发和思考，避免在实际应用过程中走弯路，能够多快好省的落地实现微服务架构。内容涉及：

1. 微服务架构的发展过程简介
2. 微服务架构的特点与常见特性
3. 微服务架构的常见技术与简单示例
4. 微服务架构存在的一些问题
5. 如何合理拆分微服务
6. 遗留系统应该如何改造
7. 怎么考虑拆分后的数据一致性
8. 系统和服务的高可用可伸缩如何实现
9. 拆分过程的测试和部署如何处理
10. 拆分后的运维和监控如何处理

• “微服务架构”则是由 Fred George 在 2012 年的一次技术大会上所提出（http://oredev.org/oredev2012/2012/sessions/micro-service-architecture.html），在大会的演讲中他讲解了如何分拆服务以及如何利用 MQ 来进行服务间的解耦，这就是最早的微服务架构雏形。
• 而后由 Martin Fowler 发扬光大并且在 2014 年发表了一篇著名的微服务文章（https://martinfowler.com/articles/microservices.html），这篇文章深入全面的讲解了什么是微服务架构。随后，微服务架构逐渐成为一种非常流行的架构模式，一大批的技术框架和文章涌现出来，越来越多的公司借鉴和使用微服务架构相关的技术。
• 2016 年 4 月，Lightbend 公司的创始人兼 CTO、Akka 的作者 Jonas Bonér，发布了一本小册子《响应式微服务架构》，讨论了基于响应式原理的微服务架构，以及如何将其用于构建可扩展，可应对故障的隔离服务，并与其他服务结合以形成一个紧密的整体。

特别值得一提的是，在微服务架构发展的过程中，还有两位技术大牛的影响不可忽视：

• Chris Richardson：《POJOS IN ACTION》与《微服务架构的设计模式》的作者，也是著名开源项目 cloudfoundry 和 eventuate 的创始人，他做了大量的微服务架构相关的方法和实践的探索，这里有其大量的演讲材料和视频：https://chrisrichardson.cn/resource/。
• Sam Newman，Martin Fowler 和 James Lewis 的 Thoughtworks 前同事，《Building Microservices》和《Monolith To Microservices》这两本的作者，前一本中文版叫《微服务设计》，同时也是 2014 年著名的推特论战《单体应用 vs 微服务应用》的主角之一（另外两人分别是 Netflix 的 Adrian Cockcroft 和 Etsy 的 John Allspaw ，具体参见 https://www.csdn.net/article/2014-08-06/2821078）。

软件架构的发展趋势，简单的说可以分为这几个阶段（详细介绍可以参见我的上一个文章《软件架构发展历程分享》或者《高可用可伸缩微服务架构：基于 Dubbo、Spring Cloud 和 ServiceMesh》一书）：

说了这么多，那么到底什么是微服务和微服务架构呢？ 具体包含如下特征：

• 高可维护性和测试性
• 松耦合性
• 可独立部署
• 围绕业务能力进行组织
• 一个小团队对其完全负责 微服务架构能够快速、频繁和可靠地发布大型的复杂应用系统，也能够使得组织可以进化出自己的技术栈。

Peter Lawyer 说，微服务很多地方特别像是 Mike Gancarz 总结的 Unix 哲学：

• 小即是美（Small is beautiful）
• 让程序只做好一件事（Make each program do one thing well）
• 尽可能早地建立原型（Build a prototype as soon as possible）
• 可移植性比效率更重要（Choose portability over efficiency）
• 尽可能地榨取软件的全部价值 Use software leverage to your advantage.

微服务架构就是 Unix 哲学在分布式系统里的应用。微服务架构的哲学本质上等于 Unix 哲学里的“让程序只做好一件事”：

• 服务都很小，细粒度地执行单个功能。
• 组织文化应拥抱自动化部署和测试。这减轻了管理和运维的负担。
• 文化和设计原则应拥抱失败和错误，类似于抗脆弱系统。
• 每个服务都是弹性的，回弹性的，可组合的，最小化的和完整的（弹性和回弹性参见响应式微服务）。

从这里我们可以得出一个结论，一个微服务架构的系统需要满足一系列的条件和原则，而不仅仅是说使用了某个微服务的技术框架就是微服务架构。微服务这个词目前也过于流行以致于有些泛滥了。很多技术组件或者框架，例如可以用来暴露服务，可以用来自动化部署，可以用来管理配置等等，它们都可以用来作为微服务架构设计时的某个组成部分。但是单独用一个，并不代表我们实现了微服务设计，而只能说明我们借鉴了一些微服务的思想。另一方面，我们在做微服务的时候，也不用把市面上所有的微服务组件都拿来用。就像是我们写个业务系统不会用到 JDK 的所有 API，画一幅画之前我们买了一盒 24 支的水彩笔，实际上我们可能做一幅作品最终只用到了 5-6 个颜色的水彩笔。

现在让我们分析一下上一节里的各个技术大牛们阐述的技术观点，从设计开发、系统部署、测试运维和服务治理四个主要方面来考虑微服务架构的特点，那么这四个方面就可以总结为下图： 微服务架构首先是一个分布式的架构，其次我们要暴露和提供业务服务能力，然后我们需要考虑围绕这些业务能力的各种非功能性的能力。这些分散在各处的服务本身需要被管理起来，并且对服务的调用方透明，这样就有了服务的注册发现的功能需求。

同样地，每个服务可能部署了多台机器多个实例，所以，我们需要有路由和寻址的能力，做负载均衡，提升系统的扩展能力。有了这么多对外提供的不同服务接口，我们一样需要有一种机制对他们进行统一的接入控制，并把一些非业务的策略做到这个接入层，比如权限相关的，这就是服务网关。同时我们发现随着业务的发展和一些特定的运营活动，比如秒杀大促，流量会出现十倍以上的激增，这时候我们就需要考虑系统容量，服务间的强弱依赖关系，做服务降级、熔断，系统过载保护等措施。

以上这些由于微服务带来的复杂性，导致了应用配置、业务配置，都被散落到各处，所以分布式配置中心的需求也出现了。最后，系统分散部署以后，所有的调用都跨了进程，我们还需要有能在线上做链路跟踪，性能监控的一套技术，来协助我们时刻了解系统内部的状态和指标，让我们能够随时对系统进行分析和干预。这六种能力总结如下图：

这个图 x 轴是系统复杂度，y 轴是开发的生产力，我们可以看到：

• 在系统复杂度很低的时候，单体的生产力要高一点，这是因为拆分微服务，管理这些服务的成本增加了
• 当复杂度开始增加，单体的生产力快速的降低，而微服务则不太受影响，这是因为复杂度大了，单体牵一发而动全身，各种耦合和相互影响太多
• 随着复杂度越来越高，微服务的低耦合开始减低了生产力的衰变，而单体架构的生产力则会降到一个非常低的水平

具体怎么做微服务呢？我们先看看大家最常简单见到的微服务的图： 在互联网出行业务中，用户通过 API 网关访问系统的乘客、司机、出行三个 REST 服务，这三个服务再通过 REST 访问计费、支付和通知三个服务。看起来很简单，也好理解，但是实际的业务系统里，设计和实现一般会是这样：

• 服务框架：我们可以选择用 Spring Cloud 或者 Apache Dubbo，包括新兴的 Spring Cloud Alibaba，还有华为贡献的 Apache ServiceComb，蚂蚁金服的 SOFAStack ，Oracle 的 Helidon，Redhat 的 Quarkus，基于 Scala 语言和 Akka 的 Lagom，基于 Grails 语言的 Micronaut，基于 Python 语言的 Nameko，基于 Golang 语言的 go-micro，支持多语言混编的响应式微服务框架 Vert.X，腾讯开源的 Tars，百度开源的 Apache BRPC（孵化中），微博的简化版 Dubbo 框架 Motan 等等。

• 配置中心：Apollo，Nacos，disconf，Spring Cloud Config，或者 Etcd、ZK、Redis 自己封装

• 服务注册发现：Eureka，Consul，或者 Etcd、ZK、Redis 自己封装

• 服务网关：Zuul/Zuul2，Spring Cloud Gateway，nginx 系列的 Open Resty 和 Kong，基于 Golang 的 fagongzi Gateway 等

• 容错限流：Hystrix，Sentinel，Resilience4j，或者直接用 Kong 自带的插件

• 消息处理：Kafka、RabbitMQ、RocketMQ，以及 Pulsar，可以使用 Sping Messaging 或者 Spring Cloud Stream 来简化处理

• Sping Cloud 与 Apache Dubbo、Spring Cloud Alibaba

  可以看到很多组件都是由 Netflix 贡献的。

  而 Apache Dubbo 定位是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。所以，我们可以看到 Dubbo 提供的能力只是 Spring Cloud 的一部分子集。

  同时 Dubbo 项目重新维护以后，捐献给了 Apache，项目的导师就是 Spring Cloud 的核心人员。自这时候起 Dubbo 项目就开始在适合 Spring Cloud 体系，结果就是 Alibaba 也基于自己的一系列开源组件和技术，实现了 Spring Cloud Alibaba，并顺利从 Spring Cloud 孵化器毕业。详见：https://spring.io/projects/spring-cloud-alibaba

  Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。主要功能和开源技术栈：

  • 服务限流降级（Sentinel）：默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
  • 服务注册与发现（Nacos）：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。
  • 分布式配置管理（Nacos）：支持分布式系统中的外部化配置，配置更改时自动刷新。
  • 消息驱动能力（Apache RocketMQ）：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
  • 分布式事务（Seata）：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。。

  可以看到，基本上功能都比较完备了。

《管理的常识》一书里说，管理的核心是不断的解决（推进工作过程中出现的各种）问题。同样地，我认为架构的核心则是不断的解决（系统设计实现与演化过程中的各种）问题。

Fred Brooks 在《人月神话》里说，“没有银弹”，现在依然成立，微服务也并不是只有优点，没有副作用，把系统拆分了了很多部分，每一个部分简单了，但是整体的关系变复杂了。前面介绍了那么多微服务的特点和优势，以及相关技术，我们再来分析一下微服务存在的问题，进而讨论什么场景适合使用微服务，什么场景不适合，以及最佳的实践方式。

微服务架构首先是一个分布式系统架构。分布式系统的发展由来已久，但是近年来产生了理论和实现的大爆发。

究其原因：分布式系统的发展得益于廉价 pc 硬件使得堆机器成为可能，而单机的成本/容量是非线性的，所以分布式的核心是线性的水平扩展整个集群的功能，以及带来的协调机制，管理复杂度，数据和状态一致性，容错和故障恢复，容量与弹性伸缩，这些通用性的基础能力建设。

简单的翻译一下：单个机器堆资源，升级 CPU 内存加大一倍，想要增加一倍的处理能力且成本不超过一倍，不仅很难、而且不现实了。这样，我们就需要思考怎么通过进一步对于系统里不同功能的部分，拆解开，单独扩展这些能水平扩展的部分，从而在控制成本的前提下，提升整个系统的处理能力。

另外，我们现在都知道，设计系统如果对可靠性，可用性有非常高的要求，那么需要先假设上下游都是不可靠的，依赖的基础设施和网络也是不可靠的，这样就考虑分布式后的分片、复制、故障转移、灾难恢复等，分布式系统下，我们可以对系统的不同性质的节点、不同可靠性可用性要求的组件，做针对性的单独处理。

很多系统看起来是分布式的，其实是一个大单机。 很多系统看起来是微服务的，其实是一个大单体。

就像人月神话里说的，往已经延期的项目，加人手，可能会导致更延期。问题不是出现在应不应该加人，或者应不应该使用分布式上。而是实施的人，没搞清楚关键。比如系统拆成分布式或微服务，然后某个关键地方依然卡住了业务流程，可能整体还不如单机的，扩展性失效，多加机器还不如单机。

同样的，如果我们拆分了很多更小独立的服务，但是一个业务请求进来，还是在一些地方被卡住，导致有一些瓶颈使得整个拆分后并不比之前有整体的改进，那么其实是费劲的做了一个大单体系统。

所以合理的拆分微服务，使得我们能够更好的扩展系统是关键，同时如果业务简单，流量不大，不扩展也可以很好的应对，系统对于可用性和一致性要求也不是特别高，那么分布式和微服务，也不是必须的。

以下几类系统，比较适合使用微服务架构，或者使用微服务架构改造：

• 大型的前后分离的复杂业务系统后端，业务越复杂，越需要我们合理的设计和划分，长期的维护成本会非常高，历史包袱也很重，这个问题后面会详谈。
• 变化发展特别快的创新业务系统，业务快，就意味着天天要“拥抱变化”，每一块的业务研发都要被业务方压的喘不过气，不做拆分、自动化，一方面研发资源永远不够用，活永远干不完，另一方面不停的在给系统打补丁，越来质量越低，出错的可能性也越来越大。
• 规划中的新大型业务系统，如果有能力一开始就应该考虑做微服务，而不是先做单体，还是发展到一定的阶段再做改造，改造一定是伤筋动骨的大手术，虽然我们可以采取一些策略做得更平滑，但是成本还是比较高的。
• 敏捷自驱的小研发团队，拥抱新技术，可以直接用微服务做系统，不但的通过快速迭代、持续交付，经过一定时间的尝试和调整，形成自己的微服务实践经验，这样在团队扩大时可以把好的经验复制到更大的团队。

反过来，以下几类系统，不太适合一开始就做微服务，

• 小团队，技术基础较薄弱，创业初期或者团队新做的快速原型，这个时候做微服务的收益明显比单体要低，快速把原型做出来怎么方便怎么来，用团队最熟悉的技术栈。
• 流量不高，压力小，业务变化也不大，单体能简单搞定的，就可以先不考虑微服务，不考虑分布式，因为分布式和微服务带来的好处，可能还不足以抵消复杂性增加带来的成本。
• 对延迟很敏感的低延迟高并发系统，低延迟的秘诀就是离 io 能多远就多远，离 cpu 能多近就多近，分布式和微服务，导致增加了网络跳数，延迟就没法降低。
• 技术导向性的系统，技术产品，这类产品跟业务系统不同，常规的业务系统研发方法不是太适合。

Chris Richardson 在 http://blog.daocloud.io/microservices-1/提到了微服务的几个不足：

• 服务大小：『微服务』强调了服务大小，有人强调服务要大一点，也有人愿意采用小服务。需要注意这只是一种选择，微服务的目的是有效的拆分应用，实现敏捷开发和部署。
• 进程通讯：微服务应用是分布式系统，由此会带来分布式固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些，需要考虑 RPC 的超时、重试、失效策略，或者消息服务不可用，堆积堵塞等问题。
• 数据库拆分：数据库事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式事务并不一定是好的选择，不仅仅是因为 CAP 理论，还因为很多中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
• 测试复杂度：比如采用流行的 Spring Boot 架构，对一个单体式 web 应用，测试它的 REST API，是很容易的事情。反过来，同样的一个业务场景，需要测试启动和它有关的所有服务，这些服务在不同的进程，所以变得尤为复杂。
• 服务依赖关系：微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务 A、B、C，而 A 依赖 B，B 依赖 C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务 C，然后是 B，最后才是 A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。特别是，如果要处理的服务间依赖是一个网状关系，那么很可能导致，我们修改 A 时，考虑到了会影响 BCDEF 这几个服务，但是漏掉了影响系统 K，导致上线以后发现 K 的部分功能无法使用了。
• 部署复杂度：部署一个微服务应用也很复杂，一个分布式应用只需要简单在负载均衡服务后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。而一个微服务应用一般由大批服务构成。例如，根据 Adrian Cockcroft，Hailo 有 160 个不同服务构成，NetFlix 有大约 600 个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制，以用来发现与它通讯服务的地址（包括服务器地址和端口）。传统的解决问题办法不能用于解决这么复杂的问题。接续而来，成功部署一个微服务应用需要开发者有足够的成熟部署方法，并高度自动化。

Peter Lawyer 有在 https://vanilla-java.github.io/2016/03/22/Micro-services-for-performance.html 中提出，微服务的几个问题：

• 服务形成信息障碍。
• 引入了额外的复杂性和新问题，例如网络等待时间，消息格式，负载平衡和容错。忽略其中之一属于“分布式计算的谬误”。
• 测试和部署更加复杂。
• 整体应用程序的复杂性仅转移到网络中，但仍然存在。
• 细粒度的微服务已被批评为一种反模式。
• 如何合理拆分微服务，粒度如何控制：对业务按粒度和边界拆解的问题，这决定了我们的服务是不是合理，开发和维护是不是方便。核心思路是深入了解业务。
• 遗留系统应该如何改造，从哪儿下手，如何推动：改造遗留系统一般来说比重新做一个新系统更复杂，如何平滑的、最大代价的将老系统改造成微服务，也是一个巨大挑战。
• 拆分后的性能应该如何保障：性能有两个指标，关键是区分出来如何处理不同特性的数据，关注不同的指标，做好优化和选型，针对具体细节具体对待。
• 怎么考虑拆分后的数据一致性，分布式事务的选取和取舍：多个服务间的业务数据一致性的问题，事务是个需要重点考虑的问题，主要是考虑强一致性的分布式事务还是可以使用最终一致的弱一致性。对于一般的业务，可能使用补偿冲正类的做法，在业务允许的一定时间内数据达到一致状态即可，比如 30s，或者 10 分钟。
• 系统和服务的高可用可伸缩如何实现：高可用意味着系统稳定健壮，可伸缩意味着弹性，资源有效使用，如何做到无状态、不共享，是实现可高用可伸缩的关键。
• 拆分过程的测试和部署如何处理，怎么提升管理能力，降低风险：跨系统的协作问题、测试的问题，这对于技术能力和研发成熟度较低的团队，会带来很大麻烦。核心思路定义好业务边界、系统间接口与数据标准，提升自动化测试水平。微服务架构由于拆分粒度较细，测试是个大问题。在保持每块职责单一的同时，关键是保证接口稳定，做好自动化测试（特别是 UT 和接口的自动化）和持续集成，尽量少全流程的人工回归测试。部署单元太多导致维护成本上升的问题，要管理的点多了，问题自然复杂了，核心思路是自动化部署与运维。
• 拆分后的运维和监控如何处理：怎么应对系统的故障，关键是保障核心技术的指标，以及业务指标，做好预警报警，积累问题、寻找根因，控制和杜绝低级失误。

当一个系统服务化的时候，就会面临一个问题：如何进行服务的划分？怎么确定服务的粒度？有没有一些可以参考的业界通用规则？

实际上服务划分的本质是对系统进行架构设计，服务的划分粒度没有绝对的过大或过小之说，不同阶段的侧重点和思考的角度也不尽相同。创业初期的团队，过分的追求微服务，为了“微”而微，反而会导致业务逻辑过于分散，技术架构过于复杂，团队基础设施搭建能力弱，进而导致忽略了快速迭代交付产品的重要性，可能错失了市场机会。所以，关于服务的划分不是对错的选择题，而是需要综合考虑各种外界的因素，所作出的一个最适合的决策，这些外界因素通常包括业务、技术债、开发、运维、测试这

五个方面：

• 业务所处领域的市场性质：对市场比较敏感的项目，创业初期粒度应该尽量划分的粗一些，先提供充足的弹药去占领市场，然后再去考虑对系统进行重构和优化；
• 与原有系统之间的关系：对于历史遗留的系统，需要做好新旧系统之间的边界划分，避免过于激进、过大幅度的改造，应该采取小步快跑的方式，有节奏的对老系统进行服务化改造；
• 开发团队的成熟度：服务化带来的技术风险应该提前进行评估，要考虑团队的承受度，用合适的人做适合的事，考虑团队需要有包括敏捷，包括 Devops，包括基础设施，运维和测试的自动化等基础能力；
• 基础设施的搭建能力：在进行细粒度的服务划分时，要考虑团队是否有足够的能力来支撑大量服务实例运行的运维复杂度，是否可以做好分布式的日志追踪和服务的监控；
• 测试团队的测试执行效率：过于细粒度的服务划分，如果测试团队不能通过自动化测试、自动回归、压力测试、极限测试等手段来提高测试执行效率，必然会带来测试工作量的大幅度上升，进而影响整个项目的上线周期；

如果没有特别强烈的大规模水平扩展需求，拆分就没有必要，反而把问题搞复杂了。进行服务化的拆分时，通常会先按照业务子系统先进行一次划分，根据业务逻辑和数据的关系划分为若干个子系统，然后再考虑子系统内部是否可以再次进行拆分。至于拆分的基本原则，我推荐：

• 高内聚低耦合：这个已经提了很多了，简单说一下，就是要把强相关的部分，总是会一起改动的部分，聚合到一起，相关性不大的部分拆开，可以参考 DDD 中的一些办法。
• 粗粒度服务：服务的粒度要稍微的抽象和粗粒度一些，因为服务是基于业务场景的抽象和设计，不能做成是直接把数据库的增删改查暴露出来成接口和方法，而是应该隐藏这些细节，考虑清楚从业务和客户角度来看，哪些步骤和过程，是必须封装起来的，细节隐藏掉，然后对外提供的就是粗粒度的服务，而在单体系统的时候，我们可以直接调用这些细节，无需过多考虑。

其中准备阶段主要是梳理清楚了依赖关系和接口，就可以思考如何来拆，第一刀切在哪儿里，即能达到快速把一个复杂单体系统变成两个更小系统的目标，又能对系统的现有业务影响最小。要尽量避免构建出一个分布式的单体应用，一个包含了一大堆互相之间紧耦合的服务，却又必须部署在一起的所谓分布式系统。没分析清楚就强行拆，可能就一不小心剪断了大动脉，立马搞出来一个 A 类大故障，后患无穷。

2）不同阶段拆分要点不同，每个阶段的关注点要聚焦

拆分本身可以分成三个阶段，核心业务和非业务部分的拆分、核心业务的调整设计、核心业务内部的拆分。这三个阶段，第一阶段将核心业务瘦身，把非核心的部分切开，减少需要处理的系统大小；第二阶段。重新按照微服务设计核心业务部分；第三阶段把核心业务部分重构设计落地。拆分的方式也有三个：代码拆分、部署拆分、数据拆分。代码直接体现了依赖关系，拆完就可以单独打包部署。但是有时候，我们可以通过控制一些提供服务的开关，使用同一份代码和打包的程序，部署多组进程，每组提供不同的服务，这就是部署拆分，比如同一份代码，我们部署了 3 组机器，A 组 5 台提供订单服务，B 组 2 台提供用户服务，C 组 2 台提供任务调度处理任务。数据拆分最复杂，涉及到代码的调整，SQL 和事务的分析和重构，数据库表的拆分甚至数据迁移，数据结构的调整和数据迁移则一般意味着需要停机维护。这三个方式，可以在适当的条件下选择先做哪个操作合适。 另外，每个阶段需要聚焦到一两个具体的目标，否则目标太多反而很难把一件事儿做通透。例如某个系统的微服务拆分，制定了如下的几个目标：

1. 性能指标（吞吐和延迟）：核心交易吞吐提升一倍以上（TPS：1000->10000），A 业务延迟降低一半（Latency：250ms->125ms），B 业务延迟降低一半（Latency：70ms->35ms）。
2. 稳定性指标（可用性，故障恢复时间）：可用性>=99.99%，A 类故障恢复时间<=15 分钟，季度次数<=1 次。
3. 质量指标：编写完善的产品需求文档、设计文档、部署运维文档，核心交易部分代码 90%以上单测覆盖率和 100%的自动化测试用例和场景覆盖，实现可持续的性能测试基准环境和长期持续性能优化机制。
4. 可维护性指标：建立全面完善的监控指标、特别是全链路的实时性能指标数据，覆盖所有关键业务和状态，缩短监控报警响应处置时间，配合运维团队实现容量规划和管理，出现问题时可以在一分钟内拉起系统或者回滚到上一个可用版本（启动时间<=1 分钟）。
5. 易用性指标，通过重构实现新的 API 接口既合理又简单，极大的满足各个层面用户的使用和需要，客户满意度持续上升。
6. 业务支持指标：对于新的业务需求功能开发，在保障质量的前提下，开发效率提升一倍，开发资源和周期降低一半。
7. 核心人员指标：培养 10 名以上熟悉核心交易业务和新系统的一线技术人员，形成结构合理的核心研发人才梯队。

结果可想而知了，目前太多了，反而没有目标。最后第一阶段只选择了稳定性作为最重要的指标，先稳住系统，然后再在后面的阶段里选择其他指标，逐步实现各个目标。

3）快速迭代，找到突破口，持续产出

4）大胆假设，小心求证，稳步上线

凡事不破不立，拆分改造过程，我们每一次改动的地方，可能有多个不同的方案和路径，具体选择哪一个最合适，这需要我们放开思路，大胆假设，充分吸收各方面的意见和想法，然后小心谨慎的去测试，甚至在线上做验证，保障万无一失后，最后上线。

5）保障质量，不断重构和改善现有设计和代码

所有的事物都有产生，发展，衰退和消亡的过程。长期来看，软件系统的代码质量肯定是会一直下降的，就像是人的身体健康，到了一定的程度，就会难以为继，需要重构或者重做。而不断的重构，改善现有的设计集合代码，就像是一直在保养身体，可以减缓衰老，保证健康，增加寿命。

6）取得领导和业务方的支持，过程和决策透明化

拆分改造看起来，没有给系统带来明确的可见收益，比如没有明显改进了用户体验，也没有给系统新增了一个业务功能，但是却涉及到多方参与，付出劳动，这就必然会带来很大的阻力，怎么办呢？还是从《管理的常识》一书里，我看到了一个很有道理的话：”如果无法推动问题背后的人解决问题，那说明对问题挖掘的还不够深“。现代化的工作教会我们，双赢/多赢是协作的唯一办法，也是可以持续的办法。搞清楚怎么才能推动各个合作方的支持，怎么才能让领导同意，如果我们现在提的意见，他们不同意，那么他们关心的点是什么，怎么把他们关心的点，纳入到这个工作范围里来，从而实现大家可以达成一致来合作。同时需要注意的是，信息一定要透明，决策要公开，让大家都直接参与到这个过程，从而明确目标，一致前行。

总结成 48 字箴言的“微服务拆分核心价值观”：

1. 功能剥离、数据解耦
2. 自然演进、逐步拆分
3. 小步快跑、快速迭代
4. 灰度发布、谨慎试错
5. 提质量线、还技术债
6. 各方一致，过程透明

理想中的系统拆分改造效果（实际上一般最后都鸡飞狗跳）：

大家可以先思考 2 个问题：延迟（latency）和吞吐量（throughout）有什么关系？ 延迟是响应时间么？

先说一下延迟和响应时间，延迟是对于服务本身来说的，响应时间是相当于调用者来说的（更多的内容可以参考《数据密集型应用系统设计》一书）：

• 延迟（latency） = 请求响应出入系统的时间
• 响应时间（ResponseTime）= 客户端请求开始，一直到收到响应的时间 = 延迟 + 网络耗时

理想状态下，延迟越低，吞吐越高，当然这是对单机单线程而言的，在分布式下就不成立了，举个反例：

比如从密云水库，拉一个水管到国贸，水流到国贸，需要 1 小时；如果再拉一个水管到顺义，20 分钟就可以。如果你在国贸用水龙头接水，你可以单位时间接到非常多的水，这个数量跟你在过国贸还是顺义，没有关系，只跟水库单位时间输入的水量/水压有关系。但是如果你在水管里放一个小球，它从密云到国贸的时间是到顺义的时间的三倍，这样对于到国贸的这个水管系统，延迟很高，但是系统的吞吐量跟到顺义的是一样的。

同理，如果一个单体系统，被拆分成了 10 个服务，假如一个业务处理流程要经过 5 个服务，这 5 个服务只要是每个吞吐量（TPS/QPS）不低于原先的单体，那么整个微服务系统的吞吐量是不变的。

相反地，我们通过服务变小，关系变简单，数据库简化，事务变小等等，如果 5 个系统的吞吐都比原来的系统打，那么改造后的系统，整体的吞吐也比之前要高。那么这个过程的副作用是什么呢？

简单的说，就是延迟变高了，原来都是本地调用，现在变成了 5 次远程调用，假设每次调用的网络延迟在 1-10 毫秒（物理机房+万兆网卡可以很低，云环境下比较高），那么延迟就会比之前增加增加 5-50 毫秒，而且前提是分布式下的请求，使用异步非阻塞的流式或消息处理方式，同步阻塞会更高，而且影响吞吐量。好在低延迟的系统要求比较少见，对于一般的业务系统来说，可以水平扩展的能力比延迟增加几毫秒要重要的多。

比如我们在淘宝或者京东，买个衣服，交易步骤的处理，在秒级都是可以接受的，如果是机票、酒店、电影票之类的，分钟级以上都是可以接受的。