Spring Cloud

约 3237 字大约 11 分钟

2025-02-27

1. 微服务架构

1.1 概念

微服务架构（Microservices Architecture）是一种分布式系统架构风格，它将一个大型单体应用拆分成一组小型服务，每个服务运行在自己的进程中，服务间采用轻量级通信机制互相协作，每个服务都围绕业务功能进行设计和开发，并使用自动化部署机制来管理服务的生命周期，这些服务共同组成了一个完整的应用。

1.2 出现和发展

微服务架构的出现和发展是为了应对单体应用的复杂性和可扩展性问题。单体应用的开发和维护成本高，随着应用的功能越来越复杂，单体应用的性能、可靠性、可扩展性等指标也越来越难以满足需求。因此，微服务架构应运而生。

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；

越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。

这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。

1.3 系统架构演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在，系统架构大体经历了下面几个过程：

单体架构 -> 垂直架构 -> -> 分布式架构 -> SOA架构 -> 微服务架构

1.3.1 单体架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。

优点：

简单：一个应用就是一个整体，所有的功能都在一个工程中，所有的模块都耦合在一起，系统的扩展性和可靠性都不好。
易于维护：一个应用就是一个整体，所有的功能都在一个工程中，所有的模块都耦合在一起，系统的扩展性和可靠性都不好。
易于部署：一个应用就是一个整体，所有的功能都在一个工程中，所有的模块都耦合在一起，系统的扩展性和可靠性都不好。

缺点：

性能瓶颈：单体应用的性能瓶颈主要是数据库的性能瓶颈，当数据库的读写请求量过大时，应用的性能就会受到影响。
扩展性差：单体应用的扩展性差，当应用的功能和数据量越来越大时，单体应用的扩展性就会受到影响。
开发效率低：单体应用的开发效率低，当应用的功能越来越多时，单体应用的开发效率就会越来越低。

1.3.2 垂直架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块，而不增加消息模块. 此时单体应用就做不到了，垂直应用就应运而生了。

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成:

电商系统(用户管理商品管理订单管理)
后台系统(用户管理订单管理客户管理)
CMS系统(广告管理营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。

优点：

系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展
一个系统的问题不会影响到其他系统，提高容错率

缺点：

系统之间相互独立，无法进行相互调用
系统之间相互独立，会有重复的开发任务

1.3.3 分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。