架構設計系列文章，請參見連接探颈。

概述

隨著公司的業(yè)務词裤、團隊的不斷更迭、增長豫尽，原有的軟件系統(tǒng)已經不能很好的解決現在的問題篙梢。這樣的一個軟件系統(tǒng)已經在各個方面產生了問題，它已經限制了公司的業(yè)務的持續(xù)增長美旧、甚至已經不能進行正常的維護開發(fā)工作渤滞。

• 不可避免
  從軟件系統(tǒng)初始階段，所有的銜接上下文都是清晰可變的榴嗅。而隨著業(yè)務的增長會想限界上下文中添加概念妄呕。而在此過程中，通常團隊并不清楚應該何時停止向領域模型中注入越來越多的概念嗽测⌒骼或許剛開始時這個模型很小也能被管理肿孵。然而隨著團隊不斷地注入更多概念，很快便出現了 一個大麻煩疏魏。不僅概念太多停做，而且模型中的語言也變得模糊不清，因為在你思考它時大莫，會發(fā)現在這個巨大的蛉腌、混亂的、漫無邊際的模型中實際存在著多種語言只厘。因為這樣或那樣的錯誤烙丛，團隊常常會將全新的軟件產品變成一個所謂的大泥球。

• 總會發(fā)生
  對于隨著公司的成長而不斷成長的軟件系統(tǒng)來說懈凹，走到這一步是遲早的問題蜀变。而走到這一步只取決于團隊的技術能力，團隊的技術能力好一些這個時刻會晚到一些介评，技術能力弱一些這個時刻會早到一些库北。

• 飲鴆止渴
  對于這類問題公司基本可以想到的解決辦法就是外部招聘有能力，有經驗的人幫助解決問題们陆。但對于一個新加入的或者是咨詢師來說對公司業(yè)務的了解需要時間寒瓦，對公司未來的發(fā)展也需要時間的理解。而對于現在浮躁的互聯(lián)網界來看新入職的人有這樣耐心的幾乎沒有坪仇，再加上浮躁的互聯(lián)網公司的處理這件事的耐心杂腰。導致人員與公司之間永遠在時間上匹配上。這樣就導致公司不斷的招聘新的處理業(yè)務混亂的人才椅文，而這些人在又在不斷的流失喂很。

對于限制業(yè)務發(fā)展、代碼無法維護的問題是怎么發(fā)生的皆刺？有哪些解決策略少辣？以及具體怎樣解決這些問題？將會在后面逐步進行討論羡蛾。

問題原因

一個有幾年沉淀的公司來說都面對著同樣的問題漓帅，技術已經制約了業(yè)務的發(fā)展，原來可以很快上線的功能到現在很難上線痴怨，上線了也經常有很多問題忙干。隨著一個軟件系統(tǒng)經過多年的發(fā)展，經過多個不同開發(fā)人員的手之后變得難以維護浪藻，難以迭代更新捐迫。這種問題在有幾年歷史的公司中非常常見，而這種公司基本上沒有辦法解決這個問題珠移。

為什么發(fā)生這種問題的公司沒有自己解決弓乙？

• 如果發(fā)生這種問題末融，代表公司的技術水平有限；
  對于技術水平的有限是在業(yè)務的持續(xù)演化過程中未能將技術實施計劃暇韧、設計落實到具體的工作中勾习，或是因為根本沒有技術實施計劃導致的。這說明整體公司的技術水平有限懈玻，因為公司中任何人都未能提出并未解決這個問題巧婶。
• 如果發(fā)生這種問題，代表公司的從業(yè)人員能力有限涂乌；
  而從業(yè)人員能力預示著一個公司遇到這類問題的時間是長是短艺栈，人員能力好一些則公司遇到這類問題的時間會長，人員能力弱一些則在很快的時間內就會遇到類似問題湾盒。
• 能嚴重到這種地步代表著公司整體的監(jiān)管能力有限湿右。
  監(jiān)管能力說明公司對與業(yè)務和團隊的管控力，如果遇到這樣的問題罚勾，也說明公司對于團隊和業(yè)務的管控能力都不足毅人。

要弄懂這個怎么解決，就必須明確問題是怎么產生的尖殃。并且明確問題所在之后才可以針對問題制定解決方案丈莺。而解決這個問題不可能一次性解決所有問題，所以最少應該朝著規(guī)避這些問題的方向前行送丰。這里總結的問題都經過了抽象缔俄，并進行進一步解釋。但為了保護作者所在公司的利益器躏，不對具體問題進行描述俐载。下面就具體說明其中會有哪些問題：

四類問題

• 限制業(yè)務發(fā)展

在業(yè)務服務發(fā)展到一定階段之后，會發(fā)現修改代碼非常困難登失。在這個過程中直接感受是修改代碼過于麻煩瞎疼，但問題的根源并不是在代碼這個層面上。

