1.3 服務端開發核心流程

軟件開發一般是以項目為單位進行的。從技術的視角看，一個軟件項目從提出需求到落地，通常要經歷需求評審、系統設計、開發、聯調、測試、驗收、上線等諸多環節，如圖1-13所示。

服務端開發是核心崗位，僅僅具備“開發運行于服務器端的程序”的能力是遠遠不足以勝任的。在頭部互聯網企業對該崗位的職責定義中，普遍要求服務端開發工程師需要具備業務分析、產品設計、架構設計、技術攻關、團隊協作、文檔編寫、系統維護等綜合能力。讀者可能會認為如此高要求完全是“內卷”的結果，但從筆者的工作經驗來看，這些能力其實是服務端開發的不同階段所需的，具體而言，服務端開發可分為需求分析、抽象建模、系統設計、數據設計、非功能性設計、編碼實現及發布運維等階段，每個階段都需要相應的能力作為支撐，核心流程如圖1-14所示。

1.3.1 需求分析

在實踐中，根據業務復雜度的不同，有時候可能只需要畫個簡單的流程圖便可梳理清楚系統，但是復雜系統的設計則困難得多。以12306為例，2020年春運期間高峰日點擊量達1495億次/天，約170萬次/秒，單從點擊量數據看，項目的設計、實現就不容易，在此，讀者不妨設想一下，如果你是12306項目的設計師，你準備如何設計這個系統呢？你的設計方法是怎樣的？

在筆者看來，不論采用何種設計方案，首先需要明確一個問題：你了解鐵路票務嗎？如果根本不了解鐵路票務，那又怎么可能設計出滿足鐵路票務業務需求的系統呢？在實踐中，設計并開發一個軟件系統并不單純是技術層面的問題，首要任務是深入了解其業務。而要了解業務，則必須要經過需求分析。

（1）需求分析的定義

需求分析也稱為軟件需求分析、系統需求分析或需求分析工程，是軟件工程師經過深入細致的調研和分析，準確理解業務方和產品經理的具體要求，將非形式化的需求表述轉化為完整的需求定義，從而確定軟件系統必須做什么的過程。

需求分析是軟件計劃階段的重要活動，也是軟件生存周期中的一個重要環節。該階段是分析系統在功能上需要實現什么，而不是考慮如何去實現。需求分析的目標是把業務方和產品經理對待開發軟件提出的“要求”或“需要”進行分析與整理，確認后形成描述完整、清晰、規范的文檔，確定軟件需要實現哪些功能、完成哪些工作。

（2）需求和業務的關系

很多工程師認為理解需求就是理解業務，這是一種誤解。需求其實是業務經過產品經理消化后的產物，通常已經經過產品經理的演繹和拆解，因此并不是業務本身。當然，了解的需求越多，對業務的全貌就越清楚。那么，什么是業務呢？業界對“業務”有多種定義，但其主要思想基本一致：業務是指商業（或非商業）組織及其運作的活動流程。直白點說，業務就是一系列人通過一系列活動完成某一任務的過程，業務可大、可小、可拆分，比如支付寶的支付業務，往下可拆分為花唄、余額寶、銀行卡等。

（3）為什么要進行需求分析

在互聯網行業，一個完整的需求通常參與者眾多，包括業務方（如運營）、產品經理、服務端開發、客戶端開發、測試、交互、視覺、項目管理等人員。正如上文所述，需求的本質是業務方原始訴求經過產品經理演繹、拆解的產物，一些問題由此而生：需求文檔所述與業務方的核心訴求可能不一致；產品設計難免存在遺漏和缺陷。因此，作為工程師，拿到需求后并不是立即投入研發，而是進一步分析需求。

（4）需求分析階段需要厘清的內容

?業務背景：即業務當前狀況及對業務發展、變化起重要作用的客觀因素。例如，某虛擬電商平臺用戶數量達2億，客單價約140元。

