大家好，我是架構擺渡人。這是實踐經驗系列的第五篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收獲，還請分享給更多的朋友。
今天跟大家聊聊隔離這個話題，對于高流量的業務場景，以電商業務舉例，一定要做好核心接口的隔離，否則真的就是牽一發而動全身。
以前的工作中有遇到過因為一個賣家的背景查詢，産生了慢SQL，導緻單量直線下跌，使用者無法下單了，都是系統異常，逾時報錯。
要解決好這些問題，隔壁必須要做，雖然成本比較大，但是帶來的收益是你想象不到的穩定。具體怎麼做，有哪些步驟，各位看官請繼續閱讀下去。
首先需要做的就是将資源進行隔離，這裡的資源指的是資料庫，緩存，MQ等程式依賴的資源。就像開頭說的慢SQL影響了整個服務，問題就在于資料庫沒做隔離。像電商這種場景，買家和賣家的庫要拆分出兩套，這樣賣家查詢即使産生慢SQL也不會影響買家這邊的下單操作，因為資料庫是兩個不同的執行個體。
緩存也是一樣的問題，如果共用一個執行個體，當Redis出現問題，比如大Key導緻帶寬滿了，其他的Redis操作都會阻塞，這樣就影響到了其他業務。
資源隔離之後，我們的服務也要進行隔離。将買家和賣家的業務獨立出兩個服務，每個服務連自己的資料庫和緩存，互不影響。
這樣隔離還有一個好處就是在後續做多活的時候，賣家場景是不需要做多活保障的，而買家場景是必須要做多活。是以在多活的時候隻需要将買家的服務進行多活改造和多機房部署即可。
核心代碼隔離的就細粒度了，前面我們做了BC端隔離，将買家和賣家的業務進行了隔離。但是還有個問題是就算全部是買家的業務，它也是分級别的，比如核心的下單，确認訂單，訂單詳情，訂單清單就屬于P0級别，其他的就是P1,P2這種級别。
如果一個P2級别的接口出了問題，影響了P0的接口，那就相當于隔離失效了，是以核心代碼一定要單獨提取出來作為獨立的服務，這樣才能達到隔離的效果。
還有個好處就是核心接口的通路量都是大于其他接口的，在大促的時候，擴容隻需要擴核心接口的服務，其他的不需要擴容，對于成本來說也是控制的比較好。
前面的步驟都完成後，必然會有一個選項就是部署隔離。因為你服務都獨立出來了，部署肯定也是獨立的，一個服務一個容器或者一台ECS。大家可能有疑惑了，不都是一個程式部署一台伺服器麼？這個其實在很多小公司為了節約成本，或者說流量不高的場景下，都會一台伺服器部署好幾個應用，資料庫也有可能就是跟應用在一個伺服器上。
隔離部署後，這樣某個服務出問題，比如CPU 100%，其實不影響其他服務，這就是獨立部署的好處。
最後一點就是在編碼的過程中，我們一定要厘清楚哪些是核心，哪些非核心。比如訂單清單的接口，需要顯示一個其他的什麼資訊，這個資訊是其他服務提供的，正常的邏輯那就是對每個訂單進行一次内部RPC調用，組裝資料傳回給用戶端。
如果這個時候依賴的那個RPC不穩定或者說出問題了，直接報錯了，那麼此時訂單清單就顯示不出來了。像這種場景，在編碼的時候就需要考慮這個外部依賴是否核心邏輯，是否能夠降級。
如果非核心，需要進行異常處理，或者增加降級開關，在大促的時候進行關閉。這樣即使調用報錯了，隻是這部分資訊不顯示而已，訂單清單還是可以顯示，這也是一種隔離方式，但是是在編碼層面提現的隔離。
聊了這麼多隔離，不知道大家在工作中有實作過哪些隔離呢？反正我是都經曆過這些問題，經曆過共用資料庫導緻的故障依賴問題，後面一步步将應用，資源，核心接口拆分獨立出去，穩定性慢慢就上升了。沒有故障，哪來少年你的成長。