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

小鱼儿 2022-09-10 14:08 212阅读 0赞

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

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

![0afd9db4cfc2f7d69a390596eb8b0ea4.png][]

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

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

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

![9b310d8bed5e8e3ffce3e1dc0b714420.png][]

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

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

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

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

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

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

![e8c36b1d6f7e183095a36dbe934f2852.png][]

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

![dd8b82826a396a65a121c24b88549224.png][]

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

![11630fa0b8e969cd1f97f75d73e4b81e.png][]

**限时 0 元**

[0afd9db4cfc2f7d69a390596eb8b0ea4.png]: /images/20220829/60336674f4284857993dd81f25f3ce19.png
[9b310d8bed5e8e3ffce3e1dc0b714420.png]: /images/20220829/e72ebcac6afd4eb58f56042e3a600a9a.png
[e8c36b1d6f7e183095a36dbe934f2852.png]: /images/20220829/938f8a441b1b4413b493e91c74eebd18.png
[dd8b82826a396a65a121c24b88549224.png]: /images/20220829/4d3da1585fb74a29ae72fe5a587fd97d.png
[11630fa0b8e969cd1f97f75d73e4b81e.png]: /images/20220829/a9a799ad8ec14f5095187852d0e209c5.png