????如何統(tǒng)一看待和區(qū)別分層架構(gòu)、微服務(wù)架構(gòu)、分布式架構(gòu)等主流架構(gòu)?什么是 SOA?我們采用 SOA 的目的是什么?什么是服務(wù)化的本質(zhì)?如何設(shè)計(jì)服務(wù)以及服務(wù)化架構(gòu)呢?

阿里高級(jí)技術(shù)專家程彥分享他對(duì)面向服務(wù)架構(gòu)的一些看法，并給出相關(guān)的步驟和方案，較長(zhǎng)，同學(xué)們可收藏后再看。

自從提倡 SOA 架構(gòu)風(fēng)格以來，個(gè)人覺得軟件架構(gòu)并未有特別突破的變革，主要是在 SOA 面向服務(wù)架構(gòu)風(fēng)格基礎(chǔ)上不斷演化迭代，基于服務(wù)的 EA 明確分層架構(gòu)也好，微服務(wù)也罷，都是在面向服務(wù)架構(gòu)基礎(chǔ)上的適應(yīng)不同的場(chǎng)景的迭代升級(jí)。

我先拋出一個(gè)觀點(diǎn)，我覺得服務(wù)化架構(gòu)的本質(zhì)，和西方教育界深受影響的古希臘哲學(xué)家蘇格拉底的“產(chǎn)婆術(shù)”的教育思想本質(zhì)上是非常相通的：蘇格拉底的“產(chǎn)婆術(shù)”思想強(qiáng)調(diào)教育是一個(gè)“接生”的過程，教師就是“接生婆”，人們之所以接受教育是為了尋找“原我”以不斷完善自身。也就是教育的目的在于喚醒而不再于塑造。同理服務(wù)化架構(gòu)的本質(zhì)也不僅僅在采用什么樣的技術(shù)框架實(shí)現(xiàn)和塑造，更重要的是在于通過不停地在共創(chuàng)中反問、反思、反省等方式進(jìn)行對(duì)業(yè)務(wù)的本質(zhì)的不斷追溯、抽象、綜合歸納演繹，我們的每一個(gè)架構(gòu)師都是服務(wù)化架構(gòu)的接生婆，我們的使命是建立真正反映業(yè)務(wù)本質(zhì)并驅(qū)動(dòng)業(yè)務(wù)不斷向前的架構(gòu)。

我們是否足夠深入理解業(yè)務(wù)的本質(zhì)，做了足夠的歸納演繹以及綜合抽象，是否清晰的反應(yīng)到了我們的服務(wù)化的根基：業(yè)務(wù)模型、域模型以及平臺(tái)公共語義模型上?這是我們每一個(gè)參與服務(wù)化的每一個(gè)產(chǎn)品、架構(gòu)師、TL 和核心開發(fā)同學(xué)需要回答的第一個(gè)根本問題。

定義

面向服務(wù)的架構(gòu)(SOA)：SOA 是一種架構(gòu)風(fēng)格，致力于將業(yè)務(wù)功能保持一致的服務(wù)(系統(tǒng)服務(wù)，應(yīng)用服務(wù)，技術(shù)服務(wù))作為設(shè)計(jì)、構(gòu)建和編排組合業(yè)務(wù)流程以及解決方案的基本單元。

目的

我們采用 SOA 的架構(gòu)是為了什么呢?

為了更好的復(fù)用?為了更好的責(zé)任切分?為了接口和實(shí)現(xiàn)的分離，提升靈活性和隔離性?還是為了更好的接口分類和管理?

以上說法其實(shí)都沒錯(cuò)，但是面向服務(wù)化的架構(gòu) SOA 的目的遠(yuǎn)遠(yuǎn)超過接口技術(shù)細(xì)節(jié)的設(shè)計(jì)與定義，其核心的關(guān)注點(diǎn)在于服務(wù)的業(yè)務(wù)內(nèi)容以及內(nèi)涵，而不僅僅是如何設(shè)計(jì)和實(shí)現(xiàn)。

同時(shí)，SOA 更多的也不是如何構(gòu)建一個(gè)服務(wù)，任何人都可以很容易地創(chuàng)建一個(gè)服務(wù)，這并不是 SOA 的核心挑戰(zhàn)，而是如何賦能企業(yè)構(gòu)建有業(yè)務(wù)價(jià)值意義的完整業(yè)務(wù)語義的服務(wù)集合。

面向服務(wù)的架構(gòu)致力于在企業(yè)內(nèi)的不同的業(yè)務(wù)環(huán)境內(nèi)，建設(shè)業(yè)務(wù)功能驅(qū)動(dòng)的服務(wù)，從而將服務(wù)組裝成有價(jià)值、更高級(jí)別的業(yè)務(wù)流程和解決方案平臺(tái)。

面向服務(wù)的架構(gòu)的真正的價(jià)值體現(xiàn)在當(dāng)可重用的服務(wù)被靈活組合、編排在一起來構(gòu)建敏捷的、靈活的業(yè)務(wù)流程，其中敏捷體現(xiàn)在服務(wù)可以快速調(diào)整，獨(dú)立演化;靈活性體現(xiàn)在服務(wù)由于其業(yè)務(wù)功能定義明確，邊界清晰且功能內(nèi)聚性強(qiáng)，同時(shí)服務(wù)具備各自獨(dú)立完整生命周期，可被靈活組裝。

如果面向服務(wù)架構(gòu)能為企業(yè)提供了重大的價(jià)值，那么這些價(jià)值通過什么來體現(xiàn)的呢?

價(jià)值體現(xiàn)

• 行為一致性

面向服務(wù)的架構(gòu)允許我們?yōu)闃I(yè)務(wù)流程、任務(wù)或者決策擁有唯一的共同的入口，也就是，不管服務(wù)訪問的路徑如何，服務(wù)給業(yè)務(wù)提供的業(yè)務(wù)行為都是一致的。

• 數(shù)據(jù)一致性

面向服務(wù)的架構(gòu)允許我們?yōu)闃I(yè)務(wù)數(shù)據(jù)信息提供單一的訪問入口，也就是它提供給業(yè)務(wù)一致的、企業(yè)內(nèi)部共識(shí)的公用數(shù)據(jù)訪問。

• 模塊化及敏捷性

面向服務(wù)的架構(gòu) SOA 為業(yè)務(wù)功能、業(yè)務(wù)決策和業(yè)務(wù)信息的模塊化提供了非常好的機(jī)制。同時(shí)，在模塊化實(shí)現(xiàn)好的情況下，這些模塊可以在多個(gè)業(yè)務(wù)流程和場(chǎng)景中被靈活復(fù)用和重新組合，從而為業(yè)務(wù)競(jìng)爭(zhēng)力和創(chuàng)造性提供靈活性和敏捷度支持。

• 功能與數(shù)據(jù)的解耦

面向服務(wù)的架構(gòu) SOA 提供了業(yè)務(wù)功能和信息集成的同時(shí)，減少了他們之間的依賴和耦合性。也就是，獨(dú)立的業(yè)務(wù)功能單元，應(yīng)用系統(tǒng)，可以一起協(xié)同工作，同時(shí)各自又具備各自的演進(jìn)計(jì)劃，生命周期和業(yè)務(wù)目標(biāo)。

• 高度可管理性

SOA 提供給我們通過定義服務(wù)水平協(xié)定在服務(wù)模塊粒度支撐我們的業(yè)務(wù)目標(biāo)，我們可以不斷的設(shè)定、監(jiān)控和優(yōu)化調(diào)整組件，應(yīng)用以及系統(tǒng)所承載服務(wù)的考核。

