跟着我学微服务，你所在领域业务为什么要微服务化，何时微服务

itbeien2025年3月3日大约 9 分钟

跟着我学微服务，你所在领域业务为什么要微服务化，何时微服务

在上一篇文章中我们学习了什么是微服务和微服务有哪些主流解决方案，今天我们一起探讨你所在组织的业务为什么要微服务化，组织和领域业务发展到哪个阶段需要进行微服务化。

1 为什么要微服务化

我们在谈为什么要微服务化之前，我们先以大文旅和支付领域业务的发展来分析服务架构演进史，来分析每个阶段的优缺点。我所在的组织和领域服务架构一共经历了三个发展阶段

第一个阶段属于业务初期这个阶段属于业务试错阶段，在技术上的投入有限一般采用的都是单体架构，单体架构的优点很明显开发、部署成本低一个小型的开发团队就能搞定。但这种服务架构适合在业务发展初期，如果你的领域模型越来越复杂在后期维护和运维上会有很大问题，比如修改了订单业务的一个小的功能，那么这时候其它模块的功能可能会受到影响。你需要把整体业务从头到尾全部测试一遍，我们当时就遇到这样的问题，非常痛苦。另一方面就是在测试通过后，你要部署你的系统到生产环境，这个时候代码量特别庞大，打包编译的时间会很长，使你团队的工作效率特别低。下图为单体架构

1.2 SOA架构

第二个阶段是SOA（Service-Oriented Architecture，面向服务的架构）架构阶段，该阶段侧重在把业务服务化，但并未达到微服务对服务拆分的粒度，这个阶段的缺点很明显第一个是所有的业务流程都是集中式管理，另外一个是服务之间通信方式采用的较复杂的Webservice模型，当时我们的业务系统采用的是SOA架构中的Webservice模型。SOA其中主流架构模型有 Web Service、企业服务总线和服务注册表。下图为SOA架构中的Webservice模型

1.3 微服务架构

最后一个阶段就是我们今天要重点分析的微服务架构阶段，微服务的主要好处我们等会在下一章节详细分析。下图为微服务架构

为什么要微服务化，微服务就是要解决领域业务在发展的过程中遇到的业务、技术、团队问题。解决单体架构、SOA架构的缺点及这两个阶段无法解决的问题。

2 微服务架构的好处

2.1 技术异构性

随着业务的发展，团队技术的多样性发展是必然要经历的过程，比如对性能要求较高的服务你可以采用运行效率更高的技术，那么这时你的团队就不单单只有一种开发语言了。在单体架构上是不能满足技术异构性特性，一家具有成熟业务场景的公司由于业务的多样性和复杂性对服务高并发、高可用、高性能、高扩展性都有其严苛的要求。我们用下图来了解组织业务中的技术异构性

2.2 弹性

在单体系统中只要有一个功能出现问题，那么系统整体的业务流程就会受到影响，单体系统可以通过将相同的实例部署在不同的机器上降低系统不可用的概率，然而微服务系统本身就能很好的处理服务雪崩、熔断和服务降级问题。微服务系统可以改进弹性，但是还是需要考虑由于网络、服务器本身故障导致的突发情况

2.3 可扩展性

单体系统只能作为一个整体来扩展，无法把其中的业务模块按照要求进行扩展。比如现在系统性能的瓶颈在订单模块，我要对订单模块进行增加硬件或者新增数据存储服务，开发人员只能把整套系统进行部署。这样无法满足细粒度的可扩展要求。微服务化后就能严格的按照各业务系统的运行情况和性能更细粒度的进行扩展。没有性能问题和硬件资源问题的服务就不需要进行扩展。

2.4 简化部署

简化部署我们可以从两个方面来分析

第一代码的打包和编译，比如有一套票务系统系统中有订单、商品、支付、验票、前端API接口等代码。微服务化后拆分为订单微服务、商品微服务、支付微服务、验票微服务、API网关微服务。开发人员在打包编译时单个微服务的代码量比单体架构的代码量少了很多，打包编译速度肯定更快，这样就大大降低了部署的时间和排查错误的时间。

第二从整体上看服务的部署频率也会降低，比如在单体架构中开发人员只修改了订单的某个功能，这个时候还是要对整套系统进行部署，导致其它模块的功能在不需要部署的情况下被动的进行了部署。那么微服务就不会出现这种情况，因为业务与业务之间在拆分微服务的时候就已经隔离了，互相不受影响。

2.5 与组织结构相匹配

当你的所在的业务团队由原有的一个团队发展为5-10个团队或者演进为不同的产品线，如果这时候你的业务系统还停留在对单体架构系统进行开发维护，那么对于你的团队来说就是一个灾难。第一个无法满足对业务功能的快速迭代，所有的开发人员都是对同一套代码同一个代码仓库进行修改。第二票务系统团队修改代码后可能对企业级支付团队的功能有所影响，这时候你找这个团队去沟通由于修改了代码还需要其它他团队来配合一起测试，大大的浪费人力，最重要的是严重的影响到产品迭代开发的效率。所以微服务化很好的解决了组织在发展的过程中很好的与之匹配等问题。