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

1、Redis的简单应用及搭建，未做深入学习，简单，目前的情况大概当做跨服务器Session使用，由于项目的原因，未能在项目在大规模应用，涉及到旧项目改造的成本和代码太高。

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

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

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

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

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

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

8、最近半年，由于现网系统的架构原因，主要基于存储过程编写，同时有很复杂庞大的业务系统，半年时间大约对系统了解也就在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：以前项目里极少、很少用到多表联合查询的场景，和业务、表的设计有关系，现有系统基本上全是这种结构；确实联合查询减少查询次数，能有效明显降低查询耗时，只是业务设计太复杂了，基本架构也设计得不行；库分太多，常常涉及跨库，做跨库事务是个麻烦事。

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

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

其它的后续再补充；

 

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

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

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

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

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

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

其它的想到再写吧。