微服务=ESB的死亡?

微服务概念不断兴起,是不是意味着SOA重要概念企业服务总线ESB的死亡呢?它们是否是两个矛盾的选择呢?
Do Good Microservices Architectures Spell the Deat一文进行了分析,内容比较抽象罗嗦,以我个人理解的大意表达如下:

首先,看看EAI vs. SOA vs. ESB vs. Microservices几个比较,许多年前,软件厂商提供一种企业应用集成EAI中间件,称为EAI broker或EAI backbone,这个中间件类似后端集中式Hub,随着SOA开始兴起,工具选择变为ESB,许多厂商重新打包它们的EAI工具变为ESB,没有什么改变,后来,一些新的ESB产品出来,它们没有集中Hub,而是分布式代理,这样ESB能够为不同的中间件服务,许多人不喜欢ESB这个词语因为他们仅仅知道集中式HUB模型,对分布式模型不了解,今天,一些人开始谈论NoESB,类似NoSQL,未来可能NoESB像NoSQL流行。

这样,厂商们就尽量避免谈论ESB词语,它们不能再卖集中式集成中间件了,因为现在分布式如此灵活,今天你可以购买一个服务递交平台,未来可能是微服务平台或类似平台,在某些情况下,代码可能还类似于20年前的EAI broker,所有这些产品都有一个共性,就是解决企业集成问题,通过企业集成模式。

回顾集成市场过去,没有看到任何性感新潮的名词,与其将注意力放在架构特点上,不如问问你自己你需要解决的业务问题是什么,然后再评估合适的架构和产品。

ESB会死吗?
如今ESB不是时髦名词,今天我们想到的是分布式 灵活可扩展的架构,你可以在云中以更加敏捷有效方式构建 部署和监控应用。使用ESB是为了集成 指挥orchestration和路由事件处理 聚合和业务活动监控,你也能通过微服务构建应用,单独彼此独立部署这些服务,基于扩展性平台对外一致的标准接口。

而ESB正好适合这样的情况,ESB应该是适合面向(微)服务方式,而不是面向集中式ESB方式,可以称为ESB 或者集成平台,或者服务递交套件 或微服务平台,都可以。

ESB这些套件中间件扮演一个服务网关角色,负责安全 策略和暴露微服务作为开发API给消费者,服务网关管理你的集成服务,你的应用服务 外部云服务。

关键问题是,我们真的需要这样一个总线概念吗?如果你想聚合来自不同的微服务,总线是有用的,将这些事件放入内存中,使得它们能够实时可监控 分析和预测。

也就是说ESB和微服务不是敌人,而是工作在一起的朋友。

好的微服务特征
需要从下面六个关键要求评估微服务:

1.服务合约Services Contract
2.从应用中暴露微服务
3.服务的发现
4.跨服务协调
5.管理复杂部署和它们的可扩展性。
6.跨服务的透明度

该文然后balabala逐条就这六个关键特征来说明微服务和ESB的集合特点。

大概看完这篇文章,并不是很同意文章的观点,在过去SOA中服务是一种粗粒度的服务,也就是与微服务相反,粗粒度的服务有两个好处:易于重用,减轻ESB的负载;而微服务催生,比如对事件总线的性能和可靠性要求提高,因为每个微服务是很小的组件,甚至是一个类,微服务之间的通讯几近类似于两个单个对象之间交互调用,性能称为至关重要,而过去的ESB产品主要面向工作流程的编排与灵活性上,性能是第二位的。

另外,微服务对团队组织也产生不同于ESB时代的影响,ESB时代,很多集成业务逻辑,也就是跨服务调用的逻辑放在ESB中,形成了专门的ESB产品开发团队,这是以ESB团队为核心的开发模式,众星捧月,树形结构;而微服务代理扁平的矩阵式管理模型,没有核心团队,不是面向ESB的开发模式,而是一个微服务一个团队。

第三,微服务概念基于云平台和Docke之类虚拟容器,允许不同语言开发方便轻量集成,而ESB的集成不同平台服务的规范复杂,非常重量,这两者存在矛盾性。

所以,从上面三个方面的矛盾性可以看出,微服务不能简单和ESB和平相处。微服务在新技术背景下集成的方式肯定与以前不同,主要区别是云平台的区别,现在我们开发的微服务需要无缝直接部署在操作系统上,也可以无缝不需要更改任何微服务配置,直接运行在云平台上,而使用过去的ESB是做不到这点的,因为以前没有云计算。

如今我们必须从这种DevOps全新角度去看过去,而不是像文章从过去SOA角度看今天。角度不同,深度不同。