[转]SOA架构设计经验分享—架构、职责、数据一致性

阅读目录：

• 1.背景介绍
• 2.SOA的架构层次
  • 2.1.应用服务（原子服务）
  • 2.2.组合服务
  • 2.3.业务服务（编排服务）
• 3.SOA化的重构
  • 3.1.保留服务空间，为了未来服务的组合
• 4.运用DDD+GRASP进行分析和设计（防止主观的判断致使错误的假设）
• 5.SOA分布式下的数据一致性
  • 5.1.分布式事务（基于DTC的分布式事务）
  • 5.2.事务补偿（提供正向或反向的操做来让数据在业务上是一致的）
  • 5.3.异步EDA（基于异步事件流来实现柔性的分布式事务）
• 6.总结

1.背景介绍

最近一段时间都在作系统分析和设计工做，面对的业务是典型的重量级企业应用方向。忽然发现不少以往以为很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。

软件的生命周期大概能够概括为四个基本的过程，分析、设计、实现、测试，固然这仅仅是一个最为粗略的表示而已。不一样的方法论有着不一样的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程当中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也一样有着上述几个过程，强调以人为中心，经过沟通来解决大部分的问题。

不能用好与很差来判断哪种方法论，只能根据目前的实际状况综合权衡。RUP的每次迭代中有几个关键的制品对系统分析、设计很重要，能够说是很是重要，如：词汇表、业务规则文档、用例、领域草图。这几个制品对分析、设计很重要，须要从这几个制品中提炼出设计模型最终才能落地。这主要用在业务复杂的应用系统中。而Scrum更加的轻量级，能够用在互联网项目中，业务不是太复杂的状况下。

其实我为何要强调软件工程及开发方法论，是由于我最近发现，作设计实际上是创建在分析的基础上的，可是这里面又有不少问题。大型企业级应用，并不能经过一次性分析就能够得出准确和所有的需求，初期阶段创建的需求70%都是不许确的。因此作架构须要有分析的能力才行且是创建在适当的开发方论上的分析，何时该用RUP，何时该用Scrum，何时该用XP都颇有讲究。分析与设计都须要有一个执行上下文，不一样的上下文对分析、设计的执行有着不一样的要求。

有句话我以为对架构者来讲颇有启发：分析就是作正确的事，设计就是正确的作事。架构跟语言跟平台关系不大，毕竟架构是设计过程当中的子过程，我想若是你的设计不合理，你用任何语言任何平台都解决不了问题。（这里的架构上下文指：企业应用架构不是基础设施的系统架构）

2.SOA的架构层次

进行SOA类型的架构设计就须要搞清楚SOA架构模型才行。并不能想固然的对系统进行简单的拆分就行，须要搞清楚SOA的架构模型是怎样的，每一块是干什么用的，这样设计由分析阶段输出的需求时才能正确的划分职责。

若是把SOA的架构简单的理解为是多个子系统之间的整合其实有点太过于简单，也没有真正搞清楚SOA的架构模型。按照SOA的正确方法论及目标模型，其实SOA在实现架构落地上，须要考虑到对服务的组合，不断的重用现有的服务，让企业应用能够逐步集成，快速实现业务的迭代。其实这就是本节要讲的服务的分层，经过分层将服务按照使用类型进行分配，上层服务对下层服务的包装，下层服务负责原子性的操做，上层服务对下层服务进行业务性的组合。

咱们来看具体的每一层的做用及主要职责。

2.1.应用服务（原子服务）

应用服务就是诸如：订单服务、仓库服务、销售服务、客户管理服务，这些服务直接对应不一样的应用系统，直接服务这些应用系统的原子操做。订单服务直接原子性的插入订单，没有任何跨其余服务的分支逻辑。仓库服务只管本身的仓库逻辑。一样其余的应用服务只管好本身的职责，杜绝对其余服务的调用。

图1：

应用服务位于UI与后台之间，后台咱们能够认为它是一异构的系统或者是数据库之类的。应用服务的位置位于前端与后端之间，起到相似一个服务API的做用，可是SOA中的服务还远远不止这一个应用服务，若是咱们的SOA架构中只有一种类型的服务，那么这会增长咱们系统的耦合程度，由于你没有对系统的服务进行层次的划分，你的业务功能会直接的落到某一个应用线上的服务，继续往下看。

