上篇所講的高聚合低耦合的宗旨，就是要用在產(chǎn)品設(shè)計上。此處所講的產(chǎn)品設(shè)計，不只是界面設(shè)計，還包括產(chǎn)品架構(gòu)、系統(tǒng)架構(gòu)、功能模塊、實體結(jié)構(gòu)、角色、邏輯等等。

本篇文章分為整體設(shè)計和局部設(shè)計兩個部分。整體設(shè)計是指從零到一開發(fā)或者重構(gòu)一款產(chǎn)品的全部流程，一共涉及業(yè)務(wù)層、系統(tǒng)層、邏輯層和交互層等四個層面。局部設(shè)計是指產(chǎn)品正常迭代或者設(shè)計產(chǎn)品某小塊下的流程和核心，局部設(shè)計的流程是整體設(shè)計流程的子集，所以主講局部設(shè)計的核心。

大家在看的時候，時刻要想著“高內(nèi)聚低耦合塑造產(chǎn)品認(rèn)知”的宗旨。

整體設(shè)計

產(chǎn)品的整體設(shè)計包括業(yè)務(wù)層、系統(tǒng)層、邏輯層和交互層等四個層面?；谛枨筇岢鰳I(yè)務(wù)方案，基于可行可落地的業(yè)務(wù)方案進行設(shè)計。

在實際過程中，并不會嚴(yán)格按照順序一層層下來，因為方法是層級的，而靈感則是跳躍的。我一般是先從業(yè)務(wù)方案中抽象出實體、角色和邏輯，

整體設(shè)計

業(yè)務(wù)層：業(yè)務(wù)方案

業(yè)務(wù)層是指業(yè)務(wù)方案。業(yè)務(wù)方案就是業(yè)務(wù)層面的方案，要求業(yè)務(wù)方案是可行可落地的。新產(chǎn)品/新模塊的業(yè)務(wù)方案一般由產(chǎn)品經(jīng)理、領(lǐng)導(dǎo)或者業(yè)務(wù)方提出，代表著在產(chǎn)品經(jīng)理、領(lǐng)導(dǎo)或者業(yè)務(wù)方的思考中是如何解決這個問題的。

只有可行可落地的業(yè)務(wù)方案才有意義，因為產(chǎn)品經(jīng)理就是要把可行可落地的業(yè)務(wù)方案搬到線上，做成標(biāo)準(zhǔn)化的解決一類問題。如果業(yè)務(wù)方案的不可行，那么后續(xù)的產(chǎn)品設(shè)計也就無從談起了。

如果業(yè)務(wù)方案已經(jīng)落地且可行，例如在運營層面已經(jīng)按照某規(guī)則人工實行了一段時間，效果不錯。產(chǎn)品經(jīng)理就需要把這個方案搬到線上，要基于業(yè)務(wù)方案設(shè)計功能，做成標(biāo)準(zhǔn)化的功能解決一類的問題，還要結(jié)合整體和未來的發(fā)展。

如果沒有可行可落地的業(yè)務(wù)方案，產(chǎn)品經(jīng)理不僅需要和各方溝通出一個或者多個解決方案，還需要通過落地執(zhí)行或者設(shè)計MVP等方法去測試方案的預(yù)計效果和可行性。有多個就對比選一個最好的，這里的最好可以是效果或者性價比等，具體請視情況判斷。

當(dāng)公司發(fā)展到一定階段，業(yè)務(wù)和系統(tǒng)必定有一個是縱向有一個是橫向，多個業(yè)務(wù)縱向鋪開后，需要橫向的系統(tǒng)打通，主要出于四方面考慮：專業(yè)深度、人力資源、用戶體驗、全局打通。例如滴滴出行在短時間內(nèi)形成了包括快車、出租車、專車、順風(fēng)車、代駕等多業(yè)務(wù)的垂直化架構(gòu)，滴滴啟動了中臺戰(zhàn)略整合業(yè)務(wù)系統(tǒng)。

