1.Vue的源码observable用法
2.秒懂设计模式之观察者模式（Observer Pattern）
3.Redux(4.0.4)源码解析
4.Hystrix技术指南（7）故障切换的运作流程原理分析（含源码）
5.Mobx源码阅读笔记——3. proxy 还是defineProperty，劫持对象行为的源码两个方案

Vue的observable用法

       Vue的observable功能在多子组件项目中应用广泛，可以简化数据在组件间的源码传递。以往在多个子组件间传递数据，源码通常需要通过父组件进行中介，源码过程繁琐且复杂。源码台历定制diy源码借助Vue的源码observable，可以在组件间共享数据，源码实现读取和修改的源码便利操作。下面的源码示例展示了如何在真实项目中使用observable功能，结合Element UI组件，源码如两个Dialog弹窗嵌套的源码场景。

       在项目中，源码首先创建一个JavaScript文件，源码用于实现两个或更多子组件共享数据的源码需求。这里可以提供数据读取和修改的方法，方便在多个组件中使用。实际项目中，这种模式可以有效地管理复杂的数据流，尤其在需要多个组件间交互的场景下。

       以项目结构为例，一个核心组件负责控制数据的传递和修改。以组件`Modify`和`MoreInfo`为例，它们各自承担不同的功能。组件`Modify`中的按钮触发事件，影响组件`MoreInfo`的可见性，而组件`MoreInfo`通过监听事件更新状态。qvector源码

       在组件`MoreInfo`中，需要依赖于组件`Modify`的操作来控制弹窗的显示与隐藏。将`moreInfoVisible`状态变量引入`bus.js`文件中，并使用Vue的observable特性。这样一来，组件`Modify`可以通过直接修改`moreInfoVisible`状态来控制组件`MoreInfo`的可见性。同时，组件`MoreInfo`可以直接读取`moreInfoVisible`状态来决定自己的打开与关闭。

       此外，组件`MoreInfo`还需要从组件`Modify`接收特定参数，如`achievementList`。这些参数同样存入`bus.js`的observable对象中，组件`Modify`作为数据的提供者，监听并更新`achievementList`。通过这种方式，组件`MoreInfo`可以实时获取最新的数据信息，确保数据的一致性和实时性。

       为了方便查看代码实现，可以参考码云上的源代码项目：[mws_home/front-knowledge](链接)。这里展示了完整的实现流程和代码细节，帮助理解如何在Vue项目中利用observable功能优化组件间的交互与数据管理。

秒懂设计模式之观察者模式（Observer Pattern）

       本文将简要介绍设计模式中的观察者模式，也称为发布-订阅模式。这个模式虽然常见且易于理解，但由于其广泛应用和深远影响，探讨起来需要谨慎。rivz源码在读者的催促下，我决定在端午节这个特殊时刻，为大家梳理一下。

       观察者模式的核心思想是建立对象间的订阅关系。例如，如果你是一名编程爱好者，对shusheng的设计模式系列很感兴趣，那么你会订阅这个系列，每当有新文章发布，你都会收到通知。这样的情境在编程中体现为：一个对象（被观察者）的状态改变，所有订阅它的对象（观察者）都会自动获知并相应更新。

       这个模式属于行为型设计模式，难度较低，主要在订阅-发布场景中发挥作用。观察者模式的UML图清晰地展示了其角色，包括被观察者（Observable）和观察者（Observer）。被观察者定义了订阅和取消订阅的方法，以及状态变化时通知观察者的方式。观察者则负责接收并处理事件通知。

       让我们通过一个实例来理解这个模式。想象王二狗和西门*荡都是上官无雪的粉丝，他们会关注上官在社交平台上的动态。每当上官发布新动态，王二狗和西门都会收到通知并做出相应的反应。

       在编程中，emojio源码可以创建一个上官无雪类，提供订阅和通知的方法。观察者王二狗和西门*荡类则实现观察者接口，接收并处理状态改变的通知。当不再关注上官时，他们可以取消订阅。

       尽管Java早期版本提供了支持观察者模式的接口，但在Java 9中这些接口被标记为废弃。如今，随着框架和库的普及，设计模式的需求在一定程度上降低了，但这并不意味着它们不再重要。设计模式可以帮助我们写出更灵活、可维护的代码，尽管在实际工作中可能并不显眼。

       最后，尽管IT行业的趋势让编程工作更侧重于实现和业务代码，但设计模式的学习仍然是提升编程技能的关键。祝大家端午节快乐，期待大家在编程的道路上不断进步。

       源码地址可在GitHub获取。

