共计 7369 个字符，预计需要花费 19 分钟才能阅读完成。
作者：十眠
为什么有了无损下线，还须要无损上线？无损上线能够解决哪些问题？
本篇文章将一一答复这些问题。
无损上线性能不得不说是一个客户打磨进去的性能
咱们将从一次公布问题的排查与解决的过程说起。
背景
阿里云外部某利用核心服务在公布过程中呈现了大量的 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 static boolean registerAsParallelCapable()
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 折优惠。点击 此处 ，即享优惠！