1 前言

1.1 架構分類

在軟體設計領域，企業架構通常被劃分為如下五種分類：

如何理解架構分類依據及其彼此之間的關係？業務是企業賴以生存之本，因此業務架構是基礎、是靈魂，其他一切均是對業務架構的支撐；根據業務架構形成與之相應的產品架構和資料架構；最後通過技術架構落地實施。

應用架構用於對產品架構進行細分，通過應用整合形成產品。但是應用架構區別於產品架構的本質不應該只在粒度，更重要的是產品直接承接業務，按照業務問題域進行劃分；而應用需要考慮通用能力沉澱和複用，為多個產品提供統一支撐。

業務架構：業務需求初期，將模糊的需求描述為清晰的問題域，主要包括業務規劃、業務模組、業務流程。
產品架構：脫胎於業務架構（主要是業務流程和業務模組），關注的是功能的列舉和分類。
資料架構：從問題定義的視角，邏輯（流程）+ 資料是兩個核心。業務架構分析流程的同時，另一個核心就是定義資料架構，結合流程和資料形成產品。在實踐過程中資料架構的工作往往被置於產品架構或者應用架構內部，從全域性視角看這是一種誤區，資料作為企業寶貴資產，其架構的好壞直接影響企業競爭力，必須全域性考量和設計。資料架構要解決兩個關鍵問題 - 1.需要什麼資料 2.如何儲存資料。
應用架構：應用架構用於對產品架構進行細分，在產品架構的基礎上進行更細粒度的問題拆解和職責劃分，並抽取可複用模組沉澱形成基礎能力。應用架構的最貼近落地實現。
技術架構:上述四個架構從問題定義視角出發，技術架構從問題解決的視角出發，關注的是技術選型、開發框架、開發語言等。

1.2 SOA

自19年底開始，我的工作內容就集中於供應鏈領域中臺產品的建設，在建設過程中不可避免的一個關鍵詞就是服務化，對此不同人會有不同的看法，個人對服務化的理解更傾向於SOA，因此通過本文談一下對SOA的認知。

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

軟體架構在SOA提出之後尚未發生變革性的突破，很多架構思想如 EA分層架構、微服務架構、DDD架構等，大多都是在SOA架構風格的基礎上進行不同角度的演化迭代，因此本文在闡述SOA的過程多少會存在其他架構思想中的「影子」。

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

2.1 What

2.1.1 術語

任何概念的定義，都有與之對應的術語。

業務行為：具備一定業務語意的原子行為抽象。
業務流程：實現特定業務價值（滿足客戶需求）的一些列業務行為的有機組合。
業務服務：提供增值價值的業務行為或業務流程（需要特別說明的是業務服務既可以是業務流程也可以是業務行為、甚至兩者的組合）。具有明確業務功能定義和價值衡量標準（SLA）。
應用元件：按照一定的相關性結構化封裝的應用功能（為方便理解，在不考慮分層的前提下，簡化等價於業務服務）的一個集合。用以提升應用的一致性、靈活性，並實現重用。
應用：應用元件的有機集合，用來提供業務功能（單個或多個），為整個系統或者平臺提供增量價值支撐。京慧中的需求計劃、經營計劃、庫存計劃、分銷補貨計劃、供給計劃（應用之間也存在一定的層級概念，貼近業務本質的理解）。
系統：一系列應用及服務的有機組合（某些服務可以獨立為系統提供增量價值支撐，微服務架構思想中有諸多體現），具備端到端的完整業務功能，體系化的提供使用者增量價值。我所建設的京慧產品（供應鏈計劃產品）本身是系統的層面。
平臺：一個或多個系統的有機組合，具備整個業務線或者業務生態的端到端業務功能全集。以提供業務線或者業務生態整體業務價值為目標。
架構：代表的是一個系統的基礎元素構成。體現在系統構成的元素集合、元素之間的關係、與外部環境的互動，以及指導系統迭代演進的原則。
架構風格：一系列符合共同特徵和核心原則的架構定義。

