spring cloud
spring cloud 分享
-
springboot:可以说是spring cloud的基础,是springMVC框架的简化,约定大于配置(在使用上、非功能上的简化)
可以说每个MPO Digital api就是springboot project(springboot项目)
-
spring cloud:将这些springboot的项目串起来,联合起立,每个springboot的项目启动的实例都是一个服务,很多的微服务组成了对外服务的整体
HSBC的MPO Digital的项目严格上说不是微服务项目,虽然拆分得很细,但是还是缺少挺多的微服务的思想,也没使用太多微服务的组件
微服务技术栈
单体架构(目前BPM用的就是单体)
单体架构的优势:
- 开发简单
- 部署简单
缺点:
- 耦合度高不适合大团队一起开发
- 编译部署和所需要的时间随着不断臃肿变得难以接受
- 只能整体扩容,不能单独为某个模块扩容
分布式架构带来的挑战
- 会话问题
- 日志查看问题
- 服务调用
- 性能监控
- …
spring cloud的组件
-
注册中心
-
配置中心
-
网关
-
负载均衡
-
链路追踪
-
分布式事务
-
限流
-
熔断和降级
Spring cloud各组件的作用
-
注册中心
- 作用:接受注册,管理微服务,健康检查等
- 选型:Eureka、Nacos
- HSBC:Digital没有注册中心
gms-iccm ---------call------> application-repository (http://xxxxxx.local:80/aaa/bbb)xxxxxx.local:80 配置成变量,不同环境有不同的值gms-iccm ---------call------> application-repository 实例1application-repository 实例2(服务中心方式可以通过服务名调用,如http://application-repo-service/aaa/bbb,Ribbon负载均衡帮转换) @Feign
补充:CAP理论,Eureka的高可用
-
配置中心
- 作用:保存、管理配置
- 选型:Spring Cloud Config,Nacos,Apollo
- HSBC:自己做了一套配置中心,单节点,90%都是API对另一个API的调用URL,无法热更新配置。能更新配置的功能很方便很重要。
-
网关
- 作用:统一入口,鉴权,日志,限流…
- 选型:Zuul 1.x(阻塞式IO),Zuul 2.x,Spring Cloud Gateway(NIO,响应式编程,拦截器和普通的不太一样)
- HSBC:Spring Cloud Gateway
- 为什么有Kong了还需要网关(router api)?
-
负载均衡
- 作用:避免单节点压力过大。服务端、客户端负载均衡
- 选型和策略:Ribbon,轮询,权重,随机…
- HSBC:用的是k8s带的负载均衡策略
-
分布式事务
- 作用:保证分布式系统下类似本地事务一样的,让各个操作成为一个整体,同时成功,同时失败。
- 选型:理论2PC,TCC,最大努力通知(支付宝),可靠消息最终一致性,seata。本地事务,什么是原子性,分布式事务,最终一致性(BASE),四种分布式事务的方案
- HSBC:没有
- 评论:有时不一定要有,会让系统非常复杂得不偿失的时候,就不使用。
@Transational
public Foo myService() {aaaRepository.deleteAll(aplnNum);aaaRepository.save(list);
}@Transational
public Foo myService() {aaaRepository.deleteAll(aplnNum);aaaRepository.save(list);restfulCall();
}@Transational
public Foo myService() {restfulCall();aaaRepository.deleteAll(aplnNum);aaaRepository.save(list);
}
-
链路追踪
- 作用:性能监控,请求追踪
- 选型:Sleuth,zipkin,Skywalking
- HSBC:有雏形RequestCorrelationId
-
限流
- 作用:限制瞬时大量的请求对系统造成的破坏。很多第三方api会对调用频率有限制。如果超过限流,会怎么样?
- 选型:Spring cloud gateway, Sentinel
- HSBC:请求量不大,似乎没见到限流的配置
-
熔断和降级