今天分享下SOA服务架构规划的整体方法论，并基于多年前的一个项目案例进行说明。在传统的企业架构规划里面往往并没有特意强调服务架构规划，仅仅是在应用架构规划里面增加了应用集成架构分析和接口梳理。

但是到了当前微服务架构和中台建设情况下，对于服务架构规划会成为一个关键点，即中台构建完成后最终还是要提供接口服务能力给前台应用使用。那么这些接口服务本身是否可复用，颗粒度是否合适就成为中台提供价值度的一个关键内容。

在微服务架构规划和设计下，可以看到基于企业架构的SOA服务规划架构思路仍然适用。

服务架构规划整体方法论

再次强调下SOA的核心思想是解耦，在首先满足解耦的要求下实现共享，协同和复用。 一个完整的业务系统被拆分了应用，服务和资源层能力三个方面的内容。 资源层的能力最终以粗粒度的服务方式暴露出来，应用的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力。 对于传统的企业架构规划和SOA规划思想的融合，在这里也只谈一些关键点和上下游衔接。

从端到端流程分析梳理业务架构

首先谈下业务架构的设计必须是以端到端流程驱动入手，通过逐层的流程分解最终确定各种业务活动单元，各个业务活动单元按照高内聚松耦合的指导原则（各种类似CRUD的矩阵分析方法）来确定大的业务域和业务组件。前面很多文章都谈到了业务组件化和组件能力化是一个核心，那么初步的业务架构和业务组件规划完成后，接着又一个重要的事情即组件向外暴露的能力服务如何识别？在这里需要在业务架构层面增加一个跨业务域或业务组件的组件交互或协同分析，分析在完成一个端到端流程的时候这些业务组件应该如何交付，那么这些具体的交互点将成为潜在的服务识别点。

数据架构规划和设计

在业务架构完成后进行数据架构规划和设计，而数据架构规划中的一个重点即是SID共享数据，其中包括了主数据和共享动态数据，在这里仍然是通过各种功能和数据的矩阵分析方法来找到相应的SID共享数据。当然在业务流程建模和分析中，可以看到有两类数据，一种是衔接某个业务活动输入和输出的数据，一种是该业务活动需要依托的底层数据，往往业务活动依托的底层数据很多都可以分析纳入到SID共享数据中。对于数据架构规划和分析中要注意到，最终是识别和形成各种数据服务能力提供。

技术架构和共性技术平台分析

在前面谈企业架构和云计算的融合中已经讲到了，在进行应用架构和技术架构分析的时候，需要考虑平台层云化能力的抽取，包括了IaaS平台和PaaS平台。其中对于PaaS平台层则需要考虑各种共性的技术组件和组件化服务能力的抽取，形成各种技术服务。

在上面几个部分都完成后，结合在应用架构规划中的应用集成架构规划和进一步分析，可以进一步分析和识别服务，形成完整的服务架构和服务目录。服务架构是在企业架构规划中必须增加的一个内容，这也将直接影响到我们应用架构的构建转化为资源+服务+应用的模式。服务在里面起到关键的解耦作用。

在基础的服务架构规划和服务目录库出来后，业务架构中的业务域可能已经转化为我们应用架构规划中的技术组件，数据组件和业务组件。这些已经是技术层面的概念，当然业务流程也进一步映射到系统层面需要实现的系统流程，那么就还得再做一次流程分析，分析在流程执行过程中需要调用到哪些业务组件或技术组件的服务能力，是否存在服务识别遗漏和缺失。这一步分析完成基本才能够保证前期分析和识别的服务是能够满足服务组装和流程编排的需要的。

流程驱动业务和IT调研分析

基于业务驱 动IT的思路，从端到端流程入手进行业务和IT调研，对端到端流程从上向下逐层分解梳理相应的业务流程关键活动和关键对象，同时端到端流程本身对应到整体IT应用架构，而分解后的流程往往和具体的业务系统对应，以此对应关系来梳理对应的IT系统现状。 通过上述调研，可以覆盖业务流程，业务数据，IT系统功能架构，技术架构和接口各个方面的内容。

业务和IT融合，关键就是分析端到端流程被拆分到多个业务子系统后是如何支撑业务的，这个时候就需要梳理核心的跨业务系统交互流程，重点只关心跨系统交互和协同。

如上图 ，基于电商C端客户销售流程，我们可以调研和输出上面这个跨系统的交互流程图。 要完成一个完整的从电商订单，到最终货品交互的端到端完整流程。 那么电商平台必须和后端的CRM系统，ERP系统，物流系统，WMS系统进行协同和交互。

