我参与的项目

在这里简单介绍一下我参与过的项目吧。

"圣堂刺客"

元数据开发框架

元数据应用开发框架主要是一个面向企业应用的开发框架,基于spring+spring mvc+元数据引擎(orm框架)+thymeleaf搭建的一个强大的开发框架。

元数据框架的元数据引擎是品高自己开发的ORM框架,这个框架可以让开发人员完全不用定义java类就能创建进行数据库操作,通过元数据类描述数据库对象和java类的映射,最终实现的效果就是可以在不写任何代码的情况下,通过web界面操作开发出一个简单的业务系统,比如学生信息管理系统,学生成绩管理系统等等。

另外,元数据还有强大的页面编辑器,可以在web上直接通过拖拽的方式定制表单,创建自己的新表单等等。

关于元数据框架的内容不介绍太多了,这个框架功能强大,不过相应的也比较重量,部署运行相当麻烦,如果对java的开发技术栈不熟悉的人,可能需要一天才能部署完成这个开发环境,这里的开发技术栈包括spring,spring mvc,maven,tomcat/jetty,eclipse/intellij idea,mysql等等技术。

实际上我入职品高之后,参与这个框架的开发维护时间并不长,之后就被其他部门借调去参与一个项目的开发了,就是下面要介绍的真功夫OA项目

真功夫OA项目

这个项目是我毕业后第一个比较像样的项目了,用的就是元数据框架开发。前期元数据开发效率非常高,几乎绝大多数的管理功能都是通过xml配置+ui操作完成的,但是之后工作流部分的业务相当复杂,包括预算管控和财务部分,当时真的是耗尽了大量的精力。

不过最初我并没有参与这个项目的核心开发,毕竟当年刚毕业,也是个菜鸡,不过后来由于这个项目中的主要开发人员有的被公司安排去做其他事情了,有的离职了,于是我终于媳妇熬成婆,称为这个项目的主要技术支撑。

这个项目让我对元数据框架的理解突飞猛进,因为当时经常出现各种bug,再找之前的同事问过几个问题之后,我开始意识到不能通过这种方式来解决bug,问题太多,解决bug的效率太低了,然后我就开始去读框架的源码,就是这个思想上的转变,加上那段时间遇到的问题非常多,可以说每天都是加班到凌晨2点左右的,那段时间我对元数据框架的核心理解越来越深,最后这个项目里几乎没有我无法解决的问题了。

最后说说我在这个项目主要做的一些事情吧。

其实这个项目在13年底开始做的,到现在已经接近3年了,能记住的东西不多,只有两个印象非常深刻的事情:

  • 预算重算
  • 一个重要的bug

预算重算

预算重算的功能,主要是当时一开始项目中有很多bug,导致OA中的审批单据经常会出现各种金额计算错误和预算扣除错误,每隔一段时间就需要对所有的单据进行重新计算,因为牵涉的业务非常复杂,因此得完全恢复年初的预算数据然后重新模拟当年所有已经提交的单据走过的所有审批流程重新走一遍。

一开始我是通过web应用启动起来之后点击一个按钮发个请求来运行重算业务的,后来发现在web下由于很多不必要的对象创建和守护线程导致重算速度非常慢,于是又另辟蹊径通过单元测试的方式来运行重算业务,通过单元测试运行重算业务之后,性能提高了两倍多。

这个功能具体的代码和逻辑已经忘记了,只记得当时随着需要重算的单据越来越多,业务越来越复杂,重算时间越来越久,不停的优化这个算法的经历。

一个重要的bug

这个bug其实是元数据内部的一个bug,一直都没被发现是因为这个bug重现的条件非常苛刻。需要在应用刚启动的瞬间,某个对象初始化的过程有一个http请求过来,并正好请求的业务设计到这个对象的使用,这个时候才能出现。当时出现这个bug之后,我们调试了很久都束手无策,后来找元数据框架核心的几位开发人员都找不到问题,找不到问题的原因在于:这个bug根本无法重现,因为条件太苛刻了,部署上线后出现了问题,重启后就没问题了,而且无论重启多少次都没有问题,只有那些错误的数据还存在数据库中。

好吧既然大家都找不出问题,重启之后又没问题,大家都决定放弃调试了。但是错误的数据就在那里,客户抓着不放,我们也没办法啊,最后我无奈之下,只能继续调试这个问题,经过几天的调试,最后我在成G的日志文件中发现了一个关键的信息,某一个位置在很短的时间(几毫秒)连续打印了两次!

