系統架構優化的幾點建議！

背景

一家新公司，剛開始的因爲業務功能單一，每每是單臺服務器，單個 web server 就提供了全部功能。使用的用戶也比較少，因此爲了能夠快速開發迭代上線，數據也全是放入數據中，如 mysql、mongo 中。當業務增多，用戶增多時，這樣的系統架構就不能知足需求了。這時候就須要作系統拆分和性能優化了。

系統拆分

通常拆分系統都是按功能模塊拆分，好比在一個簡單的電商項目，通常購物流程是瀏覽商品->下單->付款->發貨->評價這麼幾個步驟。在最初的系統裏，咱們爲了快速的開發上線，可能全部的功能全放一個項目中實現。當商品或用戶數量增多時，這樣的系統架構是知足不了需求的，可能致使用戶訪問速度變慢，影響用戶體驗，直接致使用戶流失。

那這時候該怎麼辦吶？就像公司剛開始時，一個程序員既幹前端的活又幹後端的活，還有作測試和運維。當業務在高速發展時，他一我的一天就算上 24 小時都是幹不完的。那怎麼辦？招人唄。在招個前端，測試，運維，本身專心作後端的工做。

這個模式就能夠搬到咱們的系統中來，由之前的一個系統，拆分爲多個，那怎麼拆纔是合適的？

這裏我按功能來簡單的拆分，分爲用戶系統、商品系統、訂單系統、支付系統、物流系統和評價系統。用戶系統用來提供登陸和鑑權相關服務，商品系統用來提供商品相關服務，訂單系統用來提供訂單相關服務，支付系統用來管理支付相關服務等等。

這樣一來，由之前的單臺服務升級爲多臺服務，每臺服務提供本身的服務，分擔服務器壓力從而提高系統響應。

當服務在遇到，服務拆分後還須要橫向擴展，就是把拆分後的服務部署多臺，就比如一個部門招多我的同樣。它的好處是提高系統的可用性和分擔服務壓力，更好的爲用戶提供服務。

系統優化

上面咱們聊到了系統拆分，實際上系統優化是和它並行的，或者說能夠在系統拆分以前的。這裏主要的優化是代碼邏輯、慢SQL優化、部分邏輯同步轉異步等等優化。

代碼邏輯優化，好比刪除一些不須要的代碼，減小之前的多層嵌套循環，把循環的單個插入改成批量插入。主要是提高代碼執行的效率，有多是空間換時間，有多是算法的優化等等。

慢SQL優化，系統剛開始因爲數據量小，用戶量也少，SQL查詢感受不到慢。當數據量和用戶上去後，就會明顯感受到查詢變慢。一般 SQL 優化就是給常常須要查詢的字段加索引，若是能夠加聯合索引的優先加聯合索引。索引也不是越多越好，須要額外的空間存儲索引，而且會影響插入刪除等性能。

同步轉異步，就是通知類的消息或者短信發送什麼的，不是須要強同步的，最好用消息隊列異步的方式實現，這樣能夠提高系統的響應。

緩存

對系統優化，一個很重要的手段，就是加緩存。咱們都知道內存的讀取速度比硬盤快不少，經過空間換時間，來提高系統響應速度。在分佈式系統中，通常使用分佈式緩存，如 redis 等緩存，在使用中要主要數據一致性問題，特別是修改和刪除數據時，要注意更新緩存。

除了用 redis 來緩存外，咱們還可使用本地內存來緩存一些基本不變的參數、配置等等。或者緩存訪問頻率很高的數據，不過要注意數據更新問題。

加了緩存，提高了系統的響應，相應的也給開發帶來了複雜性，特別是數據的一致性，不過，爲了系統的性能，這些複雜性也是必要的。

最後

我的以爲，最好在系統剛開始設計的時候就多想下，按大的功能模塊拆開，服務之間內部調用。這樣的好處是當用戶增加很快的時候，基本能夠快速擴容，不用急着去重構，而且服務之間解耦和邏輯清晰。

提高系統的性能主要是拆分、代碼優化和加緩存等，它們也能夠一塊兒進行，也能夠分開進行，可根據實際狀況而定。固然，若是項目週期容許的狀況下，在開始開發的時候就考慮到這些，到用戶真正上來時也不慌，直接加機器就能夠抵禦。

PS:
清山綠水始於塵，博學多識貴於勤。
微信公衆號：「清塵閒聊」。
歡迎一塊兒談天說地，聊代碼。