1. 數據模型未跟著業(yè)務的發(fā)展持續(xù)演進
   在持續(xù)的迭代過程中數據模型被各種的業(yè)務不斷的拉扯壁畸，讓其從原來規(guī)整的數據模型變成一個張牙舞爪的數據模型。這樣其實就會造成各種業(yè)務錯綜復雜茅茂，并且這種方式還會在不同的業(yè)務模塊間傳播捏萍。
2. 業(yè)務支持不完善
   在業(yè)務實現過程中，對于現有業(yè)務抽象不足造成問題在發(fā)展新的業(yè)務時都需要進行實現空闲。這樣就造成了不斷的實現新的業(yè)務令杈，不斷的為新業(yè)務造代碼。越來越多的代碼不斷的添加碴倾。
3. 業(yè)務邏輯分散修改困難
   劃分了微服務之后逗噩，新業(yè)務會隨著最靠近的服務進行實現掉丽。在實現過程中總會遇到業(yè)務邊界不清晰的問題，這個時候就會隨意的選擇一個服務對業(yè)務進行實現异雁。而這樣的事情越來越多捶障，就會發(fā)現業(yè)務逐漸的分散在不同的服務中。再加上需要串聯(lián)起來的業(yè)務纲刀，就變成了一個業(yè)務分散在不同的服務中项炼。
4. 業(yè)務過于龐雜，直接理解
   業(yè)務模型中的細節(jié)在持續(xù)的迭代中不斷的增加示绊，而這些增加過程有遺落在每次的需求中锭部。使業(yè)務細節(jié)無法使用一個文檔整體的描述，也無法一次性學習面褐。這樣造成業(yè)務越發(fā)展越大拌禾、越發(fā)展越亂。
5. 人員能力要求高
   在上述問題下就變成了展哭，需要的人的能力越高越好湃窍。只有能力高的人才可以將業(yè)務了解，并對其進行修改摄杂。

• 知識體系丟失

作者在《04.軟件產品公司競爭力》說明過業(yè)務知識是公司的核心競爭力坝咐。對于核心競爭力的承載是業(yè)務知識，而業(yè)務知識的承載可能性就很多析恢。例如：工作人員人腦中的知識墨坚、需求PRD中、數據庫設計中映挂、代碼中泽篮、文檔中等赃阀。但對于這些承載形式最終還是要讓團隊內部達成共識费尽。

1. 業(yè)務知識流失殆盡
   隨著人員的流動業(yè)務知識也在不斷的流失。而團隊成員之間的業(yè)務知識傳遞不暢造成從一個業(yè)務知識豐富的人將業(yè)務知識流轉到低業(yè)務知識的人是一個因人而異的問題夷磕。所以鞍时，業(yè)務知識在沒有其他承載形式的情況下就會不斷的流失亏拉。直至流失殆盡為止。
2. 業(yè)務知識沉淀不足
   現在很多軟件過程都不推薦使用文檔的形式進行需求的管理逆巍。而且現在軟件研發(fā)人員的文檔編寫能力都很弱及塘。導致幾乎沒有文字資料可以反應業(yè)務模型的情況。有文字資料也不能很好的描述一個模型锐极。
3. 業(yè)務知識獲取困難
   業(yè)務知識散落在不同的地方笙僚，所有的PRD都是針對迭代需求進行編寫的。而針對業(yè)務模型進行描述的文檔在沒有業(yè)務驅動的情況下是不會被編寫的灵再。所以一個業(yè)務模型的規(guī)則分散在不同的文檔中肋层，而且還有一部分在人們頭腦中的隱含知識亿笤。這樣就造成如果要學習業(yè)務知識編程很困難的一件事。

• 持續(xù)迭代又無治理導致大泥球

不斷的向限界上下文中添加概念栋猖，而這個添加的過程又不知道什么時候結束净薛。這樣就會造成在限界上下文中概念過多，關系過多掂铐。而造成大泥球的問題罕拂。

1. 設計缺失
   重要功能未有技術設計文檔及評審。注重業(yè)務可用性全陨，而未考慮技術設計合理性爆班。
2. 監(jiān)管缺失
   重要功能設計未受監(jiān)管、實現過程也未受監(jiān)管辱姨。為了追求業(yè)務快速上線柿菩，跳過了監(jiān)管。
3. 治理缺失
   在發(fā)生問題之后不進行治理動作雨涛，而使用修改的辦法去解決問題枢舶。再此過程中也會有業(yè)務治理工具缺失、技術治理工具缺失的問題替久。

• 能力體系建立能力欠缺

在業(yè)務發(fā)展過程中為了更快的建立業(yè)務能力凉泄，而建立起針對性的能力。而隨著發(fā)展下次還有類似的需求蚯根，又建立一個類似的而又偏向于這個場景下的能力后众。能力就變成了哪里都有而任何一個其他地方都用不了的情況。

