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