呵呵，運維談不上專業，只是日常需要，記錄一些問題。因爲是個人玩家，所以使用的實例配置也比較低，更容易因爲某項資源不足而觸發瓶頸，最終短板給整個系統帶來故障，甚至是災難。
1、HTTP/S請求頻繁超時？
2018~2019（今年）都碰到了這個坑，先說下現象和配置，
實例規格是ecs.n4.small ，即單核、2GB內存，帶寬1M。ECS裏主要運行了五個應用ABCDE、E開了以後，HTTP/S請求頻繁超時，導致前面4個應用也出現類似問題。
查看了下系統監控數據，CPU60上下，內存100，帶寬100，可見是帶寬觸發了上限，並且經過實驗（只跑E）發現降低E的線程數並提高sleep時間可以降內存和帶寬（這不是廢話麼）。
於是先嚐試升級帶寬（因爲應用必須保證線程數和sleep啊，不然線程數爲1，sleep(Inf)多好）。
問題改善了，於是嘗試跑E的升級版（應用需要，規模大概是線程數X2，sleep保持不變）。這個時候CPU不幹了，100！！！內存在60上下，且呈鋸齒狀，看來GC有在起作用，磁盤未見異樣，出口帶寬也夠用，TCP鏈接異常ESTABLISHED/NON_ESTABLISHED=230/3400，non裏面幾乎都是TIME_WAIT。。。說明產生了大量的主動關閉連接。
當只運行升級版E時，仍會出現頻繁超時的問題。
這裏就不追究具體的原因了，因爲有更加經濟的解決方案。
主要總結一下頻繁超時的一般可以採取的一些措施：
1、升級實例帶寬，這是最直接的，一般也有效；
2、程序優化，比如使用長連接，即keeplive，大量HTTP/S請求時，當對於同一網絡資源，可以避免頻繁建立連接；
3、應用隔離，人家阿里雲用容器給你劃了邊界，就要好好利用起來；雖然爲了整合，將帶寬都併到一起了，但有時合併CPU/內存資源卻給管理帶來了更多不確定性，一個應用導致其他應用都宕機，產生的維護成本、時間成本可能遠比多一份CPU/內存的RMB消耗還大。比如因爲E的問題，導致了ABCD幾天的運行數據都無效。
去年出現超時問題時，主要採用了帶寬升級和長連接進行了優化。而今天這個問題打算採取應用隔離。