以下《從滴滴出行業(yè)務(wù)中臺實踐聊聊如何構(gòu)建大中臺架構(gòu)》

構(gòu)建業(yè)務(wù)中臺的四個原因

2015 年末，滴滴出行在短時間內(nèi)形成了包括快車、出租車、專車、順風(fēng)車、代駕等多業(yè)務(wù)的垂直化架構(gòu)。隨之，滴滴啟動了中臺戰(zhàn)略整合業(yè)務(wù)系統(tǒng)。

決定構(gòu)建業(yè)務(wù)中臺主要出于四方面考慮：專業(yè)深度、人力資源、用戶體驗、全局打通。

專業(yè)深度。由于是多業(yè)務(wù)垂直化的架構(gòu)，會有多個團隊開發(fā)同樣的架構(gòu)，這就需要很多的工程師。

每個團隊都是用最快速的方式構(gòu)建流程，所以技術(shù)很難做深。這樣一來，導(dǎo)致客戶端的流暢度不高，后端不穩(wěn)定，影響可擴展性。

人力資源。從原則上來說把每個團隊加到足夠的人，每個架構(gòu)都能有很好的發(fā)展。但工程師的薪資都非常高，招聘大量工程師來做同樣的架構(gòu)，研發(fā)成本高昂。還有些時候，即使你愿意花錢，也招聘不到合適的人。

用戶體驗。流暢度、穩(wěn)定性、擴展性、界面、交易流程等都是影響用戶體驗的重要因素。

在當(dāng)時的組織結(jié)構(gòu)和研發(fā)情況下，會出現(xiàn)業(yè)務(wù)的應(yīng)用場景不同，交易流程卻相同的問題，這樣很影響用戶的體驗。

全局打通。所有業(yè)務(wù)本質(zhì)都是出行，出行本質(zhì)具有協(xié)同效應(yīng)。但在各自獨立發(fā)展情況下，業(yè)務(wù)間完全沒有協(xié)同性，在構(gòu)建中臺過程中，我們可以逐步把協(xié)同性建立起來。

構(gòu)建出行業(yè)務(wù)中臺的挑戰(zhàn)

構(gòu)建出行業(yè)務(wù)中臺并不是只有好處，也一定會帶來很多問題，最大的問題是軟件復(fù)雜度。

從業(yè)務(wù)角度來說，把所有業(yè)務(wù)合并到一個體系下，本身就是很難的事，再加上滴滴出行是實時性 O2O 業(yè)務(wù)，場景差異很大，而且作為互聯(lián)網(wǎng)公司，不僅有很多需求不明確，還會不斷持續(xù)變化。

這種情況下，想要用一套相對穩(wěn)定、相對固定的架構(gòu)去支持所有業(yè)務(wù)，十分困難。

從組織角度來說，滴滴出行有多個事業(yè)部，業(yè)務(wù)涉及 400 多個城市，組織和個人的變化更快。

針對軟件復(fù)雜度的挑戰(zhàn)，中臺制定了最基本的實現(xiàn)目標(biāo)：在業(yè)務(wù)多元化發(fā)展的組織中，去構(gòu)建一套工程架構(gòu)，構(gòu)建一套組織結(jié)構(gòu)及對應(yīng)的管理機制，以保證業(yè)務(wù)可持續(xù)的又快又好的發(fā)展。

滴滴業(yè)務(wù)中臺的架構(gòu)實踐

在談具體對策與實踐之前，先來看看整個業(yè)務(wù)中臺的架構(gòu)設(shè)計，如下圖：

整個的架構(gòu)設(shè)計分幾個邊界的上下文，好處在于把相關(guān)性不強的邏輯拆開，同時在一個相關(guān)性下面，通過分層對業(yè)務(wù)進行更好的建模。

