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认知和方法论