如何做技術設計

做業務的開發們，幾乎都有一個做架構的心，好的業務開發者不僅要能做好業務，更要能做好業務架構。在現實中我們總會遇到大大小小的需求，那我們應該怎麼在滿足業務的同時又能作出很好的技術設計呢。

1. 什麼是好的技術設計

好的技術設計應該很清楚的表達了：

• 要解決的問題
• 解決方法
• 各種解決方案的優缺點對比
• 如何實施

2. 要解決的問題

要解決的問題，其實就是需求是什麼。很多人覺得提需求是產品經理的事情，和開發沒有什麼關係，開發人員只要寫程式碼就可以了，實則不然。產品經理提出的需求和開發清楚理解要解決的問題，還是有一段距離的。

最簡單的產品經理提出需求：為使用者提供一個登入介面，可以在APP和微信上使用，同時能夠防止機器人自動註冊。

2.1 拆解產品需求

說到產品需求，就想起很多網上和工作中遇到的同事在吐槽產品經理，幾乎都是在吐槽產品經理奇葩的需求和混亂的邏輯。我覺得出現這種需求卻能進入開發階段，作為開發人員也是有責任的。

我一直任務開發人員是要參與到產品需求中去的，這個在程式設計師的業務觀中也有詳細的闡述，這些是題外話。

一般產品經理提出的需求在技術人員來看都缺少足夠的細節，這種時候需要針對產品需求進行拆解，將需求拆解為更小的需求，確認其中的細節。例如針對登入介面的需求就可以劃分為使用者登入介面的基本邏輯和防機器人自動登入/註冊的兩個子需求。

2.2 挖掘潛在需求

針對上面的兩個子需求，我們繼續探究一下其中的潛在需求：

• 使用者登入基面的正常邏輯裡面需要確認介面應該是什麼樣，在不同平臺上的樣式有哪些差異。是否提供微信登入、微博登入、和qq登入等第三方登入平臺的登入。
• 防機器人：使用何種方式防止機器人自動登入和註冊，使用驗證碼還是使用簡訊驗證碼，不同驗證碼方式有哪些樣式需求。

這其中的很多細節都是隱含的，有些是產品經理自己能想到的，有些是產品經理模糊有個印象的，有些可能壓根就沒有想到的，這時候需要技術人員一一確認細節，補充豐富需求。

2.3 未來可能擴充套件的需求

針對使用者登入這個需求，未來可能需要，在使用者登入的時候將使用者的登入上下文引數記錄下來，如使用者登入ip、登入平臺、微信登入時的id資訊等，並將這些作為使用者的特徵資訊記錄下來並廣播出去，供其他業務模組做邏輯判斷的條件之一。

比如，未來可能針對微信端登入的使用者，給這部分使用者發抵用券等行為。

2.4 確定需求

拆解並細化了產品需求，但並不是所有的需求都要在這一次實現，需要最後跟產品確認這一次需要實現的需求。

確定需求的過程時常成為和產品經理PK的過程，在PK的過程中最重要的是產品的價值和實現的成本，在這兩方面獲得一個平衡。以這個需求為例，微博登入相比微信登入就不是一個很有價值的需求，針對這種需求如果時間太緊就可以PK掉了。

確認了需求，我們的技術設計也就完成了一半。 這樣說來一些技術人員可能會覺得有些誇張，但實際工作中，不同的需求真的可能完全改變技術方案，——比如在關於微信的一點思考文中，提到Slack和微信關於聊天記錄的不同而導致技術上實現成本大增，且實現重點都會發生很大的變化。

為了便於後面討論，我們例子中的產品需求定位下來只提供使用者登入，和簡訊驗證碼驗證。

3. 解決方案

3.1 業務領域的劃分

現在的技術大趨勢是採用服務化的方式實現業務，正確劃分業務領域也是實現服務化基礎之一。

現在微服務的概念越來越火，服務按照什麼維度劃分才算是“微”，到現在還沒有什麼標準，不同的實踐會有適合自己的劃分方式；按照業務領域劃分服務，可以保證一個服務能夠提供一個業務領域的支援，更利於業務管理和服務規劃。同時微服務也是一種運維概念，將每個微服務單獨部署，但這種方式會導致機器很多，對運維是一個巨大挑戰，在遇到線上問題時也是一種巨大的挑戰。因此按照業務領域來組織更細粒度的服務，如訂單專案中包含建立訂單服務、訂單查詢服務和訂單修改服務等，做統一發布管理。

業務領域劃分，首先需要從需求角度來分析。如例子中的需求主要包含使用者登入和簡訊驗證碼兩個方式。

