1 前言

1.1 架構(gòu)分類

在軟件設(shè)計領(lǐng)域，企業(yè)架構(gòu)通常被劃分為如下五種分類：

如何理解架構(gòu)分類依據(jù)及其彼此之間的關(guān)系？業(yè)務(wù)是企業(yè)賴以生存之本，因此業(yè)務(wù)架構(gòu)是基礎(chǔ)、是靈魂，其他一切均是對業(yè)務(wù)架構(gòu)的支撐；根據(jù)業(yè)務(wù)架構(gòu)形成與之相應(yīng)的產(chǎn)品架構(gòu)和數(shù)據(jù)架構(gòu)；最后通過技術(shù)架構(gòu)落地實(shí)施。

應(yīng)用架構(gòu)用于對產(chǎn)品架構(gòu)進(jìn)行細(xì)分，通過應(yīng)用集成形成產(chǎn)品。但是應(yīng)用架構(gòu)區(qū)別于產(chǎn)品架構(gòu)的本質(zhì)不應(yīng)該只在粒度，更重要的是產(chǎn)品直接承接業(yè)務(wù)，按照業(yè)務(wù)問題域進(jìn)行劃分；而應(yīng)用需要考慮通用能力沉淀和復(fù)用，為多個產(chǎn)品提供統(tǒng)一支撐。

• 業(yè)務(wù)架構(gòu)：業(yè)務(wù)需求初期，將模糊的需求描述為清晰的問題域，主要包括業(yè)務(wù)規(guī)劃、業(yè)務(wù)模塊、業(yè)務(wù)流程。
• 產(chǎn)品架構(gòu)：脫胎于業(yè)務(wù)架構(gòu)（主要是業(yè)務(wù)流程和業(yè)務(wù)模塊），關(guān)注的是功能的枚舉和分類。
• 數(shù)據(jù)架構(gòu)：從問題定義的視角，邏輯（流程）+ 數(shù)據(jù)是兩個核心。業(yè)務(wù)架構(gòu)分析流程的同時，另一個核心就是定義數(shù)據(jù)架構(gòu)，結(jié)合流程和數(shù)據(jù)形成產(chǎn)品。在實(shí)踐過程中數(shù)據(jù)架構(gòu)的工作往往被置于產(chǎn)品架構(gòu)或者應(yīng)用架構(gòu)內(nèi)部，從全局視角看這是一種誤區(qū)，數(shù)據(jù)作為企業(yè)寶貴資產(chǎn)，其架構(gòu)的好壞直接影響企業(yè)競爭力，必須全局考量和設(shè)計。數(shù)據(jù)架構(gòu)要解決兩個關(guān)鍵問題 - 1.需要什么數(shù)據(jù) 2.如何存儲數(shù)據(jù)。
• 應(yīng)用架構(gòu)：應(yīng)用架構(gòu)用于對產(chǎn)品架構(gòu)進(jìn)行細(xì)分，在產(chǎn)品架構(gòu)的基礎(chǔ)上進(jìn)行更細(xì)粒度的問題拆解和職責(zé)劃分，并抽取可復(fù)用模塊沉淀形成基礎(chǔ)能力。應(yīng)用架構(gòu)的最貼近落地實(shí)現(xiàn)。
• 技術(shù)架構(gòu):上述四個架構(gòu)從問題定義視角出發(fā)，技術(shù)架構(gòu)從問題解決的視角出發(fā)，關(guān)注的是技術(shù)選型、開發(fā)框架、開發(fā)語言等。

1.2 SOA

自19年底開始，我的工作內(nèi)容就集中于供應(yīng)鏈領(lǐng)域中臺產(chǎn)品的建設(shè)，在建設(shè)過程中不可避免的一個關(guān)鍵詞就是服務(wù)化，對此不同人會有不同的看法，個人對服務(wù)化的理解更傾向于SOA，因此通過本文談一下對SOA的認(rèn)知。