?業務問題：即結合業務當前狀況和客觀因素，分析與業務預期之間的差距。接續上面的例子，用戶規模、客單價都是當前的狀況，而經過調研發現，競爭對手的客單價已達200元。為什么差距這么大呢？業務分析認為，關鍵因素是自身平臺營銷活動數量少于競爭對手，這就是業務面臨的問題。

?業務訴求：即業務想到達到的目標。接續上面的例子，訴求是豐富營銷活動模式，增加活動頻次，比如每月開展一次“滿減活動”（如“每消費滿50元減5元”），促使用戶湊單，從而提升客單價。

?業務價值：即預期可以產生的收益。接續上面的例子，營銷活動促進客單價提升，由GMV（Gross Merchandise Volume）=成交用戶數×客單價可知，客單價提升，GMV增長，進而實現利潤增加。

?產品方案：即基于業務訴求形成的產品方案。接續上面的例子，支持如“滿50減5”的營銷策略，需要一個運營后臺，支持運營靈活地配置營銷活動（滿減門檻、優惠額度、預算控制等），同時須支持將活動定向投放給指定的人群（精細化運營，針對不同的人群投放不同的活動）。

?評估指標：即評估產品落地后實際效果的客觀指標。接續上面的例子，評估指標如GMV、客單價、滿減活動參與用戶數等。

?技術現狀：結合上述內容，站在技術角度初步評估當前技術架構、系統容量、風控能力等是否可支持業務訴求落地和未來發展。

1.3.2 抽象建模

這一階段需要基于需求分析階段的知識儲備，進一步提煉、建立可以刻畫業務本質特征的模型。抽象建模實際上包含抽象和建模兩個部分，由于兩者通常同步進行，因此歸納為抽象建模。

1.抽象

抽象在中文里可作為動詞，也可作為名詞。作為動詞的抽象是指一種行為，這種行為的結果，就是作為名詞的抽象。百度百科上是這么定義抽象的：人們在實踐的基礎上，對于豐富的感性材料通過去粗取精、去偽存真、由此及彼、由表及里地加工制作，形成概念、判斷、推理等思維形式，以反映事物的本質和規律的方法。如圖1-15所示，對現實中的公牛進行抽象，用簡單的線條勾勒出公牛的本質特征（如牛尾、牛角、牛鞭等），抽象牛具備更好的泛化能力，不再局限于具體品種的公牛，而是可以實例化為幾乎所有品種的公牛。

事實上，日常生活中抽象無處不在。例如數字，人類初期并沒有數字這一概念，原始人或許能夠理解3個蘋果和3只鴨子，但他們的腦海里不存在數字“3”這個概念，在他們的意識里，3個蘋果和3只鴨子是沒有任何聯系的。人類進化到一定階段后發現了這兩者之間存在的一種共性，即是數字“3”，于是數字這個概念就逐漸形成了。此后，人們就開始用數字對各類事物進行計數。

軟件開發本身就是一個不斷抽象的過程。軟件工程師把業務需求抽象成數據模型、模塊、服務和系統，面向對象開發時抽象出類和對象，面向過程開發時抽象出方法和函數。換言之，上面提到的模型、模塊、服務、系統、類、對象、方法、函數等，都是一種抽象。由此可見，抽象對軟件開發非常重要。

2.建模

業務需求大都是以具象的現實世界事物概念來描述的，依附于自然語言體系，距離軟件工程非?！斑h”。為了將需求落地，工程師需要開展一系列的工作，其中建模尤為重要。建模的過程實際上就是從業務領域里找出反映業務本質的事物、規則和結構，并將其抽象化，進而描述業務運行的基本原理、交互機制及用戶的首要利益。從某種意義上說，建模的過程就是系統地實施抽象的過程。

目前，服務端開發常用的建模方法主要有3種，即用例建模法、服務建模法和事件建模法，在實踐中需要根據業務場景的特點和復雜度選型。關于建模方法詳見第3章。

1.3.3 系統設計

