当前位置:企业应用软件行业动态 → 正文

微服务与SOA:改进SOA遗留部分

责任编辑:editor005 |来源:企业网D1Net  2015-03-18 15:39:27 本文摘自:TechTarget中国

微服务是当前比较流行的一种应用开发形式,吸引了不少开发者的关注。前文我们讲了微服务与SOA之与其重用不如抓住敏捷性,本文将继续讲解微服务对SOA的影响。

细粒度的可扩展性

在传统的软件开发周期中,开发一直关注的重点是以整体方在单一的应用服务器上编写应用。这就是Java的工艺所在,应用服务器将下载大量的组件,并把它们像Spring框架一样使用。“问题是随着应用的扩展,不同的应用部署将消耗不同数量的内存或CPU,” Anuff说。

微服务哲学还给企业提供了框架,用于思考如何拆分应用,以一种可扩展成不同部分的应用形式。其中一个较好的方法是把应用拆分成独立的容器,使用内部应用相互通信,而不是使用传统的SOA进行内部应用通信,Anuff说。

有了微服务,电脑的最小单元就是最小的Docker容器,10行的node.js代码。

这使得实现如产品查询这样的服务成为可能,这在特定用户界面的数据库中可查询三个表,以一种容器化的方式。这一简单的服务可以单独扩展,不必拆分应用的其它部分,这可能会产生报告。

改进SOA遗留部分

微服务原则与敏捷软件开发紧密相连,也许是SOA原则的进化,为传统企业服务总线瘦了身。Haddad指出,微服务方法一个限制是,这一服务需要在原子孤岛中实施,这他们就可以独立地操作。“这一概念很有可会扭转企业架构师的大抱负,转变兴趣为在性能和跨领域的观点上,并高效地模型化,”他说。

问题在于,对于工作成立已久的企业中的企业架构师来说,他们需要与大量的现成的(COTS)应用打交道,这些应用通常规模很大,很完整。来自于微服务方法的架构如何能修正在架构和高性能应用上的投资,识别出这一点是一个挑战。

例如,企业COTS应用抑制了微服务方法,因为它捆绑在多个业务功能中。“在时间卡和工资或订单和发票之间,你并没有独立的堆栈。有的只是一个完整的应用程序,” Haddad说。

虽然这种方法有可能为订单和发票提取出两个独立的微服务,但这种方法也限制了微服务范式的实现。问题是订单和发票不能独立扩展,因为他们指向了同一个后端应用。“整个微服务的前提是运转多个后端服务,并分离出不同服务实体之间的解决方案堆栈,这样当他们失败时,也不会影响到对方,另外他们还可以各自扩展,” Haddad说。

最后,微服务并不是什么新东西,只是比SOA好点。据Genender说,“几年来,我们一直构建微服务作为ESB或SOA终端。微服务SOA后端的新术语。由于实现的不好,SOA和ESB对他们也就没有什么好意义, 术语的企业宣传和滥用意味着太多不同的东西。”

关键字:SOA服务方法Genender

本文摘自:TechTarget中国

x 微服务与SOA:改进SOA遗留部分 扫一扫
分享本文到朋友圈
当前位置:企业应用软件行业动态 → 正文

微服务与SOA:改进SOA遗留部分

责任编辑:editor005 |来源:企业网D1Net  2015-03-18 15:39:27 本文摘自:TechTarget中国

微服务是当前比较流行的一种应用开发形式,吸引了不少开发者的关注。前文我们讲了微服务与SOA之与其重用不如抓住敏捷性,本文将继续讲解微服务对SOA的影响。

细粒度的可扩展性

在传统的软件开发周期中,开发一直关注的重点是以整体方在单一的应用服务器上编写应用。这就是Java的工艺所在,应用服务器将下载大量的组件,并把它们像Spring框架一样使用。“问题是随着应用的扩展,不同的应用部署将消耗不同数量的内存或CPU,” Anuff说。

微服务哲学还给企业提供了框架,用于思考如何拆分应用,以一种可扩展成不同部分的应用形式。其中一个较好的方法是把应用拆分成独立的容器,使用内部应用相互通信,而不是使用传统的SOA进行内部应用通信,Anuff说。

有了微服务,电脑的最小单元就是最小的Docker容器,10行的node.js代码。

这使得实现如产品查询这样的服务成为可能,这在特定用户界面的数据库中可查询三个表,以一种容器化的方式。这一简单的服务可以单独扩展,不必拆分应用的其它部分,这可能会产生报告。

改进SOA遗留部分

微服务原则与敏捷软件开发紧密相连,也许是SOA原则的进化,为传统企业服务总线瘦了身。Haddad指出,微服务方法一个限制是,这一服务需要在原子孤岛中实施,这他们就可以独立地操作。“这一概念很有可会扭转企业架构师的大抱负,转变兴趣为在性能和跨领域的观点上,并高效地模型化,”他说。

问题在于,对于工作成立已久的企业中的企业架构师来说,他们需要与大量的现成的(COTS)应用打交道,这些应用通常规模很大,很完整。来自于微服务方法的架构如何能修正在架构和高性能应用上的投资,识别出这一点是一个挑战。

例如,企业COTS应用抑制了微服务方法,因为它捆绑在多个业务功能中。“在时间卡和工资或订单和发票之间,你并没有独立的堆栈。有的只是一个完整的应用程序,” Haddad说。

虽然这种方法有可能为订单和发票提取出两个独立的微服务,但这种方法也限制了微服务范式的实现。问题是订单和发票不能独立扩展,因为他们指向了同一个后端应用。“整个微服务的前提是运转多个后端服务,并分离出不同服务实体之间的解决方案堆栈,这样当他们失败时,也不会影响到对方,另外他们还可以各自扩展,” Haddad说。

最后,微服务并不是什么新东西,只是比SOA好点。据Genender说,“几年来,我们一直构建微服务作为ESB或SOA终端。微服务SOA后端的新术语。由于实现的不好,SOA和ESB对他们也就没有什么好意义, 术语的企业宣传和滥用意味着太多不同的东西。”

关键字:SOA服务方法Genender

本文摘自:TechTarget中国

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^