SOA作為一種架構(gòu)風(fēng)格，從架構(gòu)分類的視角看更偏向于業(yè)務(wù)架構(gòu)的一個思想體系，可以作為方法論指導(dǎo)我們從業(yè)務(wù)模型定義開始一直到整體的業(yè)務(wù)架構(gòu)落地。SOA強(qiáng)調(diào)我們對業(yè)務(wù)本質(zhì)的思考和設(shè)計，通過共創(chuàng)的方式（方式而非形式）對業(yè)務(wù)本質(zhì)不斷的追溯、抽象、總結(jié)、歸納、演繹，用于提升業(yè)務(wù)靈活性、加快業(yè)務(wù)創(chuàng)新、提升業(yè)務(wù)效率；不應(yīng)該跳過業(yè)務(wù)架構(gòu)將其當(dāng)作一個應(yīng)用架構(gòu)或者技術(shù)架構(gòu)的術(shù)語。往往在談到服務(wù)化的時候，很多實(shí)踐就會用技術(shù)框架（平臺）來等價代換服務(wù)化的概念，追求將熱點(diǎn)的技術(shù)框架（如serverless、codeless）在現(xiàn)有系統(tǒng)中的落地作為整個服務(wù)化建設(shè)的主旋律，這樣的建設(shè)最終往往收效欠佳。原因就是技術(shù)框架的使用僅僅是術(shù)、是器，而服務(wù)化（SOA）的本質(zhì)是道、是法。

軟件架構(gòu)在SOA提出之后尚未發(fā)生變革性的突破，很多架構(gòu)思想如 EA分層架構(gòu)、微服務(wù)架構(gòu)、DDD架構(gòu) 等，大多都是在SOA架構(gòu)風(fēng)格的基礎(chǔ)上進(jìn)行不同角度的演化迭代，因此本文在闡述SOA的過程多少會存在其他架構(gòu)思想中的“影子”。

2 What、Why、How三個視角看SOA

2.1 What

2.1.1 術(shù)語

任何概念的定義，都有與之對應(yīng)的術(shù)語。

• 業(yè)務(wù)行為：具備一定業(yè)務(wù)語義的原子行為抽象。
• 業(yè)務(wù)流程：實(shí)現(xiàn)特定業(yè)務(wù)價值（滿足客戶需求）的一些列業(yè)務(wù)行為的有機(jī)組合。
• 業(yè)務(wù)服務(wù)：提供增值價值的業(yè)務(wù)行為或業(yè)務(wù)流程（需要特別說明的是業(yè)務(wù)服務(wù)既可以是業(yè)務(wù)流程也可以是業(yè)務(wù)行為、甚至兩者的組合）。具有明確業(yè)務(wù)功能定義和價值衡量標(biāo)準(zhǔn)（SLA）。
• 應(yīng)用組件：按照一定的相關(guān)性結(jié)構(gòu)化封裝的應(yīng)用功能（為方便理解，在不考慮分層的前提下，簡化等價于業(yè)務(wù)服務(wù)）的一個集合。用以提升應(yīng)用的一致性、靈活性，并實(shí)現(xiàn)重用。
• 應(yīng)用：應(yīng)用組件的有機(jī)集合，用來提供業(yè)務(wù)功能（單個或多個），為整個系統(tǒng)或者平臺提供增量價值支撐。京慧中的需求計劃、經(jīng)營計劃、庫存計劃、分銷補(bǔ)貨計劃、供給計劃（應(yīng)用之間也存在一定的層級概念，貼近業(yè)務(wù)本質(zhì)的理解）。
• 系統(tǒng)：一系列應(yīng)用及服務(wù)的有機(jī)組合（某些服務(wù)可以獨(dú)立為系統(tǒng)提供增量價值支撐，微服務(wù)架構(gòu)思想中有諸多體現(xiàn)），具備端到端的完整業(yè)務(wù)功能，體系化的提供用戶增量價值。我所建設(shè)的 京慧產(chǎn)品（供應(yīng)鏈計劃產(chǎn)品） 本身是系統(tǒng)的層面。
• 平臺：一個或多個系統(tǒng)的有機(jī)組合，具備整個業(yè)務(wù)線或者業(yè)務(wù)生態(tài)的端到端業(yè)務(wù)功能全集。以提供業(yè)務(wù)線或者業(yè)務(wù)生態(tài)整體業(yè)務(wù)價值為目標(biāo)。
• 架構(gòu)：代表的是一個系統(tǒng)的基礎(chǔ)元素構(gòu)成。體現(xiàn)在系統(tǒng)構(gòu)成的元素集合、元素之間的關(guān)系、與外部環(huán)境的交互，以及指導(dǎo)系統(tǒng)迭代演進(jìn)的原則。
• 架構(gòu)風(fēng)格：一系列符合共同特征和核心原則的架構(gòu)定義。

2.1.2 定義