2.2.组合服务

组合服务是对应用服务的一个组合,根据实际项目的规模大小,不必定非要进行物理的隔离,在代码层面的服务化也是能够的,在未来的某一天有必要的状况下再进行物理的拆分,毕竟物理的拆分有着严重的成本和代价，对系统的稳定性带来不少挑战。因此经验告诉咱们必要的时候在进行拆分。”分布式系统设计的第一个原则就是尽可能不要分布式“，这是马丁.福勒大师说的，如今理解确实感同身受。

图2：

组合服务对下层的应用服务进行了组合，完成了一个基本的业务动做，应用服务中是最基本的基础性的原子性的操做。可是在复杂的业务需求下大部分业务功能都须要跨越多个应用线来完成一个最外层的企业动做。提交订单可能须要穿过不少应用线，订单管理、仓库、财务等等环节。因此这里咱们还须要一个能在最外层对组合服务进行编排的业务服务。这个编排服务能够彻底是自动化的，经过工做流引擎进行组合自动化来完成，这对企业应用的自动化流程颇有意义。

2.3.业务服务（编排服务）

业务服务是最外层的服务，向下编排了组合服务。业务服务位于最上层，当须要有跨越多个应用线来完成的业务，这个业务就放入业务服务中。好比提交订单，先检查库存、扣减库存（冻结库存），而后下单，再日后通知财务，再日后通知物流等等都是一个复杂的企业服务线。这种最外层的业务逻辑若是你不进行SOA分层而后将其放入最外层的业务服务中，你把它放入任何一个应用线都会使系统调用混乱不堪。因此问题就是须要进行纵向的划分层次。若是进行了SOA的层次划分后就不会出现互相乱用的状况。其实这里能够参考阿里的服务设计方法。（李智慧写的一本大型互联网架构与实践里面也讲到了服务要划分层次）

图3：

当在业务服务中执行的业务逻辑时，须要跨越多个应用线来完成。这部分的逻辑也说是职责，若是不放入这个位置，放在哪一个应用线都不合适，放入哪一个应用线都会使系统调用出现混乱。其实这里的问题就是咱们不能用一个维度来进行SOA系统的设计，原本服务就具备组合特性，因此适当的提高服务的层次是有好处的，可是应用服务和组合服务能够在代码层面上进行构建，而业务服务也叫编排服务是须要进行物理隔离的，毕竟考虑到系统复杂度和稳定性问题这是值得的。在排查问题，系统性能、稳定性等等方面，物理的隔离有必定的做用，毕竟业务服务原本就是来组合多个应用线的，这样作会使整个系统架构很清晰。

3.SOA化的重构

进行SOA化的实施，大部分状况下都是对现有系统进行重构后考虑的，初期企业发展阶段以快速出原形为首要目标，只有当系统出现瓶颈了才会考虑运用SOA来解决。可是在这个时候有不少历史包袱没法解决，进行SOA化的重构其实成本是很高的，并且很危险，对有些复杂的逻辑说的现实点，是无能为力的。若是均可以经过重构这个技术来解决，那咱们就太天真了。《重构—马丁.福勒》一书讲的是代码层面的重构，跟作系统级重构两个概念。对系统级别的重构尚未太多成熟的方法论支撑。尤为如今新技术层出不穷的，各有优势，能很好的运用这些技术、方法论、过程来重构大型企业级系统，难度很是大，这须要整个公司投入不少人力、资源成本。回过头来想一想，其实在前期适当考虑一下仍是有必要的，这样能够减小后期不少技术债务。

这里我只总结我在分析、设计公司某一块业务系统的时候对其进行SOA化的重构思路。重构原本就是一个不断迭代的过程，不能够跨大步。经过不少脚手架支撑，让系统慢慢的过分到新的SOA架构下，既然要实施SOA架构，那么很重要的一点就是对迁移的业务逻辑适当的归类，什么业务逻辑该放入“业务服务”中，什么逻辑该在代码层面上放入“组合服务”中，对基本的操做有如何放入代码层面的“应用服务”中。

3.1.保留服务空间，为了未来服务的组合

