漫天风把细小的事情做到极致

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为 Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi 在中国的推广起到了很大的作用。

王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？

林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在 3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会需要一个强 大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构 并存、数据冗余和同步等问题。

王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？

林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据 库的特性（例如Oracle的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方 式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切 换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接 和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。

王速瑜：开放平台设计问题：开放平台API设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计， 倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比 如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的?

林昊：对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http， 接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供； 开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电 信行业。

王速瑜：跨IDC部署程序模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？

林昊：跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和 时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要 借助自动化的部署系统。

王速瑜：Web2.0网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体解决方案的？

林昊：目前互联网公司，例如Google、优酷等，对于小文件或大文件的存储都有自己的一套解决方案，而并不会 去依赖高端的存储设备来解决。一方面是成本问题，另外一方面是伸缩问题，因此对于这些文件的存储、读取和备份多数都采用了类似GFS的方案或直接采用 Hadoop提供的HDFS方案。

王速瑜：互联网产品部署是一个很关键的环节，很多互联网公司依然采取手工部署发布产品版本的方式，但是这种方式 比较复杂而且低效，往往很容易出错，如果同时发布几个产品时，如果产品之间关联比较紧密，其中一个发布出错就会影响到其他的发布，请问作为架构师，您在日 常工作中是如何解决这样的问题？您的团队中是否考虑自动化动态部署，具体方案是怎么样的？

林昊：在部署这个问题上，目前好像只有国外的几家互联网公司做的不错，其中最典型的是eBay。eBay在很多 年前就已经做了一套自动化部署系统，在这套系统中，eBay可以将一次发布中的几个产品进行依赖关系的分析，从而决定其发布顺序，并可实现自动的发布、校 验和回滚，这套系统相信也是现在中国几家互联网公司都在追求的目标。

王速瑜：作为互联网技术架构师，您能简单总结一下海里互联网服务技术架构方面的理念、原则，方法吗？

林昊：我觉得eBay的五点总结基本已经够全面：

（1）“ 拆分”，数据库的拆分以及应用的拆分，当然这需要强大的技术的支撑，这点要做到的目标通常是便于应用的无限水平伸缩；

（2）能异步就异步，这需要业务的允许；

（3）能自动就自动，就像自动化的部署系统；

（4）记住所有失败的事情，这点非常重要；

（5）容忍不一致性，这句话的含义是尽量少用强事务，而是采用最终一致性这类方案。

当然，除了上面这五点之外，还有像多用缓存、自行实现关键技术（以控制稳定性、性能和做到及时响应）等。

王速瑜：有很多优秀的软件架构师能力很强，但是由于缺乏海量服务技术应用和实践的机会，不能很好地进行海量服务应用的架构设计，您能给他们一些宝贵建议，分享一下您是如何不断学习成长起来的？您有哪些提高技术视野的方法和途径，比如有哪些书籍可以推荐，哪些优秀的网站可以推荐？

林昊：这个问题提到点子上了，很多架构师不知道如何应对大型、高并发的场景，最主要的原因是没有这样的实践的机 会，毕竟目前只有在大型企业系统或互联网才能获得这类难得的实践机会，通常在没有实践机会的情况下是很难完全理解这些技术的。多数情况下，互联网中的技术 方案都是在多次血泪宕机下成长起来的，建议只能是多看各种互联网技术介绍的文章，例如Google共享了很多，还有网上也有很多各家互联网公司技术架构文 章的介绍，尤其是那类技术发展历程的介绍，可以设想下如果自己碰到这样的问题，会如何去解决，也许这样能慢慢掌握和理解大型、高并发系统的解决方案。书籍 方面目前国内各种高性能方面的书也开始不断冒出了，例如有《MySQL性能调优与架构设计》、《构建高性能的Web站点》、《构建Oracle高可用环 境》等，这些高性能的书通常都来源于作者亲身的经验，是非常值得学习的；另外要知道：如果想做到高性能，通常意味着要对软件（包括OS等）以及硬件技术都 有充分的掌握，因此像《深入理解JDK》、《深入理解Linux内核》、《深入理解计算机系统》这些书也是非常值得一看的。至于网站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/这些都是非常不错的网站。

（本文来自《程序员》杂志0909期，更多精彩内容敬请关注0909期杂志。）

冯大辉，技术名人，http://www.dbanotes.net/ 博主。

冯大辉：假设一家 C2C 网站，DB中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于一 个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?

王速瑜：对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于C2C类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要在进行细分：

1. 买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分表，定时 归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
2. 对于正在交易中的数据，主要根据时间进行分表。如果分的更细，则可以分三个表，但是这样在事务保证方面则要复杂很多，不建议这样做

