ST项目经验总结2

1.微服务划分原则

　　网上对着一块的总结有很多，但是不同业务来说其实差别还是很大的，就我们这次实践来看，大概总结了如下几点：

　　1）业务联系紧密的模块最好不要划分成多个模块，更不要分库---这里业务联系紧密会使得数据联系紧密，且需要频繁进行数据关联的维护，这会使得数据维护效率变低（每次维护都要接口调用）。

　　2）业务逻辑独立，或者可以为其它模块提供通用功能的模块可以考虑独立成一个服务。

　　3）对数据库或者服务器有着特别性能或者功能要求的模块可以考虑独立一个服务。（文件服务器）

2.websocket+nginx的使用--实现实时进度条的更新功能

　　1）nginx对于的文件上传，请求响应都有默认的大小设置，实际开发中一般都要进行相应的调整。

　　2）nginx实现websocket通信的原理是通过配置将http连接升级成websocket连接，具体配置示例如下。

server {
      listen   80;
      server_name 域名;
      location / {
        proxy_pass   http://127.0.0.1:8080/; // 代理转发地址
 　　　　proxy_http_version 1.1;
        proxy_read_timeout   3600s; // 超时设置
        // 启用支持websocket连接
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
      }
     
} 

　3）定时任务解析文件

　　关于之后做的一个资源中心功能包括对文件的解析工作，而这个解析工作要做很多事情，比如生成pdf，首页缩略图，要素分析等。技术经理给的策略是通过定时器去解析库里面还未解析的文件。这里文件的来源分为两个部分，一是平台推送，二是用户上传。

　　这里说下定时任务的优劣吧：好处就是，对于库中的文件实现了统一的处理；坏处就是用户对于上传的文件无法实时的看到解析结果，包括文件统计相关的数据（只统计成功解析的文件）。

　　这里还引发了一个问题，对于定时任务，如果前一个定时任务没有完成，而又触发了下一次定时任务会怎么样: 这里网上查到的结果是，定时任务会完成前一次的任务才开始之后的任务。

　4）数据来源的记录

　　这个还是由导入功能引发的思考，就是对于一张表，比如文件信息表，有平台推送的文件，也有用户上传的文件，但是对于用户来说文件的呈现往往是一致的（不区分来源），但是这里还是建议从需求扩展的角度考虑，把每种数据的来源在插入时记录下来，以免历史数据无法满足后续的个性化需求。