随着软件功能的不断扩展,我们在运维过程中不可避免的会遇到各种各样的故障。即然无法避免,让我们来看看如何隔离故障,让我们的架构设计可用性更高。
从字面意思来说,就是把故障通过某种方式隔离起来,让其不和其他的系统产生联系,即使这个被隔离的应用或者系统出现了问题,也不会波及到其他的应用。这个想法比较理想,但是体现了一种架构设计的思路。我们在设计应用组件的时候,都会遇到多个组件共享数据库,共享相同的基础组件,一旦基础服务或者组件出现问题,会造成系统大面积的罢工。如果有了故障隔离可以避免这种情况的发生,或者说可以减缓这种情况的发生。例如:在北京地区的用户访问都会到北京部署的服务器获取数据,如果北京的服务器出现问题,那么只对北京的用户有影响,不会对上海的用户产生影响。又例如,一个核心的组件如果出现问题,通过降级和开关的方式,让其他依赖他的组件保证不会崩溃。这些都是故障隔离带来的好处。他增加了系统的可用性和可扩展性,同时也降低了处理风险的成本。我们可以把这些隔离系统想象成一条一条的泳道,对!就好像游泳比赛的泳道,系统就好像运动员一样都在自己的泳道(系统边界)中比赛(工作),不会越过泳道(系统边界)到其他的泳道(系统边界)中去。
这里有几个原则可以给大家参考,小伙伴们可以根据自己的团队和系统复杂度,以及架构情况自行采纳。
第一,减少共享。其实严格来说故障隔离是不允许共享的。他的思路是即然是一个隔离的组件,那么这个组件应该包括所有的依赖项,在没有其他组件的情况下自身可以运行的。甚至说都不需要通讯。但是,实际开发中是没有绝对的隔绝的,一些系统特别是核心系统是需要沟通的。所以我们建议是减少共享。如果需要共享,最好是用解耦合的方式共享。例如:消息队列的方式和其他的组件或者系统进行通信。这样既保证了通讯也保证了系统的独立性不受影响。
第二,不跨越系统边界(泳道)。就如上面提到的系统边界就好像泳道一样,系统是不能跨越边界到达其他系统的。如果需要通讯需要,按照第一条中提到的通过中间件的方式来完成。为什么在这里要特别提出来,是因为被放在隔离区域中的系统通常都针对特定的客户,特定的业务,特定的组件。如果他们和外界的系统有过多的交集,就明显无法达到隔离的效果。
第三,所有的交易只能发生在系统边界内。实际上需要完成的是,所有的交易闭环都在系统边界内完成,交易中的任何环节都不要出现在系统之外。这里可以通过几个维度来考虑。
这个容易被忽略,这里提醒一下各位架构师,当设计完故障隔离的系统之后一定要记住对其进行测试。按照独立系统,共享通讯,边界清醒几个方面来测试。例如:完全断掉其他通讯机制,进行单独业务的测试。又例如:断掉通讯,测试自身的可用行和通讯方的可用性,看看系统开关和服务降级是否可用。
总结:为什么需要做故障隔离,故障隔离的有点,故障隔离的原则是怎么样的,我们要重视故障隔离。
联系客服