一、官网整体介绍
Light 4J是networknt.com官网的核心产品。一个基于Java SE快速、轻量级并且高效的微服务框架。其包含十多个子模块,用于不同风格的API构建,包括OAuth2,Portal,Logging,Messaging和Metrics等基础设施服务。此外,还有一系列工具可帮助提高开发人员和操作人员的工作效率。
1、性能情况
在Light 4J官方的benchmark的测试报告中,将它与 Spring Boot 及其他微服务平台作了性能比较。Light 4J比Spring Boot内嵌Tomcat的主流微服务框架平台快44倍,并且只需要1/5内存,性能与 Go 语言并肩,拥有更低的平均延迟。
Framework | Language | Max Throughput | Avg Latency | Transfer |
Go FastHttp | Go | 1,396,685.83 | 99.98ms | 167.83MB |
Light-4j | Java | 1,344,512.65 | 2.36ms | 169.25MB |
Spark | Java | 194,553.83 | 13.85ms | 32.47MB |
Go Http | Go | 170,313.02 | 15.01ms | 20.95MB |
Spring Boot Undertow | Java | 44,260.61 | 38.94ms | 6.42MB |
Spring Boot Tomcat | Java | 33,086.22 | 82.93ms | 3.98MB |
2、Github情况
Light 4J目前共有71个Github子项目,其中Java项目39个,最高热度的项目为Light 4J本身,2167 star,354 fork,低于Spring Boot、Spring Cloud、Dubbo等项目。其余几个核心子项目,如light-oauth2、light-rest-4j、light-proxy等项目仅有一两百的star。
Light 4J项目目前共有23个代码贡献者,但目前关注的开发者开始逐渐加入, 形成开发梯队。
3、Light 4J能力清单
模块 | 描述 |
server | 基于Undertow实现http请求 |
security | 基于OAuth2实现JWT的校验和解析,并支持mock |
config | 支持独立应用的外配配置文件,支持docker配置文件 |
Utility | 一个工具集 |
client | 封装了httpclient和httpasyncclient的能力,支持缓存和jwt信息的读取 |
validator | 支持基于sawgger的请求参数和url路径校验,支持基于json-schema-validator的请求包体校验 |
audit | 支持以json的格式,将请求和响应报文输出到日志文件中 |
info | 提供一个/server/info端点,可以输出应用的各个组件配置信息 |
mask | 为特定数据脱敏,比如卡号等信息 |
status | 构建http错误类型模型,使用唯一的错误编号来帮助应用排查问题 |
swagger-codegen | 使用swagger规范生成API接口程序 |
balance | 复杂均衡模块,默认支持轮询和本地优先,可扩展开发 |
body | 支持将http body格式化成Java Map或List |
cluster | 支持通过服务名的方式进行服务发现 |
consul | Light 4j的consul注册中心实现 |
correlation、traceability | 链路跟踪模块 |
CORS | http CORS 访问控制模块 |
zookeeper | Light 4j的zookeeper注册中心实现 |
data-source | 各种数据库接入实现 |
decryptor、encode-decode | 加解密模块,支持AES |
rate-limit | 请求速率限制模块 |
prometheus | 支持prometheus格式数据接口 |
email-sender | 邮件发送模块 |
ip-whitelist | 请求白名单 |
metrics | 交易统计模块 |
二、框架设计思路及技术核心
Light 4J面向微服务架构进行设计,力求高吞吐、低延迟、轻量级。基于Undertow Core Http server核心组件进行实现,集成了尽可能少的第三方依赖库。在架构设计时,主要遵循以下设计原则:
- 专门为微服务进行设计,并对容器化部署进行适配优化
- 摒弃复杂的JavaEE,仅基于纯粹的HTTP进行实现
- 以安全第一为设计原则,内嵌了OAuth2.0实现和分布式网关的实现
- 设计中考虑了如何在微服务上实现分布式事物
- 将各个不同功能都设计为插件形式,易于框架的定制和扩展
- 服务消费方直接支持服务的发现,无需通过服务网关、服务代理等机制进行实现
- 日志可以结合ElasticSearch,、LogStash、Kibana提供监控和报警能力
- 内嵌的服务调用统计和链路跟踪功能
- 实现了自己的依赖注入机制,无需引入Spring等复杂框架
Light 4J框架将Handler请求拦截机制作为核心,在Handler中处理框架逻辑和业务逻辑。Handler可分为两种,一种是chain类型Handler,类似过滤器,会处理每个请求;另一种path类型Handler仅处理特定http路径请求。
配置chain handler有两个步骤:1、在yml配置文件中handlers的位置增加实现类定义(外部引入),格式为“包名.类名@别名”;2、在yml配置文件中的的chains位置增加该别名,别名的顺序代表处理的顺序,cross-cutting concerns处理链是开发是结构, 用户可以override或者加入自己的cross-cutting concerns处理链去支持其它标准或者应用, 比如opentracing, istio 等。
配置http handler有三个步骤:1、基于LightHttpHandler接口实现http请求处理类;2、在yml配置文件中handler位置定义该实现类的,格式为“包名.类名”;3、在yml配置文件中paths的位置配置http请求对应的请求方式、路径、实现类。
Handlers配置示例:
Chains配置示例:
Paths配置示例:
自定义Handlers实现示例:
三、总结
1、性能方面
Light 4J相比较与现有的Spring Boot、Spring Cloud或Dubbo,由于功能上的简化,性能上确实会来带较大的提升,同时它也提供了基础的服务注册与发现机制,支持zookeeper,支持容器上云部署。
不同于大应用(monolithic application), 微服务(microservices application)的每一个服务本身所处理的逻辑相对简单, 不应该把大量的业务逻辑处理和数据库交互放在单个服务(service API)中。而service to service的交互相对更加频繁 (servicemesher)。 很多复杂的业务逻辑处理应该分布在多个服务中,然后通过service to service的交互来完成。所以框架本身的性能和service to service的交互中的相应时间就极其重要。对于大规模容器上云部署, 可以显著地节约成本。
基于一个用户的测试报告:
For the same functionality,
Framework throughput latency memory
Spring-Boot 213/s 66.07ms 1.5GB
Light-4j 2319/s 11.39ms 300MB
2、生态方面
Light 4J主要的弱点在于其生态的相对薄弱。 Light 4J目前并没有完善的生态体系,社区方面热度也较低,主项目仅有2.2k的star,其他项目基本都只有几十到几百的star。相比于Spring健全的生态体系,能力上会弱很多,比如熔断、限流、配置中心这些能力目前处于没有实现或仅有简单方案的状态,与不同第三方中间件的对接,都要以Handler的模式进行二次开发适配。
3、能力方面
Light 4J框架Handler请求拦截机制对于开发者透明并且可延迟配置, 开发者可以集中精力在业务逻辑从而提高工作效率。 虽然Light 4J本身提供了较多微服务架构下所需的能力, 有些并没有跟踪行业标准。例如Light 4J框架内部提供了链路跟踪模块不支持Open Tracing . 用户可以按自己的标准设计并开发扩展模块 (cross-cutting concerns middleware handler)。
综上所述,对于Light 4J而言,我们可以深入了解其提升性能的核心技术实现思路并进行参考。