写点什么

方面和服务,差别大吗?

2017 年 3 月 23 日

三年前,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 年 3 月 23 日 19:008251
用户头像

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

关注

评论

发布
暂无评论
  • 19|如何将模型实现为微服务?

    在我看来,行业内做伪微服务的人多,而做真微服务的人少。很多问题不值得去解决,因为没有将问题定义清楚。而一旦明白什么是真微服务,大多问题都变得不言自明。

    2021 年 8 月 14 日

  • 服务端开发篇:回顾与总结

    服务端开发致力于设计合适的业务架构来满足用户需求,而服务治理则致力于让服务端程序健康地为客户提供不间断的服务。

    2019 年 10 月 1 日

  • 移动 SOA 的门柱

    在过去几年内,业界试图多次定义和重定义SOA,整个过程中往往自相矛盾。到底是SOA真的发生了大变化,还是这一切的发生只是由于仍然缺乏对SOA本质的理解?

  • 视图:如何实现服务和数据在微服务各层的协作?

    这一讲解剖基于DDD分层架构的微服务,看看它的内部结构到底是什么样的。

    2019 年 11 月 20 日

  • SOA= 集成?

    SOA的存在已经有些年头了,但就“SOA到底是什么”这个问题而言,在SOA从业者中依旧未形成一个统一意见。最近在Gartner AADI峰会上由Yefim Natis发表的演讲引发了一场关于SOA/集成之间关系/区别的无尽争论。

  • 微服务与 SOA

    过去的一年中,我们开始听到这样一种声音,那就是微服务是一种潜在的新架构风格。最近来自Thoughtworks的Martin Fowler和James Lewis撰文对微服务进行了定义。但是,Steve Jones对这个话题和文章提出了异议,他认为在这方面并没有太多新的东西,这只是一种面向服务交付的方式。

  • 如何基于 DDD 构建微服务?

    本文将讨论微服务与 DDD 涉及到的概念、策划和设计方法,并且尝试将一个单体应用拆分成多个基于 DDD 的微服务。

  • 《Ladder to SOE》作者访谈

    本文检阅了Michael Poulin的新书:《Ladder to SOE》。Michael的这本书展示了如何使用面向服务的原则来使IT和业务对齐,以及业务和市场动态的对齐——缔造面向服务的企业(SOE,Service Oriented Enterprise)。Michael指出,要想成为SOE就必须养成使用面向服务进行思考的新习惯,同时他还给出了有效使用它们的方法。

  • 如何寻找最佳架构,单体架构还是微服务?

    我们应该关注架构驱动力,以便于寻找系统的最佳架构。

  • 克服 SOA 实施过程中的障碍

    在本文中,Jonathan Mack分享了从业务、技术和组织角度来应付SOA挑战的第一手经验。他指出了成功实施SOA的关键要素、主要障碍以及克服这些障碍的方法。

  • SOA 十大原则

    这这篇文章中,来自InfoQ的Stefan Tilkov,也是innoQ的咨询师,提出了讨论SOA的10个原则。这个列表源于Don Box的四大原则(明确边界下的服务、共享契约和架构、策略驱动和自治),又扩展了六个话题,包括可传输的格式、面向文档、松耦合、遵循标准、独立于软件供应商和元数据驱动等。

  • SOA 耦合的 7 个级别

    一般人们都认为:系统要么是松耦合的,要么不是。在一篇最近的帖子中,ZapThink高级分析师Schmelzer炮轰了这个信仰。尽管松耦合的重要性得到认识已经有些时日了,但是围绕这个帖子展开的对话却收集了一些有趣的讨论。

  • 战略设计:如何划分系统的模块?

    战略设计,就是将不同的模型进行分组。

    2020 年 7 月 31 日

  • 面向对象三要素:封装、继承和多态

    2019 年 6 月 24 日

  • 以 ESB 为导向建立 SOA 是有害的

    Bobby Woolf幽默地质疑了以ESB为导向来实现SOA的方式。对这个问题的争论已经持续了相当长的时间,在全套WS-*标准完成之后,我们有必要重新检验这个问题。

  • IT 的工业化?

    WS-CDL从其诞生之日起就一直在努力寻求主流采纳。日前,主要起草者之一Steve Ross-Talbot将WS-CDL背后的一个原理(即服务定义的精确性)比作工业革命早期的千分尺。WS-CDL能否产生如千分尺一般的影响、切实推动服务重用呢?

  • 内聚对 SOA 是否重要?

    Jim Webber重新点燃了关于SOA里是否需要内聚的服务(Cohesive Services)的一些讨论。一篇本无冒犯之意的文章,却引起了激烈的争论。

  • 依赖混乱:你可能还没发现问题,代码就已经无法挽救了

    业务代码中出现具体的实现类,实际上是违反了依赖倒置原则。

    2021 年 1 月 23 日

  • SOA 概述

    JP Morgenthal的一篇新作“忙碌总裁的面向服务的架构参考向导”是一个很好的起点,让你不需要陷入技术的术语和噱头之中就能够快速理解SOA是什么。

