架構(gòu)設(shè)計(jì)系列文章，請(qǐng)參見連接。

概述

隨著公司的業(yè)務(wù)、團(tuán)隊(duì)的不斷更迭、增長(zhǎng)，原有的軟件系統(tǒng)已經(jīng)不能很好的解決現(xiàn)在的問題。這樣的一個(gè)軟件系統(tǒng)已經(jīng)在各個(gè)方面產(chǎn)生了問題，它已經(jīng)限制了公司的業(yè)務(wù)的持續(xù)增長(zhǎng)、甚至已經(jīng)不能進(jìn)行正常的維護(hù)開發(fā)工作。

• 不可避免
  從軟件系統(tǒng)初始階段，所有的銜接上下文都是清晰可變的。而隨著業(yè)務(wù)的增長(zhǎng)會(huì)想限界上下文中添加概念。而在此過程中，通常團(tuán)隊(duì)并不清楚應(yīng)該何時(shí)停止向領(lǐng)域模型中注入越來越多的概念。或許剛開始時(shí)這個(gè)模型很小也能被管理。然而隨著團(tuán)隊(duì)不斷地注入更多概念，很快便出現(xiàn)了 一個(gè)大麻煩。不僅概念太多，而且模型中的語言也變得模糊不清，因?yàn)樵谀闼伎妓鼤r(shí)，會(huì)發(fā)現(xiàn)在這個(gè)巨大的、混亂的、漫無邊際的模型中實(shí)際存在著多種語言。因?yàn)檫@樣或那樣的錯(cuò)誤，團(tuán)隊(duì)常常會(huì)將全新的軟件產(chǎn)品變成一個(gè)所謂的大泥球。

• 總會(huì)發(fā)生
  對(duì)于隨著公司的成長(zhǎng)而不斷成長(zhǎng)的軟件系統(tǒng)來說，走到這一步是遲早的問題。而走到這一步只取決于團(tuán)隊(duì)的技術(shù)能力，團(tuán)隊(duì)的技術(shù)能力好一些這個(gè)時(shí)刻會(huì)晚到一些，技術(shù)能力弱一些這個(gè)時(shí)刻會(huì)早到一些。

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

對(duì)于限制業(yè)務(wù)發(fā)展、代碼無法維護(hù)的問題是怎么發(fā)生的？有哪些解決策略？以及具體怎樣解決這些問題？將會(huì)在后面逐步進(jìn)行討論。

問題原因

一個(gè)有幾年沉淀的公司來說都面對(duì)著同樣的問題，技術(shù)已經(jīng)制約了業(yè)務(wù)的發(fā)展，原來可以很快上線的功能到現(xiàn)在很難上線，上線了也經(jīng)常有很多問題。隨著一個(gè)軟件系統(tǒng)經(jīng)過多年的發(fā)展，經(jīng)過多個(gè)不同開發(fā)人員的手之后變得難以維護(hù)，難以迭代更新。這種問題在有幾年歷史的公司中非常常見，而這種公司基本上沒有辦法解決這個(gè)問題。

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

• 如果發(fā)生這種問題，代表公司的技術(shù)水平有限；
  對(duì)于技術(shù)水平的有限是在業(yè)務(wù)的持續(xù)演化過程中未能將技術(shù)實(shí)施計(jì)劃、設(shè)計(jì)落實(shí)到具體的工作中，或是因?yàn)楦緵]有技術(shù)實(shí)施計(jì)劃導(dǎo)致的。這說明整體公司的技術(shù)水平有限，因?yàn)楣局腥魏稳硕嘉茨芴岢霾⑽唇鉀Q這個(gè)問題。
• 如果發(fā)生這種問題，代表公司的從業(yè)人員能力有限；
  而從業(yè)人員能力預(yù)示著一個(gè)公司遇到這類問題的時(shí)間是長(zhǎng)是短，人員能力好一些則公司遇到這類問題的時(shí)間會(huì)長(zhǎng)，人員能力弱一些則在很快的時(shí)間內(nèi)就會(huì)遇到類似問題。
