从单体到微服务架构新增的挑战
01.远程调用复杂
02.服务注册与发现
03.服务治理复杂
04.链路追踪复杂
05.分布式事务复杂
06.部署复杂
01.远程调用复杂
使用本地调用不会引起性能问题,但是RPC会花大量的时间对负荷进行封装和解封装,更别提网络通信所需要的时间.
这意味着,要使用不同的思路来设计远程和本地的API.简单地把一个本地的API改造成为跨服务的远程API往往会带来问题.
02.服务注册与发现
服务提供者与消费者,通过服务注册与发现来实现远程的服务调用,区分于传统的IP+端口调用方式,起到很好弹性伸缩的效果,但是同样带来一些问题.主要针对eureka等.
1.注册服务慢:由于心跳机制,默认30s,只有当实例,服务器,客户端的本地缓存数据一致时才能被其他服务发现(3次心跳),可以修改心跳时间间隔.
2.注销服务慢:关闭自我保护,修改清理间隔时间(修改配置文件).
03.服务治理复杂
服务治理是主要针对分布式服务框架的微服务,处理服务调用之间的关系,服务发布和发现,故障监控与处理,服务的参数配置,服务降级和熔断,服务使用率监控等.
需要服务治理的原因:过多的服务URL配置困难,负载均衡分配节点压力过大的情况下,需要部署集群,服务依赖混乱,启动顺序不清晰,过多服务,导致性能指标分析难度较大,需要监控,故障定位与排查难度较大.
04.链路追踪复杂
链路追踪复杂,主要体现在整个服务调用的链路过长.从网关,到聚合层,再到业务服务层,调用仓储层(或者网关),最后到达数据库,缓存,远程服务调用等.整个调用链路过长,并且很多都是rpc或者http请求,因此需要专门的链路追踪工具.
05.分布式事务复杂
单体应用,一个应用一个数据库,在事务一致性方面,可以充分发挥数据库的事务机制.而微服务一个微应用一个数据库,涉及到分布式的事务,这时候分布式事务就会遇到很大挑战.
06.部署复杂
部署基于微服务的应用程序也是非常复杂的.一个单体应用可以很容易地部署到基于传统负载均衡器的一组相同服务器上.
22-06-20