引子

《架構師之路-redis集群解析》提到:提出有水平的問題、做出有水平的總結和建議、做出有水平的回答 是架構師面臨的三大難。

天天開會,最怕開會。開會十分鐘,準備半天功。

 

 

下面是圍繞這三大難展開的故事。

 

情景-領域劃分問題

幾年前的一天,在一個會上,完全不相關的團隊人員在進行我們系統的架構評審。由于他們對我的系統不了解,提的問題多是針對架構師個人能力上的。

我在介紹的時候提到:“根據系統的特點,按照角色劃分領域的同時結合現有人員情況劃分了下面幾個應用……”,然后我被打斷了,有人提問說:“應用是按領域劃分還是按照人員劃分?”

針對這種埋坑的問題,選項有A和B,那更合理的答案一般是C。圖片

翻譯提問者的問題其實是在問:“不是都是用領域劃分領域嗎?按照人員劃分的方法不對吧?”

先來分析一下,我順著提問者的話說會怎樣:“模塊需要按照領域劃分,模塊是分層級的。人員劃分決定的是獨立部署單位的粒度,在實際項目中應該綜合考慮?!?/p>

這樣雖然回答了提問者的問題,但是提問者很顯然有知識上的盲區,需要我給他解惑的地方:“究竟要怎樣劃分應用?”而我的回答沒有給出他完整的答案,他會繼續找一些回答的漏洞來細化問題,比如:“資源預算不算做考慮粒度的因素嗎?” 假定我每次順著他的思路來,整個回答過程就沒有清晰的結構了。

所以我需要直接針對他本質的問題展開回答,以下是回答內容:

在這次介紹的系統中,最主要的依據是按照領域來劃分模塊,同時根據資源和人員等情況來決定獨立部署的應用模塊的粒度。

但是在其他的系統中,根據不同的系統特點,模塊或者應用的劃分上,考慮側重點會有所不同。我舉幾個例子。

示例一(管道過濾器模式)

比如工作流類的系統,從總體架構上采用的是管道過濾器模式

如上圖,在這種系統中主要有兩種角色,一種是管理者角色,負責把其他模塊組織串聯起來,整體對外提供服務。記得之前做個這樣的項目,管理者角色的模塊系統名叫captain(當時大家都以漫威英雄人物命名,captain對應美國隊長)。其他模塊都是一個個過濾器。是否要將每個過濾器獨立應用部署,還是主要根據人力和資源來定。只要設計清晰,將來人力和資源有調整,或者隨著業務的發展,對穩定性有個更好的要求,可能會需要根據可用性做一個隔離。高SLA和低SLA的單獨部署,高SLA的多地區多機房部署。

示例二(三平面分離模式)

比如三平面分離架構系統,詳情可參考我之前的文章《三平面分離架構》。簡單來說分成最核心的流程控制平面、次核心的組件支撐平面和SLA只要求兩個9的管理運維平面。如下圖:

所以領域劃分時這三個平面要邊界分明,三個平面可用性級別不同,資源分配也不同。比如最核心的流程控制平臺日志存儲要90天,其他可能需要30天;流程控制平面可能需每筆請求開始和結束打日志,而其他服務只需要異常時打日志;流程控制平面和組件支撐平面需要四地八中心高可用部署,而管理運維平臺只需要兩機房容災。所以核心是要將三個平面分開以分配不同的資源。

示例三(異步處理模式)

有些應用整體是實現一個大職責,但是被中間件分成了兩個部分。比如有個服務是異步處理模式。所謂異步處理模式是將一個執行耗時長的流程分成兩個階段。比如退款操作。用戶提交一個退款請求,先會收到一個實時通知:“您的退款請求已經收到,退款會于1~2個工作日內到賬?!敝笙到y會將這個退款請求扔到MQ中,慢慢來消費處理。

這種模式的服務,根據實際資源等情況可以分成兩個獨立部署的系統,或者合在一個應用里既作為MQ的生產者又作為MQ的消費者。

 

 

總結

如果觀察到別人總是就細節進行追問,這時候可以先把思路跳出來弄清楚他的本質問題是什么。

 

推薦閱讀

服務設計要解決的問題

分布式存儲系統的一致性-可見性差異

代碼榮辱觀-以運用風格為榮,以隨意編碼為恥

程序員如何破局前行