为了做到微服务的高可用,鬼知道我出了多少张牌( 六 )


总结

为了做到微服务的高可用,鬼知道我出了多少张牌

文章插图
 
出了那么多张牌,出牌只是术,真正的道还是得静下心来看看整个服务高可用的本质是什么 。
随着微服务架构的相互调用越来越复杂,环节只会越来越多,只有建立清晰的架构和层次才能理清楚每个环节高可用的保障,保持简单 。
从手段看高可用
主要使用的技术手段是服务和数据的冗余备份和失效转移,一组服务或一组数据都能在多节点上,之间相互备份 。
当一台机器宕机或出现问题的时候,可以从当前的服务切换到其他可用的服务,不影响系统的可用性,也不会导致数据丢失 。
从架构看高可用
保持简单的架构,目前多数网站采用的是比较经典的分层架构,应用层,服务层,数据层 。
应用层是处理一些业务逻辑,服务层提供一些数据和业务紧密相关服务,数据层负责对数据进行读写 。
简单的架构可以使应用层,服务层可以保持无状态化进行水平扩展,这个属于计算高可用 。
相比计算高可用,在数据层思考的高可用则属于数据高可用,数据高可用相比计算高可用需要考虑到数据的一致性问题会更加的复杂 。
这个时候 CAP 理论在里面会发挥关键的作用,究竟是选择 AP 或 CP,这个得根据业务去选择模型 。
从硬件看高可用
首先得确认硬件总是可能坏的,网络总是不稳定的 。解决它的方法也是一个服务器不够就来多几个,一个机柜不够就来几个,一个机房不够就来几个 。
从软件看高可用
软件的开发不严谨,发布不规范也是导致各种不可用出现,通过控制软件开发过程质量监控,通过测试,预发布,灰度发布等手段也是减少不可用的措施 。
从治理看高可用
一个系统在线上跑的好好的,但我们也不能确保它在下一秒会不会出现不可用状态 。
将服务规范化,事前做好服务分割,做好服务监控,预判不可用的出现,在不可用出现之前发现问题,解决问题 。
【注:文章部分内容参考 李云华《从 0 开始学架构》杨波老师《微服务》】
作者:陈于喆
简介:十余年的开发和架构经验,国内较早一批微服务开发实施者 。曾任职国内互联网公司网易和唯品会高级研发工程师,后在创业公司担任技术总监/架构师,目前在洋葱集团任职技术研发副总监 。
【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】




推荐阅读