给系统加上眼睛：服务端监控要怎么做？

你在搭建监控系统时，所面临的第一个问题就是选择什么样的监控指标，也就是监控什么。延迟、通信量、错误和饱和度。

• 延迟指的是请求的响应时间。比如接口的响应时间、访问数据库和缓存的响应时间。
• 通信量可以理解为吞吐量，也就是单位时间内请求量的大小。比如访问第三方服务的请求量，访问消息队列的请求量。
• 错误表示当前系统发生的错误数量。这里需要注意的是， 我们需要监控的错误既有显式的，比如在监控 Web 服务时，出现 4 * * 和 5 * * 的响应码；也有隐式的，比如 Web 服务虽然返回的响应码是 200，但是却发生了一些和业务相关的错误（出现了数组越界的异常或者空指针异常等），这些都是错误的范畴。
• 饱和度指的是服务或者资源到达上限的程度（也可以说是服务或者资源的利用率），比如 CPU 的使用率、内存使用率、磁盘使用率、缓存数据库的连接数等等。

 在采集到监控数据之后，你就可以对它们进行处理和存储了。在此之前，我们一般会先用消息队列来承接数据，主要的作用是削峰填谷，防止写入过多的监控数据，让监控服务产生影响。

应用性能管理：用户的使用体验应该如何监控？

与搭建服务端监控系统类似，在搭建端到端的应用性能管理系统时，我们也可以从数据的采集、存储和展示几个方面来思考。

• 系统部分：包括数据协议的版本号，以及下面提到的消息头、端消息体、业务消息体的长度；
• 消息头：主要包括应用的标识（appkey），消息生成的时间戳，消息的签名以及消息体加密的秘钥；
• 端消息体：主要存储客户端的一些相关信息，主要有客户端版本号、SDK 版本号、IDFA、IDFV、IMEI、机器型号、渠道号、运营商、网络类型、操作系统类型、国家、地区、经纬度等等。由于这些信息有些比较敏感，所以我们一般会对信息加密；
• 业务消息体：也就是真正要采集的数据，这些数据也需要加密。

 如果是由于网络导致的问题，那么需要检测请求过程中经历的一系列过程的时间。

1. 等待时间：异步调用时，请求会首先缓存在本地的队列里面，由专门的 I/O 线程负责，那么在 I/O 线程真正处理请求之前，会有一个等待的时间。
2. DNS 时间：域名解析时间。
3. 握手时间：TCP 三次握手的时间。
4. SSL 时间：如果服务是 HTTPS 服务，那么就会有一个 SSL 认证的时间。
5. 发送时间：请求包被发送出去的时间。
6. 首包时间：服务端处理后，客户端收到第一个响应包的时间。
7. 包接收时间：我们接收到所有数据的时间。

压力测试：怎样设计全链路压力测试平台？

尽量用线上的数据和线上的环境；拷贝流量的方式，把线上流量拷贝一份到压力环境；不要从一台服务器发起流量，这样很容易达到这台服务器性能瓶颈

配置管理：成千上万的配置项要如何管理？

配置存储是分级的，有公共配置，有个性的配置，一般个性配置会覆盖公共配置，这样可以减少存储配置项的数量；

配置中心可以提供配置变更通知的功能，可以实现配置的热更新；

配置中心关注的性能指标中，可用性的优先级是高于性能的，一般我们会要求配置中心的可用性达到 99.999%，甚至会是 99.9999%；

md5 值判断更新，这个套路常用；

配置中心客户端在获取到配置信息后，会同时把配置信息同步地写入到内存缓存，并且异步地写入到文件缓存中。内存缓存的作用是降低客户端和配置中心的交互频率，提升配置获取的性能；而文件的缓存的作用就是灾备，当应用程序重启时，一旦配置中心发生故障，那么应用程序就会优先使用文件中的配置，这样虽然无法得到配置的变更消息（因为配置中心已经宕机了），但是应用程序还是可以启动起来的，算是一种降级的方案。

降级熔断：如何屏蔽非核心系统故障的影响？

在检测到某一个服务的响应时间出现异常时，切断调用它的服务与它之间的联系，让服务的调用快速返回失败，从而释放这次请求持有的资源。这个思路也就是我们经常提到的降级和熔断机制。

• 当调用失败的次数累积到一定的阈值时，熔断状态从关闭态切换到打开态。一般在实现时，如果调用成功一次，就会重置调用失败次数。
• 当熔断处于打开状态时，我们会启动一个超时计时器，当计时器超时后，状态切换到半打开态。你也可以通过设置一个定时器，定期地探测服务是否恢复。
• 在熔断处于半打开状态时，请求可以达到后端服务，如果累计一定的成功次数后，状态切换到关闭态；如果出现调用失败的情况，则切换到打开态。

相比熔断来说，降级是一个更大的概念。因为它是站在整体系统负载的角度上，放弃部分非核心功能或者服务，保证整体的可用性的方法，是一种有损的系统容错方式。这样看来，熔断也是降级的一种，除此之外还有限流降级、开关降级等等。

开关降级指的是在代码中预先埋设一些“开关”，用来控制服务调用的返回值。比方说，开关关闭的时候正常调用远程服务，开关打开时则执行降级的策略。这些开关的值可以存储在配置中心中，当系统出现问题需要降级时，只需要通过配置中心动态更改开关的值，就可以实现不重启服务快速地降级远程服务了。

常见的降级策略：

• 针对读取数据的场景，我们一般采用的策略是直接返回降级数据。比如，如果数据库的压力比较大，我们在降级的时候，可以考虑只读取缓存的数据，而不再读取数据库中的数据；如果非核心接口出现问题，可以直接返回服务繁忙或者返回固定的降级数据。
• 对于一些轮询查询数据的场景，比如每隔 30 秒轮询获取未读数，可以降低获取数据的频率（将获取频率下降到 10 分钟一次）。
• 而对于写数据的场景，一般会考虑把同步写转换成异步写，这样可以牺牲一些数据一致性保证系统的可用性。

流量控制：高并发系统中我们如何操纵流量？

限流指的是通过限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则只能通过拒绝服务的方式保证整体系统的可用性。限流策略一般部署在服务的入口层，比如 API 网关中，这样可以对系统整体流量做塑形。而在微服务架构中，你也可以在 RPC 客户端中引入限流的策略，来保证单个服务不会被过大的流量压垮。

• 你可以对系统每分钟处理多少请求做出限制；
• 可以针对单个接口设置每分钟请求流量的限制；
• 可以限制单个 IP、用户 ID 或者设备 ID 在一段时间内发送请求的数量；
• 对于服务于多个第三方应用的开放平台来说，每一个第三方应用对于平台方来说都有一个唯一的 appkey 来标识，那么你也可以限制单个 appkey 的访问接口的速率。

限流算法：

固定窗口与滑动窗口的算法

漏桶算法与令牌筒算法

漏桶一般用队列来实现，但是会造成请求有延迟并且也对处理突发流量不友好。

令牌桶，通过往桶内定时放入一个令牌，请求过来时先要申请到令牌才能继续，否则请求失败，这个对于处理突发流量时比较友好，即平时可以攒，到突发流量时可以直接用起来，guava的ratelimiter就是令牌桶算法实现的，分布式令牌桶可以用redis来实现，可以一次申请多个而不是一个这样可以降低每次请求的开销。