系統設計又稱為系統架構。在系統設計階段，需要將抽象建模的成果有條不紊地映射到具體的技術實現中，要通盤考慮、權衡取舍。工程師須具備一定的技術深度、技術視野，同時充分理解業務。如果在抽象建模階段做得足夠好，建模方法選型與業務特點匹配，且抽象出的模型可以準確刻畫業務的本質特征，那么系統設計將是一件相對輕松的事情。

1.設計和劃分功能域

在互聯網領域，一些業務的復雜度是非常高的。圖1-16所示為阿里的電商業務摘要架構圖。該架構自頂向下劃分為前臺、移動中臺、業務中臺、PaaS、IaaS，而業務中臺又可細分為會員中心、商品中心、交易中心、支付中心、評價中心和訂單中心，這其實就是一種高層次的功能域設計和劃分。

對于復雜的業務，首先應設計和劃分功能域，以降低復雜度。具體而言，在完成抽象建模后，可基于模型將系統拆分為不同的功能域，各個功能域相互協作，共同實現業務需求。需要特別注意的是，不同功能域之間必須有清晰的職責邊界，同時單個功能域的復雜度不能過高。我們可以將業務中臺的會員中心進一步拆解，劃分為積分、權益、淘氣值等功能域，如圖1-17所示。

2.設計功能域之間的協作

經過多年的發展，互聯網領域的“高增長”時代已經過去，正大步邁入“存量”時代。由于大多數業務已經相當成熟，通用基礎能力亦趨于完善，因此業務需求的復雜度通常不會高到需要步驟1中的設計和功能域劃分。

設計功能域之間的協作，可視為一種“粗粒度”的服務編排。具體而言，借助已有功能域提供的服務，目標功能域（新建或者在已有功能域的基礎上擴展）可以快速實現新的功能，滿足業務需要。在實踐中，功能域之間協作的關鍵在于充分、合理地利用已有公共基礎服務。如圖1-18所示，會員中心的權益投放通常有個性化推薦（算法推薦）和運營定向投放（運營針對特定人群，如新用戶，定向投放特殊權益）兩種策略。這兩種投放策略可以通過不同的功能域協作實現。

3.確定功能域之間的數據邊界

功能域之間的協作設計完成后，整個系統的上下游依賴也就清楚了，接下來我們需要進一步明確功能域之間的數據邊界。以微服務架構為例，一個功能域可作為一個應用，不同功能域之間通過服務調用來協作，對于服務，通常用請求（服務調用方發起請求）和響應（服務提供方響應請求返回結果）的數據模型來描述邊界。

如果有多名服務端工程師（甚至團隊）參與產品需求的開發，在確定數據邊界之后，不同功能域的職責也就進一步明確了，工程師可以專注于其所負責功能域的內部設計和開發。

4.功能域內部設計

通過步驟3，功能域的技術目標得以明確，接下來便是通過設計去實現這些技術目標。在功能域內部，為了降低問題的規模和復雜度，同時增強系統的可擴展性和可維護性，一般采用如圖1-19所示的“分層架構”。

在分層的同時，很自然會產生一些模塊。需要注意的是，在本步驟中雖然通過分層將功能域進一步細化到了“模塊粒度”，但并不涉及模塊實現細節，這是下一個階段要做的事情。

5.詳細設計

詳細設計是系統設計的最后一個環節，對大多數服務端開發工程師而言，這個環節應該是最為熟悉和擅長的，畢竟在一名工程師的職業生涯中，大多數時間都在從事子系統/模塊的設計和開發。子系統/模塊的設計是一種詳細設計，需要從細節層面考量問題，所做的設計用于直接指導開發。在這一步中，設計結果一般包括以下內容。

?相關模型：如領域模型圖、類圖、實體關系圖、數據表清單等。其中領域模型圖一般在抽象建模階段完成，而數據表清單則屬于數據設計范疇。

?上下游交互：大多數業務場景或多或少存在上下游交互，交互一般通過數據庫、接口、消息等方式。如果選擇通過接口交互，須寫明類名、方法名、入參、出參、結果碼等；如果選擇通過消息交互，須寫明消息Topic、Group、消息體結構等；如果選擇通過數據庫交互，須寫明表名、索引、QPS等。