2.1.2 定義

SOA就是一種架構風格，致力於將業務功能保持一致的服務作為設計、構建和編排組合業務流程（或者解決方案）的基本單元。

2.1.3 服務

服務是設計、構建和編排組合一個完整業務實體中業務解決方案的基礎單元。

服務可以從表裡兩個方向結合定義 - 服務是提供業務功能的原子單元（裡），通過服務契約的方式管理（表）。

服務契約是服務消費方與服務提供方互動的所有約定的集合，通常由如下元素構成：
服務介面：介面定義，描述服務做什麼、出入參定義等，通常通過介面檔案的形式呈現。圍繞著一個核心的業務功能操作以及相關聯的操作。

服務策略：服務雙方的隱性的共識，描述適應場景、約束等。
服務水平：通過服務質量、可用性、效能等各個方面衡量服務本身，基本等價於SLA，包含了服務的兩個重要方面的指標 - 業務指標和技術指標（技術指標- RT、吞吐量、可用性、可靠性等；業務指標-完成的業務功能的質量或者完成度，e.g.補貨建議是否滿足業務預期的週轉缺貨KPI）。

服務契約中體現出來的管理屬性是服務區別於其他常見定義（模組、元件等）的根本區別，我們通過服務契約來管理服務的全生命週期（設計、實現、部署、升級）。

服務實現 - 對業務功能的實現，是對SOA核心本質的對映。

服務實現：具有多種實現方式【編碼實現｜編排其他服務｜適配封裝現有應用｜混合實現】。服務如何實現對於服務消費方來說是透明的，即服務消費方僅關心服務的what而非how。服務可以在保持介面不變的情況下在橫縱兩個方向改變（橫根據不同行業不同場景提供不同的實現；縱根據行業發展演進服務）。

2.2 Why

為什麼要選擇SOA？針對這個問題會有很多觀點

職責清晰（介面定義）
可靈活擴充套件（介面與實現分離）
高度可複用
介面分類
高度可管理

上述觀點都無法否定，因為它們可以通過服務定義推演得到。其中前三個都是針對單個服務構建來看，只要掌握足夠的技術手段就可以很容易的建立一個服務（單個服務），這並不是SOA的核心競爭力。SOA的目的遠超介面技術細節的設計與定義，核心關注點在於服務的業務內容以及內涵（而非如何設計和實現）。在使用SOA總結提煉出的術與器的同時，不要忘記道和法。how to do很重要，指導的是做好一件事；但是what更重要，指導的是做對的事。

更深層次的剖析SOA的價值，我們需要回歸SOA的本質 - 致力於在企業內的不同業務環境內建設業務功能驅動的服務，並在此基礎上將服務組裝成更高價值/更高階別的業務流程（解決方案）。故而可以將SOA的價值總結為兩個關鍵點：

賦能企業構建具有業務價值的、具備完整業務語意的服務集合；
基於服務集合，組織和編排服務，構建敏捷&靈活的業務流程/解決方案。【敏捷服務可以快速調整、獨立演化；靈活服務的業務功能定義明確（邊界清晰、內聚性強），可靈活組合】

2.2.1 SOA價值的表現形式

一致性:一致性是SOA核心的價值體現，包括資料一致性和行為一致性【資料提供業務一致&共識的公共資料存取服務；行為對外（業務流程、外部任務等）提供統一的入口】
解耦:通過分離減少功能與資料的依賴和耦合。服務作為獨立的業務功能單元，在應用系統中可以協同工作，同時各自又具備各自清晰且獨立的業務目標和生命週期。
模組化&敏捷性:為業務的模組化提供基礎；同時在模組化實現的基礎上，模組可以在多個業務流程和場景中被複用和靈活組合，從而支援業務快速創新。
高度可管理性:服務水平的定義保證了服務在支撐業務目標的同時，可以跳出業務功能認知進行管理（可監控、可優化、可調整）。

2.3 How