跨系统交互流程分析核心就是梳理和识别关键的协同点和集成点。

在跨系统交互流程分析完成后，我们就可以进一步从业务系统集成的视角来分析具体有哪些的集成点。注意在梳理和分析集成点的时候，你可能会发现类似C端客户销售和B端客户销售，都会涉及到电商向CRM系统推送订单信息，那么这个接口就涉及到后续如何去整合和抽象。

在业务流程调研和集成分析完成后，我们就可以梳理出完整的接口清单。 注意接口清单上面需要重点体现如下关键属性。

• 接口数据流向：比如是电商到CRM，还是CRM系统到电商
• 同步/异步：该接口是在业务系统中同步调用，还是异步调用
• 实时/非实时：该接口是在业务系统中实时调用还是定时调用
• 接口实现方式：比如是Dblink，还是Web Service，还是Rpc等接口

以上是我们在进行接口清单梳理的关键内容。这些信息的梳理有助于我们后面对接口进行分析，从接口转服务识别和服务定义工作。

注意接口往往只谈数据流向，不谈提供方和消费方。即任何一个接口在没有转变为服务定义的时候业务系统的双方都可能是服务提供方面。比如电商平台需要传递订单信息给CRM系统，从接口层面来说数据流 电商-》CRM系统。但是从服务定义和实现则可能为：

• 电商作为服务提供方: 提供一个电商订单信息查询接口服务
• CRM系统作为服务提供方：提供一个电商订单导入信息服务

接着我们继续解释下，如果在微服务架构模式下我们希望是提供查询接口，而在传统架构数据落地模式下往往是规划为导入接口，不论是哪种都是考虑到数据的实时性需求。

传统模式下数据要落地，如果是查询接口，则CRM系统只有定时去查询增量订单信息，那么无法获取到实时订单。而导入模式下，电商平台只要有新订单就可以调用接口实时导入。

而在微服务架构下为何可以采用查询接口，一个关键就是微服务架构下推荐的模式是数据不落地，数据实时需要的时候再通过接口实时查询，因此这个时候电商采用能力开放思路提供实时的查询类服务更加能够保证数据的实时性。

企业架构梳理

在业务调研完成后，即进行相应的企业架构梳理工作。

在SOA服务架构规划和服务目录库设计中，对于企业架构梳理一般来说比较粗，你可以理解为仅仅梳理到单个业务系统里面的一级功能菜单的粒度即可。而独立数据架构同样，一般只需要关注核心的基础主数据和共享业务动态数据。而且往往只需要建模到逻辑模型层面即可。

流程梳理和分析，实际上形成了关键的业务功能和业务活动单元，业务对象和数据对象，而这些则是进行业务架构和数据架构规划的基础。

在前面多次强调了一个观点，即：

对于业务流程梳理和分析是自上而下，逐层分解和展开的过程。而对于业务架构和数据架构规划，则是从下朝上，基于高内聚松耦合的思路，采用各种聚类分析手段进行聚合，完成架构功能分域和分层的过程。

企业架构的提出，主要是为了解决业务和IT“两层皮”的问题，企业架构整个方法应该融入到整个IT规划思想中。此外，核心业务模型和业绩标准作为核心指导思想，虽然有裁剪，但是必须参考，如供应链SCOR模型，产品研发IPD方法论，项目管理PMBOK体系，战略和人力资源的平衡记分卡，CRM的4P和4C，财务域的核心模型等。针对不同行业可能又有不同行业的业务标准和模型，如电信行业的eTom模型等。

业务 架构可以理解为全公司架构规划和IT建设中的高端业务建模，这个时候不需要考虑太多IT层面的事情，重点是考虑我们的业务流程如何进行优化，业务架构如何进行重新整合，以满足我们已经明确的业务目标。 在这个步骤中可以看到业务流程和活动，业务职能单元，组织岗位角色，业务核心单据和数据，业务协同这个阶段是我们需要考虑的问题。

在这里希望融入部分SOA核心思想，即企业是一个完整的有输入有输出的产生核心业务价值的价值单元，而这个价值的实现是通过企业内部一个个相互协同的业务功能职能单元提供出来的，这些业务单元相互协同和组合完成核心价值的提供。这也是为何在端到端流程分析，流程分解和EPC分析后，重新对业务功能单元进行组合形成业务架构和业务组件，然后通过端到端业务流程对业务组件间的协同进行验证的原因。

