让企业SOA项目更可控的十大戒条

3.除了要求的不要多做

产品驱动的服务分解

SOA主要的优势就是它是一个能被转化成技术的业务概念，不像数据库世界里那样，技术概念总想试图跟上业务的步伐。在SOA中，每个服务必须明确地增加价值，不只是在抽象意义层面上，而更具体地要针对那些调用方而言。发生的一切之所以这样发生了，是因为服务请求者要求其如此。通过不实现任何服务请求者没有明确要求的东西，服务可以被限定在它们的核心功能上。如果SOA中所有的参与者都积极这样去做，那么将会使互操作性大大增加。

SOA中最高层次的服务是业务交易：某个客户下了一个货物或服务的订单——除非订单被供应商拒绝——否则这就开始了一个订单交付。在SOA范式中，任何从接受订单到订单交付之间所发生的都可以也应该以服务的形式实现。为实现订单交付而要求的每个中间产品或状态，供应商会要求某些人或某些组织机构——不一定是供应商内部的组织——来执行交付。然后这些中间服务自身又可以分解成多个服务，一直到增加价值的基本组织层面。

层次服务分解是SOA范式中非常重要的一部分，因为它使服务交付通过服务水平协议的方式管理。它可以确保每个服务都有专人负责，并且服务消费者们知道他们会得到什么。

通用的中间产品和通用的服务

服务分解都是关于产品的。只有当组成服务的那些子服务不能立即执行时流程才会出现。例如，如果决定是否接受客户订单的服务要求：先执行判断订单价值的子服务，再执行确定客户信用状态的子服务，那么实现该服务就包含了一个流程。每个这样的流程只与一个服务相关。如果你发现有个流程不仅限于单个这样的服务，那么你很有可能是忘了把客户的初始需求建模为服务了。

有可能出现这样的情况，相同的中间产品——当然还有相同的服务——可能会被不同的高级别产品需要。比如，那些要求明显区分交付过程的商品，在中间产品的环节，其中的差别一般来说几乎微乎其微，中间产品其实也是由客户来支付——为了从客户那里赚取利润，我们需要金额、日期以及让我们可以冠冕堂皇地向客户要求支付的条款，实际是什么则并不用去理会。在这种情况下，正常的基准是如果存在通用的中间产品，那么它应该由单个服务来实现，而这个服务能够被多个高级别的服务调用。

这种服务只有结果是重要的——不是开始——因为收集对交付服务有用的信息是服务本身的一部分，而不是请求服务源头的一部分。需要注意的是：是否需要单个服务是由业务决定的，和信息技术没有任何关系。如果不管是现在还是相关的未来，交付相同的中间产品都是切实有用的，那么就应该有单个服务。除非在现在或相关的未来有商业力量发挥作用使中间产品发生结构性分化，那我们最好不要为每组需求分别提供相应服务。然而事实偏偏相反。在SOA，事物是由相同走向不同，而在数据库化的方法中，事物则是由不同走向相同。

带有多种行为的通用服务

你可能会问，如果需要两种完全不同的行为而你只为其提供一种服务，这样做的意义何在呢？难道我们还在被同样困扰数据库世界的“一刀切”做法限制？比如，如果我们出售两种类型的产品，其中一种使用固定价格而另一种则根据某些复杂的公式计算出变动价格，为什么不用两种结算服务，为每种特定的产品各订制一种呢？

这些问题很好，但问错了地方。它们是好问题，那是因为任何不能充分应对发生在问题域内变化的设计方法注定会失败。但是它们问在了错误的地方，这是因为根据问题域中的变化来调整方案的灵活性应该构建到服务中，而不是围绕着服务来构建。就拿结算服务来说，每次调用一种方法时，它应该决定这两种算法应该使用哪一种。那样的话，如果引入第三种结算算法，那么只有结算服务需要去做调整。请注意这并不意味着结算服务必须被设计成某种“万能”机器；它同样可以很好地为每个算法分别调用相应的子服务。这种选择——介于多功能解决方案和包含不同组件的框架之间——是一种可以根据服务来决定的选择，因为它不需要被服务请求者知道。在SOA中，这种选择更常见，但目前的做法则常常导致产生框架解决方案，因为需要多功能方案的感觉在很大程度上是由于不能从那些需要执行的信息里识别出服务请求造成的。这种需要高素质专家来实现的带有如此多参数的以一应十的多功能方案的日子不会长久了。

坚持要点

流程驱动方法也可以使我们分清我们是代表服务请求者做事还是为自己做事。以服务请求者身份做的事应该作为服务的一部分来执行，而其余的就不应该了。通过这种区分，我们可以让服务尽可能简单，这样可以在不需要改变各式各样其他东西的情况下替换掉该服务。举例来说，我们会生产产品来满足外部服务请求，但是维护簿记系统是为了满足我们自己的需求，而不是请求者的。如果要开发一项服务将客户订单转变成制造活动及账目簿记，那么只要我们实现一个新的簿记系统，我们就要去修改一次这个服务。这听起来似乎还不是太糟糕，但试想一下所有事情都是为我们自己而做，那就太糟糕了。包含最新数据的数据仓库的簿记、日志、储存、员工绩效数据的维护：所有这些及其他事情一般都由系统完成，这些系统随组织机构和时间的不同而不同，因此在业务服务中包含这些知识会降低互操作性，增加了用其他系统来实现服务替换的难度。我们可以通过产生通知的方式来避免此类问题，即：如果对这些功能很重要的事情发生了，就发出通知，然后它们可以使用通用服务检索处理事件所需的信息。

