建站
咨詢
售后
建站咨詢
新聞中心
????如何統(tǒng)一看待和區(qū)別分層架構(gòu)、微服務(wù)架構(gòu)、分布式架構(gòu)等主流架構(gòu)?什么是 SOA?我們采用 SOA 的目的是什么?什么是服務(wù)化的本質(zhì)?如何設(shè)計服務(wù)以及服務(wù)化架構(gòu)呢?
阿里高級技術(shù)專家程彥分享他對面向服務(wù)架構(gòu)的一些看法，并給出相關(guān)的步驟和方案，較長，同學(xué)們可收藏后再看。
自從提倡 SOA 架構(gòu)風(fēng)格以來，個人覺得軟件架構(gòu)并未有特別突破的變革，主要是在 SOA 面向服務(wù)架構(gòu)風(fēng)格基礎(chǔ)上不斷演化迭代，基于服務(wù)的 EA 明確分層架構(gòu)也好，微服務(wù)也罷，都是在面向服務(wù)架構(gòu)基礎(chǔ)上的適應(yīng)不同的場景的迭代升級。
我先拋出一個觀點(diǎn)，我覺得服務(wù)化架構(gòu)的本質(zhì)，和西方教育界深受影響的古希臘哲學(xué)家蘇格拉底的“產(chǎn)婆術(shù)”的教育思想本質(zhì)上是非常相通的：蘇格拉底的“產(chǎn)婆術(shù)”思想強(qiáng)調(diào)教育是一個“接生”的過程，教師就是“接生婆”，人們之所以接受教育是為了尋找“原我”以不斷完善自身。也就是教育的目的在于喚醒而不再于塑造。同理服務(wù)化架構(gòu)的本質(zhì)也不僅僅在采用什么樣的技術(shù)框架實現(xiàn)和塑造，更重要的是在于通過不停地在共創(chuàng)中反問、反思、反省等方式進(jìn)行對業(yè)務(wù)的本質(zhì)的不斷追溯、抽象、綜合歸納演繹，我們的每一個架構(gòu)師都是服務(wù)化架構(gòu)的接生婆，我們的使命是建立真正反映業(yè)務(wù)本質(zhì)并驅(qū)動業(yè)務(wù)不斷向前的架構(gòu)。
我們是否足夠深入理解業(yè)務(wù)的本質(zhì)，做了足夠的歸納演繹以及綜合抽象，是否清晰的反應(yīng)到了我們的服務(wù)化的根基：業(yè)務(wù)模型、域模型以及平臺公共語義模型上?這是我們每一個參與服務(wù)化的每一個產(chǎn)品、架構(gòu)師、TL 和核心開發(fā)同學(xué)需要回答的第一個根本問題。
定義
面向服務(wù)的架構(gòu)(SOA)：SOA 是一種架構(gòu)風(fēng)格，致力于將業(yè)務(wù)功能保持一致的服務(wù)(系統(tǒng)服務(wù)，應(yīng)用服務(wù)，技術(shù)服務(wù))作為設(shè)計、構(gòu)建和編排組合業(yè)務(wù)流程以及解決方案的基本單元。
目的
我們采用 SOA 的架構(gòu)是為了什么呢?
為了更好的復(fù)用?為了更好的責(zé)任切分?為了接口和實現(xiàn)的分離，提升靈活性和隔離性?還是為了更好的接口分類和管理?
以上說法其實都沒錯，但是面向服務(wù)化的架構(gòu) SOA 的目的遠(yuǎn)遠(yuǎn)超過接口技術(shù)細(xì)節(jié)的設(shè)計與定義，其核心的關(guān)注點(diǎn)在于服務(wù)的業(yè)務(wù)內(nèi)容以及內(nèi)涵，而不僅僅是如何設(shè)計和實現(xiàn)。
同時，SOA 更多的也不是如何構(gòu)建一個服務(wù)，任何人都可以很容易地創(chuàng)建一個服務(wù)，這并不是 SOA 的核心挑戰(zhàn)，而是如何賦能企業(yè)構(gòu)建有業(yè)務(wù)價值意義的完整業(yè)務(wù)語義的服務(wù)集合。
面向服務(wù)的架構(gòu)致力于在企業(yè)內(nèi)的不同的業(yè)務(wù)環(huán)境內(nèi)，建設(shè)業(yè)務(wù)功能驅(qū)動的服務(wù)，從而將服務(wù)組裝成有價值、更高級別的業(yè)務(wù)流程和解決方案平臺。
面向服務(wù)的架構(gòu)的真正的價值體現(xiàn)在當(dāng)可重用的服務(wù)被靈活組合、編排在一起來構(gòu)建敏捷的、靈活的業(yè)務(wù)流程，其中敏捷體現(xiàn)在服務(wù)可以快速調(diào)整，獨(dú)立演化;靈活性體現(xiàn)在服務(wù)由于其業(yè)務(wù)功能定義明確，邊界清晰且功能內(nèi)聚性強(qiáng)，同時服務(wù)具備各自獨(dú)立完整生命周期，可被靈活組裝。
如果面向服務(wù)架構(gòu)能為企業(yè)提供了重大的價值，那么這些價值通過什么來體現(xiàn)的呢?
價值體現(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ù)據(jù)訪問。
- 模塊化及敏捷性
面向服務(wù)的架構(gòu) SOA 為業(yè)務(wù)功能、業(yè)務(wù)決策和業(yè)務(wù)信息的模塊化提供了非常好的機(jī)制。同時，在模塊化實現(xiàn)好的情況下，這些模塊可以在多個業(yè)務(wù)流程和場景中被靈活復(fù)用和重新組合，從而為業(yè)務(wù)競爭力和創(chuàng)造性提供靈活性和敏捷度支持。
- 功能與數(shù)據(jù)的解耦
面向服務(wù)的架構(gòu) SOA 提供了業(yè)務(wù)功能和信息集成的同時，減少了他們之間的依賴和耦合性。也就是，獨(dú)立的業(yè)務(wù)功能單元，應(yīng)用系統(tǒng)，可以一起協(xié)同工作，同時各自又具備各自的演進(jìn)計劃，生命周期和業(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ù)的核心價值根基。
服務(wù)
一、定義
首先我們先定義一下服務(wù)是什么?
服務(wù)是通過服務(wù)契約的方式來提供業(yè)務(wù)功能的獨(dú)立單元，同時受服務(wù)契約所明確管理。
服務(wù)是設(shè)計、構(gòu)建和編排組合一個完整業(yè)務(wù)實體中業(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è)計、部署到增強(qiáng)升級和維護(hù)都是可管理的。
舉例(下列內(nèi)容僅做示例展示用，非適用于嚴(yán)格場景)：
|
補(bǔ)貨計算服 |
服務(wù)策略 |
服務(wù)質(zhì)量 |
性能要求 |
|
補(bǔ)貨建議量計算服務(wù) |
針對行業(yè)下商家/供應(yīng)商維度的入倉貨品補(bǔ)貨建議計算 |
在銷量預(yù)測符合分布要求且滿足準(zhǔn)確率水平要求的情況下，根據(jù)缺貨率服務(wù)水平要求的產(chǎn)生的補(bǔ)貨建議量符合業(yè)務(wù)期望的周轉(zhuǎn)天數(shù) |
10W + 貨品 * 30 倉，品+倉補(bǔ)貨及建議量 <= 30min |
|
訂單創(chuàng)建服務(wù) |
包含購物車下單+立即下單場景，滿足所有優(yōu)惠計算后的訂單生成 |
訂單創(chuàng)建成功率 99.999999999% |
峰值支撐：100w 單/s |
二、服務(wù)構(gòu)成
服務(wù)自身主要包含兩個主要方面，第一方面也是服務(wù)最核心的方面就是服務(wù)的接口，另外一方面則是服務(wù)的實現(xiàn)。服務(wù)非常好的實現(xiàn)了接口和實現(xiàn)的分離。
??
??
1)服務(wù)接口
服務(wù)接口指定了服務(wù)的操作，也就是服務(wù)是做什么的(What),操作的輸入輸出參數(shù)，以及用來約定如何使用和提供這些能力的協(xié)議。
服務(wù)通常包含圍繞著一個核心的業(yè)務(wù)功能操作以及相關(guān)聯(lián)的操作。例如補(bǔ)貨建議計算服務(wù)中核心的操作是生成貨品+倉維度的補(bǔ)貨建議單，其他相關(guān)操作包含查詢補(bǔ)貨建議單相關(guān)銷量預(yù)測操作，查詢補(bǔ)貨建議單對應(yīng)計劃庫存操作。
|
服務(wù) |
核心功能操作 |
關(guān)聯(lián)操作 |
|
補(bǔ)貨建議計算服務(wù) |
|
|
|
|
品+倉維度補(bǔ)貨建議計算 |
|
|
|
|
補(bǔ)貨建議單對應(yīng)銷量預(yù)測查詢 |
|
|
|
補(bǔ)貨建議單對應(yīng)計劃庫存操作 |
2)服務(wù)實現(xiàn)
服務(wù)實現(xiàn)指的是服務(wù)如何通過其明確定義的接口提供其能力。服務(wù)實現(xiàn)可以通過以下方式實現(xiàn)：
- 完全基于編碼實現(xiàn)
- 基于其他服務(wù)的編排而成
- 基于已有應(yīng)用適配封裝而成
- 以上情況混合實現(xiàn)
核心點(diǎn)是服務(wù)如何被實現(xiàn)的對于服務(wù)消費(fèi)方來說是透明的，服務(wù)消費(fèi)方僅僅需要關(guān)心的是服務(wù)是做什么的，而不是如何被實現(xiàn)的。
服務(wù)可以提供在保持服務(wù)接口或者行為約定不改變的情況下，提供根據(jù)不同的行業(yè)不同場景提供各種不同的實現(xiàn)。
服務(wù)實現(xiàn)在保持服務(wù)接口或者行為約定不改變的情況下，可以自由進(jìn)行升級和切換。服務(wù)實現(xiàn)既可以是靜態(tài)的更新升級，也可以使動態(tài)路由實時切換實現(xiàn)，如對應(yīng)到不同的行業(yè)以及不同的業(yè)務(wù)場景的自動實現(xiàn)切換。
不管服務(wù)實現(xiàn)如何升級或者按需自動路由切換，只用服務(wù)的行為和契約不會發(fā)生改變，用戶也就是服務(wù)的消費(fèi)者根本不會感知到任何不同。
我們可以把服務(wù)接口想象成室內(nèi)普通電源國標(biāo)插口，服務(wù)策略為室內(nèi)非防水情況下適用，服務(wù)契約想象成 24X7 的 220v 電壓供電能力(其中 180V～250V 50Hz 是質(zhì)量要求，24x7 穩(wěn)定性要求，電流供給 <= 10A 是性能要求)，此國標(biāo)插座(服務(wù)提供方)可以給包含與此接口匹配且符合契約的任何電器(消費(fèi)方)交互并提供供電能力，支持其運(yùn)轉(zhuǎn)。
服務(wù)接口定義了交互的的風(fēng)格和細(xì)節(jié)，而服務(wù)的實現(xiàn)定義了一個特定的服務(wù)提供方或者特定的業(yè)務(wù)實現(xiàn)如何提供其能力。
這種類似連接點(diǎn)/插口的設(shè)計極大的方便了更松耦合的業(yè)務(wù)功能解決方案。
三、服務(wù)接口與服務(wù)實現(xiàn)的邏輯構(gòu)成
服務(wù)接口與實現(xiàn)的構(gòu)成也有兩個重要的不同方面，分別是執(zhí)行功能的方法和執(zhí)行的信息數(shù)據(jù)。換句話說，一個服務(wù)是由一個業(yè)務(wù)服務(wù)操作集合以及對應(yīng)操作的輸入輸出的抽象業(yè)務(wù)服務(wù)數(shù)據(jù)模型組成。這層業(yè)務(wù)服務(wù)數(shù)據(jù)模型是企業(yè)業(yè)務(wù)層次或者平臺業(yè)務(wù)層次的業(yè)務(wù)實體的抽象，獨(dú)立于底層數(shù)據(jù)存儲與實現(xiàn)。此業(yè)務(wù)數(shù)據(jù)模型是和各子域密切相關(guān)聯(lián)，但是超越各子域以上的，在完整的業(yè)務(wù)線或者平臺層次上達(dá)成一致的業(yè)務(wù)數(shù)據(jù)模型，也就是說在各子域之間達(dá)成共識且約定的嚴(yán)格明確的公共模型，主要用于平臺業(yè)務(wù)流程中不同域服務(wù)的交互，是平臺層次統(tǒng)一的業(yè)務(wù)語言，我把它暫時稱為平臺業(yè)務(wù)數(shù)據(jù)模型。 此平臺業(yè)務(wù)數(shù)據(jù)模型通常需要包含平臺統(tǒng)一語義的業(yè)務(wù)術(shù)語表，平臺各域核心實體表，平臺各域核心實體交互圖等。
??
??
接口與實現(xiàn)的邏輯構(gòu)成：
1)服務(wù)操作
服務(wù)操作聲明定義了這個操作的輸入以及輸出參數(shù)。
2)平臺業(yè)務(wù)實體模型
平臺業(yè)務(wù)實體模型描述了服務(wù)中輸入輸出數(shù)據(jù)的結(jié)構(gòu)以及含義。服務(wù)接口中的信息和服務(wù)實現(xiàn)中邏輯數(shù)據(jù)之間的差異是至關(guān)重要的。
在服務(wù)接口層次上，最重要的是信息必須在業(yè)務(wù)服務(wù)之間進(jìn)行交互來賦能業(yè)務(wù)流程并完成業(yè)務(wù)流程。這些信息必須在參與流程的所有業(yè)務(wù)服務(wù)間達(dá)成一致且在服務(wù)之間通用，也就是平臺層次所有服務(wù)公用且標(biāo)準(zhǔn)的業(yè)務(wù)實體模型，同時此業(yè)務(wù)實體模型必須在平臺業(yè)務(wù)語義上明確且完成，確?？梢灾纹脚_所有端到端的業(yè)務(wù)。此平臺層級的業(yè)務(wù)實體模型并不是一蹴而就的，但是可以隨著平臺的重心變化不斷迭代完善成型的。
然而不同的是，從內(nèi)部來看，很多服務(wù)在各自實現(xiàn)的子域內(nèi)部都有這些信息的不同的超集，可能潛在的存在不同的數(shù)據(jù)格式。幸運(yùn)的是，我們不需要感知也不需要在所有關(guān)聯(lián)服務(wù)的相關(guān)子域?qū)嶓w模型上達(dá)成共識，即使不是不可能，但是也不太現(xiàn)實。與之相反，服務(wù)接口和服務(wù)實現(xiàn)的分離設(shè)計允許非常方便的進(jìn)行平臺業(yè)務(wù)實體模型和服務(wù)所在子域領(lǐng)域模型進(jìn)行映射轉(zhuǎn)換。
3)服務(wù)接口最后一個重要的方面就是服務(wù)水平協(xié)議 SLA。服務(wù)水平 SLA 協(xié)議指定了服務(wù)的的兩個重要方面的指標(biāo)，分別是業(yè)務(wù)上的指標(biāo)和技術(shù)上的指標(biāo)：
- 技術(shù)指標(biāo)：響應(yīng)時間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)，首先要對 TOGAF Meta-Model 有個清晰的理解，從元模型可以看出業(yè)務(wù)服務(wù)和業(yè)務(wù)流程的上承業(yè)務(wù)，下啟系統(tǒng)平臺的核心作用，一定要深刻理解業(yè)務(wù)服務(wù)和業(yè)務(wù)流程在企業(yè)架構(gòu)中的重要性，下面我把我翻譯后畫的版本給大家放在這里，給大家做個參考，TOGAF 不多做解釋，如有需要，大家可以交流，后面有時間嘗試寫下我對 TOGAF 的學(xué)習(xí)和理解。
??
??
通常情況下，我們會按照不同行業(yè)的不同的業(yè)務(wù)流程去搭建系統(tǒng)，如供應(yīng)鏈最初在大家電 3W 行業(yè)孕育，我們按照 3W 的行業(yè)和業(yè)務(wù)場景搭建了平臺商家相適應(yīng)的計劃系統(tǒng);后續(xù)自營行業(yè)又根據(jù)自己的行業(yè)也搭建了自營的計劃系統(tǒng);后續(xù)小電數(shù)碼、國際以及其他業(yè)務(wù)快速發(fā)展，跟隨業(yè)務(wù)快跑的同時，也各自建立的各自的業(yè)務(wù)流程。在這個過程中，BPM 為建造不同的業(yè)務(wù)系統(tǒng)提供非常好的抽象支撐，但是經(jīng)常的結(jié)果是，BPM 被用作構(gòu)建了更高層抽象的，也更高效的，但是卻是煙囪式的應(yīng)用，而不沒有更好的貢獻(xiàn)更多的支撐到整體上能快速應(yīng)對業(yè)務(wù)變化而更靈活，更敏捷的業(yè)務(wù)平臺或者系統(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)一管理和演化升級。
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 對于創(chuàng)建單獨(dú)的業(yè)務(wù)應(yīng)用或許非常有用，但是通常是創(chuàng)建的煙囪式的應(yīng)用，很難擴(kuò)展到企業(yè)內(nèi)或者平臺內(nèi)不同的業(yè)務(wù)線。如果只有 SOA 而沒有BPM雖然可以創(chuàng)建可重用且一致性高的服務(wù)，但是缺少將這些服務(wù)快速搭建業(yè)務(wù)流程并支撐端到端業(yè)務(wù)的能力，也無法支撐建立具有競爭力且可以隨著外部競爭環(huán)境進(jìn)行敏捷反應(yīng)的業(yè)務(wù)。
下圖顯示了一個建議的的封層服務(wù)化架構(gòu)圖，各分層如下：
- 端到端業(yè)務(wù)流程
業(yè)務(wù)流程是按照一定業(yè)務(wù)規(guī)則決定的順序執(zhí)行的業(yè)務(wù)操作組成。高層級的業(yè)務(wù)功能，通?？缭綉?yīng)用域或者業(yè)務(wù)線。通常由行業(yè)開發(fā)團(tuán)隊開發(fā)，此行業(yè)開發(fā)團(tuán)隊可以具備明確的實現(xiàn)組織結(jié)構(gòu)，也可以由跨團(tuán)隊的相關(guān)域共同組成虛線團(tuán)隊。例如，電商業(yè)務(wù)中，用戶選購下單交互流程;供應(yīng)鏈業(yè)務(wù)中的補(bǔ)貨調(diào)撥計劃流程等。
- 平臺業(yè)務(wù)服務(wù)
高度模塊化的業(yè)務(wù)功能單元，由不同類型的子域服務(wù)組合編排而來，可作為業(yè)務(wù)流程的編排單元?？缧袠I(yè)通用的業(yè)務(wù)服務(wù)可由功能所在核心域開發(fā)團(tuán)隊編排開發(fā)，行業(yè)內(nèi)通用的業(yè)務(wù)服務(wù)可以由行業(yè)開發(fā)團(tuán)隊負(fù)責(zé)編排開發(fā)。例如，補(bǔ)貨審批服務(wù)
- 子域服務(wù)
平臺各功能子域提供的服務(wù)，對平臺可見，用于平臺業(yè)務(wù)服務(wù)的組合編排，也可以作為更高層的業(yè)務(wù)流程編排的基礎(chǔ)單元。子域服務(wù)通常由平臺各子域開發(fā)團(tuán)隊負(fù)責(zé)開發(fā)。例如，銷量計劃服務(wù)，補(bǔ)貨建議計算服務(wù)。
- 子域基礎(chǔ)服務(wù)
用于支撐各功能子域服務(wù)的基礎(chǔ)服務(wù)，對子域可見，對平臺不可見，用于子域服務(wù)的編排。
子域基礎(chǔ)服務(wù)通常由平臺各子域開發(fā)團(tuán)隊負(fù)責(zé)開發(fā)。例如，入倉決策服務(wù)，計劃單據(jù)服務(wù)，計劃庫存服務(wù)等。
- 基礎(chǔ)子域服務(wù)
或稱為基礎(chǔ)業(yè)務(wù)域服務(wù)，提供平臺基礎(chǔ)業(yè)務(wù)服務(wù)，為各個功能子域或平臺業(yè)務(wù)服務(wù)提供基礎(chǔ)業(yè)務(wù)功能及數(shù)據(jù)服務(wù)。例如：商家服務(wù)，貨品服務(wù)，庫存服務(wù)等。
- 基礎(chǔ)架構(gòu)服務(wù)層
提供不同層次所公用的基礎(chǔ)架構(gòu)服務(wù)，如用用戶管理，權(quán)限管理，操作審計等等。
??
??
我們通常按照上述分層結(jié)構(gòu)來描述平臺架構(gòu)或者企業(yè)內(nèi)部架構(gòu)，看上去好像層次結(jié)構(gòu)清晰明了，但是卻是不完整的，因為此面向服務(wù)的架構(gòu)描述缺失了平臺系統(tǒng)架構(gòu)中一個核心部分，暨信息及信息模型分層，這一點(diǎn)非常之關(guān)鍵，往往會決定架構(gòu)的成功與否。
為了使架構(gòu)更完整同時也更真實，我們需要添加對應(yīng)的完整信息抽象(實體模型 or 領(lǐng)域模型)：
- 核心單據(jù)模型
端到端業(yè)務(wù)流程中操作的核心單據(jù)，承載業(yè)務(wù)核心價值的信息單元模型，例如，銷售訂單，采購訂單，補(bǔ)貨計劃單等。此模型通常是平臺公共語義模型的核心子集。
- 平臺公共語義模型
定義了平臺層業(yè)務(wù)流程、業(yè)務(wù)服務(wù)交互數(shù)據(jù)。在平臺層面或企業(yè)層面，端到端業(yè)務(wù)流程中交互信息的公共語義模型，此模型不僅對平臺業(yè)務(wù)流程中交互的各實體進(jìn)行了明確的定義，而且包含了業(yè)務(wù)流程中所需要的完整的業(yè)務(wù)語義實體，同時各業(yè)務(wù)語義實體邊界明確，責(zé)任清晰。核心單據(jù)模型通常是平臺公共語義模型的子集。平臺公共語義模型包含下層子域的對外服務(wù)實體子集，按照端到端的完整平臺業(yè)務(wù)語義，可由平臺各功能子域模型所共享給平臺的核心實體子集有機(jī)整合而成，也可由平臺業(yè)務(wù)模型全新定義，或者從 TOP-DOWN 以及 BOTTOM-UP 兩個方向共同融合而成。需要注意的是此模型必然是無法一蹴而就，需要經(jīng)過無數(shù)迭代而不斷完善，但其一定是不可或缺的。平臺的諸多架構(gòu)決策和不斷演化完善需要基于此模型來進(jìn)行。
- 子域領(lǐng)域模型
平臺各功能子域的領(lǐng)域模型，用于驅(qū)動各功能子域的應(yīng)用系統(tǒng)設(shè)計和開發(fā)。子域領(lǐng)域模型需要保持動態(tài)穩(wěn)定，通過防腐層同所依賴的外域或者外部服務(wù)進(jìn)行隔離，防止外部服務(wù)污染子域內(nèi)的核心業(yè)務(wù)語義，同時保持域內(nèi)業(yè)務(wù)功能靈活可控。子域領(lǐng)域模型僅通過其對外服務(wù)實體子集對外可見，其余對外不可見。
- 跨域映射模型
用于各子域領(lǐng)域模型實現(xiàn)對外部模型的防腐依賴。
- 基礎(chǔ)架構(gòu)服務(wù)層
提供不同層次所公用的基礎(chǔ)架構(gòu)信息模型，如用戶模型，權(quán)限模型等。
??
??
信息架構(gòu)模型框架
現(xiàn)在來討論下服務(wù)化分層架構(gòu)重視度并不太高的另一個重要側(cè)面：信息架構(gòu)，之所以說信息架構(gòu)非常之重要，是因為信息架構(gòu)與服務(wù)化架構(gòu)是一個密不可分的完整的整體。我對信息架構(gòu)模型進(jìn)行了分層劃分，下面從 TOP_DOWN 方向來討論不同的分層模型。
??
??
Level 0：戰(zhàn)略與決策模型(高層戰(zhàn)略視角)
這層次模型用于定義企業(yè)的戰(zhàn)略方向和商業(yè)目的，從而定義了企業(yè)內(nèi)任何系統(tǒng)平臺開發(fā)的方向和終局。這必然作為企業(yè)內(nèi)任何系統(tǒng)平臺開發(fā)的基本背景和基調(diào)，影響任何系統(tǒng)平臺開發(fā)項目的中長期目標(biāo)定義和終局設(shè)定。
Level 1：商業(yè)模式(業(yè)務(wù)線 owner 視角)
這層模型從業(yè)務(wù)線 owner 的視角，用運(yùn)營主體的業(yè)務(wù)術(shù)語描述其商業(yè)模式的本質(zhì)，包括其整體結(jié)構(gòu)，業(yè)務(wù)流程，以及組織結(jié)構(gòu)等。
Level 2：業(yè)務(wù)抽象概念模型
這層模型從業(yè)務(wù)架構(gòu)的視角用信息化的方式對單個業(yè)務(wù)線或者多個業(yè)務(wù)線的業(yè)務(wù)進(jìn)行抽象。Level 1 描述是對于企業(yè)業(yè)務(wù)來說有意義的東西或者事情，而 Level 2 則給予這些有意義的東西以更嚴(yán)格且清晰的定義，明確其內(nèi)涵以及外延并體系化，同時根據(jù)不同行業(yè)線的業(yè)務(wù)內(nèi)容進(jìn)行提取抽象，抽象出共性的內(nèi)容，用于更高效靈活的描述和定義業(yè)務(wù) 。
Level 1 描述的是業(yè)務(wù)運(yùn)營人員所感知的業(yè)務(wù)流程，Level 2 不僅描述了這些業(yè)務(wù)流程，更重要的是抽象并描述了了這些業(yè)務(wù)流程所應(yīng)該包含的底層業(yè)務(wù)功能。
同樣的，Level 1 描述對企業(yè)業(yè)務(wù)來講所有重要的東西，Level 2 描述的是組織想要管理的信息后面最根本的內(nèi)容。Level 1 描述的事情是 Level 2 定義的基本實體的實際業(yè)務(wù)中對應(yīng)的樣本或事例。
簡而言之，Level 2 是 Level 1 的抽象(Abstraction)與綜合(Synthesis)。 為了達(dá)成這一視圖，必須要仔細(xì)分析和歸納，有時候需要演繹的方式來定義出隱藏在企業(yè)業(yè)務(wù)運(yùn)營主體視圖下根本結(jié)構(gòu)和內(nèi)容。
Level 3：平臺公共語義模型
Level 3 層公共語義模型同 Level 2 層業(yè)務(wù)概念模型保持緊密一致，在此基礎(chǔ)上增加了服務(wù)化視角的語義。Level 3 公共語義模型描述的內(nèi)容是在必須在平臺層業(yè)務(wù)服務(wù)間共享的具有一致語義的業(yè)務(wù)實體和信息，是平臺層一致的共享信息模型。這層模型用于描述平臺層服務(wù)接口交互的共享信息，基于平臺完整業(yè)務(wù)語義下所有服務(wù)所公共數(shù)據(jù)的標(biāo)準(zhǔn)化視圖模型。簡而言之，平臺公共語義模型，定義了業(yè)務(wù)平臺層次基本業(yè)務(wù)服務(wù)語義，是平臺各業(yè)務(wù)服務(wù)之間，平臺業(yè)務(wù)流程和平臺業(yè)務(wù)服務(wù)交互的統(tǒng)一語言。
Level 4：域模型
Level 4 層域模型定位于平臺各子域的領(lǐng)域模型/實體模型，用于對各子域的核心業(yè)務(wù)功能進(jìn)行抽象。域模型是平臺各子域的標(biāo)準(zhǔn)模型，不僅明確定義的各子域功能服務(wù)暨服務(wù)接口的語義，同時也包含各子域內(nèi)服務(wù)實現(xiàn)中的關(guān)鍵實體的定義。域模型從整體上來說是平臺各子域的私有模型，除了服務(wù)語義外整體不對外可視。公共信息中的服務(wù)視圖是域模型的子集。
域模型核心用于除了用于暴露到平臺子域的業(yè)務(wù)服務(wù)設(shè)計與實現(xiàn)外，同時也用于驅(qū)動域內(nèi)服務(wù)功能的設(shè)計和實現(xiàn)。
域模型是需要保持動態(tài)穩(wěn)定的，除非域內(nèi)業(yè)務(wù)發(fā)生本質(zhì)變化，域模型應(yīng)該是相對穩(wěn)定的。域模型穩(wěn)定性最大的敵人是外部的依賴，如何不受外部依賴的侵蝕而逐漸腐敗，域防腐層存在的最主要原因。子域防腐層維護(hù)外部依賴服務(wù)和子域模型之間的動態(tài)映射，維護(hù)域模型的獨(dú)立性，保護(hù)域模型不受有害侵蝕。
域模型我理解基本和我們通常談的領(lǐng)域模型基本接近，對于各域內(nèi)業(yè)務(wù)的抽象，驅(qū)動各域技術(shù)設(shè)計方案設(shè)計和實現(xiàn)，至于具體的模型表現(xiàn)形式，采用基于亞里士多德的物質(zhì)本源的思想(“Material Cause,Formal Cause,Efficient Cause,Final Cause" —> 實體+屬性+關(guān)系)的ER圖，還是基于我們老祖宗老子道家思想("人法地、地法天、天法道、道法自然" —> 實體+行為)的思想的領(lǐng)域驅(qū)動 DDD 的方式，個人認(rèn)為各有伯仲，組中能清楚表達(dá)出業(yè)務(wù)本質(zhì)即可，后面單獨(dú)寫一篇抽象建模的文章聊一下這兩種不同的思想。
Level 5：實現(xiàn)模型
此層模型為開發(fā)者視角的實現(xiàn)模型，也就是我們系統(tǒng)實現(xiàn)核心的對象模型，是我們系統(tǒng)落地的基石。
設(shè)計服務(wù)
我們初步了解的什么是服務(wù)，以及什么是服務(wù)化的分層?那如何設(shè)計服務(wù)以及服務(wù)化架構(gòu)呢?下面給出基本步驟和方案。
一、理解整體背景
首先，我們要理解服務(wù)化架構(gòu)的整體背景。我們必須理解我們所支撐的業(yè)務(wù)和業(yè)務(wù)根本驅(qū)動力以及所有的業(yè)務(wù)流程，業(yè)務(wù)場景以及業(yè)務(wù)用例;同時對于平臺系統(tǒng)，我們還必須理解公司的戰(zhàn)略所賦予平臺的使命是什么?我們平臺中長期的目標(biāo)是什么?平臺的終局是什么?這些組合和在一起才是服務(wù)化架構(gòu)的完整的上下文背景。這些必須要反映到我們的業(yè)務(wù)模型、平臺公共語義模型和各域模型中去。
然后，我們需要提出并回答如下問題：
- 我們當(dāng)前支撐的是什么樣的業(yè)務(wù)?(業(yè)務(wù)模型)
- 這個業(yè)務(wù)或者這些業(yè)務(wù)的中長期目標(biāo)和短期目標(biāo)分別是什么?
- 平臺的短中長期目標(biāo)是什么?平臺的終局是什么?
- 上述目標(biāo)是否存在沖突，如何平衡和取舍?
- 實現(xiàn)這些目標(biāo)，需要完成什么樣的成果?
- 這些成果如何衡量?
- 取得這些成果，需要什么樣的能力和信息?
- 實現(xiàn)這些能力需要什么樣的流程、服務(wù)、實體以及規(guī)則
- 現(xiàn)有的服務(wù)、應(yīng)用或者系統(tǒng)提供了那些基本能力和信息?
前面六個問題描述了整體的架構(gòu)需求(包括業(yè)務(wù)和平臺)，而剩下的問題則描述了整個服務(wù)化架構(gòu)的上下文以及引入了服務(wù)目錄庫的需求。我們服務(wù)不能只從單個服務(wù)的角度來看，而必須從整個服務(wù)集合的角度來反應(yīng)完整的業(yè)務(wù)語義和平臺語義。我們的服務(wù)集合也就是服務(wù)目錄庫必須具備完整的上下文語義，必須能識別出：
- 整體的上下文背景，包括完整的業(yè)務(wù)語義和平臺語義。
- 服務(wù)職責(zé)范圍
- 關(guān)聯(lián)的服務(wù)的分組
- 服務(wù)的類型和角色
服務(wù)目錄庫的設(shè)計必須支持兩個主要的設(shè)計時目標(biāo)：
- 第一個目標(biāo)是要提供一種機(jī)制來幫助理解服務(wù)整體的上下文背景，用于更好的服務(wù)選擇及更高效的服務(wù)重用。特別是，這個服務(wù)實現(xiàn)了什么樣的責(zé)任，以及如何和其他的服務(wù)相關(guān)聯(lián)。
- 第二個目標(biāo)是要提供一種機(jī)制來識別一個特定服務(wù)的責(zé)任邊界，用來指引服務(wù)的實現(xiàn)。這是一個非常關(guān)鍵的點(diǎn)，特別是在避免服務(wù)的功能和數(shù)據(jù)重復(fù)上非常重要，不僅僅是避免重復(fù)建設(shè)，更核心的是要以此保證業(yè)務(wù)功能和數(shù)據(jù)的一致性。
服務(wù)目錄庫中的服務(wù)可以按照服務(wù)類型以及服務(wù)角色來進(jìn)行組織。服務(wù)類型請參照服務(wù)化分層架構(gòu)內(nèi)容里的描述;服務(wù)角色包含任務(wù)服務(wù)角色、實體服務(wù)角色和決策服務(wù)角色，請參照后面小節(jié)描述。
二、服務(wù)設(shè)計原則
面向服務(wù)化的架構(gòu)的其中一個成功的關(guān)鍵是創(chuàng)建一個具備完整業(yè)務(wù)語義的服務(wù)集合以便于可以方便一起進(jìn)行組合編排來支撐不同的業(yè)務(wù)流程以及豐富的業(yè)務(wù)場景。
我們經(jīng)常談?wù)摳鞴δ苡蛞峁┧神詈系姆?wù)，是因為服務(wù)間的松耦合是非常重要的，特別是通過減少服務(wù)間的依賴以便于服務(wù)可以在不同的場景中被復(fù)用，以及可以起到隔離變更影響的作用。但是如何才能盡可能的實現(xiàn)這個目標(biāo)呢?
首先我們來看下對于服務(wù)最重要點(diǎn)是什么?首先就是這個服務(wù)提供了什么樣的業(yè)務(wù)功能，其次這個服務(wù)對業(yè)務(wù)有價值的數(shù)據(jù)產(chǎn)生了那些影響。從這兩個點(diǎn)上我們就可以比較容易得出兩種類型的耦合在服務(wù)接口設(shè)計中是特別重要的：
- 數(shù)據(jù)依賴
- 功能依賴
舉例來說明下：
交易服務(wù)協(xié)調(diào)所有的活動，然后依賴其他服務(wù)來幫助完成流程。交易服務(wù)依賴于或者說耦合于用戶服務(wù)，商品服務(wù)，庫存服務(wù)，營銷服務(wù)、訂單服務(wù)以及支付服務(wù)等。
為啥交易服務(wù)沒有實現(xiàn)所有的功能?
首先是因為我們想在其他高級別流程或者服務(wù)中重用底層的能力。
第二是交易服務(wù)服務(wù)并不負(fù)責(zé)用戶服務(wù)，商品服務(wù)，庫存服務(wù)，營銷服務(wù)、訂單服務(wù)以及支付服務(wù)。交易服務(wù)只是使用它們，而不是負(fù)責(zé)實現(xiàn)它們。
用戶服務(wù)被用作管理客戶信息訪問，它具有唯一的責(zé)任來提供、維護(hù)和更新客戶信息，這樣做的目的是為了可以在任何需要訪問客戶數(shù)據(jù)服務(wù)的地方重用客戶服務(wù)。比代碼重用更重要的是隔離或者是集中式訪問客戶信息，因為只有唯一的路徑訪問數(shù)據(jù)，數(shù)據(jù)就總是一致的，真正實現(xiàn) Source Of Truth。因此，盡管有很多服務(wù)包含交易服務(wù)，購物車，訂單歷史等服務(wù)需要訪問客戶服務(wù),通過松耦合的這種模式去管理這些依賴是比較容易被理解的。
通過創(chuàng)建服務(wù)來執(zhí)行用戶管理，商品管理，庫存管理，以及營銷管理等，就可以在任何可以用到的地方，執(zhí)行保持一致性的這些業(yè)務(wù)功能。
敲黑板：好的服務(wù)設(shè)計并不僅僅是關(guān)注重用性，更重要的是要提供一致性,既包含功能一致性，也包含數(shù)據(jù)一致性。
那么下一個問題是你如何決定有哪些服務(wù)以及這些服務(wù)分別是什么呢?同樣，你用功能分解和信息隔離組合在一起來決定服務(wù)有哪些并且各自是什么?
- 對線上交易功能的分解引導(dǎo)去識別用戶、商品、庫存、營銷、訂單以及支付等相關(guān)功能服務(wù)。
- 對信息的隔離引導(dǎo)我們?nèi)プR別用戶和商品等作為交易訂單中的共享信息。
- 面向服務(wù)的架構(gòu)中服務(wù)設(shè)計的問題需要跨越多個以致于所有的流程中來一起考慮。
因此，服務(wù)設(shè)計原則基本原則如下：
- 避免服務(wù)間的功能重復(fù)
- 避免服務(wù)間的功能缺失
- 避免數(shù)據(jù)重復(fù)
- 實現(xiàn)數(shù)據(jù)的協(xié)同訪問
- 具備統(tǒng)一、一致的方式來執(zhí)行給定的功能
在服務(wù)化設(shè)計中，如何實現(xiàn)上述的這些原則呢?答案是提出并回答如下問題：
- 誰負(fù)責(zé)這個功能?
- 這個功能在哪里被用到的?
- 誰負(fù)責(zé)管理這些指定的數(shù)據(jù)?
- 誰負(fù)責(zé)定義和實現(xiàn)那些特別的業(yè)務(wù)規(guī)則
- 流程中的哪個步驟具備執(zhí)行這個任務(wù)所需要的特定的知識
這些問題的答案會幫你來識別如下信息：
- 服務(wù)應(yīng)該做什么?
- 服務(wù)對什么負(fù)責(zé)?
- 同樣重要的是，識別服務(wù)不應(yīng)該做什么，而應(yīng)該依賴其他的服務(wù)來支撐
三、服務(wù)顆粒度與類型
我們通常設(shè)計服務(wù)時候一個很大的疑惑是我的服務(wù)到底要設(shè)計成什么樣的顆粒度，應(yīng)該更粗粒度一些，還是更細(xì)粒度一些?答案是：沒有一個統(tǒng)一正確的服務(wù)顆粒度標(biāo)準(zhǔn)。那怎么辦?我如何設(shè)計我的服務(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)平臺中，我們可以預(yù)期到多種多樣類型的服務(wù)。這些服務(wù)具有不同的類型和顆粒度，可以參考服務(wù)化分層中的內(nèi)容，也可以見下面的描述：
- 端到端的業(yè)務(wù)流程
業(yè)務(wù)流程通?？缭秸麄€企業(yè)或者平臺多個業(yè)務(wù)域，通常是由底層服務(wù)構(gòu)建而成
- 平臺業(yè)務(wù)服務(wù)
業(yè)務(wù)服務(wù)是最粗粒度的服務(wù)，業(yè)務(wù)服務(wù)提供高度抽象的，組合的業(yè)務(wù)功能給到平臺或者企業(yè)。業(yè)務(wù)服務(wù)的功能和數(shù)據(jù)同業(yè)務(wù)流程所需要的業(yè)務(wù)語義緊密結(jié)合。數(shù)據(jù)整合服務(wù)在這個層次提供端到端的業(yè)務(wù)流程所需要的整合后的數(shù)據(jù)。
- 子域服務(wù)
子域服務(wù)是中等粒度的，他們提供特別針對于每個業(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ù)功能完整實現(xiàn)。
- 基礎(chǔ)架構(gòu)服務(wù)層
基礎(chǔ)架構(gòu)提供了在更高層級服務(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)建以外的另外一個重要考量或者說是側(cè)面是：服務(wù)在服務(wù)組合或者流程編排中所承擔(dān)的角色是什么?
那么怎么來區(qū)分不同的角色呢?我們使用關(guān)注點(diǎn)隔離的架構(gòu)原則。例如，我們在構(gòu)建應(yīng)用中就使用了將數(shù)據(jù)同邏輯隔離作為重要的概念。這樣不僅提供了不同關(guān)注點(diǎn)解耦的可能以及機(jī)會，而且允許采用不同的方式，在不同的地方來實現(xiàn)這些不同的關(guān)注點(diǎn)。
對業(yè)務(wù)流程進(jìn)行單獨(dú)管理的BPM就是一個非常好的例子，BPM作為另外一個關(guān)注點(diǎn)分離的例子，將業(yè)務(wù)流程方案從其他邏輯中分離出來，可以使工作流程可以在一個特定的層次或者環(huán)境內(nèi)進(jìn)行執(zhí)行和管理, 這樣就可以實現(xiàn)通過快速的建立新的流程模型來快速響應(yīng)業(yè)務(wù)的變化。同時面向服務(wù)的架構(gòu)SOA提供了將業(yè)務(wù)服務(wù)作為構(gòu)建業(yè)務(wù)流程的基礎(chǔ)構(gòu)件的功能。業(yè)務(wù)規(guī)則系統(tǒng)BRMS同樣也作為一個關(guān)注點(diǎn)分離的例子，將業(yè)務(wù)規(guī)則或者業(yè)務(wù)決策從其他應(yīng)用邏輯中區(qū)分開來，這樣業(yè)務(wù)規(guī)則和業(yè)務(wù)決策也可以在一個特定的層次被執(zhí)行和管理，從而就可以很容易的被變更來支持新的業(yè)務(wù)需求。這里，業(yè)務(wù)規(guī)則以及決策服務(wù)也是面向服務(wù)的機(jī)構(gòu)來暴露出規(guī)則和決策服務(wù)來支撐規(guī)則和決策與業(yè)務(wù)流程的分離。
通常我們通過較粗粒度的來定義三大類服務(wù)角色來構(gòu)建不同的服務(wù)層次：
- 任務(wù)服務(wù)角色
任務(wù)服務(wù)通常實現(xiàn)一個完整的業(yè)務(wù)功能，既可以是基本業(yè)務(wù)功能，也可以是復(fù)雜的業(yè)務(wù)功能，如計算某個貨品在某個倉的補(bǔ)貨量，或者一個簡單的業(yè)務(wù)校驗，如此貨品在此倉是否可補(bǔ)。
此服務(wù)類型顆粒度范圍較廣，包含從獨(dú)立的子域基礎(chǔ)服務(wù)到大的平臺業(yè)務(wù)服務(wù)都可以具有任務(wù)服務(wù)角色，更小顆粒度的服務(wù)傾向于具有更通用的目的,更大的可重用的潛力。業(yè)務(wù)服務(wù)幾乎總是承擔(dān)任務(wù)服務(wù)的角色，通常是小顆粒度服務(wù)較大的組合，可以被設(shè)計成支持一個或者更多特定的流程。因此這些服務(wù)通常在跨業(yè)務(wù)流程中廣泛復(fù)用的潛力更低。但是也是正常的，因為他們通常是有其他可重用的服務(wù)組成的。
通常，具有業(yè)務(wù)角色的服務(wù)是主動服務(wù)，通過主動行為來提供價值
- 實體服務(wù)角色
主要管理訪問業(yè)務(wù)實體的服務(wù)具有這個角色。業(yè)務(wù)實體的例子如用戶、類目、商品、價格、庫存、購物車，主要對應(yīng)主要的業(yè)務(wù)信息。實體通常是中到大型實體，傾向于獨(dú)立于任何特定的業(yè)務(wù)流程,而可做為多個不同業(yè)務(wù)流程的組成部分。具有實體服務(wù)角色的服務(wù)通常通過適配和提供需要的信息來實現(xiàn)任務(wù)的方式來支撐任務(wù)服務(wù)。實體服務(wù)通常都具備較大的重用的潛力。
- 規(guī)則 / 決策服務(wù)角色
規(guī)則 / 決策服務(wù)是通過執(zhí)行業(yè)務(wù)規(guī)則來提供業(yè)務(wù)決策的服務(wù)，如補(bǔ)貨計劃自動審核服務(wù)。
規(guī)則 / 決策服務(wù)通常用作對復(fù)雜問題進(jìn)行判斷或者支持變化頻繁的業(yè)務(wù)規(guī)則，如復(fù)雜且多變的審核規(guī)則等。
規(guī)則 / 決策服務(wù)通常為小到中等大小顆粒度，通常用來組裝成更大的服務(wù)。規(guī)則/決策服務(wù)是可以不同層次不同類型的服務(wù)，包括平臺業(yè)務(wù)服務(wù)，子域服務(wù)，子域基礎(chǔ)服務(wù)等，但是通常情況下規(guī)則/決策服服務(wù)也來支撐這些服務(wù)類型。??
??
我們通過組合這些不同類型的服務(wù)角色來提供靈活的業(yè)務(wù)能力，從而用來支持業(yè)務(wù)流程內(nèi)的活動。我們提供了一些基本原則來幫助我們進(jìn)行服務(wù)組合以便于幫我們減少依賴，限制耦合以及最大化靈活性。
服務(wù)層次以及組合基本原則：
- 業(yè)務(wù)流程的任務(wù)通過任務(wù)服務(wù)實現(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ù)
- 一個任務(wù)服務(wù)可以組合規(guī)則/決策服務(wù)、實體服務(wù)以及其他任務(wù)服務(wù)
- 但是一個實體服務(wù)不允許直接調(diào)用其他實體服務(wù)
現(xiàn)在我們可以通過豐富的流程，實體和決策服務(wù)的集合，可以創(chuàng)建新的不同的服務(wù)組合，把規(guī)則的靈活可變的好處同服務(wù)化架構(gòu)的模塊化，靈活性以及重用性結(jié)合起來作為業(yè)務(wù)系統(tǒng)平臺級別的基本架構(gòu)方式。
服務(wù)化如何成功?
一、大規(guī)劃
大的規(guī)劃首先要明確 2-3 年內(nèi)的服務(wù)化的目標(biāo)。大的規(guī)劃切記事無巨細(xì)，而是根據(jù)長期規(guī)劃設(shè)定明確的指導(dǎo)性原則和要求，在體系化的基礎(chǔ)上鼓勵協(xié)同和創(chuàng)新。
二、小目標(biāo)
服務(wù)化不應(yīng)該是運(yùn)動式的大躍進(jìn)推進(jìn)，而應(yīng)該是堅持試點(diǎn)、推廣、總結(jié)、擴(kuò)大試點(diǎn)，從而由點(diǎn)到面，逐步落實的方法，由各域根據(jù)規(guī)劃的體系化要求，再各自情況暨各自成熟度來設(shè)定各自服務(wù)化目標(biāo)，制定一個個小目標(biāo)，快速迭代，敏捷式的總結(jié)推進(jìn)。
三、真共識
建立共識的根本是要講清楚服務(wù)化的目標(biāo)、架構(gòu)、設(shè)計、開發(fā)背后的清楚的邏輯，讓每個人想的清楚，聽的明白。
四、接地氣
接地氣同達(dá)成共識一樣，要用樸素的工程師語言講清楚目標(biāo)和邏輯，而不是拿各種看上去非常光鮮亮麗的各種名詞來充當(dāng)臺面，講的人解釋不清楚，聽得人一頭霧水，沒有體系化邏輯來支撐落地，最終很難達(dá)到服務(wù)化真正的目標(biāo)的。
五、結(jié)硬寨
服務(wù)化是一個龐大的，迭代的，漸進(jìn)的體系化工程，不是快閃戰(zhàn)，不是突襲戰(zhàn)，是場持久戰(zhàn)，一定要有曾國藩的“結(jié)硬寨，打呆仗”的耐心和準(zhǔn)備，踏踏實實落地迭代推進(jìn)，小步快跑，在堅持體系化思考的基礎(chǔ)上進(jìn)行持續(xù)總結(jié)改進(jìn)，通過一個接一個戰(zhàn)斗，一個小勝利接一個小勝利，一個戰(zhàn)役接一個戰(zhàn)役不停的攻城略地的基礎(chǔ)上逐漸邁向成功。
六、Think Fast & Slow
一句話，高效的方式就是慢想、快干。我們不一定缺少高執(zhí)行力的人，但是一定缺少能獨(dú)立思考并體系化行事的人。
本文題目：做了那么多架構(gòu)，你真的懂SOA了嗎？
標(biāo)題網(wǎng)址：http://m.fisionsoft.com.cn/article/cdejgcc.html