調(diào)度層作為入口去牽引多個業(yè)務(wù)線，業(yè)務(wù)流程層為調(diào)度層做服務(wù)，狀態(tài)智能層用來支持上面的兩層。

在對業(yè)務(wù)和產(chǎn)品進行更好建模的基礎(chǔ)上，進行了“五化”：服務(wù)化、異步化、配置化、插件化、數(shù)據(jù)化。

服務(wù)化

服務(wù)化很常見，以下單為例，如下圖：

下單流程能夠調(diào)用很多服務(wù)，在多個層次，以接口層次結(jié)果進行拆解。

這里需要提醒的是服務(wù)化要注意如下三點：

• 服務(wù)之間的協(xié)議和規(guī)范要建立好。

• 注意控制力度，力度太小、太大都會有問題。

• 隨著時間的發(fā)展，服務(wù)化本身要不斷的演進。

異步化

對每個事件的非核心或不需要實時反饋給客戶端的邏輯進行拆解，核心的主流程會變簡潔。對非核心的邏輯在事件上做訂閱之后，進行二級處理。

以結(jié)束訂單為例，如下圖：

結(jié)束訂單的時候有很多邏輯要做，但是都是通過 MysqlBinlog 處理或 MQ 處理。

配置化

服務(wù)化和異步化能解決很多迭代效率的問題，但由于系統(tǒng)、業(yè)務(wù)的復(fù)雜性，各個業(yè)務(wù)都有些差異，體現(xiàn)在不同的產(chǎn)品線、城市、區(qū)域、時間等等。

配置化的核心是對這些進行建模，把每個對象模型化，抽象成 ID，在不同的服務(wù)化里把這些可配置的能力進行抽象。

具體抽象過程，如下圖：

第一級抽象采用的是類 iptables 的規(guī)則引擎判定產(chǎn)品分類，第二級的規(guī)則引擎由模塊自定義。

所有配置化都是用的自生成平臺，要配置什么，自定義配置即可，這個過程是動態(tài)進行的。

當(dāng)前業(yè)務(wù)中臺已經(jīng)可以支持上千個配置點，比如不同層次的計價規(guī)則不一樣、不同產(chǎn)品線的車樣子不同、不同的場景，如拼車和接送機，管控規(guī)則也不一樣等等。

插件化

配置化解決的是業(yè)務(wù)線差異問題，但如遇到邏輯差異較大的情況，就要做插件，統(tǒng)稱為 FPI。

在 FPI 的能力上，不同的團隊可以開發(fā)很多插件，在特定的配置點下，對它的邏輯進行加載。

真正業(yè)務(wù)流程到這兒，可以調(diào)起它對應(yīng)的插件做出來。對于一些沒有差異化需求的業(yè)務(wù)，可以用開發(fā)的 default 邏輯，這是更極端的靈活性的體現(xiàn)。

有靈活性的體現(xiàn)后，團隊還可以做一些組織上的調(diào)整，原來每個服務(wù)或者平臺是一個垂直化的架構(gòu)，有些團隊是橫向，是 FT，有些 FT 是接送機 FT，專門做接送機的事情。

通過插件的形式在每個系統(tǒng)加載它的插件，它就可以跟著業(yè)務(wù)思考、跟著產(chǎn)品思考這個業(yè)務(wù)該怎么走、這個產(chǎn)品怎么演化。

相對的邏輯是更加專注的，這也帶來很好的組織結(jié)構(gòu)對中臺的適應(yīng)性。

數(shù)據(jù)化

在大數(shù)據(jù)時代，數(shù)據(jù)是不得不考慮的問題，所以在業(yè)務(wù)中臺，要實現(xiàn)全局打通，本質(zhì)是要把數(shù)據(jù)打通。

所以我們制定了離線分析與在線決策的方案，如下圖：

第一個是離線做分析，可以做數(shù)據(jù)血緣、模型訓(xùn)練，同時可以把它放到在線決策層面，構(gòu)建很好的智能客戶引擎和交易引擎，這個可以干預(yù)，因為干預(yù)可以讓升艙或者多業(yè)務(wù)線的清單成為可能。

