组织微服务

微服务可能是我的开发伙伴朋友中最受欢迎的热门话题之一,我确实喜欢灵活,敏捷以及拥有更多选择的概念。但作为一名在软件集成领域工作多年的人,我开始看到一些类似于以前ESB的东西。

从一万英尺的高空看问题:十年前,我们不得不提出一种更好的方法来组织系统之间的复杂连接,并停止在相同的业务逻辑上重复工作。那时,面向服务的体系结构(SOA)开始流行起来。通过模块化服务,在其他系统中共享服务,组织通信方式,数据路由。ESB是其中的一个实现,可能并不一定要知道如何实现的。

我非常幸运地参与了许多这样的集成项目,并亲自领导了一些项目。我们与各种中间件供应商合作,当时的解决方案都是关于ESB的。通过将系统之间复杂的互连逻辑移除到ESB中,可以在团队之间(与应用程序/服务领导者)协商数据模型,为Web服务设置WSDL合约,并在调用之间添加BPEL流程(如果需要的话)。而且我自己也看到了相当一部分ESB——在ESB之外,一切似乎都非常有条理。但是打开ESB“盒子”,你会发现其中许多结果是由于更糟的混乱代码(或图表,取决于你的工具),而这个巨大的混乱局面则成为企业变革的瓶颈。

(请注意:这是我开始介绍轻量级ESB概念,以及我如何介绍Camel、Karaf和servicemix的原因,因为它解决了我将集成代码独立打包,将ESB box分解为更小的发行版等问题)当独立部署微服务的想法出现时,这个巨大的单片怪物想到了一个智能管道,它试图做太多的事情,比如数据模型定义,流程流,互连协议和数据格式转换,以及服务等待被事件激活的愚蠢端点,这些很快被开发人员抛诸脑后。各项服务之间的关系仍然十分混乱,整体的特性使得发展周期漫长而繁琐。微服务允许开发人员变得更敏捷,他们需要那些“集成”。这和我曾经试图解决的问题很相似。

我们仍然需要与微服务之外的其他服务(系统/应用程序)进行交互。所以,从过去学习,以下是我们知道不该做的事情:

  • 没有更大的单片捆绑应用程序来加速开发周期。
  • 停止在系统集成代码中执行复杂的业务流程。
  • 数据模型不应该在集成层中定义,它只会导致团队之间的额外协商。
  • 不应该将状态保留在集成层中,以实现最大的可扩展性
  • 在服务之间创建固定的复杂契约。

而且,我们仍然喜欢旧的“整合”方式:

  • 有组织的、可视化的、相互关联的系统视图。
  • 已经为集成应用程序(如聚合,分离和数据规范化)定义的模式。
  • 一个基于事件的方法。一种更灵活和更少耦合的方式来集成系统。

这就是为什么我想出了微服务的分层架构。我希望在现代集成/应用程序开发的新集成架构中实现的主要目标是灵活性。不仅以可扩展的方式,而且还允许开发人员轻松地进行任何架构更改。首先,在新的现代敏捷集成中,集成代码本身应该被分类到不同的小型服务中,这些小型服务在商业世界中是有意义的,并且是分离的,并且是独立部署的微服务单元。然后我们可以开始将真正的CI / CD应用到集成代码。这将避免成为一个庞大的单片ESB。

为了给我的微服务带来一些逻辑意义,并避免重复在单个集成包中承担过多的错误,我为我的微服务定义了四个层,因此每个层都有自己的职责,从而更容易适应变化。

  • 网关层:提供简单的网关路由功能,如版本控制和处理不同平台的设备。

本来,我想把这个层分成两层,但决定不这样做是因为现在网关模式变得如此流行。人们有这样的感觉,即网关应该达到某种能力(这是另一个故事,我以后再谈)。这就是为什么我在图中有两种不同形式的网关 ——一种代表绿色,另一种代表蓝色。

这都是关于关注点的分离。这一层是关于将外部API消耗所需的内容整合在一起的。当不同的应用程序域试图相互集成并路由到正确的服务版本时,就会出现这种情况。显然,主要的问题是:

  • 访问策略规则,端点版本控制(API)。
  • 设置流量限制,应用限制和策略。
  • API的安全性。
  • 路由到正确的版本。
  • 将结果合并,转换并返回给客户端。
  • 普通开发者是这里的主要创造者,他们利用每个微服务团队提供的功能为外部客户提供有意义的服务。
  • 收集、拆分或规范化一个规范化数据格式给外部用户。
  • 根据客户端转换数据输出。
  • 应用程序域之间的路由
  • 复合层:处理多个微服务组合的重要中间层。它们通过处理内容数据和聚合/拆分数据执行更复杂的路由,并通过触发事件或简单地传递事件来将拆分/聚合结果填充到其他微服务。这一层将微服务的复杂性隐藏在客户端之外。