其中行為一致性和數(shù)據(jù)一致性作為服務(wù)的核心價(jià)值根基。

服務(wù)

一、定義

首先我們先定義一下服務(wù)是什么?

服務(wù)是通過服務(wù)契約的方式來提供業(yè)務(wù)功能的獨(dú)立單元，同時(shí)受服務(wù)契約所明確管理。

服務(wù)是設(shè)計(jì)、構(gòu)建和編排組合一個(gè)完整業(yè)務(wù)實(shí)體中業(yè)務(wù)解決方案的基礎(chǔ)單元。服務(wù)契約指定了服務(wù)消費(fèi)方和提供方之間所有的交互約定，包括：

• 服務(wù)接口
• 接口文檔
• 服務(wù)策略
• 服務(wù)質(zhì)量
• 服務(wù)可用性
• 性能

那我們經(jīng)常聽到模塊、組件等其他的軟件構(gòu)件，服務(wù)和他們有什么區(qū)別呢?其中最核心的區(qū)別在于服務(wù)本身是被明確管理的，其服務(wù)質(zhì)量和性能是通過服務(wù)水平協(xié)定(SLA)被明確管理的，而模塊以及組件并無此約束。此外，服務(wù)的全生命周期包含從設(shè)計(jì)、部署到增強(qiáng)升級(jí)和維護(hù)都是可管理的。

舉例(下列內(nèi)容僅做示例展示用，非適用于嚴(yán)格場(chǎng)景)：

二、服務(wù)構(gòu)成

服務(wù)自身主要包含兩個(gè)主要方面，第一方面也是服務(wù)最核心的方面就是服務(wù)的接口，另外一方面則是服務(wù)的實(shí)現(xiàn)。服務(wù)非常好的實(shí)現(xiàn)了接口和實(shí)現(xiàn)的分離。

??

1)服務(wù)接口

服務(wù)接口指定了服務(wù)的操作，也就是服務(wù)是做什么的(What),操作的輸入輸出參數(shù)，以及用來約定如何使用和提供這些能力的協(xié)議。

服務(wù)通常包含圍繞著一個(gè)核心的業(yè)務(wù)功能操作以及相關(guān)聯(lián)的操作。例如補(bǔ)貨建議計(jì)算服務(wù)中核心的操作是生成貨品+倉(cāng)維度的補(bǔ)貨建議單，其他相關(guān)操作包含查詢補(bǔ)貨建議單相關(guān)銷量預(yù)測(cè)操作，查詢補(bǔ)貨建議單對(duì)應(yīng)計(jì)劃庫(kù)存操作。

2)服務(wù)實(shí)現(xiàn)

服務(wù)實(shí)現(xiàn)指的是服務(wù)如何通過其明確定義的接口提供其能力。服務(wù)實(shí)現(xiàn)可以通過以下方式實(shí)現(xiàn)：

• 完全基于編碼實(shí)現(xiàn)
• 基于其他服務(wù)的編排而成
• 基于已有應(yīng)用適配封裝而成
• 以上情況混合實(shí)現(xiàn)

核心點(diǎn)是服務(wù)如何被實(shí)現(xiàn)的對(duì)于服務(wù)消費(fèi)方來說是透明的，服務(wù)消費(fèi)方僅僅需要關(guān)心的是服務(wù)是做什么的，而不是如何被實(shí)現(xiàn)的。

服務(wù)可以提供在保持服務(wù)接口或者行為約定不改變的情況下，提供根據(jù)不同的行業(yè)不同場(chǎng)景提供各種不同的實(shí)現(xiàn)。

服務(wù)實(shí)現(xiàn)在保持服務(wù)接口或者行為約定不改變的情況下，可以自由進(jìn)行升級(jí)和切換。服務(wù)實(shí)現(xiàn)既可以是靜態(tài)的更新升級(jí)，也可以使動(dòng)態(tài)路由實(shí)時(shí)切換實(shí)現(xiàn)，如對(duì)應(yīng)到不同的行業(yè)以及不同的業(yè)務(wù)場(chǎng)景的自動(dòng)實(shí)現(xiàn)切換。

不管服務(wù)實(shí)現(xiàn)如何升級(jí)或者按需自動(dòng)路由切換，只用服務(wù)的行為和契約不會(huì)發(fā)生改變，用戶也就是服務(wù)的消費(fèi)者根本不會(huì)感知到任何不同。

我們可以把服務(wù)接口想象成室內(nèi)普通電源國(guó)標(biāo)插口，服務(wù)策略為室內(nèi)非防水情況下適用，服務(wù)契約想象成 24X7 的 220v 電壓供電能力(其中 180V～250V 50Hz 是質(zhì)量要求，24x7 穩(wěn)定性要求，電流供給 <= 10A 是性能要求)，此國(guó)標(biāo)插座(服務(wù)提供方)可以給包含與此接口匹配且符合契約的任何電器(消費(fèi)方)交互并提供供電能力，支持其運(yùn)轉(zhuǎn)。

服務(wù)接口定義了交互的的風(fēng)格和細(xì)節(jié)，而服務(wù)的實(shí)現(xiàn)定義了一個(gè)特定的服務(wù)提供方或者特定的業(yè)務(wù)實(shí)現(xiàn)如何提供其能力。

這種類似連接點(diǎn)/插口的設(shè)計(jì)極大的方便了更松耦合的業(yè)務(wù)功能解決方案。

三、服務(wù)接口與服務(wù)實(shí)現(xiàn)的邏輯構(gòu)成

服務(wù)接口與實(shí)現(xiàn)的構(gòu)成也有兩個(gè)重要的不同方面，分別是執(zhí)行功能的方法和執(zhí)行的信息數(shù)據(jù)。換句話說，一個(gè)服務(wù)是由一個(gè)業(yè)務(wù)服務(wù)操作集合以及對(duì)應(yīng)操作的輸入輸出的抽象業(yè)務(wù)服務(wù)數(shù)據(jù)模型組成。這層業(yè)務(wù)服務(wù)數(shù)據(jù)模型是企業(yè)業(yè)務(wù)層次或者平臺(tái)業(yè)務(wù)層次的業(yè)務(wù)實(shí)體的抽象，獨(dú)立于底層數(shù)據(jù)存儲(chǔ)與實(shí)現(xiàn)。此業(yè)務(wù)數(shù)據(jù)模型是和各子域密切相關(guān)聯(lián)，但是超越各子域以上的，在完整的業(yè)務(wù)線或者平臺(tái)層次上達(dá)成一致的業(yè)務(wù)數(shù)據(jù)模型，也就是說在各子域之間達(dá)成共識(shí)且約定的嚴(yán)格明確的公共模型，主要用于平臺(tái)業(yè)務(wù)流程中不同域服務(wù)的交互，是平臺(tái)層次統(tǒng)一的業(yè)務(wù)語言，我把它暫時(shí)稱為平臺(tái)業(yè)務(wù)數(shù)據(jù)模型。 此平臺(tái)業(yè)務(wù)數(shù)據(jù)模型通常需要包含平臺(tái)統(tǒng)一語義的業(yè)務(wù)術(shù)語表，平臺(tái)各域核心實(shí)體表，平臺(tái)各域核心實(shí)體交互圖等。

??

接口與實(shí)現(xiàn)的邏輯構(gòu)成：

1)服務(wù)操作

服務(wù)操作聲明定義了這個(gè)操作的輸入以及輸出參數(shù)。

