給飛馳的法拉利換引擎 - 談邊做業務邊做架構重構（4）

前面講了那麼多，看起來都是和項目管理相關的的，例如“有的放矢”是關于找目标的、“合縱連橫”是關于溝通協調的、“運籌帷幄”是關于項目規劃的。。。。。。架構師怎麼變成了項目經理了，說好的技術呢？

 真正的架構師，當然必須具備一定的項目經理技能，但更重要的還是技術能力，道理很簡單：再好的餅，最後實作不了，都是扯淡！我将“項目管理能力”稱之為“文”的能力，“技術能力”稱之為“武”的能力，架構師必須文武雙全，才能最終把事情搞定！

 架構師的“武”展現在很多方面，既有微觀層面的，例如如何設計一個高性能的并發架構（可以參考disruptor，大量的技術細節，例如cpu cache，cache line，false sharing等）；也有宏觀層面的，例如采用hbase還是用mysql存儲；還有和業務相關的，例如某個功能應該如何設計才能具備可擴充性。業務層面的相關的技術問題，如果沒有相關的業務背景，講起來比較費勁，也不好了解，這裡就不展開了。我們講講這些重構項目中和業務無關的一些技術。

 我被問到的最多的問題其實也是宏觀層面的。其中一個主要的問題是“這些系統的業務都不一樣，你之前也沒有類似業務背景，你怎麼識别出m系統重構的目标是資料解耦，s系統重構的目标是高可用呢，x系統重構的目标是系統解耦呢？”

 以m系統為例，重構前性能不高，且隻有單機，但由于是背景系統，使用者都是内部使用者，每天就幾百個人使用而已，是以還不是關鍵問題；關鍵問題是“不合理的耦合帶來的複雜性”：将特定業務的資料和所有業務的公共資料耦合在一起，資料正确性難以保證，且每次修改都是“牽一發動全身”，效率很低，是以重構的目标就是将“不合理的耦合”進行拆分。

 而對s系統來說，前期團隊在設計的時候已經基于業務進行了拆分，各個子系統職責比較明确，邊界清晰，是以複雜度不是主要問題；每天通路量都是億級以上，之前的架構設計上已經考慮了多機房和平行擴容的能力，是以性能也不是主要問題。主要的問題就是有一個全局單點，一旦這個單點故障，就會導緻所有業務全部不可用，而遊戲相關業務可靠性要求又非常高，隻要有5分鐘不可用，客服電話已經被玩家打爆了，論壇也都被刷爆。是以我們重構的目标就是解決“全局唯一單點”的可靠性問題。

x系統的情況更加特殊。首先存在和m系統相同的“複雜度”問題，隻是表現形式不一樣而已：m系統是資料耦合導緻的複雜度增加，x系統是業務全部放到一個系統中實作導緻的複雜度增加。其次是存在和s系統類似的“可靠性”問題，也隻是表現形式有所差别：s系統是全局單點導緻可靠性問題，x系統是有問題就整站挂掉的可靠性問題。是以我們最初在讨論x系統重構的時候是定了兩個目标：解決複雜性和可靠性的問題，但随着對問題的分析逐漸深入，我們發現如果不解決複雜性問題，可靠性問題是無論如何都解決不了的。是以最終我們調整目标，将x系統的重構目标聚焦在将“大而全的系統拆分為多個分工合作的子系統”。

 從上面的3個執行個體我們可以看到，其實隻要掌握了架構設計的“道”，不管什麼業務，在宏觀層面的判斷和決策都可以用這一套方法論去應對。

 明白了架構設計和架構重構宏觀層面的關鍵之“道”，我們來看看微觀層面的“術”：即我們如何才能設計出一個方案來滿足複雜度、可靠性、性能的需求呢？

說出來你可能不相信，架構設計或者架構重構有一把“屠龍寶刀”，複雜性、性能、可靠性都可以通過這一個方法去搞定。這把屠龍寶刀就是“拆”！

資料耦合？ 系統太龐大？—— 将系統“拆”分為多個子系統。。。。。。

性能比較低？—— 将一台機器“拆”為兩台，兩台不夠“拆”為4台。。。。。。

可靠性不行？—— 單點“拆”分為叢集，單機房“拆”為雙機房。。。。。。

 到目前為止，看起來架構設計好像很簡單：“複雜性，性能，可靠性，拆”，感覺随便一個人掌握了這4個關鍵字就可以做架構設計或者重構了。。。。。。看起來架構師也不過如此嘛！其實不然，“道”是很簡單，但面對具體問題、具體業務的時候，将“道”落地實作才是關鍵！

 以x系統為例，将原有大而全的x系統拆分為多個子系統，關鍵不在于是否要拆，而是在于“怎麼拆”。是拆分為2個呢，還是4個呢，還是10個呢？。。。。。。好像都可以，那又怎麼取舍？例如：

随便取一個？。。。。。。好像心裡沒譜！

發個微信紅包看最大的紅包整數？。。。。。。好像是碰運氣，選錯了怎麼辦！

現在不是流行微服務麼，咱們拆的越細越好，參考淘寶，拆分為100個？。。。。。。你看研發和運維要不要打死你！

不知道就讓老大拍闆吧？。。。。。。是你做架構設計還是老大做架構設計！

找一群人來投票 ？。。。。。。大家都選拆分最少的投，因為這樣工作量最少！

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

是以，“拆”的方向是沒問題的，但“細節決定成敗”，“如何拆”才是展現架構師能力的關鍵。要具備這樣的能力，需要大量的實踐、積累、思考、探索，是以要想成為一個牛逼的架構師是很難的，尤其是在國内這種過了30就不做技術的氛圍下，更加需要對技術的熱愛和不斷的追求，同時要有比較好的機遇，才能夠成長為真正的架構師。

 對應到x系統的案例，我個人的經驗就是7+-2原則，也就是說将系統拆分為5 ~ 9 個人能夠維護的粒度，也就是說假如你的團隊有20人，拆分成3 ~ 5個系統是比較合适，即使再拆的更細，最低要保證3個人負責一個系統的粒度，如果出現一個人負責1個系統，甚至一個人要負責多個系統，就說明拆的太細了，會帶來很多問題。

為何按照這個原則來拆分呢？科學研究證明，人腦同時關注的目标大約就是7+-2個，對于一個9個人負責的系統來說，每個人基本上都可以覆寫到系統的所有方面，如果20個人才能維護一個系統，說明1個人可能要關注20個點，但人很難關注這麼多的點的。

其次為何至少要3個人負責一個系統呢？這是從團隊管理的角度出發的，如果2個人甚至1個人負責一個系統，首先是人員沒有足夠備份，一個人請假或者變動，整個系統的效率就要受到影響；其次如果1個人負責一個或者多個系統，思考難免有遺漏，容易出問題。