写点什么

SOA 与微服务的比较和对比

  • 2015-12-27
  • 本文字数:3906 字

    阅读完需:约 13 分钟

在过去一年左右的时间里,我们看到有关微服务的文章与演讲不断涌现,其主题包括微服务的反模式各种原则以及它与SOA 之间的关联。最近,来自C2B2 的顾问主管 Matt Braiser 也加入了微服务与 SOA 的关联这一话题的讨论之中。

最近,人们对于微服务的概念进行了大量的讨论,其中有许多讨论是关于微服务与 SOA 之间的关联。微服务究竟是压垮 SOA 的最后一根稻草,还是能够拯救整个软件工程行业的万能药?人们对此众说纷纭。

Matt 在文中对于微服务概念产生背后的原因以及 SOA 的原则进行了一些基本的概括。这篇文章的基本思想是:这两种架构在原则上确实是相当近似的,但面向 SOA 或微服务进行架构的产品确实存在着各种不同之处,使得他们各自适用于不同的用例。Matt 在对微服务的总体介绍中是这样说的:

经过分离的组件可以各自拥有独立的生命周期,并且按需进行扩展。不仅如此,这种方式也打破了组件之间的技术依赖,这就允许每个服务各自选择最适合的技术进行实现。通过将较大的问题分解为几个较小的问题,让每个问题更易于进行分析,也更利于开发者选择最适合的解决方案。

尽管有这些优点,但微服务也存在着一些不足之处。虽然在这一领域中具有实际工作经验的开发者基本上都已经很好地理解了这些问题,但针对他们的报道与讨论却相对很少:

通过这种方式对大问题进行分解也增加了整个解决方案的复杂度,尤其是在那些使用不同技术或方式创建各种服务的系统中体现得更为明显。这种架构将系统的整合点推移到了服务之间的接口,因此这些服务的接口需要进行良好的定义,在系统中也要对服务级别达成一致,并且还需要定义其他的非功能性需求。

在目前来看,微服务还是一种相对较新的技术,架构师与开发者们通常所使用的一些辅助性工具也还处于发展阶段,以上所提及的这些问题可能迟早会得到解决。但在 Matt 看来,微服务的应用还存在着一个关键问题,那就是数据的管理和所有权:

当某个原本采用一体性应用程序架构的系统被分解为多个小型服务时,在原本的一体性架构中集中保存在某处的数据,在新的微服务应用中经常会改为保存在多个地方,这种改变可能会带来维护数据一致性的挑战。

Matt 指出,与微服务相关的产品通常会专注于服务组件的生命周期,鼓励开发者在实现服务时选择某些推荐的实现方式,例如 Docker,并通过某些推荐的协议进行服务之间的交互,通常来说 RESTful 风格是一种自然的选择。

通常来说,RESTful 服务最适合于为某个数据模型提供 CRUD 操作,而微服务架构中的服务往往能够被轻易地分解为这些 CRUD 类型的服务,因此它与 RESTful 就能够很好地结合在一起。而对于其他类型的服务来说,类 RESTful 风格的服务通常也是一种良好的选择,这种类 RESTful 的风格也会使用 HTTP 作为传输协议,但服务本身并不一定要 100% 地符合 RESTful 的原则。

在 Matt 在文中提到 SOA 之后,他很快深入地谈论了 SOA 与微服务之间的关联:

现如今,谈论 SOA 的各种不足似乎已经成为了一件很普遍的事。但如果你认真地观察,就会发现 SOA 的缺陷中的绝大部分与微服务是相同的,只是有关他们的案例更为具体一些。而两者的优势其实也大体相同,因为从本质上看,这两种技术所做的都是同一件事:将一个较大的问题分解为多个较小的问题。

随后,Matt 进一步指出,那些通常被认为在实施或推广微服务方面具有领袖地位的公司,往往也乐于将他们的架构描述为面向服务的架构。不过,为了实现目标,这些公司通常会倾向于避免使用传统的 SOA 产品。按照 Matt 的观点来看,这些产品就是指专注于基于企业服务总线(ESB)的方案。但在 Matt 看来,之所以这些 SOA 产品名声不佳,是因为使用者在某些项目中将这些产品错误地用于进行应用程序的设计,而不是用于企业级架构的设计。这些产品本身在交付面向服务架构的方案开发时并不存在问题。

就其本身而论,这些产品的特性主要专注于企业级的用例,并提供了多种方法用于追踪业务单元级别的 SLA。大多数 SOA 产品都要求在服务的通信中使用一种或是少量的协议及消息格式,例如 HTTP、FTP、SOAP 和 JMS 等等,并提供连接器的代码库以实现通信功能。

实际上, Kai Wähner 相信 ESB 仍未消亡,它仍然能够在微服务架构中扮演重要的角色。