2)平臺(tái)業(yè)務(wù)實(shí)體模型

平臺(tái)業(yè)務(wù)實(shí)體模型描述了服務(wù)中輸入輸出數(shù)據(jù)的結(jié)構(gòu)以及含義。服務(wù)接口中的信息和服務(wù)實(shí)現(xiàn)中邏輯數(shù)據(jù)之間的差異是至關(guān)重要的。

在服務(wù)接口層次上，最重要的是信息必須在業(yè)務(wù)服務(wù)之間進(jìn)行交互來賦能業(yè)務(wù)流程并完成業(yè)務(wù)流程。這些信息必須在參與流程的所有業(yè)務(wù)服務(wù)間達(dá)成一致且在服務(wù)之間通用，也就是平臺(tái)層次所有服務(wù)公用且標(biāo)準(zhǔn)的業(yè)務(wù)實(shí)體模型，同時(shí)此業(yè)務(wù)實(shí)體模型必須在平臺(tái)業(yè)務(wù)語義上明確且完成，確?？梢灾纹脚_(tái)所有端到端的業(yè)務(wù)。此平臺(tái)層級(jí)的業(yè)務(wù)實(shí)體模型并不是一蹴而就的，但是可以隨著平臺(tái)的重心變化不斷迭代完善成型的。

然而不同的是，從內(nèi)部來看，很多服務(wù)在各自實(shí)現(xiàn)的子域內(nèi)部都有這些信息的不同的超集，可能潛在的存在不同的數(shù)據(jù)格式。幸運(yùn)的是，我們不需要感知也不需要在所有關(guān)聯(lián)服務(wù)的相關(guān)子域?qū)嶓w模型上達(dá)成共識(shí)，即使不是不可能，但是也不太現(xiàn)實(shí)。與之相反，服務(wù)接口和服務(wù)實(shí)現(xiàn)的分離設(shè)計(jì)允許非常方便的進(jìn)行平臺(tái)業(yè)務(wù)實(shí)體模型和服務(wù)所在子域領(lǐng)域模型進(jìn)行映射轉(zhuǎn)換。

3)服務(wù)接口最后一個(gè)重要的方面就是服務(wù)水平協(xié)議 SLA。服務(wù)水平 SLA 協(xié)議指定了服務(wù)的的兩個(gè)重要方面的指標(biāo)，分別是業(yè)務(wù)上的指標(biāo)和技術(shù)上的指標(biāo)：

• 技術(shù)指標(biāo)：響應(yīng)時(shí)間RT，并發(fā)吞吐量 Throughput，可用性 Availability，可靠性 Reliablity。
• 業(yè)務(wù)指標(biāo)：完成的業(yè)務(wù)功能的質(zhì)量或者完成度，如產(chǎn)生的補(bǔ)貨建議是否滿足業(yè)務(wù)預(yù)期的周轉(zhuǎn)缺貨KPI要求：周轉(zhuǎn)下降 10 天，缺貨率下降5%。

服務(wù)化分層架構(gòu)

理解服務(wù)化分層架構(gòu)，首先要對(duì) TOGAF Meta-Model 有個(gè)清晰的理解，從元模型可以看出業(yè)務(wù)服務(wù)和業(yè)務(wù)流程的上承業(yè)務(wù)，下啟系統(tǒng)平臺(tái)的核心作用，一定要深刻理解業(yè)務(wù)服務(wù)和業(yè)務(wù)流程在企業(yè)架構(gòu)中的重要性，下面我把我翻譯后畫的版本給大家放在這里，給大家做個(gè)參考，TOGAF 不多做解釋，如有需要，大家可以交流，后面有時(shí)間嘗試寫下我對(duì) TOGAF 的學(xué)習(xí)和理解。

??

通常情況下，我們會(huì)按照不同行業(yè)的不同的業(yè)務(wù)流程去搭建系統(tǒng)，如供應(yīng)鏈最初在大家電 3W 行業(yè)孕育，我們按照 3W 的行業(yè)和業(yè)務(wù)場(chǎng)景搭建了平臺(tái)商家相適應(yīng)的計(jì)劃系統(tǒng);后續(xù)自營(yíng)行業(yè)又根據(jù)自己的行業(yè)也搭建了自營(yíng)的計(jì)劃系統(tǒng);后續(xù)小電數(shù)碼、國(guó)際以及其他業(yè)務(wù)快速發(fā)展，跟隨業(yè)務(wù)快跑的同時(shí)，也各自建立的各自的業(yè)務(wù)流程。在這個(gè)過程中，BPM 為建造不同的業(yè)務(wù)系統(tǒng)提供非常好的抽象支撐，但是經(jīng)常的結(jié)果是，BPM 被用作構(gòu)建了更高層抽象的，也更高效的，但是卻是煙囪式的應(yīng)用，而不沒有更好的貢獻(xiàn)更多的支撐到整體上能快速應(yīng)對(duì)業(yè)務(wù)變化而更靈活，更敏捷的業(yè)務(wù)平臺(tái)或者系統(tǒng)。

而這正是面向服務(wù)的架構(gòu)中業(yè)務(wù)規(guī)則以及決策作為服務(wù)要發(fā)揮更大作用的地方。面向服務(wù)的架構(gòu)允許我們將特定業(yè)務(wù)流程中的業(yè)務(wù)規(guī)則和業(yè)務(wù)決策抽象分離出來變成業(yè)務(wù)規(guī)則或者決策服務(wù)，這些規(guī)則和決策服務(wù)就可以被靈活應(yīng)用到不同的業(yè)務(wù)流程中，從而這些服務(wù)可以被統(tǒng)一管理和演化升級(jí)。

BPM + SOA 一起提供了支撐企業(yè)架構(gòu)的完美組合。BPM 提供更高層抽象定義業(yè)務(wù)流程的能力，以及與流程相關(guān)聯(lián)的重要監(jiān)控和管理能力;業(yè)務(wù)服務(wù)提供了支撐業(yè)務(wù)流程的核心的功能、決策以及信息。面向服務(wù)的架構(gòu)則提供能力將服務(wù)組合在一起來支撐和創(chuàng)建靈活且敏捷的端到端的企業(yè)業(yè)務(wù)。如果只有 BPM 而沒有 SOA 對(duì)于創(chuàng)建單獨(dú)的業(yè)務(wù)應(yīng)用或許非常有用，但是通常是創(chuàng)建的煙囪式的應(yīng)用，很難擴(kuò)展到企業(yè)內(nèi)或者平臺(tái)內(nèi)不同的業(yè)務(wù)線。如果只有 SOA 而沒有BPM雖然可以創(chuàng)建可重用且一致性高的服務(wù)，但是缺少將這些服務(wù)快速搭建業(yè)務(wù)流程并支撐端到端業(yè)務(wù)的能力，也無法支撐建立具有競(jìng)爭(zhēng)力且可以隨著外部競(jìng)爭(zhēng)環(huán)境進(jìn)行敏捷反應(yīng)的業(yè)務(wù)。

下圖顯示了一個(gè)建議的的封層服務(wù)化架構(gòu)圖，各分層如下：

• 端到端業(yè)務(wù)流程

