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

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

 

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



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

 

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

 

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

 

 

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

 

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

 

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

 

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

 

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

 

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



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



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



限时 0 元

本文分享自微信公众号 - Python爬虫与数据挖掘(crawler_python)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章