彩世界平台-彩世界时时app-彩世界开奖app苹果下载

热门关键词: 彩世界平台,彩世界时时app,彩世界开奖app苹果下载

您的位置:彩世界平台 > 活动会议 > 热补丁动态修复手艺科学切磋

热补丁动态修复手艺科学切磋

发布时间:2019-09-22 09:20编辑:活动会议浏览(162)

    零代价修复服务器内核缺陷 UCloud内核热补丁技术揭秘

    7月18日,由InfoQ主办的ArchSummit全球架构师峰会在深圳拉开帷幕,此次会议重点选择了6个当前最受关注的领域,包括:游戏、电商、移动互联网等等。UCloud作为国内专注服务上述垂直领域的云服务商,受邀参加了本次大会。会上,UCloud资深工程师邱模炯还以《UCloud云平台的内核实践》为主题,给大家揭开了UCloud云平台内核技术的神秘面纱。其中,“UCloud内核热补丁技术”更是引发了全场架构师们的极大关注。

    如何零代价修复海量服务器的Linux内核缺陷?

    对于一个拥有成千上万台服务器的公司,Linux内核缺陷导致的死机屡见不鲜。让工程师们纠结的是,到底要不要通过给服务器升级内核来修复缺陷?升级意味者服务器重启、业务中断以及繁重的准备工作;不升级则担心服务器死机,同样造成业务中断和繁重的善后工作。

    而在今天的云计算时代,一台宿主机往往运行多个云主机,每一次重启不管是主动升级还是被动死机,都意味着中断其上运行的所有云主机。因此,宿主机内核缺陷的修复更加棘手。

    而作为一个支撑着上万家企业用户IT基础架构的云服务商,UCloud云平台上的海量宿主机又是如何修复内核缺陷的呢?

    邱模炯透露,如果按照传统的重启方式来修复,那么无论是对于UCloud或是用户,都意味着繁重的运维和业务中断。但是,UCloud通过“内核热补丁技术”——即给运行中的内核打上二进制补丁,UCloud已经做到了零代价免重启修复海量服务器的内核缺陷!目前为止,UCloud对所发现的上游内核10+个缺陷全以热补丁方式修复,累计数万台次,无一例失败且无任何副作用;理论上避免了相应次数的宿主机重启及所隐含的云主机业务中断。这项技术在UCloud已经成熟。

    UCloud 内核热补丁技术揭秘

    UCloud的热补丁技术基于多年前的开源ksplice加以定制优化而来,通过加载一个特殊准备的热补丁模块来修复内核。其过程如下图所示:

    图片 1

    热补丁模块由ksplice程序编译生成,包含有缺陷的二进制指令和修复后的二进制指令(这些二进制按函数级别组织);模块加载后,自动定位到内核的缺陷处并以修复指令动态替换缺陷指令。

    除了免重启修复,热补丁还用于内核开发过程的性能分析和故障定位。比如,加上性能统计代码生成热补丁,就可以在线分析感兴趣的性能问题;加入额外调试代码捕捉运行中内核的异常。这些非常有用,更是海量服务器里捕捉不可重现内核异常的不二法宝。由于热补丁不需要重启服务器,既可打入也可撤销,所以不会有副作用。

    UCloud对开源Ksplice的优化主要在以下三个方面:

    支持高版本内核

    热补丁技术与内核紧密耦合。不同版本的内核在指令结构体,符合表结构体和一些特性上(比如早期内核没有ftrace)有所不同,直接影响热补丁成败。UCloud研究了各版本内核的区别,使得同一份ksplice支持各个版本的Linux内核。值得一提的是,解决了ftrace与ksplice不兼容的问题。

    允许热修复频繁调用的函数

    不管什么样的热补丁技术,两种类型的内核函数难以热补丁:频繁使用的内核函数如schedule, hrtimer;经常处于线程栈内核部分顶部的函数,如sys_poll, sys_read。UCloud更改了ksplice相关内核代码和用户态工具,成功解除了这些限制,比如UCloud现网服务器已打入了三个hrtimer热补丁。

    减少业务中断时间

    ksplice是在stop_machine后替换二进制指令的。虽然单次stop_machine对业务造成的中断在一毫秒左右,但有些频繁使用的内核函数需要大量重试才能碰到合适的热补丁时机,于是会造成最长达上百毫秒的中断。UCloud在此做过一点优化,使得业务中断时间控制在十毫秒级别。

    海量服务器环境下热补丁技术可用来零代价且无副作用地修复内核缺陷,而且内核开发也因热补丁能走得更远更好。以前因为缺乏辅助分析手段和惧怕内核BUG,即使适合在内核实现的特性也被告诫移到用户态实现,然而有了热补丁,相关观念也可以适当调整,内核开发也可以更加大胆和跳脱。

    UCloud内核热补丁技术揭秘 7月18日,由InfoQ主办的ArchSummit全球架构师峰会在深圳拉开帷幕,此次会议重点选择了...

    如果发布了一个release包,但是里面出现了严重的事故级别(某些等不及下一版本迭代就得修复)的bug,那么站在公司角度,这边QA,开发,客服,甚至PR等部门都得加班赶忙发包重现覆盖,耗费的资源代价相当的大,而出问题的或许只是一两行代码;站在用户User角度,刚刚下载了一个包,准备尝鲜,发现又让更新,是不是很烦,如果新包打开就崩溃了,很多就会去市场评论,“垃圾,更新之后闪退”云云,抑或“垃圾,天天要更新”。在这个基础上热更新技术出现了,即使发出了release包,如果出现某些等不及下一版本迭代就得修复的bug,向用户下发Patch,在用户无感知的情况下,修复了bug或问题。

    花了几天查阅一些资料,去了解一些目前的热更新方案,主要有以下两大类型:

    参考文章:理解 Android Hook 技术以及简单实战

    无需重启Application、无需启动Activity即可更新Java方法 安卓代码要达到真正“热”更新的效果,也只有基于AOP这种技术,就是在方法级别这个粒度做替换。

    • ### ClassLoader(originally from qq空间团队 --原始)

      在它之后和他有相同原理的其他热门开源库有:
      • ###### Nuwa

      • ###### HotFix

      • ###### DroidFix

      • ###### Tinker

      需要重启Activity或重启Application达到更新效果。

    • ### Robust

    前两个都会存在一些兼容性问题,为此美团借鉴了Instant Run原理,推出Android热更新方案Robust

    • ##### 基于native hook的方案:需要针对dalvik虚拟机和art虚拟机做适配,需要考虑指令集的兼容问题,需要native代码支持,兼容性上会有一定的影响;但是无需重启Application、无需启动Activity即可更新Java方法。

    • ###### 基于Multidex的方案,需要反射更改DexElements,改变Dex的加载顺序,这使得patch需要在下次启动时才能生效,实时性就受到了影响,同时这种方案在android N [speed-profile]编译模式下可能会有问题,可以参考Android N混合编译与对热补丁影响解析

    • ###### 各大热补丁方案分析和比较

    本文由彩世界平台发布于活动会议,转载请注明出处:热补丁动态修复手艺科学切磋

    关键词:

上一篇:网盘seafile搭建进程

下一篇:没有了