業(yè)務(wù)流程是按照一定業(yè)務(wù)規(guī)則決定的順序執(zhí)行的業(yè)務(wù)操作組成。高層級(jí)的業(yè)務(wù)功能，通?？缭綉?yīng)用域或者業(yè)務(wù)線。通常由行業(yè)開發(fā)團(tuán)隊(duì)開發(fā)，此行業(yè)開發(fā)團(tuán)隊(duì)可以具備明確的實(shí)現(xiàn)組織結(jié)構(gòu)，也可以由跨團(tuán)隊(duì)的相關(guān)域共同組成虛線團(tuán)隊(duì)。例如，電商業(yè)務(wù)中，用戶選購(gòu)下單交互流程;供應(yīng)鏈業(yè)務(wù)中的補(bǔ)貨調(diào)撥計(jì)劃流程等。

• 平臺(tái)業(yè)務(wù)服務(wù)

高度模塊化的業(yè)務(wù)功能單元，由不同類型的子域服務(wù)組合編排而來，可作為業(yè)務(wù)流程的編排單元。跨行業(yè)通用的業(yè)務(wù)服務(wù)可由功能所在核心域開發(fā)團(tuán)隊(duì)編排開發(fā)，行業(yè)內(nèi)通用的業(yè)務(wù)服務(wù)可以由行業(yè)開發(fā)團(tuán)隊(duì)負(fù)責(zé)編排開發(fā)。例如，補(bǔ)貨審批服務(wù)

• 子域服務(wù)

平臺(tái)各功能子域提供的服務(wù)，對(duì)平臺(tái)可見，用于平臺(tái)業(yè)務(wù)服務(wù)的組合編排，也可以作為更高層的業(yè)務(wù)流程編排的基礎(chǔ)單元。子域服務(wù)通常由平臺(tái)各子域開發(fā)團(tuán)隊(duì)負(fù)責(zé)開發(fā)。例如，銷量計(jì)劃服務(wù)，補(bǔ)貨建議計(jì)算服務(wù)。

• 子域基礎(chǔ)服務(wù)

用于支撐各功能子域服務(wù)的基礎(chǔ)服務(wù)，對(duì)子域可見，對(duì)平臺(tái)不可見，用于子域服務(wù)的編排。

子域基礎(chǔ)服務(wù)通常由平臺(tái)各子域開發(fā)團(tuán)隊(duì)負(fù)責(zé)開發(fā)。例如，入倉(cāng)決策服務(wù)，計(jì)劃單據(jù)服務(wù)，計(jì)劃庫(kù)存服務(wù)等。

• 基礎(chǔ)子域服務(wù)

或稱為基礎(chǔ)業(yè)務(wù)域服務(wù)，提供平臺(tái)基礎(chǔ)業(yè)務(wù)服務(wù)，為各個(gè)功能子域或平臺(tái)業(yè)務(wù)服務(wù)提供基礎(chǔ)業(yè)務(wù)功能及數(shù)據(jù)服務(wù)。例如：商家服務(wù)，貨品服務(wù)，庫(kù)存服務(wù)等。

• 基礎(chǔ)架構(gòu)服務(wù)層

提供不同層次所公用的基礎(chǔ)架構(gòu)服務(wù)，如用用戶管理，權(quán)限管理，操作審計(jì)等等。

??

我們通常按照上述分層結(jié)構(gòu)來描述平臺(tái)架構(gòu)或者企業(yè)內(nèi)部架構(gòu)，看上去好像層次結(jié)構(gòu)清晰明了，但是卻是不完整的，因?yàn)榇嗣嫦蚍?wù)的架構(gòu)描述缺失了平臺(tái)系統(tǒng)架構(gòu)中一個(gè)核心部分，暨信息及信息模型分層，這一點(diǎn)非常之關(guān)鍵，往往會(huì)決定架構(gòu)的成功與否。

為了使架構(gòu)更完整同時(shí)也更真實(shí)，我們需要添加對(duì)應(yīng)的完整信息抽象(實(shí)體模型 or 領(lǐng)域模型)：

• 核心單據(jù)模型

端到端業(yè)務(wù)流程中操作的核心單據(jù)，承載業(yè)務(wù)核心價(jià)值的信息單元模型，例如，銷售訂單，采購(gòu)訂單，補(bǔ)貨計(jì)劃單等。此模型通常是平臺(tái)公共語義模型的核心子集。

• 平臺(tái)公共語義模型

定義了平臺(tái)層業(yè)務(wù)流程、業(yè)務(wù)服務(wù)交互數(shù)據(jù)。在平臺(tái)層面或企業(yè)層面，端到端業(yè)務(wù)流程中交互信息的公共語義模型，此模型不僅對(duì)平臺(tái)業(yè)務(wù)流程中交互的各實(shí)體進(jìn)行了明確的定義，而且包含了業(yè)務(wù)流程中所需要的完整的業(yè)務(wù)語義實(shí)體，同時(shí)各業(yè)務(wù)語義實(shí)體邊界明確，責(zé)任清晰。核心單據(jù)模型通常是平臺(tái)公共語義模型的子集。平臺(tái)公共語義模型包含下層子域的對(duì)外服務(wù)實(shí)體子集，按照端到端的完整平臺(tái)業(yè)務(wù)語義，可由平臺(tái)各功能子域模型所共享給平臺(tái)的核心實(shí)體子集有機(jī)整合而成，也可由平臺(tái)業(yè)務(wù)模型全新定義，或者從 TOP-DOWN 以及 BOTTOM-UP 兩個(gè)方向共同融合而成。需要注意的是此模型必然是無法一蹴而就，需要經(jīng)過無數(shù)迭代而不斷完善，但其一定是不可或缺的。平臺(tái)的諸多架構(gòu)決策和不斷演化完善需要基于此模型來進(jìn)行。

• 子域領(lǐng)域模型

平臺(tái)各功能子域的領(lǐng)域模型，用于驅(qū)動(dòng)各功能子域的應(yīng)用系統(tǒng)設(shè)計(jì)和開發(fā)。子域領(lǐng)域模型需要保持動(dòng)態(tài)穩(wěn)定，通過防腐層同所依賴的外域或者外部服務(wù)進(jìn)行隔離，防止外部服務(wù)污染子域內(nèi)的核心業(yè)務(wù)語義，同時(shí)保持域內(nèi)業(yè)務(wù)功能靈活可控。子域領(lǐng)域模型僅通過其對(duì)外服務(wù)實(shí)體子集對(duì)外可見，其余對(duì)外不可見。

• 跨域映射模型

用于各子域領(lǐng)域模型實(shí)現(xiàn)對(duì)外部模型的防腐依賴。

• 基礎(chǔ)架構(gòu)服務(wù)層

提供不同層次所公用的基礎(chǔ)架構(gòu)信息模型，如用戶模型，權(quán)限模型等。

??

信息架構(gòu)模型框架

現(xiàn)在來討論下服務(wù)化分層架構(gòu)重視度并不太高的另一個(gè)重要側(cè)面：信息架構(gòu)，之所以說信息架構(gòu)非常之重要，是因?yàn)樾畔⒓軜?gòu)與服務(wù)化架構(gòu)是一個(gè)密不可分的完整的整體。我對(duì)信息架構(gòu)模型進(jìn)行了分層劃分，下面從 TOP_DOWN 方向來討論不同的分層模型。

??

Level 0：戰(zhàn)略與決策模型(高層戰(zhàn)略視角)

這層次模型用于定義企業(yè)的戰(zhàn)略方向和商業(yè)目的，從而定義了企業(yè)內(nèi)任何系統(tǒng)平臺(tái)開發(fā)的方向和終局。這必然作為企業(yè)內(nèi)任何系統(tǒng)平臺(tái)開發(fā)的基本背景和基調(diào)，影響任何系統(tǒng)平臺(tái)開發(fā)項(xiàng)目的中長(zhǎng)期目標(biāo)定義和終局設(shè)定。

