架構師三大難-領域劃分問題
引子
在《架構師之路-redis集群解析》提到：提出有水平的問題、做出有水平的總結和建議、做出有水平的回答 是架構師面臨的三大難。
天天開會，最怕開會。開會十分鐘，準備半天功。
下面是圍繞這三大難展開的故事。
情景-領域劃分問題
幾年前的一天，在一個會上，完全不相關的團隊人員在進行我們系統的架構評審。由於他們對我的系統不了解，提的問題多是針對架構師個人能力上的。
我在介紹的時候提到：「根據系統的特點，按照角色劃分領域的同時結合現有人員情況劃分了下面幾個應用……」，然後我被打斷了，有人提問說：「應用是按領域劃分還是按照人員劃分？」
針對這種埋坑的問題，選項有A和B，那更合理的答案一般是C。
翻譯提問者的問題其實是在問：「不是都是用領域劃分領域嗎？按照人員劃分的方法不對吧？」
先來分析一下，我順着提問者的話說會怎樣：「模塊需要按照領域劃分，模塊是分層級的。人員劃分決定的是獨立部署單位的粒度，在實際項目中應該綜合考慮。」
這樣雖然回答了提問者的問題，但是提問者很顯然有知識上的盲區，需要我給他解惑的地方：「究竟要怎樣劃分應用？」而我的回答沒有給出他完整的答案，他會繼續找一些回答的漏洞來細化問題，比如：「資源預算不算做考慮粒度的因素嗎？」 假定我每次順着他的思路來，整個回答過程就沒有清晰的結構了。
所以我需要直接針對他本質的問題展開回答，以下是回答內容：
在這次介紹的系統中，最主要的依據是按照領域來劃分模塊，同時根據資源和人員等情況來決定獨立部署的應用模塊的粒度。
但是在其他的系統中，根據不同的系統特點，模塊或者應用的劃分上，考慮側重點會有所不同。我舉幾個例子。
示例一(管道過濾器模式)
比如工作流類的系統，從總體架構上採用的是管道過濾器模式
如上圖，在這種系統中主要有兩種角色，一種是管理者角色，負責把其他模塊組織串聯起來，整體對外提供服務。記得之前做個這樣的項目，管理者角色的模塊系統名叫captain（當時大家都以漫威英雄人物命名，captain對應美國隊長）。其他模塊都是一個個過濾器。是否要將每個過濾器獨立應用部署，還是主要根據人力和資源來定。只要設計清晰，將來人力和資源有調整，或者隨着業務的發展，對穩定性有個更好的要求，可能會需要根據可用性做一個隔離。高SLA和低SLA的單獨部署，高SLA的多地區多機房部署。
示例二(三平面分離模式)
比如三平面分離架構系統，詳情可參考我之前的文章《三平面分離架構》。簡單來說分成最核心的流程控制平面、次核心的組件支撐平面和SLA只要求兩個9的管理運維平面。如下圖：
所以領域劃分時這三個平面要邊界分明，三個平面可用性級別不同，資源分配也不同。比如最核心的流程控制平台日誌存儲要90天，其他可能需要30天；流程控制平面可能需每筆請求開始和結束打日誌，而其他服務只需要異常時打日誌；流程控制平面和組件支撐平面需要四地八中心高可用部署，而管理運維平台只需要兩機房容災。所以核心是要將三個平面分開以分配不同的資源。
示例三(異步處理模式)
有些應用整體是實現一個大職責，但是被中間件分成了兩個部分。比如有個服務是異步處理模式。所謂異步處理模式是將一個執行耗時長的流程分成兩個階段。比如退款操作。用戶提交一個退款請求，先會收到一個實時通知：「您的退款請求已經收到，退款會於1~2個工作日內到賬。」之後系統會將這個退款請求扔到MQ中，慢慢來消費處理。
這種模式的服務，根據實際資源等情況可以分成兩個獨立部署的系統，或者合在一個應用里既作為MQ的生產者又作為MQ的消費者。
總結
如果觀察到別人總是就細節進行追問，這時候可以先把思路跳出來弄清楚他的本質問題是什麼。
推薦閱讀