Redux(4.0.4)源码解析

       Redux源码解析

       Redux源代码解析旨在清晰展示其核心组件及工作流程，力求用最简洁的语言阐述每个关键部分的功能。Redux提供了一个状态管理库，以管理应用的全局状态。以下是baidupcs源码Redux核心组件的主要解析：

       createStore.js

       export default function createStore(reducer, preloadedState, enhancer)

       createStore函数是Redux的核心，负责创建一个状态存储对象。它可以接受三个参数：reducer（减少操作函数）、预加载状态（初始状态）和增强器（可选参数，用于添加额外功能）。

       getState

       获取当前状态，操作简单直接。

       subscribe

       向监听列表中添加监听函数，返回取消监听函数。在调用dispatch时订阅或取消订阅，不会影响正在进行的dispatch。下一次dispatch时，将使用订阅列表的最新快照。

       dispatch

       执行reducer获取最新状态，并依次执行监听队列中的函数。

       replaceReducer

       替换当前的reducer。执行后，dispatch一次更新状态。一般不常用。

       observable

       未见实际应用，可能用于特定场景。使用了symbol-observable包，对于熟悉该包的开发者来说，此部分可能有更多探索空间。

       utils

       包括actionTypes.js、isPlainObject.js、warning.js等辅助函数。actionTypes.js定义了Redux保留的私有操作类型，用于确保操作的正确处理。isPlainObject.js用于判断action对象是否为原生对象。warning.js用于抛出错误，保持代码质量。

       applyMiddleware.js

       通过createStore(reducer,applyMiddleware(...middleware))执行，返回带有中间件增强的dispatch。精简后，代码更加清晰。

       compose.js

       实现中间件的串联，依次增强dispatch流程。使用函数式编程技巧，代码简洁高效。

       bindActionCreators.js

       将单个或多个ActionCreator转化为dispatch(action)的函数集合，简化Action的使用方式。

       combineReducers.js

       将多个reducer整合为一个，调整state结构，便于管理和操作。

       整体而言，Redux的源码解析展示了其如何通过一系列核心组件实现状态管理的流程，从创建store到管理state、执行reducer、中间件串联，直至整合多个reducer，提供了一套高效、模块化的状态管理方案。理解这些组件及其功能是掌握Redux并能灵活应用的关键。

Hystrix技术指南（7）故障切换的运作流程原理分析（含源码）

       目前对于一些非核心操作，如增减库存后保存操作日志发送异步消息时（具体业务流程），一旦出现MQ服务异常时，会导致接口响应超时，因此可以考虑对非核心操作引入服务降级、服务隔离。

       Hystrix说明

       Hystrix是Netflix开源的一个容灾框架，解决当外部依赖故障时拖垮业务系统、甚至引起雪崩的问题。

       为什么需要Hystrix?Hystrix设计理念

       想要知道如何使用，必须先明白其核心设计理念，Hystrix基于命令模式，通过UML图先直观的认识一下这一设计模式。

       Hystrix如何解决依赖隔离Hystrix流程结构解析

       流程说明:

       以下四种情况将触发getFallback调用：

       熔断器:Circuit Breaker

       每个熔断器默认维护个bucket，每秒一个bucket，每个bucket记录成功，失败,超时,拒绝的状态，默认错误超过%且秒内超过个请求进行中断短路。

       Hystrix隔离分析

       Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散.

       线程隔离实际案例：

       Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响。Netflix 内部API 每天亿的HystrixCommand依赖请求使用线程隔，每个应用大约多个线程池，每个线程池大约5-个线程。

       信号隔离

       信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）,如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销。 信号量的大小可以动态调整, 线程池大小不可以。

       线程隔离与信号隔离区别如下图:

       fallback故障切换降级机制

       有兴趣的小伙伴可以看看： 官方参考文档

       源码分析

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       executeCommandAndObserve

       使用Observable的onErrorResumeNext，里头调用了handleFallback，handleFallback中区分不同的异常来调用不同的fallback。

       applyHystrixSemanticsViaFallback方法

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       针对每个commandKey获取或创建TryableSemaphoreActual

       fallback源码分析小结

       hystrix的fallback主要分为5种类型：

       获取以上资源请访问开源项目 点击跳转

