互联网网站架构升级----分布式环境的构建

     随着网络流量爆发式增长，几百人维护一个项目将是一个可怕的噩梦，业务拆分势在必行。拆分的业务形成一个个独立的系统，系统间的协调又变成了一个棘手的问题，所以维护这些系统间协调关系的分布式环境组件将发挥至关重要的作用。

 

　　由于拆分后的系统部署于不同机器的不同集群之中，系统间的协作要靠通信来解决，所以分布式环境组件必须解决数据流的问题。根据不同的场景，数据流又分构建于远程调用框架（如RMI、Hessian、ICE、JNDI实现等）之上的即时调用数据流，构建于消息中间件之上的异步消息（持久或非持久）数据流，构建于数据拆分组件（分库分表、读写分离等）之上的存储数据流，构建于集群系统控制（集群动态、配置推送，如PubSubHubBub）的集群协调数据流，以及构建于监控系统之上的日志及控制数据流。在这些数据流的传输过程中需要有负载均衡和容错的支持，这些数据流总的来说又分为业务数据流和控制数据流，业务数据流传输业务数据，控制数据流可以将一个个小的集群系统连接成一个大的集群系统，并使这个集群系统的运行状态直观的展示于眼前，同时还可以向这个集群系统发送控制指令直接干预它。

 

 

 

 

 

 

通信服务框架提供系统间即时的同步和异步调用，需要具备负载均衡和容错的机制，解决的是一个业务集群调用另一个业务集群的问题，根据不同的集群方案，业务集群内部各台机器内部的状态又分为可共享和不可共享两种，一般不建议集群内部直接通过通信来共享内部状态，最好通过集中式缓存或DB来共享状态。

 

消息中间件提供异步的持久和非持久消息的发布和订阅，持久消息理论上应当具备绝对的可靠性。此系统解决的是将网站业务流程中非核心的业务流程剥离出来，使用异步消息的形式将业务解耦，提高主业务流程的响应速度，同时解决的另一个问题是通过可靠的存储和传输，保证多个业务系统数据的最终一致。

 

分布式数据层提供分库分表、读写分离、Sql监控以及容灾容错的功能。这个组件不仅仅可以解决数据的拆分、读写分离问题，还可以解决数据的多写，多个Slave读取的负载均衡及容错，多机房的容灾，数据库异常的告警等多种功能，如果单独部署服务的话还可以控制数据库连接数。

 

中转枢纽提供服务的发布和调用关系以及消息的发布和订阅关系，连接通信服务框架和消息中间件的各个客户端和服务端，感知一个个业务集群中的每台机器及服务，组成一个大的集群，协调这个大集群中服务的对应关系。如果这个枢纽对业务开放的话还可以推送业务配置信息。

 

监控中心提供对前面四个组件各种数据的收集和分析，实时展示整个大集群各个集群和服务目前的运行状况和相互间的协调关系，并进行各种横向和纵向的对比为决策提供依据，并可以向集群内的机器或服务发出控制指令，直接干预集群间的协调关系。如果对业务开放的话还可以监控业务数据和进行业务控制干预。

 

先写这么多了，后续将会写业务和数据拆分方面的，以及通信框架、消息中间件、分布式数据层、中转枢纽和监控中心的具体实现。

写得很实在.
图不错.
期待技术细节.

现在还看不太懂，等楼主和下面高人进一步解析

现在看来我还是一个初级程序员，这些东西都看不太懂，期待大家的详细解析。。。

这个工作比较庞大，为了这些组建之间有良好的兼容和协调关系，将会全部自己实现，后面会一边做一边分享下自己的感悟。

楼主这一套东西，基本上是把淘宝内部的架构搬过去了，做大了面临的问题一样。不知道楼主现在在什么公司？

呵呵 是的，好的架构就是要推广嘛，淘宝当初也是很大程度上参考了ebay的架构。公司名就不说了，公司在快速膨胀，架构需要升级。公司短期内肯定达不到淘宝的流量，淘宝目前的问题一段时期内不会遇到，但不同的公司有不同的业务，基础框架就是为业务服务的，会根据业务和发展方向做出调整。

这个不错啊，很有吸引力。楼主需要人手不？让偶参与一下，学学东西～

难怪我看了眼熟

贵公司具体的应用情况是怎么样的呢?
系统的规模，机器的数量。pv，目前的瓶颈什么的。
就拿分布式数据层来说，应用场景是很有限的。