前言

58作为一个分类信息网站，作为信息服务的提供平台，我们的客户在我们的平台的交易链路，抽象后可以描述为：商户购买服务->将购买后的资源托管到资源中心->商家消耗相关资源->收入的核算。

具体业务流程如下图：

图0-1 资源中心业务流程图

资源中心就是我们交易链路中客户购买相关服务后将相关服务资源托管的管理中心。是我们进行资源管理及后续收入核算的核心服务。

其在整个交易链路所处的位置为：

1、购买链路：房产、招聘等各大业购买平台->支付->资源中心。

2、消耗链路：房产、招聘等各大业使用平台->资源中心->摊销算收入->业绩、经分进行相关数据处理。

可见其在58的整体交易链上的重要性。无论是在商户购买58相关服务还是商户在实际使用58付费服务的过程中，都需要和资源中心进行交互。那么，如何治理好这个服务就是一个非常重要的课题。本文我们将从高可用性、性能优化两个方面介绍服务治理在资源中心的具体实践。

一、高可用应用架构演进

系统的建设并非一蹴而就的。资源中心的高可用，也是经过2年的不断建设演进，达到目前的4个9的可用级别的。我们的技术演进，既有我们通过技术的实践，主动优化的，也有在使用场景中遇到的问题，血泪教训后的填坑补丁。

1、高可用的理论框架

图1-1 高可用理论架构

如上图，从通用的高可用架构理论上，一个高可用架构通常包含高可用的硬件架构、高可用的应用、高可用的服务、高可用的数据、高可用的软件质量保证及最后的相关监控。对于硬件、网络、Nginx、DB、MB等相关基础设施，通过58私有云作为IAAS/PAAS直接提供给我们服务，对软件的质量保障和后续的相关监控，也有相关部门提供了完整的支持，也不是我们核心要点。这里核心介绍高可用服务的建设。

2、我们的具体实践

高可用服务的建设可以分为分级管理、超时设置、异步调用、服务降级、幂等设计这几个方面。

2.1分级管理

分级管理在实践中的难点是统一跨部门之间对重要性的认知。我们通过跨部门协作，制定共同的服务可用性OKR。完成服务重要性的协同认知。

在认知一致的基础上，基础运维部将我们的服务作为最高级来进行。首先是我们在私有云的容器，1是通过跨机柜，跨机房等方式，尽量避免硬件层面问题带来的风险；2是独立部署，避免混合部署，其他服务带来的潜在风险。其次在数据库层面上，采用最新的硬件进行独立部署。同时进行任务的集群隔离，让DBA单独拿出一个从节点专门用来进行DB相关任务处理，与处理线线上请求的机器进行隔离保障性能。最后是沟通机制上，针对我们的服务，单独安排独立接口人，负责相关问题的处理。保障相关问题发生后，能够第一时间进行处理。

同时，针对不同的请求方，我们设置了不同的容器分组，做到不同业务间的分级管理。保障不同业务组之间不会因为流量的暴涨影响彼此。

2.2超时设置

为什么要进行超时设置呢？

由于下游服务响应过慢、线程死锁、线上BUG等一系列原因导致我们作为调用方调用之后一直没有响应。从而最终导致用户请求长时间得不到响应，同时在长时间占有线程资源甚至会拖垮整个服务影响其他正常请求。所以我们应该进行超时设置，这是微服务中快速失败的一个基本手段。

第二个问题，我们该如何设置呢？

通常有两个层面的超时：服务级超时、接口级别的超时。服务级别的超时时间一般以最慢接口的耗时时间为基准。而且大部分框架都只会有服务级的超时设置，很少有接口级的超时设置。接口级的超时设置，没有必要所有接口都设置，仅针对流量极大、性能要求较高的接口进行单独设置就行。这里教大家一个小Tips：可以使用位于JUC包中的Future进行接口级的超时设置，简单有效。

第三个问题，服务超时时我们该如何处理呢？

基于这个这个问题，我们需要从上下游、流量、业务场景这三个维度进行考量。

超时的处理手段一般有两种：重试、异常快速返回。重要的写事务场景需要重试，我们要尽最大努力保证事务成功。流量较大的接口一般不适合重试，直接返回异常就好，最极端的场景下容易导致流量翻n倍，导致后面的链路奔溃。

2.3异步调用

异步调用可以分为同进程下的线程异步和进程间的异步调用。在最初的架构设计中，我们针对非核心流程但是相对关系较为紧密的内容做了单进程下的异步。使用的Disruptor队列异步写日志。用Event Bus异步化非核心流程。系统平稳运行了多年，以至于我们极少关注我们的非核心异步相关的服务。但是，一次线上事故还是给了我们深刻的教训。

2020年8月，突然有人反馈服务大量超时。我们通过我们的监控发现我们的请求大量积压，有一组服务处于无法提供服务的状态。经过比较发现，这组服务依赖的日志写入数据库出现超时。导致异步写日志的线程池创建了大量等待线程，进而导致正常处理请求的线程所能占用的CPU时间大大降低，最终大致正常请求超时并出现雪崩现象。这里有我们线程池参数设置不合理的原因，同时，也提醒我们，在同进程下异步，在出现小概率事件之后，依然可能影响到我们的服务可用性。针对这种情况，我们整体梳理了我们的核心流程和非核心流程。将非核心流程采用消息的方式，进行进程间隔离。进行服务治理完成之后我们大概的服务拓扑图如下图：

图1-2 资源中心服务拓扑图

2.4服务降级

图1-3 资源中心依赖方列表

如上图我们的服务拆分了非核心依赖之后还有十几个核心依赖。假设每个服务都是4个9高可用的服务，99.99^10≈99.9%我们的服务可靠性立马下降了一个数据量级，极大的影响了服务的稳定性。