Level 1：商業(yè)模式(業(yè)務(wù)線 owner 視角)

這層模型從業(yè)務(wù)線 owner 的視角，用運(yùn)營(yíng)主體的業(yè)務(wù)術(shù)語描述其商業(yè)模式的本質(zhì)，包括其整體結(jié)構(gòu)，業(yè)務(wù)流程，以及組織結(jié)構(gòu)等。

Level 2：業(yè)務(wù)抽象概念模型

這層模型從業(yè)務(wù)架構(gòu)的視角用信息化的方式對(duì)單個(gè)業(yè)務(wù)線或者多個(gè)業(yè)務(wù)線的業(yè)務(wù)進(jìn)行抽象。Level 1 描述是對(duì)于企業(yè)業(yè)務(wù)來說有意義的東西或者事情，而 Level 2 則給予這些有意義的東西以更嚴(yán)格且清晰的定義，明確其內(nèi)涵以及外延并體系化，同時(shí)根據(jù)不同行業(yè)線的業(yè)務(wù)內(nèi)容進(jìn)行提取抽象，抽象出共性的內(nèi)容，用于更高效靈活的描述和定義業(yè)務(wù) 。

Level 1 描述的是業(yè)務(wù)運(yùn)營(yíng)人員所感知的業(yè)務(wù)流程，Level 2 不僅描述了這些業(yè)務(wù)流程，更重要的是抽象并描述了了這些業(yè)務(wù)流程所應(yīng)該包含的底層業(yè)務(wù)功能。

同樣的，Level 1 描述對(duì)企業(yè)業(yè)務(wù)來講所有重要的東西，Level 2 描述的是組織想要管理的信息后面最根本的內(nèi)容。Level 1 描述的事情是 Level 2 定義的基本實(shí)體的實(shí)際業(yè)務(wù)中對(duì)應(yīng)的樣本或事例。

簡(jiǎn)而言之，Level 2 是 Level 1 的抽象(Abstraction)與綜合(Synthesis)。 為了達(dá)成這一視圖，必須要仔細(xì)分析和歸納，有時(shí)候需要演繹的方式來定義出隱藏在企業(yè)業(yè)務(wù)運(yùn)營(yíng)主體視圖下根本結(jié)構(gòu)和內(nèi)容。

Level 3：平臺(tái)公共語義模型

Level 3 層公共語義模型同 Level 2 層業(yè)務(wù)概念模型保持緊密一致，在此基礎(chǔ)上增加了服務(wù)化視角的語義。Level 3 公共語義模型描述的內(nèi)容是在必須在平臺(tái)層業(yè)務(wù)服務(wù)間共享的具有一致語義的業(yè)務(wù)實(shí)體和信息，是平臺(tái)層一致的共享信息模型。這層模型用于描述平臺(tái)層服務(wù)接口交互的共享信息，基于平臺(tái)完整業(yè)務(wù)語義下所有服務(wù)所公共數(shù)據(jù)的標(biāo)準(zhǔn)化視圖模型。簡(jiǎn)而言之，平臺(tái)公共語義模型，定義了業(yè)務(wù)平臺(tái)層次基本業(yè)務(wù)服務(wù)語義，是平臺(tái)各業(yè)務(wù)服務(wù)之間，平臺(tái)業(yè)務(wù)流程和平臺(tái)業(yè)務(wù)服務(wù)交互的統(tǒng)一語言。

Level 4：域模型

Level 4 層域模型定位于平臺(tái)各子域的領(lǐng)域模型/實(shí)體模型，用于對(duì)各子域的核心業(yè)務(wù)功能進(jìn)行抽象。域模型是平臺(tái)各子域的標(biāo)準(zhǔn)模型，不僅明確定義的各子域功能服務(wù)暨服務(wù)接口的語義，同時(shí)也包含各子域內(nèi)服務(wù)實(shí)現(xiàn)中的關(guān)鍵實(shí)體的定義。域模型從整體上來說是平臺(tái)各子域的私有模型，除了服務(wù)語義外整體不對(duì)外可視。公共信息中的服務(wù)視圖是域模型的子集。

域模型核心用于除了用于暴露到平臺(tái)子域的業(yè)務(wù)服務(wù)設(shè)計(jì)與實(shí)現(xiàn)外，同時(shí)也用于驅(qū)動(dòng)域內(nèi)服務(wù)功能的設(shè)計(jì)和實(shí)現(xiàn)。

域模型是需要保持動(dòng)態(tài)穩(wěn)定的，除非域內(nèi)業(yè)務(wù)發(fā)生本質(zhì)變化，域模型應(yīng)該是相對(duì)穩(wěn)定的。域模型穩(wěn)定性最大的敵人是外部的依賴，如何不受外部依賴的侵蝕而逐漸腐敗，域防腐層存在的最主要原因。子域防腐層維護(hù)外部依賴服務(wù)和子域模型之間的動(dòng)態(tài)映射，維護(hù)域模型的獨(dú)立性，保護(hù)域模型不受有害侵蝕。