在进行系统拆分的时候，对当先后端的调用都进行适当的规划，将其分为两类，一类是应用服务，一类是组合服务，这两个服务是能够在代码层面上进行抽象。重点是那些调用其余系统的地方，须要将其放入业务服务中，这块逻辑比较复杂，难以抽取，须要适当的结合”数据落地“的思路来综合考虑。有时候把一部分数据落入本地能够提高系统的总体简洁度和稳定性，可是要考虑数据的一个生命周期性质。

在迁移的过程当中可能还会有一些新的功能并行开发的，既有新的逻辑须要放入新的SOA服务中，也会有迁移过来的逻辑，这两个过程同时进行其实很痛苦，尽可能避免这样同时进行，可是现实是根本不可能，正常都是一块儿并行推动。若是这两个过程是同一组团队负责其实还好，毕竟对这块的代码、业务都比较了解。

这一节目的是想强调对如今系统进行迁移的时候要考虑服务的层次，不要只进行一个简单的搬移代码，这个时候是一个对代码进行重构的好机会，该划分层次的要划分层次，该读写分离的要读写分离，要重点考虑那些“业务服务”，须要跨越多个应用线的逻辑。

顺便说一下，还有一个重点就是迁移的时候还要考虑数据存储方面的迁移，光代码层面的迁移只是第一步，第二步还须要进行数据层面的迁移。固然这两个大的步骤都是要经过不少次迭代完成，而且仍是一个对业务、代码进行很好梳理和整理的好机会。

在将系统进行服务化的时候要考虑服务层，若是当前没有业务服务的逻辑那么就保留服务空间，至少要清楚在服务层中有这么一个空间是要预留的，当有其余的应用线须要与你交互的时候能够顺利的进入到你的服务区，而不是直接到达你的应用。

4.运用DDD+GRASP进行分析和设计（防止主观的判断致使错误的假设）

作系统设计时最怕的就是职责搞错了，这会使系统的架构忽然就复杂了，并且系统架构都是很难改变的或者压根就没法改变的决定。因此我对这块引发了重视，有时候你对业务在了解在熟悉依然会搞错职责，对于这块光凭主观的判断是不长远的，无发复制、没法传播的，也没法落字成文的。

对DDD我这里就很少作介绍了，这里要强调是GRASP。运用DDD能够很好的帮助咱们来战略性的观察企业所坐立的领域，我仍是很提倡DDD在公司实施的，不说DDD中的“战术设计”方法论，就光说它的“战略设计”方法论仍是有很大做用的，让咱们能够在脑海中创建一个战略性的模型。具体要不要进行代码层面的落地这就看实际状况了。并且DDD中的不少不错的思想均可以借鉴过来，包括领域通用语言，有了领域通用语言团队之间的沟通和交流会节省不少成本。对于新人来讲，能够很快的了解公司的一些大概的业务，这和“词汇表”其实仍是有区别的。

上面说了，在划分职责的时候不少都是经过经验来主观的判断，没有其余的客观证据了。那么有没有一个不错的方法论或模式来指导咱们进行这类问题的解决呢，其实仍是有的，由于在国外人家这方面已经很成熟。

GRASP就是这样的一套模式，它能够帮助咱们进行客观的设计职责。到底该把这块数据放入哪一个应用中，到底该把这个逻辑放入哪一个服务中，都有指导，包括对对象层面的设计依然能够。咱们可能对“信息专家模式”都有了解，可是以往咱们可能都只把它用在对象设计上，而没有提高一个系统层面中考虑。那是由于咱们以往可能没有遇见很复杂的职责分配场景，只有当出现问题时咱们才能真正领会某个东西的好坏。

DDD只有结合GRASP才能客观准确的方配某个领域的职责，无论是战略设计层面仍是战术设计层面，都是一个很好的平衡标准，不会因为技术人员主观的兴趣倾向致使一个错误的职责分配决定，而这个错误的决定最终是要开发人员来买单。

5.SOA分布式下的数据一致性

传统分布式系统与当代的面向SOA的分布式系统有必定区别，论概念上来说SOA是以服务为中心，既然以服务为中心就会有不少面向服务的设计原则。而传统的分布式系统没有服务的概念，也没有所谓的一切皆是服务的原则。而当代SOA则首要原则就要以服务为中心，针对服务的设计又有了不少服务设计原则。

