2009年是挑战和机遇并存的一年，对大部分人来说，已经习惯了金融危机，并努力解决危机。在技术圈子也一样，被裁员的肯定也找到了工作，所以都在踏实做技术。言归正传，先念叨念叨2009年的一些故事，寻个回忆，找个乐子。
数据扩展性探讨和总结
金融危机是电子商务的机遇，所以09年是淘宝高速发展的一年。当一个网站从百万、千万记录的数据规模，增长到亿、十亿、几十亿记录的数据规模时，是一个量变到质变的过程，单纯的硬件升级已经达到了瓶颈，而需要在整体结构上做文章。09年一年，大部分时间都在数据的扩展性上努力。
对于一个电子商务网站来讲，订单是最核心的数据，也是增长最快的数据。对于数据的扩展性来讲，最传统也是最简单有效的模式是数据库的分库分表。当订单和分库分表相遇，会有什么火花迸发出来？09年初碰撞了很久，结果产生的火花很小。最大的问题在于数据分割的规则，无规则的水平分割肯定会带来数据合并的开销，而按照业务规则拆分，会因为买家和卖家的查询需求不同而导致数据不能分割，唯一可行的火花是把订单双份保存，买家卖家各自一份，只是成本比较高，而且对数据同步的要求非常高。
于是我们初步决定按照双份保存的方式拆分订单，而有一天，仔细查看了订单访问的情况，发现订单数据库90%以上的压力来自于查询，而查询中90%以上的压力来自于非核心业务，仅仅是订单数据的展现，对一致性和实时性的要求很低。
因为数据量大，造成数据库压力大，天然想到的是分散压力，其办法就是分库分表。有些时候我们想问题不妨直接一点，既然压力大，能不能减小压力呢？通过对订单访问情况的了解，发现昂贵的主数据库，有80%以上的压力给了不重要的需求，这个就是我们优化的关键，所以订单最后采用了读写分离的方案，高成本的主数据库解决事务和重要的查询业务，80%以上不重要的读，交给了低成本的数据库服务器来解决，同时对数据复制的要求也很低，实现无太大难度。
另外一个有意思的案例是商品的数据扩容，商品的水平分割非常容易，按照卖家进行拆分即可。有了订单的先例，首先想到了读写分离，因为成本可以做低。开始实施后一段时间，又仔细回想了一下商品的整体需求，突然发现商品其实不需要和订单同等的要求，一定要采用高成本的主数据库吗？ 全部采用低成本的普通服务器来做数据库是否可行？经过仔细的评估，发现是可以接受的，而这样就导致之前已经启动的商品读写分离项目的一部分工作白做了！
故事讲完了总是要有点总结，来点虚的先：对于原始需求的清晰了解是系统决策的前提，否则弯路肯定要走，而对原始需求的了解并不容易，中间会有很多干扰和阻力，前面的实例看起来很简单，但是在一个运行了5年的系统上来了解本质，来进行变更，并没那么容易。另外，经验有些时候会成为系统决策的障碍，这个很矛盾，所以需要有归零的心态来思考问题。说到底，回归本源。
再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是非常必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路由、复制、合并、搬迁、热点处理等功能，并且要对应用透明，应用针对性的，可以在JDBC层面包装，数据库针对性的，可以在数据库协议层包装，比如Amoeba。
关注系统和人的交互
还有一个故事，在数据层的前期版本，为了做到透明的路由，曾经采用无SQL的方式，所有的数据库访问都是写代码来做。上线后发现一个非常痛苦的问题，无法和SQL对应，排错非常难。曾经一次DBA发现数据库上一个查询耗费太多资源，把优化后的SQL给开发人员改进，开发人员好几天没找到具体是哪个查询。
另外一个在2009年的感触是业界服务化的实施情况，很多组织都在实施服务化，系统层面都很成功，通信、负载均衡、消息系统、服务容器等都有很多成果，但是实施一段时间以后的效果并不是非常好，依赖复杂，变更混乱，效率低下。究其根本，是对人的关注不够，缺少的产品化的服务运维，缺少服务治理。
上面的两个例子都是对人的关注缺失，技术人员做系统，大部分都更关注技术，而忽视技术的创造者和使用者——人。软件或服务的可测试性是对测试人员的关注、可维护性和可管理性是对运维人员的关注，而一个框架的易用性是对所有使用人员的关注。除非能做出自己进化的Skynet（注：Skynet（天网）出现在《终结者》系列电影中，是一个人类于20世纪后期创造的以计算机为基础的人工智能防御系统，最初是研究用于军事的发展。），否则还是要多关注系统和人的交互。
关注可用性
还有一个感触是业界对可用性这个基本指标的关注度不够。几乎所有的框架都会说自己的扩展性多高，性能多好，而很少会提到监控有多强、排错有多容易，很少提到在故障时怎么做隔离，怎么做降级；从这个角度看，商用的产品确实做得好很多；关于性能相关的文章搜索一下，很多，各种优化策略，各种优化方法，而可用性方面，找到的系统性的知识真的很少；希望是我了解的不多。
回顾过去，展望未来。2010年，很多可以做的事情，面向服务系统的隔离和降级、系统可维护性的提高、协程和异步模式在web应用的全面使用……
免责声明：我很现实，为解决问题和完成工作不择手段，并且不懂架构是什么意思，以上观点如有雷同，纯属巧合！如有异议，欢迎拍砖！
个人简介：岳旭强，淘宝网技术专家。2004年加入淘宝，见证了淘宝网业务以及技术上完整的发展过程；在过去5年的时间中，参与了淘宝几乎所有核心系统改造，并主导了用来支撑淘宝网未来高速发展的核心业务中心的建设。岳旭强现在负责网站整体业务架构的设计和规划，在大型交易网站的设计和调优方面有丰富的经验。