冯大辉：技术团队在开发过程中是否进行集成测试? 进行与否的理由各是什么? 对于集成测试你是否有其他补充?

王速瑜：有进行集成测试，因为集成测试对于产品版本的发布是一环重要的保证。但是由于互联网产品研发的敏捷性，很难建立一套大而全的集成测试平台，而更多还是在功能级和模块级别上的集成测试。

互联网产品的测试跟传统的软件测试不太一样，互联网产品的特性是短平快，因此敏捷开发的理念在互联网产品研发中非常适合，腾讯很多团队都采用敏捷开 发的实践，包括TDD,重构和持续集成。因此集成测试更多是体现在产品的每个小迭代和小发布中。互联网产品技术架构都是分层的，因此对于后台server 的集成测试也很重要，这个在迭代过程的测试中容易被忽略。这一块往往需要开发额外的工具来辅助进行，比如对于协议接口的测试，通常会有一些小工具来辅助进 行。

冯大辉：对于一个架构师来说，如何与冗杂的会议进行斗争? 你有哪些心得或者贵公司有哪些针对会议的策略呢?

王速瑜：对于 架构师，参加会议是必然的，架构师往往都需要深入到具体的项目中去，在项目的开展过程，大概会有几类会议是由架构师发起或重点参与的，包括迭代0的架构设 计讨论会、定期的架构和代码Review会等等，项目之外，架构师通常还会参加诸如行业级和公司级别的一些盛会和峰会。对于会议，更多还是抱着有益，高效 的态度去参加。在实际工作当中，我觉得有以下几点是可以参考的：

1. 涉及架构发展和改进的会议一定要进行， 而且要在产品研发过程中阶段性进行。有利于保证架构工作的可持续发展；
2. 由架构师主导的会议，要把握高效会议的原则，包括会议前的充分准备工作、会议进程的把握、会后的关键事项跟进等等；
3. 架构师要积极参加产品的讨论会，了解产品发展的规划和细节，有很多架构工作是需要技术与业务相平衡的，参加这样的会议有利于架构师更好理解业务和它的发展，从而为架构的平衡做出更好的判断；
4. 架构师要扩展视野和保持不断学习的态度，因此行业技术盛会、公司技术峰会、产品月会等等类型的会议架构师要主动选择性去参加，可以保证架构师能了解技术趋势，提升自己的能力。
5. 不必要的会议尽量不参加，可以采取其他沟通手段，如邮件，IM工具来替代，提升沟通的效率。

冯大辉：架构师是否有必要关注用户体验? 如何从架构师的层面关注用户体验?

王速瑜：非常有必要。保证用户体验是所有软件最重要的目标，特别是互联网产品，如果该目标无法实现，再好的架构也没有存在的意义。因此如何在满足用户体验的前提下进行架构设计是架构师的必要素质。

产品的用户体验包括几个方面：产品的功能便利性、产品可用性、性能、安全性等等。例如：枪战类的游戏，需要优先保证其实时性。而在C2C订单交易中则优先保证其金钱的安全性。因此如何从架构层面就去关注用户体验非常重要。对于架构师来说，通常有以下几点是需要注意的：

1. 用户体验表现在外表，但来源与内在。比如互联网服务的性能设计，能否让用户在1秒内使用你的产品，将是保证用户继续使用产品的关键所在。架构上如何做得在海量用户的前提下很高的性能，就应该是架构师首要关注的点；
2. 用户体验与架构设计有时候会对立矛盾，架构师需要平衡。比如为了某个用户体验，可能需要架构上做出重点的调整，可能会带来巨大的运营成本。这个时候就需要架构师来Trade-Off了，柔性可用依然是可以采取的架构原则；
3. 一切以用户体验和价值为核心是每个架构师在架构互联网服务的基本准则。互联网服务不同于传统软件，UGC型的互联网产品更是如此，没有用户参与，再好的架构都是无益的，因此架构设计需要围绕用户体验和价值来持续进行。

本次“架构师接龙”全文，请见2009年08期《程序员》杂志。

一、背景

Netlog是一家社交网站社区，目前拥有大规模的应用数据，包括：

超过4000w的活跃用户数、每个月5000w的UV、每月50亿的PV、每月60亿的在线时长、支持26中语言，覆盖5个主要的欧洲国家，如意大利、德国，土耳其等

用户访问的统计视图如下：

数据库统计如下：

大量的数据需要存储，eg. 100+ million 好友关系

互动性强，写操作非常频繁，1.4/1 read-write ratio

在没有做架构改进前，高峰期数据库压力：3000+ queries/sec

相关问题：

