设计分布式SOA系统需要避免几大误区

日期: 2013-03-06 作者:Jason Tee翻译:蒋红冰 来源:TechTarget中国 英文

你的组织是否涉猎SOA?你是否在犹豫不前,因为你不想因错误的方式而浪费资源?如果你能够了解怎样避免出现平平无奇的SOA的陷阱,会怎样?不妨来看看分布式系统架构幕后的奇才Arnon Rotem-Gal-Oz,看看它是怎么做的?这里是TheServerSide的一些发现:   面向服务架构不是魔法   这是建立分布式系统的一个简单该当,因为它是组件化和灵活的。然而,当组织不了解原则时,他们就会遇到麻烦。我们问Arnon(Nice Systems公司企业部分架构主管)哪里人们最容易出错。你回答说:“他们在服务粒度大小上容易错。

他们需要金凤花的大小,不能太大也不太小。”   组织通常需要在业务流程灵活……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

你的组织是否涉猎SOA?你是否在犹豫不前,因为你不想因错误的方式而浪费资源?如果你能够了解怎样避免出现平平无奇的SOA的陷阱,会怎样?不妨来看看分布式系统架构幕后的奇才Arnon Rotem-Gal-Oz,看看它是怎么做的?这里是TheServerSide的一些发现:

  面向服务架构不是魔法

  这是建立分布式系统的一个简单该当,因为它是组件化和灵活的。然而,当组织不了解原则时,他们就会遇到麻烦。我们问Arnon(Nice Systems公司企业部分架构主管)哪里人们最容易出错。你回答说:“他们在服务粒度大小上容易错。他们需要金凤花的大小,不能太大也不太小。”

  组织通常需要在业务流程灵活性、性能和重用性之间做出权衡。做为一个例子,恰当的粒度意味着少量的网络流量,但是每个调用要检索出更多的信息。经验是解决这些问题的老方法。但是通过阅读关于《SOA项目服务粒度(Service Granularity in SOA Projects)》的,这篇富有洞察力的硕士论文:Claudia Steghuis的权衡分析(A Trade-off Analysis by Claudia Steghuis)后,你仍然可以避免重新发明轮子的问题。

  不要抓的太紧

  模块化你的交互,找出把服务恰当地构建到一起方法,是很关键的。因太紧耦合而失败的解决方案是一个常见的错误。管理一个单片系统是非常困难的——但它确实是扩展的问题。紧耦合系统允许你控制所有,且从单一解决看事情。如果你有一个小的、简单的解决方案,那么从管理员的角度来看它是非常吸引人的。从是Rotem-Gal-Oz警告说,一旦你走入一个特定的大小(或你有很多开发人员),你就会丢失敏捷性。


  —系统的不同部分之间有许多信赖关系
  —你不得不等待其它团队成员进入到下一个项目阶段
  —你不自己自由发展,因为实施更改需要巨大量的时间

  在持续部署时代,这种笨拙的发展步伐是不可以接受的。聪明的组织知道技术、需求、接口和其他方面的计算很容易改变。SOA使系统组件化,因此你得到更小的部分,很容易管理。这并没有为也web而使开发变得更加敏捷。它也创建了一个移动开发变得更简单的环境,因为你需要在资源非常受限的平台上获得更多的灵活性.

  把各部分组合到一起

  当然,在你的SOA拼图中有越多的部分,意味着就越来越多的耦合需要管理。Arnon说这不一件坏事,“学习怎样使事情更好的一起工作是一件有益的事。当你开始后,你会得到意想不到的行为。”从SOA角度进行模块化和了解你的业务流程的一些额外努力并不是错误,相反它是一种特色。

翻译

蒋红冰
蒋红冰

TechTarget云计算主编,主要负责云计算和虚拟化网站的内容建设。长期专注于IT前沿技术,对云计算、虚拟化、人工智能、区块链等技术都有了解;对行业趋势、市场动态有一定的洞察。

相关推荐