写点什么

方面和服务,差别大吗?

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

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

关注

评论

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

TiDB 性能分析工具——PProf

TiDB 社区干货传送门

TiDB 底层架构

【TiDB 4.0 新 Feature 原理及实践】 Dashboard 触手体验

TiDB 社区干货传送门

TiDB 数据库开发规范

TiDB 社区干货传送门

TiCDC 应用场景解析

TiDB 社区干货传送门

实践案例

移动云基于 TiDB 实现 serverless 数据库服务

TiDB 社区干货传送门

TIDB 3.0.5 性能压测

TiDB 社区干货传送门

数据库架构选型

以TiDB热点问题来谈Region的调度流程

TiDB 社区干货传送门

实践案例

PD 分配 TS 的 QPS 上限揭密

TiDB 社区干货传送门

如果你的 kubelet 运行在容器中,使用 local static provisioner 要注意一个问题

TiDB 社区干货传送门

AskTUG 论坛迁移实战:Discourse 从 PostgreSQL 到 MySQL 到 TiDB

TiDB 社区干货传送门

招募体验官!构建实时数仓 - 当 TiDB 遇见 Pravega

TiDB 社区干货传送门

【热门问题】关于近期签名过期的处理合集

TiDB 社区干货传送门

常见问题排查之 -- DM 主键冲突的原因及排查思路

TiDB 社区干货传送门

NewSQL 在微众银行核心批量场景的应用

TiDB 社区干货传送门

实践案例

TiDB 5.0 异步事务特性体验——基于X86和ARM混合部署架构

TiDB 社区干货传送门

【技术专题】如何做数据库选型?

TiDB 社区干货传送门

实践案例

从抓包发现并解决 Navicat 编辑 TiDB 视图报错的问题

TiDB 社区干货传送门

实践案例 TiDB 底层架构

速度收藏!TiDB 读、写性能慢问题排查思路汇总

TiDB 社区干货传送门

管理与运维

几分钟读懂 TiDB HTAP

TiDB 社区干货传送门

tidb开发规范

TiDB 社区干货传送门

Tiflash 尝鲜小案例

TiDB 社区干货传送门

管理与运维

【TiDB 最佳实践系列】HAProxy

TiDB 社区干货传送门

实践案例

【TiDB DevCon 2020】金融专题论坛演讲视频汇总

TiDB 社区干货传送门

【TiDB 最佳实践系列】乐观锁事务

TiDB 社区干货传送门

实践案例

从内容角度看看TUG小伙伴都在关注些啥

TiDB 社区干货传送门

版本测评

【精选实践】TiDB 在马上消费金融核心账务系统归档及跑批业务下的实践

TiDB 社区干货传送门

实践案例

基于阿里云ECS部署的TiDB 2.1.14升级到4.0.0-rc实践

TiDB 社区干货传送门

管理与运维 安装 & 部署

TiDB 多Socket 服务器性能扩展问题分析-续

TiDB 社区干货传送门

性能调优 性能测评

tiup目录冲突检测不健全导致的节点被destroy问题以及解决

TiDB 社区干货传送门

TiDB at ZaloPay Infrastructure & Lesson Learned

TiDB 社区干货传送门

日本大型移动支付软件 PayPay 的 TiDB 迁移实践

TiDB 社区干货传送门

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