Networknt Light 4J分析报告

Networknt Light 4J分析报告

 

 

一、整体介绍

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核心组件进行实现，集成了尽可能少的第三方依赖库。在架构设计时，主要遵循以下设计原则：

1. 专门为微服务进行设计，并对容器化部署进行适配优化
2. 摒弃复杂的JavaEE，仅基于纯粹的HTTP进行实现
3. 以安全第一为设计原则，内嵌了OAuth2.0实现和分布式网关的实现
4. 设计中考虑了如何在微服务上实现分布式事物
5. 将各个不同功能都设计为插件形式，易于框架的定制和扩展
6. 服务消费方直接支持服务的发现，无需通过服务网关、服务代理等机制进行实现
7. 日志可以结合ElasticSearch,、LogStash、Kibana提供监控和报警能力
8. 内嵌的服务调用统计和链路跟踪功能
9. 实现了自己的依赖注入机制，无需引入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而言，我们可以深入了解其提升性能的核心技术实现思路并进行参考。

转载于:https://my.oschina.net/u/4142103/blog/3056593