SOA就是一種架構(gòu)風(fēng)格，致力于將業(yè)務(wù)功能保持一致的服務(wù)作為設(shè)計、構(gòu)建和編排組合業(yè)務(wù)流程（或者解決方案）的基本單元。

2.1.3 服務(wù)

服務(wù)是設(shè)計、構(gòu)建和編排組合一個完整業(yè)務(wù)實(shí)體中業(yè)務(wù)解決方案的基礎(chǔ)單元。

服務(wù)可以從表里兩個方向結(jié)合定義 - 服務(wù)是提供業(yè)務(wù)功能的原子單元（里），通過服務(wù)契約的方式管理（表）。

服務(wù)契約是服務(wù)消費(fèi)方與服務(wù)提供方交互的所有約定的集合，通常由如下元素構(gòu)成：
服務(wù)接口：接口定義，描述服務(wù)做什么、出入?yún)⒍x等，通常通過接口文檔的形式呈現(xiàn)。圍繞著一個核心的業(yè)務(wù)功能操作以及相關(guān)聯(lián)的操作。

• 服務(wù)策略： 服務(wù)雙方的隱性的共識，描述適應(yīng)場景、約束等。
• 服務(wù)水平：通過服務(wù)質(zhì)量、可用性、性能等各個方面衡量服務(wù)本身，基本等價于SLA，包含了服務(wù)的兩個重要方面的指標(biāo) - 業(yè)務(wù)指標(biāo)和技術(shù)指標(biāo)（技術(shù)指標(biāo)- RT、吞吐量、可用性、可靠性等；業(yè)務(wù)指標(biāo)-完成的業(yè)務(wù)功能的質(zhì)量或者完成度，e.g.補(bǔ)貨建議是否滿足業(yè)務(wù)預(yù)期的周轉(zhuǎn)缺貨KPI）。

服務(wù)契約中體現(xiàn)出來的管理屬性是服務(wù)區(qū)別于其他常見定義（模塊、組件等）的根本區(qū)別，我們通過服務(wù)契約來管理服務(wù)的全生命周期（設(shè)計、實(shí)現(xiàn)、部署、升級）。

服務(wù)實(shí)現(xiàn) - 對業(yè)務(wù)功能的實(shí)現(xiàn)，是對SOA核心本質(zhì)的映射。

• 服務(wù)實(shí)現(xiàn)：具有多種實(shí)現(xiàn)方式【編碼實(shí)現(xiàn) ｜編排其他服務(wù) ｜ 適配封裝現(xiàn)有應(yīng)用 ｜ 混合實(shí)現(xiàn)】。服務(wù)如何實(shí)現(xiàn)對于服務(wù)消費(fèi)方來說是透明的，即服務(wù)消費(fèi)方僅關(guān)心服務(wù)的what而非how。服務(wù)可以在保持接口不變的情況下在橫縱兩個方向改變（橫 根據(jù)不同行業(yè)不同場景提供不同的實(shí)現(xiàn)；縱 根據(jù)行業(yè)發(fā)展演進(jìn)服務(wù)）。

2.2 Why

為什么要選擇SOA？針對這個問題會有很多觀點(diǎn)

1. 職責(zé)清晰（接口定義）
2. 可靈活擴(kuò)展（接口與實(shí)現(xiàn)分離）
3. 高度可復(fù)用
4. 接口分類
5. 高度可管理

上述觀點(diǎn)都無法否定，因?yàn)樗鼈兛梢酝ㄟ^服務(wù)定義推演得到。其中前三個都是針對單個服務(wù)構(gòu)建來看，只要掌握足夠的技術(shù)手段就可以很容易的創(chuàng)建一個服務(wù)（單個服務(wù)），這并不是SOA的核心競爭力。SOA的目的遠(yuǎn)超接口技術(shù)細(xì)節(jié)的設(shè)計與定義，核心關(guān)注點(diǎn)在于服務(wù)的業(yè)務(wù)內(nèi)容以及內(nèi)涵（而非如何設(shè)計和實(shí)現(xiàn)）。在使用SOA總結(jié)提煉出的術(shù)與器的同時，不要忘記道和法。how to do很重要，指導(dǎo)的是做好一件事；但是what更重要，指導(dǎo)的是做對的事。

