第一个思考

背景：现有系统的是十年前的老系统，看到里面的代码，可以说就是一坨，然而作为一个全公司的接口门户，支持几十个外接系统的调用，对公司内部系统的起到保护作用，作为十年前的思想设计而成的系统，在十年间不断的缝缝补补夹杂着各路码雄之神的手，留下了数之不尽的足迹，但英雄多了代码的整洁度可想而知，冗杂了每个人的思想，不过性能方面还是可以的1小时多出来20W的吞吐还是单机支撑，不过在使用高峰时UI界面几乎瘫痪，不能使用只有后台功能正常运行，还有的时候莫名瘫痪。

现有架构activemq,jdbc,servlet,jsp这一套最接近原始的结束，没有化过妆素面朝天，效率上应该是很高，但是代码维护上比较累。其中，与数据库交换次数较为频繁，以数据库作为开关，这点资源浪费较大耗时较长，队列路由配置较为繁琐，错误信息提示的不够友好，参数较多，导致次对接新系统投入的维护量较大。经过一段的时间的熟悉和了解，基本知道了此系统的担任的角色及涉及的业务，决定将现有系统进行重构，现有的问题是，在不影响已有的系统之间关系及系统升级后不涉及关联系统的改动情况下使目标系统完成升级不调高性能。

思考加构activemq,springmvc,spring,mybatis,redis间核心服务与用户服务拆分，减少核心服务运行时用户服务对核心服务的资源占用，activemq作为一个开源的消息中间件很好的支持了jms等协议，提供了队列模式及订阅模式，对于一个系统对接多个远程服务来说很是有用，由于服务端基于的协议不同也就代表着同时处理不同队列请的不同服务可以在同一时间点获取不同队列的消息服务，我们的服务端有基于http协议和webservice协议的，而mq可以在高并发的请求时起到缓冲作用，降低了服务端的压力还保证了数据的安全性，redis作为一个缓存数据库在本系统中主要担任的角色也是缓存数据作用，减少程序于数据库之间的交换，降低资源开销，加快查询效率，更快的处理请求。

服务拆分，主线对不同的客户端请求达到转发并实时返回，基于这个主线展开1、系统维护人员进行日程的CRUD工作，2、接口调用前的数据初始化以及对目标服务的访问权限的控制，暂时拆分为三个服务。

缓存的处理，由于本系统涉及的数据基本上不会变动，这就为缓存调用打下了坚实的，不过还是动态的添加数据是少不了的，如何解决这种新增的数据及时的添加到缓冲中那，由于我们的数据初始化时在服务器启动时就已经初始完成，动态添加我们想了两种路线的方式，一、在UI端完成数据添加后写进缓存。二、客户段调用时如果缓存中没有目标数据的存在则直接查询数据库并将返回结果添加到缓存中，这里可能会有同学疑问如果同时有多个请求获取次数据，但次数据不存在，就会造成频繁对缓存的更新，我们这里在缓存前依然会进行一次回去如果不存在才会更新。至于服务额各个服务间的调用我们采用的是dubbo方式进行服务间的通讯。