随着业务的快速增长，性能问题日益突出，主要瓶颈更多是发生在数据库层，原因如下：

1、web应用堆栈的各个层，大部分是无状态通信的；

2、唯一有状态（或事务）主要发生在数据库层，关系数据库的依赖关系和数据交互导致；

3、传统数据库技术无法满足高性能需要，水平扩展的需求明显；

本文主要是通过开发者视角来介绍Netlog在发展过程中的解决方案和经验。Netlog 基本完全采用开源的解决方案：例如 php, MySQL, Apache, Debian, Memcached, Sphinx, Lighttpd, Squid, 及其它.

二、Netlog数据库系统可伸缩性变化过程

在这个演变过程中，其实跟我上次介绍的另外一篇文章基本类似 “大型网站架构演变和知识体系藏”

第一步：一台DB Server 苦干

这个server 刚开始还是部署在虚拟机环境，承担所有的数据请求和处理，包括web服务器也是在这台机器上（嘿嘿，刚开始的时候，好像所有公司都这个样子，那个时候没有米嘛），后来根据实际情况，把web 服务器和DB 服务器做了一次分离。

第二步：Master-Slave

一台DB Server已经无法满足业务增长需要。在这个阶段，根据业务情况可以考虑投入更多的server，通过mysql的复制功能（replication）很容易实现ML的方案。ML方案使你很容易把所有写操作（INSERT/UPDATE/DELETE)跳转到Master Server，而所有读操作（READ)导向Slave Server，因此在某种意义上把数据库压力做了均衡。同时，Slaver Server通过读取Master Server的BinLog文件来保持同步，并把写的请求的数据写到Slave Server中去。

ML方案也存在一些问题，主要包括几个方面：

1、人力方面的投入，如果服务器数量增多的话，在运维上需要投入专门的DBA来运维；

2、可能出现的“replication lag”问题，也就是由于可能出现的读操作堵塞、down机、硬件故障等原因引起的Slave server与Master server数据不同步，从而引起Read的结果是取到过期的数据；

3、数据一致性的问题；

为了解决数据一致性的问题，实际开发中有些技巧，比如对Slave服务器做一些分类，把他们应用在一些诸如搜索/后台服务/统计等数据的Read中会更有效果，因为这些数据查询对实时性要求不高，可以合理避免数据一致性的问题。

Master-Slave模式非常适合读操作频繁的应用。架设你的一台server 承受所有的负载（100%),而读写的比例是4/1，那么相当于你的master server要承受大概80%的select查询，压力非常大，架设这个时候你通过增加一台Slave服务器进来，它能有效的分担select的流量，并且增强整个系统的2倍的能力。所以是一个非常廉价的解决方案。

架设是写操作非常频繁的应用，或者是master sever要承担90%的写操作负载的情况下，通过增加一台slaver server，它仅仅能带来10%的能力提升。因为这个时候，slave服务器要在master和slave服务器之间忙于数据同步，这个时间跟master的90%时间是一致的。在这样的情况下，ML模式仅仅是把read操作分布处理了，而没有分布出来write 操作，其根本原因是你把write traffic 重复了一遍，因此在这个情况下，就没有很好的解决问题。

第三、数据垂直分区

Master/Slave方案有效的解决了Read操作频繁的应用，但是对于SNS这类互动性很强的平台，Write操作也是非常频繁，但是ML却没有办法有效解决这个问题，因此，为了更好的发展，需要对Write 操作进行分布式设计。

常用的对write操作分布式设计的方案是对应用特性级进行垂直划分（Vertical Partitioning）。其实很简单，就是在把业务逻辑划分定义清楚，然后把业务对应的表（数据库）分布部署在不同的服务器，比如Blogs、Photos、Videos等等，要确保这些表没有太多的关联操作和依赖关系。对于每个应用共同的业务，如用户数据，则可以通过数据库复制的方式，把这些公共表部署在每个业务的数据库服务器中去。如下图：

待续

以下文章内容来自程序员杂志对豆瓣技术总监洪强宁的采访，简要介绍了douban网在技术架构上的思想，本次Qcon大会有洪强宁的演讲，据内部人介绍，这次演讲非常的精彩，期待中。

本刊记者：好，现在开始，豆瓣是一个非常著名的Web2.0网站，你们的开发语言选择的是Python，我想问的是，为什么选择Python？

洪强宁：我们选择Python的理由是它是动态语言，具有动态语言的优点，比如开发特别迅速。我们做的是一个Web2.0的网站，这种网站的 特点就是always beta，用户的需求在随时发生变化，我们也不断发现新的价值。所以网站的结构和程序会不断变化，如果用Java做，你的开发量比较大，你就难以做出迅速 地改变。Python的特点就是开发迅速，你可以在一两个小时，就做出一个功能。或者说已¾¬上线了，用户反映需要某一功能，也可以比较快地做出来。

