这次SD2C大会主要关注架构设计和敏捷相关的议题，结合在会上听的一些议题以及自己的想法谈一谈这次大会的一些感想，希望与大家更多一些交流。
CAP定理
2000年,Eric Brewer提出了CAP定理，对于分布式系统来说，有三个核心的系统级指标：Consistency、Availability 和 Partition Tolerance，按照更通用的说法，就是Consistency、Availability 和 Scalability，CAP定理指出，同一时刻只能做到其中的两项。
对于一个高用户、高并发和高流量的网站来说，Scalability是必须得保证的，这是网站继续良好运行和发展的一个很重要的前提，说到底，就是保证通过增加硬件就可以达到更高性能、更高容量、更高并发处理能力和更低响应时间等。
对一个中大型网站来说，Availability也是必须得保证的，一般来说，按照可用性程度可以分成基本可用性(99%可用)、较高可用性(99.9%可用)、具有故障自动恢复能力的可用性(99.99可用)和极高可用性(99.999可用)，很多站点也都在这方面下了很大工夫。提高可用性有很多方式，比如消除单点、做集群、异地容灾等等。比如，今年8月18日，因为台湾地震导致海底电缆断线，当时很多国外的网站都上不去，但是Google却可以上去，是因为Google考虑到单点问题，同时在南部和北部都部署了海底电缆，这也是提高可用性的一种方式。还有比如，淘宝网的登陆凭证信息放在集中式session和cookie中,大概是8/2比例，但是淘宝做了个策略，如果集中式session服务器当了的话，可以完全切换到使用cookie临时使用，当然有些朋友可能会提到完全使用cookie的话，安全性以及cookie的大小方面限制怎么保证，安全性如果控制好了不是问题，比如EBay的登陆凭证信息几乎都放在cookie里的。可用性是相对的，只有更好，没有最好。
所以，既然在Scalability和Availability上取舍不了，那就只能在一致性上做适当的取舍，淘宝选择这样做， EBay、 Amazon选择这样做，大部分的大中型网站很多也都往这方向靠。 Consistency也是需要的，但是迫不得已，为了Scalability和Availability，只能在可接受的范围内做一些牺牲。
一般来说，解决一致性问题，做到尽量别用分布式事务，或者最多就用BASE事务。还有尽量的用异步操作，能异步做的就尽量别同步做，当然前提是不会影响到业务。举个例子，在Asp.net中，如果一些操作比较耗时、耗资源，这样的操作，如果是同步执行，在很大访问量的情况下，容易把线程池中的工作线程耗光，这时候就处理不了新的请求。可能有朋友说，如果操作可以支持IOCP，用IO线程来处理，这当然也是一种处理方式，但是并不是最好的方式，如果可以异步处理当然是更好了。说到这里的异步处理方式，指的是在w3wp进程之外的异步处理，比如可以Host一个基于消息队列的异步服务到Windows Service，而不是指Asp.net的异步处理方式，这样才能更根本上的解决问题。当然异步处理会出现一些延迟，需要从用户体验和产品角度去权衡了。很多事情往往都只能是在权衡。
在网站的快速发展过程中，一般都会经历一些共同的发展历程，比如上面说的这些，还有包括Distributed Cache、Distributed Storage、前端优化等等。
关于数据分割策略(分库、分表等)
在阐述淘宝发展的历程时，淘宝架构师岳旭强有提到一开始很想拆分订单表，但是一直不敢轻易动手，除去一些业务上的原因之外，还有一个原因是如果按照买家来拆分的话，按照卖家来获取订单就可能需要跨表甚至跨库了，这显然是不能接受的，反之，如果以卖家来拆分，也是会碰到这样的问题。所以接下来提到了以下几种策略：
N策略：就是一个订单存一份，所以就会碰到上面说到的问题。
2N策略：显然，2N策略就是一个订单存两份，以空间换取时间，以买家和卖家为拆分依据各自存一份订单数据，这样能保证基于买家或者卖家获取订单，在一张表里就可以获取到相应的数据，而不需要跨表/跨库操作。
2N+1策略：这个策略是N策略和2N策略的折中，就是如果同库的话只存一份，异库存两份。大家想一想，其实这种策略只是避免了跨库操作，但是避免不了同库里的跨表操作。
所以还是要根据大家的具体需求，选择具体的策略。N策略牺牲最大的时间，但是换取最小的空间需求。2N策略空间需求最大，但是时间是最少的。2N+1策略是时间和空间的折中。但是如果空间需求可以接受的话，我还是建议使用2N策略，毕竟2N策略比起2N+1策略操作起来更加方便，而且具有更高的性能。
一般来说，分表/分库是基于取模的方式，或者无论是其他的方式，比如按区间段，都会碰到热点问题：如果分配到某个表的刚好都是一些热点数据。比如淘宝上排名前几名的，商品数可能特别多，这些用户大部分是卖图书的，而图书大部分都是通过爬当当、卓越等图书网站的数据来获取的，所以可想而知，这种量将是特别大的，可能一个用户就有几十万、上百万的图书资料，如果几个这样的用户刚好都在一个表，可想而知，肯定是有很大问题。所以分表/库都要考虑到热点问题，也就是要维护一个热点用户列表。然后基于热点数据、分表策略、还有包括其他一些规则做一套路由规则。
做SNS网站的朋友可能都能体会到，好友动态是一个比较特殊和棘手的功能。岳旭强在谈到关于分表、分库策略时候，也特别提到了这个，说目前淘宝网好友动态的设计还不够完美。岳旭强没有具体的说明关于这部分的实现。我刚好在工作中，也有做过好友动态功能，也有一些感触，大概说明与大家共享和讨论一下。
首先看分析一下需求，可以得知，读的比率远大于写，所以为了更好的性能，就应该保证读的时候在一张表里，而不应该跨表、跨库读取。当然，凡事都是两面的，要保证读是这样的，肯定是要牺牲写的，也就是写的时候可能需要跨表，甚至跨库。看一下上面提到的无论是N、2N或者2N+1策略，都没有办法解决好友动态的问题，而应该是换成MN策略。一个用户发了一条动态，会广播给所有好友，也就是会存M份数据(M为好友数），最差的情况下，如果这M个好友都在不同的表、库中，就需要往不同的表、库中做M次操作，可想而知，如果好友数多的话，将是影响性能的一个关键点。当然发送动态的情况一般以异步的方式操作，而且如果再优化，可以做并行化、多线程处理。但是总的来说，还不是一个最完美的方案，是一个持续演化的过程。
敏捷相关
有不少人以为敏捷是反文档的，不需要文档的，但是其实敏捷里是用“单元测试”和各种脚本等各种“文档”来替代传统文档的，这些“文档”比起传统文档更有用和高效。
提到结对编程，来自微软的胡德民提到一点是，每个人每天8个小时的工作中，加起来一般就只有4-5个小时在很专注的工作，如果结对编程了，可以把这个时间提高不少。几个讲师也大概都提到，结对编程可以避免出现对某些知识点和技术点的“单点问题”，这些也是“文档”，比起传统文档更具有效的文档，这样也相对不怕人员流动。但是对于国内的大部分公司来说，还是不容易实施起来。
敏捷开发一般来说都很注重持续集成，乔梁在介绍持续集成的成熟度模型时，说到的成熟度模型从低到高为：
1.自动化构建并持续编译
2.单元测试自动化
3.功能测试自动化
4.部署自动化，并进行验收性测试和性能测试
5.自动部署到试运行环境和生产环境
相对来说，对于刚准备实施敏捷的公司或者团队来说，比较好实施的是：
自动化构建并持续编译 -> 单元测试自动化 -> 自动部署到测试环境。 对于自动化部署到生产环境，还是有比较多的挑战，比如要考虑到自动化回滚，需要分析各种依赖关系等，相对来说比较不容易做到完全可靠。
吴穹博士提到一个特性团队的概念，特性团队是这样一个团队，这个团队里各种职责的人都有，从产品、架构、开发到测试等，大家都互相非常熟悉，沟通和协作很方便，大家一起做事非常高效。传统的团队可能是某些项目需要人了，然后从其他团队拉一帮人过去，临时组建一个团队，然后直到项目完成，接着下一个项目可能又是一批临时组建起来的团队。特性团队讲究比较稳定的团队，不轻易的拆分人。吴穹博士说了一个数据，据某种统计显示，4-5年以上的特性团队最高效，这样的一个团 队还是比较难得的。
从我个人的角度来看，我觉得一开始实施敏捷，单元测试和持续集成可能是相对比较容易做，也比较容易出效果的。由于对敏捷还只是在探索阶段，还希望多多交流沟通。
其他几个议题
听了手机之家的"构建一个可依赖的Data Access Layer",总体上来说，手机之家在这个数据访问层上做了很多工作，比如结合MySql Proxy、Memcached、集群等思想，做成一个分布式的数据访问层。包括做到分库分表透明化，自动管理缓存等等，为了做到这样的效果，还实现了一个解析引擎，前端访问数据访问层，只能以规定的语法来调用。我听完之后，第一感觉是感觉有点“重”了，受到的约束太大了，一些数据库特性可能无法完全的使用，因为要完全让DB透明化，实在是太难做到了，尤其是还跟缓存、分布式、防止单点等一系列事情结合。而且在项目组里推动的话，可能也会遇到不少阻力。不过总体上感觉，总体思路还是不错，思路上有不少可以学习的地方，比如说，做到了缓存支持Namespace和遍历的功能，手机之家也花很多人力和精力在做，还是值得关注一下。
有个议题叫“你的服务器费用多高”，听了会，感觉跟我预想要讲的内容有比较大出入。不过也从中听到几组数据，通过统计，每台服务器的使用率一般小于15%，所以说一般来说每台服务器还有85%的资源可以挖掘。比如Google的服务器在每台及其上都备有一块小电池，效率比起UPS高很多，可以达到99.99%。
周爱民老师的<认真我们自己-实践者的思想>和黄冬老师的<大规模消息系统的架构设计>讲得挺不错，夜深了，先不写了，睡觉了。