写点什么

方面和服务,差别大吗?

  • 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:0011107
用户头像

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

关注

评论

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

Element Plus 和 Ant Design Vue 对比测评,哪个更好?

蒋川

Vue antd vue Element Plus Element UI Ant Design

uni-app技术分享| uni-app转小程序_实时音视频

anyRTC开发者

小程序 音视频 WebRTC uniapp 实时通讯

Element Plus for Vue 3 入门教程

蒋川

Element Element Plus Element UI

云效·Insight(效能洞察)一款面向企业研发管理层的研发效能数字化度量服务

阿里云云效

阿里云 云原生 研发管理 研发效能 效能洞察

解读加密市场13种NFT类型

CECBC

好代码和坏代码

博文视点Broadview

TASKCTL-调度监控常见问题

敏捷调度TASKCTL

kettle 分布式任务调度 ETL任务 ETL系统

Flink 在 B 站的多元化探索与实践

Apache Flink

大数据 flink 编程 流计算 实时计算

主流跨端开发技术方案对比

Speedoooo

跨端开发 跨端 降本增效 小程序容器 轻应用

使用混合云平台企业,怎样才能做好运维?

行云管家

私有云 混合云 多云管理 云管平台

新手指南,带你启航:如何给OpenMLDB社区贡献代码

第四范式开发者社区

机器学习 数据库 开源 开源社区

大数据培训-程序员坚持不断的学习能成大神吗

@零度

大数据开发

分享回顾|木兰技术开放日,建木团队与你一同畅聊「云原生」

Jianmu

ci 开源 云原生 开发运维

Apache ShardingSphere 企业行|走进怪兽充电

SphereEx

开源 ShardingSphere SphereEx apache 社区 怪兽充电

KubeEdge-Sedna边云协同终身学习:迈向次时代AI范式

华为云原生团队

人工智能 开源 AI 边缘计算 边缘技术

虚拟货币网络犯罪愈演愈烈 安全防护更要“多管齐下”

CECBC

有了这款工具,定位线上问题事半功倍|云效工程师指北

阿里云云效

云计算 阿里云 程序员 云原生 开发

为什么要做网站SEO优化?

源字节1号

SEO优化

【课程汇总】OpenHarmony成长计划知识赋能第三期系列课程(附链接)

OpenHarmony开发者

OpenHarmony ETS Openharmony啃论文俱乐部

"三高"Mysql - Mysql备份概览

懒时小窝

MySQL 高可用 MySQL 数据库

使用APICloud开发多端短视频应用

YonBuilder低代码开发平台

前端开发 APP开发 APICloud 多端开发 小程序开发

Ali266首次商用落地,助力优酷码率最高节省40%

阿里云CloudImagine

阿里云 音视频 优酷 编码器 视频云

我国将筹建工业元宇宙服务平台

CECBC

jackson学习之二:jackson-core

程序员欣宸

4月月更

活动预告 | 对话ACE:Oracle停服俄罗斯,国产数据库未来发展

OceanBase 数据库

oceanbase

java培训-不干程序员了还能干什么

@零度

JAVA开发

Zadig 构建缓存如何配置才好用?

Zadig

云原生 CI/CD 软件交付 Zadig

做网工还是运维好?小白求解!

行云管家

云计算 运维 网络 IT运维

浅谈Vue开发小程序

Speedoooo

小程序 Vue 开发框架 小程序容器

vulnhub靶场解题笔记——THE PLANETS:EARTH

L0kt4r

渗透测试

Linux驱动开发-编写FT5X06触摸屏驱动

DS小龙哥

4月月更

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