?方案描述：當業務較為復雜的時候，文字描述難以直觀地反映設計方案的細節，也不便于后續評審和實施，因此，一般通過流程圖、時序圖來描述。

需要注意的是，詳細設計環節通常是包含數據設計的，但考慮到數據設計的重要性和復雜性，筆者會進行詳細介紹。

1.3.4 數據設計

談及數據設計，大多數IT從業者的第一反應是數據庫設計。這其實是片面的。事實上，數據設計的內涵非常豐富，數據庫選型、表結構設計、字段設計、索引設計、緩存設計、數據核對、數據監控等都屬于數據設計的范疇。

如圖1-20所示，完整的數據設計一般包含3個環節：領域概念模型設計、邏輯數據模型設計和物理存儲模型設計。不過，落實到具體的業務需求，這3個環節并不是必需的。例如在一些相對簡單的業務場景中，根本不涉及領域概念模型，也無須領域概念模型設計。本節重點介紹一下數據庫選型和存儲方案設計，其他數據設計相關的內容在后文再展開詳細介紹。

1.數據庫選型

目前，常見的數據庫類型如表1-6所示，數據庫類型不同，其特性和適用的場景也存在較大差異。服務端開發工程師需要根據業務場景自身的特點，結合數據庫的性能、存儲成本、容量、一致性、讀寫偏好、穩定性等指標綜合評估選型。

2.存儲方案設計

數據庫選型確定后，接下來需要根據數據庫進一步設計存儲方案。為了便于讀者理解，筆者以MySQL和HBase為例介紹存儲方案設計。如圖1-21所示，對于MySQL數據庫，存儲方案的核心是字段設計和索引設計；而對于HBase，核心則是RowKey設計。

1.3.5 非功能性設計

業務方提出的需求和產品經理設計的產品方案大都聚焦于業務功能描述，在驗收時，通常也只是驗證要求實現的功能是否符合預期，極少考慮穩定性、兼容性、安全性、異常補償等非功能性問題。然而，很多時候，非功能性問題往往事關項目成敗，因此必須根據業務場景謹慎評估非功能性問題并設計相應的解決方案。

1.穩定性設計

在互聯網領域，穩定性設計是最重要的非功能性設計。根據阿里官方公布的數據，在2020年的“雙11”大促活動中，天貓平臺訂單創建峰值達58.3萬筆/秒。如此巨大的流量，若沒有穩定、可靠系統和服務，業務便是空中樓閣，隨時有崩塌的可能。那么，在互聯網企業，可以通過哪些具體的措施來保障穩定性呢？如圖1-22所示，在穩定性保障的流程中，容量評估、壓測驗證、限流/預案等環節都是需要服務端工程師來保障的。

2.可測試性設計

與客戶端不同，服務端對用戶來說是不可見的，測試工程師無法直接通過UI（User Interface）界面來驗證服務端的復雜邏輯，因此，服務端開發工程師在進行非功能性設計時，需要充分考慮可測試性。

?功能可測試：對于客戶端不直接可見的功能（如異步處理、定時任務補償等），服務端可采用在關鍵鏈路打印摘要日志等方式來幫助測試人員識別不可見邏輯是否正確執行。

?支持壓測：壓測數據（如用戶賬號、場景等）通常為虛構數據，在服務端強校驗邏輯下（如賬號校驗）無法直接跑通全鏈路。因此，服務端需要識別壓測數據，并支持壓測標識傳遞，對于不支持壓測的特殊環節還需要支持約束跳躍。

?灰度可測試：重大變更通常需經過充分灰度測試才能對外切流。在灰度環節，服務端需要支持多種流量控制策略，如白名單、百分比、萬分比等。

3.其他非功能性設計

非功能性設計涉及面廣，除了前面介紹的穩定性和可測試性，還有應用安全、異常處理、擴展性、兼容性等方面，如圖1-23所示。