更深層次的剖析SOA的價值，我們需要回歸SOA的本質(zhì) - 致力于在企業(yè)內(nèi)的不同業(yè)務(wù)環(huán)境內(nèi)建設(shè)業(yè)務(wù)功能驅(qū)動的服務(wù)，并在此基礎(chǔ)上將服務(wù)組裝成更高價值/更高級別的業(yè)務(wù)流程（解決方案）。故而可以將SOA的價值總結(jié)為兩個關(guān)鍵點(diǎn)：

1. 賦能企業(yè)構(gòu)建具有業(yè)務(wù)價值的、具備完整業(yè)務(wù)語義的服務(wù)集合；
2. 基于服務(wù)集合，組織和編排服務(wù)，構(gòu)建敏捷&靈活的業(yè)務(wù)流程/解決方案?！久艚?服務(wù)可以快速調(diào)整、獨(dú)立演化；靈活 服務(wù)的業(yè)務(wù)功能定義明確（邊界清晰、內(nèi)聚性強(qiáng)），可靈活組合】

2.2.1 SOA價值的表現(xiàn)形式

• 一致性:一致性是SOA核心的價值體現(xiàn)，包括數(shù)據(jù)一致性和行為一致性【數(shù)據(jù) 提供業(yè)務(wù)一致&共識的公共數(shù)據(jù)訪問服務(wù)；行為 對外（業(yè)務(wù)流程、外部任務(wù)等）提供統(tǒng)一的入口】
• 解耦:通過分離減少功能與數(shù)據(jù)的依賴和耦合。服務(wù)作為獨(dú)立的業(yè)務(wù)功能單元，在應(yīng)用系統(tǒng)中可以協(xié)同工作，同時各自又具備各自清晰且獨(dú)立的業(yè)務(wù)目標(biāo)和生命周期。
• 模塊化&敏捷性:為業(yè)務(wù)的模塊化提供基礎(chǔ)；同時在模塊化實(shí)現(xiàn)的基礎(chǔ)上，模塊可以在多個業(yè)務(wù)流程和場景中被復(fù)用和靈活組合，從而支持業(yè)務(wù)快速創(chuàng)新。
• 高度可管理性:服務(wù)水平的定義保證了服務(wù)在支撐業(yè)務(wù)目標(biāo)的同時，可以跳出業(yè)務(wù)功能認(rèn)知進(jìn)行管理（可監(jiān)控、可優(yōu)化、可調(diào)整）。

2.3 How

相比于What和Why，SOA的實(shí)踐是一個很龐大的問題，本文選擇從服務(wù)設(shè)計的角度進(jìn)行剖析。

2.3.1 梳理上下文

對業(yè)務(wù)系統(tǒng)，理解我們所支持的業(yè)務(wù)及其核心驅(qū)動力，是我們做好服務(wù)化的前提；如果是平臺類系統(tǒng)，需要理解公司的戰(zhàn)略所賦予平臺的使命和平臺的終局目標(biāo)、中長期目標(biāo) 。換言之，第一步是理清服務(wù)化架構(gòu)的完整上下文背景。這些內(nèi)容需要映射到模型中（各層級模型，詳見下文分層設(shè)計）。如何梳理上下文，一種好的實(shí)踐方式是定義問題集。有一種觀點(diǎn)是提出好的問題 == 問題解決了一半，問題集定義：

通過上述8個問題描述了整個服務(wù)化架構(gòu)的上下文：

• 問題1-6:描述業(yè)務(wù)/平臺整體架構(gòu)需求梳理；
• 問題7:描述架構(gòu)需求梳理的結(jié)論；
• 問題8:引入了服務(wù)集合定義。服務(wù)集合是SOA建設(shè)的核心成果，需要從持續(xù)迭代演進(jìn)的視角去理解。

我們通過服務(wù)集合來反映完整的業(yè)務(wù)語義和平臺語義。怎樣確定服務(wù)集合是否具備完整的上下文語義，必須能識別出下述內(nèi)容：

• 完整的上下文背景
• 服務(wù)集合職責(zé)范圍
• 服務(wù)分組（體現(xiàn)服務(wù)關(guān)聯(lián)性）
• 服務(wù)的類型和角色

服務(wù)集合設(shè)計的兩個主要目標(biāo)

1. 提供一種機(jī)制來識別一個特定服務(wù)的責(zé)任邊界，指引服務(wù)實(shí)現(xiàn)。（重要 明確服務(wù)職責(zé)及邊界，避免重復(fù)建設(shè)，保障行為和數(shù)據(jù)一致性）
2. 提供一種機(jī)制來幫助理解服務(wù)整體的上下文背景，用于更高效的服務(wù)選擇、服務(wù)重用。（服務(wù)分類，服務(wù)間關(guān)聯(lián)性）