因為有這樣的決策，使在線服務(wù)的管控和判斷做得更加智能。

數(shù)據(jù)化方面，需要注意以下三方面：

• 讓數(shù)據(jù)更加規(guī)范和標(biāo)準(zhǔn)化。

• 構(gòu)建完整的數(shù)據(jù)流，從在線到離線，從日志到模型的在線使用。

• 引入機器學(xué)習(xí)的算法、人工智能的算法去構(gòu)建在線數(shù)據(jù)智能的決策。

這是業(yè)務(wù)中臺的五個對策，主要解決傳統(tǒng)的系統(tǒng)架構(gòu)問題，怎么做到高耦合和內(nèi)聚，怎么提高迭代。

配置化和插件化解決靈活性問題，把靈活性開放給不同團隊。數(shù)據(jù)化實際上是中臺賦能業(yè)務(wù)，有中臺的賦能才能變得更好。

經(jīng)驗總結(jié)

業(yè)務(wù)中臺從無到有，到被應(yīng)用的實踐過程中，積累了很多實戰(zhàn)經(jīng)驗。主要分享以下幾點：

第一點：成功實現(xiàn)最大的業(yè)務(wù)孵化中臺是滴滴出行構(gòu)建業(yè)務(wù)中臺最大的經(jīng)驗。

因為最大的業(yè)務(wù)最復(fù)雜，把最復(fù)雜的業(yè)務(wù)搞定，用最復(fù)雜的業(yè)務(wù)落地別的業(yè)務(wù)會容易。也就是從快車開始做，逐步整合專車、出租車、代駕等。

第二點：穩(wěn)定，中臺對業(yè)務(wù)有收益，最根本的是保證穩(wěn)定，穩(wěn)定是發(fā)展的前提和基礎(chǔ)。

在整個構(gòu)建中臺的過程中非常重視穩(wěn)定性，有各種機制，包括灰度發(fā)布、分層次發(fā)布、流量回放、全鏈路壓測等等，保證代碼的質(zhì)量和系統(tǒng)的穩(wěn)定。

第三點：加強溝通，平衡多業(yè)務(wù)的優(yōu)先級。

滴滴出行有多個業(yè)務(wù)，有很多大區(qū)和城市，每個地方都有很多需求，要有一套機制和資源池。

如何保證相應(yīng)每個業(yè)務(wù)都能按照所對應(yīng)的在公司的重要性來獲取部分資源，要保障它的靈活性和效率，所以要有很多溝通工作，有很多平衡的工作。

第四點：中臺系統(tǒng)要不斷演進，不能一成不變，要發(fā)現(xiàn)問題、解決問題。

業(yè)務(wù)中臺不是一蹴而就，而是要在發(fā)展過程中不斷的變化，持續(xù)迭代。

第五點： “沒有最好，只有最合適”！

所有中臺都一定是適合某個公司特點，最合適的中臺是當(dāng)你深入了解業(yè)務(wù)、產(chǎn)品、系統(tǒng)、組織，而且不僅了解今天在哪里，還要了解過去是怎么演變而來，未來又會怎么演化。

系統(tǒng)層：系統(tǒng)定位、系統(tǒng)架構(gòu)、模塊抽象、規(guī)劃藍圖

系統(tǒng)層是指系統(tǒng)層面的一些東西，包括系統(tǒng)定位、系統(tǒng)架構(gòu)、模塊抽象、規(guī)劃藍圖。人們看到體驗到的產(chǎn)品都是露在外面的那一塊，實際上還有很多系統(tǒng)在海平面以下，或大或小的產(chǎn)品背后總后好幾套系統(tǒng)的存在。大的例如下圖的唯品會，整個分為SAAS、PAAS和IAAS，每個里面有多個平臺多個系統(tǒng)，才能支撐起唯品會的發(fā)展。小小的一款A(yù)PP里的IM、推送等可能都是第三方提供的獨立的系統(tǒng)。

