分布式环境搭建.docx

随着网络流量爆发式增长，几百人维护一个项目将是一个可怕的噩梦，业务拆分势在必行。拆分的业务形成一个个独立的系统，系统间的协调又变成了一个棘手的问题，所以维护这些系统间协调关系的分布式环境组件将发挥至关重要的作用。?　　由于拆分后的系统部署于不同机器的不同集群之中，系统间的协作要靠通信来解决，所以分布式环境组件必须解决数据流的问题。根据不同的场景，数据流又分构建于远程调用框架（如RMI、Hessian、ICE、JNDI实现等）之上的即时调用数据流，构建于消息中间件之上的异步消息（持久或非持久）数据流，构建于数据拆分组件（分库分表、读写分离等）之上的存储数据流，构建于集群系统控制（集群动态、配置推送，如PubSubHubBub）的集群协调数据流，以及构建于监控系统之上的日志及控制数据流。在这些数据流的传输过程中需要有负载均衡和容错的支持，这些数据流总的来说又分为业务数据流和控制数据流，业务数据流传输业务数据，控制数据流可以将一个个小的集群系统连接成一个大的集群系统，并使这个集群系统的运行状态直观的展示于眼前，同时还可以向这个集群系统发送控制指令直接干预它。??????通信服务框架提供系统间即时的同步和异步调用，需要具备负载均衡和容错的机制，解决的是一个业务集群调用另一个业务集群的问题，根据不同的集群方案，业务集群内部各台机器内部的状态又分为可共享和不可共享两种，一般不建议集群内部直接通过通信来共享内部状态，最好通过集中式缓存或DB来共享状态。?消息中间件提供异步的持久和非持久消息的发布和订阅，持久消息理论上应当具备绝对的可靠性。此系统解决的是将网站业务流程中非核心的业务流程剥离出来，使用异步消息的形式将业务解耦，提高主业务流程的响应速度，同时解决的另一个问题是通过可靠的存储和传输，保证多个业务系统数据的最终一致。?分布式数据层提供分库分表、读写分离、Sql监控以及容灾容错的功能。这个组件不仅仅可以解决数据的拆分、读写分离问题，还可以解决数据的多写，多个Slave读取的负载均衡及容错，多机房的容灾，数据库异常的告警等多种功能，如果单独部署服务的话还可以控制数据库连接数。?中转枢纽提供服务的发布和调用关系以及消息的发布和订阅关系，连接通信服务框架和消息中间件的各个客户端和服务端，感知一个个业务集群中的每台机器及服务，组成一个大的集群，协调这个大集群中服务的对应关系。如果这个枢纽对业务开放的话还可以推送业务配置信息。?监控中心提供对前面四个组件各种数据的收集和分析，实时展示整个大集群各个集群和服务目前的运行状况和相互间的协调关系，并进行各种横向和纵向的对比为决策提供依据，并可以向集群内的机器或服务发出控制指令，直接干预集群间的协调关系。如果对业务开放的话还可以监控业务数据和进行业务控制干预。?消息中间件实现方案? 这一聊聊消息系统，消息中间件对目前大中型互联网来说是非常重要的，在业务数据流动中仅次于RPC服务调用，担负着越来越复杂的网站业务从主流程上解耦的重要责任；??? 从目前互联网对消息中间件的需求来看应该分为两种类型，一种是和钱相关的需求，一种是和钱无关的需求；和钱相关的需求消息的可靠性是放在第一位的，和钱无关的需求是速度放在第一位的，但这两种需求又是矛盾的，很难设计出一种既可靠又高效的系统，除非将两套方案捏合成一个系统，通过配置来选择不同方案，但从实现上说还是两种实现。所以目前业界有几种不同的设计方式来满足不同的需求。下面看看以下几种典型实现方案：1、以ActiveMQ为代表的可靠性优先的设计原理：??? 此种方案将所有的消息数据和消息的发送状态都存储在消息服务器上，可以在消息服务上通过多种手段来保证消息的可靠性，但增加了众多复杂的可靠性保证手段后，消息从发布者到订阅者的速度势必会受到影响；此种方式发布者将消息推向消息服务器，消息服务器再将消息推向订阅者，为消息发送策略提供了很好的可扩展性；2、以KafKa为代表的速度优先的设计原理：??? 此种方式将消息的发送状态保存在客户端，同时客户端用拉的模式从消息服务器上获取消息，由于是顺序读，同时还采取了很多保证速度的策略，如zero-copy，所以此种方案速度比较快，但牺牲了很多可靠性方面的保证，比较适合Web2.0网站，这些网站对消息的可靠性要求不是很高，同时由于产生了大量的和用户状态相关的消息，需要一个高效的系统来处理这些消息；另外这种方案也比较适合日志消息的收集；3、传统的系解耦方案：??? 此种方式是不用消息中间件直接用数据库存储做的解耦，随着消息中间件的出现，这种方式的使用越来越少，但现在由于MongoDB和Redis等的兴起，一些基于这些Nosql数据库的消息应用逐渐兴起，由于消息数据和消息状态都存储在DB上，所以效率和速度在上面两种方案之间；?? ? 那么有没有一种更高