前言
昨晚救火到兩三點，早上七點多醒來，朦朧中醒來發現電腦還開着，趕緊爬起來看昨晚執行的SQL命令結果。由於昨晚升級了阿里雲的RDS，等了將近兩個小時 還在 升降級中，早上阿里雲那邊回復升級過程中出現異常，正在加緊處理。。。有點蛋疼
項目介紹
這個項目主要分為WEB、WEB-Manager、WEB-API、APP（ANDROID、IOS） 。
開發語言主要是ASP.NET
數據庫MySql
架構采用了ASP.NET +EF+ORM Unity依賴注入 采用了DDD的部分實踐
ORM使用的是AutoMapper
使用了Redis緩存
Log4net記錄文件日志，剛開始使用Mongodb記錄日志，用了一段時候后取消了。
WEB端使用了angularjs
API層通過JSON數據與APP進行交互，用戶狀態通過access_token進行傳遞
數據庫層目前是基於倉儲（Repositor）模式實現的
剛開始項目急於上線多數采用Linq +lambda 的查詢方式，在實踐過程中發現變態的業務調整和快速的請求響應，將其復雜的查詢改成了原生SQL，通過Context.DataBase.SqlQuery 執行
其他的技術就不一一介紹了
目前訪問量較大的是APP端， 最大並發 1300+
主要是API的壓力比較大，日均 100W+ 請求，API 目前 部署在Windwos server 2012上， 接口在50個以上
數據庫使用的是阿里雲的單機MySql RDS 5.6 版本，10盒12G，連接數2000，iops 6000
目前 單表最大是8000W+數據。物理文件300G，APIlog日均100W+，API與業務系統完全獨立，除了DBLog日志還有Log4g.net生成的文件日志。
目前采用的是阿里雲的負載，一主一從 購買的阿里雲負載 兩台應用均為 8盒16G ，10M帶寬 ，資源文件上了CDN。
主的上面部署了WEB端和WEB管理后台，從的上面只有API。
數據庫遇瓶頸
最近用戶量突破10+以上，最大並發1300+ 從前天晚上開始數據庫CPU居高不下，一時達到100%臨界點，導致很多SQL命令執行發生錯誤，鏈接拒絕。阿里雲的報警短信也隨之而來，隨即我停掉了IIS應用，因為不停止應用MySql數據庫很難復蘇，大概過了5分鍾之后數據庫恢復正常，然后再開啟IIS應用。蛋疼的是阿里雲的負載健康檢查也提示異常，但有點不解的是健康狀態顯示異常，請求仍然在繼續分發，很是不解。立馬我將IIS 應用程序池資源回收，停止然后再重啟，這里給個提示 重啟IIS應用程序池的時候最好先停止掉IIS應用，然后再重啟IIS應用程序池，不然訪問量大的情況下很難起起來。過了幾分鍾之后負載上的健康檢查顯示正常。
上阿里雲后來看了下各個監控指標，顯示流量從前一個小時開始 突然猛增，我以為是有攻擊，但跟蹤了幾個連接發現是正常請求，但360的防御助手顯示確實有幾個攻擊，但那幾個請求根本不足以拉跨數據庫，大概也就幾十個請求， 幾個簡單的 XSS攻擊 這里貼下：攻擊的數量不是太多，但主要攻擊的內容和參數就這個幾種類型
url/'%22/%3E%3C/script%3E%3Cscript%3Ealert()%3C/script%3E
url/'%22+onmouseover=alert()+d='%22
url/matrix_callback.php
url/index.php?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)
后來發現是數據庫遇到危機了，CPU幾度達到了100%，活躍連接數和非活躍連接數都比平時都要高很多。目前數據庫中有一張最大的表超8000W條數據，超300W以上的也有十幾張，是查詢拖垮了數據庫，平時開發的時候我們都是要求查詢類的SQL要求0.03秒之內完成。但涉及到這幾張大表的查詢我們設定到0.5秒之內返回。今天肯定是查過0.5秒了，
我查了下阿里雲控制台的慢SQL日志，眼下系統運行還稍微正常，就拿那些慢SQL 一個一個的優化，不能立馬發版，也就是不能改寫SQL代碼，只能從索引上進行優化了。就這樣把慢SQL逐一過了一遍，大約有20多個 超2秒執行的，最慢的達到了10秒，最大的解析行數達到了10W行以上，哎 應該是下面的兄弟寫sql不嚴謹，否則不會出現解析行數超10W+的，但兄弟挖的坑 我哭着也要去填。就這樣用explain 調整索引的方式逐一過了一遍，之前通過表空間已經做過一次優化了。
到昨晚又到了高並發的時候，數據庫又報警了，還好只是報警沒有給我crash掉。與客戶那邊溝通下來，決定進行數據庫擴容。現在擴容到了16盒64G 連接數14000 iops16000。
增加了一個應用幾點，現在是一主兩從
應該能撐一段時間了
接下來需要着手上讀寫分離， 針對比較大的表進行拆分，代碼和數據庫繼續優化。盡量做到最優。
再下來着手上分布式 因為架構的演變是根據市場營銷情況而定，不能走太前更不能走到市場的后面
周末比較累 寫的比較簡短，有時間再續