域模型我理解基本和我們通常談的領(lǐng)域模型基本接近，對(duì)于各域內(nèi)業(yè)務(wù)的抽象，驅(qū)動(dòng)各域技術(shù)設(shè)計(jì)方案設(shè)計(jì)和實(shí)現(xiàn)，至于具體的模型表現(xiàn)形式，采用基于亞里士多德的物質(zhì)本源的思想(“Material Cause,Formal Cause,Efficient Cause,Final Cause" —> 實(shí)體+屬性+關(guān)系)的ER圖，還是基于我們老祖宗老子道家思想("人法地、地法天、天法道、道法自然" —> 實(shí)體+行為)的思想的領(lǐng)域驅(qū)動(dòng) DDD 的方式，個(gè)人認(rèn)為各有伯仲，組中能清楚表達(dá)出業(yè)務(wù)本質(zhì)即可，后面單獨(dú)寫一篇抽象建模的文章聊一下這兩種不同的思想。

Level 5：實(shí)現(xiàn)模型

此層模型為開發(fā)者視角的實(shí)現(xiàn)模型，也就是我們系統(tǒng)實(shí)現(xiàn)核心的對(duì)象模型，是我們系統(tǒng)落地的基石。

設(shè)計(jì)服務(wù)

我們初步了解的什么是服務(wù)，以及什么是服務(wù)化的分層?那如何設(shè)計(jì)服務(wù)以及服務(wù)化架構(gòu)呢?下面給出基本步驟和方案。

一、理解整體背景

首先，我們要理解服務(wù)化架構(gòu)的整體背景。我們必須理解我們所支撐的業(yè)務(wù)和業(yè)務(wù)根本驅(qū)動(dòng)力以及所有的業(yè)務(wù)流程，業(yè)務(wù)場(chǎng)景以及業(yè)務(wù)用例;同時(shí)對(duì)于平臺(tái)系統(tǒng)，我們還必須理解公司的戰(zhàn)略所賦予平臺(tái)的使命是什么?我們平臺(tái)中長(zhǎng)期的目標(biāo)是什么?平臺(tái)的終局是什么?這些組合和在一起才是服務(wù)化架構(gòu)的完整的上下文背景。這些必須要反映到我們的業(yè)務(wù)模型、平臺(tái)公共語義模型和各域模型中去。

然后，我們需要提出并回答如下問題：

• 我們當(dāng)前支撐的是什么樣的業(yè)務(wù)?(業(yè)務(wù)模型)
• 這個(gè)業(yè)務(wù)或者這些業(yè)務(wù)的中長(zhǎng)期目標(biāo)和短期目標(biāo)分別是什么?
• 平臺(tái)的短中長(zhǎng)期目標(biāo)是什么?平臺(tái)的終局是什么?
• 上述目標(biāo)是否存在沖突，如何平衡和取舍?
• 實(shí)現(xiàn)這些目標(biāo)，需要完成什么樣的成果?
• 這些成果如何衡量?
• 取得這些成果，需要什么樣的能力和信息?
• 實(shí)現(xiàn)這些能力需要什么樣的流程、服務(wù)、實(shí)體以及規(guī)則
• 現(xiàn)有的服務(wù)、應(yīng)用或者系統(tǒng)提供了那些基本能力和信息?

前面六個(gè)問題描述了整體的架構(gòu)需求(包括業(yè)務(wù)和平臺(tái))，而剩下的問題則描述了整個(gè)服務(wù)化架構(gòu)的上下文以及引入了服務(wù)目錄庫(kù)的需求。我們服務(wù)不能只從單個(gè)服務(wù)的角度來看，而必須從整個(gè)服務(wù)集合的角度來反應(yīng)完整的業(yè)務(wù)語義和平臺(tái)語義。我們的服務(wù)集合也就是服務(wù)目錄庫(kù)必須具備完整的上下文語義，必須能識(shí)別出：

• 整體的上下文背景，包括完整的業(yè)務(wù)語義和平臺(tái)語義。
• 服務(wù)職責(zé)范圍
• 關(guān)聯(lián)的服務(wù)的分組
• 服務(wù)的類型和角色

服務(wù)目錄庫(kù)的設(shè)計(jì)必須支持兩個(gè)主要的設(shè)計(jì)時(shí)目標(biāo)：

• 第一個(gè)目標(biāo)是要提供一種機(jī)制來幫助理解服務(wù)整體的上下文背景，用于更好的服務(wù)選擇及更高效的服務(wù)重用。特別是，這個(gè)服務(wù)實(shí)現(xiàn)了什么樣的責(zé)任，以及如何和其他的服務(wù)相關(guān)聯(lián)。
• 第二個(gè)目標(biāo)是要提供一種機(jī)制來識(shí)別一個(gè)特定服務(wù)的責(zé)任邊界，用來指引服務(wù)的實(shí)現(xiàn)。這是一個(gè)非常關(guān)鍵的點(diǎn)，特別是在避免服務(wù)的功能和數(shù)據(jù)重復(fù)上非常重要，不僅僅是避免重復(fù)建設(shè)，更核心的是要以此保證業(yè)務(wù)功能和數(shù)據(jù)的一致性。

服務(wù)目錄庫(kù)中的服務(wù)可以按照服務(wù)類型以及服務(wù)角色來進(jìn)行組織。服務(wù)類型請(qǐng)參照服務(wù)化分層架構(gòu)內(nèi)容里的描述;服務(wù)角色包含任務(wù)服務(wù)角色、實(shí)體服務(wù)角色和決策服務(wù)角色，請(qǐng)參照后面小節(jié)描述。

二、服務(wù)設(shè)計(jì)原則

面向服務(wù)化的架構(gòu)的其中一個(gè)成功的關(guān)鍵是創(chuàng)建一個(gè)具備完整業(yè)務(wù)語義的服務(wù)集合以便于可以方便一起進(jìn)行組合編排來支撐不同的業(yè)務(wù)流程以及豐富的業(yè)務(wù)場(chǎng)景。

我們經(jīng)常談?wù)摳鞴δ苡蛞峁┧神詈系姆?wù)，是因?yàn)榉?wù)間的松耦合是非常重要的，特別是通過減少服務(wù)間的依賴以便于服務(wù)可以在不同的場(chǎng)景中被復(fù)用，以及可以起到隔離變更影響的作用。但是如何才能盡可能的實(shí)現(xiàn)這個(gè)目標(biāo)呢?

首先我們來看下對(duì)于服務(wù)最重要點(diǎn)是什么?首先就是這個(gè)服務(wù)提供了什么樣的業(yè)務(wù)功能，其次這個(gè)服務(wù)對(duì)業(yè)務(wù)有價(jià)值的數(shù)據(jù)產(chǎn)生了那些影響。從這兩個(gè)點(diǎn)上我們就可以比較容易得出兩種類型的耦合在服務(wù)接口設(shè)計(jì)中是特別重要的：

• 數(shù)據(jù)依賴
• 功能依賴

舉例來說明下：

交易服務(wù)協(xié)調(diào)所有的活動(dòng)，然后依賴其他服務(wù)來幫助完成流程。交易服務(wù)依賴于或者說耦合于用戶服務(wù)，商品服務(wù)，庫(kù)存服務(wù)，營(yíng)銷服務(wù)、訂單服務(wù)以及支付服務(wù)等。

為啥交易服務(wù)沒有實(shí)現(xiàn)所有的功能?

首先是因?yàn)槲覀兿朐谄渌呒?jí)別流程或者服務(wù)中重用底層的能力。

第二是交易服務(wù)服務(wù)并不負(fù)責(zé)用戶服務(wù)，商品服務(wù)，庫(kù)存服務(wù)，營(yíng)銷服務(wù)、訂單服務(wù)以及支付服務(wù)。交易服務(wù)只是使用它們，而不是負(fù)責(zé)實(shí)現(xiàn)它們。

用戶服務(wù)被用作管理客戶信息訪問，它具有唯一的責(zé)任來提供、維護(hù)和更新客戶信息，這樣做的目的是為了可以在任何需要訪問客戶數(shù)據(jù)服務(wù)的地方重用客戶服務(wù)。比代碼重用更重要的是隔離或者是集中式訪問客戶信息，因?yàn)橹挥形ㄒ坏穆窂皆L問數(shù)據(jù)，數(shù)據(jù)就總是一致的，真正實(shí)現(xiàn) Source Of Truth。因此，盡管有很多服務(wù)包含交易服務(wù)，購(gòu)物車，訂單歷史等服務(wù)需要訪問客戶服務(wù),通過松耦合的這種模式去管理這些依賴是比較容易被理解的。

通過創(chuàng)建服務(wù)來執(zhí)行用戶管理，商品管理，庫(kù)存管理，以及營(yíng)銷管理等，就可以在任何可以用到的地方，執(zhí)行保持一致性的這些業(yè)務(wù)功能。

敲黑板：好的服務(wù)設(shè)計(jì)并不僅僅是關(guān)注重用性，更重要的是要提供一致性,既包含功能一致性，也包含數(shù)據(jù)一致性。

那么下一個(gè)問題是你如何決定有哪些服務(wù)以及這些服務(wù)分別是什么呢?同樣，你用功能分解和信息隔離組合在一起來決定服務(wù)有哪些并且各自是什么?

• 對(duì)線上交易功能的分解引導(dǎo)去識(shí)別用戶、商品、庫(kù)存、營(yíng)銷、訂單以及支付等相關(guān)功能服務(wù)。
• 對(duì)信息的隔離引導(dǎo)我們?nèi)プR(shí)別用戶和商品等作為交易訂單中的共享信息。
• 面向服務(wù)的架構(gòu)中服務(wù)設(shè)計(jì)的問題需要跨越多個(gè)以致于所有的流程中來一起考慮。

因此，服務(wù)設(shè)計(jì)原則基本原則如下：

