微服务学习笔记 微服务和SOA的异同

最新推荐文章于 2024-04-27 22:06:49 发布
最新推荐文章于 2024-04-27 22:06:49 发布
阅读量102 收藏
点赞数
分类专栏： 微服务学习笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qj4865/article/details/112802373
版权

在这里插入图片描述

智能管道

类似A——ESB——B的架构
应用A要访问服务B，A要先发数据给ESB，然后ESB调用B，B产生的数据返给ESB，然后ESB再返给A。ESB起到了类似于中间层的作用，对A的请求进行过滤和分发，之后再传递给相应的B获取响应；而B返回的响应先给ESB进行组合处理后再返回给A

哑管道

类似A——B的架构
去掉了ESB中间层，微服务体系的管道只提供路由或者负载均衡之类的，不承载业务逻辑，或者是MQ之类的异步消息中间件，管道根本不关心具体传送的数据

参考：参考文章

Mush1
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
SpringCloud（Hoxton SR6）微服务工具集学习笔记
weixin_43711204的博客
11-14 915
版本: Hoxton SR6
微服务学习笔记 分层架构和六边形架构
qj4865的博客
01-19 847
分层架构 传统的mvc三层架构，上层依赖于下层，层与层之间有严格的界限。但是一旦业务庞大起来后，为了业务需要，就会增加新的层。新层往往有边界模糊等问题。此外，因为上层依赖于下层，当数据来源出现变更的时候（mysql专为redis或者es），数据源的切换，也会变得极为麻烦。 六边形架构 六边形架构有别于传统的分层架构，将上层对下层的依赖进行了依赖倒置，高层模块不再依赖低层模块，两者都依赖其抽象。通过适配器，将输入和输出都放到了设计的边缘部分。整个架构不再关心公开的是REST或者是GRPC，也不再关心从何处获
面试官：SOA 和微服务的区别？这回终于搞清楚了！
最新发布
2301_76348242的博客
04-27 951
针对以上面试题，小编已经把面试题+答案整理好了。
《微服务架构设计模式》读书笔记
山河已无恙
07-20 420
看看了书评，挺好的，刷一下，嘻嘻....傍晚时分，你坐在屋檐下，看着天慢慢地黑下去，心里寂寞而凄凉，感到自己的生命被剥夺了。当时我是个年轻人，但我害怕这样生活下去，衰老下去。在我看来，这是比死亡更可怕的事。--------王小波
微服务架构设计模式读书笔记
多看多听多总结
09-12 812
2、单体架构 2.1单体架构好处 主要体现在早期 应用开发简单 易于对应用程序进行大规模的更改 测试相对简单直观 部署简单明了 横向扩展不费吹灰之力 2.2局限性 过度的复杂性会吓退开发者 开发速度缓慢 从代码提交到实际部署的周期很长，而且容易出问题 难以扩展 交付可靠的单体应用是一项挑战 需要长期依赖某个可能已经过时的技术栈 ...
微服务学习笔记
03-28
微服务学习笔记和SpringCloud学习笔记，概念，特点，设计原则，微服务注册与发现，项目整合Spring Boot Actuator，Renew(服务续约)...
SpringCloud微服务架构学习笔记与示例
01-27
Cloud集成），正值当年代表：ServiceMesh（服务网格）=>例如ServiceFabric、lstio、Linkerd、Conduit等现状：在快速发展中，更新迭代比较快基础的云平台为微服务提供了资源能力（计算、存储和网络等），容器作为最小...
微服务学习笔记.md
11-25
微服务学习笔记.md
SpringCloud微服务架构笔记（一）
03-18
本文总结了 Spring Cloud 微服务架构笔记（一），涵盖了微服务基础知识、系统架构演变、单体应用架构、垂直应用架构、分布式 SOA 架构、微服务架构、分布式核心知识等方面的知识点。 微服务基础知识： 1. 微服务...
微服务学习笔记 K8S、ISTIO、微服务、容器不得不说的故事
qj4865的博客
02-01 5604
微服务运行在容器内；容器依靠K8S进行编排、服务发现、负载均衡等；Istio和K8S进行融合，在利用K8S的一些功能的基础上（服务注册），对K8S进行功能的扩展，追加了一些服务治理功能（熔断、限流、动态路由、调用链追踪）。 微服务与容器 为了微服务的快速部署和迭代，如今的微服务架构中，通常将微服务部署在容器内。使用容器的好处 K8S K8S是一个基于容器技术的分布式架构方案。利用K8S，我们可以很好的对容器进行管理。 其架构如下： K8S的最基础单位是Pod，一个Pod下可以支持许多容器，Pod中的容器.
微服务学习笔记 演进式架构 适应度函数概念
qj4865的博客
02-25 1333
适应度函数定义如下： 架构的适应度函数为某些架构特征提供了客观的完整性评估。 适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现（性能、可靠性、安全性、伸缩性、代码规范等），并从全局角度进行平衡，从而实现增量和引导式演进。 适应度函数不单指特定的一种方法（如，单体测试），而是所有能够评估架构性能的方法。适应度函数可以是单体测试、功能性测试、监控工具等。但是不是所有方法都是适应度函数，只有该方法能够评估架构性能的时候，才是适应度函数（用于验证业务的单体测试就不是适应性函数）。 架构师通过适应度
微服务学习笔记 DDD中的Repository
qj4865的博客
05-17 1058
浅薄的了解ddd中的repository层，就是起到一个聚合的作用。他介于domain和dao层之间，相当于一个聚合dao数据的作用。比如说我一个查询需要先查cache，命中不到再去找dao，那我这个逻辑就可以放在repo层；又比如说我一个domain层需要一组数据，这个数据是从多个表拿的，那么我就也可以吧多个dao查出来的数据，在repo层聚合。 ...
微服务学习笔记 服务间消息传递架构（消息代理）
qj4865的博客
01-24 672
服务间消息传递架构通常分为两种，一种是无代理消息架构（服务和服务之间直接传递消息），一种是基于代理的消息架构（服务把消息传递给消息代理，消息代理将消息再传递给接收方） 无代理消息架构的优劣 优势 有着更低的延迟，无须经过代理 避免了因为消息代理而出现的问题 复杂度低，无须维护消息代理 劣势 必须使用服务发现机制来找到接收方 消息无法保存，发送方和接收方必须同时在线 代理消息架构的优劣 优势 发送方不需要知道接收方的位置，也不必关心接收方是否在线，只要将消息交给消息代理即可 能够缓存消息，可以保持
微服务学习笔记 Saga模式
qj4865的博客
01-24 417
单体架构下，大多数采用的事务的ACID原则来保证事务，但是在微服务架构下，由于要保证低耦合等的要求，采用ACD Saga的模式来保证事务。（虽然也可以使用分布式事务，即"两阶段提交"，但是这会导致服务和服务之间的强耦合） 所谓的Saga，就是通过使用异步消息来协调一系列本地事务，从而维护多个服务之间的数据一致性。 每个TXN是一个本地事务，当本地事务提交后，通过异步消息来告知下个服务开始执行其本地事务，以此类推。 使用Saga是不考虑ACID的I（隔离性）的。此外，和使用分布式事务不同，每完成一个本地事务
微服务学习笔记 事件溯源
qj4865的博客
02-18 305
什么是事件溯源 传统的数据对象持久化主要是将数据对象映射到数据库的表中。其中列代表了对象的属性，而行代表了一个对象（例如mysql中的行与列的关系）。传统的数据对象持久化只会保存当前对象状态，而不会保存变更之前的状态。 事件溯源和传统的数据对象持久化不同的是，其主要操作对象是事件。聚合对象通过一系列事件存储在数据库中，每个事件代表聚合对象的状态改变，通过加载事件和重放事件来获取当前或者某个时间内的对象状态。 事件溯源的具体操作 在传统的数据持久化的操作中，直接对数据库的数据对象进行增删改查。 在事件溯源
微服务学习笔记 三大编程范式
qj4865的博客
03-03 216
三大编程范式包括，结构化编程，面向对象编程，函数式编程。 结构化编程范式 结构化编程是指将复杂程序递归拆分成一系列更小的，可证明的单元（函数），之后通过编写测试来试图证明这些函数是错误的。如果无法证伪这些函数，就可以认为这些函数足够正确，进而推导整个程序是正确的。（注意，这里是用科学论证法进行验证，只要函数无法证伪，就能认为其足够正确；而数学论证则要求证明函数的正确性） 由于需要递归的将程序拆分成更小的，可证明的单元，而使用goto语句会导致某个模块无法递归拆分，进而违背了结构化编程范式。所以，在结构化编程
微服务学习笔记 服务发现和注册
qj4865的博客
01-20 112
服务的发现和注册有两种模式 应用层服务发现模式 这种模式下，服务端直接自己向注册中心进行注册（自注册模式），而客户端也直接通过查询注册中心获取服务实例的地址来调用服务（客户端有时可能会缓存服务实例）。 这种模式的好处在于，他可以处理多平台部署问题，即如果在K8S上部署了一些服务，另一些服务在其他的遗留环境下，那么使用这种模式就能发现所有不同环境下的服务。而基于K8S的服务发现仅能发现部署在K8S下的服务。 弊端在于需要为每种语言提供服务发现库，而且开发者需要自己负责和管理服务注册表。 平台层服务发现模式
微服务学习笔记 模式
qj4865的博客
01-19 90
模式是针对特定上下文中发生的问题的可重用解决方案。 常用的模式结构包含： 需求 结果上下文 相关模式 需求：必须解决的问题 需求部分描述了必须解决的问题和围绕这个问题的特定上下文环境。需求之间可能会有冲突，所以必须把需求按照优先级进行排序。 结果上下文：采用模式后可能带来的后果 包含三个部分 好处：这个模式的好处以及他解决了什么需求 弊端：这个模式的弊端和他没有解决那些需求 问题：这个模式锁引入的新问题 相关模式：模式之间存在5种不同类型的关系 前导：是催生这个模式的需求的模式。如微服务架构模式是
"从单体到微服务：SpringCloud微服务架构笔记
单体应用架构、垂直应用架构和微服务架构各有优点和缺点，而SpringCloud作为一套完整的微服务架构解决方案，提供了丰富的功能和工具，使得开发者可以更加方便地构建和管理微服务架构。但是，微服务架构也面临着一些...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值