作者：十眠
为什么有了无损下线，还需求无损上线？无损上线能够处理哪些问题？
本篇文章将逐个回答这些问题。
无损上线功用不得不说是一个客户打磨出来的功用
咱们将从一次发布问题的排查与处理的进程说起。
布景
阿里云内部某运用中心服务在发布进程中呈现了很多的 5xx 超时反常。开端怀疑是无损下线问题，于是很快便接入了 MSE 供给的无损下线功用。可是接入无损下线功用后继续发布，运用的发布进程依然存在很多的超时报错。根据事务方同学的反馈，大约运用在发动后 5 秒左右，会有很多超时恳求。
无损下线功用未收效？
于是拉了相关的同学开端排查。运用的调用状况如下：gateway – > A -> C 。
发布的运用为 C 运用，发布进程中呈现很多超时报错。咱们经过相关日志与运用的发动状况，整理如下线索：
【服务端视角】：找了一台 C 运用的机器 xxx.xxx.xxx.60 调查
第一阶段：xxx.xxx.xxx.60 (C 运用)下线阶段
- 20:27:51 开端重启，履行重启脚本
-
- 一同调查到履行了 sendReadOnlyEvent 动作，标明服务端发送只读事件，客户端不会再恳求该服务端
- 在 sendReadOnlyEvent 后，开端连续履行刊出服务动作
- 20:27:54 刊出一切 provider seivce 完结
- 20:28:15 运用收到 kill -15 信号
第二阶段：xxx.xxx.xxx.60 (C 运用)上线阶段
- 20:28:34 服务端重新发动
- 20:29:19 在 Dubbo 注册中心操控台调查到 xxx.xxx.xxx.60 注册结束
- 20:29:19,257 日志中看到 start NettyServer
【客户端视角】：找了一台 A 运用的机器 XXX.XXX.XXX.142 调查
- 20:27:51 received readOnly event，收到服务端发送的只读事件，此刻该客户端不会恳求至 XXX.XXX.XXX.60 机器
- 20:27:56 close [xxx.xxx.xxx.142:0 -> /XXX.XXX.XXX.60:20880] ，关闭channel衔接
事务日志报错信息
一同搜 C 运用的机器 XXX.XXX.XXX.60 的报错相关的日志，共 237 条日志
其间最早的 time: 2020-07-30 20:29:26,524
其间最晚的time: 2020-07-30 20:29:59,788
结论
调查这些痕迹能够开端得出结论：
- 无损下线进程均契合预期，而且下线进程中并没有呈现任何报错
- 报错期间处于服务端运用成功发动后且注册成功后，与事务方调查的现象共同
这时候怀疑是上线期间的问题，一同排查服务端相关日志，发在报错期间，服务端线程被打满：
问题定位为上线进程中的问题，与无损下线无关。
无损上线实践
咱们帮助用户处理问题的思路：帮助用户发现问题的本质、找到问题的通用性、处理问题、将处理通用问题的才能产品化。
发现用户 Dubbo 版别比较低，短少自动打线程仓库的才能：
- 经过 MSE 添加 Dubbo 线程池满自动 JStack 才能
这是每次发布必现的问题，经过调查线程池满时的 JStack 日志，有助于咱们定位问题。
阻塞在异步衔接等资源预备上
开端调查 JStack 日志，发现不少线程阻塞在 taril/druid 等异步衔接资源预备上：
一同咱们云上也有有客户遇到过，运用发动后一段时刻内 Dubbo 线程池满的问题，后经过排查因为 Redis 衔接池中的衔接未提前树立，流量进来后很多线程阻塞在 Redis 衔接树立上。
衔接池经过异步线程坚持衔接数量，默许在运用发动后 30 秒树立最小衔接数的衔接。
1、处理思路
- 提前树立衔接
- 运用服务推迟发布特性
2、预建衔接
以 JedisPool 预建衔接为例，提前树立 Redis 等衔接池衔接，而不是等流量进来后开端树立衔接导致很多事务线程等候衔接树立。
org.apache.commons.pool2.impl.GenericObjectPool#startEvictor
protected synchronized void startEvictor(long delay) {
if(null != _evictor) {
EvictionTimer.cancel(_evictor);
_evictor = null;
}
if(delay > 0) {
_evictor = new Evictor();
EvictionTimer.schedule(_evictor, delay, delay);
}
}
JedisPool 经过守时使命去异步确保最小衔接数的树立，但这会导致运用发动时，Redis 衔接并未树立完结。
自动预建衔接方法：在运用衔接之前运用 GenericObjectPool#preparePool 方法去手动去预备衔接。
在微服务上线进程中，在初始化 Redis 的进程中提前去创立 min-idle 个 redis 衔接，确保衔接树立完结后再开端发布服务。
同样有类似问题，预建数据库衔接等异步建连逻辑，确保在事务流量进来之前，异步衔接资源全部安排妥当。
3、推迟发布
推迟发布为了一些需求异步加载的前置资源如提前预备缓存资源，异步下载资源等，需求操控服务注册时机，即操控流量进入的时机确保服务所需的前置资源预备完结该服务才能够进行发布，推迟发布有两种方法
- 经过 delay 装备方法
经过指定 delay 大小例如 300 s，Dubbo/Spring Cloud 服务将会在 Spring 容器初始化完结后进行后等候 5 分钟，再履行服务注册逻辑。
- online 指令上线
经过翻开默许不注册服务装备项，再配合发布脚本等方法履行 curl 127.0.0.1:54199/online 地址触发自动注册。咱们能够在前置资源预备完结后，经过 online 指令去注册服务。
也能够在 MSE 实例概况经过服务上线去注册服务。
阻塞在 ASMClassLoader 类加载器上
很多线程阻塞在 fastjson 的 ASMClassLoader 类加载器加载类的进程中，翻看 ClassLoader 加载类的代码其默许是同步类加载。在高并发场景下会导致很多线程阻塞在类加载上，然后影响服务端功用，形成线程池满等问题。
private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;
// 敞开并行类加载
if (ParallelLoaders.isRegistered(this.getClass())) {
parallelLockMap = new ConcurrentHashMap<>();
package2certs = new ConcurrentHashMap<>();
domains =
Collections.synchronizedSet(new HashSet<ProtectionDomain>());
assertionLock = new Object();
} else {
// no finer-grained lock; lock on the classloader instance
parallelLockMap = null;
package2certs = new Hashtable<>();
domains = new HashSet<>();
assertionLock = this;
}
}
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
......
return c;
}
}
protected Object getClassLoadingLock(String className) {
Object lock = this;
//假如敞开类加载器并行类加载，则锁在所加载的类上，而不是类加载器上
if (parallelLockMap != null) {
Object newLock = new Object();
lock = parallelLockMap.putIfAbsent(className, newLock);
if (lock == null) {
lock = newLock;
}
}
return lock;
}
1、处理思路
- 敞开类加载器并行加载
2、类加载器敞开并行类加载
JDK7 上，假如调用下面的方法，则会敞开并行类加载功用，把锁的等级从 ClassLoader 对象自身，降低为要加载的类名这个等级。换句话说只需多线程加载的不是同一个类的话，loadClass 方法都不会锁住。
咱们能够看 Classloader.registerAsParallelCapable 方法的介绍
protected staticbooleanregisterAsParallelCapable()
Registers the caller as parallel capable.
The registration succeeds if and only if all of the following conditions are met:
no instance of the caller has been created
all of the super classes (except class Object) of the caller are registered as parallel capable
Classloader.registerAsParallelCapable
它要求注册该方法时，其注册的类加载器无实例而且该类加载器的承继链路上一切类加载器都调用过registerAsParallelCapable，关于低版别的 Tomcat/Jetty webAppClassLoader 以及 fastjson 的 ASMClassLoader 都未敞开类加载，假如运用里边有多个线程在一同调用 loadClass 方法进行类加载的话，那么锁的竞赛将会十分激烈。
MSE Agent 经过无侵入方法在类加载器被加载前敞开其并行类加载的才能，无需用户晋级 Tomcat/Jetty，一同支撑经过装备动态敞开类加载并行类加载才能。
其他一些问题
- JVM JIT 编译问题引起 cpu 飙高
- 日志同步打印导致线程阻塞
- Jetty 低版别类加载类同步加载
- K8s 场景下，微服务与 K8s Service 生命周期未对齐
1、处理思路
- 服务预热
-
- 客户端负载均衡
- 服务端服务分层发布
- 事务日志异步化
- 供给微服务 Readiness 接口
2、事务日志异步化
同步进行日志打印，因为日志打印运用的是事务线程，因为日志打印进程中存在序列化、类加载等逻辑，在高并发的场景下会导致事务线程hang住，导致服务结构线程池满等问题。MSE Agent 支撑动态运用异步日志打印才能，将日志打印使命与事务线程分开，提高事务线程吞吐量。
3、小流量预热
运用发动后，很多恳求进入，导致运用存在许多问题,所以需求微服务的一些才能来处理服务预热问题：
- JVM JIT 编译线程占用 CPU 过高，CPU/load 短期内飙高，Dubbo 处理恳求功用下降
- 瞬时恳求量过大，导致线程阻塞在类加载、缓存等，然后导致 Dubbo 服务线程池满
小流量预热，MSE 服务管理经过 OneAgent 无侵入供给了以下几种才能：
- 客户端负载均衡
经过增强客户端负载均衡才能，关于刚上线的需求预热的节点进行流量权重的调整，做到刚上线的运用按照用户所装备的规则进行小流量预热，用户只需指定预热规则即可按照预期对刚上线的节点进行小流量预热
事务方的一台服务端实例运用服务预热后的效果:服务预热敞开后，待预热的运用将在预热周期内经过小流量完成运用发动进程的预热初始化。下图预热时长为 120 秒，预热曲线为 2 次的预热效果图：
阐明 该测验 Demo 是守时伸缩模仿运用发动，因此除了预热进程，还包括运用下线的进程。下图预热时长为 120 秒，预热曲线为 5 次的预热效果图：
如上图所示，比较于 2 次预热进程，5 次预热进程刚发动的这段时刻（即17:41:01~17:42:01），QPS 一向坚持在一个较低值，以满足需求较长时刻进行预热的复杂运用的预热需求。
- 服务端分层发布
经过修改服务注册的逻辑，添加对运用 load 等指标的监控，对服务进行分批注册现已回滚注册等逻辑，确保服务注册进程中，流量分服务进入，体系 load 始终低于阈值，而且需求在指守时长内将服务注册上去。
缺陷：在运用的服务流量平均，不存在超热点接口的状况下，分层发布能够很好地处理服务预热问题。可是假如运用存在一些超热服务，或许这个服务几乎占一切流量 90% 以上，那服务端分层发布效果并不会很明显。
留意：关于一些存在依赖的服务接口，服务分层发布或许需求事务整理服务分批发布的顺序
4、打通 K8s 与微服务生命周期
K8s 供给两种健康查看机制：
- livenessProbe，用于勘探不健康的 Pod，勘探失利将会重启 Pod。
- readinessProbe，用于勘探一个 Pod 是否安排妥当承受流量，勘探失利将会在 Service 路由上摘取该节点。
假如不装备 readinessProbe ，默许只查看容器内进程是否发动运转，而关于进程的运转状况很难考量，Mse Agent 经过对外供给 readiness 接口，只要 Spring Bean 初始化完结以及异步资源预备安排妥当而且开端服务注册时， readiness 才回来 200。将微服务侧的服务暴露与 K8s Service 体系打通，使 K8s 管控能感知到进程内部的服务安排妥当时机，然后进行正确地服务上线。
咱们需求在 MSE 无损上线页面敞开无损滚动发布的装备：
一同给运用装备 K8s 的安排妥当查看接口，假如您的运用在阿里云容器服务 ACK 上，能够在阿里云容器 ACK 服务对应运用装备的中健康查看区域，选中安排妥当查看右侧的敞开，装备如下参数，然后单击更新。
该运用在下次重启时，该装备即可收效。
5、服务并行订阅与注册
经过并行的服务注册与订阅，能够大幅提升运用发动的速度，处理服务发动慢的问题。
以并行服务订阅为例：
如上图所示，经过 Java Agent 将服务结构 refer 的流程从 SpringBean 的初始化流程中剥离出来而且经过异步线程来完成服务的并行订阅与注册。
总结
经过不断地调查事务状况，然后进行不断地问题剖析考虑与处理的尝试，直到敞开了服务小流量预热才能后，彻底处理了事务团队运用在上线期间线程池满导致恳求有损的问题。
- 发布期间 Exception 总量与发布日期（包括无损上线功用连续上线的节点）的状况如下图
9 月 15 号发布了服务小流量预热才能后，发布期间相关 Exception 下降至 2。（经事务方承认不是因为发布引起的，能够忽略）
上线了无损上线功用后，事务团队的运用中心继续多个月的发布报错问题总算告一段落，可是无损上线功用远不止于此。还处理许多云上客户上线有损的状况，功用的才能与场景也在不断地处理问题中逐步完善与丰厚。
MSE 无损上线
MSE 服务管理一个特点是经过 Agent 无侵入地支撑市面上近五年来 Dubbo、Spring Cloud 一切版别，所以无损上线这个功用也会是如此，下面会以 Dubbo 为例子无损上线的功用，当然一切才能咱们都是无缝支撑 Dubbo、Spring Cloud 的。
下面开端体系地介绍一下 MSE 服务管理的无损上线，咱们能够先从开源的一个 Dubbo 运用上线的流程开端剖析：
- 运用初始化，Spring Bean容器初始化
- 收到 ContextRefreshedEvent后，Dubbo 会去拉取 Dubbo运用所需的装备、元数据等
- exportServices 注册服务
开源 Dubbo 上线流程仍是十分完善与谨慎，可是依旧存在一些场景会导致服务上线存在问题：
-
当服务信息注册到注册中心后，在消费者看来该服务便是能够被调用的。可是，此刻或许存在一些数据库、缓存资源等一些异步资源尚未加载结束的场景，这取决于你的体系有没有对应的组件，它们何时加载结束，也完全取决于你的事务。
-
假如在大流量的场景下，服务在注册到注册中心后，立刻有大流量进入，存在一系列问题，导致线程阻塞，对事务流量形成损失
-
- 比如 Redis 的 JedisPool 衔接池创立后并不会当即树立衔接，会在流量进来后开端树立衔接，假如一开端涌进的是大流量，则导致很多线程阻塞在衔接池重的衔接的树立上
- FastJson 以及 Jetty/tomcat 等低版别中，并未敞开类加载器并行类加载才能，导致很多线程阻塞在类加载器加载类上
- JVM JIT 编译问题引起 cpu 飙高
- 线程阻塞在事务日志上
-
云原生场景下，微服务与 K8s 的生命周期未对齐的状况
-
- 滚动发布，重启的 pod 还未注册至注册中心，可是 readiness 查看以及经过。导致第一个 pod 还未注册至注册中心，最终一个 pod 以及下线，导致短时刻内的客户端 NoProvider 反常
针对如上问题，MSE 服务管理不仅供给了完整的处理方案，还供给了白屏化开箱即用的才能，动态装备实时收效。
一同 MSE 服务管理针对无损上下线的场景还供给了完整的可观测才能。
无损上线功用能够总结为以下这张图：
不只是无损上下线
无损上下线才能是微服务流量管理中的重要的一环，当然除了无损下线，MSE 还供给了全链路灰度、流控降级与容错、数据库管理等一系列的微服务管理才能。服务管理是微服务改造深入到一定阶段之后的必经之路，在这个进程中咱们不断有新的问题呈现。
- 除了无损上下线，服务管理还有没其他才能？
- 服务管理才能有没一个规范的界说，服务管理才能包括哪些？
- 多言语场景下，有无全链路的最佳实践或者规范？
- 异构微服务怎么能够一致管理？
当咱们在探索服务管理的进程中，咱们在对接其他微服务的时候，咱们发现管理体系不同形成的困扰是巨大的，打通两套甚者是多套管理体系的成本也是巨大的。为此咱们提出了 OpenSergo 项目。OpenSergo 要处理的是不同结构、不同言语在微服务管理上的概念碎片化、无法互通的问题。
OpenSergo 社区也在联合各个社区进行进一步的合作，社区来一同讨论与界说一致的服务管理规范。当时社区也在联合 bilibili、字节跳动等企业一同共建规范，也欢迎感兴趣的开发者、社区与企业一同参加到 OpenSergo 服务管理规范共建中。欢迎我们参加 OpenSergo 社区交流群（钉钉群）进行讨论：34826335
MSE 注册装备首购 8 折，首购 1 年及以上 7 折。MSE 云原生网关预付费全标准享 9 折优惠。点击此处 ，即享优惠！
