SOA架构设计经验分享—架构、职责、数据一致性.docxVIP

PAGE 1 PAGE 1 SOA架构设计经验分享—架构、职责、数据一致性  最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发觉许多以往觉得很简洁的问题变得没有想象的那么简单，最大的问题就是职责如何安排。论系统架构设计的最大的问题，其实也就是职责的安排，安排的合理，实现起来就会很柔性，反之就会使架构很混乱。  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.组合服务  组合服务是对应用服务的一个组合,依据实际项目的规模大小,不一定非要进行物理的隔离,在代码层面的服务化也是可以的,在将来的某一天有必要的状况下再进行物理的拆分,究竟物理的拆分有着严重的成本和代价，对系统的稳定性带来许多挑战。所以经验告知我们必要的时候在进行拆分。”分布式系统设计的第一个原则就是尽量不要分布式“，这是马丁.福勒大师说的，现在理解的确感同