下面是小编为大家推荐的淘宝网技术专家:大型交易网站的设计和调...，本文共5篇，欢迎阅读，希望大家能够喜欢。
篇1：淘宝网技术专家:大型交易网站的设计和调...
是挑战和机遇并存的一年，对大部分人来说，已经习惯了金融危机，并努力解决危机，在技术圈子也一样，被裁员的肯定也找到了工作，所以都在踏实做技术。言归正传，先念叨念叨20的一些故事，寻个回忆，找个乐子。
数据扩展性探讨和总结
金融危机是电子商务的机遇，所以09年是淘宝高速发展的一年。当一个网站从百万、千万记录的数据规模，增长到亿、十亿、几十亿记录的数据规模时，是一个量变到质变的过程，单纯的硬件升级已经达到了瓶颈，而需要在整体结构上做文章。09年一年，大部分时间都在数据的扩展性上努力。
对于一个电子商务网站来讲，订单是最核心的数据，也是增长最快的数据。对于数据的扩展性来讲，最传统也是最简单有效的模式是数据库的分库分表。当订单和分库分表相遇，会有什么火花迸发出来？09年初碰撞了很久，结果产生的火花很小。最大的问题在于数据分割的规则，无规则的水平分割肯定会带来数据合并的开销，而按照业务规则拆分，会因为买家和卖家的查询需求不同而导致数据不能分割，唯一可行的火花是把订单双份保存，买家卖家各自一份，只是成本比较高，而且对数据同步的要求非常高。
于是我们初步决定按照双份保存的方式拆分订单，而有一天，仔细查看了订单访问的情况，发现订单数据库90%以上的压力来自于查询，而查询中90%以上的压力来自于非核心业务，仅仅是订单数据的展现，对一致性和实时性的要求很低。
因为数据量大，造成数据库压力大，天然想到的是分散压力，其办法就是分库分表。有些时候我们想问题不妨直接一点，既然压力大，能不能减小压力呢？通过对订单访问情况的了解，发现昂贵的主数据库，有80%以上的压力给了不重要的需求，这个就是我们优化的关键，所以订单最后采用了读写分离的方案，高成本的主数据库解决事务和重要的查询业务，80%以上不重要的读，交给了低成本的数据库服务器来解决，同时对数据复制的要求也很低，实现无太大难度。
另外一个有意思的案例是商品的数据扩容，商品的水平分割非常容易，按照卖家进行拆分即可。有了订单的先例，首先想到了读写分离，因为成本可以做低。开始实施后一段时间，又仔细回想了一下商品的整体需求，突然发现商品其实不需要和订单同等的要求，一定要采用高成本的主数据库吗？ 全部采用低成本的普通服务器来做数据库是否可行？经过仔细的评估，发现是可以接受的，而这样就导致之前已经启动的商品读写分离项目的一部分工作白做了！
故事讲完了总是要有点总结，来点虚的先：对于原始需求的清晰了解是系统决策的前提，否则弯路肯定要走，而对原始需求的了解并不容易，中间会有很多干扰和阻力，前面的实例看起来很简单，但是在一个运行了5年的系统上来了解本质，来进行变更，并没那么容易。另外，经验有些时候会成为系统决策的障碍，这个很矛盾，所以需要有归零的心态来思考问题，
说到底，回归本源。
再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是非常必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路由、复制、合并、搬迁、热点处理等功能，并且要对应用透明，应用针对性的，可以在JDBC层面包装，数据库针对性的，可以在数据库协议层包装，比如Amoeba。
关注系统和人的交互
还有一个故事，在数据层的前期版本，为了做到透明的路由，曾经采用无SQL的方式，所有的数据库访问都是写代码来做。上线后发现一个非常痛苦的问题，无法和SQL对应，排错非常难。曾经一次DBA发现数据库上一个查询耗费太多资源，把优化后的SQL给开发人员改进，开发人员好几天没找到具体是哪个查询。
另外一个在年的感触是业界服务化的实施情况，很多组织都在实施服务化，系统层面都很成功，通信、负载均衡、消息系统、服务容器等都有很多成果，但是实施一段时间以后的效果并不是非常好，依赖复杂，变更混乱，效率低下。究其根本，是对人的关注不够，缺少的产品化的服务运维，缺少服务治理。
上面的两个例子都是对人的关注缺失，技术人员做系统，大部分都更关注技术，而忽视技术的创造者和使用者——人。软件或服务的可测试性是对测试人员的关注、可维护性和可管理性是对运维人员的关注，而一个框架的易用性是对所有使用人员的关注。除非能做出自己进化的Skynet（注：Skynet（天网）出现在《终结者》系列电影中，是一个人类于20世纪后期创造的以计算机为基础的人工智能防御系统，最初是研究用于军事的发展。），否则还是要多关注系统和人的交互。
关注可用性
还有一个感触是业界对可用性这个基本指标的关注度不够。几乎所有的框架都会说自己的扩展性多高，性能多好，而很少会提到监控有多强、排错有多容易，很少提到在故障时怎么做隔离，怎么做降级；从这个角度看，商用的产品确实做得好很多；关于性能相关的文章搜索一下，很多，各种优化策略，各种优化方法，而可用性方面，找到的系统性的知识真的很少；希望是我了解的不多。
回顾过去，展望未来。，很多可以做的事情，面向服务系统的隔离和降级、系统可维护性的提高、协程和异步模式在web应用的全面使用……
免责声明：我很现实，为解决问题和完成工作不择手段，并且不懂架构是什么意思，以上观点如有雷同，纯属巧合！如有异议，欢迎拍砖！
个人简介：岳旭强，淘宝网技术专家。加入淘宝，见证了淘宝网业务以及技术上完整的发展过程；在过去5年的时间中，参与了淘宝几乎所有核心系统改造，并主导了用来支撑淘宝网未来高速发展的核心业务中心的建设。岳旭强现在负责网站整体业务架构的设计和规划，在大型交易网站的设计和调优方面有丰富的经验。
篇2：大型综合网站设计之美交互设计
前言
标题有点大的，确切点说这里讨论的是“大型综合网站的设计之美”，区别于个人站点和一些SHOW类型的公司站点，
话题是前2天提到的关于站点设计的“美”的问题想到的。究竟对一个较大的综合性网站来说，如何的设计表现才算是得体、到位？如何才能算得上是一个“美”的站点？
本文分3个部分：
首先大致分析下各方面对设计（部门）的诉求是什么；
然后再回头看看，对于这些诉求，究竟什么才是“美”，和我们原本想象的有没有差别；
最后，结合目前实际，给出几条粗浅的见解，如何成就网站设计之美；
对美的需求
OK，设计之美，什么是设计之美呢？还是先从各方面对美的诉求开始简单看一下吧
·商业设计服务于商业目标
在所有的诉求之前，有一条商业设计基本定律，即一切商业设计服务于商业目标的诉求。这是最基本也是最核心的。但是说起来简单，理解执行彻底却不是那么容易。有的时候，对于一些问题，我们如果冷静下，回到初始状态来仔细想一想，我们为什么要（给一个站点/项目）做设计，就能得到答案了。
·内容之美
请问有多少访问GOOGLE的用户是为了欣赏它的美丽的？百度呢？FACEBOOK？SOHU？SINA？恐怕即使有也仅是很少的特别用户，例如设计师。这类站点吸引人的地方并不是它们的设计，它们不因为美而闻名。它们因为功能而受欢迎，因为新鲜的内容而受关注。这也是基本定律之一。没有人会仅仅为了吸收美丽的版面设计而常来TAOBAO或者口碑，用户来是因为站点满足了他们某方面的需求。当然，也存在那种很大程度上依赖外观来吸引人的产品，APPLE是一个神话，但那种创新的勇气和魄力绝对不是一般其他公司所能比的。
·视觉与情感
对访问者来说，在使用产品或者满足其需求的同时，如果能操作更简单、流程更顺利、视觉感受到的东西和当时内容表现的情感能相互烘托，而带来某种额外的满足或者心情的愉悦，那么，也可以看作是对美的一种潜在需求。
·效率之美
这点是从公司运行的层面来看的，即保证有限资源在流程中不成为项目的瓶颈，用最少的资源达到较优的效果。时间管理的培训中曾提到，往往花20%的时间就能完成80%的事情，而剩下的20%的事情，却要用80%的时间来完成。效率之美，在于它的过程，不影响整体流程进度、节省资源，同时也就能有更多的精力投入到更需要的、更重要的地方去（例如用户体验研究）。
什么是美
简单的（很可能是还不够全面的）了解了一下各个方面对美的诉求，让我们再回头看看，对一个大型综合类站点来说，究竟什么才是设计之美。
·简单or繁复
这个有点TO BE OR NOT TO BE的味道，简单呢？还是繁复？貌似很难回答。当把这个问题带到一个实际项目中去的时候，就更难客观把握。OK，我们刚刚了解过美的诉求，现在不妨带入这里看一下。第一条，不管简单还是繁复，应当以商业需求为目的。恩，不过貌似并没有解决问题，再看。第2条，需要显现出（这里没有使用“突出”这个词，因为这个动词往往被理解为“用设计上的着重表现手法使其明显”）内容和功能，并不一定要设计得很复杂，只要内容和功能能显现并被正确使用和理解就好了。再看第3条，在不影响内容和功能使用的基础上，能额外的带给用户情感的愉悦。最后，要开发、维护成本低。
看起来有矛盾的地方，但是基本还是很清楚的：
1、最基本的，站点的表现（叫设计也好，叫修饰也好），应该以能条理清晰的展现内容、准确无误的引导使用功能为准。
如果太过简陋，条理不清晰，糊在一起，则设计不够；如果设计成分，如标题栏背景、装饰图片等吸引了注意力，影响了对内容本身的注意，则设计太过。
2、在完成以上最基本的诉求之后，可以适当的点睛之笔来满足视觉和情感上的诉求。但是忌多忌滥忌喧兵夺主忌为了设计而设计。
一个页面，在1-2处以精致的图标或者小创意为着色点，可以极尽发挥，生动有趣、酷眩动人，不影响其他内容的理解和阅读，又让整个页面生动活泼、不失风味。但是千万不能说为了这里要好看，所以就生硬的找几个地方浓墨重彩。相反，修饰应该都是带有目的性的，为什么要修饰它，为什么要这么修饰，都是有讲究的。
3、有的时候，商业需求需要做一些特殊的调整，例如活动和