更快、更轻、更敏捷的应用运行时技术是云原生计算的持续追求。
体积更小 - 对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度。
知识蒸馏通过知识压缩的原理进行。使用诸如强化学习之类的技术，神经网络可以学习如何产生预期的结果。在这一点上，较小的网络将学习创建与较大的网络已经开创的结果相似。较小的网络规模更适合移动设备、传感器和类似硬件等边缘设备。知识蒸馏可以将边缘设备的空间负担减少多达2000%，从而减少了运行网络所需的能源、物理约束以及设备本身的成本。
基于ML的预测性维护的两个最重要的好处是它的快速性和准确性。 AI可以足够快速、准确地识别机械问题，以便在发生故障和故障之前进行纠正。例如，通用汽车使用安装在装配机器人上的摄像头，通过使用，它能够在5000多个机器人中检测出数十个组件故障，从而避免了停机的可能性。
B端的产品比较复杂（如上图所示）包括官网注册、H5、注册账号、创建项目、集成代码、使用产品、留存日活、pro付费等，KPI拆解到了注册账号数、注册转化率、有效集成数、首次完成激活等。在这之中，有些目标需要自己做，有些需要跟别的团队协同合作。
以友盟+服务的客户场景来说，比如在拿到一份高质量的数据之后，KPI在确定情况下进行了拆解，现在要做的就是希望团队里的人知道自己的KPI，KPI大屏就可以轻松解决这个问题。
全链路监控组件如何获得链路相关的信息呢？最简单的方式是让开发者在业务代码中手工埋点，生成符合OpenTracing标准的链路信息，并汇入全链路监控组件。但手工埋点的方式要求开发者主动配合，并在业务代码中嵌入大量非业务逻辑。
无法支撑大规模场景：当接入的应用数量达到上千个之后，开源全链路监控方案会暴露出各种性能问题，需要开发者修改源代码进行针对性的优化。
应用列表和全局拓扑
在应用列表视图，我们能看到每一个应用的健康度以及最近10分钟对外服务的响应情况。如果应用的状态列亮红灯，代表此应用运行不健康，我们可以继续点击红灯查看ARMS此应用生成的诊断报告，以进一步分析应用不健康的原因。
如果访问这个接口的上游应用也接入了ARMS，还能从链路上游页签查看每一个上游应用访问这个接口的请求数、响应时间和错误数。同样，如果这个接口对应的链路在离开这个应用后，还会继续访问接入了ARMS的下游应用，我们也能从链路下游页签查看到针对每一个下游应用的请求情况。
古人云：“活到老，学到老。”互联网算是最辛苦的行业之一，“加班”对工程师来说已是“家常便饭”，同时互联网技术又日新月异，很多工程师都疲于应付，叫苦不堪。以至于长期以来流传一个很广的误解：35岁是程序员工作的终点。
