2009系统架构师大会感想征文邀你参与！讨论：你想进行哪些行业技术沙龙？

zyxins_cu

支持，系统架构很重要。

jinnazhao

现在还能看到ppt吗？

hunterocean

非常感谢，认真学习！

polo_sz

关注

superray

在北京就好了

kekelogin

look

10149500

我很想看看。

cuguess

支持，系统架构很重要

lsl031

这个要看一看

草上飞2008

转一下：这是来自shanzhashu的大会纪要：

2009系统架构师大会纪要

    2009年8月28日至29日，IT168、ChinaUnix、IXPUB、ITPUB等多方论坛平台机构在北京举办了2009系统架构师大会（SACC），针对CTO、架构师、运维人员、开发者等对象，提供若干企业与高校中的资深架构师的技术演讲与交流。大会为期两天，在北三环附近的歌华开源大酒店举行。我作为公司的一员以听众的身份与两位同事一同前往分别学习研讨，在听课的两天中获益良多，特此记录。

    大会两个课堂是并行的，因此部分课程有时间冲突，只能选择性地听。课中有位讲师对架构师做了个分类的定义，把网络布线设计工程师等也纳入了架构师的范畴，不过从这儿多个演讲的内容来看，本次大会中的“架构师”定义主要归属于构建高负载高性能高可靠性系统的一类，这类三高系统往往有着分布式的运算与存储架构，有负载均衡、容错处理、灾难备份、内存缓存等机制，而这样的系统又以网络游戏与大型网站应用为典型代表，因此新浪、腾讯、淘宝、TOM等公司都有代表性的资深人士站出来分享他们的架构经验，同时硬件设施方面也有浪潮、世纪互联等的资深人士来针对性地讲述如何评测服务器、如何架设数据中心等，另外本次大会的赞助方也有几位娓娓动听地做着他们产品的广告。下面根据我整理的笔记结合大会提供的会议指南分别叙述之。

Linux Virtual Server

    要说本次大会技术含量最高的演讲，非章文嵩博士的Linux Virtual Server（LVS）莫属。LVS是在Linux内核的TCP/IP协议栈中实现的负载均衡和调度的模块，已经被收录入Linux 2.4和2.6的官方内核中。遗憾的是章文嵩博士的演讲时间较短，对实现的详细部分匆匆一路带过，只讲述了LVS中实现内核IP包转发的三种模式与十种调度算法。一组完整的LVS服务器由一拥有对外独立IP的负载均衡器与内网的一组LVS成员服务器组成，外部的所有用户请求都直接发给负载均衡器，由负载均衡器根据策略进行包转发，转发模式可以是NAT、IP隧道等。其中NAT方式是始终由负载均衡器实现内外网数据转发，从性能上说可能是瓶颈；其他模式则可以只让第一次会话经过负载均衡器，之后便可通过路由和外网的客户端建立直接连接而通讯，大大降低了负载均衡器的负担。这组LVS成员服务器之间的状态同步由互相之间的UDP广播实现，负载情况可动态反馈以调整转发策略。由于这些工作是在Linux内核中实现的，因此效率相当高，负载均衡器只需要很普通的CPU便可实现千兆带宽的转发，万兆也能应付得来。
    LVS已经成为了许多高性能集群解决方案的软件技术基础，如本次大会的演讲里广告做的挺隐性的F5公司，上午刚通过吴静涛先生罗列的一堆性能难点来引出自己的产品介绍，下午章文嵩博士便小声说F5前期的产品是基于LVS的，牛人就是牛啊。

海量SNS网站的柔性运营

    腾讯的邱跃鹏给我们带来了“柔性”服务的体验，意思是说在访问负荷特大、带宽等资源严重不足的时刻，允许服务不那么刚性地提供所有完整的服务，而只提供部分核心业务内容，如QQ空间只显示文字不显示皮肤等。但他又同时强调，柔性并不等于放弃服务质量，而只是某一高峰时段的应急措施，由于这种措施降低了服务质量，因此对于收费服务等，很可能引起用户的不满而带来很大的负面效应，所以采取这种柔性措施必须很慎重，必须尽量先想其他办法来分流高峰。他举例说QQ的购买奴隶游戏，每过半夜12点就出现极大的流量对服务器造成很大的冲击，原因在于许多用户在半夜12点抢购好友为奴隶并折磨、讨好之。而腾讯应付的办法是，抢购好友为奴隶的允许时间段不变，但把允许折磨、讨好奴隶的时间段改为早晨六点（或是八点？）后，这样就把半夜12点的一次大流量高峰分流了一半到早晨，有效地降低了系统负荷，这种先从业务改造为主来应对危机的思想是值得体味的。