• 能嚴(yán)重到這種地步代表著公司整體的監(jiān)管能力有限。
  監(jiān)管能力說明公司對(duì)與業(yè)務(wù)和團(tuán)隊(duì)的管控力，如果遇到這樣的問題，也說明公司對(duì)于團(tuán)隊(duì)和業(yè)務(wù)的管控能力都不足。

要弄懂這個(gè)怎么解決，就必須明確問題是怎么產(chǎn)生的。并且明確問題所在之后才可以針對(duì)問題制定解決方案。而解決這個(gè)問題不可能一次性解決所有問題，所以最少應(yīng)該朝著規(guī)避這些問題的方向前行。這里總結(jié)的問題都經(jīng)過了抽象，并進(jìn)行進(jìn)一步解釋。但為了保護(hù)作者所在公司的利益，不對(duì)具體問題進(jìn)行描述。下面就具體說明其中會(huì)有哪些問題：

四類問題

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

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

1. 數(shù)據(jù)模型未跟著業(yè)務(wù)的發(fā)展持續(xù)演進(jìn)
   在持續(xù)的迭代過程中數(shù)據(jù)模型被各種的業(yè)務(wù)不斷的拉扯，讓其從原來規(guī)整的數(shù)據(jù)模型變成一個(gè)張牙舞爪的數(shù)據(jù)模型。這樣其實(shí)就會(huì)造成各種業(yè)務(wù)錯(cuò)綜復(fù)雜，并且這種方式還會(huì)在不同的業(yè)務(wù)模塊間傳播。
2. 業(yè)務(wù)支持不完善
   在業(yè)務(wù)實(shí)現(xiàn)過程中，對(duì)于現(xiàn)有業(yè)務(wù)抽象不足造成問題在發(fā)展新的業(yè)務(wù)時(shí)都需要進(jìn)行實(shí)現(xiàn)。這樣就造成了不斷的實(shí)現(xiàn)新的業(yè)務(wù)，不斷的為新業(yè)務(wù)造代碼。越來越多的代碼不斷的添加。
3. 業(yè)務(wù)邏輯分散修改困難
   劃分了微服務(wù)之后，新業(yè)務(wù)會(huì)隨著最靠近的服務(wù)進(jìn)行實(shí)現(xiàn)。在實(shí)現(xiàn)過程中總會(huì)遇到業(yè)務(wù)邊界不清晰的問題，這個(gè)時(shí)候就會(huì)隨意的選擇一個(gè)服務(wù)對(duì)業(yè)務(wù)進(jìn)行實(shí)現(xiàn)。而這樣的事情越來越多，就會(huì)發(fā)現(xiàn)業(yè)務(wù)逐漸的分散在不同的服務(wù)中。再加上需要串聯(lián)起來的業(yè)務(wù)，就變成了一個(gè)業(yè)務(wù)分散在不同的服務(wù)中。
4. 業(yè)務(wù)過于龐雜，直接理解
   業(yè)務(wù)模型中的細(xì)節(jié)在持續(xù)的迭代中不斷的增加，而這些增加過程有遺落在每次的需求中。使業(yè)務(wù)細(xì)節(jié)無法使用一個(gè)文檔整體的描述，也無法一次性學(xué)習(xí)。這樣造成業(yè)務(wù)越發(fā)展越大、越發(fā)展越亂。
5. 人員能力要求高
   在上述問題下就變成了，需要的人的能力越高越好。只有能力高的人才可以將業(yè)務(wù)了解，并對(duì)其進(jìn)行修改。

• 知識(shí)體系丟失

作者在《04.軟件產(chǎn)品公司競(jìng)爭(zhēng)力》說明過業(yè)務(wù)知識(shí)是公司的核心競(jìng)爭(zhēng)力。對(duì)于核心競(jìng)爭(zhēng)力的承載是業(yè)務(wù)知識(shí)，而業(yè)務(wù)知識(shí)的承載可能性就很多。例如：工作人員人腦中的知識(shí)、需求PRD中、數(shù)據(jù)庫設(shè)計(jì)中、代碼中、文檔中等。但對(duì)于這些承載形式最終還是要讓團(tuán)隊(duì)內(nèi)部達(dá)成共識(shí)。

