本文针对 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配合支撑，而小公司不具备这种优势，也没有阿里的技术支持，建议选用社区比较丰富、成熟的产品。