唯品會的整體架構(gòu)

 

系統(tǒng)定位

系統(tǒng)定位就是指確定系統(tǒng)要解決什么需求，先要有拆分出系統(tǒng)的需求，然后才有這個系統(tǒng)。系統(tǒng)定位必然是最先一步，并不是所有東西都要單獨拉出個系統(tǒng)去做。觀察大型系統(tǒng)的演進過程可以發(fā)現(xiàn)，絕大部分系統(tǒng)都是從初始的小功能到模塊最后再到系統(tǒng)的（功能＜模塊＜系統(tǒng)）。

系統(tǒng)化本身就是為了解決資源共享低、利用率低、不能集中處理等問題，系統(tǒng)也能降低整體耦合性，此時應(yīng)該和架構(gòu)師進行探討，因為大部分都是技術(shù)層面的東西，要思考清楚哪些是系統(tǒng)哪些不是系統(tǒng)，所解決的需求是否重要是否急迫，并且對每個系統(tǒng)提出定位作為迭代方向，當(dāng)然定位并不是一成不變的。

 

系統(tǒng)架構(gòu)

確定了有哪些系統(tǒng)和對應(yīng)的系統(tǒng)定位后，即可開始進行系統(tǒng)架構(gòu)。系統(tǒng)架構(gòu)強調(diào)的是系統(tǒng)和系統(tǒng)之間的聯(lián)系，如果有多個系統(tǒng)還可以像唯品會一樣平臺化，便于理解也便于組織架構(gòu)劃分。

如果發(fā)現(xiàn)系統(tǒng)架構(gòu)完成后，并沒有把所有系統(tǒng)or模塊包含進去，則要回到系統(tǒng)定位上重新梳理和思考，要把所有都包含進去。因為系統(tǒng)架構(gòu)是解釋系統(tǒng)之間的關(guān)系，絕對不能硬塞進一個模塊。就像外出前收拾行李，把一堆東西塞進一個書包、一個旅行箱和一個編織袋，塞完了發(fā)現(xiàn)還剩一雙鞋，得想辦法塞到專門放鞋子得編織袋里面，但是編織袋已經(jīng)滿了也沒法倒騰出空位，那就只能塞到旅行箱里面。

裝滿東西的旅行箱（來自百度圖片）

系統(tǒng)和系統(tǒng)之間要協(xié)調(diào)配合，互相聯(lián)系互相制約，就像運動系統(tǒng)、神經(jīng)系統(tǒng)等八大系統(tǒng)使人體內(nèi)各種復(fù)雜的生命活動能夠正常進行。

 

模塊抽象

平臺、系統(tǒng)、模塊和功能之間的關(guān)系應(yīng)該是：平臺包含系統(tǒng)，系統(tǒng)包含模塊，模塊包含功能。此處所講的均不能只看做是前臺的某個界面，均包含后臺所對應(yīng)的邏輯等，是一個立體的結(jié)構(gòu)而不是前臺的平面結(jié)構(gòu)。平臺、系統(tǒng)、模塊和功能都是立體結(jié)構(gòu)，只是粒度不同。而角色、實體和流程是平面結(jié)構(gòu)，是不同角度下不同視野下的系統(tǒng)。

模塊抽象就是指把不同模塊都抽離出來，模塊和模塊之間互相獨立互相依存，類似系統(tǒng)定位，劃分了模塊之后才能確定哪個系統(tǒng)包含哪些模塊。

功能從場景和流程中抽象，模塊從功能和實體中抽象。像唯品會等電商系統(tǒng)，會分商品模塊、品類模塊、訂單模塊、購物車模塊、支付模塊等等。一個模塊包括前臺的展示頁面/組件+后臺邏輯。模塊的抽象是很自然的，因為本身系統(tǒng)的建立就有其內(nèi)部的生態(tài)或者邏輯，就像人體的呼吸系統(tǒng)包含呼吸道（鼻腔、咽、喉、氣管、支氣管）和肺一系列器官以及內(nèi)在邏輯。

 

