技术选型

一般在做一个新玩意之前都会有技术选型的过程，但这点在做 cicada 的时候却异常简单。

因为我的需求是想提供一个高性能的 HTTP 服务，纵观整个开源界其实选择不多。

加上最近我在做 Netty 相关的开发，所以自然而然就选择了它。

同时 Netty 自带了对 HTTP 协议的编解码器，可以非常简单快速的开发一个 HTTP 服务器。我只需要把精力放在参数处理、路由等业务处理上即可。

同时 Netty 也是基于 NIO 实现，性能上也有保证。关于 Netty 相关内容可以参考这里。

下面来重点分析其中的各个过程。

路由规则

最核心的自然就是 HTTP 的处理 handle，对应的就是 HttpHandle 类。

查看源码其实很容易看出具体的步骤，注释也很明显。

这里只分析重点功能。

先来考虑下需求。

首先作为一个 HTTP 框架，自然是得让使用者能有地方来实现业务代码；就像咱们现在使用 SpringMVC 时写的 controller 一样。

其实当时考虑过三种方案：

• 像 SpringMVC 一样定义注解，只要声明了对应注解我就认为这是一个业务类。

• 用过 Struts2 的同学应该有印象，它的业务类 Action 都是配置到一个 XML 中；在里面配置接口对应的业务处理类。

• 同样的思路，只是把 XML 文件换成 properties 配置文件，在里面编写 JSON 格式的对应关系。

这时就得分析各个方案的优缺点了。

方案二和三其实就是 XML 和 json 的对比了；XML 会让维护者感到结构清晰，同时便于维护和新增。

JSON 就不太方便处理了，并且在这样的场景并不用于传输自然也发挥不出优势。

最后考虑到现在流行的 SpringBoot 都在去 XML，要是再搞一个依赖于 XML 的东西也跟不上大家的使用习惯。

于是就采用类似于 SpringMVC 这样的注解形式。

既然采用了注解，那框架怎么知道用户访问某个接口时能对应到业务类呢？

所以首先第一步自然是需要将加有注解的类全部扫描一遍，放到一个本地缓存中。

这样才能方便后续的路由定位。

路由策略

其中核心的源码在 routeAction 方法中。

首先会全局扫描使用了 @CicadaAction 的注解，然后再根据请求地址找到对应的业务类。

全局扫描代码：

首先是获取到项目中自定义的所有类，然后判断是否加有 @CicadaAction 注解。

是目标类则把他缓存到一个本地 Map 中，方便下次访问时可以不再扫描直接从缓存中获取即可（反射很耗性能）。

执行完 routeAction 后会获得真正的业务类类型。

Class<?> actionClazz = routeAction(queryStringDecoder, appConfig);

传参方式

拿到业务类的类类型之后就成功一大半了，只需要反射生成它的对象然后执行方法即可。

在执行方法之前又要涉及到一个问题，参数我该怎么传递呢？

考虑到灵活性我采用了最简答 Map 方式。

因此定义了一个通用的 Param 接口并继承了 Map 接口。