如何设计服务以及服务化架构(SOA)

1、如何设计服务以及服务化架构自从提倡SOA架构风格以来，个人觉得软件架构并未有特别突破的变革，主要是在SOA面向服务架构风格基础上不断演化迭代，基于服务的EA明确分层架构也好，微服务也罢，都是在面向服务架构基础上的适应不同的场景的迭代升级。我先抛出一个观点，我觉得服务化架构的本质，和西方教育界深受影响的古希腊哲学家苏格拉底的“产婆术”的教育思想本质上是非常相通的：苏格拉底的“产婆术”思想强调教育是一个“接生”的过程教师就是“接生婆”，人们之所以接受教育是为了寻找“原我”以不断完善自身。也就是教育的目的在于唤醒而不再于塑造。同理服务化架构的本质也不仅仅在采用什么样的技术框架实现和塑造，更重要的是在

2、于通过不停地在共创中反问、反思、反省等方式进行对业务的本质的不断追溯、抽象、综合归纳演绎，我们的每一个架构师都是服务化架构的接生婆，我们的使命是建立真正反映业务本质并驱动业务不断向前的架构。我们是否足够深入理解业务的本质，做了足够的归纳演绎以及综合抽象，是否清晰的反应到了我们的服务化的根基：业务模型、域模型以及平台公共语义模型上？这是我们每一个参与服务化的每一个产品、架构师、TL和核心开发同学需要回答的第一个根本问题。面向服务的架构（SOA）：SOA是一种架构风格，致力于将业务功能保持一致的服务（系统服务，应用服务，技术服务）作为设计、构建和编排组合业务流程以及解决方案的基本单元。目的我们采用

3、SOA的架构是为了什么呢？为了更好的复用？为了更好的责任切分？为了接口和实现的分离，提升灵活性和隔离性？还是为了更好的接口分类和管理？以上说法其实都没错，但是面向服务化的架构SOA的目的远远超过接口技术细节的设计与定义，其核心的关注点在于服务的业务内容以及内涵，而不仅仅是如何设计和实现。同时，SOA更多的也不是如何构建一个服务，任何人都可以很容易地创建一个服务，这并不是SOA的核心挑战，而是如何赋能企业构建有业务价值意义的完整业务语义的服务集合。面向服务的架构致力于在企业内的不同的业务环境内，建设业务功能驱动的服务，从而将服务组装成有价值、更高级别的业务流程和解决方案平台。面向服务的架构的真正

4、的价值体现在当可重用的服务被灵活组合、编排在一起来构建敏捷的、灵活的业务流程，其中敏捷体现在服务可以快速调整，独立演化；灵活性体现在服务由于其业务功能定义明确，边界清晰且功能内聚性强，同时服务具备各自独立完整生命周期，可被灵活组装。如果面向服务架构能为企业提供了重大的价值，那么这些价值通过什么来体现的呢？价值体现行为一致性面向服务的架构允许我们为业务流程、任务或者决策拥有唯一的共同的入口，也就是，不管服务访问的路径如何，服务给业务提供的业务行为都是一致的。数据一致性面向服务的架构允许我们为业务数据信息提供单一的访问入口也就是它提供给业务一致的、企业内部共识的公用数据访问。模块化及敏捷性面向服务

5、的架构SOA为业务功能、业务决策和业务信息的模块化提供了非常好的机制。同时，在模块化实现好的情况下，这些模块可以在多个业务流程和场景中被灵活复用和重新组合，从而为业务竞争力和创造性提供灵活性和敏捷度支持。功能与数据的解耦面向服务的架构SOA提供了业务功能和信息集成的同时，减少了他们之间的依赖和耦合性。也就是，独立的业务功能单元，应用系统，可以一起协同工作，同时各自又具备各自的演进计划，生命周期和业务目标。高度可管理性SOA提供给我们通过定义服务水平协定在服务模块粒度支撑我们的业务目标，我们可以不断的设定、监控和优化调整组件，应用以及系统所承载服务的考核。其中行为一致性和数据一致性作为服务的核心

6、价值根基。服务一、定义首先我们先定义一下服务是什么？服务是通过服务契约的方式来提供业务功能的独立单元，同时受服务契约所明确管理。服务是设计、构建和编排组合一个完整业务实体中业务解决方案的基础单元。服务契约指定了服务消费方和提供方之间所有的交互约定，包括：服务接口接口文档服务策略服务质量服务可用性性能那我们经常听到模块、组件等其他的软件构件，服务和他们有什么区别呢？其中最核心的区别在于服务本身是被明确管理的，其服务质量和性能是通过服务水平协定（SLA）被明确管理的，而模块以及组件并无此约束。此外，服务的全生命周期包含从设计、部署到增强升级和维护都是可管理的。举例（下列内容仅做示例展示用，非适用于

