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

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

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

整體設計

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

在實(shí)際過(guò)程中，并不會(huì )嚴格按照順序一層層下來(lái)，因為方法是層級的，而靈感則是跳躍的。我一般是先從業(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)導或者業(yè)務(wù)方提出，代表著(zhù)在產(chǎn)品經(jīng)理、領(lǐng)導或者業(yè)務(wù)方的思考中是如何解決這個(gè)問(wèn)題的。

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

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

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

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

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

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

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

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

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

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

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

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

在當時(shí)的組織結構和研發(fā)情況下，會(huì )出現業(yè)務(wù)的應用場(chǎng)景不同，交易流程卻相同的問(wèn)題，這樣很影響用戶(hù)的體驗。

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

構建出行業(yè)務(wù)中臺的挑戰

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

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

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

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

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

滴滴業(yè)務(wù)中臺的架構實(shí)踐

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

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

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

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

服務(wù)化

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

下單流程能夠調用很多服務(wù)，在多個(gè)層次，以接口層次結果進(jìn)行拆解。

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

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

• 注意控制力度，力度太小、太大都會(huì )有問(wèn)題。

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

異步化

對每個(gè)事件的非核心或不需要實(shí)時(shí)反饋給客戶(hù)端的邏輯進(jìn)行拆解，核心的主流程會(huì )變簡(jiǎn)潔。對非核心的邏輯在事件上做訂閱之后，進(jìn)行二級處理。

以結束訂單為例，如下圖：

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

配置化

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

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

具體抽象過(guò)程，如下圖：

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

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

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

插件化

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

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

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

有靈活性的體現后，團隊還可以做一些組織上的調整，原來(lái)每個(gè)服務(wù)或者平臺是一個(gè)垂直化的架構，有些團隊是橫向，是 FT，有些 FT 是接送機 FT，專(zhuān)門(mén)做接送機的事情。

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

相對的邏輯是更加專(zhuān)注的，這也帶來(lái)很好的組織結構對中臺的適應性。

數據化

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

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

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

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

數據化方面，需要注意以下三方面：

• 讓數據更加規范和標準化。

• 構建完整的數據流，從在線(xiàn)到離線(xiàn)，從日志到模型的在線(xiàn)使用。

• 引入機器學(xué)習的算法、人工智能的算法去構建在線(xiàn)數據智能的決策。

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

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

經(jīng)驗總結

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

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

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

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

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

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

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

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

第四點(diǎn)：中臺系統要不斷演進(jìn)，不能一成不變，要發(fā)現問(wèn)題、解決問(wèn)題。

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

第五點(diǎn)： “沒(méi)有最好，只有最合適”！

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

系統層：系統定位、系統架構、模塊抽象、規劃藍圖

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

唯品會(huì )的整體架構

 

系統定位

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

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

 

系統架構

確定了有哪些系統和對應的系統定位后，即可開(kāi)始進(jìn)行系統架構。系統架構強調的是系統和系統之間的聯(lián)系，如果有多個(gè)系統還可以像唯品會(huì )一樣平臺化，便于理解也便于組織架構劃分。

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

裝滿(mǎn)東西的旅行箱（來(lái)自百度圖片）

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

 

模塊抽象

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

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

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

 

規劃藍圖

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

規劃藍圖并不是計劃藍圖，規劃和計劃的區別在于，規劃是長(cháng)遠的（6個(gè)月以上）、不詳細的、目標不精確的，計劃則是短期的、詳細的、目標精確的。例如，2018上半年要開(kāi)發(fā)新版本就是個(gè)規劃，而2018年6月前用戶(hù)要自然增長(cháng)100%通過(guò)優(yōu)惠券、滿(mǎn)減等手段則是計劃。

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

需求樹(shù)示例

 

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

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

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

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

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

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

里程碑主要是用來(lái)劃分階段的，例如找到第一個(gè)用戶(hù)G點(diǎn)并形成可復制方案使得用戶(hù)大規模增長(cháng)，從初始進(jìn)入了成長(cháng)期；在新增和流失用戶(hù)打平，做再多拉新活動(dòng)ROI都會(huì )持續下降，從成長(cháng)進(jìn)入了成熟期等等。

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

來(lái)源：Vency