通过使用 ESB,你能够实现这一产品原本的目标,包括集成、编排、路由、(某些类型的)事件处理、相关性以及业务活动的监控。你也可以通过(微)服务构建你的应用,通过这些服务实现你的需求,解决你在业务上的问题。随后,你将自动地将这些服务独立地部署到某个可伸缩的运行时平台上,为这些服务提供标准化的接口。这些服务是松耦合的,他们能够通过大量一般水平的硬件实现线性的扩展。

显然,不仅仅是 Matt,还有许多人也相信 SOA 与微服务应用了相同的原则,只是在组织中的应用层次不同。SOA 专注于对“大型服务”进行编排操作,但这些大型服务也可以通过对一系列微服务进行组合而实现。当然,正如我们在一篇较早的文章中所说,服务的大小并不是一种定义微服务的好方法:

Jeppe Cramon 一系列博客文章中表达了他对于微服务的观点,以及他在同步的双向通信方案所看到的耦合问题。在他看来,仅仅使用服务的大小定义微服务并不是一种良好的衡量方法,并且也无助于判断某个服务是否具有正确的职责。

实际上,Matt 相信,微服务的出现应当归功于 SOA 原则的成功(另一部分人则发现通过实施微服务,将更易于理解面向服务的思想),他的总结如下:

作为一名开发者,如果你正在开发一个应用程序,那么微服务框架将能够带来更大的敏捷性,并为你提供更好的控制能力。而如果你的任务是在整个企业中对于大量的业务过程进行编排,那么 SOA 产品或许能够为你提供更适合的工具。

在 2014 年,我们曾经在一篇文章中报道过在来自 Cap Gemini 的 Steve Jones 与其他人之间进行的一次讨论,其观点是微服务并不是什么新鲜的东西。在当时,Steve 是这么说的:

在我看来,微服务只是一种为经过良好架构设计的 SOA 解决方案实现的面向服务的交付方案。SOA 提供了上下文的框架,同时也提供了微服务所坚持的大部分规则。不仅如此,SOA 还提供了一种更宽泛的上下文,使微服务能够在复杂的企业中符合这些上下文。许多人在不断地抱怨 SOA 中的各种 WS-* 协议、ESB 的庞大以及各种极端复杂的项目,其实这只是面临的挑战不同而已。

这样看来,Matt 并不是唯一一个认为 SOA 与微服务之间存在着密切联系的人,只是这些讨论往往是由具有深厚 SOA 背景的人所发起的。或许是因为那些微服务的提倡者在过去几年中没有深入地钻研过 SOA,也可能是他们发现 SOA 或是那些旨在帮助用户通过 SOA 方法进行开发的工具中缺少了某些方面的内容?举例来说,在今年早些时候,Bob Rhubart 曾引用了 Eberhard Wolff 的文章,后者是 adesso AG 的技术咨询公告板的主管,同时也是一位自由职业的顾问以及培训师,他是这样谈论 SOA 与微服务的:

SOA 是一种能够改变整个企业的 IT 结构的战略创新,它将企业系统划分为不同的服务,为企业赋予了更大的灵活性……微服务必须能够独立地进行部署,而 SOA 服务往往是按照一体性的部署方式实现的。因此,虽然 SOA 与微服务技术有一定程度的相似性,但他们的本质是完全不同的。

然而,就在同一篇文章中,Oracle ACE 部门的总监 Torsten Winterberg 说到:在他看来,“微服务正是我们在过去十年间一直在谈论的那种 SOA”。这种 SOA 与微服务之间的关联的争论很可能还会持续很长一段时间,或许就像 REST 与 SOA 的争论一样。实际上,TIBCO 亚洲区的 CTO Kevin Pool 就将此称为一种良性的争论

那么微服务的不同之处体现在哪里呢?在微服务架构中,每个操作(或方法)都是独立开发的。(在他的文章前半部分)我们所描述的那个单用户的 SOA 服务将分别实现为多个独立的微服务。这些服务之间一般不会定义正式的接口,或者仅仅是定义一种非常简单直接的接口。也无需定义具有复杂的架构层次和结构的中央式数据模型。好吧,或许我们需要定义某种通用的数据字典,但这一点在每个微服务中并非是强制性的,因为每个微服务都可以按照自身的需要,独立地整合相应的变更。每个微服务都实现了独立部署、停用或是重启等操作。在大多数场景中,各个独立的微服务将在一个统一的平台中执行。

Kevin 在比较和对比 SOA 与微服务的不同之处时选择了一种非常特定于实现的视角,SOA 的实现专注于 ESB、SOAP 和 WSDL。不过,在今年早些时候,Coert van den Thillart 在他的文章中对此给出了或许是最好的一次总结:

