星球同學問了這樣一個性能分析的問題：
他們有一個地圖服務，數據都存儲在同一個sql server實例中，訪問量過高導致服務掛了，開發的解決方案是將地圖服務的內存從4G升級到8G，問題就解決了。
她的問題是開發的這種解決辦法是否是最優解，有沒有更好的解決方案。
由於我對他們的系統架構不太瞭解，也無法看到具體的日誌信息和監控，因此我的分析思路是這樣的。
我嘗試繪製了大致的服務請求調用鏈路圖，如下圖所示：
按照她的描述，現有系統架構下GIS地圖服務會被多個不同系統調用，且所有的地圖數據都是存儲在同一個數據庫中。當請求獲取地圖數據的訪問量過高時，就可能出現如下幾種場景：
- 應用直連數據庫且不作限制，會對數據庫造成較大的訪問壓力；
- 獲取地圖數據是密集計算型業務，對應用服務內存資源耗用較多；
- 可用內存不足，由於資源競爭導致請求超時、失敗，最終資源耗盡而服務宕機；
當然，他們開發同學的解決辦法是增加應用服務內存，這個問題暫時被解決了。
但從我的角度來說，增加內存是短時間內的最合適的辦法，但長期來說可能存在一些隱患，下面列舉一些性能優化的思路和方法，僅供參考。
1、應用服務升配
獲取地圖數據這種業務場景，在應用層需要做大量的邏輯計算處理，是典型的計算密集型業務，對應用服務的內存資源耗用比較大，因此對地圖應用服務提升配置(加內存)，是最簡單粗暴的方式。
2、服務水平擴容
上面提到是多個業務系統訪問同一個地圖應用，地圖應用可以看作是一個基礎公共服務，爲了避免單機服務(概率很低)掛掉的不可用風險，因此對地圖應用服務水平擴容，將多個系統的請求通過負載均衡，分散訪問壓力，也是一種辦法。
3、熔斷+本地緩存
所謂的熔斷措施，即當訪問壓力達到某個臨界點(比如內存資源使用率>70%)則將其他請求做超時失敗處理，即快速失敗，避免過多的請求造成資源競爭導致服務掛掉。
本地緩存是一種應急方案，可以將一部分使用頻率較高的地圖信息數據掛載在應用服務上，請求不再訪問數據庫，熔斷後直接返回本地數據。但這樣做對業務是有損的，會降低地圖的精度和準確性，只能作爲應急手段。
4、壓測+限流+連接池
對該業務應用和相關核心場景進行壓測，找到系統的性能瓶頸，明確安全水位指標，然後按照壓測的結果進行優化或者限流，業務可用性的前提是應用服務可用(技術角度的SLA)。
不確定他們的系統在應用服務層和應用訪問數據庫之間是否有連接池配置，但爲了應用解耦，建議在應用層增加連接池配置，不要用默認參數，而是通過不斷壓測找到最合適的配置參數。
同時，應用服務訪問數據庫不要直連，而是通過DAL組件來訪問。這樣做的好處是連接可以複用，不同系統的同一類型請求可以合併處理，且可以對過高的請求進行限制。
5、數據庫層面讀寫分離
上述問題當前的系統架構下，數據庫是單庫，單點問題很可能在較高的訪問請求壓力下成爲穩定性最大的不確定因素。因此可以對數據庫進行讀寫分離操作，按照一主多從的結構對數據庫進行垂直分庫。
即不同系統請求地圖數據，將請求路由到該業務對應的從庫，地圖數據更新先寫入主庫，然後再同步到從庫。
但這樣改造又存在幾個問題，首先是改造成本比較高，技術難度不小；其次是主從結構下數據同步問題(地圖數據一般數據量比較大，同步耗時較長)，可能會影響地圖的實時精度。
具體實踐中，要綜合考慮訪問量、投入產出比，再決定是否進行改造。
當然，上述的分析和優化方法僅是我個人基於對這個問題的一些猜測，然後結合個人經驗給出的建議，不構成實際操作建議，僅供參考。
性能問題分析和優化，還是要結合具體的業務場景和成本問題，綜合考慮，謹慎優化。