1. 業(yè)務(wù)知識(shí)流失殆盡
   隨著人員的流動(dòng)業(yè)務(wù)知識(shí)也在不斷的流失。而團(tuán)隊(duì)成員之間的業(yè)務(wù)知識(shí)傳遞不暢造成從一個(gè)業(yè)務(wù)知識(shí)豐富的人將業(yè)務(wù)知識(shí)流轉(zhuǎn)到低業(yè)務(wù)知識(shí)的人是一個(gè)因人而異的問題。所以，業(yè)務(wù)知識(shí)在沒有其他承載形式的情況下就會(huì)不斷的流失。直至流失殆盡為止。
2. 業(yè)務(wù)知識(shí)沉淀不足
   現(xiàn)在很多軟件過程都不推薦使用文檔的形式進(jìn)行需求的管理。而且現(xiàn)在軟件研發(fā)人員的文檔編寫能力都很弱。導(dǎo)致幾乎沒有文字資料可以反應(yīng)業(yè)務(wù)模型的情況。有文字資料也不能很好的描述一個(gè)模型。
3. 業(yè)務(wù)知識(shí)獲取困難
   業(yè)務(wù)知識(shí)散落在不同的地方，所有的PRD都是針對(duì)迭代需求進(jìn)行編寫的。而針對(duì)業(yè)務(wù)模型進(jìn)行描述的文檔在沒有業(yè)務(wù)驅(qū)動(dòng)的情況下是不會(huì)被編寫的。所以一個(gè)業(yè)務(wù)模型的規(guī)則分散在不同的文檔中，而且還有一部分在人們頭腦中的隱含知識(shí)。這樣就造成如果要學(xué)習(xí)業(yè)務(wù)知識(shí)編程很困難的一件事。

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

不斷的向限界上下文中添加概念，而這個(gè)添加的過程又不知道什么時(shí)候結(jié)束。這樣就會(huì)造成在限界上下文中概念過多，關(guān)系過多。而造成大泥球的問題。

1. 設(shè)計(jì)缺失
   重要功能未有技術(shù)設(shè)計(jì)文檔及評(píng)審。注重業(yè)務(wù)可用性，而未考慮技術(shù)設(shè)計(jì)合理性。
2. 監(jiān)管缺失
   重要功能設(shè)計(jì)未受監(jiān)管、實(shí)現(xiàn)過程也未受監(jiān)管。為了追求業(yè)務(wù)快速上線，跳過了監(jiān)管。
3. 治理缺失
   在發(fā)生問題之后不進(jìn)行治理動(dòng)作，而使用修改的辦法去解決問題。再此過程中也會(huì)有業(yè)務(wù)治理工具缺失、技術(shù)治理工具缺失的問題。

• 能力體系建立能力欠缺

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

1. 半拉子工程
   為了快速的試錯(cuò)，而建立的系統(tǒng)。建立起來之后是不是就不管了？建起來之后具體怎樣淘汰？怎樣從mvp到真正產(chǎn)品階段？對(duì)于一個(gè)系統(tǒng)的生命周期管理不進(jìn)行管理造成問題。

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

3. 公共服務(wù)維護(hù)力度不夠
   因?yàn)榻M織變更造成業(yè)務(wù)重新劃分，但提供公共能力的服務(wù)永遠(yuǎn)會(huì)落在兩個(gè)團(tuán)隊(duì)之間不管的地帶。這樣的服務(wù)對(duì)于兩個(gè)團(tuán)隊(duì)來說都不是自己的業(yè)務(wù)核心那么就以為這不會(huì)有專門的規(guī)劃去完成這部分的維護(hù)。

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

解決策略

遇到了問題不要退縮而應(yīng)迎難而上，而且要解決根本性問題才對(duì)問題有意。如只是解決表面問題下回總是還會(huì)遇到類似問題。只有持續(xù)改進(jìn)才能真正的解決問題。

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

