​手把手教你微服务的可用性设计

微服务现在有多火，应该不需要我过多解释了。

 

现在可以确定，只要有点规模的公司，肯定是跑微服务架构。简单来说下背景，随着业务量越来越大，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。同时，我们也需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

拆完微服务之后，我个人觉得比较难的一个知识点就是微服务的可用性设计。

 

提到可用性，一般情况下，就会跟着出来这些词：隔离、超时、限流、降级、重试。我一般面试的时候，都会挑着拿出来一个问题来问候选人，以看他的技术深度。

 

就拿隔离来说，隔离设计对应的单词是 Bulkheads，中文翻译为隔板。但其实，这个术语是用在造船上的，也就是船舱里防漏水的隔板。一般的船无论大小都会有这个东西，大一点的船都会把船舱隔成若干个空间。这样，如果船舱漏水，只会进到一个小空间里，不会让整个船舱都进水而导致整艘船都沉了。

 

 

在分布式软件架构中，我们同样需要使用类似的技术来让我们的故障得到隔离。这就需要我们对系统进行分离。一般来说，对于系统的分离有两种方式，一种是以服务的种类来做分离，一种是以用户来做分离。

 

服务隔离举个例子，我们可以将系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库，做到从接入层到应用层再到数据层三层完全隔离。这样一来，在物理上来说，一个板块的故障就不会影响到另一板块。

 

用户隔离举个例子，我们将用户分成不同的组，并把后端的同一个服务根据这些不同的组分成不同的实例。让同一个服务对于不同的用户进行冗余和隔离，这样一来，当服务实例挂掉时，只会影响其中一部分用户，而不会导致所有的用户无法访问。

 

这其实就是隔离大致的原理。在隔离设计上也有一些考量，比如，我们需要定义好隔离业务的大小和粒度，过大和过小都不好。这就需要认真地做业务上的需求和系统分析。另外，隔离模式需要配置一些高可用、重试、异步、消息中间件，流控、熔断等设计模式的方式配套使用。

 

如果你对这块感兴趣的话，我向你推荐毛剑的一个分享，这应该是我见过的讲的最全面的内容了，不说别的，人家这是直接讲案例啊！

 

《Go 微服务架构实践 - 可用性设计原则》，该课程是 3 天视频课 + 1 天直播课，全方面的讲解微服务的可用性设计。现在直接扫描下图的二维码添加学习助理，就可以免费领取。

以下是本次课程的具体大纲内容和直播安排。不只是图中的课程内容，每天还会有大厂助教老师在社群里布置作业和互动答疑，最后一天是毛剑老师来直播讲解授课。学、问、答、练全都有了。

这么干货的课程，现在限时免费可以领取！0 元来收获毛剑大佬的硬核分享，非常超值！有需要的扫描下边的二维码添加学习助理即可。

限时 0 元