关于阿里Java热加载框架jarslink的应用和选型研究

本文针对 jarslink v1.0+

(jarslink官方地址:https://github.com/alibaba/jarslink)


一、本身设计和功能问题(不成熟,功能弱):

1、jarslink自定义的API,无法和swagger等API文档自动生成工具结合;

2、传统的统一配置中心都是基于应用级别的隔离,无法针对module来隔离配置,和jarslink结合不好;

3、不能方便的支持多数据源和多redis源;

4、缺少各module之间的日志隔离规范,所有module的日志混在一起;

5、父module和子module之间无隔离,父module会影响到所有子module;

6、各module之间CPU、内存等资源无法隔离,一个module挂起会影响所有;

7、基于传统的classloader隔离方式,并无新意,甚至不如OSGi成熟(例如Equinox),又摆脱不了它固有的局限和缺点。


二、应用场景问题

1、如果module都按fatjar加载(大概60Mb),如果有十几个module,主项目将成为一个巨大型项目,增大管理成本和稳定性风险;

2、jarslink与微服务比,缺乏配套的内部监控和服务治理,不能做负载均衡、服务降级、限流、熔断等;

3、Classloader隔离技术,一直无法很好的解决内存管理和卸载问题,对可卸载的内容有严格要求,该技术最佳的应用场景是测试环境和一些边缘生产系统或特殊系统,对于服务隔离最好还是基于微服务技术;

4、金融公司、银行对于线上故障是非常敏感的,处理流程也相对严格,所以稳定第一,对于新技术的投产,需要严格测试。


三、周边风险

1、目前官方已废弃1.0版本,升级到了v2.0,基于SOFA框架,可以认为v1.0和v2.0完全是两个东西,间接说明之前版本存在问题;

2、目前该技术,Contributors只有1个,维护及稳定性问题值得担忧;

3、目前该技术,应用者寥寥无几,issues很少,阿里内部也只是小范围在使用,作为首批吃螃蟹的人,各种坑难以估计;

4、目前该技术,文档很少,遇到棘手问题,恐怕得查看源代码或者想办法联系作者,难度比较大;

5、阿里有强大的研发实力,有定制的Ali-JVM、SOFA配合支撑,而小公司不具备这种优势,也没有阿里的技术支持,建议选用社区比较丰富、成熟的产品。


© 2009-2020 Zollty.com 版权所有。渝ICP备20008982号