從上圖可以看出幾個優點
成本降低
穩定性提升
使用者體驗體驗提升
性能優化的缺點也有
維護成本增加：代碼可能變複雜，結構可能變複雜，技術棧可能變複雜
性能優化的兩種模式
個人總結，性能優化整體上可以分為兩類：單應用優化和結構型優化。
單應用優化，關注單系統瓶頸，通過解決單系統瓶頸提升性能。
結構型優化，通過改造鍊路結構和配比，進行整體性能的優化。
單應用優化常見步驟
優化基本思路（閉環）
确定性能瓶頸/熱點
确定優化方案
實施、回報優化情況
确定性能瓶頸/熱點的常見方法
性能壓測：通過工具/人肉等方式量化運作時性能情況
業務/代碼梳理：通過代碼走讀，發現資源消耗熱點（牛b的人可以這麼幹）；通過統計代碼對資源的操作，量化代碼對資源的消耗（比如一個業務操作會進行多少次資料庫調用，會進行多少次服務運算等方式）
壓測時常觀察的内容及工具（舉例java應用）
壓測工具：jmeter
記憶體的使用情況：mat，gc日志，vmstat
io情況：iostat
網絡情況：netstat
熱點代碼：jprofile，btrace，jstack，jstat
cpu情況：top
優化的常見手段或模式
靜态化：動态資料和靜态資料分離。
異步化：使用異步化減少主流程中的非關鍵業務邏輯。
并行化：使用多線程并發處理，縮短響應時間。
記憶體優化：減少對象大小，減少對象創造，資料模型優化
去重複運算：業務邏輯優化，或者使用緩存
減少資料庫操作：資料備援，資料緩存等
縮短資料庫事務：短事務，異步化，最終一緻性等方式可以考慮
精簡代碼邏輯：去除備援代碼，諸如過度設計檢查等代碼。
精簡日志操作：日志大小要關注，注意io上的瓶頸；日志太多，說明生成的string也會多，也增加了gc負擔
等等
結構型優化常見步驟
此部分介紹的内容，在很多網站架構變遷的文章中介紹過，這裡通過圖的方式展現出來。
每個階段都有适用的軟體架構，基于成本、建設複雜度、維護成本的考慮，不必強求一開始建設很完整的技術體系。
個人認為，性能是驅動應用體系研究的重要驅動力，可以通過下面應用結構演進看出來。
1、單應用時代常見瓶頸先發生在db
2、單應用時代常見第一個解法是使用緩存（偏向應用級别緩存）
3、單應用時代常見第一個解法是獨立緩存服務（集中式緩存，如memcache）
4、單應用集中式部署部署後的db瓶頸
5、單應用集中式部署部署後的db瓶頸解法（資料庫拆分、讀寫分離）
6、服務化拆分應對更大範圍請求量
服務化叢集部署模式
6、服務化拆分應對更大範圍請求量兩個結構優化的案例
處理單點/網絡瓶頸的可行方式
處理資料庫連接配接池瓶頸的可行手段
總結：性能/應用優化的幾個趨勢
關于作者
陳顯銘，從事研發工作七年，螞蟻金服技術專家，愛思考
<b> </b><b> 中生代技術分享群微信公衆号</b>