大型微服务架构稳定性建设策略

Posted GitChat精品课

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大型微服务架构稳定性建设策略相关的知识,希望对你有一定的参考价值。

对于大型应用后台系统来说,稳定性至关重要。目前越来越多的大型应用系统采用微服务架构,更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。


针对我们业务后台系统建设,任何大型业务后台系统绝对不是一蹴而就。它是伴随着业务不同阶段,不断进行演进的过程。如果经历过从 0 到 1 建设一个业务后台系统的同学,都会有类似的体会。


01

启动阶段


启动阶段,业务模型相对简单,用户量少,这时候我们可以将所有的系统模块耦合在一个工程里面,进行单机部署。这时候可能仅仅需要将业务系统与数据库进行隔离。


02

探索阶段


探索阶段,业务模型不断演进,用户量增加,单机服务能力瓶颈凸显。这时候就需要由单机服务部署向集群服务部署来优化,利用负载均衡将请求合理分配,减少单机服务压力。另外一个方面,数据量不断的增加,也需要考虑针对数据来进行水平的扩展(主从部署,读写分离)。


在这一阶段,我们仅仅是做了集群扩展,但所有的业务代码都在同一个工程维护,所有的数据信息都在同一个数据库中存储。随着团队的扩充与业务交互不断复杂化,在工程维护上存在很大的风险,工程研发效率受到制约,业务代码之间的耦合也难以清晰,系统可靠性存在很大风险,一个 bug 可能会造成整个应用的崩溃不可用。


03

发展阶段


如果我们比较幸运,业务持续快速发展,对于业务角色模型理解越来越清晰,业务角色模型之间的交互越来越确定。这时候就需要我们基于对业务充分的理解前提下进行垂直拆分。不同的业务模型会部署到不同的系统工程中,工程之间通过接口来进行交互。


这样工程内业务高度集中,工程间通过接口服务来进行解耦。这时候不管是系统维护,还是业务模块维护,都将大大的提高效率。数据部分同样垂直拆分,不同业务数据拆分到不同的数据库,从而提高单机数据库的能力。


拿电商系统的结构来说,如下图所示:

基于业务模型分为几个大的系统服务,系统服务之间通过内部 RPC 接口来进行交互。


04

成熟阶段


上面是基于大的业务模型进行划分,随着业务复杂度越来越高,我们必将对大业务模型,基于功能或者业务边界进行更细粒度的拆分。比如说,我们可以将产品中心划分为:基础信息中心,库存管理中心,SKU 中心等。


这时候就涉及到微服务的拆分与治理工作。


微服务的拆分原则我们应该注意:业务功能单一;服务间业务边界清晰;拆分粒度合理;分层划分合理。


从研发的角度来说,微服务带来的好处:研发效率提升;代码质量更优;能够独立部署;单模块复杂度降低。上面提到的产品中心我们可以拆分很多小的服务来提供,如下图所示:

细粒度的拆分,也会带来一定的挑战:

  • 微服务划分单元越细,整体服务维护非常复杂;

  • 微服务通过 RPC 接口交互,整个链路可能会不清晰;

  • 单服务的修改或者优化会受到其他模块的牵制。


当然这些挑战都是我们需要思考与解决的问题,并不能抹杀微服务的优点。在这篇 Chat 文章里,我系统的梳理了一下大型网站后台稳定性的技术策略,堪称“行动指南”!!


扫描下方二维码查看完整全文

进入读者圈与作者深入交流


点击阅读原文,订阅本场 Chat ,查看完整原文!

以上是关于大型微服务架构稳定性建设策略的主要内容,如果未能解决你的问题,请参考以下文章

ArchSummit阿里云原生微服务架构治理最佳实践

微服务运维减负:Istio Service Mesh原理+实战

转载微服务,我们需要哪些基础框架?

Java架构:一文读懂微服务架构的重构策略

一文读懂微服务架构的重构策略

微服务架构模式下配置管理