一、官网整体介绍
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而言，我们可以深入了解其提升性能的核心技术实现思路并进行参考。
