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管理项目进度；希望让工作能更科学；面对不同的挑战，以及空降这个事情，外加现有系统和业务的复杂，希望能逐步理清，也能借用这个场景历练自已。面对不同的困境，不断思考解决困难的方法，多实践，多反思。
其它的后续再补充；
整理一点平时的想法，和希望有机会实践的东西：
1、希望自已做一套分布式网关，同时自带API文档、入参校验、签名校验，支持服务间调用、应用化调用、外部业务调用；支持对分布式后端服务代码、程序做自动负载热更新；优先考虑在.NET Core的基础之下进行开发网关系统；
2、整理和再学习微服务架构；
3、用好redis、用活MQTT；或者自已开发一套基于webSocket的发布、订阅系统；多数场景下，可以使用webSocket来替代TCP；
4、思考对现有系统的复杂框架，在许可的条件下，逐步改造成无限扩展的分布式系统的各种方案，相信也许会有机会，或者有合适的启发，能向这个方向去发展；主要是代码量，存储过程的数量，表的数量，以及过去表设计不合理，业务复杂化，但历史遗留问题，虽然很难解决，还是需要不断的想办法。
其它的想到再写吧。