《分布式环境搭建》由会员分享，可在线阅读，更多相关《分布式环境搭建（8页珍藏版）》请在金锄头文库上搜索。
1、随着网络流量爆发式增长，几百人维护一个项目将是一个可怕的噩梦，业务拆 分势在必行。拆分的业务形成一个个独立的系统，系统间的协调又变成了一个 棘手的问题，所以维护这些系统间协调关系的分布式环境组件将发挥至关重要 的作用。由于拆分后的系统部署于不同机器的不同集群之中，系统间的协作要靠通 信来解决，所以分布式环境组件必须解决数据流的问题。根据不同的场景，数 据流又分构建于远程调用框架（如 RMI、Hessian、ICE、JNDI 实现等）之上的 即时调用数据流，构建于消息中间件之上的异步消息（持久或非持久）数据流， 构建于数据拆分组件（分库分表、读写分离等）之上的存储数据流，构建于集 群系统控制（集
2、群动态、配置推送，如 PubSubHubBub）的集群协调数据流，以 及构建于监控系统之上的日志及控制数据流。在这些数据流的传输过程中需要 有负载均衡和容错的支持，这些数据流总的来说又分为业务数据流和控制数据 流，业务数据流传输业务数据，控制数据流可以将一个个小的集群系统连接成 一个大的集群系统，并使这个集群系统的运行状态直观的展示于眼前，同时还 可以向这个集群系统发送控制指令直接干预它。通信服务框架通信服务框架提供系统间即时的同步和异步调用，需要具备负载均衡和容错的 机制，解决的是一个业务集群调用另一个业务集群的问题，根据不同的集群方 案，业务集群内部各台机器内部的状态又分为可共享和不可共享
3、两种，一般不 建议集群内部直接通过通信来共享内部状态，最好通过集中式缓存或 DB 来共享 状态。消息中间件消息中间件提供异步的持久和非持久消息的发布和订阅，持久消息理论上应当 具备绝对的可靠性。此系统解决的是将网站业务流程中非核心的业务流程剥离 出来，使用异步消息的形式将业务解耦，提高主业务流程的响应速度，同时解 决的另一个问题是通过可靠的存储和传输，保证多个业务系统数据的最终一致。分布式数据层分布式数据层提供分库分表、读写分离、Sql 监控以及容灾容错的功能。这个 组件不仅仅可以解决数据的拆分、读写分离问题，还可以解决数据的多写，多 个 Slave 读取的负载均衡及容错，多机房的容灾，数据库
4、异常的告警等多种功 能，如果单独部署服务的话还可以控制数据库连接数。中转枢纽中转枢纽提供服务的发布和调用关系以及消息的发布和订阅关系，连接通信服 务框架和消息中间件的各个客户端和服务端，感知一个个业务集群中的每台机 器及服务，组成一个大的集群，协调这个大集群中服务的对应关系。如果这个 枢纽对业务开放的话还可以推送业务配置信息。监控中心监控中心提供对前面四个组件各种数据的收集和分析，实时展示整个大集群各 个集群和服务目前的运行状况和相互间的协调关系，并进行各种横向和纵向的 对比为决策提供依据，并可以向集群内的机器或服务发出控制指令，直接干预 集群间的协调关系。如果对业务开放的话还可以监控业务数据
5、和进行业务控制 干预。消息中间件实现方案这一聊聊消息系统，消息中间件对目前大中型互联网来说是非常重要的，在 业务数据流动中仅次于 RPC 服务调用，担负着越来越复杂的网站业务从主流程 上解耦的重要责任；从目前互联网对消息中间件的需求来看应该分为两种类型，一种是和钱相 关的需求，一种是和钱无关的需求；和钱相关的需求消息的可靠性是放在第一 位的，和钱无关的需求是速度放在第一位的，但这两种需求又是矛盾的，很难 设计出一种既可靠又高效的系统，除非将两套方案捏合成一个系统，通过配置 来选择不同方案，但从实现上说还是两种实现。所以目前业界有几种不同的设 计方式来满足不同的需求。下面看看以下几种典型实现方案
6、：1 1、以、以 ActiveMQActiveMQ 为代表的可靠性优先的设计原理：为代表的可靠性优先的设计原理：此种方案将所有的消息数据和消息的发送状态都存储在消息服务器上，可 以在消息服务上通过多种手段来保证消息的可靠性，但增加了众多复杂的可靠 性保证手段后，消息从发布者到订阅者的速度势必会受到影响；此种方式发布 者将消息推向消息服务器，消息服务器再将消息推向订阅者，为消息发送策略 提供了很好的可扩展性；2 2、以、以 KafKaKafKa 为代表的速度优先的设计原理：为代表的速度优先的设计原理：此种方式将消息的发送状态保存在客户端，同时客户端用拉的模式从消息 服务器上获取消息，由于是顺序读
7、，同时还采取了很多保证速度的策略，如 zero-copy，所以此种方案速度比较快，但牺牲了很多可靠性方面的保证，比较 适合 Web2.0 网站，这些网站对消息的可靠性要求不是很高，同时由于产生了大 量的和用户状态相关的消息，需要一个高效的系统来处理这些消息；另外这种方案也比较适合日志消息的收集；3 3、传统的系解耦方案：、传统的系解耦方案：此种方式是不用消息中间件直接用数据库存储做的解耦，随着消息中间件 的出现，这种方式的使用越来越少，但现在由于 MongoDB 和 Redis 等的兴起， 一些基于这些 Nosql 数据库的消息应用逐渐兴起，由于消息数据和消息状态都 存储在 DB 上，所以效率
8、和速度在上面两种方案之间；那么有没有一种更高效的方式呢？答案是肯定的，但那可能要进一步降低可靠性！看看 Facebook 的 Scribe 日志收集系统的原理：如果 Scribe Server 正常工作，Scribe Client 将 App 的日志（可以看成 一个消息）推送到 Scribe Server 端，如果不正常，则写到本地文件，当 Scribe Server 恢复正常时再将其推送过去；这里使用本地文件作为缓冲，那 么能否综合 Scribe 和 Kafka 的优点来设计一个消息系统（或日志收集系统，改 造一下可以互用），看下面的方案：上面的 MQ 暂且叫他 FastMQ 吧，中消息发布
9、端直接写本地文件，同时消 息订阅者通过 Zookeeper 协调，向相关消息发布者的 Agent 拉消息，并在本地 记录消息指针状态；如果嫌在消息发布端开启 MQ Agent 麻烦，那么如中消息拉取协议使用 SCP 或 FTP 协议，用这些 Linux 必备的协议提供者作为 Agent 减少开发和部署 的难度，在服务订阅端解析这些协议流，反序列化为消息供业务使用；如果觉得消息只存储在消息发布端的磁盘不可靠，那么如中可以在消息 订阅者处理不及消息的时候，把消息数据缓冲在消息订阅端的磁盘上来备份数 据，不过这样做就使系统变的复杂，虽然提高了可靠性，但是速度就会有所降 低；此种方案可以使消息分散的存储在业务本身的磁盘上，避免几种存储相互 影响的缺点，同时又可以有效利用业务机器的磁盘（大部分业务机器磁盘基本 没使用），另外还可以减少一次网络通信的过程，使从发送到接收的速度更快； 但其本身也有不少缺点，要做好监控，避免消息大量积压的时候业务磁盘过度 使用，对业务造成影响。目前我们的监控日志收集系统使用的是和中类似的方案，消息系统使用 的是 3 方案，后期可能会将可靠性要求高的向 1 方案过度，可靠性要求不高的 向最下面介绍这种过度！