该层可能是负责以前大部分集成逻辑的层,它负责执行

  • 撰写微服务。
    • 通过调用微服务提供的API,根据需要在它们之间转换数据,并根据数据的内容将数据路由到相应的微服务。
  • 触发域内的事件
    • 我坚信,事件库在分离每个服务之间的粘性方面做得最好,并且由于其异步性,允许性能达到最佳状态。这里的事件总线不必是消息代理,而是任何形式的总线。
  • 丰富的内容
    • 这里的内容丰富应该针对格式,尽可能避免任何业务方面的丰富。
  • 应用集成模式
    • 旧的集成问题不会在微服务领域消失。通过应用经过验证的模式,我们可以避免犯错误。
  • 缓存
    • REST架构专门讨论缓存层。复合层尝试应用缓存机制是有意义的,因为它与业务无关,但确实对系统的性能和容错能力产生了重大影响。

复合服务也应该包含在应用程序域中,我将在基础层中讨论这个问题。

  • 基础层:像名称一样,它很可能代表系统的基本组件,处理数据检索或业务逻辑处理。每一个都应该是独立自主的。

借鉴Bounded Context(限界上下文)的思想,在本例中,逻辑组织的一组微服务进入所谓的应用程序域,其中每个域表示共享相同数据模型的业务功能的独立实体,从而消除了在代码中进行过多转换的需要。

  • 反腐败层:该层负责处理传统应用程序的接口或针对微服务的快速灵活原则的任何操作。这一层是为你的系统构建的内置保护墙,通过执行转换工作并在系统的两个非常不同的实现之间进行转换。

下一次再见!

本文的版权归 Aaroncang 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信公众号:Java团长

我的Java EE学习路线图

先来整理一下我曾经学习Java的一个路线图吧,然后按照这个路线图来谈谈我的一些感受。

1132
来自专栏SAP最佳业务实践

想学FM系列(6)-SAP FM模块:主数据(4)-基金

3.1.3 基金 基金是账户分配要素中的一个维度,在具体实施时,可以按照特定目的来的划分来设定,以达到该维度反映特定报表的需求,比如,预算资金来源,预算资金管理...

3677
来自专栏程序你好

微服务Microservices——应用架构的未来

能够构建、演变和扩展大型应用程序对于组织来说是至关重要的,但是所涉及的挑战使其成为一项困难的任务。正因为如此,微服务已经成为构建现代云应用的主导模式,它将单个组...

1112
来自专栏顾宇的研习笔记

Serverless 微服务持续交付案例

“Serverless 风格微服务的持续交付(上):架构案例”中,我们介绍了一个无服务器风格的微服务的架构案例。这个案例中混合了各种风格的微服务

872
来自专栏java思维导图

为什么一定要前后端分离?

由于近期前端抽不出资源,博主最近接手一个前端项目的代码维护工作。拿到手一看,一脸懵逼,和博主当年所学的jsp开发方式、利用ajax来请求数据的单页面开发方式完全...

1334
来自专栏性能与架构

内容平台 Medium 的技术体系

Medium 是全球知名的内容平台,访问量惊人 据半年前的数据统计,用户在 Medium 上阅读时间的总和已经达到 2600年,每月有2500万阅读者,每周有数...

3486
来自专栏子勰随笔

SDK之关于SDK的一些想法

23216
来自专栏架构师小秘圈

为什么一定要前后端分离?

作者:孤独烟,中国平安研发工程师,目前负责云平台架构设计以及需求研发工作。毕业后一直从事Java开发工作,在Web开发、架构设计上有多年的实战经验。在MySQL...

1022
来自专栏微信公众号:Java团长

JavaEE学习路线图

这是学习Java的基础,掌握程度的深浅甚至直接影响后面的整个学习进程。Java的核心主要包括几个部分:

821
来自专栏pangguoming

高性能Web服务端 PHP vs Node.js vs Nginx-Lua 的对比分析

1. ngx_lua nodejs php 比较 我在研究一阵子ngx_lua之后发现lua语法和js真的很像,同时ngx_lua模型也是单线程的异步的事件驱动...

6765

扫码关注云+社区