本刊记者：这就是TDD，敏捷开发的思路，和传统的方式有些不同。但是会有另一方面的问题，Python的程序员好找吗？在国内会Python的要比会Java程序员少的多。

洪强宁：对，确实是。在中国用Python的人确实不多，也给我们寻找开发任何人员带来困难。不过从另一方面说，也有好处，因为没有一个学校 去教Python，会Python的人都是自己学的，也就是说他知道自己需要什么技术，而且能够通过自学掌握它，包括Python的资料中文比较少，需要 学习者接触第一手资料，这都使得Python程序员的平均水平，要比使用其他热门语言的平均水平要高。另一方面Python也越来越流行，在国外比较流行 的动态语言有Perl,和Python,现在Python已经超过了Perl。

本刊记者：不过，在Web开发这方面有许多选择，比如，Java，.NET，和PHP，在这个格局里Python还是比较弱势。

洪强宁：对，当然，它是新兴语言。在未来，我相信，至少在在Web2.0网站开发方面，它会有自己的一个位置。

本刊记者：还有问一个问题，Python与Perl比较怎么样？因为Python的面向对象的特性好一些，代码看起来更容易理解一些吧，我以前是用 Perl写程序的，觉得Perl的程序代码看起来比较乱。

洪强宁：对，Perl 是write once风格的，一个人写完了，过一段时间，可能自己都不能看懂，它确实很强大，但比较适合当作个人工具使用，不太适合团队的开发。Python的哲学是 解决问题的最好方式只有一种，这样同样的功能，每个人写出来的程序样子应该差不太多，比较易于理解，更适合团队开发。

本刊记者：还有一个问题,，有一种说法，认为Python比较慢，在性能方面会不会有问题？

洪强宁：这个问题可以分两个方面说，首先，说Python慢，这是和编译语言比，比如与C,C++，Java比，在动态语言中，它并不慢，它 比Ruby要快，它和Perl性能相当。如果选择动态语言的话，Python并不是很慢。另一方面，如果做网站开发，语言的不是速度的瓶颈，比如我把我们 现在用Python写的程序全部用C写，程序当然会快一点，但是改变不是很大。Web网站一般会有很多对IO的操作，比如对数据库的访问，对硬盘的访问响 应用户的请求，80%，90%你的时间都花在IO上，语言的速度，相对而言，不是那么重要。也可以这样说，网站的性能主要取决于架构设计的是否合理。因为 网站需要响应大量的并发的请求，如果你的设计的不好，即使你用C写的，也可能无法应付。所以更多的考虑是在架构设计上，要使架构体系不会产生速度瓶颈。

本刊记者：那您能简要地介绍一下豆瓣的架构吗？

洪强宁：关于豆瓣的系统架构图，首先我们在Web server上做个划分，把网站内容分为动态内容和静态内容。在豆瓣上所有的html都是动态内容，图片都是静态内容。分成两个Web 服务可以做不同的调优。 对动态内容，我们用的是nginx和lighttpd的混合，nginx做负载的平衡，lighttpd通过 SCGi 与application server相连，application server是基于 quixote这个框架写的。

application server拿到用户的请求,分析用户的url，并且利用外部的资源，比如数据库，组合成一个html，返回。从数据库存取会比较慢，数据库有大量的 IO，我们使用cache,我们使用的是Memcached,这是一个分布式的内存的cache，比如你可以用很多机器，每个机器有两个G的内存，我们自 己开发了client端来使用它，另外如果用户有搜索请求，我们会用搜索引擎。Xapian是一个C++写的开源的搜索引擎，我们通过Web service去访问它。其他，我们还提供了另外的Web service接口响应用户的请求，比如要访问某个文件。spread是我们最近加了一部分，用户有的请求可以采用这样的异步服务。

数据库是这样的，两个MySQL做成一对，一个master ，一个 slave，根据应用划分，使得load不会太高。这个图上»¬的是两对，实际上有三对。还有一个slave,一方面作为备份，一方面用作数据挖掘，因为不能对线上的数据做直接操作。

对于静态部分，我们也是用nginx，你注意到豆瓣现在有日记的贴图功能系统，用户可能上传很多图片，我们采用的方案是用了mogile FS ，这是一个分布式的文件系统，同时可以做备份，保持高可用性，可以提高很大的IO。

