Jerry Server - 正式版1.0.0 文档
之前发过一篇文章，当时的想法现在看来真的不是很明确，得到了很多批评。不过，批评有利有弊，由此我又仔细思考了很多，最终明确了自己究竟要做什么。特厚着脸皮发出正式版文档！
下面废话较多，大家直接看第3条思想即可理解。
1、缘由
以Java web举例，现在的网站系统开发模式，对于web端和服务端的数据交互以及页面渲染，无外乎两种：
- 第一种是交给后端处理，Jsp，Freemark模板引擎之流，这种开发模式需要前端人员做好静态页面交给后端去处理一些其它工作。这种开发模式到如今也依旧流行，这也是招聘Java web程序员要求也要会HTML、JS、CSS的原因。到现在基本上都是采用这种开发模式，注意这种模式并非真正的前后端分离！
- 另一种是交给前端处理，前端全部完成web端的页面渲染工作。要知道的是，前端处理只能使用JS，一些前端JS模板引擎也有不少，Vue等，无论再花哨，本质依旧是JS。不可忽视的是，完全依赖JS处理前端页面是存在弊端的，比如SEO问题。
- 总的来说，两种方式有利有弊。如果你在实际开发中涉及到我上面说的第一种，需要后端再对前端页面进行处理，那么可以使用 Jerry 来解决这部分的分工，实现完全前后端分离。
2、定义
Jerry是帮助前后端完全分离的工具，它可以帮助后端工程师只做后端，前端工程师只做前端。
3、思想
简单来说，以往的模式是请求后端接口，后端进行处理后返回一个页面给浏览器。前后端并没有进行彻底分离，比如还在使用后端模板引擎（FreeMark，Thymeleaf）或JSP。为什么Web开发不能像Android等移动端开发一样真正前后端分离呢？
上述开发模式是后端提供接口（也就是网址），经过处理得到一些数据，然后经过模板引擎的一系列渲染，填充数据，再把完成的HTML页面返回给浏览器。流程图如下：
Jerry 的思想就是把这部分的流程进行拆分。流程图如下：
也许你会说，Cookie 怎么办？会话如何保持？我想说，Jerry 服务器会相当认真的执行代理的角色。把客户端的HTTP请求的方法、Cookie、参数原封不动的发送给服务端。服务端发送回来的响应也会把Set-Cookie响应给客户端。（笔者想到的就是Cookie比较常用，若思考欠缺，欢迎指正。）理论上说，Jerry的方案是可行的。
4、模式
-
一种完全真正的前后端分离，Jerry采用如今最流行的JSON作为前后端数据交互的接口。
对后端工程师来说，只需要关心接口的实现，不需要再接触前端页面，甚至不要求懂HTML，JS等。
-
只做接口有什么优势？一套接口适用web、Android、ios各个平台，这对软件项目的可扩展性大大提升。不可否认的是，现在依旧有些网站采用后端直接返回html片段的开发模式，这对软件的扩展性非常不利。
-
对前端工程师来说，任务脉络更为清晰而简洁。不像以前只需要做好页面，更需要使用FreeMark等处理动态交互。这在之前是由后端工程师来做的。可以说是完全颠覆以往。把网站开发做成像安卓开发一样的前后端分明。
-
如果你已经有了成熟的前后端分离方案，自然不需要Jerry，如果你们的后端工程师还需要再去写FreeMark，Thymeleaf等，则可以考虑使用Jerry达到更彻底的前后端分离。
5、场景
你既可以把Jerry部署在实际项目中使用，当做一个前端服务器。
如果你真的不想在线上部署Jerry，那你可以在开发过程中，交由前端开发人员去使用Jerry。
把原来的前端只做静态页面然后交由后端去渲染的工作改为全部让前端去做，然后在上线时再把写过FreeMark语法的HTML文件放到后端项目中。
5、优势
-
启动快！
响应快，配置后台监控，响应时间一览无遗。
优先读取各种文件的缓存，使用EhCache实现。
对于后端接口，使用加权负载均衡。
对于日志监控等耗时而且响应无关的操作，全部运行在其它线程。
如果你还有其它加快速度的方法，欢迎留言。
-
轻量级！没有过多依赖，大部分功能能自己实现就自己写。全部依赖如下：
- Netty
- slf4j + logback
- fastjson
- ehcache
- junit4
- freemark
-
自带监控系统。对页面的响应速度以及HTTP信息一览无遗。
6、引擎
Jerry 使用 FreeMark 作为模板引擎。也就是说，原来需要后端工程师使用freemark去渲染页面，现在变为前端工程师去使用。
例如，服务端接口：
{ "message": "响应成功", "state": { "message": "ok", }, "data": [{ "time": "2018-04-25 13:25:07"