• 從業務角度來看，其使用場景是使用者，從使用場景來說更適合在使用者服務上，細分下來可以劃分到使用者登入服務；簡訊驗證碼在這個需求的使用場景，物件導向也是普通使用者，在這個需求裡來看，劃分到使用者服務領域沒有什麼大的問題。
  但是長遠來看，簡訊驗證功能不僅僅會用在使用者登入，也可以用在商戶登入、使用者註冊、使用者修改密碼、使用者領券驗證等場景，面向的物件也不單單是普通使用者，可能有商戶等等。因此長遠來看簡訊驗證劃歸到使用者服務裡是不合適的。
• 劃分業務領域，不單單要從業務角度，還要從系統規劃角度來分析：
  例如這裡的簡訊驗證服務，因為會出現多個複用的場景，且其業務領域更偏重於驗證，因此將驗證服務與使用者登入服務獨立，使用服務呼叫的方式來實現複用，更便於以後的系統發展。

實際專案中劃分業務領域不會像例子中那麼界線分明，專案中的業務領域相互有包含關係，業務邊界有交叉甚至有相似之處，但從業務和系統的角度深入分析，才能慢慢釐清其中的關係。

3.2 資料模型

業務領域模型和資料模型共同構成了系統業務模型。資料模型是資料庫系統的核心和基礎，在設計中使用E-R圖的方式來展示資料模型。

業務模型抽象出來之後，我們的資料庫表的設計也就基本有出來了，只要再根據業務需求進行合理的欄位冗餘和索引設計就形成了基本的資料表。為了應對高併發需求，資料庫會進行分庫分表的處理；前文說道的業務領域劃分，在資料表上就是垂直分表的體現。不過資料庫的分庫分表是一個很複雜的話題，可以參照分庫分表的幾種常見形式以及可能遇到的難題。

3.3 服務關係

釐清了業務領域和業務模型，各服務之間的依賴關係也就非常清晰了。在本文的例子裡，使用者登入服務直接依賴簡訊驗證服務。在技術設計中，不單單需要釐清本次需求涉及到的服務相互關係，還需要理出受影響服務的關係，避免因為新增業務而打亂服務之間的關係。

服務模式在我們需要什麼樣的微服務中有更詳細的闡述。

3.3 介面設計

關於api設計文章已經太多了，比如api雜談、 RESTful API 設計指南 和 RESTful API 設計最佳實踐 ，都已經比較好的介紹了API設計時需要注意到的問題。

但是在技術設計中，介面設計應該是自然而言的過程，很多時候api設計也並不一定是必須的；真正在實施過程中，api的定義不可避免的會出現微調。
幾個api設計的坑點：

• 提供適當的批量查詢介面。比如批量查詢使用者資訊等這種基礎性的查詢。
• 服務在介面層有自我保護。如批量查詢介面，需要控制批量查詢的規模，過大規模的查詢不單單會對自身系統造成很大的壓力，在資料傳輸過程中也會大量佔用網路頻寬。
• api根據使用業務場景分類。比如現在電商中時常使用的立減，在展示測的立減展示服務和在支付時的使用立減服務，就是兩個不同的使用場景。不同的使用場景對服務的要求是完全不一樣的，立減展示更多偏重於資訊展示，同樣是要請求立減金額，在實現上可以使用快取，也能容忍一定程度的資料金額不一致；但在立減使用場景下，在請求立減金額時卻需要嚴格的校驗使用規則，且需要獲取實時的立減金額。

3.4 業務流程Demo

到此為止，系統的整體已經完成了，這時候應該已經能夠滿足業務需求了，可以根據實際中的業務流程來實驗一下我們的系統了。

業務流程demo可以採用UML時序圖的方式來檢驗，系統中每個流程跑下來，就可以看到對每個介面的呼叫情況和對資料庫的訪問情況。

4. 實施方案

有了業務系統設計，剩下的就是要怎麼實施了。實施中會牽涉到參與開發人員、具體的時間節點已經模組劃分等，這些和每個開發團隊自身情況非常相關，在這裡不再多說。這裡主要說說系統的上線方案和回滾方案。

• 上線方案
  系統如何上線？如果只是新專案上線，那隻要按照專案依賴關係依次上線就可以了。但如果涉及到老介面的修改和線上資料模型的修改，就會牽涉到新舊邏輯相容的問題。灰度上線，需要考慮到新資料舊流程、新資料新流程、舊資料舊流程和舊資料新流程的業務邏輯。
• 回滾方案回滾是上線的逆流程，針對新系統上線的回滾中，只需要關閉入口、沒有新資料進入就可以按照上線順序逆序依次回滾。但針對老介面修改和線上資料模型修改時，同樣需要考慮新資料舊流程、新資料新流程、舊資料舊流程和舊資料新流程的業務邏輯。

打賞支援我寫出更多好文章，謝謝！

打賞作者