微服务是否使SOA变得无关紧要?

服务导向架构(简称SOA,service-oriented architecture)已经死亡?你可能会这么想。

但其实不然。的确,随着新技术的出现,SOA本身的价值可能已经大不如前,但是SOA的遗产仍在推动微服务市场发展。

将SOA原则纳入微服务的设计和构建是确保您的产品或服务长期处于有利地位的最佳方式。从此意义上讲,理解SOA,对于在微服务世界中取得成功至关重要。

在本文中,我将解释设计微服务应用程序时应采用哪些SOA原则。

介绍

如今,在移动终端开发环境中,代码为王,构建具有RESTful界面的服务变得前所未有的容易,将其连接到数据存储就可以了。如果你想要更进一步,就把几个公共软件服务(免费或付费)整合在一起,这样你就可以拥有一个满足需求的持续交付流水线。欢迎来到现代Web和完全buzzworthy兼容的应用程序开发过程。

在许多方面,微服务是SOA的直接产物,有点像服务世界的朋克摇滚。没有严格的规则,只是一些基本原则让所有人保持大体想法一致。就像朋克摇滚,微服务最初信奉的是一种按自己的节奏来的行业伦理。此后微服务一直在不断发展,一些架构方式开始让微服务转变为主流。不光是使用微服务的dot com或Web公司——所有的公司都对此感兴趣。

定义

为体现本讨论的目的,以下是我将要使用的定义。

  • 微服务:特定业务功能的实现,使用队列或RESTful(JSON)接口作为单独的可部署工件,可以用任何语言编写,并利用持续交付流水线。
  • SOA:基于组件的架构,其目标是在组织内部跨技术组合促进重用。这些组件需要松耦合,可以是集中管理的服务或库,并要求组织使用单个技术栈来最大限度地实现可重用性。

基于微服务的开发的优点

正如您所知,微服务具有SOA所缺乏的几个很好的特性:

  • 允许规模较小、自给自足的团队拥有支持特定业务功能的产品/服务,这大大提高了他们渴望的业务敏捷性和IT响应能力。
  • 自动构建和测试,虽然可能不及SOA,现在是关键的筹码。
  • 允许团队使用他们想要的工具,主要围绕使用哪种语言和IDE。
  • 以敏捷为基础的开发与直接访问业务。微服务和移动开发团队已经成功地向企业展示了技术人员如何适应并接受不断反馈的业务。以往,瀑布式软件交付方法受制于不必要的开销和交付日期延长的影响,随着业务的变化,开发团队一开始创建的产品,在交付时常常无法满足业务需求。甚至像Rational Unified Process(RUP)这样的迭代开发方法在业务、产品开发和开发人员进行实际工作之间都有抽象层。
  • 对服务的最小粒度的普遍了解。关于“添加客户端业务功能还是客户端管理业务功能”的争论一直存在,这并不完美,但至少两者都可以被实际运营业务的业务方所了解。你可能不愿相信,但技术并不是所有业务(对于世界上大多数企业而言)。回溯到SOA还是行业霸主时期,一些服务只执行一个数据库操作,其他服务则在系统中添加客户端,当IT缺乏一致的标准,就会导致业务的混乱。

SOA如何助力?

看完这些定义后,你可能会想:“微服务听起来好得多”。的确,这正是未来发生演变的原因,只是它抛弃了许多在SOA世界中获得的经验教训。它放弃了SOA尝试实现的所有美好的事物,因为这一领域的IT供应商们为了推出更多的产品,而改变了一切。

企业集成模式(定义企业如何采用新技术或概念)是微服务利用SOA世界所做的工作的关键所在。每个参与整合空间的人都可以从这些模式中获益,然而它们只是概念,微服务是实现这些概念的一种很好的技术方法。

下面,我列出了微服务生态系统中应用SOA原理获得巨大成功的另外两个领域。

API网关(née ESB)

微服务鼓励点对点连接,每个客户端都可以按自己的方式处理日期和其他细微之处。由于大多数公司提供的微服务的数量急剧增加,这种方式不可持续。

因此,在SOA环境中,企业服务总线(ESB)旨在为不同应用程序提供通信方式。SOA原本打算将ESB用于服务组件之间进行传输—而不是整个企业的中心。厂商推动,大公司购买,人们对这种模式的评价十分糟糕。

ESB中成功的产品已经转变为今天的API网关供应商,便于单一组织集中管理它们所呈现的端点,并为那些多年来尚未触及但对业务至关重要的旧式服务 (通常是soa/soap) 提供转换服务。

首要标准

SOA具有WS- *标准。此标准虽然严厉,但在很大程度上保证了互用性。这些标准,特别是像WS-Security和WS-Federation这类更常见的标准,允许企业调用在其合作伙伴系统中使用的服务——虽然它们只是一个清单,任何人都能理解。

微服务已经开始形成一套正式标准,也带来了一票提供相应服务的供应商。OAuth和OpenID认证框架就是两个很好的例子。随着微服务的成熟,在内部构筑一切是有趣、充实、且对自身有益的,但最终令人沮丧的是,随着新特性的引入,它会产生大量的技术债务,代码不断地需要被修改。

标准正迅速整合的另一面是API设计和描述。在SOA世界中,有一种方法。对人而言它既没有美感,又几乎不可读,但是Web服务定义语言(WSDL)是一种通用的标准化的编目网络服务的格式。

