Behind The Cloud--浅析分布式系统背后的基础设施
?
前言：WEB2.0的时代格局下，信息越来越发散，搜索越来越智能，内容越来越丰富，互动越来越频繁。随着团购、社区、微博不断崛起，互联网已经深入人心。用户规模的不断扩大，新业务的不断开拓，直接导致系统规模不断膨胀。在这种情况下，如何来保障分布式系统构建的稳定性与高性能呢？
?
--本文作者chenkangxian，引用请标明出处?http://chenkangxian.iteye.com/blog/1674198
图1??? 传统的共享文件系统
图2? HDFS体系结构
图3 TFS体系结构
图4? Zookeeper集群
?
3.分布式服务治理
随着访问量的急剧攀升，导致服务端承受的压力越来越大，由于单台服务器节点硬件的垂直可扩展的空间有限，且随着规模的增大成本急剧攀升，单一应用依靠增加机器带来的速度提升成本越来越高，已经无法满足需求，因此不得不对其进行业务的拆分和细化，将相关业务抽取出来，形成独立的服务，这样既能够方便扩展和管理，又能够适应不断变化的需求，降低开发成本，提高系统的复用性，这便是所谓的SOA(Service-oriented Architecture)。
图5 基于rpc的SOA模型
图6? mapreduce计算模型
图7 mapreduce任务调度
图8? 某CDN节点负载均衡结构
?????????? ???????? 图9? memcache构建的cache集群
图11 HBase集群部署图
图12 点对点消息模型
图13? 订阅发布模型
在分布式系统环境下，消息从发送到接收，经历过的中间环节非常多，任何一个环节出错，均有可能会导致消息的丢失，而对所有的消息均采用持久化处理，又会导致的性能的成本升高，因此，对消息进行分级是有必要的。既允许一部分消息丢失，来换取高吞吐率，对于不可丢失的消息，先做持久化后再进行返回。某些情况下，多条消息可能需要同时发送成功，而这些消息的接收者可能是不同的对象，这种情况下，则需要使用XA事务来进行保障。多线程高并发条件下，消息发送的顺序性很难保障，并且，由于网络的缘故，可能消息接收方明明收到消息，而在回复确认的时候网络闪断，则接收方有可能收到重复的消息，因此，既要保证消息不重发又要保证消息的安全是非常困难的，所以我们在可能接收到重复消息的情况下，必须保证所设计系统的幂等性。
常见开源的消息队列产品包括apache的ActiveMQ，spring的RabbitMQ，memcacheQ以及淘宝的metamorphosis等等，以淘宝的metamorphosis[4]为例，它支持broker以Master/Slaver的方式实现HA(High Availability)和Failover，Master与Slaver通过Msglog来实现同步，避免了broker的单点问题。
?
--本文作者chenkangxian，引用请标明出处?http://chenkangxian.iteye.com/blog/1674198
?
小结
本文对分布式系统架构所涉及的一些基础设施做了简要介绍，讨论了构建一个健壮的分布式系统所涉及到的众多领域，并分析了他们的设计思想及原理。一个成熟的分布式系统通常内置冗余设计，通过使用大量普通的机器集群来替代高性能服务器，以此节约成本，并保障系统的高可用性，而CAP理论则告诉大家，一致性、可用性、分区容错性这三者无法同时兼备，因此，我们在设计时必须得有所取舍。
由于分布式系统本身的复杂性，牵涉范围广泛，因此难免挂一漏万，一个可靠的完整的分布式系统架构可能还涉及到硬件虚拟化，数据仓库，搜索，集群监控，智能运维等等领域，限于篇幅，笔者此处便不再赘述。
?
?
?
参考文献
[1] TFS?http://code.taobao.org/p/tfs/wiki/index/
[2] http://www.infoq.com/cn/articles/tao-tfs
[3] tair http://code.taobao.org/p/tair/wiki/index/
[4] metamorphosis http://code.taobao.org/p/metamorphosis/wiki/index/
?
?
1 楼 bushyou 2012-09-10 mark，空了来看 2 楼 bingyingao 2012-09-10 不错，mark