之前写过一篇阿里云的踩坑吐槽文：踩坑记：C#访问阿里云的API小结，阿里云的文档有待改善
近来2年开始利用AWS云服务，也记录一下跟阿里云不一样的踩坑历史吧。
1、AWS特有的CPU积分机制
这个机制没有认真的去研究，
好比CPU积分，大意就是 aws答应你超出尺度，利用额外的CPU性能，但是这个超额时长是有限制的，这个限制，就是CPU积分机制：官网规则参考。
举个例子，你的步伐特别耗CPU，但是你买的EC2的CPU达不到步伐要求，那么你的步伐在运行时，就会斲丧积分，在积分斲丧完毕后，你的步伐就会被逼迫降频利用，从而导致步伐出现卡顿或停止相应。
要留意的是，AWS不但仅有CPU积分，另有流量积分等。
之前利用阿里云，并没有这个积分的概念，不外还不确定阿里云对步伐超限时，是怎么处置惩罚的。
我被坑的履历：
新项目，在测试环境测试跑大使命（还不是压测，只是数据量大一些），常常出现MySQL卡顿，正常的主键查询SQL都会出现耗时1秒的环境，关键还会上午正常，下午故障。
由于大部分时间正常，小部分时间故障，也没怀疑到资源问题
花了一周排查各种问题，各种慢查询优化都没有办理问题，才怀疑到是资源问题，认真排查了一下监控，发现出故障前CPU是高低波动，出故障时，MySQL的CPU直接降落到一个点，然后呈近乎一条直线。
运维后面给AWS提工单，AWS复兴建议之所以正常是积分见效，积分用完就出问题了，建议升配。
如果没有积分机制，那么早就发现问题了，就是资源不足……
事实上，在后续的生产环境，也出现过类似的问题，在突发流量时，触发积分不足的问题。
办理？自然就是把积分不足的环境，也纳入监控和告警了。
2、DNS有qps限制
这个是生产环境出现的，巡查生产错误日记，发现每天的高峰期，都会出现几条DNS剖析错误日记。
找运维排查照旧没发现问题，
又是下工单找AWS协助，答复是：
K8S里的CoreDNS，有qps访问上限要求，而且是跟宿主机相关，跟pod数无关；
如果哀求量大了，必须扩容购买宿主机。
也就是说，即使你的宿主机资源富足，但是只要出现这个DNS的访问限制问题，也照旧必须购买新的宿主机才气办理。
3、逼迫升级要求
AWS的很多服务：kafka、k8s、mysql，都会定期升级，而且是逼迫升级，并且有时间期限，
到截止时间，AWS会逼迫自动升级。
关键升级的频率还很高，几乎隔1，2个月就会来一次，缘故原由就是修补各种bug或安全隐患。
但是正常环境下，生产服务根本都是摆设在内网，并且有IP白名单限制，
对外一般只开放80和443的Web端口，即使存在安全隐患，一般也不会有什么问题，
这样，升级这个事变，对我们几乎没有收益，反而可能出现服务中断。
好比在Kafka的实际升级过程中，
- 有些体系斲丧者步伐没做幂等，或幂等做的不好导致垃圾数据；
- 有些体系生产者没做ack保障，导致消息丢失；
- 另有些体系没对kafka异常做捕获，导致后续流程中断。
固然，这些都是我们体系健壮性、可用性不敷，对异常处置惩罚不完善的问题，需要安排修复。
但是在创业团队的实际工作中，一般不会给你太多时间去做SLA的质量包管工作；
所以能不升级，业务团队照旧希望不升级，稳定为主。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