相比於What和Why，SOA的實踐是一個很龐大的問題，本文選擇從服務設計的角度進行剖析。

2.3.1 梳理上下文

對業務系統，理解我們所支援的業務及其核心驅動力，是我們做好服務化的前提；如果是平臺類系統，需要理解公司的戰略所賦予平臺的使命和平臺的終局目標、中長期目標。換言之，第一步是理清服務化架構的完整上下文背景。這些內容需要對映到模型中（各層級模型，詳見下文分層設計）。如何梳理上下文，一種好的實踐方式是定義問題集。有一種觀點是提出好的問題 == 問題解決了一半，問題集定義：

通過上述8個問題描述了整個服務化架構的上下文：

問題1-6:描述業務/平臺整體架構需求梳理；
問題7:描述架構需求梳理的結論；
問題8:引入了服務集合定義。服務集合是SOA建設的核心成果，需要從持續迭代演進的視角去理解。

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

完整的上下文背景
服務集合職責範圍
服務分組（體現服務關聯性）
服務的型別和角色

服務集合設計的兩個主要目標

提供一種機制來識別一個特定服務的責任邊界，指引服務實現。（重要明確服務職責及邊界，避免重複建設，保障行為和資料一致性）
提供一種機制來幫助理解服務整體的上下文背景，用於更高效的服務選擇、服務重用。（服務分類，服務間關聯性）

服務集合中的服務可以按照服務型別以及服務角色來進行組織。服務型別參照服務化分層架構描述，服務角色包含任務服務角色、實體服務角色、決策服務角色。

2.3.2 服務設計原則

SOA成功的關鍵之一是建立一個具備完整上下文語意（業務/平臺語意）的服務集合，以便於通過組合編排服務來支撐不同的業務流程和業務場景。面向服務的架構中服務設計的問題要跨越多個甚至全部的流程來一起考慮。

首先，最容易想到的是鬆耦合，無論是SOA思想還是其他思想（e.g.OOP）鬆耦合都是基礎原則之一；通過減少服務間的依賴提升不同應用場景下的複用性，隔離變更影響。耦合 - 服務間存在依賴關係。首先我們來看下對於服務最重要的兩個點：

服務提供的業務功能
服務對業務資料產生的影響

從上述兩個點我們比較容易得出兩種型別的耦合（依賴） - 資料和功能。這裡會存在一個很基礎的問題為什麼要產生依賴，從技術實現的角度看可以摒棄依賴實現一個大而全的服務。開發人員特別是習慣物件導向思想的開發人員對鬆耦合/高內聚已經形成一種本能，很少會反思為什麼要這麼做 - 兩個方面（內在一致性保障；外在能力複用）。好的服務設計不僅是關注重用性，更重要的是提供一致性（行為與資料）。

再有，如何決定有哪些服務以及服務是什麼？還是從資料和功能出發，通過功能分解和資料隔離組合在一起來決定服務有哪些以服務分別是什麼。由此擴充套件所得的基本原則如下：

避免缺失
避免重複
保持一致性

如何實踐落地上述原則？可以藉助問題集的定義和轉換：

2.3.3 服務集合設計

我們從分層、分類、顆粒度切分三個緊密聯絡的方面來看服務集合設計。

服務分層

資訊架構是服務化分層架構設計中會被忽視的一個重要側面，體現的是企業中不同角色的關注點。

戰略與決策定義企業的戰略方向和商業目標，指引企業內部系統/平臺發展的方向和終局。
商業模式用運營主體的術語描述對企業業務有價值的事物。
業務抽象用資訊化的方式對單個業務線或者多個業務線的業務進行抽象。從業務抽象開始進入問題域定義。
公共語意模型在業務抽象的基礎上增加服務化的語意。公共語意模型描述的是在平臺各業務服務間共用的具有一致語意的業務實體和資訊，需要在平臺層達成共識。
子域領域模型是各子域的核心業務功能的抽象，包括服務定義及服務實現中的關鍵實體的定義。從整體視角來看是平臺各子域的私有模型，除了服務語意之外整體不對外可視。
開發實現模型等價於OOP中的物件模型，是開發和落地的基石。