在业务架构的流程分析中，包括两个方面的内容，一个是业务的问题，一个是数据的问题，业务功能和协同在前面已经解决，而数据的问题是另外一个维度，数据的识别是通过业务流程分析，而数据的建模有专门的方法来支持。 业务协同最终将体现到底层数据的关联关系和相互映射，底层数据模型出现问题直接影响高层业务协同。

流程中的业务单据是信息架构的数据来源，对于一般的应用系统而言，采取自顶向下的概念模型－>逻辑模型的建模思路，信息架构需要关注数据分域，主数据，跨业务模块的核心业务单据数据。数据的问题最终都将对应到应用架构和信息架构，SOA解决的是业务集成和协同，而数据集成是有其它系统解决方案，包括BI，数据中心，MDM系统等。

应 用架构规划需要体现逐层展开的核心思路，总体应用架构清楚后将细化到第二个层次： 功能架构和集成架构。 这个时候细化相当重要，真正解决业务目标和业务功能的落地问题。 功能架构包括功能模块和具体核心功能点，这些梳理出来后我们需要明确当初提到的业务架构和业务需求在功能架构中如何落地。 其次，以某个应用为核心，来观察该应用和外部应用间的集成关系以及集成后如何协同。 前者为功能性需求，后者为接口需求。

集成架构包括了业务集成和数据的集成，也包括集成接口关系和集成逻辑模型等方面的内容。当前大企业的IT系统建设通常分而治之，衍生了多个业务系统，那么多系统间的数据集成和业务协同等大问题就必须在集成架构规划中进行分析和考虑。

总体来说，应用中规划的功能点是为了映射和满足业务架构中的哪个业务功能或需求？业务架构中的功能是为了满足哪个业务目标？这两个问题都回答了，那么就基本回答了“规划的功能点支撑不了业务，功能点和目标之间关系不清晰”的问题。

集成架构规划

在前面进行了业务流程调研分析，业务架构和应用架构规划后，可以看到已经形成了很多关键的输出内容。这些输出内容包括：

• 端到端的业务流程
• 已经拆分后的业务子系统，微服务下是更细粒度的微服务
• 接口清单和集成点

那么接着我们要做的就是基于接口集成点，进一步对跨系统交互流程进行验证。首先还是可以继续进行基于业务系统的，跨系统交互流程集成点分析。

注意，这个时候我们做的不是一个流程，而是所有的跨系统交互流程，梳理出来的集成点，你会发现很多集成点类似需要进行整合，也可能接口集成点太粗，在转换为服务能力的时候还需要进一步进行拆分等。

在集成点分析完成后，接着可以构建完整的企业业务系统间的集成架构视图，也可理解为当前的系统间详细接口和集成情况。这个图梳理清楚后，系统间交互的接口、交互关系已基本全部梳理清楚。对于集成架构图的形成，一方面是采用跨系统流程分析和梳理中的接口交互，数据架构CRUD分析中的数据共享和交互；一方面是由底向上的分析当前系统间已有的历史接口情况，并对接口的业务场景和对应流程进行补充梳理，以形成完整的集成架构视图。

注意集成架构视图本身也需要分级展开，如下：

服务目录库 规 划

集成点分析和集成架构视图只解决了具体的接口有哪些的问题。

而接口如何转服务，是在进行服务目录库规划的时候的关键，即对于接口如何转变为服务，才能够更好地保证服务本身的粗粒度，服务的可重用性。

通过跨系统交互流程梳理出来的集成点，究竟有哪些需要合并，哪些需要拆分等。下面举一些场景来说明接口转服务的一些分析过程。

异步多接口-》归并为同步单服务

注意，如果原来在业务系统间集成的时候采用类似MQ这种消息中间件，那么任何一个消息或数据的集成都会涉及到消息推送和消息结果反馈两个消息接口。对于这种场景需要单独拿出来分析，即如果对于消息接收方，当接收到消息后可以实时的处理（对于消息的内部处理业务规则和逻辑不复杂），那么对于这类消息发送和回写接口可以考虑转化为同步的一个web service服务来实现。

同步接口-》异步服务

对于原来的同步接口，当需要对接口涉及的源系统和目标系统彻底解耦的时候，即我们不希望由于目标系统本身的故障而导 致消息分发失败。在这种情况下需要考虑将同步接口转化为基于JMS消息的两个异步服务。对于这种服务可以称为异步准实时，一方面是可以充分利用消息中间件 的高可靠性和消息重试能力，一方面可以利用消息中间件的排队机制减少在大并发请求场景下对目标系统的性能压力。

数据接口-》拆分为多个业务服务