服務(wù)集合中的服務(wù)可以按照服務(wù)類型以及服務(wù)角色來進(jìn)行組織。服務(wù)類型參照服務(wù)化分層架構(gòu)描述，服務(wù)角色包含任務(wù)服務(wù)角色、實(shí)體服務(wù)角色、決策服務(wù)角色。

2.3.2 服務(wù)設(shè)計原則

SOA成功的關(guān)鍵之一是創(chuàng)建一個具備完整上下文語義（業(yè)務(wù)/平臺語義）的服務(wù)集合，以便于通過組合編排服務(wù)來支撐不同的業(yè)務(wù)流程和業(yè)務(wù)場景。面向服務(wù)的架構(gòu)中服務(wù)設(shè)計的問題要跨越多個甚至全部的流程來一起考慮。

首先，最容易想到的是松耦合，無論是SOA思想還是其他思想（e.g.OOP）松耦合都是基礎(chǔ)原則之一；通過減少服務(wù)間的依賴提升不同應(yīng)用場景下的復(fù)用性，隔離變更影響。耦合 - 服務(wù)間存在依賴關(guān)系。首先我們來看下對于服務(wù)最重要的兩個點(diǎn)：

• 服務(wù)提供的業(yè)務(wù)功能
• 服務(wù)對業(yè)務(wù)數(shù)據(jù)產(chǎn)生的影響

從上述兩個點(diǎn)我們比較容易得出兩種類型的耦合（依賴） - 數(shù)據(jù)和功能。這里會存在一個很基礎(chǔ)的問題為什么要產(chǎn)生依賴，從技術(shù)實(shí)現(xiàn)的角度看可以摒棄依賴實(shí)現(xiàn)一個大而全的服務(wù)。開發(fā)人員特別是習(xí)慣面向?qū)ο笏枷氲拈_發(fā)人員對松耦合/高內(nèi)聚已經(jīng)形成一種本能，很少會反思為什么要這么做 - 兩個方面（內(nèi)在 一致性保障；外在 能力復(fù)用）。好的服務(wù)設(shè)計不僅是關(guān)注重用性，更重要的是提供一致性（行為與數(shù)據(jù)）。

再有，如何決定有哪些服務(wù)以及服務(wù)是什么？還是從數(shù)據(jù)和功能出發(fā)，通過功能分解和數(shù)據(jù)隔離組合在一起來決定服務(wù)有哪些以服務(wù)分別是什么。由此擴(kuò)展所得的基本原則如下：

• 避免缺失
• 避免重復(fù)
• 保持一致性

如何實(shí)踐落地上述原則？可以借助問題集的定義和轉(zhuǎn)換：

2.3.3 服務(wù)集合設(shè)計

我們從分層、分類、顆粒度切分三個緊密聯(lián)系的方面來看服務(wù)集合設(shè)計。

服務(wù)分層

信息架構(gòu)是服務(wù)化分層架構(gòu)設(shè)計中會被忽視的一個重要側(cè)面，體現(xiàn)的是企業(yè)中不同角色的關(guān)注點(diǎn)。

• 戰(zhàn)略與決策 定義企業(yè)的戰(zhàn)略方向和商業(yè)目標(biāo)，指引企業(yè)內(nèi)部系統(tǒng)/平臺發(fā)展的方向和終局。
• 商業(yè)模式 用運(yùn)營主體的術(shù)語描述對企業(yè)業(yè)務(wù)有價值的事物。
• 業(yè)務(wù)抽象 用信息化的方式對單個業(yè)務(wù)線或者多個業(yè)務(wù)線的業(yè)務(wù)進(jìn)行抽象。從業(yè)務(wù)抽象開始進(jìn)入問題域定義。
• 公共語義模型 在業(yè)務(wù)抽象的基礎(chǔ)上增加服務(wù)化的語義。公共語義模型描述的是在平臺各業(yè)務(wù)服務(wù)間共享的具有一致語義的業(yè)務(wù)實(shí)體和信息，需要在平臺層達(dá)成共識。
• 子域領(lǐng)域模型 是各子域的核心業(yè)務(wù)功能的抽象，包括服務(wù)定義及服務(wù)實(shí)現(xiàn)中的關(guān)鍵實(shí)體的定義。從整體視角來看是平臺各子域的私有模型，除了服務(wù)語義之外整體不對外可視。
• 開發(fā)實(shí)現(xiàn)模型 等價于OOP中的對象模型，是開發(fā)和落地的基石。

