记一次不太成功项目感想

         公司项目越来越多，模块没有分类，为图方便把一些功能与特殊模块都放在一个应用包中，最后的后果就是应用影响介绍数据模块，接收数据数据模块没法充分接收数据。

最后决定把接收数据模块从应用中剥离。

         大家的愿景都是好的，开始着手开发接收服务。

         需求讨论阶段发现问题来了，前端与中心服务器的接口太多，导致不能轻易的改变，中间这些接口也是几易其主，没有人对这些接口真正了解。最终是一部分接口还保留在原有应用中，接收服务器只负责一些公用数据。

         设计过程中接收通道是独立灵活的，TCP、UDP、serverlet都可以适用，根据实际情况选择不同传输通道。

         设计过程中对文件传输采用serverlet方式，对量级小频繁数据使用TCP、UDP传输。

         数据接收完成以后保存数据，约定以压缩文件的方式保存数据，再通过文件分发数据。

         

通过以上设计可以解决历史遗留问题

1.接收服务接收数据太少，主要表现是数据接收以后无法处理完成。

2.每次应用功能更新，接收服务需要停止，导致数据无法接收。

3.接收服务分离以后可以部署多台接收服务，进行负载均衡。

4.接收分离以后接收可以作为数据服务提供者对外提供数据。

如果说是一个对立的系统这些设计都是非常合理和优秀的，但是作为一个产品或者一个项目就暴露出来一些问题。

1.这些数据不只是单独的数据，同时也是原有系统的业务数据，分离以后这些数据与原有系统的关系通过什么来维系，设计中没有好好体现。

2.外部环境缺少充分考虑，原有系统一台机器一个IP可以做掉所有的事情，但是拆分以后需要需要服务器和IP，这些都没有考虑。为什么不可以同一台服务器部署接收服务和应用，这也是后期迟迟未能推广该方案的原因。

3.没有对客户的现实环境充分了解，可能是设计过程中最大的弊端。

再好的应用没法落地，最后只能算是一堆字符串。