整理近期工做的一些收穫，作備忘

一、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網關、分佈式數據庫場景、分表場景、熱更新場景、代碼批量發佈場景（借用網關鏈接同步實現代碼的遠程批量發佈或者逐步發佈實現服務不中斷熱更新）等。

其它的想到再寫吧。