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

 98972  2015/03/23 15:00:00

car_5

  微服务是当前比较流行的一种应用开发形式,吸引了不少开发者的关注。前文我们讲了微服务与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对他们也就没有什么好意义, 术语的企业宣传和滥用意味着太多不同的东西。”

本文转自:http://soft.chinabyte.com/88/13305588.shtml