微服务的演变史
1.单体应用架构
在项目体量小的时候,所有的功能都放在一个工程中,并且打包部署在一个Tomcat容器中的架构模式就是单体应用架构.
优点:
- 架构简单,开发节奏快,易于小团队快速迭代
- 易于测试部署,只需要通过单元测试和打包单一的jar启动即可
缺点:
- 随着功能扩展,团队扩大,单个项目代码混乱,不适合多人共同维护.
- 新增业务难度大,需要了解整个项目的逻辑,并且业务直接耦合度高,容易互相影响
2.垂直应用架构
为了避免单体架构中的问题,便开始对项目进行模块的垂直划分,基于业务特性做分割,实现业务之间的互不影响.
优点:
- 系统拆分实现流量分担,解决了并发问题
- 单个模块直接的更新互不影响,方便水平扩展,负载均衡,容错率高.
缺点:
- 服务之间互相调用,若ip或端口变动,则需要调整配置
- 建立集群之后,实现负载均衡比较复杂,机器迁移可能会导致线上故障
- 服务之间调用方式不统一,如httpclient,webservice等
- 服务监控不到位,如调用成功率,失败率,耗时等
3.SOA应用架构
在使用垂直应用架构之后,随之而来的问题就是服务之间调用的问题,比如接口协议不统一,无法监控到服务状态,服务的负载均衡处理等.
这个时候,阿里巴巴开源的Dubbo出现了,一款高性能,轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现.
SOA(Service-Oriented Architecture)架构,即面向服务的架构,根据实际业务,将系统拆分成独立的模块,模块之间通过Dubbo,WebService等技术通信.
优点:
- 分布式,解耦合,可扩展,可重用
缺点:
- 服务抽取粒度较大,服务调用方和提供方耦合度较高
4.微服务应用架构
相比SOA架构,粒度更细致,强调组件化,服务化.以及引入了SpringCloud微服务技术.
优点:
- 微服务很小,每个服务聚焦于特定业务,方便上手,以及重用组装
- 微服务很独立,每个微服务可以使用不同的语言开发,松耦合
- 微服务下,我们更容易引入新技术,以及实现DevOps开发运维一体化
缺点:
- 微服务架构下,分布式复杂难以管理,当服务数量增多时,管理更加复杂
- 分布式链路跟踪难
同时,微服务也引入了一些新的概念:
- 服务注册与发现: 服务提供者提供服务的信息(服务器ip端口,访问协议等)注册到注册中心,而服务消费者则从注册中心获取到服务进行访问
- 负载均衡: 即将请求分配到多个服务器,数据库等.以此来提高服务的性能,可靠性
- 熔断: 即断路保护,当请求压力过大或者响应变慢失败时,上游服务为了保护系统整体可用性,可以暂时切断对下游服务的调用
- 链路追踪:当一次请求跨越多个服务时,我们只有详细的日志记录,性能监控,才能够在出现问题时进行排查解决.
- API网关: 为客户端调用微服务提供统一的地址,由API网关实现请求统一调用,流量控制,安全防护等功能.
SpringCloud核心组件
Spring Cloud是⼀个微服务相关规范，这个规范意图为搭建微服务架构 提供⼀站式服务，采⽤组件（框架）化机制定义⼀系列组件，各类组件针对性的处 理微服务中的特定问题，这些组件共同来构成Spring Cloud微服务技术栈。
微服务架构面临的问题
- 服务管理：⾃动注册与发现、状态监管
- 服务负载均衡
- 熔断
- 远程过程调⽤
- ⽹关拦截、路由转发
- 统⼀认证
- 集中式配置管理，配置信息实时⾃动更新