2020年10月28日上午由于下游的某一个服务出现问题，导致30%的流量持续将近3分钟不可用。如下图：

图1-4 资源中心流量监控

30%是个什么概念呢？资源中心的核心服务日访问量4.5亿+，峰值近百万QPM。30%持续3分钟大概100万的请求不可用。所以降级对我们来时势在必行。

首先我们团队仅仅4个人，还得花90%的时间处理业务需求，所以自己造轮子是不可取的。就成本来说开源框架也是极好的选择。业内知名的几款降级框架对比如下图：

表1-1 降级开源框架比较

最终降级组件我们选的是Sentinel。首先先不考量Resilience4J因为其缺少生产级别的配套设施，相关监控系统以及控制台，我们无法感知到内部运行情况以及出现问题时无法从外部人工接入。再说Sentinel与Hystrix相比我们看中其源码简单、异常处理灵活两大特点。我们大部分接口平均耗时在2ms以后，所以我们果断采取信号量隔离机制，此时Hystrix另外一个优点线程池个隔离对我们来说意义也不大，所以选择了Sentinel。

为什么我们会将异常处理作为选择Sentinel的一个点呢？Hystrix在进行降级阀值计算时，所有的异常都会被统计，其实正常的业务异常是不需要被统计的，例如有的服务接口参数校验不通过时会抛异常，这时因为参数不合法而触发降级是不合理的。所以我们只针对超时、服务挂了等几个特殊异常才会进行降级处理。

组件选择好之后该怎么实现呢？

我们本着：关注点聚焦业务、将降级工具化的思想，利用自动扫包工具+RPC框架过滤器机制设计我们的组件。实现机制如下图：

图1-5 资源中心降级方案

我们的组件在使用降级的时候只需要两步就可以：1、实现要降级的接口，定义Fall Back类；2、要Fall Back方法上以注解的形式配置降级参数。

参数如何降级参数如何设置呢？

我们进行参数设计是需要遵循两个原则：普通网络抖动不触发降级，尽可能快的发现发现服务异常进入降级状态。

我们的做法是：

1、统计过往服务正常状态下由于网络抖动触发的超时量；

2、以这个量基准与当时的请求量相比较得到降级触发的阀值；

3、 开放在线手动微调接口，对其参数进行微调，以保证设置的参数达到最优效果。

2.5幂等防重设计

我们采用两层防护措施进行防重设计。第一层DB层，幂等的key用唯一索引，保证DB底层只有一条数据入库。第二层应用层，我们采用基于Redis的幂登锁来保证数据的唯一性。引入第二层的原因是减少DB的压力。第一层是兜底层，防止Redis挂了无法进行防重。

3、目前我们的架构

经过我们的实践和建设，形成了我们目前的整体架构：

图1-6 资源中心系统架构

二、性能优化之路

在保障高可用的前提下，作为支持商家使用的基础服务，从性能上能够快速响应，也是我们的重中之重。在性能优化的道路上，我们也介绍一下我们的一些实践经验。

1、服务外部优化

我们基于Mongo提供日志流水的查询，经过我们进行索引优化后，还存在稍微量大一点的数据就会超时。就我们查询的数据量来看在MySQL下一点问题也没有。经过我们与DBA的长期观察与解决，由于投入的人力、时间成本有限以及社区没有相关的问题的解决方案，最终没有找到问题的根本原因从而解决问题。

不能再一颗树上吊死，我们换了另外一种思路，换个存储介质是否可以？

1、 Mongo存的是操作日志，不存在更新的为，数据比较好迁移

2、 Mongo运维人员较少而且大数据平台拉取数据支持的不友好

经过分析确实可行，我们最终选择了TiDB。三方面原因：

1、不需要我们应用层进行分库分表，性能也能满足我们的需求；

2、运维以及公司的基础环境相对比较完善投入的人力成本以及硬成本比较好；

3、社区比较活跃遇到棘手问题容易解决。

最终我们经过大概10个人天的时间从迁移数据到下掉双写代码。而且效果非常好，原来200左右的超时量，下降到50以内。

2、服务内部优化

2.1、JVM调优

每次服务启动或者重启时都会有一段时间的超时。我们通过JSTAT命令监控服务，我们发现服务在每次启动的时候都会有4次FGC，接下来我们观察GC日志发现4次FGC的原因是因为元空间不够了，最终4次GC后元空间的大小为100多M，最终我们将JVM的参数调整为：MateSpace=256m。为什么不是128呢？给未来预留余地，防止未来随着项目的元数据增多再次发生同样的问题。

启动时FGC是没有了，但是我们发现我们的服务由物理机迁移到docker云平台后，YGC的时间大大的增加了，几乎每次YGC时都会有服务超时。当时我们的新生代配置是10G空间，按照默认Eden和两个Survivor的比例是8：1：1新生代的空间是老年代的8倍。我们的物理机的配置是32核128G而我们的云机器是8核16G，CPU核数少了四倍，内存少了8倍。总所周知JVM在进行GC处理的时候主要是利用CPU进行内存整理，算是一个CPU密集型操作。现在CPU计算能力减少了4倍GC的耗时理所当然的就要增加了。

这时我们并没有贸然的增加云机器的配置，因为我们日常8核16G其实基本上够用了，没有必要为了YGC的问题额外的浪费成本。我们也没有贸然的将现有的新生代减少4倍。这样新生代空间骤然减少这么多倍，可能会带来更加频繁YGC的风险，导致服务整体耗时会更慢，甚至会出现线上事故。我们采取较为缓和的手段，一点一点减少新生代大小以及减少Eden以及Survivor的比例。最终，经过我们反复尝试将JVM参数调至：-Xmn:8g -XX:SurvivorRatio=4。