微服务、SOA、ESB比较

很多时候会听到微服务、SOA、ESB之间有着联系也有着区别,有时候了解了一下,过段时间有混肴模糊了今天看了一篇文章写的很好,特地记录一下。

原文地址:https://mp.weixin.qq.com/s/fCsVP5pO2vJX3DlMb-RdrA

一、SOA架构解析

SOA 全称是: Service Oriented Architecture,中文释义为 “面向服务的架构”它是一种设计理念,其中包含多个服务, 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行,服务之间 通过网络进行调用。架构图如下:

二、 ESB(企业服务总线)

简单来说 ESB 就是一根管道,用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB 做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通;

三、微服务

微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华,只不过微服务架构强调的是“业务需要彻底的组件化及服务化”,原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元,就像 PC 中的 CPU、内存、显卡、硬盘一样,独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构 建,那么这台 PC 只需要维护主板(可以理解为ESB)和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务,例如PC 需要调用 CPU 做计算处理,只需知道 CPU 这个组件的地址就可以了。

微服务的特征

1. 通过服务实现组件化

2. 按业务能力来划分服务和开发团队

3. 去中心化

4. 基础设施自动化(devops、自动化部署)

微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时以 SOA 的思想进入到单个业务系统内部实 现真正的组件化。

原文地址:https://www.cnblogs.com/lukelook/p/11216522.html

时间: 2024-10-29 11:36:00

微服务、SOA、ESB比较的相关文章

微服务以及SOA架构

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

谈谈我对微服务、SpringCloud、k8s、Istio的一些杂想

一.微服务与SOA "微服务"是一个名词,没有这个名词之前也有"微服务",一个朗朗上口的名词能让大家产生一个认知共识,这对推动一个事务的发展挺重要的,不然你叫微服务他叫小服务的大家很难集中到一个点上. 业界对微服务与SOA的区别争论比较多大多都是在微观上对比他们的区别什么微服务粒度更细啊.微服务没有ESB啊.微服务通讯相比SOA采用更轻量级的协议啊等等,但是从微观谈区别本身就有悖论, 这些区别只是微服务的一种"最佳实践"而已.我个人理解微服务与S

大项目微服务架构设计

大项目微服务架构设计 李万鸿 根据目前产品存在的问题,针对快速开发.海量用户.大量数据.低延迟等互联网应用的实际需要,通过对业务架构.系统架构.基础架构.技术架构进行分析,采用先进实用的微服务SOA架构重构智慧校园.数字化校园等产品,彻底解决系统解耦.性能低下等问题,而且支持云计算部署,可以满足高并发.高可用.高稳定和高安全等性能要求,提供强大的saas和互联网访问服务.由于采用微服务架构,各个服务模块化编写,具有高内聚低耦合的优势,便于灵活更新升级,而不会影响其他业务.一套代码,同时支持移动应

微服务踩坑之边界

近年来微服务/SOA很是流行,我们团队赶时髦,也玩了玩.虽然用的时间还不长,但也已经踩过不少坑.今天想记录下自己对边界问题的一些思考. 很多人在谈起微服务时,总是会很自豪的说,微服务为我们提供了高内聚低耦合的明显好处,因为微服务强化了模块化的概念.但是, 如何模块化,如何明确的定义模块的边界,却很少有人提及,而这正是微服务架构的难点,也恰恰是开发人员技术能力的体现.如何正确的定义模块的边界,似乎还没人总结出一套理论原则. 当我们将一个单体服务进行模块化拆分时,我们总是能够很轻易地找到模块边界.那

【转】微服务与SOA之间差了一个ESB

本文来自 dockone 编辑:yan 微服务只是最近提出的概念,实际上很多巨头公司(FB.Twitter.AWS等)已经在亲身实践.微服务并不是银弹,但是我们可以参考它的思想来解决自己遇到的问题.对于已经找准市场,业务即将或者马上就要急剧发展的创业公司,适合使用基于微服务的软件架构. 今天阅读了两篇关于微服务的文章,总结一些笔记,简单翻译了一篇文章.说明:并没有严格按照原文一字语句翻译,有部分自己的理解,还有部分是意译. 微服务(micro services)这个概念不是新概念,很多公司已经在

孢子框架-接口访问层、ESB、微服务API GateWay对比

如果从百度去搜索“接口访问层”你会发现主要是.NET里面的技术,叫做IDAL,其实是数据访问层接口.它的主要作用是兼容多种数据库.比如你定义一个标准接口,然后实现改接口的SqlServer访问和Oracle访问,那么利用IDAL就可以自由切换数据库.看.NET DEMO PetShop4,总共有22个项目.大体思想是3层,从Model.DAL.BLL,然后他在各层上又采用了工厂模式,把逻辑与实现想分离,比如以前BLL直接调用DAL就好了,但现在BLL却调用了IDAL,IDAL就是一个接口层,里面

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和微服务架构的区别?

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

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

服务导向架构(简称SOA,service-oriented architecture)已经死亡?你可能会这么想. 但其实不然.的确,随着新技术的出现,SOA本身的价值可能已经大不如前,但是SOA的遗产仍在推动微服务市场发展. 将SOA原则纳入微服务的设计和构建是确保您的产品或服务长期处于有利地位的最佳方式.从此意义上讲,理解SOA,对于在微服务世界中取得成功至关重要. 在本文中,我将解释设计微服务应用程序时应采用哪些SOA原则. 介绍 如今,在移动终端开发环境中,代码为王,构建具有RESTful