整理近期工做的一些收获，作备忘

一、Redis的简单应用及搭建，未作深刻学习，简单，目前的状况大概当作跨服务器Session使用，因为项目的缘由，未能在项目在大规模应用，涉及到旧项目改造的成本和代码过高。

二、MQTT，基于MQTT的消息订阅和发布机制，是颇有意思的一个思路，也在项目中实践应用；

三、Nginx，有个需求，须要同一台服务器的webSocket和https使用同一个端口，使用HaProxy死活作不了，使用TCP四层协议的时候，没法向后端透传客户的真实IP地址，使用HTTPS没法自动识别，后来使用NGINX的HTTPS机制，完美实现。

四、从新改造的预发布文件系统监控、SQL脚本批量多服务器执行、负载均衡多服务器代码一键发布；在这半年的时间里，反复验证，已经基本完美，完好陷、无BUG，保持长时间稳定运行；

五、更进一步认识LINQ、EF框架；有更深入的了解；

六、对SQL、存储过程写法，应用得比过去更多，场景更变态，更复杂，对自已也算是对不足的一个补充；

七、见识了不一样人所写的代码、对系统的设计思路，有优有劣；

八、最近半年，因为现网系统的架构缘由，主要基于存储过程编写，同时有很复杂庞大的业务系统，半年时间大约对系统了解也就在50%左右；可是这半年时，常常面对已经通过无数次优化的存储过程、查询和代码，总结了一些优化心得，略作描述，备忘

　　　　A：SQL SERVER的跟踪管理器，用于查找reads读的次数超多（一般是未走索引，经过消息里的表扫描能够看出来）、或者du执行时间超过X秒的存储过程，找出来使用SQL查询分析器作分析，寻找和补充索引。

　　　　B：新增索引优先考虑对现有索引的优化，考虑能与现有索引兼容的状况；

　　　　C：多列索引的场景下，索引先后顺序决定查询条件是否走某个索引，索引列的升序降序，虽然不能体现减小reads或者扫描次数，但确确实实有时候能很是明显的提高查询速度；

　　　　D：把不合理的查询方法改正，例如存储过程里相同、消耗时间的结果，屡次重复查询；减小为1次；

　　　　E：代码里不合理的循环的使用，以某个案例，查询1号到30号的数据，在循环内30次调用存储过程；执行接近60秒；改为直接查询范围1-30号，一次查询拿到所有目标结果，而后在程序代码里再对数据进行加工，分组，耗时降为5秒。

　　　　F：SQL里之前不多用到的：Select * Into #temp from ...；update table_1 set x=1 output Insert.ID Into #Temp;等；接下来会继续学习；

　　　　G：之前项目里极少、不多用到多表联合查询的场景，和业务、表的设计有关系，现有系统基本上全是这种结构；确实联合查询减小查询次数，能有效明显下降查询耗时，只是业务设计太复杂了，基本架构也设计得不行；库分太多，经常涉及跨库，作跨库事务是个麻烦事。

九、开始学习使用redmine管理项目进度；但愿让工做能更科学；面对不一样的挑战，以及空降这个事情，外加现有系统和业务的复杂，但愿能逐步理清，也能借用这个场景历练自已。面对不一样的困境，不断思考解决困难的方法，多实践，多反思。

十、小票控制、绘制、打印、本地打印机云化。

其它的后续再补充；

 

整理一点平时的想法，和但愿有机会实践的东西：

一、但愿自已作一套分布式网关，同时自带API文档、入参校验、签名校验，支持服务间调用、应用化调用、外部业务调用；支持对分布式后端服务代码、程序作自动负载热更新；优先考虑在.NET Core的基础之下进行开发网关系统；

二、整理和再学习微服务架构；

三、用好redis、用活MQTT；或者自已开发一套基于webSocket的发布、订阅系统；多数场景下，可使用webSocket来替代TCP；

四、思考对现有系统的复杂框架，在许可的条件下，逐步改形成无限扩展的分布式系统的各类方案，相信也许会有机会，或者有合适的启发，能向这个方向去发展；主要是代码量，存储过程的数量，表的数量，以及过去表设计不合理，业务复杂化，但历史遗留问题，虽然很难解决，仍是须要不断的想办法。

五、分布式系统，自带API文档框架、API开发框架、API网关、分布式数据库场景、分表场景、热更新场景、代码批量发布场景（借用网关链接同步实现代码的远程批量发布或者逐步发布实现服务不中断热更新）等。

其它的想到再写吧。