商業(yè)模式與業(yè)務(wù)抽象的關(guān)系

1-商業(yè)模式描述業(yè)務(wù)運(yùn)營人員感知的業(yè)務(wù)流程；業(yè)務(wù)抽象不僅描述業(yè)務(wù)流程，更重要的是抽象描述業(yè)務(wù)流程所應(yīng)該包含的底層業(yè)務(wù)功能。
2-商業(yè)模式描述對企業(yè)業(yè)務(wù)來講所有重要的事物；業(yè)務(wù)抽象描述企業(yè)業(yè)務(wù)想要事物背后的最根本的內(nèi)容。

雖然從層級結(jié)構(gòu)上看商業(yè)模式是業(yè)務(wù)抽象的上層，但是商業(yè)模式描述的東西是業(yè)務(wù)抽象定義所對應(yīng)的樣本或?qū)嵗◤母拍钌蟻碇v業(yè)務(wù)抽象的范圍更寬泛）。業(yè)務(wù)抽象是商業(yè)模式的抽象與綜合，必須要仔細(xì)分析和歸納、甚至通過演繹的方式來定義出隱藏在企業(yè)業(yè)務(wù)運(yùn)營主體背后的根本內(nèi)容和結(jié)構(gòu)。

公共語義模型與子域領(lǐng)域模型的關(guān)系

公共語義模型用于描述平臺層服務(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)一語言，強(qiáng)調(diào)統(tǒng)一和共享。而子域領(lǐng)域模型是平臺各域的私有模型，用于驅(qū)動子域內(nèi)服務(wù)功能的設(shè)計與實(shí)現(xiàn)。除非域內(nèi)業(yè)務(wù)發(fā)生本質(zhì)變化，子域領(lǐng)域模型需要保持動態(tài)穩(wěn)定，通過防腐層隔離外部依賴的侵蝕 （領(lǐng)域模型也是DDD思想的核心）。

服務(wù)分層是服務(wù)化分層架構(gòu)設(shè)計的主體。理解服務(wù)分層架構(gòu)的一個好的方式是學(xué)習(xí)一下 TOGAF Meta-Model。

• 業(yè)務(wù)流程（端到端）:按照一定業(yè)務(wù)規(guī)則決定的順序執(zhí)行的業(yè)務(wù)操作。高層級的業(yè)務(wù)功能通?？缍鄠€應(yīng)用子域/業(yè)務(wù)條線。
• 業(yè)務(wù)服務(wù)（平臺/系統(tǒng)）:高度模塊化的業(yè)務(wù)功能單元。由不同類型的子域服務(wù)組合編排而來，可作為業(yè)務(wù)流程的編排單元。
• 子域服務(wù):功能子域提供的服務(wù)，對平臺可見，用于平臺業(yè)務(wù)服務(wù)的組合編排，也可以作為更高層的業(yè)務(wù)流程編排的基礎(chǔ)單元。
• 子域基礎(chǔ)服務(wù):用于支撐各功能子域服務(wù)的基礎(chǔ)服務(wù)，對子域可見，對平臺不可見，用于子域服務(wù)的編排。
• 基礎(chǔ)子域服務(wù):或稱之為基礎(chǔ)業(yè)務(wù)域服務(wù)，提供平臺基礎(chǔ)業(yè)務(wù)服務(wù)，為各個功能子域或平臺業(yè)務(wù)服務(wù)提供基礎(chǔ)業(yè)務(wù)功能及數(shù)據(jù)服務(wù)（e.g.商家服務(wù)、貨品服務(wù)、庫存服務(wù)）
• 基礎(chǔ)架構(gòu)服務(wù):提供不同層次所共用的基礎(chǔ)架構(gòu)服務(wù)（e.g.用戶管理、權(quán)限管理）

模型分層是對服務(wù)分層的重要補(bǔ)充。服務(wù)分層從結(jié)構(gòu)上看是清晰和完整的，但是從服務(wù)化建設(shè)的整體視角看卻并不完整，我們需要添加與之對應(yīng)的模型抽象。

