更新时间:2022-10-02 18:27:33
我要讲的故事开始了
A公司的技术架构体系目前还是以集群扩展体系为主,我们可以看下图所示,在这种体系结构中,可以看到应用都是单块结构,但是单块结构的应用具有扩展性,通过布署在多个Tomcat上实现应用的集群,所有的应用都去访问同一个数据库(这个库可以假设为Oracle数据库),数据库间采用DataGuard来实现主从同步,读库只具有读取功能,为后台数据统计功能提供数据查询和统计服务。目前业务请求的并发量每分钟有几十笔交易,看起来这套架构还是能够支撑目前的业务发展的。
突然有一天客户在做活动的时候,监控中心各种告警,在每分钟500tps的时候很多请求超时,监控显示目前的服务器不能支撑这么大的并发量,于是快速增加服务器布署应用上线,发现根本没用,加了和没加一样,加几台都一样,运维和DBA发现此时的数据库压力非常大,好不容易熬过这段是时间后,团队成员痛定思痛一致认为,目前的架构体系已经不能支持业务的发展,微服务开始快速推进。
其中微服务的数据去中心化核心要点是:
最终经过服务化改进后,变成了如下图所示的样子:
上图看起来是不是很棒,服务拆分是不是很清晰?
于是问题随后就来了:
那我们用Spring Cloud做一个大一统的整合可以吗?于是看到Spring Cloud原来有这些坑啊:
注册IP问题
早期的Spring Cloud Eureka在注册获取网卡IP时,不能区分外网网卡和内网网卡,如果安装了虚拟机和Docker也不能区分虚拟网卡,每次启动注册的IP都有可能不一样,如果要注册为外网网卡IP,那运行带宽就不够,这个bug应该说是比较严重的问题,因此重写了网卡IP获取的逻辑来解决,同时也反馈给了Spring Cloud团队,再后期的版本中添加了网卡接口排序和通过名称过滤的功能来得到解决。
HealthCheck的问题
在一些极小概率的情况下,会导致Eureka Server下线微服务实例,出现“Remote status from Eureka server is down”的问题,即便是重启微服务也无济于事,不过已经有码友在Spring Cloud 官方GitHub贴出了解决方法的issue。
Feign使用不当带来的性能问题
其他的小坑也就忍了,大坑却不能。于是去各大社区讨论发现原来大家都对Cloud的不少组件进行了二次封装。
回顾一下
上面用了很大的篇幅各种吐槽,那么我们说微服务好吗?我一直坚持认为微服务很好,但是如果我们为了使用微服务而使用的话将会伤其自身,从单块系统到微服务的是需要逐步演进的过程,如果前期没有调研,没有一个整体规划,后期在做的时候会发现,需要做的事情只会越来越多,尤其是对于快速发展的创业型公司来说。
就拿我上面举的例子来看,数据库自身压力大,经过分析看出其实是很多SQL没有加索引,大量使用数据库悲观锁,大表的数据一直长期积累没有迁移出去所致。当单块系统遇到了性能问题后,如果认真分析了性能的根源,也许还会为我们做服务化演进争取了更多的时间。
最后想说一句,对于中小公司来说,如果业务发展非常快速,人员不足的情况下,我们更需要的是在业务发展和架构优化间做平衡,逐步演进,而不是快速使用。
本文作者:佚名
来源:51CTO