传统进行数据集成的时候，我们并不会太多考虑业务场景，而是更多考虑传递的数据对象本身。因此往往存在不同的业务场景由于数据对象本身差异不大而采用相同的数据接口。如对于采购订单和采购冲红单等，在传统数据接口设计中可能采用的是一个数据接口。但是在转化为服务的时候，即使两种场景传递的数据对象差异不大也建议不要合并，而分拆为不同的业务服务。即采购订单分发和采购冲红单分发两个业务，即让服务本身有明确的业务场景和业务含义，而不是单纯的数据集成和数据服务。

还有一种场景可以看到，往往一个数据接口覆盖了多种业务场景，对于每种业务场景虽然有数据对象差异，但是差异全部传递在接口的xml或json字符串对象里面，导致一个接口本身的复杂度和耦合性相当大。对于这种场景也需要根据不同的业务场景，实现拆分为不同的业务服务或数据服务。

数据接口-》转化为服务查询

注意对于传统的数据接口和数据集成，其本质已经是同一份基础主数据或共享数据已经会通过数据接口或传统的数据交换平台在多个业务系统中落地。由于数据多点落地带来的最大影响就是数据本身在某个时点在多个系统中的数据不一致性和数据实时性。对于这种场景可以考虑对于一些数据有传统的数据集成和传递，转换为直接由数据拥有方提供数据查询服务能力，消费方在业务场景中根据实际需要实时查询而不具体落地和存储数据。这虽然增加了两个系统的耦合性，并带来业务系统本身的逻辑改造，但是带来了真正SOA服务能力开放思想。

不同数据接口-》合并为相同的服务

对于同一个数据对象，往往可以看到在不同的业务系统之间传递的时候，往往由于历史遗留原因可能采用了不同的数据或消息集成方式，传递不同格式和内容的数据对象，如订单对象在多个业务系统间的传递。同时也可能看到当我们在进行流程交互分析过程中，一个源系统在和多个目标系统对接的时候，对于同一个业务能力提供往往采用了不同的接口和数据交换标准。对于这些场景我们需要考虑合并为同一个数据或业务服务，对于这种协同采用同样的服务契约和接口标准，以提升服务本身的可重用性。

多接口-》消息发布订阅服务机制

对于原有的同一数据或业务对象的分发类消息或数据接口，原有业务场景往往是需要做多个接口点对点集成和连接。对于这种场景需要考虑这类数据分发转化为消息发布订阅模式，即充分利用ESB本身的消息和事件管理能力，对于源系统只需要将消息分发给ESB，而由ESB再根据消息订阅情况进行消息的服务分发。

以上谈到的就是在接口转化为服务过程中涉及到的去重，拆分，转换，合并等常见的接口转服务方法。虽然服务本身也包括了数据服务和业务服务，但是一定要注意到了服务层会更加关注业务服务，每一个业务服务都应该有明确的业务价值和能力实现，而不是底层简单的数据集成和传递。

最后，我们需要基于集成 架构视图情况，规划和梳理服务目录集，即按照服务的分层和分类来重新审视当前的系统间集成和能力共享。 下面来看下几类典型服务的进一步服务识别和规划。

流程服务： 注意端到端流程也是流程服务，但是该流程更加长，也很多对应到最终的流程编排和组合。因此需要从端到端流程中进一步找寻流程协作片段。这种流程片断最好是完全的自动化业务流，或者有较强的一致性和事务要求，这些都可以识别为流程服务。

业务服务： 业务服务更多强调的是业务规则类服务，或者强调基于业务功能操作触发的单条数据操作类服务。业务服务将更加体现服务调用的实时性，和业务操作场景的绑定以及业务逻辑的体现。或者可以理解为对于业务流程中横向实时协同的服务都可以看作为业务服务。

数据服务： 更多的是从数据CRUD分析中识别出来的服务，其中既包括了主数据，也包括了共享动态数据。一个服务如果更多是事后非实时的共享数据传递或数据查询，则更多的是数据服务。从这个层面来说业务服务和数据服务本身存在一些较难界定清楚的地方。也有一些方法是单独仅仅将主数据和共享数据中心提供出来的分析规划为数据服务，其它全部为业务服务。

服务全部识别清楚后，还需要进一步对服务进行归并去重，服务组合或拆分，服务关键属性的定义，以方便根据服务类型，服务技术分层，服务提供系统多层面来规划完整的服务目录库和服务视图。

进一步的案例分享

以下是某运营商服务架构规划的案例展示。

服务架构愿景

