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

如何设计服务以及服务化架构自从提倡SOA架构风格以来，个人觉得软件架构并未有特别突破的变革，主要是在SOA面向服务架构风格基础上不断演化迭代，基于服务的EA明确分层架构也好，微服务也罢，都是在面向服务架构基础上的适应不同的场景的迭代升级。我先抛出一个观点，我觉得服务化架构的本质，和西方教育界深受影响的古希腊哲学家苏格拉底的“产婆术”的教育思想本质上是非常相通的：苏格拉底的“产婆术”思想强调教育是一个“接生”的过程，教师就是“接生婆”，人们之所以接受教育是为了寻找“原我”以不断完善自身。也就是教育的目的在于唤醒而不再于塑造。同理服务化架构的本质也不仅仅在采用什么样的技术框架实现和塑造，更重要的是在于通过不停地在共创中反问、反思、反省等方式进行对业务的本质的不断追溯、抽象、综合归纳演绎，我们的每一个架构师都是服务化架构的接生婆，我们的使命是建立真正反映业务本质并驱动业务不断向前的架构。我们是否足够深入理解业务的本质，做了足够的归纳演绎以及综合抽象，是否清晰的反应到了我们的服务化的根基：业务模型、域模型以及平台公共语义模型上？这是我们每一个参与服务化的每一个产品、架构师、TL和核心开发同学需要回答的第一个根本问题。定义面向服务的架构（SOA）：SOA是一种架构风格，致力于将业务功能保持一致的服务（系统服务，应用服务，技术服务）作为设计、构建和编排组合业务流程以及解决方案的基本单元。目的我们采用SOA的架构是为了什么呢？为了更好的复用？为了更好的责任切分？为了接口和实现的分离，提升灵活性和隔离性？还是为了更好的接口分类和管理？以上说法其实都没错，但是面向服务化的架构SOA的目的远远超过接口技术细节的设计与定义，其核心的关注点在于服务的业务内容以及内涵，而不仅仅是如何设计和实现。同时，SOA更多的也不是如何构建一个服务，任何人都可以很容易地创建一个服务，这并不是SOA的核心挑战，而是如何赋能企业构建有业务价值意义的完整业务语义的服务集合。面向服务的架构致力于在企业内的不同的业务环境内，建设业务功能驱动的服务，从而将服务组装成有价值、更高级别的业务流程和解决方案平台。面向服务的架构的真正的价值体现在当可重用的服务被灵活组合、编排在一起来构建敏捷的、灵活的业务流程，其中敏捷体现在服务可以快速调整，独立演化；灵活性体现在服务由于其业务功能定义明确，边界清晰且功能内聚性强，同时服务具备各自独立完整生命周期，可被灵活组装。如果面向服务架构能为企业提供了重大的价值，那么这些价值通过什么来体现的呢？价值体现行为一致性面向服务的架构允许我们为业务流程、任务或者决策拥有唯一的共同的入口，也就是，不管服务访问的路径如何，服务给业务提供的业务行为都是一致的。数据一致性面向服务的架构允许我们为业务数据信息提供单一的访问入口，也就是它提供给业务一致的、企业内部共识的公用数据访问。模块化及敏捷性面向服务的架构SOA为业务功能、业务决策和业务信息的模块化提供了非常好的机制。同时，在模块化实现好的情况下，这些模块可以在多个业务流程和场景中被灵活复用和重新组合，从而为业务竞争力和创造性提供灵活性和敏捷度支持。功能与数据的解耦面向服务的架构SOA提供了业务功能和信息集成的同时，减少了他们之间的依赖和耦合性。也就是，独立的业务功能单元，应用系统，可以一起协同工作，同时各自又具备各自的演进计划，生命周期和业务目标。高度可管理性SOA提供给我们通过定义服务水平协定在服务模块粒度支撑我们的业务目标，我们可以不断的设定、监控和优化调整组件，应用以及系统所承载服务的考核。其中行为一致性和数据一致性作为服务的核心价值根基。服务一、定义首先我们先定义一下服务是什么？服务是通过服务契约的方式来提供业务功能的独立单元，同时受服务契约所明确管理。服务是设计、构建和编排组合一个完整业务实体中业务解决方案的基础单元。服务契约指定了服务消费方和提供方之间所有的交互约定，包括：服务接口接口文档服务策略服务质量服务可用性性能那我们经常听到模块、组件等其他的软件构件，服务和他们有什么区别呢？其中最核心的区别在于服务本身是被明确管理的，其服务质量和性能是通过服务水平协定（SLA）被明确管理的，而模块以及组件并无此约束。此外，服务的全生命周期包含从设计、部署到增强升级和维护都是可管理的。举例（下列内容仅做示例展示用，非适用于严格场景）：补货计算服服务策略服务质量性能要求补货建议量计算服务针对行业下商家/供应商维度的入仓货品补货建议计算在销量预测符合分布要求且满足准确率水平要求的情况下，根据缺货率服务水平要求的产生的补货建议量符合业务期望的周转天数10W+货品*30仓，品+仓补货及建议量=30min订单创建服务包含购物车下单+立即下单场景，满足所有优惠计算后的订单生成订单创建成功率99.999999999%峰值支撑：100w单/s二、服务构成服务自身主要包含两个主要方面，第一方面也是服务最核心的方面就是服务的接口，另外一方面则是服务的实现。服务非常好的实现了接口和实现的分离。1）服务接口服务接口指定了服务的操作，也就是服务是做什么的(What),操作的输入输出参数，以及用来约定如何使用和提供这些能力的协议。服务通常包含围绕着一个核心的业务功能操作以及相关联的操作。例如补货建议计算服务中核心的操作是生成货品+仓维度的补货建议单，其他相关操作包含查询补货建议单相关销量预测操作，查询补货建议单对应计划库存操作。服务核心功能操作关联操作补货建议计算服务品+仓维度补货建议计算补货建议单对应销量预测查询补货建议单对应计划库存操作2）服务实现服务实现指的是服务如何通过其明确定义的接口提供其能力。服务实现可以通过以下方式实现：完全基于编码实现基于其他服务的编排而成基于已有应用适配封装而成以上情况混合实现核心点是服务如何被实现的对于服务消费方来说是透明的，服务消费方仅仅需要关心的是服务是做什么的，而不是如何被实现的。服务可以提供在保持服务接口或者行为约定不改变的情况下，提供根据不同的行业不同场景提供各种不同的实现。服务实现在保持服务接口或者行为约定不改变的情况下，可以自由进行升级和切换。服务实现既可以是静态的更新升级，也可以使动态路由实时切换实现，如对应到不同的行业以及不同的业务场景的自动实现切换。不管服务实现如何升级或者按需自动路由切换，只用服务的行为和契约不会发生改变，用户也就是服务的消费者根本不会感知到任何不同。我们可以把服务接口想象成室内普通电源国标插口，服务策略为室内非防水情况下适用，服务契约想象成24X7的220v电压供电能力（其中180V～250V50Hz是质量要求，24x7稳定性要求，电流供给=10A是性能要求），此国标插座（服务提供方）可以给包含与此接口匹配且符合契约的任何电器（消费方）交互并提供供电能力，支持其运转。服务接口定义了交互的的风格和细节，而服务的实现定义了一个特定的服务提供方或者特定的业务实现如何提供其能力。这种类似连接点/插口的设计极大的方便了更松耦合的业务功能解决方案。三、服务接口与服务实现的逻辑构成服务接口与实现的构成也有两个重要的不同方面，分别是执行功能的方法和执行的信息数据。换句话说，一个服务是由一个业务服务操作集合以及对应操作的输入输出的抽象业务服务数据模型组成。这层业务服务数据模型是企业业务层次或者平台业务层次的业务实体的抽象，独立于底层数据存储与实现。此业务数据模型是和各子域密切相关联，但是超越各子域以上的，在完整的业务线或者平台层次上达成一致的业务数据模型，也就是说在各子域之间达成共识且约定的严格明确的公共模型，主要用于平台业务流程中不同域服务的交互，是平台层次统一的业务语言，我把它暂时称为平台业务数据模型。此平台业务数据模型通常需要包含平台统一语义的业务术语表，平台各域核心实体表，平台各域核心实体交互图等。接口与实现的逻辑构成：1）服务操作服务操作声明定义了这个操作的输入以及输出参数。2）平台业务实体模型平台业务实体模型描述了服务中输入输出数据的结构以及含义。服务接口中的信息和服务实现中逻辑数据之间的差异是至关重要的。在服务接口层次上，最重要的是信息必须在业务服务之间进行交互来赋能业务流程并完成业务流程。这些信息必须在参与流程的所有业务服务间达成一致且在服务之间通用，也就是平台层次所有服务公用且标准的业务实体模型，同时此业务实体模型必须在平台业务语义上明确且完成，确保可以支撑平台所有端到端的业务。此平台层级的业务实体模型并不是一蹴而就的，但是可以随着平台的重心变化不断迭代完善成型的。然而不同的是，从内部来看，很多服务在各自实现的子域内部都有这些信息的不同的超集，可能潜在的存在不同的数据格式。幸运的是，我们不需要感知也不需要在所有关联服务的相关子域实体模型上达成共识，即使不是不可能，但是也不太现实。与之相反，服务接口和服务实现的分离设计允许非常方便的进行平台业务实体模型和服务所在子域领域模型进行映射转换。3）服务接口最后一个重要的方面就是服务水平协议SLA。服务水平SLA协议指定了服务的的两个重要方面的指标，分别是业务上的指标和技术上的指标：技术指标：响应时间RT，并发吞吐量Throughput，可用性Availability，可靠性Reliablity。业务指标：完成的业务功能的质量或者完成度，如产生的补货建议是否满足业务预期的周转缺货KPI要求：周转下降10天，缺货率下降5%。服务化分层架构理解服务化分层架构，首先要对TOGAFMeta-Model有个清晰的理解，从元模型可以看出业务服务和业务流程的上承业务，下启系统平台的核心作用，一定要深刻理解业务服务和业务流程在企业架构中的重要性，下面我把我翻译后画的版本给大家放在这里，给大家做个参考，TOGAF不多做解释，如有需要，大家可以交流，后面有时间尝试写下我对TOGAF的学习和理解。通常情况下，我们会按照不同行业的不同的业务流程去搭建系统，如供应链最初在大家电3W行业孕育，我们按照3W的行业和业务场景搭建了平台商家相适应的计划系统；后续自营行业又根据自己的行业也搭建了自营的计划系统；后续小电数码、国际以及其他业务快速发展，跟随业务快跑的同时，也各自建立的各自的业务流程。在这个过程中，BPM为建造不同的业务系统提供非常好的抽象支撑，但是经常的结果是，BPM被用作构建了更高层抽象的，也更高效的，但是却是烟囱式的应用，而不没有更好的贡献更多的支撑到整体上能快速应对业务变化而更灵活，更敏捷的业务平台或者系统。而这正是面向服务的架构中业务规则以及决策作为服务要发挥更大作用的地方。面向服务的架构允许我们将特定业务流程中的业务规则和业务决策抽象分离出来变成业务规则或者决策服务，这些规则和决策服务就可以被灵活应用到不同的业务流程中，从而这些服务可以被统一管理和演化升级。BPM+SOA一起提供了支撑企业架构的完美组合。BPM提供更高层抽象定义业务流程的能力，以及与流程相关联的重要监控和管理能力；业务服务提供了支撑业务流程的核心的功能、决策以及信息。面向服务的架构则提供能力将服务组合在一起来支撑和创建灵活且敏捷的端到端的企业业务。如果只有BPM而没有SOA对于创建单独的业务应用或许非常有用，但是通常是创建的烟囱式的应用，很难扩展到企业内或者平台内不同的业务线。如果只有SOA而没有BPM虽然可以创建可重用且一致性高的服务，但是缺少将这些服务快速搭建业务流程并支撑端到端业务的能力，也无法支撑建立具有竞争力且可以随着外部竞争环境进行敏捷反应的业务。下图显示了一个建议的的封层服务化架构图，各分层如下：端到端业务流程业务流程是按照一定业务规则决定的顺序执行的业务操作组成。高层级的业务功能，通常跨越应用域或者业务线。通常由行业开发团队开发，此行业开发团队可以具备明确的实现组织结构，也可以由跨团队的相关域共同组成虚线团队。例如，电商业务中，用户选购下单交互流程；供应链业务中的补货调拨计划流程等。平台业务服务高度模块化的业务功能单元，由不同类型的子域服务组合编排而来，可作为业务流程的编排单元。跨行业通用的