• 避免服務(wù)間的功能重復(fù)
• 避免服務(wù)間的功能缺失
• 避免數(shù)據(jù)重復(fù)
• 實(shí)現(xiàn)數(shù)據(jù)的協(xié)同訪問
• 具備統(tǒng)一、一致的方式來執(zhí)行給定的功能

在服務(wù)化設(shè)計(jì)中，如何實(shí)現(xiàn)上述的這些原則呢?答案是提出并回答如下問題：

• 誰負(fù)責(zé)這個(gè)功能?
• 這個(gè)功能在哪里被用到的?
• 誰負(fù)責(zé)管理這些指定的數(shù)據(jù)?
• 誰負(fù)責(zé)定義和實(shí)現(xiàn)那些特別的業(yè)務(wù)規(guī)則
• 流程中的哪個(gè)步驟具備執(zhí)行這個(gè)任務(wù)所需要的特定的知識(shí)

這些問題的答案會(huì)幫你來識(shí)別如下信息：

• 服務(wù)應(yīng)該做什么?
• 服務(wù)對(duì)什么負(fù)責(zé)?
• 同樣重要的是，識(shí)別服務(wù)不應(yīng)該做什么，而應(yīng)該依賴其他的服務(wù)來支撐

三、服務(wù)顆粒度與類型

我們通常設(shè)計(jì)服務(wù)時(shí)候一個(gè)很大的疑惑是我的服務(wù)到底要設(shè)計(jì)成什么樣的顆粒度，應(yīng)該更粗粒度一些，還是更細(xì)粒度一些?答案是：沒有一個(gè)統(tǒng)一正確的服務(wù)顆粒度標(biāo)準(zhǔn)。那怎么辦?我如何設(shè)計(jì)我的服務(wù)的顆粒度呢?雖然沒有統(tǒng)一的標(biāo)準(zhǔn)，但是我們可以依賴下面的因素來決定合適的服務(wù)粒度：

• 誰是服務(wù)的潛在消費(fèi)方?其他服務(wù)，業(yè)務(wù)流程還是外部合作方?
• 服務(wù)在哪里被消費(fèi)，通過什么樣的路徑被消費(fèi)，也就是服務(wù)的拓?fù)浣Y(jié)構(gòu)是什么?
• 服務(wù)的性能要求是什么?
• 服務(wù)預(yù)期的業(yè)務(wù)范圍或者邊界是什么?

在幾乎任何復(fù)雜的環(huán)境或者系統(tǒng)平臺(tái)中，我們可以預(yù)期到多種多樣類型的服務(wù)。這些服務(wù)具有不同的類型和顆粒度，可以參考服務(wù)化分層中的內(nèi)容，也可以見下面的描述：

• 端到端的業(yè)務(wù)流程

業(yè)務(wù)流程通?？缭秸麄€(gè)企業(yè)或者平臺(tái)多個(gè)業(yè)務(wù)域，通常是由底層服務(wù)構(gòu)建而成

• 平臺(tái)業(yè)務(wù)服務(wù)

業(yè)務(wù)服務(wù)是最粗粒度的服務(wù)，業(yè)務(wù)服務(wù)提供高度抽象的，組合的業(yè)務(wù)功能給到平臺(tái)或者企業(yè)。業(yè)務(wù)服務(wù)的功能和數(shù)據(jù)同業(yè)務(wù)流程所需要的業(yè)務(wù)語義緊密結(jié)合。數(shù)據(jù)整合服務(wù)在這個(gè)層次提供端到端的業(yè)務(wù)流程所需要的整合后的數(shù)據(jù)。

• 子域服務(wù)

子域服務(wù)是中等粒度的，他們提供特別針對(duì)于每個(gè)業(yè)務(wù)子域的業(yè)務(wù)相關(guān)服務(wù),被本域內(nèi)的不同業(yè)務(wù)服務(wù)所使用，但是未必暴露出子域外

• 子域基礎(chǔ)服務(wù)

子域基礎(chǔ)服務(wù)通常是最小粒度的服務(wù)，他們提供更低層次的服務(wù)，用來提供子域內(nèi)子域業(yè)務(wù)功能的基本功能支撐

• 基礎(chǔ)子域服務(wù)

子域基礎(chǔ)服務(wù)通常也提供教小粒度的服務(wù)，用于支撐上層業(yè)務(wù)功能服務(wù)的業(yè)務(wù)功能完整實(shí)現(xiàn)。

• 基礎(chǔ)架構(gòu)服務(wù)層

基礎(chǔ)架構(gòu)提供了在更高層級(jí)服務(wù)構(gòu)建中細(xì)粒度的能力，獨(dú)立于任何業(yè)務(wù)域。這些服務(wù)需要和業(yè)務(wù)相關(guān)明確區(qū)分開來，例如安全認(rèn)證，權(quán)限管理以及純粹技術(shù)編排服務(wù)。

四、服務(wù)角色

獨(dú)立于服務(wù)的粒度，職責(zé)范圍以及服務(wù)創(chuàng)建以外的另外一個(gè)重要考量或者說是側(cè)面是：服務(wù)在服務(wù)組合或者流程編排中所承擔(dān)的角色是什么?

那么怎么來區(qū)分不同的角色呢?我們使用關(guān)注點(diǎn)隔離的架構(gòu)原則。例如，我們?cè)跇?gòu)建應(yīng)用中就使用了將數(shù)據(jù)同邏輯隔離作為重要的概念。這樣不僅提供了不同關(guān)注點(diǎn)解耦的可能以及機(jī)會(huì)，而且允許采用不同的方式，在不同的地方來實(shí)現(xiàn)這些不同的關(guān)注點(diǎn)。

對(duì)業(yè)務(wù)流程進(jìn)行單獨(dú)管理的BPM就是一個(gè)非常好的例子，BPM作為另外一個(gè)關(guān)注點(diǎn)分離的例子，將業(yè)務(wù)流程方案從其他邏輯中分離出來，可以使工作流程可以在一個(gè)特定的層次或者環(huán)境內(nèi)進(jìn)行執(zhí)行和管理, 這樣就可以實(shí)現(xiàn)通過快速的建立新的流程模型來快速響應(yīng)業(yè)務(wù)的變化。同時(shí)面向服務(wù)的架構(gòu)SOA提供了將業(yè)務(wù)服務(wù)作為構(gòu)建業(yè)務(wù)流程的基礎(chǔ)構(gòu)件的功能。業(yè)務(wù)規(guī)則系統(tǒng)BRMS同樣也作為一個(gè)關(guān)注點(diǎn)分離的例子，將業(yè)務(wù)規(guī)則或者業(yè)務(wù)決策從其他應(yīng)用邏輯中區(qū)分開來，這樣業(yè)務(wù)規(guī)則和業(yè)務(wù)決策也可以在一個(gè)特定的層次被執(zhí)行和管理，從而就可以很容易的被變更來支持新的業(yè)務(wù)需求。這里，業(yè)務(wù)規(guī)則以及決策服務(wù)也是面向服務(wù)的機(jī)構(gòu)來暴露出規(guī)則和決策服務(wù)來支撐規(guī)則和決策與業(yè)務(wù)流程的分離。

通常我們通過較粗粒度的來定義三大類服務(wù)角色來構(gòu)建不同的服務(wù)層次：

• 任務(wù)服務(wù)角色

任務(wù)服務(wù)通常實(shí)現(xiàn)一個(gè)完整的業(yè)務(wù)功能，既可以是基本業(yè)務(wù)功能，也可以是復(fù)雜的業(yè)務(wù)功能，如計(jì)算某個(gè)貨品在某個(gè)倉(cāng)的補(bǔ)貨量，或者一個(gè)簡(jiǎn)單的業(yè)務(wù)校驗(yàn)，如此貨品在此倉(cāng)是否可補(bǔ)。