商業模式與業務抽象的關係

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

雖然從層級結構上看商業模式是業務抽象的上層，但是商業模式描述的東西是業務抽象定義所對應的樣本或範例（從概念上來講業務抽象的範圍更寬泛）。業務抽象是商業模式的抽象與綜合，必須要仔細分析和歸納、甚至通過演繹的方式來定義出隱藏在企業業務運營主體背後的根本內容和結構。

公共語意模型與子域領域模型的關係

公共語意模型用於描述平臺層服務介面互動的共用資訊，基於平臺完整業務語意下所有服務公用資料的標準化檢視模型。簡言之，平臺公共語意模型定義了業務平臺層次的基本業務服務語意，是平臺各業務服務之間、平臺業務流程和平臺業務服務互動的統一語言，強調統一和共用。而子域領域模型是平臺各域的私有模型，用於驅動子域內服務功能的設計與實現。除非域內業務發生本質變化，子域領域模型需要保持動態穩定，通過防腐層隔離外部依賴的侵蝕（領域模型也是DDD思想的核心）。

服務分層是服務化分層架構設計的主體。理解服務分層架構的一個好的方式是學習一下 TOGAF Meta-Model。

業務流程（端到端）:按照一定業務規則決定的順序執行的業務操作。高層級的業務功能通常跨多個應用子域/業務條線。
業務服務（平臺/系統）:高度模組化的業務功能單元。由不同型別的子域服務組合編排而來，可作為業務流程的編排單元。
子域服務:功能子域提供的服務，對平臺可見，用於平臺業務服務的組合編排，也可以作為更高層的業務流程編排的基礎單元。
子域基礎服務:用於支撐各功能子域服務的基礎服務，對子域可見，對平臺不可見，用於子域服務的編排。
基礎子域服務:或稱之為基礎業務域服務，提供平臺基礎業務服務，為各個功能子域或平臺業務服務提供基礎業務功能及資料服務（e.g.商家服務、貨品服務、庫存服務）
基礎架構服務:提供不同層次所共用的基礎架構服務（e.g.使用者管理、許可權管理）

模型分層是對服務分層的重要補充。服務分層從結構上看是清晰和完整的，但是從服務化建設的整體視角看卻並不完整，我們需要新增與之對應的模型抽象。

核心模型:端到端的業務流程承載業務核心價值的資訊模型。在供應鏈領域中是單據模型，e.g.銷售訂單、採購訂單、補貨計劃單。
公共語意模型:定義了平臺層面業務流程、業務服務互動資料。在平臺層面或者企業層面，端到端的業務流程中互動資訊的公共語意模型定義了業務流程中所需要的完整的業務語意的實體定義（各業務語意實體邊界明確、責任清晰）。核心模型通常是公共語意模型的子集。平臺公共語意模型包含下層子域的對外服務實體子集，按照端到端的完整平臺業務語意，可以由平臺各功能子域模型所共用給平臺的核心實體子集有機整合而成，也可以由平臺業務模型全新定義（從top-down與bottom-up兩個方向共同融合而成）。此模型需要不斷迭代演進，平臺的諸多架構決策和完善都是基於此模型來進行。
子域領域模型:平臺各功能子域的領域模型用於驅動各功能子域的應用系統設計和開發。（同服務分層描述需要保持動態穩定，通過防腐層對外部服務進行隔離，防止外部服務汙染子域內的核心業務語意，同時保持域內業務功能靈活可控。子域領域模型僅通過其對外服務實體對外可見，其他均對外不可見。）
跨域對映模型:用於各子域領域模型實現對外部模型的防腐依賴。
基礎架構服務模型:提供跳出層級之外的公用的基礎架構資訊模型，如使用者模型、許可權模型。

服務分類

