注意,這是我的架構實踐心得的第二季的系列文章,第一季有10篇你也可以回顧。
最近我一直在思考幾個問題:
- 業務代碼究竟難不難寫?
- 一直開發業務代碼是不是完全學不到東西?
- 5年+開發經驗的老程序員的價值在哪裡?
- 如何通過面試來區分業務代碼開發的水平?
其實,這幾個問題或多或少是相互關聯的。有的時候大家也會自嘲說,“程序員接手的代碼永遠是爛攤子,然後自己繼續在這個爛攤子上產出代碼,留給又一波後人接手”。十幾年來經歷過十來個公司,我看了不少差的代碼,也看了不少好的代碼,自己產出過垃圾代碼,也帶領團隊實現過一些自認為不錯的代碼。你可能會說,業務代碼就是增刪改查,和框架代碼的難度不能比,完全是機械勞動,其實我覺得不完全是這樣,甚至完全不是這樣,我個人認為寫出能跑的業務代碼不難,但要寫出好的業務代碼其實是挺難的,更重要的是如果系統設計的足夠好,在很長一段時間內系統的可維護性是可控的,只需要簡單擴展即可,如果基礎打的不夠好,那麼項目可能就是一次性項目,下面我列出業務系統我關注的一些點,你想想是不是有道理。
標準化
標準的項目結構
我自己非常注重搭建項目結構的起步過程,模塊的劃分、目錄(包)的命名,我覺得非常重要,如果做的足夠好,別人導入項目後可能只需要10分鐘就可以大概瞭解結構了。
1、有些名詞是約定俗成的,大家一眼就能看出是啥東西的,比如:
- controllers
- services
- configs
- utils
- commons
- jobs
比較重要的是確定先進行分類再分業務,還是先分業務再分類,在代碼裡混用這兩種風格的結構就會很混亂:
- controllers
- order
- user
- jobs
- order
- user
- order
- services
- mappers
- user
- services
- mappers
對於直筒的三層架構的純數據表驅動的代碼我建議第一層是分類,第二層是業務功能:
- 看一眼controllers目錄我們知道項目對外的Api能力
- 看一眼services目錄我們知道項目的邏輯複雜度
- 看一眼mappers目錄我們知道項目的表結構
對於有一些項目,不一定每一個邏輯都涉及到三層架構,數據流量比較複雜,我建議是按照業務功能先來分,下一層視情況也不一定完全是需要按照組件類型分二級目錄,也可以是按功能來分:
- core
- storage
- service
- dispatcher
- engine
- context
- callback
- gateway
- handler
- notification
- sms
- push
對於這種目錄結構一眼望去就能知道大概項目數據流和架構了,core對內,dispatcher做分發的感覺,callback是外部來的回調數據,notification是通知外部的數據流。這種數據流向複雜的項目,使用這種結構會比前一種合理的多,因為我們需要先關注數據流,而不是三層結構的層次,甚至對於core、dispatcher、notification我們知道其實是沒有controller的。
2、有些名詞可能就需要內部有一個統一,比如不同的層次面向數據庫,面向業務,面向UI,面向RPC需要有不同的POJO,我們需要明確一套對應的命名,能明確就好,比如下面的這些POJO我們其實挺難分辨其用途的,需要進行規範,並且放置於匹配的目錄結構中:
- CreateOrderRequest / CreateOrderResponse
- CreateOrderParam / CreateOrderDto
我們可以約定第一組用於服務本身訪問外部(的Rpc服務也好,REST服務也好),第二組用於服務本身對外提供的Web Api,比如:
- controllers
- OrderController
- queryOrder()
- createOrder()
- QueryOrderParam
- QueryOrderDto
- CreateOrderParam
- CreateOrderDto
- rpcs
- UserService
- login()
- register()
- LoginRequest
- LoginResponse
- RegisterRequest
- RegisterResponse
- services
- OrderService
- OrderServiceImpl
- OrderEntity
- storages
- OrderMapper
- OrderModel
總之,雖然可能10+人在維護相同的項目,目錄結構的風格、命名、專用名詞的使用一定要統一。
統一的框架
這個需要在開展項目之前明確下來,我見過有項目中同時使用了Spring MVC和Jersey做Web API,同時使用了Spring Scheduler和Quartz做任務調度。最好是項目開展前明確框架的版本並且搭建好項目腳手架,大概涉及:
- Web API / Web MVC
- Job Scheduler
- Micro Service
- Config Center
- Redis Client
- Data Access
- Entity Mapper
- MQ Client
當然,我們也可以獨立出依賴管理的項目,專門由獨立模塊進行依賴版本管理。最差也要在Wiki上進行明確。
統一的API
如果項目涉及到對外提供API,那麼非常有必要在初期就規範API的框架定義,涉及到:
- 包裝類 Result的定義(見過一個項目用了三種包裝類的)以及遇到錯誤的情況下,Http狀態碼的體現
- 比如這樣的包裝類格式:
public class ApiResult { boolean success; String code; String message; String path; long time; T data; }
我們可以這麼和客戶端的開發來明確:
1、即使遇到錯誤,Http狀態碼還是200,Http狀態碼如果是500或是404的話那一定是網關層面的錯誤了,這個錯誤不是後端服務返回的
2、在Http狀態碼還是200的時候代表收到了後端的返回,前端去按照ApiResult以Json格式反序列化Http Body的報文
3、然後查看success(如果沒success也行,我們可以約定code是200就是成功),如果是success代表後端服務成功處理了請求,如果不成功,則根據後端給的錯誤代碼映射表根據code進行處理或直接提示message中的內容。注意,這裡的success只代表後端是否成功處理了請求,不代表請求代表的業務邏輯是否成功處理。舉一個例子,如果這個請求是異步支付請求,那麼success==true代表前端給的參數都正確,後端正確接受了支付申請,不代表支付成功
4、在success==true的情況下再去解析data中的內容,拿取客戶端需要的信息,還是前面的例子,data裡可以是{"orderStatus":"PROCESSING", "orderId":"1234"},這個才是真正業務邏輯的數據和狀態,success並不代表訂單支付操作就是成功的,也可能是處理中的狀態
所以這是幾個層次的事情,Http Status->ApiResult.status->ApiResult.data.orderStatus
- 加解密規範和簽名規範
- Api的加密解密以及簽名最好在設計的時候就考慮進去,而且要仔細斟酌,否則以後很難變更,特別Api的使用方是客戶端的情況,客戶端很難輕易強更。如果做SAAS服務,建議參考大廠的規範,比如亞馬遜AWS的API規範或阿里雲API的規範,不建議自己造輪子,大廠做的API規範都是經過安全方面的專家深度思考的。
- 版本管理規範(比如Url path路由還是Http header路由)
- 如果使用了老版本的話,是否需要在返回內容中提示新版本的Url、版本號、老版本最後維護時間呢?這個就不展開了
所以統一Api這個事情不僅僅是Api的格式還涉及到安全處理、版本處理、客戶端操作方式等等。對於一些需要服務端驅動客戶端的業務(UI邏輯動態)來說,我們可以定義一套更復雜的ApiResult,讓服務端告知客戶端這個時候應該是提示還是跳轉還是返回等等。
統一的源碼工作模式
現在大家都使用Git,分支如何管理每一個公司(在Gitflow的基礎上)都會略有不同,也需要和大家明確:
- 分支的定義(master、develop、release、hotfix、feature)
- 分支命名規範
- checkout、merge request流程
- 提測流程
- 上線流程
- Hotfix流程
別小這個,雖然這個和代碼質量和架構無關,但是梳理清楚可以:
- 提高開發和測試的工作效率,人多也亂
- 減少甚至杜絕代碼管理導致的線上事故
- 讓項目管理者和架構師可以明確什麼代碼現在在哪裡
- 方便運維處理發佈和回滾
- 讓項目的開發可以靈活適應多變的需求
容錯性
見過一些項目在實現業務代碼的時候是不考慮任何異常處理、事務處理、鎖處理的,在流量小無併發的情況下,這些項目不容易爆發出嚴重的問題,基本能用。但是對於高併發的項目或將來可能會高速發展的項目,如果不考慮這些問題會死的很難看。
我們來想一下,如果現在在設計一個訂單服務,如果因為網絡問題、併發問題導致數據錯亂、服務中斷的可能在千分之一,如果一個業務一天只有1000次請求,1天才遇到這樣1次問題,即使遇到了問題用戶也不一定會來反饋,即使來反饋往往客服也能通過後臺取消訂單等操作來處理,這個問題不會爆發出來,如果一天的單量是1000萬,那麼每天可能就會有10000單異常的訂單,這個可能就超過了客服的處理能力了。
很少有項目真正100%完全做好了所有細節,只不過往往是因為量小得不到大家的重視罷了。但我們想一下,如果遇到數據庫或中間件級別大規模故障的情況下,如果一致性處理的不好,那麼數據庫恢復後可能會留下一大堆異常數據需要修復,如果處理的好,業務數據不會錯亂,數據庫恢復後業務馬上可以恢復。在遇到事故的時候,系統這方面的設計功力就體現出來了。
一致性處理
在實現代碼的時候需要考慮如下事情:
- 本地事務處理:見過一些代碼完全不考慮事務,或者是隻是知其然使用@Transactional,但是方法內部完全catch了所有異常的情況
- 事務包含的方法塊
- 嵌套事務、事務傳播
- 什麼時候遇到什麼異常應該回滾
- @Transactional是否真正生效了?
- 外部服務調用的事務問題
- 調用外部服務出現異常的時候,本地事務怎麼處理
- 調用的外部服務是否允許重試(冪等調用)
- 調用外部服務出現未知結果後,怎麼進行補償
- 補償是否有上限,是否存在死信數據卡死補償的情況?
- 如果有2+外部服務連同本地數據庫存儲都需要有事務性,怎麼實現
- 數據重複和順序問題
- 先本地事務提交還是先調用外部接口(如果先調用外部接口,可能會遇到外部回調的時候本地事務還沒提交找不到數據的情況)
- 從MQ收到的消息順序問題怎麼解決?
- 重新入MQ的延遲消息或重試消息亂序是否會有問題?
- 對外提供的Api或回調方法是否支持冪等?
- 鎖的問題
- 哪個層面做鎖?服務層分佈式鎖還是數據庫層面鎖?
- 樂觀鎖還是悲觀鎖?
- 你確信你的Redis鎖方案是可靠的嗎?
- 你是否知道多少請求再排隊等待,又是為什麼?
這些要做好真的很難,每一步都需要認證考慮,但是很遺憾見過的很多具有複雜業務的代碼,在Service中一連串調用了N個外部服務進行寫操作,方法內也實現了N個表的寫操作,即不考慮外部服務的事務和補償問題,本地也沒有事務控制,出了錯只是打印了堆棧然後客戶端看到的是一個服務器忙。
異常處理
異常處理不僅僅是狹義上遇到了Exception怎麼去處理,還有各種業務邏輯遇到錯誤的時候我們怎麼去處理。
就拿記日誌這一件事情來說:
- WARN和ERROR的選擇需要好好考慮,WARN一般我傾向於記錄可自恢復但值得關注的錯誤,ERROR代表了不能自己恢復的錯誤。對於業務處理遇到問題用ERROR不合理,對於catch到了異常也不是全用ERROR。
- 記錄哪些信息,最好打印一定的上下文(用戶Id、訂單Id、外部傳來的關鍵數據)而不僅僅是打印線程棧。
- 記錄了上下問信息,是否要考慮日誌脫敏問題?可以在框架層面實現,比如自定義實現logback的ClassicConverter
我們知道catch到了異常或遇到了業務錯誤,我們除了記錄日誌還有很多選擇,也需要認真考慮什麼時候應該做什麼:
- 直接返回
- 拋出異常
- 重試處理
- 恢復處理
- 熔斷處理
- 降級處理
- 甚至關閉業務
這又涉及到了彈力設計的話題,我們的系統往往會對接各種外部服務、Api,大部分服務都不會有SLA,即使有在大併發下我們也需要考慮外部服務不可用對自己的影響,會不會把自己拖死。我們總是希望:
- 儘可能以小的代價通過嘗試讓業務可以完成
- 如果外部服務基本不可用,而我們又同步調用外部服務的話,我們需要進行自我保護直接熔斷,否則在持續的併發的情況下自己就會垮了
- 如果外部服務特別重要,我們往往會考慮引入多個同類型的服務,根據價格、服務標準做路由,在出現問題的時候自動降級
架構設計
表
表的設計和Api的定義類似,屬於那種開頭沒有開好,以後改變需要花10x代價的,我知道,一開始在業務不明確的情況下,設計出良好的一步到位的表結構很困難,但是至少我們可以做的是有一個好的標準:
- 統一的附加字段,create_time,update_time,version等
- 表的命名標準,比如[domain]_[tablename]_[tabletype]
- 字段類型、長度標準
- 雖沒有外鍵,但是外表關聯字段和主表字段的命名標準
- _id還是_no等字段命名的區別
除了標準,儘可能需要結合業務以及業務可能的擴展思考一下:
- 1:N的可能性,是有1就足夠了,還是一開始就要設計1:N的層次關係
- 如果表字段可能會很多,業務變化多,是否考慮1:1甚至1:N的擴展表,把擴展字段從主表分開
- 表的領域職責,表可能也會分上游、中游、下游,什麼字段應該在哪裡太重要了(我覺得表的領域相當於之前提到的項目結構中的包的分類,這個最好一開始定義清楚)
- 關聯表字段冗餘冗餘到什麼程度,冗餘字段的同步
- 枚舉的維護方式,是否考慮字典表?
對於表結構文檔,我覺得列出字段類型、長度、說明是不夠的,如果能結合業務代碼梳理清楚下面這些,那這個文檔就是真正有價值的表結構文檔:
- 記錄由哪個業務模塊創建
- 數據重要程度
- 數據歸檔方案
- 字段數據源頭
- 字段會由誰更改
- 字段可能會在哪裡緩存
設計模式
我想90%的業務項目都是所謂的三層結構,Web層處理參數調用Service層做Db層的聚合,Db層基本就是代碼生成或Orm框架補充少量的手寫SQL。對於這樣的項目,大部分人認為是沒有設計的,也不需要設計。我認為那是因為沒有好好思考:
- 在我們寫下if-else的時候,我們就可以考慮使用抽象類+具體實現類的方式來替代
- 在實現層次化業務處理的時候,就可以考慮使用Filter或職責鏈模式來實現
- 在封裝外部Api的時候與其每次都寫一套解析邏輯,我們是否考慮進行動態封裝呢
- 在數據改變後我們要記錄改版軌跡,與其複製粘貼是否考慮過發佈訂閱模式
說白了就是利用各種設計模式和OO思想,來儘可能在業務變化需要擴展的時候:
- 只是新增代碼而不是修改代碼
- 儘可能減少重複代碼複製粘貼
- 儘可能讓同類代碼都呆在一起
- 儘可能讓直筒式的代碼有層次
往大了說
在一個公司層面,如果有幾十個,幾百個業務項目,我們看這個公司的技術水平到了什麼程度,我個人認為不僅僅是用了什麼新技術,而是是否:
- 具有統一的開發、服務框架
- 具有統一的運維、監控、中間件、測試平臺
- 具有清晰的縱向領域劃分
- 具有清晰的橫向基礎平臺服務和基礎業務服務
- 具有統一的代碼工作模式
最簡單的一個例子,一個業務從前到後跨10個事業部,100個服務,實現灰度測試,想想這件事情有多難?整個公司層面要實現步調一致的這些東西還確實很難,不僅僅是技術能力的體現,沒有良好的組織架構,人心不齊,恐怕這些無法實現,實現了也無法推廣,推廣了也無法持續……當然,這些已經超出個人能做的了,作為程序員的我們應該從我做起,認真考慮前面提到的這些問題,至少在項目內部做良好的設計。
再來看看文首的問題,你看,雖然只是寫業務代碼,如果要寫的足夠好,必須要了解設計模式、理解各種彈力設計、理解事務、熟悉框架、瞭解中間件原理,怎麼可能學不到東西,要實現健壯的業務代碼,其實很難,要考慮的東西太多了,如果說寫框架我們需要考慮不同的使用方和使用環境,這很難,寫業務代碼我們要考慮到千奇百怪的使用行為,要考慮到層次不起的對接方,這不比寫框架簡單。對於5年+經驗豐富的程序員應當有能力開一個好頭,或者說願意在老代碼上去做一些改變,否則你的價值在哪裡呢?
本文只是展開了一些想到的內容,每一點都有很多東西可以寫,也沒時間一些子展開說太多,這些細節留在今後的文章慢慢展開了。