規(guī)劃藍圖

優(yōu)秀的產(chǎn)品都是迭代和規(guī)劃出來的，而不是一生下來就是。很多產(chǎn)品前期都是很簡單很基礎(chǔ)的幾個模塊，而且1.0版本用以快速試錯的，如果模塊很多體量很大就會浪費資源，要是失敗了就得不償失。

規(guī)劃藍圖并不是計劃藍圖，規(guī)劃和計劃的區(qū)別在于，規(guī)劃是長遠的（6個月以上）、不詳細(xì)的、目標(biāo)不精確的，計劃則是短期的、詳細(xì)的、目標(biāo)精確的。例如，2018上半年要開發(fā)新版本就是個規(guī)劃，而2018年6月前用戶要自然增長100%通過優(yōu)惠券、滿減等手段則是計劃。

在系統(tǒng)架構(gòu)和模塊抽象起來后，我會進行規(guī)劃藍圖的工作。規(guī)劃藍圖分兩塊，需求樹和產(chǎn)品路線圖，需求樹是把所有需求（系統(tǒng)、模塊、功能或者某些待解決的問題）放到樹形圖上，產(chǎn)品路線圖則是把需求樹上的需求經(jīng)過篩減后按照產(chǎn)品階段放置。

需求樹示例

 

需求樹，是為了梳理、分類需求，分析優(yōu)先級和前后置條件。樹根是實現(xiàn)整個系統(tǒng)所必須要的基礎(chǔ)設(shè)施，樹干是核心功能模塊，樹枝是可以進入的領(lǐng)域或者方向，樹枝上也有功能模塊。一開始先把核心功能、基礎(chǔ)設(shè)施和方向領(lǐng)域確定好，然后用便利貼往上貼功能模塊或者需求，最后按照越靠近主干越優(yōu)先的策略調(diào)整便利貼的位置。期間整個團隊都有一起合作，各抒己見，一起協(xié)商這些具體功能或者想法應(yīng)該怎么發(fā)展，一起確定優(yōu)先級。

需求樹可隨時補充，而且要定期把需求樹上新增的需求刪減、調(diào)整以放到路線圖中。

產(chǎn)品路線圖示例

產(chǎn)品路線圖，是為了明確產(chǎn)品什么時候該做什么，是最多6個月到2年的產(chǎn)品路線，具體看公司規(guī)模、行業(yè)特點等。產(chǎn)品路線圖可根據(jù)實際情況進行調(diào)整，但不是想要改就改的，產(chǎn)品路線圖很嚴(yán)肅，不嚴(yán)肅的毫無意義，要遵守他。

路線圖包括產(chǎn)品階段、里程碑、需求。

產(chǎn)品開發(fā)階段是指產(chǎn)品所處的階段，會有初始、成長、成熟和衰退四大階段，每個大階段根據(jù)不同情況會有小階段，視產(chǎn)品情況自行確定。處于不同階段的產(chǎn)品都有不同的產(chǎn)品戰(zhàn)略，要歸納出來，為需求的選擇和實施方向提供思想支持。

里程碑主要是用來劃分階段的，例如找到第一個用戶G點并形成可復(fù)制方案使得用戶大規(guī)模增長，從初始進入了成長期；在新增和流失用戶打平，做再多拉新活動ROI都會持續(xù)下降，從成長進入了成熟期等等。

基于產(chǎn)品階段、階段中的產(chǎn)品戰(zhàn)略和需求樹，把需求放到產(chǎn)品路線圖中，最終形成產(chǎn)品路線圖。離當(dāng)前時間越近的要詳細(xì)些，遠的則大方向要清晰。

來源：Vency