此服務(wù)類型顆粒度范圍較廣，包含從獨(dú)立的子域基礎(chǔ)服務(wù)到大的平臺(tái)業(yè)務(wù)服務(wù)都可以具有任務(wù)服務(wù)角色，更小顆粒度的服務(wù)傾向于具有更通用的目的,更大的可重用的潛力。業(yè)務(wù)服務(wù)幾乎總是承擔(dān)任務(wù)服務(wù)的角色，通常是小顆粒度服務(wù)較大的組合，可以被設(shè)計(jì)成支持一個(gè)或者更多特定的流程。因此這些服務(wù)通常在跨業(yè)務(wù)流程中廣泛復(fù)用的潛力更低。但是也是正常的，因?yàn)樗麄兺ǔＪ怯衅渌芍赜玫姆?wù)組成的。

通常，具有業(yè)務(wù)角色的服務(wù)是主動(dòng)服務(wù)，通過主動(dòng)行為來提供價(jià)值

• 實(shí)體服務(wù)角色

主要管理訪問業(yè)務(wù)實(shí)體的服務(wù)具有這個(gè)角色。業(yè)務(wù)實(shí)體的例子如用戶、類目、商品、價(jià)格、庫(kù)存、購(gòu)物車，主要對(duì)應(yīng)主要的業(yè)務(wù)信息。實(shí)體通常是中到大型實(shí)體，傾向于獨(dú)立于任何特定的業(yè)務(wù)流程,而可做為多個(gè)不同業(yè)務(wù)流程的組成部分。具有實(shí)體服務(wù)角色的服務(wù)通常通過適配和提供需要的信息來實(shí)現(xiàn)任務(wù)的方式來支撐任務(wù)服務(wù)。實(shí)體服務(wù)通常都具備較大的重用的潛力。

• 規(guī)則 / 決策服務(wù)角色

規(guī)則 / 決策服務(wù)是通過執(zhí)行業(yè)務(wù)規(guī)則來提供業(yè)務(wù)決策的服務(wù)，如補(bǔ)貨計(jì)劃自動(dòng)審核服務(wù)。

規(guī)則 / 決策服務(wù)通常用作對(duì)復(fù)雜問題進(jìn)行判斷或者支持變化頻繁的業(yè)務(wù)規(guī)則，如復(fù)雜且多變的審核規(guī)則等。

規(guī)則 / 決策服務(wù)通常為小到中等大小顆粒度，通常用來組裝成更大的服務(wù)。規(guī)則/決策服務(wù)是可以不同層次不同類型的服務(wù)，包括平臺(tái)業(yè)務(wù)服務(wù)，子域服務(wù)，子域基礎(chǔ)服務(wù)等，但是通常情況下規(guī)則/決策服服務(wù)也來支撐這些服務(wù)類型。??

我們通過組合這些不同類型的服務(wù)角色來提供靈活的業(yè)務(wù)能力，從而用來支持業(yè)務(wù)流程內(nèi)的活動(dòng)。我們提供了一些基本原則來幫助我們進(jìn)行服務(wù)組合以便于幫我們減少依賴，限制耦合以及最大化靈活性。

服務(wù)層次以及組合基本原則：

• 業(yè)務(wù)流程的任務(wù)通過任務(wù)服務(wù)實(shí)現(xiàn)，業(yè)務(wù)流程路由的核心規(guī)則由規(guī)則/決策服務(wù)來提供，而不是定義在流程網(wǎng)關(guān)內(nèi)。這一塊內(nèi)容后續(xù)詳細(xì)說明。
• 更高層次的任務(wù)為核心的業(yè)務(wù)服務(wù)由其他更小的服務(wù)組成
• 服務(wù)依賴嚴(yán)格單向原則，上層服務(wù)可以依賴下層次服務(wù)以及同一層次服務(wù)，但是下層服務(wù)不可以依賴上層服務(wù)
• 一個(gè)任務(wù)服務(wù)可以組合規(guī)則/決策服務(wù)、實(shí)體服務(wù)以及其他任務(wù)服務(wù)
• 但是一個(gè)實(shí)體服務(wù)不允許直接調(diào)用其他實(shí)體服務(wù)

現(xiàn)在我們可以通過豐富的流程，實(shí)體和決策服務(wù)的集合，可以創(chuàng)建新的不同的服務(wù)組合，把規(guī)則的靈活可變的好處同服務(wù)化架構(gòu)的模塊化，靈活性以及重用性結(jié)合起來作為業(yè)務(wù)系統(tǒng)平臺(tái)級(jí)別的基本架構(gòu)方式。

服務(wù)化如何成功?

一、大規(guī)劃

大的規(guī)劃首先要明確 2-3 年內(nèi)的服務(wù)化的目標(biāo)。大的規(guī)劃切記事無巨細(xì)，而是根據(jù)長(zhǎng)期規(guī)劃設(shè)定明確的指導(dǎo)性原則和要求，在體系化的基礎(chǔ)上鼓勵(lì)協(xié)同和創(chuàng)新。

二、小目標(biāo)

服務(wù)化不應(yīng)該是運(yùn)動(dòng)式的大躍進(jìn)推進(jìn)，而應(yīng)該是堅(jiān)持試點(diǎn)、推廣、總結(jié)、擴(kuò)大試點(diǎn)，從而由點(diǎn)到面，逐步落實(shí)的方法，由各域根據(jù)規(guī)劃的體系化要求，再各自情況暨各自成熟度來設(shè)定各自服務(wù)化目標(biāo)，制定一個(gè)個(gè)小目標(biāo)，快速迭代，敏捷式的總結(jié)推進(jìn)。

三、真共識(shí)

建立共識(shí)的根本是要講清楚服務(wù)化的目標(biāo)、架構(gòu)、設(shè)計(jì)、開發(fā)背后的清楚的邏輯，讓每個(gè)人想的清楚，聽的明白。

四、接地氣

接地氣同達(dá)成共識(shí)一樣，要用樸素的工程師語言講清楚目標(biāo)和邏輯，而不是拿各種看上去非常光鮮亮麗的各種名詞來充當(dāng)臺(tái)面，講的人解釋不清楚，聽得人一頭霧水，沒有體系化邏輯來支撐落地，最終很難達(dá)到服務(wù)化真正的目標(biāo)的。

五、結(jié)硬寨

服務(wù)化是一個(gè)龐大的，迭代的，漸進(jìn)的體系化工程，不是快閃戰(zhàn)，不是突襲戰(zhàn)，是場(chǎng)持久戰(zhàn)，一定要有曾國(guó)藩的“結(jié)硬寨，打呆仗”的耐心和準(zhǔn)備，踏踏實(shí)實(shí)落地迭代推進(jìn)，小步快跑，在堅(jiān)持體系化思考的基礎(chǔ)上進(jìn)行持續(xù)總結(jié)改進(jìn)，通過一個(gè)接一個(gè)戰(zhàn)斗，一個(gè)小勝利接一個(gè)小勝利，一個(gè)戰(zhàn)役接一個(gè)戰(zhàn)役不停的攻城略地的基礎(chǔ)上逐漸邁向成功。

六、Think Fast & Slow

一句話，高效的方式就是慢想、快干。我們不一定缺少高執(zhí)行力的人，但是一定缺少能獨(dú)立思考并體系化行事的人。