初入微服务,时代在召唤,现在开始!
随着互联网的进步,流量越来越庞大,单一系统逐渐向分布式,微服务化发展,以避免单一系统宕机引起的服务停滞!而向微服务迁移也并不是一帆风顺的,会有服务架构不稳定,数据一致性难保证等问题!
微服务的优点:
1,服务之间解耦!
2,单个服务可独立扩展!
3,各个服务单独部署,甚至做成负载均衡系统
4,对外透明!
既然已经选择了微服务,肯定是知道其有点的,但是存在哪些挑战呢?
1,单个服务独立部署,运维成本高!
2,单个服务容易宕机,停止服务!
3,机器太多,问题更难定位!
4,雪崩问题:(单个服务宕机引起整个系统的崩溃)
5,数据一致性难保证!
运维暂且不谈!
如何防止单个服务宕机和雪崩?①对并发压力大的单个服务利用nginx搭建服务集群,保证单个服务的稳定性!②使用hystrix熔断器,防止反复调用引起雪崩!
问题怎么定位?问题日志可能分布在一个集群里面N台机器上,一个一个打开找日志?NO!使用集中式日志处理,将日志在统一的机器上进行打印和文件
数据一致性怎么保证?由于网络延迟,硬件故障等引起分布式系统上的数据不能保持一致的问题,可以说是经久不衰的讨论话题,而长期以来的解决方案一共有下面四种:
1,基于XA协议的两阶段提交方案!
2,TCC方案(try,confirm,cancel)!
3,基于分布式消息系统的最终一致性方案!
4,阿里的GTS!
因为系统是分布式的,所以没法保证事务的同时进行,所有的这些分布式事务都是异步调用,确认的解决方案!各种解决方案也会出现不同的问题,比如应用侵入性强,开发量大,性能影响等!
选择合适的方案加上合理的架构,对单个服务使用负载均衡,使用熔断器,根据业务合理的进行接口重试,幂等性原则防止数据重复,增加外挂手动补偿等方式解决雪崩和数据一致性问题!由于篇幅原因,具体的解决方案会在以后提及!
本人一直致力于分布式,微服务,消息中间件,多线程等的研究和应用,如果你感兴趣,敬请关注。。。
联系客服