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

Posted 2021-04-14 GitChat精品课

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

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

01

启动阶段

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

02

探索阶段

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

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

03

发展阶段

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

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

拿电商系统的结构来说，如下图所示：

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

04

成熟阶段

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

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

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

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

细粒度的拆分，也会带来一定的挑战：

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

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

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

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

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

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

▼

点击阅读原文，订阅本场 Chat ，查看完整原文！