什么是微服务架构
介绍
微服务架构:将原本的一个单体应用拆分成多个应用程序,其中每个微服务运行在自己的进程上,并且能通过自动化部署将其独立发布上线。它们之间通过轻量级的通信机制进行交互,通常服务会根据业务模块进行划分,各个服务职责单一。服务可使用不同的编程语言,不同的数据库,不同的技术栈。
![简单的微服务架构设计](https://lianyp.fun/picture/mark-text-doc/picture/2024/05/31/screen-2024-05-31_11-25-36.230.png)
比较
单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构
- 单体架构
企业发展初期,公司网站的流量不会太大,仅需一个应用即可将所有业务涵盖在内,部署上线。 优点:
架构简单,项目的开发和运维成本很低,通常是三五个人的小团队 缺点
业务代码耦合比较严重,随着项目规模越来越大 ,项目的维护成本很高,特别是互联网发展很快,有些技术不断迭代,需要升级
容错性低,因为模块都耦合在一块,一旦一个模块出问题,将会影响其他模块
无法对项目进行水平扩展
- 垂直应用架构 企业发展到一定规模,因为上述的一些问题,单体应用发展为了 垂直应用架构,将一个应用拆分成互相独立的应用, 优点:
增加了容错性,可以减少因某个应用影响其他应用的运行
各系统分担流量,提高整体的性能,可以独立部署应用,可以对某个应用进行优化 缺点
系统之间独立,无法相互调用,从而导致一些重复开发
- 分布式系统 随着垂直应用的增多,重复代码增多,这时候提出一个概念 第三方接口,我们需要为其他系统提供接口调用。
在分布式系统中,我们将整个系统分为服务层和表现层,其中服务层是具体逻辑实现,而表现层则是与第三方的数据交互操作。 优点
将那些重复的实现代码抽离出来,成为公共服务,不在仅限当前应用调用,提高代码复用性。
系统服务有了更多的优化空间 缺点
公共服务不那么好确定,不仅技术要求更高,而且需要将各个业务都很熟悉。
系统之间耦合性又变高了。
系统之间调用关系难以维护。
- SOA架构 在分布式架构的基础上,部署的服务越来越多则会导致重复的代码也越来越多,这时增加一个调度者的角色,对整个集群进行实时监测管理。 优点
使用[注册中心]解决了各个服务之间的服务依赖和调用关系的自动注册与发现。 缺点
服务之间存在依赖关系,其中一个服务的故障可能会导致服务雪崩
服务之间存在的关系复杂,部署的难度更大
- 微服务应用 在SOA架构的基础上进一步升级,将其彻底拆分为微服务,每个服务拥有自己的数据库,自己的开发语言,自己的技术栈,职责划分明确。 优点:
服务彻底拆分,各服务独立打包、独立部署和独立升级。
每个微服务负责的业务比较清晰,利于后期扩展和维护。
微服务之间可以采用REST和RPC协议进行通信。轻量
缺点:
开发成本更高
架构更复杂
服务的一致性,容错性问题
分布式事务问题
分布式缓存问题