写点什么

方面和服务,差别大吗?

  • 2017-03-23
  • 本文字数:1958 字

    阅读完需:约 6 分钟

三年前,Arnon Rotem-Gal-Oz探讨了在当时看来还比较新颖的话题微服务以及它们与 SOA 的关系,并提出了有关 Nanoservices 的问题。在近日发表的一篇文章中,Arnon 仍然认为,微服务可能不是某些人所认为的灵丹妙药,它可能是一种营销活动:

在我看来,能说明有关微服务的整个宣传是一种顾问式营销活动的其中一个证据是,一个东西要么是微服务,要么是单体,好像没有东西是介于两者之间。另一方面,现如今,似乎所有通过一个端点交付并运行在自己进程中的一切都被称为微服务。

也许他说的有点道理,但显然,其他人看到的是一系列的方法,而不是这种二元划分。例如,Gartner 等就在谈论“迷你服务(Miniservices)”,其定义如下:

迷你服务是真正的 SOA(不像微服务),可以包含许多微服务。它位于微服务之上,是服务的一种“外延方法(external approach)”,而微服务关注的是“内在尺度(internal scale)”,从根本上改善外部功能。

当然,还有其他类似迷你服务的概念,如所谓的 Microlith 。让我们回到 Arnon 的观点,他担心的是那个推断,即如果你开发的不是一个微服务,那么你的服务就会存在某种程度的缺陷或者是一个单体:

[…] 如果每个独立部署的组件都是一个微服务,并且需要具备微服务的所有特性,那么生活真得就太复杂了。这些特性、隔离 & 自治需要付出艰苦的工作来避免 API 耦合、事务耦合、时空耦合、内部结构耦合,等等。不过,我们现在的情况是,什么都叫微服务,即使它不完全符合微服务的原则。

对于他的文章,其中有一位评论者指出,我们过去也曾多次报道过,REST 存在同样的情况:

术语微服务和 REST 一样失去了原来的意义。(几乎)每个通过 http 使用 json 的 API 现在都被称为 REST,同样地,几乎每个服务都被称为微服务。

Arnon 认为,服务的这种二元方法(要么是好的微服务,要么是不怎么好的服务)是反生产力的:

最好是承认,服务就是这些围绕业务能力构建的东西,是通过端点提供并受外部策略限制的自治性 API(或契约),诸如此类。另一方面,我们又需要将服务分解成更小的半独立组件,它们遵循大部分原则,并且具有独立部署、开发周期这样的优点,但仍然可以共享部分依赖,尤其是数据结构和存储。我将它们称为半独立组件“方面(aspects)”。

他继续写道,区分方面和服务可以确保不同服务的不同方面仍然保持服务边界。将服务拆分成方面有助于保持服务的灵活性和简单性,因为随着服务规模和复杂性的提升,它们可能会背离微服务当前的定义。Arnon 举了一些真实世界的例子,那是他参与研发的一个系统,其中有些服务比较小(Arnon 并没有给出“小”的定义,也许是根据代码行数),只有一个方面。不过,他们也有包含多个方面的更复杂的服务:

一个方面负责将事件数据接收到服务,执行转换和“数据梳理(data munching )”(构建新数据和现有数据的关系图),另一个方面负责处理用户修改数据,而第三个方面提供了一个查询 API(通过 graphQL),用于访问那份数据。每个方面都有自己的生命周期,每个方面都是独立部署的,这些方面使用了多种语言(Scala 和 JavaScript),但是,一方面它们会共享数据,另一方面他们会保持和其它服务设定的界限。

按此情形,这些方面听上去很像微服务,即使它们是一起部署并作为一个相关单元来运营,但不管怎么样,微服务不会孤立存在。也许,整体的架构方法和 Martin Fowler 等人以前探讨的 Strangler 模式类似。Arnon 总结道:

控制耦合水平并保持服务界限很重要。理解什么是方面,什么是服务,有助于控制整体架构,确保它不会成为一个错综复杂的相互依赖网络,并通过使用较小的组件提高灵活性,缩短周转时间。

