容错，对于构建高可用系统是至关重要的一个环节。没有容错的系统是不完整的系统、不健康的系统。对于开发人员来说，容错至少存在于两个层次：系统框架层、业务应用层（当然也可细分成公共业务、具体业务等）。前者处理共性问题，如RPC框架的超时、异常返回等情况；后者是具体业务的容错，比如收到不合法数据或者数据中不包含关键项的内容、由于信息不同步导致的接口变化而引起的返回数据格式活内容变化等。面对林林总总的不一致、错误、甚至异常，程序是否能做到容错呢？全量容错比部分好，部分容错比没有好。
开关，一种被广泛应用的显式容错方式，通过开关控制功能的状态，根据开关状态进行不同的处理，这种容错易于设计和实现，同时也容易被理解。对于开关的设计要小心、对于开关的使用控制要严格、对开关的兼容要完善、对开关的监控要完整，小心使用开关、在何时的地方使用开关能给系统带来莫大的好处。，
容错的另一个角度是对业务隔离，就像泳道一样，不同业务之间不能产生影响。当然这是一种理想的状况，不能做到百分之百的互相不影响，但是可以通过技术手段实现被以来的服务如果出问题了，依赖的服务可以兼容这种错误，给用户一个友好的提示或者在业务允许的条件先保存业务的中间状态，待被依赖服务重新具备服务能力后通知用户继续之前未完成的业务。
所谓异步通信，通常指通过对消息中间件的使用将同步调用转为异步调用，异步调用相比同步调用的好处是无需等待，只需要确认将数据发送到消息中间件即可，数据的处理由另外的程序进行，也就是将数据的产生与处理隔离开来，互相不知道对方的具体位置。
在实际使用中，并不是所有场景都适合使用异步通信，只有那些对于实时性要求不高的场景适合使用，这点一定要注意。任何技术方案、技术组件都不是万能的。
由于不同的消息中间件具有不同的特点，在选择时也需要留意，甚至可以在不同的场景使用不同的消息中间件，这完全取决于具体业务场景的需求，比如对于消息中间价吞吐量和持久化数据量要求高、对消息中间件并发能力要求高等等。
对于消息中间件一样要避免单点故障，因此其可扩展能力就显得尤为重要。当部署一个消息中间件集群时，我们至少要考虑到这个集群的负载均衡怎么处理、业务数据是否持久化、每个节点的数据是全量还是部分、节点间是否需要数据同步以及怎么同步、当其中一个或几个节点挂掉后集群怎么保证持续提供服务能力。。。
当解决了上述问题后，我们就会面临另外一个问题，一个消息中间件的集群有多大容量或者说某一类或几类业务需要什么规模的消息中间价集群？这就需要我们对业务规模、消息中间件特性有综合的评估，合理的规划消息中间件集群及规模，做到心中有数。
随时随地看视频
热门评论
-
大江ss2016-08-24 0
查看全部评论很好，学习，真的有用