前言
在现如今的微服务架构下，每个系统的背后都隐藏着大量的微服务，那么每个服务都会存在可用性的问题，服务之间存在各种依赖关系，一旦某个服务出现故障时，影响的范围可不仅仅该服务，这种影响可能带来级联的影响，甚至雪崩现象，导致整个系统不可用，服务依赖存在关键依赖、非关键依赖，假如是因为非关键依赖服务出现故障，影响整个系统，那么影响则是相当的恶劣，那么该如何应对上述情况，就延伸出了服务分级，将服务划分不同的级别，识别出哪些关键和非关键依赖，包括应对思路，在本章节中，让我们一起来聊聊吧。
1、什么是服务分级
服务分级是通过识别服务对于业务影响的重要程度，为服务关联标签，通过标签区分出各个服务的重要程度，哪些服务是关键服务和非关键服务，我们系统中的所有服务都必须要有对应的标签，不论什么样的服务，服务分级某种意义是上让我们更清晰和管理服务依赖的方法，只有划分不同的级别服务，这样不论在架构设计还是资源上都会更倾向和关注级别高的服务。
如果不能对系统中的服务分级，那么所有服务的级别都是一样的，这样就导致在架构设计时区分不清主次，一视同仁，一旦某个服务出现故障，可能是因为边缘服务，影响整个系统，影响也是非常的恶劣。如下面这图，这么多服务，哪些关键服务呢？很难区分，服务分级就可以帮助我们管理服务依赖的方法。
2、服务分级重要性
服务分级是稳定性建设不可缺少的一环，通过上述章节我们了解到服务分级、服务分级的方法，服务分级目标是为了能够清晰知道我们的服务分布情况，哪些服务一旦出故障是必保的，哪些服务出现故障时可熔断、降级、隔离的，只有通过服务分级通过标签来识别系统的级别，这样在架构设计上不论是关注程度还是资源都需要更倾向高级别的服务，高级别服务的稳定性也是整个系统价值的体现，服务分级的重要性主要体现在以下几方面。
目标明确
通过服务分级之后，使稳定性建设的核心目标变得更加明确，那就是优先确保高级别服务的稳定性，也就是我们常说的核心服务，如果我们不清楚我们的服务级别，那么是在做稳定性建设时是无从下手，很盲目，也没有方向感，试想下在错综复杂的微服务网格下，我们该从何处入手，只有目标明确之后更能激发研发人员的动力，能够清楚知道自身负责业务的重要性及其他服务依赖关系，也能够明确其也业务价值，提升研发人的责任感和成就感，对于研发工程师而言，我们不是机器人是有情感的，对于研发工程师工作，首先价值观上认同，其次明确工作内容目标和路径，该内容对团队及公司的重要性及工作内容的价值，最后是关于自身成长，要在过程中有思考，只有这样才能不断自我雕琢和提升，而不是一味听从安排，做一个执行者。
容量评估
在微服务架构下，容量评估变得不是那么容易，在错综复杂的微服务网格下，服务依赖关系尝尝也错综复杂，对于容量评估这件事情，一般情况通过运营伙伴，对于运营活动做出的预测给到研发人员，我们需要对运营伙伴给到的预测来合理评估系统的容量，看能否满足需求，研发人员对于这类运营活动拆分之后落实到各个服务之后，评估单个服务容量额外加上自然流量，计算整体的容量，在这种情况下，就需要我们对服务依赖关系有足够的了解，原因是可能存在某两个调用同一个服务的情况，如果不清楚服务调用依赖关系，那么容易出大问题。
如下图
ServiceB、C是业务服务，ServiceD服务是基础服务、或公共服务，对于容量评估我们也需要能够清楚的了解服务依赖关系，最后全链路压测来模拟，压测和验证我们容量规划方案，看是否满足预期。
依赖治理
服务依赖是真正决定系统的复杂度，对于服务依赖并非是一成不变的，而是随着业务演化，服务依赖治理是定期检查我们的依赖模型是否合理，如遇到不合理则需要进行整改，将其合理化；依赖模型包括依赖关系、流量、强弱三个部分组成，依赖治理也是治理依赖模型，依赖关系是服务依赖的方向，我依赖谁，谁依赖，上下游调用方；强弱则是依赖的松紧程度，强依赖还是弱依赖；流量则是上下游的应用的流量情况，自身的流量状况摸底；
对于服务依赖关系是需要定期进行治理的，不然随着时间慢慢就腐化了。
小结
服务分级对系统的稳定性建设可以说是很基层的，服务分级的重要性也是不言而喻，对于稳定性建设必不可少，对于我们众多服务一方面便于管理，一方面需要足够的了解生命周期，了解其依赖关系，了解服务的级别，这样才能在出现故障时，及时做好隔离、防止故障传播，对于高级别的服务做好熔断降级，提供有限的服务，如果我们不重视服务分级、那么带来的影响和损失则是不可估量的。那么服务如何分级呢，请关注我，下小节分享
