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