关于application server，它都是用Python写的。我们是用的MVC方式，Controller我们用的是quixote ，它接受用户的请求，根据这个URL去找到Model的某个具体的函数来执行，它是一个dispatcher，当中会判断用户的权限等。然后再传给 View，View根据模版进行渲染，形成网页。View的模版，我们以前是用的是PTL，PTL很高效，最近引用了mako，这是一个比较现代的开源的 模版，用它写出的代码比较好维护，比PTL好维护一些.。同时，在使用mako的同时，我们的工程师做了很多加速的工作，现在mako的代码有很多是豆瓣 的人写的。

你如果注意过Python的Web开发框架的话，你会发现Python的有三个比较著名的框架，Django，Pylons，TurboGears，Pylons默认的模版就是Mako。

下面的就是Model，业务模块，核心是类是User，因为Web2.0是以人为本，我们肯定会有一个User。只有人也做不了事情，还要有物。豆瓣的物，就是Subject，比如书，比如评论，比如小组等。

与数据库进行链接，我们一个很轻量级的与数据库进行链接，这也是一个开源项目，SQL Farm Manager。这个Web service，豆瓣中有很多用的都是Web service。

本刊记者：好，还想问您一个问题，Web2.0会不会也在架构设计中也有所体现呢 ？

洪强宁： Web2.0用户的反复的操作非常多，你需要一个非常流畅的体现。这需要一些技术来实现，比如Ajax；豆瓣花了很多钱很多精力，来提高性能，比如买好的 机器，使用Gentoo Linux，为什么使用Gentoo Linux，因为它方便调优。还有，大量的使用cache。在数据库调优方面，我们也花了很大的精力。

另一方面，Web 2,0是用户提供数据的，用户有很多写操作。这样很多1.0优化方法在2.0中行不通。豆瓣在数据库上用的是分库的方式。除此之外我们还尝试了一些其他的方法。

虽然没有太多更详细的介绍，但是已经可以看到豆瓣所采取的一些开源方案，现在开源的世界来构建大规模应用网站已经非常成熟了。

很早之前在Infoq上看到Heroku的介绍，不过当时这个网站并没有推出，今天在整理收藏夹的时候发现，Heroku已经推出一段时间，而且现在作为云计算平台已经有很快的发展了。

Heroku是Rails应用最简单的部署平台。只是简单的把代码放进去，然后启动、运行，没人会做不到这些。Heroku会处理一切，从版本控制到 自动伸缩的协作（基于Amazon的EC2之上）。我们提供一整套工具来开发和管理应用，不管是通过Web接口还是新的扩展API。

HeroKu的架构大部分是采用开源的架构来实现的，：）其实构建云计算平台，开源的世界已经解决一切了，不是吗？下面看看HeroKu的架构图，非常漂亮：

一、反向代理服务器采用Nigix

Nigix是一个开源的，高性能的web server和支持IMAP/POP3代理的反向代理服务器，Nigix不采用多线程的方式来支持大并发处理，而是采用了一个可扩展的Event-Driven（信号asynchronous）的网络模型来实现，解决了著名的C10K问题。

Nigix在这里用来解决Http Level的问题，包括SSL的处理，Http请求中转，Gzip的传输压缩等等处理，同时应用了多个前端的Nigix 服务器来解决DNS及负载均衡的问题。

二、Http Cache采用Varnish

Varnish is a state-of-the-art, high-performance HTTP accelerator. It uses the advanced features in Linux 2.6, FreeBSD 6/7 and Solaris 10 to achieve its high performance.

Varnish在这里主要给采用来处理静态资源，包括对页面的静态化处理，图片，CSS等等，这里请求获取不到的再通过下一层的Routing Mess去获取。通常还有另外一个选择Squid，不过近几年来，Varnish 给大型网站应用的更加的多了。

三、动态路由处理层，这里采用了Erlang 实现的，是由该团队自己实现的，Erlang 提供了高可靠性和稳定性的服务端实现能力（其实，我们也可以这样去使用），这个层主要是解决路由寻址的问题，通过合理分配动态过来的请求，跟踪请求的负载能力，并合理的分配可获取的下一层app 服务。这个层实现了对业务app的可扩展性和容错性，可以根据下一层服务的负载容量来合理进行路由的选择。原理上它是一个分布式的动态HTTP请求的路由池子。

四、动态网格层，用户部署的app是部署在这一层，可以看成是一个服务器集群，只是粒度会更加的细小。

五、数据库层，这里不用多说了

六、Memory Cache

也不需要多说，现在大部分互联网公司都在应用，而且基于它开发了很多好的连接器，我们公司其实也有在采用，不过我们还有自己开发的分布式内存系统，如原来的TTC Server，现在好像叫WorkBench。