微服务可能是我的开发伙伴朋友中最受欢迎的热门话题之一,我确实喜欢灵活,敏捷以及拥有更多选择的概念。但作为一名在软件集成领域工作多年的人,我开始看到一些类似于以前ESB的东西。
从一万英尺的高空看问题:十年前,我们不得不提出一种更好的方法来组织系统之间的复杂连接,并停止在相同的业务逻辑上重复工作。那时,面向服务的体系结构(SOA)开始流行起来。通过模块化服务,在其他系统中共享服务,组织通信方式,数据路由。ESB是其中的一个实现,可能并不一定要知道如何实现的。
我非常幸运地参与了许多这样的集成项目,并亲自领导了一些项目。我们与各种中间件供应商合作,当时的解决方案都是关于ESB的。通过将系统之间复杂的互连逻辑移除到ESB中,可以在团队之间(与应用程序/服务领导者)协商数据模型,为Web服务设置WSDL合约,并在调用之间添加BPEL流程(如果需要的话)。而且我自己也看到了相当一部分ESB——在ESB之外,一切似乎都非常有条理。但是打开ESB“盒子”,你会发现其中许多结果是由于更糟的混乱代码(或图表,取决于你的工具),而这个巨大的混乱局面则成为企业变革的瓶颈。
(请注意:这是我开始介绍轻量级ESB概念,以及我如何介绍Camel、Karaf和servicemix的原因,因为它解决了我将集成代码独立打包,将ESB box分解为更小的发行版等问题)当独立部署微服务的想法出现时,这个巨大的单片怪物想到了一个智能管道,它试图做太多的事情,比如数据模型定义,流程流,互连协议和数据格式转换,以及服务等待被事件激活的愚蠢端点,这些很快被开发人员抛诸脑后。各项服务之间的关系仍然十分混乱,整体的特性使得发展周期漫长而繁琐。微服务允许开发人员变得更敏捷,他们需要那些“集成”。这和我曾经试图解决的问题很相似。
我们仍然需要与微服务之外的其他服务(系统/应用程序)进行交互。所以,从过去学习,以下是我们知道不该做的事情:
而且,我们仍然喜欢旧的“整合”方式:
这就是为什么我想出了微服务的分层架构。我希望在现代集成/应用程序开发的新集成架构中实现的主要目标是灵活性。不仅以可扩展的方式,而且还允许开发人员轻松地进行任何架构更改。首先,在新的现代敏捷集成中,集成代码本身应该被分类到不同的小型服务中,这些小型服务在商业世界中是有意义的,并且是分离的,并且是独立部署的微服务单元。然后我们可以开始将真正的CI / CD应用到集成代码。这将避免成为一个庞大的单片ESB。
为了给我的微服务带来一些逻辑意义,并避免重复在单个集成包中承担过多的错误,我为我的微服务定义了四个层,因此每个层都有自己的职责,从而更容易适应变化。
本来,我想把这个层分成两层,但决定不这样做是因为现在网关模式变得如此流行。人们有这样的感觉,即网关应该达到某种能力(这是另一个故事,我以后再谈)。这就是为什么我在图中有两种不同形式的网关 ——一种代表绿色,另一种代表蓝色。
这都是关于关注点的分离。这一层是关于将外部API消耗所需的内容整合在一起的。当不同的应用程序域试图相互集成并路由到正确的服务版本时,就会出现这种情况。显然,主要的问题是:
该层可能是负责以前大部分集成逻辑的层,它负责执行
复合服务也应该包含在应用程序域中,我将在基础层中讨论这个问题。
借鉴Bounded Context(限界上下文)的思想,在本例中,逻辑组织的一组微服务进入所谓的应用程序域,其中每个域表示共享相同数据模型的业务功能的独立实体,从而消除了在代码中进行过多转换的需要。
下一次再见!