建站
咨詢
售后
建站咨詢
新聞中心
什么是設計?什么是架構(gòu)?從零開始建立一個新的系統(tǒng)，新寫的每行代碼都可能成為明天的歷史包袱?如何能有效的在遺留代碼上工作?今天，阿里資深技術(shù)專家輝子為我們帶來NBF框架下軟件工程架構(gòu)設計通用方法論，值得細細品讀。
公司主營業(yè)務：網(wǎng)站制作、成都做網(wǎng)站、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出荔灣免費做網(wǎng)站回饋大家。
Note：本文討論的是基于服務化前提下的通用軟件工程架構(gòu)方法論，并未涉及到微觀設計或架構(gòu)的具體細節(jié)。
前言
即使代碼多年的人都會對這兩個問題有點蒙圈：什么是設計?什么是架構(gòu)?
從單詞上看：設計是Software Design，架構(gòu)是Software Architecture;分別對應的作者是：Designer和Architect：
- Architect都是Designer，但Designer未必是Architect。正如所有的架構(gòu)設計都是設計，但設計未必是架構(gòu)設計;
- Design關(guān)注微觀代碼(inside component)，Architecture關(guān)注宏觀軟件結(jié)構(gòu)(between components);
- Architect應該都是從Designer成長起來的。畢業(yè)了用code編寫軟件;成長了用ppt設計軟件;
- 只會用ppt設計，但代碼寫得不好的Architect都是假的Architect;
- Architecture里聽到比較多的詞語：Serverless、FAAS、Microservice、multi-layer、Event driven、OSGI、NBF......
- Design里聽到比較多的詞語：SOLID、 DDD、正交設計、Design Pattern;
- 搞不清SOLID，也不可能把軟件的層次分好，也無法理解什么是OSGI的價值;
- 好的Designer是通往好的Architect的必經(jīng)之路。
服務化架構(gòu)的基本原則
??
??
New System
從零開始建立一個新的系統(tǒng)，有幾個特征：
- 歷史包袱小
- 上下文簡單
- 設計的約束小
- 新寫的每行代碼都可能成為明天的歷史包袱
由于調(diào)用方還沒有，新系統(tǒng)可以比較完美的執(zhí)行我們預想的架構(gòu)設計，但是切記，最后那行才是最重要的那行：不要讓今天的代碼成為明天的歷史包袱，新的每行代碼都在書寫歷史。
上圖的1，2，3，4代表新建系統(tǒng)的順序：
- 由“相”抽象出“心”：先思考，那么多的業(yè)務場景下“相”，共同的特征“心”是什么。并反向用更多的相去驗證心。
- 將“心”具象成領域模型：關(guān)注領域模型(Domain Model)，解耦數(shù)據(jù)模型(Persistence Model)：將TUNNEL SPI化。
- 將領域模型中的依賴SPI化：解耦對外部系統(tǒng)的依賴，反轉(zhuǎn)依賴控制權(quán)。
- Mock所有spi實現(xiàn)，確保“心”領域模型包裹的單元測試完全通過
- 實現(xiàn)TUNNEL BUNDLE：設計數(shù)據(jù)模型(Persistence Model)，關(guān)注“存”，“取”不關(guān)注領域模型。
- 實現(xiàn)依賴SPI適配BUNDLE：連接真實依賴服務。
- 包裝domain service：模型相關(guān)，業(yè)務無關(guān)。
- 根據(jù)業(yè)務需求組合/編排domain service成為scenario bundle或者業(yè)務SOP。
Working on legacy
對于一個軟件工程師來講，寫代碼最痛苦的事情莫過于coding on legacy，但同時又給了我們各種說辭：
- 這些代碼太爛了，改起來太費勁【需要更多人】
- 這事做不到，因為以前系統(tǒng)架構(gòu)問題導致的【責任不在我】
- 經(jīng)過我的修改，現(xiàn)在已經(jīng)好很多了，工單數(shù)量大批下降【我功勞顯著】
- 知不知道：接手你代碼的人其實也在重復說上述3件事情
如何能有效的在遺留代碼上工作，業(yè)內(nèi)有本非常不錯的書，叫"Working Effectively with Legacy Code",值得精讀：
??
??
圖片來源：書籍《Working Effectively with Legacy Code》
所以我這里的標題可能不準確，我要討論的更多是"遺留代碼的重構(gòu)"，什么時候我們開始討論需要把現(xiàn)有系統(tǒng)重構(gòu)：
- 代碼確實腐化到無法正常維護，或者新加一個需求代價很大;
- 目前代碼的技術(shù)架構(gòu)滿足不了下一步業(yè)務的發(fā)展;
- 很多特性已經(jīng)下線作廢，卻跟有用的代碼藕斷絲連;
- 業(yè)務邏輯隨著發(fā)展分散到不同的應用里，界限不清;
- 專家級的未雨綢繆，著眼未來的規(guī)劃和新技術(shù)的應用;
- 換老大了，需要立新的flag。
架構(gòu)的基本原則依然是上面那幅圖。但上下文的不同，我們的發(fā)力點和優(yōu)先級有明顯的區(qū)別。阿里整個體系里的依賴關(guān)系錯綜復雜，要對阿里環(huán)境下的系統(tǒng)做重構(gòu)是件絕對謹小慎微的事情。為了完成在這么復雜體系下的架構(gòu)及代碼重構(gòu)，我們必須有條不紊的分離關(guān)注點以及一如既往的堅持軟件卓越。
聚焦與收斂上游調(diào)用
??
??
解耦下游依賴
??
??
以服務為單位切換
??
??
老系統(tǒng)下線
經(jīng)過一步一步的分解，legacy系統(tǒng)已經(jīng)完全被重構(gòu)，并且具備隨時切換的準備。這里我給幾個建議：
- 先把老實現(xiàn)作為API的默認實現(xiàn)，新的實現(xiàn)作為老的實現(xiàn)的降級實現(xiàn)，并使用策略分流一部分流量(具體比例跟團隊信心相關(guān));
- 對于有業(yè)務需求變更的部分應盡快實現(xiàn)在新的實現(xiàn)里，并將新實現(xiàn)作為API的默認實現(xiàn)，老實現(xiàn)作為新實現(xiàn)的降級實現(xiàn)，策略應該是即時降級，也就是新實現(xiàn)出現(xiàn)問題立刻降級到老實現(xiàn);
- 運行一段時間沒有問題后，講所有默認實現(xiàn)切換為新實現(xiàn)，并將老實現(xiàn)作為新實現(xiàn)的降級實現(xiàn);
- 其實這時就算所有切換完畢：老實現(xiàn)可以永遠作為新實現(xiàn)的降級實現(xiàn)，也就是只要我升級一次服務，上一次成功版本就可以作為這次的降級實現(xiàn)，這樣，線上問題回滾就是秒級的。
總結(jié)
本文基于借助NBF提供的遠程多態(tài)，服務編排等能力下基礎資料，商品，組網(wǎng)等系統(tǒng)新建，重構(gòu)的經(jīng)驗及方法論總結(jié)。僅供遇到架構(gòu)重構(gòu)，解耦等問題困擾的技術(shù)團隊參考。
當前文章：如何避免新代碼變包袱？阿里通用方法來了！
本文地址：http://www.5511xx.com/article/cojeohd.html