• 核心模型:端到端的業(yè)務(wù)流程承載業(yè)務(wù)核心價值的信息模型。在供應(yīng)鏈領(lǐng)域中是單據(jù)模型，e.g.銷售訂單、采購訂單、補(bǔ)貨計劃單。
• 公共語義模型:定義了平臺層面業(yè)務(wù)流程、業(yè)務(wù)服務(wù)交互數(shù)據(jù)。在平臺層面或者企業(yè)層面，端到端的業(yè)務(wù)流程中交互信息的公共語義模型定義了業(yè)務(wù)流程中所需要的完整的業(yè)務(wù)語義的實(shí)體定義（各業(yè)務(wù)語義實(shí)體邊界明確、責(zé)任清晰）。核心模型通常是公共語義模型的子集。平臺公共語義模型包含下層子域的對外服務(wù)實(shí)體子集，按照端到端的完整平臺業(yè)務(wù)語義，可以由平臺各功能子域模型所共享給平臺的核心實(shí)體子集有機(jī)整合而成，也可以由平臺業(yè)務(wù)模型全新定義（從top-down與bottom-up兩個方向共同融合而成）。此模型需要不斷迭代演進(jìn)，平臺的諸多架構(gòu)決策和完善都是基于此模型來進(jìn)行。
• 子域領(lǐng)域模型:平臺各功能子域的領(lǐng)域模型用于驅(qū)動各功能子域的應(yīng)用系統(tǒng)設(shè)計和開發(fā)。（同服務(wù)分層描述 需要保持動態(tài)穩(wěn)定，通過防腐層對外部服務(wù)進(jìn)行隔離，防止外部服務(wù)污染子域內(nèi)的核心業(yè)務(wù)語義，同時保持域內(nèi)業(yè)務(wù)功能靈活可控。子域領(lǐng)域模型僅通過其對外服務(wù)實(shí)體對外可見，其他均對外不可見。）
• 跨域映射模型:用于各子域領(lǐng)域模型實(shí)現(xiàn)對外部模型的防腐依賴。
• 基礎(chǔ)架構(gòu)服務(wù)模型:提供跳出層級之外的公用的基礎(chǔ)架構(gòu)信息模型，如用戶模型、權(quán)限模型。

服務(wù)分類

服務(wù)分類（或稱服務(wù)角色）是獨(dú)立于職責(zé)范圍、服務(wù)粒度之外的另一個重要因素；用于標(biāo)識服務(wù)在組合/流程編排中所扮演的角色是什么。
如果說服務(wù)分層是縱向切分，服務(wù)分類就是橫切面。借鑒OOP與AOP的理念，對服務(wù)分類的定義我們使用關(guān)注點(diǎn)分離的架構(gòu)原則。

通常我們通過較粗粒度來定義三大類服務(wù)：

• 任務(wù)服務(wù):任務(wù)服務(wù)通常實(shí)現(xiàn)一個完整的業(yè)務(wù)功能，既可以是基本業(yè)務(wù)功能，也可以是復(fù)雜的業(yè)務(wù)功能。此服務(wù)類型顆粒度粗，包含從獨(dú)立的子域基礎(chǔ)服務(wù)到平臺業(yè)務(wù)服務(wù)都可以具有任務(wù)服務(wù)角色。業(yè)務(wù)服務(wù)通常承擔(dān)任務(wù)服務(wù)的角色，本身是由小顆粒度服務(wù)較大的組合（流程），可以被設(shè)計成支持一個或者更多待定的流程。任務(wù)服務(wù)的針對性強(qiáng)，復(fù)用能力弱。通常，具有任務(wù)服務(wù)是主動服務(wù)，通過主動行為來進(jìn)行價值輸出。
• 實(shí)體服務(wù):管理訪問業(yè)務(wù)實(shí)體的服務(wù)。舉例來看，e.g.用戶、類目、商品、購物車。實(shí)體服務(wù)通常獨(dú)立于任何特定的業(yè)務(wù)流程，可作為多個不同業(yè)務(wù)流程的組成部分。實(shí)體服務(wù)通常通過是配合提供需要的信息來實(shí)現(xiàn)任務(wù)的方式來支撐任務(wù)服務(wù)。實(shí)體服務(wù)通常具備很強(qiáng)的復(fù)用潛力。
• 規(guī)則/決策服務(wù):通過執(zhí)行業(yè)務(wù)規(guī)則來提供業(yè)務(wù)決策的服務(wù)。舉例來看，e.g.補(bǔ)貨計劃自動審核服務(wù)。通常作用于復(fù)雜問題的判斷或者支持變化頻繁的業(yè)務(wù)規(guī)則。從顆粒度上來看，規(guī)則/決策服務(wù)通常為小到中等，用來組裝成更大的服務(wù)。規(guī)則/決策服務(wù)可以是不同層次的服務(wù)（包括業(yè)務(wù)服務(wù)、子域服務(wù)、子域基礎(chǔ)服務(wù)等），但是更常見的是作為基礎(chǔ)服務(wù)來支撐這些服務(wù)。