7、严格场景）：补货计算服服务策略服务质量性能要求补货针对行业下商在销量预测符合分布要求且满足准10W+货品*建议家/供应商维度确率水平要求的情况下，根据缺货率30仓，品+仓量计的入仓货品补服务水平要求的产生的补货建议量补货及建议量算服货建议计算符合业务期望的周转天数=30min务包含购物车下订单单+立即下单峰值支撑：创建场景，满足所有订单创建成功率99.999999999%100w单/s服务优惠计算后的订单生成二、服务构成服务自身主要包含两个主要方面，第一方面也是服务最核心的方面就是服务的接口，另外一方面则是服务的实现。服务非常好的实现了接口和实现的分离。1）服务接口服务接口指定了服务的操作，也

8、就是服务是做什么的（What）,操作的输入输出参数，以及用来约定如何使用和提供这些能力的协议。服务通常包含围绕着一个核心的业务功能操作以及相关联的操作。例如补货建议计算服务中核心的操作是生成货品+仓维度的补货建议单，其他相关操作包含查询补货建议单相关销量预测操作，查询补货建议单对应计划库存操作。服务核心功能操作关联操作补货建议计算服务品+仓维度补货建议计算补货建议单对应销量预测查询补货建议单对应计划库存操作2）服务实现服务实现指的是服务如何通过其明确定义的接口提供其能力。服务实现可以通过以下方式实现：完全基于编码实现基于其他服务的编排而成基于已有应用适配封装而成以上情况混合实现核心点是服务如何

9、被实现的对于服务消费方来说是透明的，服务消费方仅仅需要关心的是服务是做什么的，而不是如何被实现的。服务可以提供在保持服务接口或者行为约定不改变的情况下，提供根据不同的行业不同场景提供各种不同的实现。服务实现在保持服务接口或者行为约定不改变的情况下，可以自由进行升级和切换。服务实现既可以是静态的更新升级，也可以使动态路由实时切换实现，如对应到不同的行业以及不同的业务场景的自动实现切换。不管服务实现如何升级或者按需自动路由切换，只用服务的行为和契约不会发生改变，用户也就是服务的消费者根本不会感知到任何不同。我们可以把服务接口想象成室内普通电源国标插口，服务策略为室内非防水情况下适用，服务契约想象成

10、24X7的220v电压供电能力（其中180V250V50Hz是质量要求，24x7稳定性要求，电流供给实体+属性+关系）的ER图，还是基于我们老祖宗老子道家思想（人法地、地法天、天法道、道法自然实体+行为）的思想的领域驱动DDD的方式，个人认为各有伯仲，组中能清楚表达出业务本质即可，后面单独写一篇抽象建模的文章聊一下这两种不同的思想。Level5：实现模型此层模型为开发者视角的实现模型，也就是我们系统实现核心的对象模型，是我们系统落地的基石。设计服务我们初步了解的什么是服务，以及什么是服务化的分层？那如何设计服务以及服务化架构呢？下面给出基本步骤和方案。一、理解整体背景首先，我们要理解服务化架构

11、的整体背景。我们必须理解我们所支撑的业务和业务根本驱动力以及所有的业务流程，业务场景以及业务用例；同时对于平台系统，我们还必须理解公司的战略所赋予平台的使命是什么？我们平台中长期的目标是什么？平台的终局是什么？这些组合和在一起才是服务化架构的完整的上下文背景。这些必须要反映到我们的业务模型、平台公共语义模型和各域模型中去。然后，我们需要提出并回答如下问题：我们当前支撑的是什么样的业务？（业务模型）这个业务或者这些业务的中长期目标和短期目标分别是什么？平台的短中长期目标是什么？平台的终局是什么？上述目标是否存在冲突，如何平衡和取舍？实现这些目标，需要完成什么样的成果？这些成果如何衡量？取得这些成

12、果，需要什么样的能力和信息？实现这些能力需要什么样的流程、服务、实体以及规则现有的服务、应用或者系统提供了那些基本能力和信息？前面六个问题描述了整体的架构需求（包括业务和平台），而剩下的问题则描述了整个服务化架构的上下文以及引入了服务目录库的需求。我们服务不能只从单个服务的角度来看，而必须从整个服务集合的角度来反应完整的业务语义和平台语义。我们的服务集合也就是服务目录库必须具备完整的上下文语义，必须能识别出：整体的上下文背景，包括完整的业务语义和平台语义。服务职责范围关联的服务的分组服务的类型和角色服务目录库的设计必须支持两个主要的设计时目标：第一个目标是要提供一种机制来帮助理解服务整体的上下

