Networknt Light 4J分析报告是怎样的
这篇文章将为大家详细讲解有关Networknt Light 4J分析报告是怎样的,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
Networknt Light 4J分析报告
一、整体介绍
Light 4J是networknt.com的核心产品。一个基于Java SE快速、轻量级并且高效的微服务框架。其包含十多个子模块,用于不同风格的API构建,包括OAuth3,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-oauth3、light-rest-4j、light-proxy等项目仅有一两百的star。
Light 4J项目目前共有23个代码贡献者,但目前关注的开发者开始逐渐加入, 形成开发梯队。
3、Light 4J能力清单
模块 |
描述 |
server |
基于Undertow实现http请求 |
security |
基于OAuth3实现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进行实现
以安全第一为设计原则,内嵌了OAuth3.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)。
关于Networknt Light 4J分析报告是怎样的就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。