2017年底总结，一套落地的框架和应用的开发之路

感谢公司和项目组的信任，17年年中开发了四年的开发框架，在项目中正式开始使用。

17年就要结束了，在社区写自己的技术总结博客，洋洋洒洒也写了快上百篇了，中间删除了一部分，不太好的，一路下来，是在做开发道路上的不同阶段的总结，也有现在看来漏洞百出的文章，但是是当时的心境和想法。做软件的都希望有一套自己得心应手的开发框架或开发工具，别人写的再好，用起来终究不如自己写的，容易掌控。

框架开发从第一天开始，就是要打造中间件自身的解耦，框架开发机缘巧合，从最底层的中间件开始了，大概在13年八九月份，第一梯队的中间件雏形诞生，分别是底层通信中间件、线程调度中间件、日志记录中间件，曾经因为工作变动原因，从一个超高速的快节奏环境，换到了一个舒缓的工作环境，有了大量的思考时间，这段时间重新把Windows核心编程、消息设计与中间件开发、Windows操作系统原理、.net 框架原理、编译原理、算法导论、TCP/IP协议卷等大部头的书籍，仔仔细细的再次化时间和精力去阅读，针对性的把自己的设计雏形理念，在书籍中去找对应的理论支撑和设计思想等。这个阶段花费大部头的时间，在解决通信的连接管理、并发管理、IO性能吞吐管理等方面，为了得到一个好的调度容器，参考Windows核心编程中的示例，把线程调度与异步IO通信的各种实现，全部尝试了一遍，找到其最佳的融合点。此阶段的中间件，投入了差不多有一年半左右的时间，去优化和调优。

有了第一阶段的中间件做支撑，第二阶段的中间件目标是RMI调用中间件和事务处理中间件，RMI调用中间件属于应用层的中间件，其负责结构化数据的序列化、反序列化、报文的封包、解包等，然后送入上一阶段的通信中间件，此阶段报文的制定和修改几易其稿，很痛苦。设计、编码、测试大概一年左右的时间。事务处理中间件，这个中间件是完全独立于具体的数据库或数据库连接，为了达到此目的，引入了操作系统级的事务环境处理。在RMI调用和事务处理层面，为了解决对调用方法堆栈的动态拦截，引入了透明代理，基于AOP的动态拦截，AOP拦截实现，一般都会耦合到调用方的实现中，这在中间件层也是不好维护的，一度上述中间件的实现，因为AOP的解耦，无法顺利做下去了，后来在CodePlex上看到了一篇微软编译器开发人员写的IL语言的动态执行处理，并且很不错的是，对方提供了一个比较丰富的IL实现的AOP拦截示例，在此基础上，进行了一些修改，主要是重构了拦截器的拦截回调点，使AOP的拦截实现了中间件的解耦剥离。曾经一直耿耿于怀的是，想实现IL层面的事件拦截和注册，后来一直没实现。

第三阶段，是解决数据库的访问，有了标准的事务中间件，为了解决不同的数据库的通用访问，引入了ORM中间件，参考了Hibernate和mybatis，有点贪心，其中在面向表的数据实体访问层，完全使用了Hibiernate的那一套，而面向查询，则使用了Hibernate加MyBatis的变体实现，发现使用效果超好，摒弃了HSQL那一套，所有的基于SQL的复杂查询，还是基于原有数据库语句，只是在每一个方法实现时，需要开发人员，针对不同的数据库，分别写对应的PLSQL语句。SQL语句是稍微多写了一点，但是兼容性和性能得到保证了。这个阶段实现比较快，关键是设计，此阶段花费时间最大的是，对连接的管理，既要高效还要稳定可靠，对事务的压力最小，最初连接是放给ORM层中间件自己管理，后期发现同一事务环境下，复杂业务处理场景时，会产生多个连接，连接的管理不可靠，多次腾挪之后，将连接的管理送入了事务中间件的调用方法栈上，ORM层只负责去申请连接，连接的创建、释放，交于事务层，后期发现很多业务场景中，面向单数据库连接，一个长连接就全部搞定了，有效的降低了事务的级别，九成九的场景，事务不会自动上升到分布式事务，其事务的锁周期和效率得到数量级的提升。。

第四阶段，像数据对象承载模型一样，去对界面建立解耦模型，让界面层也能像数据承载层，自动解耦到不同的窗体上，可能一个很复杂的界面实现，本身是由几个很简单的界面实现，界面之间的通信，完全依赖于其绑定的数据模型。为了保证开发人员快速的开发和使用，此阶段，编写了自动化的代码生成工具，可以根据表、SQL语句等生成对应的实体类，可以根据实体类等生成各种情景的十几种界面呈现，包括多个复杂实体类组合成的复杂界面，包括各种树形界面、表格界面等

第五阶段，进入应用系统开发阶段，一套应用系统的出现，首先需要对应的运行容器和权限管理，为了更契合的迎合企业应用系统的需求，按照企业组织架构，进行权限管理和设定，权限系统分三个大的权限：功能权限、界面权限、数据权限，其中 的功能权限，设定为勾选对应的功能应用，界面权限则把整个用户视图界面变成可序列化和可图形化动态配置的，用户自己动一下鼠标，就可以实现界面的效果拖动，数据权限比较复杂，与具体的业务场景有关，但是有了基于企业组织架构的权限授予，对于用户来说，就可以实时的把其操作的每笔业务的归属记录下来了。

第六阶段，业务开发阶段，上面的所有准备，都是为此处准备的，因为框架的设计和框定，业务开发人员，可自由发挥的地方已经不多了，框架是基于严格的面向对象模型构建，因此业务开发人员，也不得不按照严格的面向对象的编程模型来实现其对应的业务逻辑。有了此基础，所有的业务点，就可以用UML的建模语言，预先实现需求、分析和设计的一致性。利用流程图圈定了业务系统的流程，用类图圈定了业务系统的建表范围和数据关系，用用例图圈定了业务使用人员的范围，用序列图描述了复杂业务场景中的消息通信描述。总之，开发人员被逼入了一个软件工程的开发套路中，开发人员可以实现迭代，可以实现需求的变更升级，但是因为其约束和契约接口的规范，又不会造成系统整体性的混乱。最终可以实现，随着时间的推移和软件规模的变体，系统整体会越来越健壮，越来越稳定。

一套好的系统，除了代码的整齐划一，风格的统一之外，关键是要友好，可靠稳定，软件本身都是对现场场景的抽象和模拟，用来抽象和模拟，进一步上升，需要靠的是软件工程的辅助，像IBM rational rose中的瀑布模型，永远不过时，而结合了敏捷的迭代，会更有效率。

系统的吞吐、并发、承载量、分布、调度、均衡、响应时间等，这都是一套框架开发人员需要考虑的，否则再好的理念解耦，达不到使用标准也是不行的。这就需要框架开发的每一个阶段，都尽可能的去兼顾整体的性能和效率，为整体的性能实现考虑。

17年还有不到一小时就结束了，也用技术的总结，为自己的17年画个句号。