• 約束
  上一章節(jié)說明了具體的問題，而解決這些問題還有一些限制。這因?yàn)檫@些限制導(dǎo)致解決問題的難度大大的增加。故這些約束也是解決問題的前提。

  1. 盡量少影響現(xiàn)有業(yè)務(wù)
  2. 盡量可以利用原有數(shù)據(jù)
  3. 提供完善的中臺(tái)能力
  4. 提供演進(jìn)方法

• 方法
  基于重構(gòu)還是基于重寫去完成服務(wù)治理？根據(jù)上面的約束可以很容易的得出結(jié)論。
  

• 業(yè)務(wù)模型
  團(tuán)隊(duì)中每個(gè)人認(rèn)為的業(yè)務(wù)模型都是不一樣的，所以需要通過共識(shí)的方法將所有的人的模型達(dá)到共識(shí)。
  

• 實(shí)現(xiàn)方法
  原先一個(gè)接口中包含的業(yè)務(wù)過多，需要將業(yè)務(wù)拆分成不同的接口。以原子化的方式提高接口的通用能力。
  

解決問題

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

• 按照業(yè)務(wù)場(chǎng)景梳理所有業(yè)務(wù)
  通過場(chǎng)景的信息建立對(duì)于場(chǎng)景下業(yè)務(wù)模型的知識(shí)?？梢愿玫氖崂沓鰳I(yè)務(wù)模型的規(guī)則。

• 制定中臺(tái)實(shí)施規(guī)范
  通過規(guī)范去建立規(guī)范的平臺(tái)。例如：服務(wù)平臺(tái)整體設(shè)計(jì)、知識(shí)庫梳理、基礎(chǔ)服務(wù)平臺(tái)接口規(guī)范、基礎(chǔ)服務(wù)平臺(tái)質(zhì)量規(guī)范、基礎(chǔ)服務(wù)平臺(tái)日志規(guī)范、基礎(chǔ)服務(wù)平臺(tái)異常規(guī)范、基礎(chǔ)服務(wù)平臺(tái)工程規(guī)范等。

• 進(jìn)行服務(wù)治理
  通過梳理與遵循規(guī)范對(duì)服務(wù)進(jìn)行治理。例如：對(duì)服務(wù)進(jìn)行拆分和下線、減除同層橫向依賴、建立補(bǔ)償機(jī)制、剪除第三方依賴等。

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

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

  1. 數(shù)據(jù)化
  2. 可視化
  3. 標(biāo)準(zhǔn)化
  4. 體系化

例如：研發(fā)體系中事件通知機(jī)制建立、分布式任務(wù)調(diào)度、服務(wù)間通信機(jī)制、ID生成器、文件存儲(chǔ)服務(wù)、日志服務(wù)、分布式事務(wù)管理、調(diào)用鏈管理、限流、降級(jí)、熔斷、特性開關(guān)、QRCode，運(yùn)維體系中K8s、彈性伸縮、發(fā)布方法（藍(lán)綠或灰度）、自動(dòng)恢復(fù)、故障預(yù)案

總結(jié)

對(duì)于解決這類問題有兩個(gè)最重要的問題：

1. 冰凍三尺非一日之寒
   對(duì)這類問題需要有耐心去處理，如果想著處理一段時(shí)間就會(huì)將這類問題處理好。根據(jù)墑增原理，如果一個(gè)系統(tǒng)不經(jīng)過外部作用永遠(yuǎn)都會(huì)趨向于無須。
2. 不積跬步無以至千里
   有真正的投入才有真正的收獲。對(duì)于解決這類糾纏不清、難于理順的問題來說，需要拖入的不止時(shí)間，還需要精力的投入。正面面對(duì)這個(gè)問題，問題才可以得到解決。

對(duì)于看完上面內(nèi)容的讀者來說，作者在這里給出的終極路徑只有一條：整體設(shè)計(jì)，漸進(jìn)式重構(gòu)，漸進(jìn)式上線。

感謝

感謝在這個(gè)過程中幫助過我們的人們。