有一次在與客戶交流過程中，客戶提出“我們的系統遇到了很大的瓶頸，運行極慢，我們該怎麼辦？微服務之後能否解決慢的問題？”
相信大家也遇到過類似的問題，系統往往最初剛上線的時候運行的很好，甚至三五年都很好，但是隨着時間的推移，業務與數據的增長使得我們的系統不再如初上線時那麼流暢，變得非常臃腫（不靈活，龐大，效率低下）。我們該怎麼辦？
一、“協作”，通過擴充團隊力量，實現快速響應，此方法如同螞蟻搬家，通過團隊協作實現效率提升。這也好比我們應用架構的集羣化方案，單臺扛不住，我們就多臺的意思。但這並沒有解決根本性問題。同時該方案對團隊成員的能力要求非常高，要求團隊成員能迅速融入，並快速上手。往往對於一個臃腫的大單體應用來說，團隊成員又無法快速融入，快速上手。從而形成了矛盾體，所以我們一般會進行第二種方案。
二、“分解（分而治之）”，對當一個應用已經無法通過增加團隊成員來提升效率的情況。我們勢必會進行分解，將一個大應用拆成小應用。通過業務拆分，實現應用靈活可擴展，微小易控制，DevOps敏捷提升。這也就是我們常說的微服務架構。
微服務架構能否解決慢的問題？我們先不說微服務架構，我們先來談慢的問題，應用爲什麼慢，到底是哪裏慢呢？恰恰這也是微服務的一個核心要素——聚焦核心問題。對我們不應當討論微服務的必要性，而應當討論應用爲什麼慢？
對於應用變慢的總結：
1、硬件過時
我們知道硬件更新換代的速度快的驚人（諾基亞、摩托羅拉、柯達數碼等等都是硬件廠商鮮明例證），計算機的更新換代就更不在話下。我們不得不在硬件方面加大投入來提升我們的應用性能。而且我們需要根據應用的特性來進行彈性的伸縮。例如CPU型應用、內存型應用、存儲類應用對硬件的要求是不一樣的。這也就是我們常說的分佈式架構，或者說分佈式應用，通過分佈式解決應用特性彈性伸縮問題。還有就是集羣，上面講到通過增加團隊增加人的集羣，下面這相當於通過增加機器增加服務器的集羣。
2、網絡耗時
網絡耗時這也是個極大的痛點。從2G到5G時代主要解決的也是網絡問題，通過優化網絡鏈路及網絡環境減少網絡耗時。互聯網企業一般採用專線、CDN等技術提升網絡性能。同時結合應用特性、優化應用傳輸數據，減少數據傳輸量級，從而提升網絡性能。
3、前端性能體驗
前端相比較早些年，真是質的變化，量的飛躍。以React、Vue爲主流的前端框架讓應用真正的實現了前後端的分離。通過採用這種前沿技術提升性能體驗，是我們最常用的方法。我想補充的是業務優化，前端顯示什麼，不顯示什麼，什麼時候顯示，在哪顯示，如何顯示等等都將帶來不同的性能體驗。往往這個優化空間還是蠻大的，我們需要予以關注。
4、後端應用性能
後端性能常常通過優化API接口（如入參、出參優化，邏輯優化，SQL優化等）、梳理服務依賴（避免環形和雙向依賴）、聚焦核心問題（通過聚焦主業務、降級輔業務保證核心業務性能）等來提升後端性能。
5、存儲瓶頸
存儲一般存儲在物理機或虛擬機上，當然在如今非常盛行的容器化時代，也可能是容器環境。往往第一步我們需要對存儲環境進行優化。當然這需要結合選用的存儲中間件來進行差異化調整。其次就是存儲中間件本身的優化（如數據庫參數、索引優化、語句優化；分庫分表方案；讀寫分離等），Redis高速緩存、TiDB分佈式數據庫、ES、Hadoop、FastDFS、RabbitMQ等，具體中間件具體調優（本文略）。
6、全鏈路監控缺失
我們迴歸的主題，應用慢，到底慢在哪？客戶一臉茫然，爲什麼呢？因爲他不清楚，是真不清楚，爲什麼會出現這種情況，其實就是全鏈路監控的缺少，我們常說不怕出問題，怕的是出了問題無法快速定位，快速解決。全鏈路監控實現了應用的可監控性，可測試性，讓我們不再茫然。
總結：
微服務之必要性，通過微服務架構模式我們可以將不確定的問題拆分爲足夠小，足夠清晰的應用，幫助我們梳理問題。微服務應用有助於我們更好的實現分佈式，實現根據不同業務特性彈性伸縮。同時微服務由於其微小，使得我們更容易控制，也更容易進行DevOps敏捷迭代，快速交付。同時結合微服務治理平臺可以對服務進行全鏈路監控，實現業務高可用。微服務不能直接解決慢的問題，但是微服務可以幫你一步步拆解慢的問題，最終解決應用問題。當然微服務很美好，但是微服務同樣會帶來新的問題，這裏略，所以最後總結沒有完美的架構，只有適合的架構。架構也是一個演進迭代的過程。
