- 综合排序
- 最热优先
- 最新优先
- 来自专栏centosDai
使用队列解耦的架构方案
为什么要使用队列解耦？ 让我们来看看不使用队列的情况下如何解耦的： 原始需求 假设有一个商城系统，业务上划分为用户、订单、财务、消息、仓储几个模块（模块的划分实际上也是解耦设计的重要部分，但非这篇文章的关注点），这几个模块是分布式部署的 这种做法完全忽视了使用队列进行解耦的好处。 应该把发送到队列的数据看作一个消息、或者一个事件，而不是某个具体业务方需要的某几个数据，这个消息可能是和业务方需求的数据完全吻合，也可能少或者多，对于业务方需要的缺少的数据应该可以根据消息中某个标识去查询，这样才算比较合适的解耦
3800编辑于 2021-12-08 - 来自专栏花落的技术专栏
Flutter 解耦
uncoupling使用了标记的方式，直接操作文件代码以实现代码物理方式的灵活插入与抽取，对工程没有任何侵入性，简单易用。
77930编辑于 2021-12-15 - 来自专栏架构师之路
MQ，互联网架构解耦神器
一个架构常识：当调用方需要关心执行结果，通常使用RPC调用。 会影响上游通用基础服务，此时通用服务的owner又在心里骂娘了“我ca，稳定性的KPI，全被兄弟部门毁了” 一旦业务侧接口升级，上游基础服务需要配合升级，此时通用服务的owner可能又会抱怨“为何被动升级的人总是我” 架构不合理 MQ能够做到上下游物理上和逻辑上都解耦： 物理上解耦，增加MQ之后，上游互不知道彼此的存在，不会建立物理连接了，大家都只与MQ建立物理连接 逻辑上解耦，事件发布方甚至不用知道哪些下游订阅了这个消息，新增消息的订阅方只需要连接 MQ就行了，不需要上游关注 MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器。 关注下游执行执行结果，用RPC； 不关注下游执行结果，用MQ，不用RPC； 这只是一个很小的优化点，但对于通知解耦却是非常有效。 希望每天收获一点点，架构就能美好一点点。
1.7K90发布于 2018-03-02 - 来自专栏存储公众号：王知鱼
解耦SDS架构：加速云存储的未来
然而，传统的云存储架构在处理大规模数据访问时，面临着性能瓶颈和延迟问题。本文探讨了一种通过解耦软件定义存储（SDS）架构来加速云存储性能的创新方法。 阅读收获 理解云存储架构的瓶颈与优化方法：通过解耦SDS架构，读者可以了解如何在不牺牲存储可靠性的前提下提升性能。 SDS架构中的变更解耦了数据路径，并与控制平面同步。硬件卸载的内存占用是一个问题，导致采用一种方法，将映射表缓存存储在卸载内存中。 延伸思考 这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~ 在解耦SDS架构的过程中，如何平衡性能提升与系统复杂性之间的关系？ 在更大规模的云存储系统中，如何确保解耦架构的稳定性和可扩展性？ 原文标题：Storage Acceleration via Decoupled SDS Architecture
82210编辑于 2025-03-10 - 来自专栏四楼没电梯
MVVM 架构模式：解耦、可测试与高效
它通过解耦视图和业务逻辑，提升了代码的可维护性和扩展性。今天我们来深入探讨MVVM 的原理、优点，以及如何通过它来构建一个现代应用的架构。 什么是 MVVM？ 架构图 View <--> ViewModel <--> Model 为什么要使用 MVVM？ 解耦：通过 MVVM，View 和 Model 之间实现了完全解耦，ViewModel 作为中间层管理两者的交互。 结论 MVVM 架构通过数据绑定简化了视图和模型的交互，使代码更加清晰和可维护。无论是开发 SPA 应用、移动端还是桌面端，MVVM 都为我们提供了一种高效的架构方式。 MVVM 的优势在于解耦、可测试性和扩展性，如果你正在开发一个复杂的前端或移动应用，不妨试试这种架构模式。
3.1K10编辑于 2024-10-12 - 来自专栏進无尽的文章
架构 - iOS架构设计之模块间的解耦尝试
前言 工程大了以后，就需要分拆，不管是组件化还是插件化，还是什么，解耦是第一步，而且是各个维度的解耦。 getSomeData { return self.data; } 那么我们可以实现一个 getSomeDataFromB 的接口，让 A 只依赖这个接口，而 B 来实现这个接口，这样就实现了 A 与 B 的解耦 协议与实现做成了一个机制与策略分离 所谓机制即是抽象出来的规则,比如: f(x)=x^2 x属于R 所谓策略即是在具体场景中的应用，比如当x=2的时候: f(2)=4 x=2 【3】中间件的路由通信解耦 ，或者任何操作都是通过一个URL来唤起的话，这样是不是就把各个复杂的业务之间解耦了呢，通信都使用URL. 参考文章： BeeHive框架全面解析——iOS开发主流方案比较 iOS架构设计解耦的尝试之模块间通信
1.9K20发布于 2018-12-10 - 来自专栏架构师之路
配置中心，互联网架构解耦利器
《小小的ip，大大的耦合》提到，因为"变更ip，导致上游重启一大片"的不合理架构，可以使用“内网域名代替内网ip”的方式解耦。 配置中心是一个典型的逻辑上解耦、物理上不解耦的一个架构优化工具（如果大家还有印象《MQ，互联网架构解耦神器》提到，MQ是一个逻辑上解耦，物理上也解耦的一个架构优化工具）。 物理依赖，指物理上要建立连接，产生依赖： MQ解耦，上游和下游不会建立物理连接 配置中心解耦，上游和下游依然会建立物理连接 但很多时候，当关注下游处理结果的时候，上下游不能使用MQ通讯，而必须使用RPC （详见《MQ，互联网架构解耦神器》）。 B、配置中心对于“配置私藏”的上下游解耦非常有效。 C、MQ和ConfCenter是常见的互联网架构解耦利器： 前者，逻辑解耦，物理解耦 后者，逻辑解耦，物理不解耦
1.1K50发布于 2018-03-02 - 来自专栏look Java
Event事件传递 解耦
Event事件传递 解耦 spring中创建bean后，我们在完成对一个bean的操作后，我们希望把运行后的bean结果同步传递给另一个bean。
28510编辑于 2023-12-07 - 来自专栏Rice嵌入式
框架解耦神器 -- REventBus
对通信双方做到完全解耦。 使用RThread pool灵活切换工作线程，一定程度提供了事件处理效率 支持同步事件发布，和异步事件发布。 资源占用极小。 缺点： 当业务多的时候，需要定义很多事件类型。
44520编辑于 2023-09-02 - 来自专栏linux驱动个人学习
Linux之设备树解耦架构解读-V1.0
Linux使用设备树的主要原因如下 A:平台识别 B:实时配置 C:设备植入 二、设备树解耦目标 目标一 vendor相关修改，完全独立出来，禁止在soc原生的dtsi中修改，只允许以dtbo的方式存在 ； 目标二 同基线项目dtbo要共二进制 三、设备树解耦框架设计 ? 四、设备树代码架构 ? 五、设备树overlay规则 该节内容为overlay机制原生规则，罗列出来帮助驱动工程师解决各种异常问题。
1.8K20发布于 2021-08-18 微服务2.0-开发逻辑架构和运行物理架构解耦
对于微服务优点大家都知道，在传统的单体应用转成微服务以后，对于每一个微服务它本身的相应的性能扩展性都得到了大幅的提升，包括可以更好的解耦，更好应对软件需求的变更。 逻辑架构和物理架构解耦 所以说在这种情况下面，他就提出了一个关键的问题点，就是原来我们的微服务架构更加强调我在开发态的时候，我的逻辑架构和我在运行态的物理架构往往是一对一映射的，我在开发态的逻辑架构怎么分解的往往部署的时候物理架构也是相应的做了对应的分解 ，所以说他提出一个关键问题，这两者之间能不能更好的去解耦？ 微服务2.0的基础概念 在微服务2.0里面，它更加强调的就是叫逻辑边界和物理边界之间的一个解耦。 微服务逻辑边界和物理边界解耦 因此微服务2.0更加强调的是什么？ 即微服务应用的开发态逻辑边界和运行态物理边界能否更好的解耦？在应用的运行态根据并发和负荷情况自动进行拆分部署。
19001编辑于 2025-06-24- 来自专栏Rice嵌入式
框架解耦神器 -- REventBus
对通信双方做到完全解耦。 使用RThread pool灵活切换工作线程，一定程度提供了事件处理效率 支持同步事件发布，和异步事件发布。 资源占用极小。 缺点： 当业务多的时候，需要定义很多事件类型。
48750编辑于 2023-06-01 数据库解耦，代码复用？还是数据库复用，代码解耦？
那时候是大型机、小型机和IOE架构等。微服务其实不一定要分库但是的确如果在都在一个数据库那还做什么微服务？ 以上称之为解耦数据库一拆分就是解耦了。但是逻辑上来说原来在一起是有道理的，现在分开就是解除耦合了吗？有没有可能他本身就是要耦合的？问题来了很多长流程的业务，被切割成多个数据库。 但是也有为了架构而架构，把这种拆成异步处理。结果比起原来，现在慢了不少，还因为消息队列可能堵塞而迟迟数据送不过去。还有可能出现数据不一致情况。 如果说遇到问题，要解耦，你会发现根本解不开。最底层的是包罗万象的。一动影响全局。这就是典型的双标。在企业管理中，去申请权限一般来说，给一个最小的，然后逐步放开。 但是这个公共组件做的大而全，无法解耦。上来先运算100个。最后99%都是无用功。小结个人观点：代码应该解耦，数据库不应该。因为有时候用着用着数据就要发生联系了。
25410编辑于 2025-07-24- 来自专栏蓝天
巧用NULL模式解耦依赖
由于需求的变化，应用B需要库libM.a的能力，以便和服务M交互。为了复用和简化，通过类A间接提供，应用B不用修改代码，只需要重新编译即可获得新的能力，其它用到类A的应用也是如此。
64130发布于 2018-09-30 - 来自专栏魔术师卡颂
使用IOC解耦React组件
IOC（控制反转）是一种编程思想，可以解耦组件，提高组件复用性。 改造后的依赖关系： 士兵 --> 武器库 <-- 武器 改造后应用（士兵）与服务提供方（武器）解耦，他们通过IOC容器（武器库）联系。 所以说，合理使用React可以充分利用IOC的思想解耦代码逻辑。 接下来我们看看专业的DI库如何与React结合： InversifyJS InversifyJS[1]是一个强大、轻量的DI库。 ? 业务逻辑的更多依赖都可以通过注入IOC容器来实现解耦。
1.2K10发布于 2021-03-15 - 来自专栏韩曙亮的移动开发专栏
【Jetpack】Lifecycle 架构组件 ( 系统组件与普通组件解耦 | Lifecycle 解耦系统组件与普通组件 | 解耦服务组件与普通组件 | 监听应用程序生命周期 )
文章目录 一、系统组件与普通组件解耦 二、Lifecycle 解耦 Activity 系统组件与 UI 组件 1、传统实现方式 ① Activity 系统组件 ② 布局文件 ③ 执行效果 2、LifeCycle 实现方式 ① 自定义 UI 组件 ② Activity 系统组件 ③ 布局组件 ④ 执行效果 三、LifecycleService 解耦 Service 与 UI 组件 1、构建脚本导入依赖 2、 说明 2、代码实现 ① LifecycleObserver 组件 ② 自定义 Application ③ AndroidManifest.xml 清单文件配置 ④ 执行效果 一、系统组件与普通组件解耦 , 降低代码复杂度 , 提高程序的可读性 , 可维护性 ; Lifecycle 架构组件 就是实现上述 解耦功能 ; Lifecycle 的适用场景 : 建立 可感知 系统组件 生命周期 的 自定义 , 讲到 将 系统组件 与 普通组件 进行 解耦 , Activity 组件就是 系统组件 , 在 Activity 中使用到的 UI 组件 , 就是实际实现业务逻辑的 普通组件 ; 实现一个功能 :
1.3K20编辑于 2023-03-30 - 来自专栏音视频专栏
装饰者解耦的秘诀
装饰者解耦的秘诀 组合优于继承原则是个很棒的想法，可以解决继承的地狱。 然而，几乎没有库、示例代码或者教程来教你如何在 Android 上实现这原则。 这里思考一下我们如何站在前人的肩膀上去做。 protected void onStop() { } protected void onDestroy() { } } 这里装饰器里面持有了被装饰者的实例，看样子并没有有效的解耦和
1.2K40发布于 2020-04-08 - 来自专栏SDNLAB
解耦重构 Internet BGP SDN
并且解耦了传统Peering路由器，演进为Peering Fabric和服务器集群（提供反向Web代理）。 2.3 解耦Peering Router 演进到Peering Fabric Espresso 另一个主要的设计原则是解耦路由器，演变成Peering Fabric。 通过Espresso，Google改造/解耦了Peering/ASBR路由器，通过把大部分软件控制功能移到服务器。 全网已经改造为Switch/Server的架构。 ，但是开发工作量也是巨大， Google为Espresso开发了很多全新组件： { 全新层次化SDN控制器GC/LC，全新BGP协议Raven实现，全新主机IPv4/IPv6 转发表， 全新路由器解耦
2.5K41发布于 2018-10-24 - 来自专栏明志德到的IT笔记
代码中的解耦思维
通过应用解耦思维，可以将复杂问题分解为更小、更简单的子问题，并使得系统更易于理解、开发和维护。这种思维方式在软件设计、系统架构以及问题解决中都具有重要意义。 应用架构中的解耦 在应用架构中，解耦是一种重要的设计原则，旨在降低不同组件之间的依赖关系，提高系统的灵活性、可扩展性和可维护性。以下是应用架构中常见的解耦方法： 1. 通过明确定义每个层之间的接口和依赖关系，可以实现模块之间的解耦。 2. 服务导向架构（Service-Oriented Architecture，SOA）：SOA将应用程序划分为一组松散耦合的服务。 事件驱动架构（Event-Driven Architecture）：事件驱动架构通过发布和订阅事件来实现模块之间的解耦。当一个模块发生状态变化或产生重要事件时，它会发布相应的事件。 这种解耦设计可以提高系统的可靠性、可伸缩性和弹性。 6. 微服务架构（Microservices Architecture）：微服务架构将应用程序拆分为一组小型、独立部署的服务。
1.6K10编辑于 2023-12-31 - 来自专栏用户10106051的专栏
编程思想里面，何谓解耦？
核心思想主要涉及到两个方面： 一、模块解耦：模块解耦指的是将系统分解为更小的、独立的模块或组件，每个模块负责一个明确定义的功能。 不知道大家有没有听过传统的MVC架构，它将应用程序划分为三个主要部分：模型、视图、控制层。让它们各施其职，相互隔离，彼此的改动，谁也影响不了谁。 这其实本质就是模块解耦思想的体现。 （多module示例图） 二、时间解耦：时间解耦指的是系统中的不同部分不应该过于依赖彼此的执行顺序。 我们也知道它的三大核心特性：异步、解耦、消峰。 这里的解耦指的就是时间维度上的解耦。 生产者压根不需要知道消费者应用的存在。它尽管只要往指定通道发送消息即可。消费者应用如果想要数据，订阅就好。 综上，解耦是面向对象设计和软件架构中的重要原则之一，有助于构建更灵活、可维护和可扩展的软件系统。
1.5K10编辑于 2023-12-20
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号