SOA对服务还进行了类型的划分，按照服务的应用层次来分类：业务服务、组合服务、应用服务，包装服务等。再按照管理与运维的层面来分类：控制服务、调度服务、监控服务等等。传统的分布式系统是没有这些的，咱们谈论的是当代SOA的分布式系统，因此咱们强调的是以服务为中心，以服务设计原则为架构设计的指导要求，当代SOA是对传统分布式系统的一个迭代进化，不是一个时代的产物，SOA更增强调了以服务为首要原则，已经提高到了另一个更加高级的层面。

本节咱们交流一下在当代SOA分布式系统中的数据一致性问题，在SOA中这主要涉及两个层面来考虑，一个是服务层面、一个数据持久化层面。再按照一致性的基本要求，能够分为：读一致性、写一致性、会话一致性、最终一致性、实时一致性等几个维度，固然还有其余几个维度的一致性要求。

咱们这里重点讨论在企业应用中实施SOA时遇到的一些比较棘手的数据一致性问题和解决方案，对于刚才提到的几个维度的一致性要求均具备重要的参考价值。

5.1.分布式事务（基于DTC的分布式事务）

以往包括目前不少项目仍是倾向于使用DTC来处理分布式事务，这个方案多数适用于通常的企业应用，业务、访问量、数据量要求都不是很高的状况下。用DTC很方便，事务的自动传播、事务的自动感知、事务的自动回滚和提交，这都是中央DTC帮咱们管理好了。

因为有中央DTC的统一协调，看似好像帮咱们解决了不少咱们须要考虑的问题，可是它也是整个平台的致命的瓶颈，一旦DTC因为某个问题出现错误，并且这种错误都是系统层面的错误，不少问题咱们是无能为力的。若是出现问题，整个应用平台都没法完成任何一个跨服务的业务流程，这其实很危险，你不没法控制系统的稳定性。

这里总结，DTC用于通常的小型企业应用，不建议用在中等规模的企业应用中，不是说这个东西很差，而是没法控制它。

5.2.事务补偿（提供正向或反向的操做来让数据在业务上是一致的）

世界级SOA专家所编写的书籍里都提到了使用“补偿”操做来完成数据的不一致性，当咱们编写了一个服务方法A，就须要一个服务方法A1的补偿接口来完成A服务的补偿操做。可是真实的业务状况下很难实施这种看起来好像很优美很柔性的设计。没有实践就没有发言权，咱们公司的技术团队就实施过这种方案，可是很不理想，这跟技术自己及技术团队不要紧，只是咱们的平台业务太复杂，很难去“补偿”一个已经作过的操做。

这固然也要看你所面对的项目状况，量变引发质变，若是你的各类量都上去了，这个“补偿”方案不实际，并且很难在数据层面进行“补偿“。总之，这不是一个中长期的方案。

5.3.异步EDA（基于异步事件流来实现柔性的分布式事务）

EDA简称”事件驱动架构“。多个系统之间经过传播”事件“来驱动整个业务的运转。系统之间没有紧耦合的同步调用的操做，都是经过发出异步的“事件”来通知下一个业务环节。

可能你会有一个疑问，异步操做，是否是系统之间延迟会很长，其实不是，如今有不少成熟的消息中间件在内网内几乎是毫秒级别的延迟，至于跨机房就看物理上的距离了。

异步操做有不少好处，这里我就不浪费你们时间重复那些好处。使用EDA实现系统之间的一个松散的事务关系，要把控好项目的质量，对系统的非功能需求、BUG数等等可能会影响业务操做中断的地方都要创建起适当的机制，让这些问题尽早的在线下解决。好比能够实施UnitTest、持续集成等一些敏捷的方法论。

6.总结

一样一个工具在于什么人用，真正的工匠都是使用很朴实的工具来雕刻没法超越的艺术品，这就是工匠情怀。最近对工匠情怀感觉愈来愈深，一直觉得本身是一个比较喜欢专的人，这是否是偏离了一个大的方向冲进了一个小胡同，直到最近我才领悟，这实际上是”软件工匠“的精神。可是这不表明不考虑全局，这只是一种情怀，一种态度，对于架构也是，对于代码也是，不要认为那些看似可有可无的问题就忽视它，带着工匠精神雕刻它。

 

参考书籍：《SOA实践指南》、《SOA概念、技术与设计》、《精益软件》、《UML与模式应用》、《软件预构的艺术》

 

做者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面