服务器性能评测优化与数据中心的节能建设

    这三个议题偏向于硬件设施方面。浪潮的乔鑫先生带来了服务器性能评测与优化的经验，评测主要从可用性、功耗、性能、稳定性、可管理性等各方面进行针对性评测。优化的手段只记住一个：硬件定制化，如摒弃传统机箱，用机架搭上一层层主板来做服务器集群等。北京计算中心的欧阳巨星（！）先生则在数据中心的节能方面展示了一批数据与采取的应对措施。据其数据显示，决定一个数据中心能否正常运营的首要因素是耗电，耗电成本决定了建设位置。而在耗电量的分布中，数据中心的服务器只占据了一半，其余近40%的耗电量用于制冷，10%用于UPS。因此从服务器与制冷两方面都有节能的措施可以做：选择节能芯片、使用小硬盘与固态硬盘；水冷机柜、建立热模型以实现局部精确制冷等。这些手段的前期成本投入会比较高，但从长远来看还是很划算的。另外如果分布式系统中带有冗余存储的设计，则UPS等也可以省略而改用低成本的充电电池，只要意外断电时能有几秒或几分钟的时间来同步状态即可。世纪互联的姜俊海先生接着讲述了一下数据中心建设中的工程规划问题，包括施工、接线、消防设施整合等，离我们似乎比较远，没记下多少来。

高性能服务器程序设计

    TOM在线网站的肖彬先生在他的演讲中罗列了一些设计经验，如瓶颈多发处可能是在内存复制、上下文切换、内存分配释放以及锁竞争的时刻；SocketAPI的效率、线程创建销毁的性能、IO性能等是选择OS的依据；IO策略在select、poll、Kqueue、/dev/poll、Epoll中究竟应该如何选择等。但这些内容对于听众来说，倘若没有实际的经验，恐怕是难以深入理解的。

有效地监控分析系统

    海纳互联网研究中心的王怀志先生给大家分享了他在实际项目中通过系统监控来根据监控结果做优化的宝贵经验。他列举的分布式系统中的监控内容中有以下几个重点：用户请求的成功率、高负载下的响应时间、单个节点的性能（如线程数等）随数据量增长的曲线、节点与节点之间业务报文请求的成功率等。举例说明，如果某节点线程数很多但CPU占用率不高，则需要检查线程函数中是否有无谓的等待在浪费时间。
    另外王先生还分享了几条设计的经验原则，给我印象最深的是I/O要力争做到连续，也就是力争做到存储连续不跳跃以减少同一业务中的IO次数。这里王先生举了一个十分典型的例子：好友列表功能。一般系统中如果允许用户拥有其他一批用户为好友，那么常规的设计是在数据库中增加一张两个字段的表，每条记录对应着一条好友关系，表示第二个字段的人是第一个字段的人的好友。这样用户量增长时这张表的记录数增长很快，并且由于用户添加好友在时间段上的不连续性，同一用户的好友记录分布也是不连续的。这样每次查询一个用户的好友所执行的SQL语句在存储方面可能就要进行多次IO以读取完整的数据，造成瓶颈。王先生说碰到这样的性能瓶颈问题先不要马上考虑MemCache，而是可以在好友存储方式上做做手脚。他的解决方案是把好友列表放入单个文本文件中存储，每一个文件中的一行代表了一项好友关系，磁盘预先分配空间避免增长碎片。这样，每次读取一个用户的好友列表时便只需要一次IO便能将数据全部读入内存，有效提高了性能。不过我怀疑的是，光好友列表功能这样做容易，但倘若还有其他和数据库打交道的业务模块需要和好友列表等功能交互，那么文件方式和数据库方式的整合可能存在不小的困难。如果全改成预分配文件存储，那数据库方面的功能如表连接等做起来就麻烦了，需要自己实现基于文本文件的SQL解析引擎，可实施度不高，只能在数据库自身的存储方面尽量优化做到连续。
    其他的原则还包括读写分离，读不上锁而写才上锁，锁应该尽可能少；用异步请求代替同步以减少等待时间；避免用户引发计算，尽可能提前生成结果；优化的重点顺序是先优化算法，再考虑MemCache，再考虑加硬件，等等。

其他

    此外，新浪的总监童剑先生介绍了新浪平台的架构，原型来自Livejournal，用了许多久经考验的开源系统。北京武神世纪的曹世军先生也谈到了游戏架构中的监控架构设计，列举了一些典型的监控工具如实现嵌入式监控、和OS独立的IPMI，专门报警的Nagios，专门记录的Cacti等，并提到设计的开始应该保持简单和易于扩展，可多用成熟开源的系统，重视已有的标准可以少走弯路。有位讲师（忘记是谁了）还说，我们不需要重新造轮子，但可以打磨轮子，还是很有道理的。

总结

    由于分身乏术，淘宝、数据库Mysql等的专场我没能聆听，有待其他朋友补上。另外大会最后日程安排有变化，取消了教育行业方面架构设计的下午专场，不能不说是一个遗憾。总的来说大会组织还是不错的，自助餐吃得也比较爽，广告多一点也是没有办法的事情。台下提个问也有纪念品拿，引诱了大伙积极性的爆发，把气氛弄得挺热烈，这招真不错。