虽然名称不同,但不管“方面”是不是实际上的“微服务”,至少有另外一个人( Udi Dahan )也得出了类似的结论,虽然他对这些软件组件的叫法有点不同:

我一直使用术语自治组件(AC)来描述包含一个服务的软件程序包,它可能会部署为一个单独的端点,也许会和其它 AC 托管在一起。在构建复合 UI 时,这种共同托管模型最有用。

在 Udi 的定义中,自治是指它们不依赖于其它 AC,关于这一点,他在多年之前讨论SOA 时就做过说明。幸好,几年之后,Udi 又写了更多关于 AC 和微服务的内容,他写道:

微服务差不多可以和自治组件同样看待。为什么是“差不多”?因为自治组件(AC)不一定是一个物理部署单元,经常,我们会看到多个 AC 在同一个物理进程中部署。其中一个最常见的情况是,在 Web 前端作为一个复合 UI 构建。在同一个 Web 服务器进程中,我们会看到来自多个服务的组件。

方面 / 自治组件和微服务之间的差别似乎是单体架构和纯粹的微服务架构之间一个有益的过渡,然而,由于微服务没有一个标准的定义,所以这些组件本身也被说成了微服务。也许其他人已经这样做了,但并没有像我们这样明确地说出来。

查看英文原文: Aspects and Services - an Important Distinction?

2017-03-23 19:0011188
用户头像

发布了 1008 篇内容, 共 448.4 次阅读, 收获喜欢 346 次。

关注

评论

发布
暂无评论
发现更多内容

【程序大侠传】服务发布引发mq消息重复消费

Disaster

嘿!通义灵码周边「超大鼠标垫」上线啦,更多玩法等待解锁

阿里巴巴云原生

阿里云 云原生 通义灵码

万界星空科技SMT行业MES系统功能

万界星空科技

SMT mes 万界星空科技 SMT行业

京东云智能编程助手与安全大模型双双获奖!

京东科技开发者

Apache Paimon 在蚂蚁的应用

Apache Flink

大数据 flink 流计算 paimon

AI心理助手:随时待命,伴你左右

心大陆多智能体

智能体 AI大模型 心理健康 数字心理 CBT

「邀您参会」首个中国可观测日即将盛大开幕

观测云

可观测性 AWS

被种草新版 FinClip Cloud,主打一个好用!

Onegun

finclip 小程序容器

茶思屋直播|向下扎根,向上生长,TinyEngine 灵活构建个性化低代码平台

OpenTiny社区

开源 前端 低代码 OpenTiny TinyEngine

Altair HyperWorks 新版本|AI 赋能设计与仿真,驱动全球前沿创新技术

Altair RapidMiner

人工智能 设计 仿真 工程 altair

今天来揭秘提示工程 (Prompt Engineering)

澳鹏Appen

大模型 生成式AI 提示工程 Prompt Prompt Engineering

如何使用腾讯混元API开发一个旅游攻略助手

幂简集成

腾讯 AI API

蚂蚁金服oceanbase的性价比是传统数据库的十倍

极客天地

大模型再加速,保障京东618又便宜又好

京东科技开发者

嘿!通义灵码周边「超大鼠标垫」上线啦,更多玩法等待解锁

阿里云云效

阿里云 云原生 通义灵码

国内低代码平台推荐--万界星空科技低代码平台

万界星空科技

低代码 低代码开发 低代码平台 mes

基于Java+SpringBoot+Vue大创管理系统设计和实现

hunter_coder

哈银消费金融:中期业绩稳健增长,普惠金融助力消费经济新活力

极客天地

京东上万程序员都AI用它!

京东科技开发者

【YashanDB知识库】oracle dblink varchar类型查询报错记录

YashanDB

yashandb 崖山数据库 崖山DB

基于Java+SpringBoot+vue+element课程作业管理系统设计实现

hunter_coder

后端开发

TimechoDB v1.3.3 发布 | 新增多种数据类型,增加数据订阅、配置项设置等功能

Apache IoTDB

方面和服务,差别大吗?_SOA_Mark Little_InfoQ精选文章