RabbitMQ消息中间件(九) RabbitMQ的SET化架构衍化与设计

大厂单元化架构设计演变之路

    随着业务的多元化发展，各个行业业务持续高速增长，单个大型分布式体系的集群，通过加机器+集群内部拆分（kv，mq，MySQL等），无法满足扩展性需求，并且大集群内核心服务出现问题，会影响全网素有用户。

    单个大型分布式集群，会面临以下问题：

        1.容灾问题

            *核心服务（比如订单服务）挂掉，会影响全网所有用户，导致整个业务不可用

            *数据库主库集中在一个IDC，主机房挂掉，会影响全网所有用户，整个业务无法快速切换和恢复。

        2.资源扩展问题

            *单IDC的资源（机器，网络带宽等）已经没法满足，扩展IDC时，存在跨机房访问时延问题（增加异地机房时，时延问题更加严重）

            *数据库主库单点，连接数有限，不能支持应用程序的持续扩展

        3.大集群拆分问题

            *核心问题：分布式集群规模扩大后，会相应的带来资源扩展，大集群拆分以及容灾问题

单元化架构方案

    对于业务扩展性以及容灾需求的考虑，我们需要一套从底层架构彻底解决问题的方案，业界主流解决方案：单元化架构方案

        同城"双活"架构介绍：

            1.业务层面上已经做到真正的双活（多活），分别承担部分流量。

            2.存储层面比如定时任务，缓存，持久层，数据分析等都是主从架构，会有跨机房写。

            3.一个数据中心故障，可以手动切换流量，部分组件可以自动切换。

        两地三中心架构介绍：

            使用容灾的思想，在同城”双活“的基础上，在异地部署一套灾备数据中心，每个中心都既有完备的数据处理能力，只有当主节点故障需要容灾的时候才会紧急启动备用数据中心。

SET化方案目标：

    业务：解决业务遇到的扩展性和容灾等需求，支撑业务的高速发展

    通用性：架构侧形成统一通用的解决方案，方便各业务线接入使用

    流量路由：

        按照特殊的key（通常为userid）进行路由，判断其次请求该路由到中心集群还是单元化集群

    中心集群：

        未进行单元化改造的服务（通常不在核心交易链路，比如供应链系统）称为中心集群，跟当前架构保持一致。

    单元化集群：

        每个单元化集群只负责本单元内的流量处理，以实现流量拆分以及故障隔离。

        每个单元化集群前期只存储本单元产生的交易数据，后续会做双向数据同步，实现容灾切换需求。

    中间件（RPC，KV，MQ等）：

        RPC：对于SET服务，调用封闭在SET内；对于非SET服务，沿用现有路由逻辑

        KV：支持分SET的数据生产和查询

        MQ：支持分SET的消息生产和消费

    数据同步：

        全局数据（数据量小且变化不大，比如商家的菜品数据）部署在中心集群，其他单元化集群同步全局数据到本单元化内。

        未来演变为异地多活架构时，各单元化集群数据需要进行双向同步来实现容灾需要

SET化路由策略及其能力

    异地容灾：

        通过SET化架构的流量调度能力，将SET分别部署在不同地区的数据中心，实现跨地区容灾支持

    高效本地化服务：

        利用前端位置信息采集和域名解析策略，将流量路由到最近的SET，提供最高效的本地化服务。比如O2O场景天然具有本地生产，本地消费的特点，更加需要SET化支持

    集装箱式扩展：

        SET的封装性支持更灵活的部署扩展性，比如SET一键创建/下线，SET一键发布等

SET化架构图：

        图中C点可有可无，可以等待RPC调用返回消息，不阻断核心链路

        一个SET中服务挂掉，会调用其他SET中的服务。

SET化结构原则

    SET化重要的原则：

        对业务透明原则：SET化架构的实现对业务代码透明，业务代码层面不需要关心SET化规则，SET的部署等问题。

        SET切分规则：

            1.理论上，切分规则由业务层面按需定制

            2.实现上，建议优先选最大的业务维度进行切分

            3.比如海量用户的O2O业务，按用户位置信息进行切分。此外，接入层，逻辑层和数据层可以有独立的SET切分规则，有利于实现部署和运维成本的最优化。

        部署规范原则：

            一个SET并不一定只限制在一个机房，也可以跨机房或者跨地区部署，为保证灵活性，单个SET内及其数不宜过多。

RabbitMQ-SET化架构实现

    SET化消息中间件架构实现（RabbitMQ双活）：

    使用RabbitMQ异步消息通信插件Federation安装与配置：

rabbitmq-plugins enable rabbitmq_federation

rabbitmq-plugins enable rabbitmq_federation_management

备注：当你在一个cluster中使用federation插件，所有在集群中的nodes都需要安装federation插件

    Federation插件：

        Federation插件是一个在不需要cluster，而brokers之间传输消息的高性能插件。它可以在brokers或者cluster之间传输消息，链接的双方可以使用不同的users和virtualhosts，或者双方的rabbitmq和erlang版本不一致，federation插件使用AMQP协议通信，可以接受不连续的传输。

    建立Federaiton：

        上游节点：196.168.11.81 下游节点：192.168.11.82

    添加策略：

    发送&接收消息：

        在81上建立的test.exhcange上发送消息，在82上的test.queue上接收消息

SET化配置规则：

    1.Federation Exchanges，可以堪称Downstream（82节点）从Upstream（81节点）主动拉取消息，但并不是拉取所有消息，必须是在Downstream上已经明确定义Bindings关系的Exchange，也就是有实际的物理Queue来接收消息，才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间同i性能，Downstream会将绑定关系组合在一起，绑定/解除绑定命令将发送到Upstream交换机。

    2.经过配置后，Upstream节点已经可以把消息直接通过Federation Exchange路由给Downstream节点，然后进行消费。也就是说可以实现消息的转发，接下来也可以在Upstream添加具体的队列去进行消费Federation Exchanges里的消息，我们一条消息分别发到了2个RabbitMQ集群并且消费，这样我们可以实现SET化的关键要素，就是集群间的消息同步了。

    3.可以根据自己的业务规则去规划不同的集群去监听不同的消息队列，从而达到SET化的手段，保障了性能，可靠性，数据一致性。