題圖：設計理論的完善
最近似乎所有的電臺裏都在為國慶長假倒數計時，身邊的小夥伴們好像也提前進入了慶歡狀態，連我也提前一周打點好了潛水裝備，耐心等待那黃金一刻的到來
按照慣例，每年十一黃金周是公司啟動下一年戰略規劃的觸發點，對於IT側來說無非就是談談架構，算算成本， 攏攏人頭
既然是談談架構，必然會談到技術改造的話題，比如某某系統的改造，某某系統的重構之類，而且改造（或重構）可以給公司將來帶來如何如何的好處和收益，這些其實都是司空見慣的事情，可就在討論的過程中，由於某系統的改造方案，引起了一場小小的爭論……
故事情節回放
故事場景： A系統，負責公司內部的信息化管理工作，疑似 “OA+資源管理+DevOps（部分）” 的綜合性功能類系統
故事背景： 由於業務叠代多，速度要求提高，導致BUG增多，效率下降，所以決定對A系統進行服務拆分
改造目的：
-
遷移： DevOps類功能遷移至PaaS平臺中
-
拆分： 業務垂直拆分，解決改A錯B
-
分層： 建立自定義中臺，支持大量自定義流程更改並同時快速叠代的需求
資源投入： 架構師*1，開發*3
時間要求： 1個月內上線，同時保證正常周叠代需求陸續上線
技術指標： 在線<200人，穩定性要求高
題圖：A君 = 系統架構設計概要圖 - 采用Dubbo作為RPC技術選型
說完情節，回放以下部分對話（A君 = 架構師）：
……(完成對改造方案的說明)……
A君：大家看看，對這個方案有什麽問題嗎？
B君：我感覺沒必要拆的那麽細吧，不就內部系統嗎？又不是在線聯機服務，把代碼分層做做好，也可以放在不同的Project裏，表在一個庫裏用不同的前綴區分業務，獲取數據也變得更簡單了
題圖：B君 = 系統架構設計概要圖 - 代碼分層，JVM內部方法調用
A君：你這麽設計有問題的，問題如下：
-
如果A模塊變更，怎麽才能獨立發布呢？
-
再如果B模塊方法入參變更，影響到C模塊怎麽辦？
-
再如果D模塊因為某某原因導致流量增大，不是把其他功能都拖慢了嗎？
-
再如果E模塊出現一個BUG，不是把整個系統都Crash掉了嗎？
-
再如果數據庫掛了，不是整個系統都不可用了嗎？
-
再如果……
A君：剛才說的是系統結構，再說說人吧，我們幾個都不太會前端技術，只有張三會前端，所以如果按照我的架構設計，我打算把整個表現層都交給張三做，獨立的War包服務，想怎麽玩，想怎麽發布都行
A君：何況外面的系統都是這麽玩的，我不覺得我的設計有什麽問題，你這個設計太落伍了吧，不利於未來的擴展性、靈活性……
……(略過很多行，不過到這時，B君已經不再說話了)……
在做出合理的選擇之時，我們該考慮些什麽？
接口規範遠比擴展性與靈活性更重要
相比系統的擴展性與靈活性，接口輸入、輸出及接口命名的規範與標準化，往往更容易對後期發展造成較大影響（如加個參數，改A錯B）
接口標準做好了，換成RPC或其他協議，想必也不會困難到哪裏去
題圖：采用分層架構的某某系統，接口抽樣說明
無論分布式數據庫，還是數據庫集群
自打這世界上有了關系型數據庫之後，就從來沒聽說在高可用上缺乏過解決方案，對於某些非熱點（雙11，大促之類）應用或服務，分不分布式，有那麽重要嗎？
比起運維成本與聚合數據時，應用付出的額外開銷，采用數據庫集群來滿足，可能是一個非常不錯的選擇
殺雞不用 牛刀 ，不僅想起了當年的EJB
回憶起十幾年前，那個EJB大肆盛行的年代，我見過40+人的團隊，使用EJB開發電商系統，同時我也見過3個人的團隊，使用EJB開發OA系統的……
面向成果，還是面向簡歷？
上半年接觸到的一個名詞 “簡歷驅動開發”（Resume Driven Development），在很多技術方案討論中，恰恰融入了很多這樣的因素，雖然本身並不是什麽壞事，不過還是需要兼顧下 “系統利益獲得者（使用方、業務方或運維成本）”
名詞解釋如下：
-
選擇是否使用一項技術或者架構的標準是是否有利於自己的職業發展，而不是有利於客戶/用戶；
-
選擇是否使用一項技術或者架構的標準是是否時髦而不是是否符合業務場景；
-
以技術的名義創造各種NB頭銜（Job Title）；
記得有一次面試，我問面試者：
我：你們用Docker嗎？ 面試者：用啊 我：你們用Docker的目的是什麽？ 面試者：（……略去很多內容，這位小夥伴說了很多Docker帶來的好處……） 我：嗯，你們有多少臺服務器啊？ 面試者：2臺 我：……2臺？為什麽不選擇Master/Slave，而選擇Docker呢？ 面試者：節約資源呀，況且現在不是很流行嗎？不用就要落伍啦，找不著工作啦
有些系統考慮未來毫無必要
每個系統都是有生命周期的，未來會發展成什麽樣？將一個在其生命周期內不可能產生高並發場景的系統設計成高並發架構，這種行為就是耍流氓
你那麽斷定嗎？萬一他哪天有了這樣的場景呢？我只是說萬一，那推倒重構的成本你過算嗎？
當然沒算過，不過可以預料的是，由於過度設計而導致的額外支出成本（如排障時間、人員離職及技術BUG等）一定比重構成本來的大，何況在大部分情況下，選擇重構，多數是由於依賴系統的業務有了發展，我們才會痛下決心去重構，要不然為什麽要去操這份心呢？
結束語
雖然從某種角度來說，分層架構與微服務並不屬於同一級別，乃至同一層級的話題，但在實際工作場景中，往往會成為初期選擇的爭論點之一
記得在SOLID原則中提到
當我們不確定哪種架構更合適的時候，分層架構將是一個很好的起點
故事講到這裏應該結束了，也許，這樣的故事每天都在發生，有可能這次是A君 “贏了” ，下次是B君 “勝了”，可作為系統設計者，是否更應多從系統的受益方（也許是業務，也許是IT的其他崗位）來思考呢？
也許哪一天，“ 合理的 選擇 ” 將不再充滿爭議……
近期發表文章：
為什麽有的人跑步時喜歡聽音樂，有的人卻不喜歡？
基於資產配置業務場景下的全鏈路監控平臺
註釋，是一種藝術
一場你註定無法躲避的“江湖恩怨”
掃描二維碼或手動搜索微信公眾號【吃草的羅漢】
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【吃草的羅漢】近期的文章匯總
↓↓↓
Tags: 架構 系統 叠代 改造 拆分 分層
文章來源：