是 iOS 平台的自动内存泄漏检测工具,Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架

by admin on 2020年3月13日

摘要自去年11月份阿里公开宣布重启维护Dubbo 之后,8 日夜间,Dubbo
创始人之一梁飞在 Dubbo 交流群里透露了 Dubbo 3.0
正在动工的消息。概述2018年1月8日夜间,Dubbo 创始人之一梁飞在 Dubbo
交流群里透露了 Dubbo 3.0
正在动工的消息。什么是Dubbo百度百科上说:Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的
RPC
实现服务的输出和输入功能,可以和Spring框架无缝集成。知乎上的答友说:1.
Dubbo负载均衡是对外提供一个公共地址,请求过来时通过轮询、随机等,路由到不同server。目的分摊压力。失效备援是发现一台server挂了,就让另外一台去服务了。跟餐馆换个服务员继续招待你一样;2.
Dubbo是Java下的一套RPC框架(soa思想),作用就是统一管理配置,各个系统服务间的调用。dubbo在淘宝也是解决他们实际问题的,不一定适合其他。
另外各家公司也都有大同小异的实现,所以没多少人用、也就没多少介绍。原理就是:
A系统调用B系统接口服务,
后面就是怎么把这个流程,动态化(zookeeper通知)、权限化、配置化、低耦合化、自动化。总之:Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求。Dubbo
3.0重大革新据了解,新的 Dubbo 内核与 Dubbo 2.0 完全不同,但它兼容
2.0。Dubbo 3.0 将以 Streaming 为内核,而不再是 2.0 时代的 RPC,但是 RPC
会在 3.0 中变成远程 Streaming
对接的一种可选形态。梁飞给出了一个内核接口:Streaming
docking(Streaming),他说一切服务治理将围绕这个内核接口进行扩展。而
Streaming 通道与 gRPC 类似,支持 HTTP/2,同时 REST
接口也会受到一等公民支持,但是梁飞也表示此次在通讯上的改动并不大,重点是在服务治理和编程模型上。说到编程模型的革新,梁飞透露,此次
Dubbo 3.0
能够开工,主要也是因为新特性将去掉一切阻塞,以“一切同步”为第一目标,在对
IO
密集业务的处理上,它能够提高机器利用率,使得一半机器的成本被节省下来。他还表示,其实
Dubbo 3.0
技术选型重大变更的驱动因素,也就是降低成本,因为在将系统服务化后,全业务线的机器都在等待返回数据,负载压不上去,机器浪费严重。这个去阻塞化的模式,其实就是使用了“反应式编程”模式(Reactive
Programming),梁飞介绍,在 Dubbo 3.0 中,reactive
将成为核心,会做到客户端、服务端、缓存和数据库,全程无阻塞。在数据库上,JDBC
驱动将进行更改,同时,为了性能,还会配合使用阿里毕玄对 JVM
协程的改造。更为重要的是,这个重大变更,不仅体现在 Dubbo
上,它也将影响到阿里 10 年来积累的中间件。群里有人问到是否会采用 Service
Mesh,梁飞表示,Dubbo 3.0 将支持可选 mesh,多加一层
IPC,这主要是为了兼容老系统;而内部则会优先尝试内嵌模式。他说代理模式
Ops
可独立升级框架,减少业务侵入,而内嵌模式可以带业务测试、部署节点少、稳定性检测方便。同时,可以将
Dubbo 3.0 启动为独立进程,由 dubbo-mesh 进行
IPC,路由、负载均衡和熔断机制将由独立进程控制。拭目以待据说,目前Dubbo
3.0 已正式投入全职开发梯队,初步 Runtime 已在验证,3
月底将在线上应用投入使用。自去年11月份阿里公开宣布重启维护Dubbo
之后,大家一直在关注着Dubbo
的进展。今天这样一个小道消息的爆出,让大家很是兴奋,希望Dubbo真正完成涅磐重生!开源地址Dubbo
GitHub地址:

摘要腾讯今日开源了业界首创iOS自动内存泄露检测工具MLeaksFinder,MLeaksFinder
是 iOS 平台的自动内存泄漏检测工具,引进 MLeaksFinder
后,就可以在日常的开发,调试业务逻辑的过程中自动地发现并警告内存泄漏。前言腾讯今日开源了业界首创iOS自动内存泄露检测工具MLeaksFinder,MLeaksFinder
是 iOS 平台的自动内存泄漏检测工具,引进 MLeaksFinder
后,就可以在日常的开发,调试业务逻辑的过程中自动地发现并警告内存泄漏。MLeaksFinder简介MLeaksFinder
是 iOS 平台的自动内存泄漏检测工具,引进 MLeaksFinder
后,就可以在日常的开发,调试业务逻辑的过程中自动地发现并警告内存泄漏。开发者无需打开
instrument
等工具,也无需为了找内存泄漏而去跑额外的流程。并且,由于开发者是在修改代码之后一跑业务逻辑就能发现内存泄漏的,这使得开发者能很快地意识到是哪里的代码写得问题。这种及时的内存泄漏的发现在很大的程度上降低了修复内存泄漏的成本。特性介绍自动检测内存泄漏和释放不及时的场景构建泄漏对象相对于
ViewContrller
的引用链以帮助开发者定位问题不侵入业务逻辑,引入即生效,无需修改任何代码或引入头文件工程主页和源码地址团队博客:

