为什么架构师一定要懂“故障隔离”？

点击上方“Java之间”，选择“置顶或者星标”

你关注的就是我关心的！

作者：疯狂的肉丝面

随着软件功能的不断扩展，我们在运维过程中不可避免的会遇到各种各样的故障。即然无法避免，让我们来看看如何隔离故障，让我们的架构设计可用性更高。

故障隔离

从字面意思来说，就是把故障通过某种方式隔离起来，让其不和其他的系统产生联系，即使这个被隔离的应用或者系统出现了问题，也不会波及到其他的应用。这个想法比较理想，但是体现了一种架构设计的思路。我们在设计应用组件的时候，都会遇到多个组件共享数据库，共享相同的基础组件，一旦基础服务或者组件出现问题，会造成系统大面积的罢工。如果有了故障隔离可以避免这种情况的发生，或者说可以减缓这种情况的发生。例如：在北京地区的用户访问都会到北京部署的服务器获取数据，如果北京的服务器出现问题，那么只对北京的用户有影响，不会对上海的用户产生影响。又例如，一个核心的组件如果出现问题，通过降级和开关的方式，让其他依赖他的组件保证不会崩溃。这些都是故障隔离带来的好处。他增加了系统的可用性和可扩展性，同时也降低了处理风险的成本。我们可以把这些隔离系统想象成一条一条的泳道，对！就好像游泳比赛的泳道，系统就好像运动员一样都在自己的泳道（系统边界）中比赛（工作），不会越过泳道（系统边界）到其他的泳道（系统边界）中去。

如何进行故障隔离

这里有几个原则可以给大家参考，小伙伴们可以根据自己的团队和系统复杂度，以及架构情况自行采纳。

第一，减少共享。其实严格来说故障隔离是不允许共享的。他的思路是即然是一个隔离的组件，那么这个组件应该包括所有的依赖项，在没有其他组件的情况下自身可以运行的。甚至说都不需要通讯。但是，实际开发中是没有绝对的隔绝的，一些系统特别是核心系统是需要沟通的。所以我们建议是减少共享。如果需要共享，最好是用解耦合的方式共享。例如：消息队列的方式和其他的组件或者系统进行通信。这样既保证了通讯也保证了系统的独立性不受影响。

第二，不跨越系统边界（泳道）。就如上面提到的系统边界就好像泳道一样，系统是不能跨越边界到达其他系统的。如果需要通讯需要，按照第一条中提到的通过中间件的方式来完成。为什么在这里要特别提出来，是因为被放在隔离区域中的系统通常都针对特定的客户，特定的业务，特定的组件。如果他们和外界的系统有过多的交集，就明显无法达到隔离的效果。

第三，所有的交易只能发生在系统边界内。实际上需要完成的是，所有的交易闭环都在系统边界内完成，交易中的任何环节都不要出现在系统之外。这里可以通过几个维度来考虑。

1、和利益相关的业务，例如支付服务，收款机提供的服务。这些服务都设计到钱和交易。我们在做架构设计的时候尽量使之独立。

2、经常出现故障的业务，在系统中总有一些业务或者服务使用的最频繁同时最容易出现故障。这类服务我们需要特别的关注，也可以考虑把他们设计成故障隔离系统。

3、用户边界明显的业务，例如：北京的用户，上海的用户。又例如：大型企业用户，中小企业用户。

故障隔离的测试

这个容易被忽略，这里提醒一下各位架构师，当设计完故障隔离的系统之后一定要记住对其进行测试。按照独立系统，共享通讯，边界清醒几个方面来测试。例如：完全断掉其他通讯机制，进行单独业务的测试。又例如：断掉通讯，测试自身的可用行和通讯方的可用性，看看系统开关和服务降级是否可用。

总结：为什么需要做故障隔离，故障隔离的有点，故障隔离的原则是怎么样的，我们要重视故障隔离。

原文链接：

https://www.toutiao.com/i6683299465396224516/

最近热文阅读：

1、我是一条DQL

2、你真的理解零拷贝吗？

3、90%程序员面试都用得上的索引优化手册

4、90%架构师都知道的压力测试，你知道吗？

5、为什么程序员都不喜欢使用switch而使用if来做条件跳转

6、分享一些好用的 Chrome 扩展

7、分库分表就能无限扩容吗，解释得太好了！

8、全文搜索引擎选 ElasticSearch 还是 Solr？

关注公众号，你想要的Java都在这里！