Mobx源码阅读笔记——3. proxy 还是defineProperty，劫持对象行为的两个方案

       这篇文章将深入分析 MobX 的 observableObject 数据类型的源码，同时探讨使用 Proxy 和 Object.defineProperty 这两种实现方案来劫持对象行为的策略。通过分析，我们能够理解 MobX 在创建 observableObject 时是如何同时采用这两种方案，并在创建时决定使用哪一种。

       首先，回顾 observableArray 的实现方式，通过 Proxy 代理数组的行为，转发给 ObservableArrayAdministration 来实现响应式修改的逻辑。同样，我们已经讨论过 observableValue 的实现，通过一个特殊的类 ObservableValue 直接使用其方法，无需代理。

       对于 observableObject 的实现机制，其特点在于同时采用了上述两种方案，并且在创建时决定使用哪一种。让我们回到文章中提到的工厂方法，其中根据 options.proxy 的值来决定使用哪一种方案。

       在 options.proxy 为 false 的情况下，使用第一条路径来实现 observableObject。这通过直接返回 extendObservable 的结果，其中 extendObservable 是一个工具函数，用于向已存在的目标对象添加 observable 属性。属性映射中的所有键值对都会导致目标上生成新的 observable 属性，并且属性映射中的任意 getters 会被转化为计算属性。

       这里首先根据 options 参数选择特定的 decorator，这个过程与之前在第一篇文章中通过 options 参数选择特定的 enhancer 类似。实际上，这里的 decorator 起到了类似的作用，甚至在创建 decorator 这个过程本身也需要通过 enhancer 参数。

       至于 decorator 和 enhancer 之间的耦合机制，文章中详细解释了 createDecoratorForEnhancer 和 createPropDecorator 函数，通过这些函数我们能够了解到它们是如何将 decorator 和 enhancer 联系起来的。

       接下来，文章深入分析了 decorator 的作用机制，包括它如何决定是否立即执行，以及在不立即执行时如何将创建 prop 的相关信息保存下来。通过 initializeInstance 函数，我们了解了如何解决 # 问题，这涉及到如何正确处理那些在创建时未被立即执行的 prop。

       最终，通过为 target 对象创建 ObservableObjectAdministration 管理对象，并通过 $mobx 和 target 属性将它们关联起来，我们完成了 observableObject 的创建。如果传入的 properties 不为空，则使用 extendObservableObjectWithProperties 来初始化。这里的代码逻辑相对简单，主要遍历 properties 中的所有键并调用对应的 decorator。

       文章还指出，虽然在第一条路径中，使用 Object.defineProperty 重写了 prop 的 getter 和 setter，但在 MobX 4 及以下版本中，使用 Proxy 来实现 observableObject 的逻辑更为常见。Proxy 特性在 ES6 引入后，提供了更强大的能力来劫持对象的行为，不仅限于 getter 和 setter，还包括对象的其他行为。

       最后，文章总结了使用 Proxy 方案的优点，包括能够更全面地劫持对象的行为，而不仅仅是属性的 getter 和 setter。Proxy 方案在实现双向绑定时，能够提供更灵活和强大的功能。同时，文章也提到了两种方案的局限性，尤其是在处理对象属性的可观察性方面，Proxy 方案在某些情况下可能更具优势。