微服务:
系统架构的演变
单一应用架构
早期的互联网应用架构,大量应用服务 功能 集中在一个包里,把大量的应用打包为一个jar包,部署在一台服务器,例如tomcat上部署Javaweb项目
缺点:耦合度高,一台服务器宕机,所有功能停止工作。维护成本高,无法做拓展。
垂直应用架构
把一个单一应用 拆分成几个毫不相干的应用,可以分担流量,减缓压力。比如把一个电商系统拆分成前台系统 管理系统 用户系统,这其中可能会有 重复的地方。
的优点在于:
系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水平扩展。 一个系统的问题不会影响到其他系统,提高容错率。 缺点:
系统之间相互独立, 无法进行相互调用。 系统之间相互独立, 会有重复的开发任务
分布式架构
在垂直应用架构的基础上 比如把一个电商系统拆分成前台系统 管理系统 用户系统 提取公共业务代码为服务层,通过前端表现层去调用服务。但是这几个系统相互独立 调用起来相当复杂 并且导致 比如上面提到的前台系统 管理系统 用户系统相互粘连 耦合度变高
优点:
抽取公共的功能为服务层,提高代码复用性。 缺点:
系统间耦合度变高,调用关系错综复杂,难以维护。
SOA架构
提供一个面向服务的调度中心 统一对服务进行调度
优点:
使用注册中心解决了服务间相互调用的问题 缺点:
仔细一看 图中 服务间会有依赖关系,一旦某个环节出错会影响较大( 服务雪崩 )。服务关心复杂,运维、测试部署困难
微服务架构
基于服务彻底拆分应用 使得每个微小的服务独立运转,即使一个服务宕机也不会影响其他服务的使用!但是这样随之而来的是高成本,每个服务都是独立的,并且可以拓展功能,但是这样运维的压力会很大。
这样也就带来了微服务要处理的一些问题:
资源的分配与调度,服务的治理,服务网关的配置,服务的发现与注册,服务的追踪与容错。