我們通過組合不同類型的服務(wù)角色來提供靈活的業(yè)務(wù)能力，支持業(yè)務(wù)流程內(nèi)的活動。因此需要一些基本原則來幫助我們合理的組合服務(wù)（減少依賴、限制耦合、獲取最大的靈活性） - 服務(wù)分層以及組合的基本原則：

• 業(yè)務(wù)流程的任務(wù)通過任務(wù)服務(wù)實(shí)現(xiàn)，業(yè)務(wù)流程路由的核心規(guī)則由規(guī)則/決策服務(wù)來提供
• 服務(wù)更高層次的業(yè)務(wù)服務(wù)由其他更小的服務(wù)組成
• 任務(wù)服務(wù)可以組合規(guī)則/決策服務(wù)、實(shí)體服務(wù)以及其他任務(wù)服務(wù)
• 實(shí)體服務(wù)不允許存在相互調(diào)用
• 服務(wù)單向依賴，上層服務(wù)可以依賴下層服務(wù)以及同一層次的服務(wù)，下層服務(wù)不可以依賴上層服務(wù)

通過豐富的流程、實(shí)體和決策服務(wù)的集合，創(chuàng)建新的不同的服務(wù)（流程）；結(jié)合規(guī)則/決策的靈活可變與服務(wù)分層的模塊化、可重用性，打造系統(tǒng)/平臺實(shí)踐落地的架構(gòu)方法論。

顆粒度切分

我們在設(shè)計服務(wù)是一個很大的疑惑是我們的服務(wù)到底要設(shè)計成什么樣的顆粒度？這個問題沒有統(tǒng)一標(biāo)準(zhǔn)，可以通過設(shè)置問題集結(jié)合并結(jié)合服務(wù)分層的方式來求解

• 誰是服務(wù)消費(fèi)方（包含潛在消費(fèi)方），e.g.其他服務(wù)、業(yè)務(wù)流程、外部合作方
• 服務(wù)在哪里別消費(fèi)，通過什么路徑消費(fèi)（即服務(wù)拓?fù)洌?/li>
• 服務(wù)的性能要求
• 服務(wù)預(yù)期的業(yè)務(wù)范圍和邊界

在復(fù)雜的環(huán)境或者系統(tǒng)（平臺）中，服務(wù)具有不同的類型和顆粒度。一種通用的方式是參照服務(wù)化分層進(jìn)行合理映射：

• 業(yè)務(wù)流程（端到端）:跨越整個企業(yè)或者平臺多個業(yè)務(wù)域，通常由底層服務(wù)構(gòu)建而成
• 平臺業(yè)務(wù)服務(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ù):最小粒度的服務(wù)，提供低層次的服務(wù)，用來提供子域內(nèi)業(yè)務(wù)功能的基本功能支撐
• 基礎(chǔ)子域服務(wù):較細(xì)粒度的服務(wù)，支撐上層業(yè)務(wù)功能服務(wù)的業(yè)務(wù)功能實(shí)現(xiàn)
• 基礎(chǔ)架構(gòu)服務(wù):較細(xì)粒度的服務(wù)，獨(dú)立于任何業(yè)務(wù)域。（明確區(qū)分于業(yè)務(wù)，e.g.安全認(rèn)證、權(quán)限管理等）

3 總結(jié)

架構(gòu)的范疇太大太廣，本文嘗試從一個點(diǎn)切入闡述一下個人的認(rèn)知。有太多相關(guān)性的問題想去闡述，比如SOA與BPM的結(jié)合、實(shí)踐過程中遇到的細(xì)節(jié)問題等等，為了比較干凈的剖析SOA還是刪除掉了。希望各位看官有所收獲。

作者：京東物流 崔立群

來源：京東云開發(fā)者社區(qū)?自猿其說Tech 轉(zhuǎn)載請注明來源文章來源地址http://www.zghlxwxcb.cn/news/detail-710833.html

到了這里，關(guān)于SOA認(rèn)知和方法論的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！