一、背景
来公司四五个月了，一直接手会员的相关项目，其实我们知道，会员属于公共模块，由于公司项目都很老了，大部分都是ejb,但是ejb现在已经不可维护，之前的代码做了各种封装，着实沉重，基本属于没办法修改的状态，所以几年前就开始慢慢去ejb,但是由于控制不好，造成了版本众多，五花八门，接口开了那些，给谁开的，那些在用，那些没用，都不知道。因此近期按照计划重构项目；
二、为什么重构
(1)、Api接口重构
可读性还算可以，但是估计是谁为了装技术，自己写的一个框架，分了三层，服务引擎，云引擎，数据引擎，其中在服务引擎中，有一个过滤器，当作所有接口请求的入口，然后方法名就是接口名，通过过滤器，调用反射找到服务引擎中的方法，在服务引擎中再通过socket通讯调用数据引擎，所以云引擎就是一个公共的封装，公共的数据加载，socket通讯等。但是想法是好的，但是socket通讯不稳定，支持的量也不够大，造成结口请求异常缓慢，甚至有时候还连接异常，在测试环境中经过自动化一跑，第二天早上来就必须要重启服务器，并且由于一层调用一层，造成本不是很复杂的业务经过了云引擎就变的更加复杂，并不是像我们现在的模块化，服务引擎调用后，你想找数据层，还必须进行搜索，因为这是两个独立的项目，所以找bug都很麻烦。但是由于维护性差，稳定性差，需要进行重构。
(2)、后台管理系统
后台系统可以说是没办法进行维护操作，其重构是势在必行，后台管理系统的面向用户就是公司内部管理人员，运营人员，销售人员等相关人员使用或者查看。销售人员查看肯定是跟后期数据分析联合使用，通过分析用户行为数据，进行业务推广，活动推广等。所以，新的系统重做是必然。
三、重构的出发点
重构的出发点我们需要明确，如果重构的结果是跟之前的系统一样，那么我们有重构的必要吗？所以我们首先明确重构的出发点就是要做一套可以支撑现在的业务，并且能保证未来具有拓展性的系统，再说明白点，就是做一套可持续性可维护性更新迭代的系统，支撑公司后期业务发展的需要。
所以对于会员后台系统的更新迭代有以下几点确定：
1.基础能力化：满足基本的功能。
2.数据化：展现数据变化，应用分析。
3.智能化：多维度数据加工。
对于会员api接口也有几点确定：
1.接口的可开放：对外开放接口，open开发平台。
2.接口的可对内：接口可以衔接各个业务并支撑公司所有业务线。
所以整套会员系统需要具有安全性，操作性，便捷性，兼容性，拓展性。
系统我们必须先做加法，在做减法，必须解决痛点。对于后期数据的分析，我们需要多维度数据加工，类似QQ，对于人的分析，好像就有1800个维度，其实我想象不到那么多。所以结构化数据深度分析很重要，这对于我们拿到数据，做营销很有必要,智能分析，精确营销。
四、重构影响因素
重构说起来很容易，但是有一点需要考虑就很头疼，兼容性！！！
也就是说对于接口必须兼容之前的接口,所以在重构后的代码返回数据必须跟之前保持一致。而对于后台系统，必须包含之前的所有功能，只能多不能少。
重构涉及到的另外一个因素就是数据库，数据库表设计在很大因素上影响系统拓展性，也影响性能。并且我们数据库中有些数据比较杂乱。比如状态，有些多余的数据，所以在重构时，需要对于不确定或者错乱的状态数据进行处理。数据库表关系的梳理对于做后台业务逻辑很有必要。
五、日志的处理思考
api我们计划一次性部署四台服务器，那么四台服务器的日志分别存放在各自服务器相应地址中，如果这样每次找bug我都是要连接四台服务器，然后分别看日志。根据之前的问题在四个服务器里面的日志中进行查找。这是处理已经出现的问题的方式；这种日志查询实在是心内，我们现在的所有项目都是这样去查找日志的。所以对于日志的处理我们是否可以把所有的日志存起来，我现在能想到的，就是拦截每次请求的参数，接口，时间，ip地址，异常情况等相关信息存入数据库，然后定期清理数据。由于没有使用过所谓的日志处理系统，我现在只知道kafka比较适合做日志。所以现在先一步步走，重构完系统，然后进一步完善不足。日志还是需要思考如何处理的。
六、浩语
__
__ _ ____ __| |__ _____ ___
\ \/ \/ / | \ | \\__ \ / _ \
\ /| | / Y \/ __ \( <_> )
\/\_/ |____/|___| (____ /\____/
\/ \/
走在自己的路上，遇到要遇到的人，经历要经历的事，这才是我们需要面对的。