这个发现终于让我找到线索,找到打印这段日志的代码,在一个事件处理器里打印的,从日志的现象分析,应该是这个事件处理器在短时间内执行了两次,于是进一步追溯到事件处理器的初始化类中,发现事件处理器是存放在一个Map中的,我马上想到的就是并发情况下初始化了两次,但是从Map的初始化代码中发现使用的是ConcurrentHashMap,这个类不可能会出现并发问题,所以问题不在Map上,我差点又一次进入僵局。

进一步跟随代码之后才发现,其实框架是先初始化Map再初始化事件处理器的,而事件处理器是放到一个List中再作为Map的value保存起来的,所以最终的结论就是事件处理器被初始化了两次,并且两次放入List中,最终才导致同一个事件处理器执行了两次的问题。

有了猜想之后,我通过断点的方式让两个线程同时进入事件处理器初始化的代码,终于重现了最初发现的bug,剩下的就很好办了,因为这里只在应用启动的时候调用,根本不会存在性能问题,直接在事件处理器的初始化代码前加一个synchronized解决。

这个bug是到目前为止我调试过的最有成就感的bug了,其实到后边bug本身已经不是什么问题了,重点在于调试问题的思路和方法吧。

广垦OA

这个项目其实就没什么好说的了,也是元数据做的一个项目,我担任的是技术选型和架构搭建的角色,实际上经过真功夫项目的锻炼,这个对我来说小事一桩,通过maven创建工程,分独立子模块,各个模块之间处理好关系就好了,并没有遇到太多问题。

这个项目由于我要归回我原来的部门,所以并没有负责后续的开发,只做了两个模块:

  • 表单最终的PDF打印和EXCEL导出
  • 真功夫财务模块移植

广垦OA并没有遇到太多问题,所以能记住的内容似乎已经不多了

Leap framework

leap是一个开源框架,主要用来开发web应用的,其实好理解一点的说法就是和SSH框架具有类似功能的开发框架,这个框架是我现在的老大开发的,当然我也作为核心开发人员参与其中,说起来,做一个开源框架是我从学习编程以来一直都有的一个梦想,所以我在这个框架投入了极大的心血去学习和开发。关于这个框架就不再多做介绍了,可以在官网看。

品高企业网盘

品高企业网盘,这个不得不说我们公司领导层的战略眼光,15年开始开发,当时市面上各种免费个人网盘,因此企业网盘在企业内的推广其实是很受阻的,然而到了16年,各种个人网盘全线关闭,到我写这个博客的时候几乎就剩下百度网盘还在苟延残喘了。

品高企业网盘是一个很大型的企业应用,包含PC端应用,web端应用,元数据服务,全文检索服务,文件转换服务,S3云存储等模块。

实际上我只是负责web模块的开发而已,但是开发web端用的就是leap。

SSO单点登录

SSO大概是目前为止我接触最多的一个产品了,其实在我入职品高的时候,品高sso已经是一个非常成熟的产品了,我最初的工作只是在这个产品上做一些技术支撑,就是教给其他开发人员如何使用,支持他们的项目开发,偶尔也帮他们调试问题,后来在这个产品上也做了一个微信企业号的登录插件,还有一个saas化的用户登录插件而已。

我原本以为我与SSO的情缘仅止于此了,后来公司由于业务发展和战略规划,需要开发新的SSO,遵从OpenId Connect(sso+oauth2)标准的SSO,我们内部称为SSOV3,我顺理成章地成为这个产品的主要研发人员,说起来这个产品算是第一个我参与规划设计并主要开发的产品了。

品高API网关

API网关是一个非常大型的企业应用架构,也是现在非常火的微服务架构,API网关的核心功能就是服务代理,简单的说就是一个反向代理服务器,架构如下:

gw.png

我们可以看到,网关(gw)代理了所有service对外提供服务,所有的客户端请求都通过网关来获取服务,网关还负责跟认证服务器(Authentication)打交道认证用户身份和权限等,后端的服务就可以不再关注授权和认证的事情了。

当然这里只是一个非常粗浅的架构,也是网关最核心的功能,实际上整个api网关还包括服务治理,调用链跟踪,服务监控,api文档生成,sdk文档生成等功能,并且支持分布式式部署,内置负载均衡等等,这里涉及公司产品的机密,不方便多说。

在网关这个产品中,我的身份也不只是一个开发者,我主要还负责网关的管理接口开发,认证服务器(SSO)开发,以及最终的产品交付管控等工作。