SOA服务架构规划将从原来的MSS域拓展到BOSS域，同时SOA服务架构将充分考虑到平台化建设的需求，对各种技术服务和平台级服务进行识别。当前接入的业务系统除了包括MSS域的ERP核心系统、报账、采购、资金、预算和营销物资外。也包括了BSS的集中渠道和B域主数据等。在后续架构规划愿景中将进一步接入OSS域的资源管理，电子运维和综合网管等相关业务系统。

对于后续新建设的业务系统，将彻底打破业务系统的边界，实现业务组件化架构，同时通过公有的PaaS技术平台对各个业务模块进行支撑，通过ESB平台实现对业务组件间的交互和协同。在业务系统和模块的开发中，要求其遵循SOA规范，以业务流程中心，执行服务分析与识别，最终形成非共享服务和共享服务。其中非共享服务保留在各自业务域的功能模块中。而共享服务将被分离出来，开发服务接口，注册在ESB上。

企业的服务架构由归属各业务模块的非共享服务、发布在ESB上的共享服务、数据库的共享服务以及公用服务组成。如下图所示：

需要说明的是，由于应用系统的SOA改造是渐进的，所以共享服务的分析识别是伴随着应用系统的改造进行的。 在特定的时间点上，共享服务既可能来自于封装旧系统，也可能是由来自于新应用系统开发。

同时，共享服务与非共享服务之间是可以转换的，所以以流程为中心进行服务分析与识别非常重要。即便分析得到的是大量的非共享服务，但是由于应用系统构建在流程分析和服务分析的基础上，这种松耦合特性使得未来可以敏捷地应对业务需求变更。

服务分类和目录库规划

SOA服务目录集是服务共享体系的应用基础，包括从企业业务管理全视图角度进行规划和提供的各类信息和数据交互的服务、服务目录，以及提供和（或）使用这些服务的各类专业应用系统。

服务： 就是按照业务流程全视图、业务数据全视图和业务系统全视图进行规划、开发和提供，并发布到企业服务总线平台上，用于各个应用系统间进行数据和信息交互的接口。每个具体的服务只能由某个具体的应用系统提供，发布于企业服务总线平台上的所有服务由平台维护单位统一管理。

服务目录： 服务目录即对企业内各个专业业务系统所发布的服务的一种组织，允许按照业务类型和业务系统两种方式进行组织。两种组织方式下，各个服务的功能、提供规则和使用规则相同。

各类专业应用系统： 公司内的各个信息化系统均可根据需要接入到企业服务总线平台上。这些信息化系统都可以向平台上发布服务，或从平台上消费服务。

一个基于标准的价值链的服务目录规划可以参考下图：

对于流程视图展现的是企业所包含的所有业务和流程，而对于服务视图则展现的是企业在业务和流程协作中可以复用的服务能力，这是服务视图和流程视图的一个关键差异点。

首先，服务视图本身有多个可以展现的维度，而我们前面所说的流程视图，数据视图，应用视图恰好都是服务视图可以展现的各个维度。高端的服务视图就是服务目录集或服务资产库，这是对服务视图的一个高端分类，这个分类可以按业务流程，数据分类，业务系统应用分类多个维度进行展开。这也可以理解为服务关系的核心逻辑，即服务和流程的关系，服务和数据的关系，服务和应用系统间的关系。

其次，服务目录规划需要体现服务的分层。对于服务的分层从业务层面来看，应该包括数据服务，业务服务，流程服务三个层面。从技术来看，则应该包括技术层服务，公共平台层服务。对于服务的调用应该基于一个从上到下的调用顺序，而不能进行逆向调用，即服务调用顺序为：流程服务->业务服务->数据服务->公共平台服务->技术服务。

另外服务目录和视图的构建，还需要考虑和服务工程域，服务全生命周期的融合。服务本身不能离开服务全生命周期而存在。服务全生命周期体现了服务从业务目标和需求开始，到服务识别和发现，服务定义，服务设计开发，服务测试，服务上线，服务使用的全过程。通过上面的分析，服务视图的呈现就比较清楚了，服务视图是一个涉及到服务生命周期，服务分类，服务关系等的一个多维度呈现模型。

以下为按照以上思路理出的不同类型的服务目录库。

按业务类型的服务目录库规划

按数据类型的服务目录库规划

后 续将基于这篇文章思路，进一步整理和思考在当前中台和微服务架构下，对传统的SOA服务架构和服务目录库规划方法的演进。 在前面我分享了中台架构对传统企业架构规划方法的演进，但是对于服务架构规划的优化还需要进一步补充。