发现更多内容

Linux Lab 进阶: Uboot 引导程序

贾献华

Linux bootloader Linux Kenel boot

什么是防火墙?

婚恋交友软件开发

luluhulian

使用APICloud敏捷式开发总结,回顾开发一个完整APP过程。

孙叫兽

App 开发 APICloud

架构师训练营结课作业

Rocky·Chen

Go Modules v2 及后续版本

Rayjun

go

2 期架构师训练营 - 大作业(二)

Vicente

架构师训练营第2期

Python实现钉钉/企业微信自动打卡

sum56

Python python 爬虫 打卡

程序员养家活口接私活必备网站(顺便用技术改变世界)

孙叫兽

程序员 网站 私活

驱动力读书笔记之四

张老蔫

28天写作

产品 0 期 - 第四周作业

vipyinzhiwei

广西党建智慧平台方案,智慧组工信息化建设

135深圳3055源中瑞8032

史上最全的技术手册整理总结,编程小白都从这篇文章迅速成为大牛

孙叫兽

Java 前端 技术手册 开发文档

从躬身入局到共生入境的做产品

boshi

产品经理 产品设计 七日更

2020年末总结,脚踏实地,一步一个脚印——致敬自己一年的心酸历程

孙叫兽

孙叫兽 年度报告

智慧社区服务平台,平安社区搭建

135深圳3055源中瑞8032

区块链珠宝溯源平台,区块链溯源解决方案

135深圳3055源中瑞8032

即使技术再精,面试时一问这个必挂!!

冰河

面试 类加载器 我要进大厂 Java类加载

OpenCV简介及其工程应用-游戏色块检测

行者AI

OpenCV

股票配资系统开发

v16629866266

大作业2-知识总结

arcyao

百度网盘限速解决方案

孙叫兽

解决方案 百度网盘 限速

Webpack | 提升构建速度和体积优化的N种方式

梁龙先森

前端工程化 webpack 2月春节不断更

容器&服务:开篇,压力与资源

程序员架构进阶

容器 服务 七日更 28天写作 2月春节不断更

机器学习笔记之:Matrix Matrix Multiplication

Nydia

Elasticsearch multi-index 搜索

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

MyBatis专栏 - 进阶(引入外部配置文件, 类型参数设置)

小马哥

Java mybatis 七日更 2月春节不断更

探寻内部类的奥秘(上)

后台技术汇

2月春节不断更

学习总结之HTML5剑指前端(建议收藏,图文并茂)

魔王哪吒

学习 程序员 面试 前端 2月春节不断更

重磅发布 | 2021年OpenAtom XuperChain开源技术路径

开放原子开源基金会

区块链 百度 开源 开放原子开源基金会

话题讨论 |互联网软件技术培训,靠谱吗?

不脱发的程序猿

程序员 程序人生 话题讨论 互联网培训 技术培训

方面和服务,差别大吗?-InfoQ