1. 半拉子工程
   為了快速的試錯颅拦，而建立的系統(tǒng)蒂誉。建立起來之后是不是就不管了？建起來之后具體怎樣淘汰距帅？怎樣從mvp到真正產品階段右锨？對于一個系統(tǒng)的生命周期管理不進行管理造成問題。

2. 重復造輪子
   之前mvp造過一次碌秸，后面有個其他方向的mvp有造一遍绍移。在發(fā)展出來兩個完成體系之后沒有對原先的能力進行熟悉而直接再造一個的。

3. 公共服務維護力度不夠
   因為組織變更造成業(yè)務重新劃分讥电，但提供公共能力的服務永遠會落在兩個團隊之間不管的地帶登夫。這樣的服務對于兩個團隊來說都不是自己的業(yè)務核心那么就以為這不會有專門的規(guī)劃去完成這部分的維護。

4. 運維體系不完善
   故障預案是運維最基本的能力體系允趟。在很多時候都是線上發(fā)生問題了之后進行問題解決，這其實就凸顯了運維能力鸦致、體系不完善的問題潮剪。

解決策略

遇到了問題不要退縮而應迎難而上涣楷，而且要解決根本性問題才對問題有意。如只是解決表面問題下回總是還會遇到類似問題抗碰。只有持續(xù)改進才能真正的解決問題狮斗。

幸福的家庭都是相似的，不幸的家庭各有各的不幸弧蝇。-- 托爾斯泰《安娜·卡列尼娜》

• 約束
  上一章節(jié)說明了具體的問題碳褒，而解決這些問題還有一些限制。這因為這些限制導致解決問題的難度大大的增加看疗。故這些約束也是解決問題的前提沙峻。

  1. 盡量少影響現有業(yè)務
  2. 盡量可以利用原有數據
  3. 提供完善的中臺能力
  4. 提供演進方法

• 方法
  基于重構還是基于重寫去完成服務治理？根據上面的約束可以很容易的得出結論两芳。
  

• 業(yè)務模型
  團隊中每個人認為的業(yè)務模型都是不一樣的摔寨，所以需要通過共識的方法將所有的人的模型達到共識。
  

• 實現方法
  原先一個接口中包含的業(yè)務過多怖辆，需要將業(yè)務拆分成不同的接口是复。以原子化的方式提高接口的通用能力。
  

解決問題

具體解決問題也分步驟竖螃，根據步驟完成服務治理工作淑廊。步驟的前后全系承載著業(yè)務的逐漸梳理過程。

• 按照業(yè)務場景梳理所有業(yè)務
  通過場景的信息建立對于場景下業(yè)務模型的知識特咆〖境停可以更好的梳理出業(yè)務模型的規(guī)則。

• 制定中臺實施規(guī)范
  通過規(guī)范去建立規(guī)范的平臺坚弱。例如：服務平臺整體設計蜀备、知識庫梳理、基礎服務平臺接口規(guī)范荒叶、基礎服務平臺質量規(guī)范碾阁、基礎服務平臺日志規(guī)范、基礎服務平臺異常規(guī)范些楣、基礎服務平臺工程規(guī)范等脂凶。

• 進行服務治理
  通過梳理與遵循規(guī)范對服務進行治理。例如：對服務進行拆分和下線愁茁、減除同層橫向依賴蚕钦、建立補償機制、剪除第三方依賴等鹅很。

• 建立能力體系
  根據業(yè)務模型嘶居，建立起可以支撐業(yè)務創(chuàng)新的業(yè)務能力體系。

• 建立技術體系
  通過建立研發(fā)體系和運維體系達成技術體系建立的目標。建立技術體系可以通過：滿足四化完成

  1. 數據化
  2. 可視化
  3. 標準化
  4. 體系化

例如：研發(fā)體系中事件通知機制建立邮屁、分布式任務調度整袁、服務間通信機制、ID生成器佑吝、文件存儲服務坐昙、日志服務、分布式事務管理芋忿、調用鏈管理炸客、限流、降級戈钢、熔斷痹仙、特性開關、QRCode逆趣，運維體系中K8s蝶溶、彈性伸縮、發(fā)布方法（藍綠或灰度）宣渗、自動恢復抖所、故障預案

總結

對于解決這類問題有兩個最重要的問題：

1. 冰凍三尺非一日之寒
   對這類問題需要有耐心去處理，如果想著處理一段時間就會將這類問題處理好痕囱。根據墑增原理田轧，如果一個系統(tǒng)不經過外部作用永遠都會趨向于無須。
2. 不積跬步無以至千里
   有真正的投入才有真正的收獲鞍恢。對于解決這類糾纏不清傻粘、難于理順的問題來說，需要拖入的不止時間帮掉，還需要精力的投入弦悉。正面面對這個問題，問題才可以得到解決蟆炊。

對于看完上面內容的讀者來說稽莉，作者在這里給出的終極路徑只有一條：整體設計，漸進式重構涩搓，漸進式上線污秆。

感謝

感謝在這個過程中幫助過我們的人們。