推薦一張不錯的架構圖

今天在地鐵上看到溫昱老師傳送的幾張圖，非常受益。原來比較模糊的一類問題有了較為清晰的思路。也許這就是一種茅塞頓開的感覺，因為最近就是在思考這類問題，在糾結這類問題，如何繼續推進下去，思路還不是很明確。

看了這個圖，發現原來這個過程中我也缺少了一個環節，那就是介面設計的部分和分佈設計環節，這個環節的功夫下得還不夠。

因為我最近在構建一個平臺，但是隨著業務需求的深入，發現技術支援上開始乏力，而且在急於求成的過程中，會傾向於直接從需求過渡到開發測試的階段，急於實現，但是發現在實現的過程會有很多的分叉點，可以這樣做，也可以那樣做，然後就開始糾結那種好一些，然後新的問題來了，新的技術點又需要融會貫通，然後又可能有分叉點，如此一來，距離解決問題的正確方向似乎開始偏離了，雖然最終也可以把這個流程打通，但是顯然效率低了不是一點半點。不是規劃的節奏，而是想到哪裡做到哪裡的節奏，這樣一來，質量和目標保證不了，很多計劃做的事情就得擱置了。

上面的片子裡面主要的方向是討論CBB產品的架構設計，但是對於我們構建平臺來說是通用的。

從這個角度來說，幾個人和幾百人，幾千人去構建這樣一個平臺，架構的複雜度和模組重用的複雜度可想而知。

比如運維平臺中，我希望引入一個通用模組-任務排程，這個模組會服務於其他的多個模組，比如備份任務的排程，資料恢復的排程，按照架構模式，目前的設計會按照多工結構+佇列（使用Redis）來實現，對映到具體的方案即是celery的技術棧。

如果能夠滿足當前系統的需求，要滿足更多外部部門的需求，那就有更多的事情需要做，有的部門絕對滿足不了，乾脆就自己造輪子，相對來說更耗時耗力，這個時候就會涉及到程式碼重用和CBB重用就尤為重要了。

對我最關心的介面設計，溫昱老師給了一些指點，有個很乾的公式：

介面設計=互動過程設計 + 介面技術選擇 + 介面格式定義

專業的架構層面有很多我們需要借鑑的東西。基礎技術達標了，後期要提升的空間裡，工程方法論就是一個很重要的入口。

如果對這些內容感興趣，需要諮詢的可以留言或者企業對接，我可以代為轉達。