另一类不应作为服务一部分执行的业务活动包括那些一旦服务请求被撤销就无法逆转的活动。通常来说，这类活动包括诸如因客户订货导致库存量低于补货水平从而需要订购补给、注册新用户以及更新现有用户信息。这些活动是整个流程中的各个步骤，应使用单独的服务一一执行。

当然，这种思维方式可以与数据库范式紧密结合。但并不是其所特有的，因为它与SOA有关。结果是，许多SOA的实现与数据库化的思维方式背道而驰，而正是这种思维方式激发了他们以自下而上的方式识别服务，而非SOA的自上而下方式。在自下而上方式中，原本一开始为某个问题开发的服务也可以为其他问题复用，这多亏了设计它的人对于如何更广泛地应用做了认真的思考。SOA中，在多个上下文中使用某个服务是缜密设计的结果，而不是靠直觉，并且从设计之初就将所有那些上下文都考虑了进来。说到复用某一服务来交付某一通用的中间产品就好比说重复使用前门进入房子，不管那扇门是通向客厅、厨房，还是卫生间。你能想象厨房设计师说：“真妙！那家伙设计的室外通向客厅的入口正好可以被我用来作为通向厨房的室外入口！”吗？任何谈论“复用”（如复用支付服务）的人都还没有实现它。请注意，这并不是错误的，只是有点奇怪和没有什么启发性罢了。

服务遵从业务

采用SOA方式思考问题的一个结果就是SOA会使得服务依据其业务意义而非机械的实现来表述。例如，名为增加用户记录的服务是数据库化的，而名为注册新用户的服务就是SOA的，即便这两个服务做的事情完全一样。我们对服务的命名十分重要，因为它告诉我们是谁在请求该服务，以及为什么他要请求这项服务。在这个特定的例子中，SOA自上而下的方法会得到一个结论，那就是业务流程需要一个有效的用户注册服务，该服务通过修改现存的注册服务（如果有的话）来完成，而不是重新自动创建一个新的。在SOA中，这是用户注册服务的责任，而数据库化的方法却会把这个责任推到服务请求者身上。类似地，SOA注册用户服务自身会决定用户ID是什么，而数据库化的服务可能就会干脆让服务请求者做这个决定。

汇聚到单个方案

总的看来，SOA由上至下的思维方式使得很多设计决策只存在一个选项，而数据库化的思考者会把该选项仅仅看作众多可选方案之一。这是SOA很重要的一个优势，考虑到SOA是以互操作性为导向的，而互操作性要求我们行车时都在同一边行驶而不用去和我们碰到的每辆车去交涉。那些忽视这点的人--比如通过主张Web服务只是众多实现跨系统边界SOA的一种方式--能够一直成功的机会和那些只考虑下一步的棋手差不多。诚然，总是有比Web服务更简单的方法去连接两个系统，但是为了让呼叫中心或输出管理设施能使用相同数据你会怎么做？为了确保数据仓库能够在你把事件从一个系统转换到另一个系统时得到通知，或者事件一发生便能及时通知你的客户，你又会怎么做呢？在SOA的世界里，数据和事件必须在多个系统中可用，而Web服务是能够确保在低投资和低维护成本的前提下达到这一效果的最有效的方法。

存在这一明显差异的一个领域就是电子数据交换（EDI）。传统的电子数据交换（EDI）技术旨在确定组织之间通信可能需要的信息，并为该信息定义词汇。那和定义某一特定的信息交互不是一回事。比如，你可以使用相同的EDI报文来下订单、查询其进展以及修改它。两个组织想通过这些规范进行通信必须坐下来一起就这一词汇的使用方式达成一致。SOA分离了这些关注点：词汇由命名空间来处理，而这些命名空间可能会被多个服务使用，每个服务有各自特定的目的。

“SOA由上至下方式导致更具体的结论”的另一领域是这样一个问题：是什么筑起了一个编排过的流程边界。通常，这个问题会引起无休止的争论。比如，采用输出管理服务给客户发送确认信息是否应被编排为用户流程的一部分，如果是的话，它应该采用即发即弃（fire-and-forget）的方式处理还是应该由输出管理服务来报告动作成功完成？按SOA的话讲，所有这些东西都是用户意图的一部分，因此都应该被编排的。其他一些行为，比如考虑到新用户订单的更新数据仓库或者更新总分类，很显然都不是用户意图的一部分，不应该包含在流程编排中，哪怕它们是同一方执行的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友