截至2017年4月,所有主要的参与者(包括谷歌、IBM、Microsoft、MuleSoft和Salesforce.com)都参与了提供构建RESTful api的工具,这些都是OpenAPI倡议的成员。曾经那个有多个标准(JSON API、WASL、RAML和Swagger)的破碎市场,现在变成了可以用单一方式描述所有内容。

结论

SOA源于一组概念,它们与微服务架构具有相同的核心概念。SOA落后是因为是驱动了太多管理,而“仅仅让它工作”是不够的。

为了使微服务继续生存下去,利用这些服务的团队不仅需要汲取以往的宝贵经验, 并使用敏捷开发的方法重新引入它们,此外还需采取适当的反治措施,防止SOA管理机制的重演。接下来还需把 ITIL安全地置于能够令其茁壮成长的运营团队中。

时间: 2024-08-01 22:48:01

微服务是否使SOA变得无关紧要?的相关文章

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

我所理解的SOA和微服务

SOA和微服务到底是什么关系? 说实话,我确实不明白SOA和微服务到底有什么本质上的区别,两者说到底都是对外提供接口的一种架构设计方式.我倒觉得微服务其实就是随着互联网的发展,复杂的平台.业务的出现,导致SOA架构向更细粒度.更通过化程度发展,就成了所谓的微服务了.以这种说法做为根据,我觉得SOA与微服务的区别在于如下几个方面: 微服务相比于SOA更加精细,微服务更多的以独立的进程的方式存在,互相之间并无影响: 微服务提供的接口方式更加通用化,例如HTTP RESTful方式,各种终端都可以调用

朱晔的互联网架构实践心得S2E4:小议微服务的各种玩法(古典、SOA、传统、K8S、ServiceMesh)

十几年前就有一些公司开始践行服务拆分以及SOA,六年前有了微服务的概念,于是大家开始思考SOA和微服务的关系和区别.最近三年Spring Cloud的大火把微服务的实践推到了高潮,而近两年K8S在容器编排的地位确定之后大家又开始实践起以K8S为核心的云原生思想和微服务的结合如何去落地,2018年又多出一个ServiceMesh服务网格的概念,大家又在思考如何引入落地ServiceMesh,ServiceMesh和K8S以及Spring Cloud的关系如何等等. 确实有点乱了,这一波又一波的热潮

程序员修神之路--为什么有了SOA,我们还用微服务?

菜菜哥,我最近需要做一个项目,老大让我用微服务的方式来做 那挺好呀,微服务现在的确很流行 我以前在别的公司都是以SOA的方式,SOA也是面向服务的方式呀 的确,微服务和SOA有相同之处 面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互.它是一种设计方法,其中包

atititi.soa  微服务 区别 联系 优缺点.doc

atititi.soa  微服务 区别 联系 优缺点.doc 1. 应用微服务的动机,跟传统巨石应用的比较1 2. 面向服务架构(SOA)  esb2 3. 微服务架构(Microservices)2 4. 微服务架构特征(Characteristics)3 4.1. 通过服务实现组件化 vs   通过库(library)3 4.2.  去中心统一化  vs 统一的技术平台3 4.3. 7. Design for failure3 5. 服务划分有两个原则要遵循:单一职责原则    每个工具都小

微服务与SOA的区别

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务. 那么微服务跟SOA有什么区别呢,可以把微服务当做去除了ESB的SOA.ES

微服务以及SOA架构

Docker Docker解决了微服务架构下,服务的粒度细服务数量多所导致的开发环境搭建,部署以及运维成本高的问题,也可以大大降低随着微服务数量增多所导致的节点数量增多的成本. SOA vs 微服务 SOA:将服务分解成多个子系统来实现,粒度比较大,基于企业服务总线,集中式的服务架构,属于单块架构系统,相互依赖,部署复杂,集成方式依赖于SOAP/ESB/WS等重量级协议: 微服务则自底向上开展实施,一个系统被才分成多个粒度精细的服务,集成方式为HTTP/REST/JSON轻量级协议,无集中式总线

SOA与微服务

https://springcloud.cc/spring-cloud-dalston.html SOA架构特确点: 1,依赖与中心化服务发现机制 2,SOA架构采用SOAP协议(HTTP+XML).XML传输协议比较占用宽带.整个XML报文中有非常大的冗余数据,所以在微服务中以json轻量级方式替代xml报文传输 3,服务管理非常混乱,缺少服务管理和治理设施不完善 为服务架构是从SOA架构演变而来的,比SOA架构力度更精细.每个服务独立部署,为服务架构更加体现轻量级,RESTFUL提供API,

微服务、SOA、ESB比较

很多时候会听到微服务.SOA.ESB之间有着联系也有着区别,有时候了解了一下,过段时间有混肴模糊了今天看了一篇文章写的很好,特地记录一下. 原文地址:https://mp.weixin.qq.com/s/fCsVP5pO2vJX3DlMb-RdrA 一.SOA架构解析 SOA 全称是: Service Oriented Architecture,中文释义为 “面向服务的架构”它是一种设计理念,其中包含多个服务, 服务之间通过相互依赖最终提供一系列完整的功能.各个服务通常以独立的形式部署运行,服务