服務分類（或稱服務角色）是獨立於職責範圍、服務粒度之外的另一個重要因素；用於標識服務在組合/流程編排中所扮演的角色是什麼。
如果說服務分層是縱向切分，服務分類就是橫切面。借鑑OOP與AOP的理念，對服務分類的定義我們使用關注點分離的架構原則。

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

任務服務:任務服務通常實現一個完整的業務功能，既可以是基本業務功能，也可以是複雜的業務功能。此服務型別顆粒度粗，包含從獨立的子域基礎服務到平臺業務服務都可以具有任務服務角色。業務服務通常承擔任務服務的角色，本身是由小顆粒度服務較大的組合（流程），可以被設計成支援一個或者更多待定的流程。任務服務的針對性強，複用能力弱。通常，具有任務服務是主動服務，通過主動行為來進行價值輸出。
實體服務:管理存取業務實體的服務。舉例來看，e.g.使用者、類目、商品、購物車。實體服務通常獨立於任何特定的業務流程，可作為多個不同業務流程的組成部分。實體服務通常通過是配合提供需要的資訊來實現任務的方式來支撐任務服務。實體服務通常具備很強的複用潛力。
規則/決策服務:通過執行業務規則來提供業務決策的服務。舉例來看，e.g.補貨計劃自動稽核服務。通常作用於複雜問題的判斷或者支援變化頻繁的業務規則。從顆粒度上來看，規則/決策服務通常為小到中等，用來組裝成更大的服務。規則/決策服務可以是不同層次的服務（包括業務服務、子域服務、子域基礎服務等），但是更常見的是作為基礎服務來支撐這些服務。

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

業務流程的任務通過任務服務實現，業務流程路由的核心規則由規則/決策服務來提供
服務更高層次的業務服務由其他更小的服務組成
任務服務可以組合規則/決策服務、實體服務以及其他任務服務
實體服務不允許存在相互呼叫
服務單向依賴，上層服務可以依賴下層服務以及同一層次的服務，下層服務不可以依賴上層服務

通過豐富的流程、實體和決策服務的集合，建立新的不同的服務（流程）；結合規則/決策的靈活可變與服務分層的模組化、可重用性，打造系統/平臺實踐落地的架構方法論。

顆粒度切分

我們在設計服務是一個很大的疑惑是我們的服務到底要設計成什麼樣的顆粒度？這個問題沒有統一標準，可以通過設定問題集結合並結合服務分層的方式來求解

誰是服務消費方（包含潛在消費方），e.g.其他服務、業務流程、外部合作方
服務在哪裡別消費，通過什麼路徑消費（即服務拓撲）
服務的效能要求
服務預期的業務範圍和邊界

在複雜的環境或者系統（平臺）中，服務具有不同的型別和顆粒度。一種通用的方式是參照服務化分層進行合理對映：

業務流程（端到端）:跨越整個企業或者平臺多個業務域，通常由底層服務構建而成
平臺業務服務:最粗粒度的服務，提供高度抽象的組合業務功能給到平臺或者企業。業務服務的功能和資料同業務流程所需要的業務語意緊密結合。資料整合服務在這個層次提供端到端的業務流程所需要的整合後的資料
子域服務:中等粒度服務，提供針對每個業務子域的業務相關服務，被本於內的不同業務服務所使用，但是未必暴露在子域外
子域基礎服務:最小粒度的服務，提供低層次的服務，用來提供子域內業務功能的基本功能支撐
基礎子域服務:較細粒度的服務，支撐上層業務功能服務的業務功能實現
基礎架構服務:較細粒度的服務，獨立於任何業務域。（明確區分於業務，e.g.安全認證、許可權管理等）

3 總結

架構的範疇太大太廣，本文嘗試從一個點切入闡述一下個人的認知。有太多相關性的問題想去闡述，比如SOA與BPM的結合、實踐過程中遇到的細節問題等等，為了比較乾淨的剖析SOA還是刪除掉了。希望各位看官有所收穫。

作者：京東物流崔立群

來源：京東雲開發者社群自猿其說Tech 轉載請註明來源

SOA認知和方法論