13、文背景，用于更好的服务选择及更高效的服务重用。特别是，这个服务实现了什么样的责任，以及如何和其他的服务相关联。第二个目标是要提供一种机制来识别一个特定服务的责任边界，用来指引服务的实现。这是一个非常关键的点，特别是在避免服务的功能和数据重复上非常重要，不仅仅是避免重复建设，更核心的是要以此保证业务功能和数据的一致性。服务目录库中的服务可以按照服务类型以及服务角色来进行组织。服务类型请参照服务化分层架构内容里的描述；服务角色包含任务服务角色、实体服务角色和决策服务角色，请参照后面小节描述。二、服务设计原则面向服务化的架构的其中一个成功的关键是创建一个具备完整业务语义的服务集合以便于可以方便一起进

14、行组合编排来支撑不同的业务流程以及丰富的业务场景。我们经常谈论各功能域要提供松耦合的服务，是因为服务间的松耦合是非常重要的，特别是通过减少服务间的依赖以便于服务可以在不同的场景中被复用，以及可以起到隔离变更影响的作用。但是如何才能尽可能的实现这个目标呢？首先我们来看下对于服务最重要点是什么？首先就是这个服务提供了什么样的业务功能，其次这个服务对业务有价值的数据产生了那些影响。从这两个点上我们就可以比较容易得出两种类型的耦合在服务接口设计中是特别重要的：数据依赖功能依赖举例来说明下：交易服务协调所有的活动，然后依赖其他服务来帮助完成流程。交易服务依赖于或者说耦合于用户服务，商品服务，库存服务，营

15、销服务、订单服务以及支付服务等。为啥交易服务没有实现所有的功能？首先是因为我们想在其他高级别流程或者服务中重用底层的能力。第二是交易服务服务并不负责用户服务，商品服务，库存服务，营销服务、订单服务以及支付服务。交易服务只是使用它们，而不是负责实现它们。用户服务被用作管理客户信息访问，它具有唯一的责任来提供、维护和更新客户信息，这样做的目的是为了可以在任何需要访问客户数据服务的地方重用客户服务。比代码重用更重要的是隔离或者是集中式访问客户信息，因为只有唯一的路径访问数据，数据就总是一致的，真正实现SourceOfTruth。因此，尽管有很多服务包含交易服务，购物车，订单历史等服务需要访问客户服务

16、,通过松耦合的这种模式去管理这些依赖是比较容易被理解的。通过创建服务来执行用户管理，商品管理，库存管理，以及营销管理等，就可以在任何可以用到的地方，执行保持一致性的这些业务功能。敲黑板：好的服务设计并不仅仅是关注重用性，更重要的是要提供一致性,既包含功能一致性，也包含数据一致性。那么下一个问题是你如何决定有哪些服务以及这些服务分别是什么呢？同样，你用功能分解和信息隔离组合在一起来决定服务有哪些并且各自是什么？对线上交易功能的分解引导去识别用户、商品、库存、营销、订单以及支付等相关功能服务。对信息的隔离引导我们去识别用户和商品等作为交易订单中的共享信息。面向服务的架构中服务设计的问题需要跨越多个

17、以致于所有的流程中来一起考虑。因此，服务设计原则基本原则如下：避免服务间的功能重复避免服务间的功能缺失避免数据重复实现数据的协同访问具备统一、一致的方式来执行给定的功能在服务化设计中，如何实现上述的这些原则呢？答案是提出并回答如下问题：谁负责这个功能？这个功能在哪里被用到的？谁负责管理这些指定的数据？谁负责定义和实现那些特别的业务规则流程中的哪个步骤具备执行这个任务所需要的特定的知识这些问题的答案会帮你来识别如下信息：服务应该做什么？服务对什么负责？同样重要的是，识别服务不应该做什么，而应该依赖其他的服务来支撑三、服务颗粒度与类型我们通常设计服务时候一个很大的疑惑是我的服务到底要设计成什么样的

18、颗粒度，应该更粗粒度一些，还是更细粒度一些？答案是：没有一个统一正确的服务颗粒度标准。那怎么办？我如何设计我的服务的颗粒度呢？虽然没有统一的标准，但是我们可以依赖下面的因素来决定合适的服务粒度：谁是服务的潜在消费方？其他服务，业务流程还是外部合作方？服务在哪里被消费，通过什么样的路径被消费，也就是服务的拓扑结构是什么？服务的性能要求是什么？服务预期的业务范围或者边界是什么？在几乎任何复杂的环境或者系统平台中，我们可以预期到多种多样类型的服务。这些服务具有不同的类型和颗粒度，可以参考服务化分层中的内容，也可以见下面的描述端到端的业务流程业务流程通常跨越整个企业或者平台多个业务域，通常是由底层服务

