可能大家都听说过《Goldilocks和三只熊》这个童话故事。Goldilocks闯进了三只熊的家,她分别试了熊爸爸、熊妈妈和熊宝宝的粥、椅子和床去寻找一个觉得舒服的选择。很简单一个道理,能满足其它人要求的事物可能并不能让Goldilocks有满意感受,很多早期面向服务架构的支持者都认识到他们必须测算服务的大小才能解决他们的业务问题,从而使可重用达到最大化减少不必要的开销。不仅如此,这些早期的采用者还意识到他们必须处理服务基础设施的重要方面以及重新设计架构的最佳实践,哪怕是部署一小部分服务。
毕竟,成功的SOA实践需要的不仅是正确的服务,还需要用正确的方式实现它们。 ZapThink反复强调……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
可能大家都听说过《Goldilocks和三只熊》这个童话故事。Goldilocks闯进了三只熊的家,她分别试了熊爸爸、熊妈妈和熊宝宝的粥、椅子和床去寻找一个觉得舒服的选择。很简单一个道理,能满足其它人要求的事物可能并不能让Goldilocks有满意感受,很多早期面向服务架构的支持者都认识到他们必须测算服务的大小才能解决他们的业务问题,从而使可重用达到最大化减少不必要的开销。不仅如此,这些早期的采用者还意识到他们必须处理服务基础设施的重要方面以及重新设计架构的最佳实践,哪怕是部署一小部分服务。毕竟,成功的SOA实践需要的不仅是正确的服务,还需要用正确的方式实现它们。
ZapThink反复强调的就是SOA是企业架构的一个方面,本身并非一种技术,而更是一种规则。SOA最佳实践的精髓就是理解如何用正确的服务处理正确的问题。毕竟,IT是用来处理业务问题的,而不是实现技术方案然后用它们找出一些业务问题。
识别合理尺寸的问题
正确识别服务的合理尺寸一个关键是识别SOA项目的适当范围,换句话说,就是解决正确的业务问题。在处理SOA项目时关注公司想要的所有潜在服务是非常危险的。这种方法实际上就是想把整锅水都烧开,其实是毫无意义的。毕竟,SOA的目的是处理公司面对的不可预测的经常性的变化。所以,我们没有必要试图通过识别公司需要的所有服务来处理一个非常庞大的业务问题,因为这些服务还是会继续随着时间变化的。
另一方面,ZapThink曾经鼓励公司应该首先处理最小的问题才能成功应用SOA。现在,这很容易被误解成鼓励公司只开发粗粒度的服务,甚至是解决每人实际关心的一些小问题。SOA领域一些著名的专家对这个问题也存在争论,但他们对此问题的解释是适用于市场的。事实上,我们赞同其中的很多观点,尤其是James Governor的。相反,公司想要的最后的东西是细粒度的服务集合。它们满足的业务需求很小以至于每个单独的服务几乎是没用的。公司需要合适粒度的服务来处理业务问题,但是业务问题又应该是多大呢?这个问题不同于服务的粒度或者实现服务所需的基础设施、架构和计划。
理解构建一个完全SOA的细粒度服务(或者相同风格的完全粗粒度服务)的错误很重要。我们喜欢使用LEGO拼装玩具作为SOA的隐喻来说明这个问题的答案。单从细粒度服务来实现SOA就好比只用最小的LEGO构建某种东西一样。当然,每一小块都有合适的接口使你能把它连接到其它的1x1块上。那就像拥有一箱马形状和车形状的LEGO。当然,它们有突起,而且与你想要的很相似,但它们不是可重用的,而且完全无助于构建其它任何马和车之外的东西。这个故事的道理就在于,你需要对服务合理分类,从细粒度的一直到粗粒度的,这样才能说明你特有的业务问题。
我们的首个服务需要多少基础设施
假如你正在启动一个SOA项目,你或许只看到了有限范围的服务功能。但这并不表示你需要限制基础设施。因为一个组织为他们的第一个项目可能实现一小部分服务并不意味着他们就能提供产品中成百的服务。事实上,拥有业务依赖的粗粒度服务是很重要,至少跟有成百个细粒度的,且每一个都能解决整个业务问题一部分的服务一样重要。所以,公司需要从一开始就考虑在整个生命周期内如何开发、部署、测试以及维护你的服务。
一个例子就是ZapThink对注册、存储、元数据管理和SOA控制的观察。在早期的SOA和Web services,根本没有人对基础设施构件感兴趣。这是因为注册和控制直到有足够多的服务在组织中被构建和部署时才会需要。然而,成功部署了SOA的公司发现实际上在服务部署过程中更早需要这些解决方案,因为尽管只有一部分服务被部署(甚至没有部署),但更早地搭建架构上的最佳实践很重要,这样的话,控制和元数据管理就能尽可能早地实现。对安全和身份管理同样如此。事实上,对于任何SOA的业务问题,SOA的实现者都要意识到他们需要从用面向服务来解决他们问题的那一天起就考虑整体的SOA实现路线图。
从业务需求开始
没有公司采用SOA是不以处理重大业务问题为目标的。毕竟,如果我们所做的仅是为了用服务处理小问题,那么我们就会跌入我们构建。所有的软件项目都必须很自然的从业务需求开始,而对于SOA,主要的业务需求是“元需求”,它的目的是实现一个响应不可预见的变化的架构,一个本质上很灵活的架构。无论如何,架构师首先要意识到对IT的特殊业务需求,例如,一些新的业务功能,新的产品,新的业务关系或者新的预算限制。无论这些业务需要什么,面向服务的架构都必须铭记这样的需求永远没有尽头。
毕竟,SOA项目不是典型的IT项目。典型的IT项目以确定的业务需求开始,架构师或项目团队里的其他人可以和业务干系人(提出需求的人)坐在一起提炼出一套需求用例。但是,SOA项目的用例完全不同。它不会说明特定的“我需要系统这样做”一类的需求,而是描述很多用户想如何利用。于是,面向服务的架构必须允许需求变更而不是假定有一套固定的需求。解决方案必须不只满足业务的短期需求,而必须能够满足未来的需求。
ZapThink的做法
因此,我们说SOA项目应该以最小的业务问题为目标。这并不意味着最小的应用或最小的解决方案。就好比业务过程以组成服务的方式组合,也能包含更小的业务过程。业务问题也是组合的。公司可能会有如何更好服务客户的业务问题,但这个问题实际上由很多更小的问题组成,例如更好的确定他们客户的身份,改进客户支持过程或者减少支持客户的时间和费用。每个这种问题又是由更小的问题组成。
因此,面向服务的架构必须能为组织如何解决迭代式问题维护一个实用的思维模型,而不是维护一个单独的附带的组织架构。通过这种方式,架构师能用不大也不小的合适粒度的服务为业务问题构建SOA解决方案。
尽管我们的产业专家不会同意,但实际上我们正在谈论的东西是很能给人鼓励的。很长时间里我们没有谈论SOA为何物了,而只是谈论如何使用它。所以,现在的谈论正好帮助大家意识到SOA成功的关键并不在于选择合适的中间件,而在于选择合适的服务,并且用合适的基础设施使这些服务对组织产生价值。
相关推荐
-
SAP收购CallidusCloud 与Salesforce竞争
一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
把软件架构演进体现在栈上
曾几何时,企业架构师要为了得到承认和支持而抗争,但这种时候正在过去。大多数企业现在已经意识到实现业务流程中敏捷性和效率需要业务目标、人力资源以及信息技术的结合。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响