最近在看Presto源码，研究如何高效的开发和部署微服务，发现一些有发展前景的东西拿出来和大家一起分享一下。
Airlift是什么
Airlift 是一个目前还处于开发早期的基于HTTP REST的Java微服务框架，由Facebook在2013年开发的分布式SQL查询引擎Presto 中分离出来，重新封装以后成为一个通用的微服务框架。Presto在2018年开源并加入到apache基金会的顶级项目，目前有包括Facebook，Lyft等公司已经大规模部署并投入日常生产，但Airlift现在用的人还很少，它离完善的解决方案还有一定距离。本文的目的不是为了介绍Presto，而是对Airlift做一个简单的入门，欢迎有兴趣的小伙伴一起深入研究和探讨它合适的用途。
HTTP REST微服务框架
现在基本上大部分公司都已经转型微服务架构了，目前国内比较流行的out-of-the-box框架主要是阿里的Dubbo （基于RPC）和spring cloud（基于REST）。那么Airlift和它们相比有什么优势和劣势呢？一个直观的感觉是它高度结构化，是一个集合了大家熟知的一些Java依赖库的完整框架，涵盖了几乎server端所有的功能模块，非常轻量级，各个模块子系统的分工明确，耦合度很低，通信协议主要是HTTP REST。它和spring cloud的功能比较相似，但由于没有使用spring框架依赖或是动态代理，Airlift在运行时消耗的系统资源很少，依赖注入主要由Google Guice提供，在bootstrap阶段就已经完成。所以在系统灵活性方面不及spring cloud，但是安全性也大大提高。
个人感觉它的设计目标主要有：
- 敏捷开发
开发微服务非常方便，开发者可以一键自动生成一个服务的“skeleton”代码，直接开始写业务，而不必要担心任何server端的琐事，降低开发门槛。
- 安全性
不支持动态代理，内置一个安全模块，专门防御网络嗅探和中间人攻击。
- API/日志审计
内置日志模块和令牌模块（trace-token），用来审计API请求。
- 开发人员友善
整个框架使用Maven管理和发布，模块切分合理。
- 鼓励使用JSON格式
JSON的支持非常完善，其他二进制的消息格式并没有太多的涉及。
- 整合运维基础设施
由于高度结构化，编写运维脚本的成本大大降低。
坑
由于项目还处于早期开发，除了正常的软件坑之外，个人感觉总体设计上有一些地方值得商榷：
- 框架的依赖管理
由于框架帮忙做了很多事情，开发者对那些应该管理的依赖（例如logback, json）反而失去了控制权。比如我想要增加一些日志配置，就没有那么容易了，因为所有的配置和可配置项都被Airlift牢牢控制，需要修改框架源代码才能达到我的目标。
框架以外的依赖需要自己管理。实际上框架只是包含了一大部分常用Java库，对于一些第三方类库（例如大数据，云服务）的整合需要开发者自己解决和维护。这个似乎反而增加了维护成本。
- 高度结构化带来的局限性
使用 Airlift 基本上确定了整个微服务生态圈所有的微服务都必须用Java来写，很多的类库都是“钦定”好了的，整个框架高度“静态化”。如果要在微服务层面自定义一些模块（比如servlet），不修改源码是不可能的。
- 技术栈统一
Airlift 完美支持的技术栈主要是 Java/Http/Json， 所以无论是性能还是可扩展性都是中规中矩，如果追求高性能、高并发应用，那么基本可以不考虑Airlift。
更多内容。。。