19、构建而成平台业务服务业务服务是最粗粒度的服务，业务服务提供高度抽象的，组合的业务功能给到平台或者企业。业务服务的功能和数据同业务流程所需要的业务语义紧密结合。数据整合服务在这个层次提供端到端的业务流程所需要的整合后的数据。子域服务子域服务是中等粒度的，他们提供特别针对于每个业务子域的业务相关服务,被本域内的不同业务服务所使用，但是未必暴露出子域外子域基础服务子域基础服务通常是最小粒度的服务，他们提供更低层次的服务，用来提供子域内子域业务功能的基本功能支撑基础子域服务子域基础服务通常也提供教小粒度的服务，用于支撑上层业务功能服务的业务功能完整实现。基础架构服务层基础架构提供了在更高层级服务构建中

20、细粒度的能力，独立于任何业务域。这些服务需要和业务相关明确区分开来，例如安全认证，权限管理以及纯粹技术编排服务。四、服务角色独立于服务的粒度，职责范围以及服务创建以外的另外一个重要考量或者说是侧面是：服务在服务组合或者流程编排中所承担的角色是什么？那么怎么来区分不同的角色呢？我们使用关注点隔离的架构原则。例如，我们在构建应用中就使用了将数据同逻辑隔离作为重要的概念。这样不仅提供了不同关注点解耦的可能以及机会，而且允许采用不同的方式，在不同的地方来实现这些不同的关注点。对业务流程进行单独管理的BPM就是一个非常好的例子，BPM作为另外一个关注点分离的例子，将业务流程方案从其他逻辑中分离出来，可以

21、使工作流程可以在一个特定的层次或者环境内进行执行和管理,这样就可以实现通过快速的建立新的流程模型来快速响应业务的变化。同时面向服务的架构SOA提供了将业务服务作为构建业务流程的基础构件的功能。业务规则系统BRMS同样也作为一个关注点分离的例子，将业务规则或者业务决策从其他应用逻辑中区分开来，这样业务规则和业务决策也可以在一个特定的层次被执行和管理，从而就可以很容易的被变更来支持新的业务需求。这里，业务规则以及决策服务也是面向服务的机构来暴露出规则和决策服务来支撑规则和决策与业务流程的分离。通常我们通过较粗粒度的来定义三大类服务角色来构建不同的服务层次：任务服务角色任务服务通常实现一个完整的业务

22、功能，既可以是基本业务功能，也可以是复杂的业务功能，如计算某个货品在某个仓的补货量，或者一个简单的业务校验，如此货品在此仓是否可补。此服务类型颗粒度范围较广，包含从独立的子域基础服务到大的平台业务服务都可以具有任务服务角色，更小颗粒度的服务倾向于具有更通用的目的,更大的可重用的潜力。业务服务几乎总是承担任务服务的角色，通常是小颗粒度服务较大的组合，可以被设计成支持一个或者更多特定的流程。因此这些服务通常在跨业务流程中广泛复用的潜力更低。但是也是正常的，因为他们通常是有其他可重用的服务组成的。通常，具有业务角色的服务是主动服务，通过主动行为来提供价值。实体服务角色主要管理访问业务实体的服务具有这

23、个角色。业务实体的例子如用户、类目、商品、价格、库存、购物车，主要对应主要的业务信息。实体通常是中到大型实体，倾向于独立于任何特定的业务流程,而可做为多个不同业务流程的组成部分。具有实体服务角色的服务通常通过适配和提供需要的信息来实现任务的方式来支撑任务服务。实体服务通常都具备较大的重用的潜力。规则/决策服务角色规则/决策服务是通过执行业务规则来提供业务决策的服务，如补货计划自动审核服务。规则/决策服务通常用作对复杂问题进行判断或者支持变化频繁的业务规则，如复杂且多变的审核规则等。规则/决策服务通常为小到中等大小颗粒度，通常用来组装成更大的服务。规则/决策服务是可以不同层次不同类型的服务，包括平台业务服务，子域服务，子域基础服务等，但是通常情况下规则/决策服服务也来支撑这些服务类型。从而用来支持业务流程内的活动。我们提供了一些基本原则来帮助我们进行服务组合以便于帮我们减少依赖，限制耦合以及最大化灵活性服务层次以及组合基本原则：业务流程的任务通过任务服务实现，业务流程路由的核心规则由规则/决策服务来提供，而不是定义在流程网关内。这一块内容后续详细说明。更高