微服务架构风格与 SOA 究竟有多大区别,回答完全取决于个人观点。在围绕着服务的概念创建架构这一方面,微服务提供了一种更清晰、定义更良好的方式。两者之间最关键的区别在于,微服务专注于以自治的方式产生价值。

在对 SOA 和微服务的各方面特性与实现途径进行比较与对比后,George Lawton 相信微服务为 SOA 技术引入了敏捷性,并且“修正了 SOA 中的一些遗留问题”:

微服务的原则与敏捷软件开发思想是高度一致的,而它与 SOA 原则的演化的目标也是相同的,则减少传统的企业服务总线开发的高复杂性。

对于他的这篇文章,目前看来至少有一位留言者表示了赞同意见:

我同意(包括其他留言)微服务并不是一种新思想的方法。在我看来,它更像是一种思想的精炼,并且更好地利用了先进的技术以解决问题,例如容器与自动化。

那么,你对此问题的观点是怎样的呢?微服务与 SOA 之间是否存在关联?我们所讨论的方向是否应偏重于如何通过技术(实现)手段以支持这两种架构,而不是专注于他们在架构上的区别?还是如同 Matt 所说,真正的区别在于数据的管理与所有权?这一争论是否完全没有存在的必要?或者是否正如乔治. 桑塔亚那所说的,那些不能铭记过去的人注定要重蹈覆辙呢?

查看英文原文: SOA versus Microservices?

2015-12-27 18:0017348
用户头像

发布了 428 篇内容, 共 177.9 次阅读, 收获喜欢 38 次。

关注

评论

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

【等保知识】等保三级要求多少分?几分能过?

行云管家

网络安全 等保 等级保护

AI加持数据管理服务DAS,让数据库运维更“聪明”,DBA更轻松

华为云数据库小助手

GaussDB dba 华为云DAS 华为云数据库

深入了解RocketMQ之过滤器

邱学喆

bloomfilter TAG过滤 SQL92

48W字?GitHub上下载量破百万的阿里:图解Java、网络、算法笔记

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

The Data Way Vol.3|做到最后只能删库跑路?DBA 能做的还有很多

SphereEx

数据库 开源

FL Studio中钢琴卷帘窗的工具的使用

懒得勤快

架构实战营模块1作业

^_^

架构实战营

ipfs矿机是什么?ipfs矿机挖出的币能交易吗?

区块链 分布式存储 ipfs挖矿 ipfs矿机 filecoin挖矿

百分点感知智能实验室:语音识别技术发展阶段探究

百分点科技技术团队

语音识别 百分点科技 感知智能

细节爆炸!腾讯用13个案例实战讲明白MySQL,没想到这么全

Java~~~

Java MySQL 数据库 架构 面试

6年Java经验,4面阿里定级P7,多亏阿里13万字+脑图+源码面试笔记

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

致远互联2021年中报:扎根协同的广阔天地,撸起袖子加油干

海比研究院

微信开源C/C++ RPC框架PhxRPC

OpenIM

分享 10 个高星的创意项目!

程序员鱼皮

Java Python 数据库 大前端 Go 语言

融云 X-Live 系列直播启动,遇见通信的无限可能

融云 RongCloud

开发者 音视频 通信 融云 即时通信

GitHub阅读量最高的文章竟是图解Java,不愧是Alibaba内部资料

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

项目中全局变量的灵活用法 12/100 发布文章

CodeNongXiaoW

Tapdata Cloud 版本上新!率先支持数据校验、类型映射等6大新功能

tapdata

MySQL nosql schema

MapReduce高阶 分区、排序,Combine

Mike

NFT盲盒玩法详解|盲盒系统开发

Geek_23f0c3

DAPP智能合约交易系统开发 NFT 盲盒

程序员应该专注技术还是转管理?

石云升

职业规划 职场经验 8月日更

webrtc 即时带宽评估器(BitrateEstimator)

webrtc developer

WebRTC

Google官方bazel构建工具的安装

Changing Lin

8月日更

区块链盲盒游戏app软件开发|盲盒游戏软件介绍

量化系统19942438797

区块链 智能合约 盲盒

高安全等级网络是什么意思?有什么特点?

行云管家

网络安全 数据安全 安全事故 安全等级

游戏开发者的通关之旅,华为AGC for Games带来了什么?

叶落便知秋

新时代大视频产业的底座,视频云创变了什么?

阿里云视频云

阿里云 直播技术 视频制作 视频流 视频云

疫情下的人生百态

6979阿强

图计算 GraphScope 新冠

算法毕业总结

Geek_Gu

架构设计-模块一

逝水流

架构

百分点大数据技术团队:BI嵌入式分析实践

百分点科技技术团队

BI 百分点科技 嵌入式分析

SOA与微服务的比较和对比_SOA_Mark Little_InfoQ精选文章