Tephra之愿景

随着移动端的风靡，早先那种基于HTML/XML数据传输的系统架构已经无法满足开发需求了，因此重新做了底层框架，并名之曰Tephra。Tephra默认采用JSON作为数据格式，可以在各个终端中快乐地工作着。

Tephra拥有以下几个功能包：

• core——核心组件包；
• dao——持久化组件包；
• ctrl——控制组件包；
• ctrl-http——基于HTTP的控制组件包；
• script——JavaScript组件包；
• web——WEB配置包；
• workbench——工作台组件包；
• workbench-web——工作台UI组件包。

core

core主要提供了Bean的管理，使用Spring的IoC容器，并且严格遵循面向接口编程之思想。Bean的定义全部采用注解（Annotation）方式，有利于组件化开发。

在Bean的载入（Load）上，Tephra封装了一个动态载入器（DynamicClassLoader），允许在运行期间动态更新小部分的类。这并不是热部署，只是类的运行期载入而已。这个功能主要是应对一些突发、紧急的BUG修正需求，不能作为热部署、热更新使用。真正的热部署或热更新还是静候JDK9之佳音吧！

接下来是NIO的封装。虽然JDK的NIO已经封装得不错了，不过还是有些问题，比如一直没有得到完美解决的CPU100%问题。其实Tephra一开始也是直接对JDK的NIO进行封装适配的，不过在一些技术问题上一直得不到完美解决，后来改为采用Netty作为NIO的基础库了。

开发人员只需实现相应的Listener接口，便可实现监听、交互等操作。数据的读写通过一个NioHelper提供支持，开发时无需涉及底层IO操作。

缓存没有使用现成的开源组件，主要是为了得到一个最快速响应的缓存。Tephra使用全冗余的方式，在各个节点中均缓存相同的数据，然后每个节点在获取缓存数据时仅从本地内存中获取。其优势在于可以最快速获得缓存数据，缺点在于所有节点缓存的最大容量取决于最小内存节点。

定时任务方面，Tephra实现了每天、小时、分钟、秒四个默认定时器，并提供了四个相应的定时任务接口，开发人员只需实现相应的接口即可。所有定时任务在执行时均为同一实例串行、不同实例并行的模式，最大限度提升定时任务的执行周期。

日志管理器仍旧使用log4j，当然现在习惯性会加上slf4j规范。日志管理器在输出日志时无需提供当前调用类信息，由日志管理器自动获取，简化日志输出。同时，日志输出时根据不同的日志级别输出到不同的日志文件中（这个功能目前log4j2已实现，之前的框架是自己实现的）。

还有一些工具类，比如验证、转换、加解密、序列化、HTTP请求等。

dao

dao主要提供持久化封装。首先是读写分离，由框架底层自动进行读写分离处理，并且如果有多个读库将自动进行负载均衡。并且这一处理对开发人员是完全透明的，启动时根据不同的配置参数来决定是否进行读写分离。因此可以在开发时不进行读写分离，运营时才进行；甚至可以是一开始运营时可能并发量并不大而不需要读写分离，在并发接近限定值时通过读写分离、对读进行负载均衡来快速增加处理能力。

分库也是dao的一个亮点。很多框架在设计时都只支持一个库，或者根本就没有限定库，由开发人员自行添加。Tephra允许配置多个库，在开发时只需指定配置名称即可。多库同时也支持读写分离和读负载均衡。

dao组件包有提供SQL操作工具，可以直接操作SQL。这个主要用于满足一些需要复杂检索、或不使用ORM以提高处理效率的场景。

ORM方面仍旧封装了Hibernate，也支持读写分离和多库访问。提供Hibernate封装主要是适应一些后台管理项目，或者一些对性能要求不是很苛刻的项目。当然，现在Hibernate的性能其实也不差的，甚至如果开发人员如果SQL能力不够的话，使用SQL不见得会比使用Hibernate高效。

dao包同时还提供了一个轻量级的ORM工具，是自己实现的，不过参考了Hibernate，或者说遵守JPA部分规范，也使用标准的JPA注解进行配置。这个ORM只提供基于字段的映射，并不提供级联映射，因此其性能损耗会低于Hibernate。这个轻量ORM的性能可能会比MyBatis还高，因为功能更简单。至于没使用MyBatis的原因，在于MyBatis的SQL都是配置的，导致代码的可读性降低，并且这种配置模式导致底层无法自动进行读写分离和分库访问。

数据库读写分离是应对高并发的一个必不可少的能力，很多项目在业务层做了大量的负载均衡以提高并发能力，但最终被数据库瓶颈卡住了。因此数据库并发能力的解决方案在一定程度上也决定了底层开发框架的适用范围，甚至于成败！

ctrl

ctrl主要实现了MVC访问，其设计思路参考了Struts2和SpringMVC，但为什么不使用这两个现成的呢？因为BUG！这两个现成的MVC框架都存在严重的安全隐患，特别是Struts2，所以只能放弃自己实现。

不过在实现过程中，引入了新的目标，就是配置更简洁、执行更高效、扩展更方便！当然，功能会比Struts2和SpringMVC弱，但已能满足大部分开发需求。

ctrl默认使用JSON格式数据传输，但也支持FreeMarker模板引擎输出。当然，可以扩展任意的数据格式，只需实现Template接口即可。

自动数据传输加解密也是支持的，并且无需配置，只需实现Coder接口，完成加解密算法，ctrl会自动对数据传输进行加解密。

URI映射支持正则表达式，但会优先使用完整映射的URI。这个功能使得可以对同一类操作进行统一处理，然后对特殊需求进行定制；同时还可以处理类似于静态化的需求。

ctrl-http

ctrl-http是HTTP协议的一个实现，其目的是将接收到的HTTP请求推送给ctrl组件处理，并返回处理结果。之所以把这个组件独立出来，是考虑到后续可能会需要支持Socket访问，或者WebSocket访问。当然，也可以支持两种方式同时存在。

script

script组件包提供JavaScript脚本执行支持，支持在服务端发布js脚本作为服务。由于脚本可以支持热载入，因此可以支持一些活动类的需求。

script组件包提供了直接访问Java代码的能力，即可以通过js脚本直接调用服务端Java方法，使得使用js脚本提供的服务也能具有Java代码所具有的能力。

web

web组件包主要包含相关的配置文件，以及Servlet入口设置。

workbench

workbench的目标是开发一系列通用功能，比如UI、自动增删改查、权限控制等。此组件的目的是减少后台型项目的开发工作量。

workbench-web

workbench的UI实现，其目标是构建一个标准的UI组件库，及统一的门户界面。此组件包可以根据服务端返回的数据渲染出指定的界面，使得基于此组件包的项目可以只开发服务端业务功能、逻辑，而无需关心UI开发。

当然，此组件是基于PC端的UI组件，后续将会增加基于移动端的UI组件。

总结

Tephra的目标是为大并发提供简洁的解决方案，高效开发、快速运行、轻松集群，此Tephra之愿景！