微服务=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的集合特点。