从单体架构到微服务架构||沉潜飞动|君子藏器于身，待时而动。

从单体架构到微服务架构

你好，我是看山。

微服务的优势众多，在现在如果有谁没有听过微服务架构，可以从这里了解一下。本文主要聊一聊是否值得花时间将单体架构重构为微服务架构？

微服务架构是一种架构风格，专注于软件研发效能，主要包括单位时间内实现更多功能，或者软件从想法到上线的整个持续交付的过程。在当前的互联网环境中，业务变化迅速，也促使了微服务架构的普及。这种架构迫使团队迅速反应，快速实施，在方案没有过期之前已经上线运行，经受市场考察和考验。

目前国内大多数公司正在运行的系统都是单体架构系统，不可否认，这些系统在公司发展过程中，发挥了不可替代的作用，保障了公司正常运行，创造了很多价值。但是，随着系统的日渐膨胀，集成的功能越来越多，开发效率变得越来越低，一个功能从想法到实现，需要花费越来越长的时间。更严重的是，由于代码模块纠结在一起，很多已经老化的架构或者废弃的功能，已经成为新功能的阻碍。

众所周知，单体架构随着功能增多，不可避免的是研发效能的降低：研发周期变长、研发资源占用增多。从而引发的情况是：新员工培训时间增多、员工加班时间变长、员工要求涨薪或者跳槽。到了这种情况就说明，单体架构已经不能够满足企业发展需要，这个时候，需要升级架构来提升研发效能，比如微服务架构。

想要说明微服务架构的好处，可以来一个比喻。我们建了一个空间站，为此，我们需要将人、货物和设备运输到空间站中，这个时候，运载火箭是比较好的选择，尽管运载火箭造价也比较高，但是几个月发射一次，也能够满足需求。随着空间站的扩大，火箭发射的间隔变短，运输成本高的离谱，而且越来越没法满足空间站运转需求。这个时候，可以尝试另外一种方式，比如，太空电梯。当然太空电梯的造价成本高于一次飞行的费用，但是只要建成，以后的成本就降低了很多。

这个比喻也是说明了微服务带来的美好期望，同时也说明一个问题，实施微服务架构会带来巨大的投资。所以，我们在建造太空电梯之前需要想好，我们真的需要这种投入，否则只能是一种浪费。

to be or not to be

决定从单体架构升级为微服务架构时，先问问自己下面几个问题：

产品或系统是否经过市场考验
是否需要超过一个团队来保证产品发布
系统是否对可靠性、可伸缩性有较高要求

微服务架构

什么是微服务架构呢？Sam Newman认为是：“一组围绕业务领域建模的、小而自治的、彼此协同工作的服务。”

微服务架构中的服务，是根据业务能力抽取的业务模块，独立开发和部署，但是需要彼此配合完成整个业务功能。服务不是单纯的数据存储组件，那是数据库。也不是单纯的逻辑函单元，那是函数。只有同时包括数据+逻辑，才是真正意义上的服务。

服务边界

服务拆解过程中，DDD（领域驱动设计）可以作为微服务架构的指导方针。因为微服务是围绕业务功能定义服务，根据服务定义团队，这与DDD将业务域拆解为业务子域、定义限定上下文的方法论如出一辙，于是DDD作为微服务的指导方针，快速定义各个服务组件，完成从单体架构到微服务架构的迁移。

Alberto Brandolini提出识别服务上下文的方式叫做“Event Storming”。第一步是识别业务域中发生的事件，也就是说，我们的关注点是行为，不是数据结构。这样做的好处是，系统中不同服务之间是松散耦合关系，而且单个服务能够自治。

定义好了服务边界，还需要定义事务边界。过去，我们的服务在一个进程中，后面挂着一个数据库，事务可以选择强一致性事务，也就是ACID。当服务增多，彼此配合，这个时候可以使用最终一致性事务，也就是BASE。不同于ACID，BASE更加灵活，只要数据在最终能够保持一致就可以了。这个最终的时间范围，根据不同的业务场景不同，可能是分钟、小时、天，甚至是周或者月。

准备工作

微服务架构愿景美好，属于重型武器，优点众多，缺点也很明显。服务增多，运维难度增大，错误调试难度增大。所以需要自动化构建、配置、测试和部署，需要日志收集、指标监控、调用链监控等工具，也就是需要DevOps实践。实现DevOps的三步工作法中说明了实现DevOps文化的三个步骤。

除了上面提到的基础，还需要在早期确定服务之间如何集成和彼此调用方式，还需要确定数据体系，包括事务一致性和数据可靠性方法。随着服务增多，还需要配置管理、服务发现等众多组件。具体需要的基础组件可以参考微服务的基建工作。

这些基础的服务和设计，最好在早期定义，否则，后期需要花费更多的资源才能够完善架构。如果前期缺失，后期也没有补足，造成的后果就是微服务架构迁移失败，最后的系统也只是披着微服务外衣的单体架构。

进化还是革命？

定义好服务边界之后，还有一个问题需要解决：是逐步进化更新系统、还是破釜沉舟重构整个系统。

第二种方式很诱人，比较符合大多数程序猿的思维，系统不行，推倒重来，名为重构。但是在大多数情况下，这种方式不能被允许，因为市场变化迅速、竞争激烈，大多数公司不会停止业务，去等待重构一个能够运行、只是有些缺点的系统。所以，逐步提取更新系统才是王道，大多数公司也能接受。这种方式又被称为绞杀模式。

Transformation

该如何逐步过渡到微服务架构？下面一步步进行展示：

单体架构

第一步，将用户视图层与服务层部分逻辑进行分离。业务逻辑委托给服务层，支持页面展示的查询定向到数据库。这个阶段，我们不修改数据库本身。

部分拆分视图和业务逻辑

第二步，用户视图层与数据库完全分离，依赖于服务层操作数据库。

完全拆分视图和业务逻辑

第三步，将用户视图层与服务层拆分为不同服务，并在服务层创建一个API层，用户视图层与服务层之间通信。

物理拆分视图和业务逻辑

第四步，拆分数据库，将不同业务数据拆分到不同的数据库中，同时对应业务服务层拆分到不同的服务。用户视图层通过API网关与不同业务服务层的API组件通信。这个时候需要注意，如果团队没有微服务开发经验，可以首先抽取简单业务域服务，因为业务简单，实现简单，可以练手，积累经验。

业务服务层拆分、垂直拆分数据库

最后一步，拆分用户视图层。

拆分用户视图层

绞杀模式的优势就在于，我们可以随着业务变化随时调整方案，不会造成整个业务进化过程的停摆。

成功标准

当我们完成了整个升级过程，就需要检查一下我们是否达到了预期的结果。引入微服务的目的首先是改善开发流程，我们可以通过简单的指标来衡量：

开发周期：从概念到上线持续的时间
开发效能：单位时间内团队或个人完成的功能或用户故事
系统可伸缩性
平均维修时间：查找和排除故障所需时间

通过对比老架构和新架构的这些特性值，可以评估升级过程取得的效果。当然，升级过程中也要有这些指标的监控。

最重要的事

作为攻城狮，我们为能够解决或改善周围世界而自豪，着迷于提供解决方案。同时，我们也要意识到，我们付出的每一份努力，都要有回报。如果不能带来任何回报的重构升级，都是浪费时间。