多年以来，我们对 SOA 原则这一主题以及什么会促进 SOA 成功，什么会阻碍 SOA 实施等内容都进行过很多相关的报道。从初期的狂热宣传，到大规模企业的实施、Web 服务以及较近期 REST 带来的影响力。我们可以通过这 7 年来的文章，对 SOA 的演进进行追溯。然而，在此期间的成功案例却通常少之又少，据一些数据表明仅有 20% 的 SOA 项目获得了成功。其中包括了 CISCO 和 eBay 等几个著名的成功案例。
InfoQ 英文站编辑 Jean-Jacque Dubray 不仅帮助我们追溯了 SOA 在那段岁月的发展，也分享了不少他的个人观点。他对 SOA 起到了积极的影响并基于 SOA 原则部署过很多成功的系统。通过基于这些经验背景的思考，Jean-Jacques（JJ）最近在博客中发表了他所信奉的四条促进SOA 成功的原则：
1. 服务接口应该与服务实现解耦
- 所有业务逻辑应该标准化
- 变更一个服务应该是非常容易的
- 在服务消费者准备就绪之前，服务变更对消费者来说应该是不可见的
- 当服务消费者准备就绪之后，服务变更应该是易于消费的
- 服务版本控制应该基于兼容性
JJ 认为只要你在所有设计和开发阶段一贯地遵守这些原则，成功的机率将会大大提升。虽然这些原则相对来说比较容易理解，但遗憾的是他没有对所列举的这些原则进行更详细的阐述。对于“服务接口”，JJ 补充道：
大部分人在 SOA 中遭遇了失败，因为他们认为服务是一种抽象，就好比 OO 中的“类”。但实际上服务接口是一种契约，通过它可以暴露和控制变更。[…] 不要在你的服务边界（service boundaries）上耗费太多精力，应尽可能的将更多的精力花在构建最好的服务接口上（也就是指有效地管理变更）。
然而，JJ 所做的工作还涉及到围绕 SOA 相关的其他一些领域，这些领域在过去的时间里也曾引起了很多人的关注。其中包括治理（governance），对此他建议道：
不要“过度治理”，治理应该保持最小化并且是基于短期内（3-6 个月）的合乎情理的共识。而数据治理（Data Governance）则更为重要，因为你的信息模型发生的任何变更通常都会对服务接口造成影响。
松耦合通常作为成功 SOA 的核心组成部分而被人们广为称道，对于如何实现松耦合，JJ 建议道：
对消费者交互环境的管理不涉及接口背后的业务逻辑实现。在接口消费者中，不出现重复的涉及对各类记录系统状态管理的业务逻辑。
服务复用通常是 SOA 中另一个被认为非常重要，然而也很难实现的领域。早在 2009 年的时候，我们就援引过 Burton 的 Richard Watson 曾经说过的一段话：
一个服务可能永远不会被复用，但是我们仍然可以通过其他方式来创造价值：通过适应性和低成本的维护来减少冗余；通过对既定策略的贯彻执行来提升安全性和依从性，以上列举了一些我们期望得到的其他成果。而过于专注在复用上将会蒙蔽我们的双眼，从而导致我们无法看到这些其他的成果。
而 JJ 也赞同这一点：
没有人会指望今天构建的一个服务会在从现在开始的三年内被持续的新消费者们不断消费，这是荒唐的想法。如果你想以这种方式进行复用，那么你迟早会失败并最后得出一个例如“SOA 不起作用了”这样的愚蠢结论。对于 SOA（在现实世界中也是如此）的复用，它是以另外一种方式进行的：并不是一个新的消费者复用一个老的服务；几乎都是一个服务的新版本（变更以支持新消费者）在不打断老消费者的情况下被消费者复用。
事实上在 2009 年的文章中，JJ 曾对此有过以下评论：
大多数的人仍然无法理解的是：在 SOA 中的“复用”并不是人们通常听到的“复用”，对它们的理解是不一样的。在 SOA 中的复用是向前复用（forward reuse），而例如我今天早上听到的复用则是向上复用（upward reuse）。在 SOA 中，复用意味着为新消费者构建的服务新版本并不会打断现有的老消费者。对于认为某人能在今天设计出一个服务并且可以在两年内被一直“复用”这种想法，很大程度上来说是个幻想。在 SOA 中，较老的消费者可以“复用”那些为最新消费者而创建的服务新版本。
正如最初所提到的，所有这些原则和思想都受到了 JJ 在这个领域中多年经验的影响。其他人对于这些问题又是怎么认为的呢？你愿意也来分享一下你的经验吗?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论