前言
昨晚救火到两三点，早上七点多醒来，朦胧中醒来发现电脑还开着，赶紧爬起来看昨晚执行的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/'"/>
url/'" onmouseover=alert() d='"
url/matrix_callback.php
url/index.php?option=com_fields&view=fields&layout=modal&list[fullordering]=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。
增加了一个应用几点，现在是一主两从
应该能撑一段时间了
接下来需要着手上读写分离， 针对比较大的表进行拆分，代码和数据库继续优化。尽量做到最优。
再下来着手上分布式 因为架构的演变是根据市场营销情况而定，不能走太前更不能走到市场的后面
周末比较累 写的比较简短，有时间再续