當我談架構的時候，我談些什麼？

過去一年，業務增長迅猛，架構不斷改進，但我卻看不清楚架構未來的樣子，經過思考悟出一些簡單的道理，架構是為業務服務的，一切不以業務為指標的架構都是耍流氓。

為什麼要談架構？

談一談過去一年，自己在建設小米廣告平台的一些關於架構收穫。最近一年，小米廣告的業務飛速發展，架構不斷進化，單一業務變成了近10個業務，研發人員也翻了3倍，廣告請求流量翻了10倍還多，部署的機器也翻了近8倍，各個業務將繼續保持高速發展。最近碰到一個困擾，我能看清楚三個月內架構進化的目標。但是，我卻無法想清楚半年或一年後架構演化的藍圖？這個問題給我帶來不少思考，直到最近，才理清楚了一些道理：不為業務服務的架構演化都是耍流氓，對架構長期目標的不清楚，就來源於對於業務多變性的不可預測。

先講講近一年項目的架構演化，年初的時候，業務單一，基礎薄弱，演算法樸素。首先，在線上事故的教訓下，增加了全面的監控，包括主動監控、被動監控，並且將可監控性作為每一個服務的基本屬性，問題檢測時間縮短到分鐘級，問題排除效率也大大提高；另外，在業務壓力的推動下，樸素的廣告演算法逐步升級成基於大數據的模型，模型數據的實時性也從每日更新，變成每分鐘更新，進行一個演算法實驗變得更加敏捷；在牽一髮而動全身的設計困惑下，「大泥團」的架構實體漸漸理順了層次和關係，分清了主和次。業務也從單一大業務，變成了3個骨幹業務+5初創業務的複合服務。

軟體架構的藍圖在哪裡？

雖然架構一直在進化，新舊問題也不斷在被解決，但是對於半年或一年後的架構，依舊無法看透。架構需要不斷的優化和改進，但是以什麼為指南針，來判定架構改進任務的優先順序，如何平衡短期和長期的投入和收益？一直沒有悟透這個道理，為此找來了幾本書看看。一本是《架構之美》，還有一本是《恰如其分的架構設計》，還有Martin Fowler的一些文章，有了一些啟發。

首先對於架構的理解，找到了些共鳴。

大師Grady Booch對於軟體架構的定義是「架構是一種設計，但並非所有設計都是架構。架構代表著發展一個系統的重要決定，而這種重要性是通過引入變化的成本來衡量的」。引入變化成本將成為架構決策的重要因素，這與我的想法不謀而合，其實架構的演化就是與業務息息相關。

《恰》里提到「對定一個系統，需要多少專門的架構設計工作？ 一個關鍵問題是，如果一個項目沒有太多的設計風險，說明架構在一個好的狀態，不需要太多的架構工作；如果一個系統的設計風險很大，每一個業務實現都需要過多的考慮設計風險，那麼說明這個項目的架構需要大力投入了。這就是風險驅動的架構設計。」

這些理解都和我的想法不謀而合，架構是一個過程，而不是一個結果。架構的需求來源於系統的狀態和業務的需求，說一句俗氣的話「不為業務服務的架構都是耍流氓」，遵守奧卡姆剃刀定律，如無業務必要，無需增加不必要的架構工作。

架構師和建築師

架構師和建築師相同點是都需要負責一些框架，建築師需要保證建築的美觀，實用和堅固，架構師也需要負責軟體架構的簡單，實用和可靠。他們之間很大的區別是：架構師隨著時間的演化，需要繼續對架構進行演化，以支持業務的發展，他比建築師多一個時間的維度。所以，架構師的角色更像是一個城市的規劃師，負責長期的演化工作，應對以後的變化，包括很多未知的可能性。遙想建國初年，梁思成提出來的《梁陳方案》如果能夠演化下來，北京的古城保護將會是另外一番景象。

架構師的KPI

好了，搞清楚了架構師的作用之後，如何評定架構師的成績（OKR或者KPI)、響應時間、並發數量、開發效率、缺陷數量等。這些都是工程師眼中的工程師目標，這些指標到底和業務增長有多少關係呢？ 有些可能是直接相關的，有些可能是間接相關的，並非是面向業務的演化。如果將業務的KPIs作為架構師的KPIs呢，例如營收、用戶數、使用時長、留存數等？初想這個問題，感覺很難關聯上，但是仔細想想，關聯還是非常大的。架構師在系統演化過程中，最重要的技能就是能夠平衡好成本、速度、質量和風險，那麼在平衡這些因素的時候，總是需要一個基本原則來指導，這就是通常說的True North，用最簡單的指標來決定方向。那麼，業務的關鍵指標將是非常重要的。

為什麼只選一個關鍵指標，因為真正的北方只有一個。有一本書叫做《Lean Analytics》裡面介紹了一種觀點 OMTM(One Metric That Matter)，每個組織都應該找到它的關鍵指標，這個指標必須簡單直接，尋找這個指標也許不容易，但是一旦確定下來，就可以快速迭代、進行優化、周而復始的為之努力。架構的演化也必須找到這個指標。

總結一下，當我談架構的時候，我談的是架構需要對業務負責，演化指標必須與業務關聯，為情懷而生的架構是難以落地的。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！