databus

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :

背景 有不同类型的消息 不同类型的消息需要被不同的member进行消费 实现 DataType：数据的类型，包含了一个数据传输的引用，dataBus AbstractDataType：抽象的数据的类型，用来进行设置数据传输的小火车 StoppingData：具体的消息类型，停止的消息 StartingData：具体的消息类型，开始的消息 Member：消费者的接口，用来接收DataType，也就是事件进行消费 MessageCollectorMember：具体的实现消费者，内部有自己的实现逻辑 StatusMember：具体的消费事件的消费者 DataBus：事件的传送者，内部维护了一个消费者的set的列表。包含对消费者的订阅和取消订阅，以及发布事件，发布事件的实现通过消费者的列表来进行实现 来源： CSDN 作者： LuckyZhouStar 链接： https://blog.csdn.net/ZHOUCHAOQIANG/article/details/103963358

（如果对SPA概念不清楚的同学可以先自行了解相关概念） 平时喜欢做点小页面来玩玩，并且一直采用单页面应用（Single Page Application）的方式来进行开发。这种开发方式是在之前一年做的一个创业项目的经验和思考，一直想写篇博客来总结一下。 个人认为单页面应用的优势相当明显： 前后端职责分离，架构清晰：前端进行交互逻辑，后端负责数据处理。 前后端单独开发、单独测试。 良好的交互体验，前端进行的是局部渲染。避免了不必要的跳转和重复渲染。 当然，SPA也有它自身的缺点，例如不利于搜索引擎优化等等，这些问题也有其相应的解决方案。 下面要介绍的这种方式可以说是一种模式或者工作流，和前端使用什么框架无关，也和后端使用什么语言、数据库无关。不能说是The Best Practice，我相信经过更多人的讨论和思考会有A Better Practice。:) 概览 下图展示了这种模式的整个前后端及各自的主要组成： 看起来有点复杂，接下来会仔细地对上面每一个部分进行解释。看完本文，就应该能理解上图中的各部件之间的交互流程。 前端架构 把上图的前端部分单独抽出来进行研究： 前端中大致分为四种类型的模块： components：前端UI组件 services：前端数据缓存和操作层 databus：封装一系列Ajax操作，和后端进行数据交互的部件 common/utils：以上组件的共用部件