基于微服务成熟度模型的高可用优化实践

前言

     随着微服务的流行，每个互联网公司后台都有无数大大小小的服务，服务与服务之间又有着千丝万缕的调用关系。要保证整个微服务系统的成熟稳定，就必须保证每个微服务的成熟度。但如何来定义服务的成熟度？应该从哪些纬度来考量？各个纬度里又有哪些普遍的问题？如何来优化？

     本文介绍了爱奇艺技术产品团队用来衡量服务成熟度的模型，并基于此模型对多个后台服务进行评估，总结出了一些常见的低分项，并对低分项整理了相关优化方案。希望对大家有所帮助。

01

 服务成熟度模型

       为了能够对服务的成熟度进行量化，我们需要从多个维度对服务进行评估。

       每个服务随着需求不断迭代，每个迭代周期都需要经历如下三个阶段：开发测试，运维上线，线上运行。每一个阶段，都需要一系列的措施来保证服务最终的成熟可靠。我们针对每一个阶段，梳理出来需要关注的指标，来衡量该阶段的整体质量。

       我们对上面3个阶段进行综合评分，并根据评分对服务成熟度进行了等级划分。（1-5分为准入级，6-7分为服务级，8-10分为成熟级。）

       通过这样的服务成熟度模型，我们就可以以量化的指标直观的评价一个服务的成熟度，并发现服务有哪些可改进项。

02

 低分项梳理

      基于服务成熟度模型，我们对多个后台服务进行了评估，发现了一些指标项在各个服务中普遍得分较低。这些指标项包括：

• 开发测试方面：代码规范，单元测试，压力测试，接口拨测；

• 运维上线方面：灰度上线，上线回滚；

• 线上可用性方面：系统保护，数据备份，报警处理，应急预案。

       于是我们优先对这些低分项的优化方案进行了梳理，期望通过对低分项的优化，提升服务的成熟度，使我们的服务提升至成熟级别。

03

 低分项优化方案

      我们的服务主要基于Java语言开发，主要是虚机部署的部署方式，并少量采用容器部署。所以下面的优化方案主要围绕我们的服务现状展开。

3.1

开发测试

       线上bug往往都是开发新需求引入的，如果在开发测试阶段尽可能的发现问题，提高代码质量，能够将问题的影响范围控制在最小。下面是开发测试阶段一些常见的措施和手段：

3.1.1 代码规范

       代码风格：采用统一的代码风格，一方面可以使得代码的可读性提升，另一方面会减少代码合并时的冲突&#x