摘要阿里巴巴于近期正式开源了其自研的动态非侵入AOP解决方案:JVM-Sandbox。JVM-Sandbox即JVM沙箱容器,一种JVM的非侵入式运行期AOP解决方案。写在前面随着软件部署规模的扩大,系统的功能的细化,系统间耦合度和链路复杂度不断加强。若要继续保持现规模系统的稳定性,需要实现并完善监控体系、故障定位分析、流量录制回放、强弱依赖检测、故障演练等支撑工具平台。出于对服务器规模和业务稳定性的考量,这些配套工具平台要具备对目标应用具有无侵入、实时生效、动态可插拔的特点。要实现这些,多少都会触及到一块底层技术——动态字节码增强。如果每个工具都自己实现一套字节码增强逻辑,前期实现的门槛与后期维护成本高,且不同工具间相互影响造成不可预知的风险。如何屏蔽字节码增强技术的高门槛,降低研发运维成本,同时又能支持上层多个工具平台功能的快速实现和动态管理,成为阿里集团的目标。从去年开始潜心修行,创新的研发了一套实时无侵入的字节码增强框架。于是
JVM-Sandbox
诞生了!诞生历程2014年GREYS第一版正式发布,一路看着他从无到有,并不断优化强大,感慨羡慕之余,也在想GREYS是不是只能做问题定位。2015年开始根据GREYS的底层代码完成了人生的第一个字节码增强工具——动态日志。之后又萌生了将其拆解成录制回放、故障模拟等工具的想法。扪心自问,我是想以一人一个团队的力量建立大而全的工具平台,还是做一个底层中台,让每一位技术人员都可以在它的基础上快速的实现业务功能。我选择了后者。应用场景JVM-Sandbox
的目标群体Btrace
好强大,也曾技痒想做一个更便捷、更适合自己的问题定位工具,既可支持线上链路监控排查,也可支持单机版问题定位。有时候突然一个问题反馈上来,需要入参才能完成定位,但恰恰没有任何日志,甚至出现在别人的代码里,好想开发一个工具可以根据需要动态添加日志,最好还能按照业务
ID
进行过滤。系统间的异常模拟可以使用的工具很多,可是系统内的异常模拟怎么办,加开关或是用
AOP
在开发系统中实现,好想开发一个更优雅的异常模拟工具,既能模拟系统间的异常,又能模拟系统内的异常。好想获取行调用链路数据,可以用它识别场景、覆盖率统计等等,覆盖率统计工具不能原生支持,统计链路数据不准确。想自己开发一个工具获取行链路数据。我想开发录制回放、故障模拟、动态日志、行链路获取等等工具,就算我开发完成了,这些工具底层实现原理相同,同时使用,要怎么消除这些工具之间的影响,怎么保证这些工具动态加载,怎么保证动态加载
/
卸载之后不会影响其他工具,怎么保证在工具有问题的时候,快速消除影响,代码还原。如果你有以上诉求,那么你就是
JVM-Sandbox 的潜在客户。JVM-Sandbox
提供动态增强类你所指定的类,获取你想要的参数和行信息;提供动态可插拔容器,管理基于
JVM-Sandbox 的模块。JVM-Sandbox 能做什么?在
JVM-Sandbox(以下简称沙箱)的世界观中,任何一个 Java
方法的调用都可以分解为BEFORE、RETURN和THROWS三个环节,由此在三个环节上引申出对应环节的事件探测和流程控制机制。不仅如此还有LINE事件,可以完成代码行的记录。//
BEFORE-EVENTtry { /* * do something… */ //LINE-EVENT a(); //
RETURN-EVENT return;} catch (Throwable cause) { //
THROWS-EVENT}基于BEFORE、RETURN和THROWS三个环节事件以及LINE事件,可以完成很多类
AOP
的操作。可以感知和改变方法调用的入参可以感知和改变方法调用返回值和抛出的异常可以感知一个请求按顺序执行了哪些行可以改变方法执行的流程在方法体执行之前直接返回自定义结果对象,原有方法代码将不会被执行在方法体返回之前重新构造新的结果对象,甚至可以改变为抛出异常在方法体抛出异常之后重新抛出新的异常,甚至可以改变为正常返回JVM-Sandbox
都有哪些可能的应用场景线上故障定位线上系统流控线上故障模拟方法请求录制和结果回放动态日志打印安全信息监测和脱敏行链路计算和覆盖率统计JVM
沙箱还能帮助你做很多很多,取决于你的脑洞有多大了。JVM-Sandbox
在阿里集团的应用线上故障演练17 年故障演练平台在 JVM-Sandbox 基础上仅耗时
1
周即完成故障注入部分的系统重构。重构后的系统在挂载效率和挂载成功率方面有了明显的提升,极大的缩短的故障演练的时间,演练效率提升了数十倍。基于
JVM-Sandbox 改造后的故障演练平台,通用性强,所有基于 JVM
启动的系统均支持,极大的拓展了故障演练的范围,故障演练已达到集团级部署。与
16 年故障演练数据对比,17 年的故障演练平台,覆盖 BU 提升了 1.6
倍,覆盖应用提升了 5 倍,覆盖场景提升了 37 倍。依赖检测17
年强弱依赖自动化检测平台诞生。它提供了依赖检测、强弱分析、依赖扫描、故障注入等多种能力,底层能力基于
JVM-Sandbox 在 1
周内完成功能开发。利用其模块容器的特性,将前人开发的模块与新增模块一起挂载共同工作,完成平台功能。强弱依赖梳理方面,承载了淘宝的系统强弱依赖梳理工作,260+
个应用一键接入系统,并实现了 0
人工成本的自动化、智能化梳理。服务端录制隔离回放机制在 JVM-Sandbox
基础上开发了一个 SS 模块,相当于一个录音机 + 回放机,
在调用中间件的时候, 顺序录制下了我们的中间件请求,
并且存储这份‘磁带’到服务器上。当我们需要隔离回放的时候,
将这份‘磁带’找到, 并且在需要的时候直接从‘磁带’读取,
并不需要真实地请求我们的中间件,
这样就保证了我们的读、写接口也能做到可重复使用,从而实现服务端的隔离回放。线上录制隔离回放不仅极大的缩短的业务回归的耗时,把业务测试同学从繁琐的数据准备和接口自动化脚本的编写过程中解放出来,而且极大的拓展了覆盖范围,使回归的范围更贴近用户,且场景更丰富。精准回归服务端录制隔离回放机制诞生之后,虽然有效的提升了覆盖范围,降低了自动化脚本的人工投入,但是也带来了新的问题。线上录制的场景是海量的,单个系统都可以达到万级、十万级甚至百万级别的录制,这些录制的场景中,存在大量的重复场景,如何识别重复场景,实现有效、精准的回放,成为新的待解决问题。17
年在 JVM-Sandbox 的基础上,利用 LineEvnet
实现了行链路识别和标记,有效的提升了回放的精准度和效率。JVM-Sandbox
在阿里集团已经实现全网部署,在其上加载不同的模块实现了不同的功能,每个功能根据
BU
和应用的需要进行加载:强弱依赖检测功能:覆盖淘宝、天猫、业务平台、菜鸟、飞猪、ICBU、CBU
等 7 个 BU,240+
个应用;线上故障演练功能:覆盖集团客户体验事业群、淘宝网、云零售事业部、天猫、业务平台、飞猪、菜鸟、钉钉、阿里健康、CBU、集团安全、支付宝等
16 个 BU,391 个应用;服务端录制回放:覆盖淘宝网、钉钉 2 个
BU;精准回归:覆盖淘宝网、业务平台、钉钉 3 个
BU。通过上边的事例,想必大家对 JVM-Sandbox
是什么,核心功能是什么,还能做哪些事情,以及是否可以为阿里以外的同学提供服务等问题更感兴趣了,下面我们着重介绍这部分内容。开源和共建1、已开源,寻求更多的同学一起完善
JVM-Sandbox 的功能。Github
地址:
JVM-Sandbox
的功能;3、希望更多的同学想到跟多的应用场景,并能开源出来供大家使用。综上,JVM-Sandbox
是一个纯 java 编写的 AOP
解决方案。它为研发人员提供了一个快速实现字节码增强工具的平台。他的模块管理功能可以最大限度的复用模块、协同合作,减少重复投入。随着
JVM-Sandbox
的开源,我们期待更多的人加入到功能扩张和优化上,使其适配更多的开源中间件和
JVM。希望有更多的同学,发挥其聪明才智,开发更多、更好的上层模块,提供给自己和其他人的人使用。也希望能够利用好已有的模块,组装出新的工具平台和应用场景。JVM-Sandbox
建设和应用期待大家共同建设。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图