工作小结

一.业务

1）用户模块

主要用来对用户得信息进行管理；

2）行情模块

行情模块又可以分为细分为两个模块，行情服务器与行情APP接口模块

行情服务器负责对接各类数据源，进行原始数据得采集，清洗，格式化，存储等工作；

行情APP接口负责对接APP端，接收APP的请求，读取redis上的行情数据，做一些优化与个性化的处理，供APP展示；

行情服务器与行情APP接口模块就是一个分布式的系统了，他们通过redis来进行通信，一方挂掉不会导致另一方也挂掉；

3）交易模块

交易模块没有研究，采用的应该还是第三方的交易系统，只是作为一个中转做一些简单的处理。

4）活动模块

活动模块经过多个版本的迭代，形成一个可以根据活动，渠道（渠道-方案-奖励规则），用户灵活配置的模块。

其主要采用了java多线程的机制，来实现对活动用户的批量采集，奖励发放，奖励国企处理。

5）投顾/自媒体/模拟炒股

自媒体相当于一个微博和滴滴打车的结合体，自媒体模块种用户的关系是一个与微博相同的关注/被关注的关系；

同时在自媒体中有一个广场问答模块，这个广场问答的业务模式和滴滴又是一样的，即用户抛单->投顾抢单->打赏；

6）资讯/帮助中心

帮助中心的业务比较简单，就是一个资料库的管理，资讯中有一些推荐，过滤，爬虫等的业务需求在里面；

7）消息模块(站内信/邮件/短信/推送)

这个模块比较有意思，邮件和短信这个具体还不太清楚，消息推送这块有一些技术手段在里面

比方消息队列MQ的使用，调用第三方推送打点，APP读取消息（第三方）和历史消息（自有数据库），已读和未读区分；

8）WebApp(对接H5页面)

这个主要是接收H5页面发送过来的请求，然后通过dubbo服务调用其他基础模块提供的服务；

其中用到的技术就是跨域请求的处理，HttpSession和数据库Session的绑定，主要是会话保持的一些业务；

9）WebOms(运营管理平台，提供给运营人员使用，综合管理平台)

这个模块就涉及到很多的管理功能，主要是一些增删改查，数据统计功能；

其中用到的主要技术就是SpringMVC，用来进行业务管理；Shiro，用来对不同类型的工作人员设置不同的权限。还有就是一些前端的技术，js,jQ,ztree等前端页面展示技术。

10)BPM开户系统

这个系统由于开户流程需要不同的审批，涉及到多人协同，有一个工作流的东西在里面，Activity工作六框架，其他的倒是没有特别的技术点在里面。

11）犇犇智能机器人

这个系统相当于与一个中转站，真正的业务分析后台还是由第三方提供。

 

二.架构方面的亮点

1.dubbo架构搭建一个分布式的环境

系统设计为一个分布式的系统，各个模块采用dubbo框架来进行相互的通信，各个模块可以部署在不同的服务器上面，这样可以降低服务器的压力，增强系统的高并发性和稳定性与可维护性；

同时模块之间也有一些实现分布式架构的子架构，如通过redis缓存，行情服务器模块与行情APP接口也可以称为一个分布式的系统；缓存多用在一些对实时性要求较高的场景下面

消息队列（MQ）也可以理解为实现分布式的一种方式，比如行情模块需要推送个股数据给用户，只需要将推送的数据放到消息队列中，消息模块监听消息，收到消息后就调用推送接口进行消息推送，其实质是做异步处理；消息队列多用于一些对实时性要求不高但要保证可靠的场景下面

 

2.Redis缓存和pub/sub机制的使用

1）Redis缓存系统，这个在多个模块中都有用到，比如用户模块将用户信息缓存起来，可以提高查询速度，提高系统的性能；

行情模块中采用redis缓存来实现解耦以实现分布式，行情服务器和行情APP接口模块之间需要交互的数据分为两类：

实时行情数据   分时数据      

这两类数据结构都由S（行情服务器）来维护，S负责写入实时数据，然后A（行情接口模块）负责读出数据，一方写，一方读

2）Redis pub/sub机制，其实redis的pub/sub也可以算作是消息队列的一种，行情模块中用则用来对用户做股价提醒等实时性较高的场景；

由于价格变动很快，这个要求高实时性，如果由A去遍历查询所有的股票做价格对比，则很耗资源，同时会产生延迟；最好的方式就是S主动将有价格变动的股票推送给A侧，并且这个推送的实时性要求较高，所以选择redis的pub/sub方式是最佳选择；

几种消息队列的比较：

Redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。
其他的MQ和Kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是又太弱智，也并非完全可靠不会丢。

 

3.MQ消息队列

这个主要用在通知的场景，服务端给客户端发送推送消息的时候就用到了MQ，服务通知部分行情到期时，后台任务采集行情到期的用户以后，将到期通知放入MQ消息队列，消息模块读取消息队列的消息，异步调用推送接口推送给APP端。

后台行情到期处理Job-->MQ-->消息模块读取MQ推送-->APP端

行情部分的股价提醒则综合采用了两种方式，

S（行情服务器）-->redis channel(redis消息队列)-->A（行情接口）-->MQ-->消息模块读取MQ并发送-->APP端。

 

4.Activity工作流框架的使用

这个主要是应用在开户系统里面，开户过程中会有多个角色对用户的开户申请进行审批，这涉及多人协同，所以采用工作流来简化开发。

 

三.服务性能优化

其实采用分布式架构本身就是服务器性能优化的一种方式。上面提到的几个既是架构特点，也是性能优化的特点

1.redis缓存，将频繁使用的数据缓存，提高查找速度，如在用户模块中，将频繁使用的用户信息放入session（其实就是缓存），来加快对用户信息的读取（这里是指对一个系统而言）

2.异步操作，如利用消息队列MQ，将A->B转化为A-->MQ-->B，这一般应用于短时间高并发的场景，如后台给全体用户发送休市通知，将消息存入消息队列，由消息模块异步读取处理，起到削峰作用。

3.分布式，将系统设计为分布式的系统，也是一种提高系统性能的方式。

4.集群，集群是指多台服务器处理相同的业务，通过增加服务器来分担访问量，集群与分布式不是同一个概念。在统一认证中用到。

5.代码优化，多线程，非阻塞I/O，资源池化（如数据库连接池，线程池）。