微服务架构的概述
应用架构的发展
应用是可以独立运行的程序代码,提供相对完善的业务功能. 目前的软件架构有三种架构类型:
- 业务架构
- 应用架构
- 技术架构
他们之间的甚是: 业务架构决定应用架构,技术架构支撑着应用架构. 应用架构的发展历程:
- 单体架构: 最古老的单体应用,没有任何应用拆分,整体就是一个war包
- 分布式应用 | SOA架构: 根据业务进行划分服务,不同的业务建立不同的服务,不同的服务之间通过服务接口进行数据交互(网络通信).
- 微服务架构: 将业务功能拆分为多个相互独立的微服务,各个微服务之间松耦合,通过各种远程协议进行同步 / 异步通信,各服务之间可以独立部署,扩 / 缩容以及升 / 降级.
每种技术架构都有其优缺点,存在即合理,不同的业务场景使用不同的应用架构,不一定说最新的架构就是最适合你的.
重点说一下微服务架构,在重新定义SpringCloud实战中介绍了5种微服务架构技术选型,这里说两种,我用过的,常听到的.(先提及一个概念 CAP理论: 一致性,高可用,分区容错性)
| SpringCloud | Dubbo | |
|---|---|---|
| 功能 | 微服务完整解决方案 | 服务治理(定位以及发现问题)框架 |
| 通信 | REST / HTTP | RPC(远程方法调用)协议 |
| 服务注册/ 发现 | Ecureka(AP) | ZK(CP),Nacos |
| 负载均衡 | Ribbon | 客户端负载 |
| 容错机制 | 六种容错策略 | 六种容错策略 |
| 熔断机制 | Hystrix | 无 |
| 配置中心 | Spring Cloud Config | Nacos |
| 网关 | zuul,Gateway | 无 |
| 服务监控 | Hystrix + Turbine | Dubbo + Monitor |
| 链路监控 | Sleuth + Zipkin | 无 |
| 多语言 | REST支持多语言 | 只支持Java |
| 社区活跃 | 高(背靠Spring) | 高(背靠阿里) |
微服务的解决方案
- 基于SpringCloud的微服务解决方案
SpringCloud的技术选型是中立的,可随意搭配更换.
| 组件 | 方案1 | 方案2 | 方案3 |
| 服务发现 | Eureka | Consul | etcd,阿里的Nacos |
| 共用组件 | 服务间调用组件Feign,负载均衡组件Ribbon,熔断器Hystrix | ||
| 网关 | 性能低: zuul; 性能高: Spring Cloud Gateway | 自研网关中间件 | |
| 配置中心 | Spring Cloud Config, 携程阿波罗, 阿里Nacos | ||
| 全链路监控 | zipkin(不推荐),Pinpoint(不推荐),Skywalking(推荐) | ||
| 搭配使用 | 分布式事务,容器化,Spring Cloud与DDD,gRPC | ||
- 基于Dubbo实现微服务解决方案
Dubbo不是一个微服务的全面解决方案,而是专注于RPC领域成为微服务生态体系的一个重要的组件,所以说基于Dubbo的微服务组件是: Dubbo + Nacos + 其他. (Nacos的定位是一个更易于帮助构建云原生应用的动态服务发现,配置和服务管理平台)
Spring Cloud和Dubbo
Spring Cloud和Dubbo的比较其实是针对REST和RPC之间的对比,其余方面没有对比性,因为领域不同,对于Spring Cloud提供的一套完整的微服务解决方案,提供分布式情况下的各种解决方案;而Dubbo则是专注于RPC.
Spring Cloud的设计理念是Integrate Everything,即充分利用现有的开源组件,在他们之上设计一套统一规范/接口使他们能够接入Spring Cloud体系并能够无缝切换底层实现.
2018年6月,Spring Cloud中国社区开源名为spring-cloud-dubbo项目,目标是将dubbo融入Spring Cloud体系中,使微服务之间的调用同时具备RESTful和Dubbo调用的能力,做到对业务代码无侵入,无感知,在使用过程中引入jar包则在微服务间调用时使用Dubbo,去掉jar则使用默认的RESTful.