以下为2012年全球架构师峰会ArchSummit第一天早上的实录资料。
【时间】2012年8月10日 上午
【地点】深圳万科国际会议中心大宴会厅
【实录内容】
【主持人霍泰稳】我是InfoQ的创始人兼CEO，今天上午的串场由我来主持。现场有多少同学从华南地区过来的？（全场大部分人举手）这个效果正是我们InfoQ想要的，今年要在华南做一次全球峰会，主要是为了华南朋友不要那么周折去参加活动。第一次在北京做活动的时候，很多朋友从深圳、广州过去，华为、腾讯每年都有很多人参加，做了一个简单的回访，去北京参会最大问题是什么？很多人说太远，三天会议的票价还没有差旅费那么高。
在去年在杭州做了另外一场全球软件开发，今年在深圳做Archsummit，Archsummit主要关注架构方面，全球软件开发大会除了架构包括软件开发和项目管理方面。
在今天上午有三个主题演讲：
第一，大数据的技术趋势和演变。
第二，腾讯开放平台、架构设计揭秘。
第三，一个圆桌论坛。
在座的都知道Facebook，这次我们邀请到Facebook前数据团队的负责人，也是Apache蜂巢的创始人。今天分享中首先会谈到大数据的驱动力，接着是演化、遵循的路径，背后的故事，还会谈一些方向以及包括一些挑战。
第二个主题演讲嘉宾是汤道生，腾讯公司的高级执行副总裁，有四个人直接向马化腾汇报的，汤经理是其中一个。今天分享的是腾讯开放平台架构设计揭秘，主要包含几方面的内容：
如何实现整个海量处理架构、如何把这种架构的能力提供给创业团队，现在创业人士越来越多，不能在开放平台上做事情，要自己做事情。腾讯开放平台会提供什么帮助。以及会谈到很多人关心的安全问题，如果放在腾讯开发平台上怎么保障数据的安全性。
第三个是圆桌论坛，邀请了几位嘉宾，主持人是王宏，来自上海大众点评网的高级架构师，从一开始创建在大众点评工作，架构是由他来主导设计的。有四个参与者：
黄冬，土豆网产品与技术副总裁，是啄木鸟社区的创始人；
廖若雪，百度技术委员会主席；
汤道生刚才介绍了；
吴永强，去哪儿CTO，现在主要负责技术团队的管理。
接下来邀请下午的主持人介绍一下负责的专题包含哪些内容，听了简单的介绍对下午有一个简单的了解。下午可以自由选择相关的场地，有请吴永强。
【吴永强】主持人一说压力很大，我主题专题是架构的伸展与演变。我们觉得架构像一个孩子的心智一样，架构像他的父母，怎么在企业不断扩张、成长的过程中，带领着架构不停地往上升级。
主要讲师有：
第一，来自于人人网的刘源，从人人网的特点讲到遇到的问题和解决方案，从很具体的故障当中分析大型系统中的共性问题。
第二，来自腾讯的张松国，讲得腾讯微博架构引进的三个阶段，分的非常清楚。包括第一个阶段的平台化，第二个阶段的性能优化，到第三个阶段更高层次的要求，比如说高质量运维方面的内容。
第三，来自淘宝的赵超，他在淘宝待了十几年，见证了淘宝从最开始很简单的架构，到现在承载了中国电子商务网站中最大流量变迁的过程。讲得东西很有意思，基本上他讲大家都会觉得像说相声一样，非常有意思。
第四，Ashish讲的是Facebook海量数据架构演变过程。
欢迎大家下午参加我们的专题，谢谢！
【主持人】这个专题就在这个会场，下面一个主持人是来自百度的廖若雪。
【廖若雪】大家好！下午我这边主持的话题是“搜索新时代”，搜索引擎从发展开始，架构是搜索里面一个革新的技术，我们处理互联网网站、互联网数据，达到PP级的分布式计算和存储平台。我们现在认为搜索引擎对于大多数用户来说是随时可用的系统，如何解决这方面的问题？如何提供高可用性？提供随时可用的服务体验？都是搜索遇到的问题，今天在下午讲师有：
首先，百度公司最早架构师的陈竞凯，会讲搜索引擎的架构，一开始怎么做？发展到什么程度？思考以及展望。竞凯对百度搜索引擎最了解，最清楚的架构师之一。
第二，来自搜狗的茹立云，主要讲来自I网核心的问题，不止是针对PC互联网上的数据，去抓取应用非常好的价值。无线互联网时代的数据，非常具有现实和将来的意义。
第三，一淘网的曲琳，主要讲大的应用垂直搜索，与一般的网页搜索相比除了遇到的问题，还会遇到更复杂的策略、更复杂数据相关的问题，更重要的是如何建立一个很有效的运维系统提供高可靠性、可用性的系统。听完这样专题会有问题，所以最后我们有一个圆桌论坛，有什么问题可以一起讨论，充分解决大家的问题，充分理解在这里的分享，谢谢！
【主持人】谢谢！下面有请海量视频的处理与分发的黄冬。
【黄冬】深圳来了之后先被出租车冻了一下，又热了一下。视频网站带宽用很多，用的很大，量也很大。光大没用，还要有新的东西。今天讲与视频网站相关的新技术和面对的新问题。跟大家介绍一下视频网站新兴的不同的方向。
首先，来自微酷的首席架构师赵志猛，主要分享在微视上遇到的问题，传统的视频特性和微视频遇到的问题，如何做好的、快的架构，这个内容很新的。
第二，来自于视讯天下的廖雪峰，基于视频的SaaS，可以用视讯天下的平台搭建视频网站，搭建视频网站上的各个服务，因为是SaaS的平台，汇集了现有的视频网站经验，以及面对中小用户出现问题一系列的处理，有非常精彩的处理。
第三部分，来自于土豆网，会很细致的说一下在土豆网如何完成整个视频网站最核心CDN部分处理的特性和实践方法。土豆网CDN的架构非常独特，在国内视频网站里面最与众不同的一个，欢迎大家一起听一听。
最后，杜嵩会为大家讲一个特别的话题，视频广告的架构，视频网站的广告和传统互联网不同，互联网是基于网页的广告，而视频广告有很多独特的特性，决定了一个截然不同的架构。如何面对用户访问的特性以及后面的数据处理都有非常精彩的分享。
所有有关视频相关的部分我相信都会有很好的分享，希望大家到我们的会场来听一听，谢谢！
【主持人】非常感谢腾讯和腾讯大讲堂，假设没有腾讯的支持，全球架构师峰会在深圳举办非常困难的。在和腾讯沟通过程中非常愉快，给整个大会，包括在组织上、资金上、内容上给了非常多的支持。非常感谢另外一个VIP的赞助商VMware，感谢它的支持。
QCon杭州在10月份，有需要的同学报名。让我们掌声有请来自Apache Hive的Ashish，有请他来第一个分享！
#p#
【Ashish Thusoo】各位上午好！我叫Ashish，第一次来到中国，感谢主办方邀请我来参加这次活动，今天谈一谈大数据架构以及怎么样不断的演进，与其说演进，不如说革命。
首先，看一下今天讲的三大主题：
第一，大数据的需求。当今世界需要大数据，有哪些驱动因素促使我们不同方式考虑大数据？以不同方式处理数据。
第二，技术给我们带来哪些架构上的调整或者权衡。比如说新的技术和传统上90年代的数据技术有哪些变革？架构上做了哪些调整？要哪些优化？不同纬度做权衡的标准。
第三，未来。我们哪些技术问题需要解决的？
以上是我讲的三大主题，希望大家会觉得有意思，从中学到一些东西。
首先，看一下变革的驱动因素是什么？我们生活在不断变革的世界中，有三个技术的参数，在大数据方面带来很大的变化：
第一，设备。第二，基础设施。第三，应用程序。
以上三点结合在一起，不但快速改变我们的生活，而且变革给我们带来很多的需求，这里讲了三个技术上的驱动因素，分别意味着什么？具体来看一看。
首先，看一下设备。现在看到的图是手持设备发展过程，上世纪90年代的手机非常大，不可能随手拿着，放到包里才能带出去，最新的是现在看到的iphone，获得了非常大的变化。比如说PDA或者其他的智能手机，现在有一些重要的能力，以前无法设想的，永远保持网络联系，可以查询到它的位置。
有非常强劲的功能，可以用GPS、有摄像头，可以进行重力感应，调整现在的温度。手机从感官的角度来讲，把人的感官延伸，这些程序给我们带来很多数据。除了讲得PDA和所联系的设备部分，包括iphone，其他设备也在进化，包括智能读表器、健康情况小设备，融汇在我们生活中，非常强劲，也给我们产生很多数据。这些设备产生了很多数据，也让我们想想怎么好好管理这些大数据。
互联性，现在看到的是国际电信联盟下载的材料，是关于全球移动用户的用户数量。2004年的情况，蓝色是密度非常低，在亚洲和非洲地区。黄色密度最高，用的最多是橙色的。在一些不是特别发达的国家，甚至世界各地，手机用户数量越来越多，不仅讲得是互联性，还有带宽，新的无线传输技术，使得手机设备方面的数据传输越来越快，最大的手机传输数据100兆已经不是问题，未来会越来越高，相互联系的能力会越来越强，带宽越来越宽，以及我们说的感应设备等。这种技术上的大融合趋势，能够让我们看到了最后一个应用。所有新的技术要通过应用才能实现。
现在看到很多基于云计算的程序，很多应用化计算都是基于“云”的，在90年代关注企业里面有10个人、100人、1000人，现在规模和容量扩大，不仅几千、几万，甚至上百万、上千万，现在设备做得越来越多，联系性越强，设备越强，有更大的带宽，基于云的集中式的数据。这三点是需要的大数据。感应式的设备生产数据。更多的联系性把数据到云端，在云端做些什么呢？这么多的数据怎么运作快速生成的大量数据。大数据意味着很多人一起做很多的事情。要关注大数据的三个特点：大容量、高速度、种类繁多。不止有一些表格、数据，应对非常多的数据。
举一个例子，在容量方面，2011年数字宇宙里面，我们所存储的数据是1.8个ZB，1个ZB相当于100万个GB，2009到2020年中间，数据总数量达到35个ZB。
再来看一看速度，数字形成的速度也让人瞠目结舌。现在的数据来自于知名的互联网应用，推测的数量每天3.4亿，而且数据不是最新的，最近数据增加非常多，另外每分钟上传的视频72小时，每秒290万封邮件，数据生成的速度非常快。另外还有视频、图片、应用、记录等，不仅仅讲得传统意义上的图表，现在还包括各种各样的文件。
现在讲得数据和过去讲得数据不一样，是大容量、高速度、种类繁多的数据。这对系统架构有什么影响呢？影响非常深远，直接关系到在过去这么多年以来，怎么样向数据不断严谨。回到上世纪90年代，我们关注的是结构性的数据，怎么样数据处理更快。现在的应用越来越繁杂，需要不同的规格以及不同的扩展，因此我们的关注在过去十年里也出现了变化。原来只是关注简单的性能，到现在可扩展性、可应用型。原来只是机械、刚性、结构性的数据，现在已经灵活半结构化的数据。我们讲得是数据结构、数据架构里面颠覆性的变化。
现在看一个平台成功的标准也出现了变化，这种标准的变化是现在看到的技术上的变化，是着重讲的。
再深入看一看具体的方面，首先从可扩展性方面，系统怎么样通过演变解决这两个要求，很重要的要求是有一个简单的解决方案来解决复杂的问题，或者简单的方法解决复杂的问题。怎么解决可扩展性呢？我们要有这样一套系统能够处理PD级的数据，每秒操作达到百万级，这也是我们所面临的问题，是可扩展性的要求。简单的方法可以采用分片方法，是很多架构所采用的分而治之的方法。可以把数据问题分成块，不放在同一个系统上，分成几个分片，这是一个很基本的理念，这种方法是所有系统当中所通用的构想，所以接到系统的时候，最核心的一点就是要用分片的设想。
简单的概念，在深入思考的话，有一些其他的复杂问题解决。比如说，一个很基本的分片问题，怎么样把某一条记录导入到不同的分片当中。很多的功能，比如说应该放到某一个分片上，怎么样快速把这条记录放在合适的记录上，确保可用是安全存放的，有很多问题。我们有各种机制解决引导的问题，用的一致性的散列、映射表也来自于这些方法。其他也有一些应用，比如说一条记录一半放在一边分片，一半放在另外分片，怎么解决？是分布式的传送问题。很多系统以前是分别的传送，来储存不同部分，怎么确保到达不同的系统呢？今天的系统要有可伸缩性、可扩展性，要用非常高度的简化方法来处理问题。简单的问题就是把记录的两个部分单独的看作独立的两块。这部分记录独立的看作一个部分放入某一个分片，进入这样的分类，简化了数据的分类，存储就加以简化，分片的处理把数据分成不同的部分，分到不同的分片上单独作为一个独立的部分看待。
另外一个复杂的问题，在分片当中，如果有一个分片坏了，这时有一条新的记录，记录往哪放？分片机坏了，不知道往哪放怎么办？如果一个分片坏了当然可以放到其他分片上，可用上减少，并不是减少到零，只是其中一部分坏了而已。如果整个架构坏了就完蛋了，是其中一块坏了。我们要用很好的方法，就算是一个分片失效了，也要用到该用的分片机上。我们做不同的副本，把分片进行不同副本的存放。有一套记录，两套副本，上帝保佑不要三片全坏就行了。通过复制来解决问题，但是需要有多少个副本呢？数据进来之后应该在副本当中复制多少次呢？要确保记录安全的话，什么时候要重建一个副本呢？或者一个副本失效了，要建立另外一套副本，怎么把记录传送到新的副本当中呢？这里有很多重点，用复制的方法解决问题。同时，这个过程带来新的问题。所以我们应该在系统构建过程中一体化进行考虑。
以前系统往往是在事后考虑问题，现在在系统构建过程中就要设想到这些问题，在技术当中加以解决，这是内在的设计。这里看到很多不同种类的方法解决，有些用一致性的散列或者在一些零片上进行复制或者恢复，当然有不同方案解决的问题，可以用单一的映射表来解决。解决的方法是多种多样的，包括怎么样从一套副本恢复到另一个副本当中。这也是不同架构师的不同方法。但是最基本的一点是设想和思维是一样的，最基本的方法是要加以简化，按照这种思路来设计不同解决方法来解决不同问题。
为什么我称是颠覆式的发展，因为关注点不同，90年代是单片的效能和绩效，比如说IO结构做得最好，怎么减少IO的传送，怎么样设计出一些更加对缓存敏感的算法，这是90年代在系统设计的时候关注的重点，2000年以后有了颠覆性的变化。最基本的角度是考虑可扩展性、可用性，涉及到分片和复制。这也是我们讲到为什么是一种颠覆性的变革。
我们讲得第二个层面的变化是柔性数据、灵活性以及半结构化。我们解决柔性数据的问题在哪呢？其中一个是我们的数据库并不只是记录和表格，有些数据我们可能是优化专门存放表格、数据和记录的，但是实际上还要考虑这个应用程序到底怎么样构建的。可能大家听过短跑模式，不会坐下来整个架构、整个系统，想到所有的数据、所有的构思再写应用程序，今天写应用程序非常快，快速变化，得到反馈马上调整改变，这个应用程序是不断改变的过程，我们做一些短跑式的模式，使得整个架构、记录的结构不能固定下来，固定下来不能灵活的调整程序，我们希望应用程序变化的时候，不需要改变数据的结构。这也是我们现在要解决的问题。通过现在一些系统和架构解决根本性的问题。
现在要构建这种记录有很多好处，比如说可以得到优化的计划，可以按照我们应用来优化存储的布局，包括阵列、分类、缩影、查找等。可以实现一些好处，这个系统可以带来最优的选择获取数据。可以优化数据存储，不需要把结构性的数据存放在一块，可以单独存放起来，但是有利有弊，取舍是我们优化的速度、优化了它的性能表现，但是有没有优化应用程序的更新呢？如果应用程序的应用发生了改变，数据库能不能跟的上呢？如果应用程序发生改变，数据表加了一列，结构发生调整，使到我们减速，这也是能够重建的缩影。我们系统要怎么样应对这些挑战，最主要的问题是我们在网上的世界当中，往往在网上操作是很简单的操作，可以设想我们的前提、观点，其实要用我的数据系统，要的很简单，简单的查找、更新，并不需要去过多的担心一些非常复杂的操作，但是大部分的操作是简单操作的话，其实并不需要关注用什么样的执行计划，为什么要去把整个的架构放到某个系统当中，如果有些并不用到这些系统，关注的是应用开发速度。解决这样的诉求，必须要有一种足够的结构性，来满足要求。有足够的结构性来满足快速读取的要求。
简单的方法是把一切的数据分成键和值的关系，所有都围绕这个系统。如果应用程序发生改变，这个也随之对应。就像一个巨大的散列表。我们的操作只需要找到这个键，再看这个键对应的值是多少？再提取出来。只需要优化这一步。听起来很简单，但是要做很多的工作优化这种结构，使到这个结构运行起来很快。比如说有些经过分类的散列表、分类的文件，这样才能优化机制、快速存取、范围查找、快速更新。我过于简化了这个问题。
应用程序希望获得的能力，在更新某一个键的时候，把关联的其他数字一起更新，这是另外一个结构。这个结构要增加一部分，数据系统当中增加标签的一列。不同的系统，有的叫标签，不同的组、不同的名字。在一个服务器当中，可以进行一种关联数据同步的更新。在某几个数字用同一个标签，属于同一类、同一组的更新。最根本的是键、标签和值，这个体系使到我们真正能够响应、优化我们最常用的三种操作：查找、范围查找、更新，这是专门为企业优化的，同时也可以优化应用程序的开发，应用程序开发的时候，也可以应用短跑模式。
刚才讲得这么多对于在线的很需要，但是有没有一些分析性的应用呢？在座的各位知道，我们做分析过程非常复杂，有不同类、不同组、不同分析工具，另外，在数据上做不同数据的转换，才能了解到数据的情况。刚才讲了三类的分析是比较简化，怎么查询、存取等。在简化之余，过程非常复杂，这个方法在分析过程中能不能用得上呢？在分析的时候查询非常复杂，这些工具是否合适？有没有简单的结构解决分析查询的问题。
其实很多应用比较关注这个问题，很多数据系统也关注有没有方法解决分析的问题，其实很简单用简单的技术就可以，就是分类。
接下来看看映射和缩减，可以扩展、可以并行分类。不仅仅把它作为一个处理，而是进行更好的分析，把信息分类出来。比如说拿出一个数据集，可以分成不同的分片和分成，分成三个数据集，有红色、绿色的。我们影射不同的数据集能进行化解。怎么把绿色和红色的剔出来，放在一起。我们可以分类，非常不错。我们的用户可以自己界定所谓的影射函数和化解函数。这样的话对于用户来讲更加灵活了，不仅仅是原来要赞助的特定数据，还可以用其他类型的数据，用影射工具很快影射出来。比如说有图像信息分出来，具体的目标去提取。而且在我们所做的这些工作核心就是我们讲得可以使用并行的分类。这样的话可以把原来复杂的架构变成简单的架构，这种灵活性也是我们现在所要关注的。
除了这些好处之外，还有什么其他优势呢？在数据信息分类之后，出现故障什么问题。比如说分了几个小的数据集，如果出现问题了，怎么办？数据保留下来还是重新再做呢？在一个完全平衡有很多数据的系统里面，重新再做肯定要花很多时间才行。因此在我们的系统里面影射以及化简的过程中，可以随时重启。如果发现影射器里面有些出了问题怎么办？不需要重新启动，只要把有问题的影射器重启就行。在数据分析过程中，不同地方加入了检查点的功能。其实我们的关注在于首先要把结构变得更加简单、更加灵活，而且有更高的可用性。就像系统还原一样，找到有问题的点重新做一下就行了。原来是中间出现小问题就要重新做，现在不用重新做。原来查询系统没有任何检查点的概念。原来我们讲得系统只是去关注性能。更多关注结构才能优化速度。进入21世纪之后，我们使用短跑的模式，不像我们原来所说的看单纯的性能，在开发构造应用程序出现很多的变化。
前面讲到设备的效率和数据的多样性，在演讲一开始就说过。
接下来看看未来的前景怎么样？往哪些方向走？
这个系统里面有一个非常关键的主题，和其他的基础一样，肯定会让我们和以前的技术分道扬镳。但是，在这里发现不能完全各走各的路，还是要把我们发展建立在这个系统之上。现在不仅是新老交替，在新老交替中，还要进一步融合。我们还需要一些旧的SQL，否则无法做影射，还需要一些相应的语言。刚才讲得这些方面已经做了很多工作，有些是用新的语言，很多用旧的语言。怎么将其他组件组合在一起呢？新的应用程序是独立的东西，自己来用非常好、非常不错，但是如何把新的东西和旧的东西加在一起，或者在新的系统上加入一些其他的组件。现在也在关注其他的情况，现在系统刚刚起步，很少一部分使用，慢慢形成主流之后看更多的结合在一起。
一开始讲到了更多关注可用性、可扩展性，效率讲得不多。如果数据越来越大、规模越来越大，效率也非常重要，怎么样能够有更好的、更高效处理大量的数据。比如说银行交易，把钱存在一个账户转到另外一个账户里面。有些人说，他能够做，但是现在情况来讲，很难把你的钱转到另外一个账户。旧的系统里面关注怎么样优化资金传输的效用。旧的系统做得很不错，新的系统无法比肩旧的系统，无法解决。
现在很多路径里面都有图形，像社交网络里面图形，有时候可以做一阶分析，二阶分析和三阶分析怎么传输出去，这是做得不足的，要解决。
新的系统里面有很多需要解决问题，但是有些解决方案已经浮出水面了。比如新的范式、新的操作界面、新的应用。新的系统为大众所接受必须要跨过的桥梁。标准让更多的人所熟知，或者界面更加简单，让一些新的用户轻松的了解到可用之处。
说到这里想再花点时间讲下面这一点。如果要高速人们了解这些信息的情况，把它部署在一键式全包的方法，通过云来做。现在具有很强的可用性，或者可以用虚拟机来操作，但是如果用虚拟机的话，不清楚到底什么时候突然有问题。现在可以通过云端来去做，通过云端来做可以有效减少采用这些部署系统的复杂程度。只要放到云端可以解决所有的问题。当然，说到这些，可以说是任重而道远，有很多的工作要做，尤其是在分析领域。
Apache就在关注这些问题，怎么按需提供系统满足客户的需求。另外，我们该使用什么结构？原来的可以继承下来，通过改进做得更快，可以直接把系统部署在里面做得更快。现在已经做了一些工作，解决了一些小问题，比如说自动扩展、高速缓存等都可以实现改变。我们讲得大数据还有很多东西期待解决。我们要让系统进入主流系统让更多人所接受。比如说分析师、数据使用者了解，需要很多工作做。
我们可以说刚刚起步，未来还有很长的路要走，非常激动人心的时代就是我们看到在整个应用、基础设施、设备方面有很多很大的变化，这些变化反过来也让我们这些系统架构师反思一下过去做得什么，该采用什么变化，改变我们所做得纬度、改变我们品牌与架构成功的标准，不仅看速度、看灵活性，看短跑模式更快部署、怎么应对更加广泛、大量的用户。
在这里总结一下，再次感谢主办方邀请我参加此次峰会，如果大家有问题很乐意回答问题，没有问题的话讲到这里，谢谢各位！
【主持人】由于时间的关系不留提问时间了，接下来是十分钟的短休，十分钟之后由腾讯的汤道生为大家讲一下腾讯开放平台的话题。
#p#
【主持人】汤道生是腾讯的高级执行副总裁，2005年加入腾讯，参与系统架构设计和平台规划的工作，曾担任QQ空间产品部总经理、QQ秀产品部总经理、互联网研发部总经理等职务，致力发展腾讯社交网络服务与增值业务。自2008年10月起担任互联网业务系统研发副总裁、公司副总裁、公司高级副总裁，负责互联网业务系统多项平台产品策略与技术平台研发和运营的管理工作。掌声有请汤道生分享腾讯开放平台设计！
【汤道生】各位嘉宾、各位技术专家，大家早上好！今天负责高兴在这里有这样一个机会跟大家分享腾讯开放平台的一些设计理念，架构设计的想法。我是2005年加入腾讯，一开始是作为一个架构师在腾讯参与了不少前期架构的项目、后台存储等方面，设计系统也有产品。后来从技术人员转向到产品业务方向发展。同时，在这个转型、转变中，把很多以往在技术上的设计理念、设计方法带到业务、带到产品上来，今天我也希望借此机会跟大家分享一下腾讯开放平台设计上跟平时做的系统架构设计有什么相关地方、类似地方，从而延伸通用系统的设计理念的探讨。
据我的理解，系统架构的设计其实很多时候是围绕资源的管理，不管CPU的资源、内存的资源、还是硬盘IO的资源或者在开放平台上推广的资源、用户的资源。这些往往在系统上，不同阶段有不同的稀缺性。系统架构的设计，在允许的时间内、有限的资源内怎么可以建立一个可持续的架构来实现一条可执行的系统，满足用户需求或者解决问题。后面的介绍也会围绕架构设计的主题来探讨到底怎么去管理资源、系统的设计跟开放平台的设计有什么共性的地方。同时，我们发现技术发展经常受到许多经济因素的影响。05年来到腾讯，从美国一个企业软件的公司来到腾讯，有一个特别很深的感受，我记得在美国当年我们做很多的设计优先考虑的是开发人员的效率，怎么把语言不断抽象，提升开发人员的效率。后来我来到腾讯，很不一样的感受是，腾讯会花很多开发人员的力量、很多人优化每一个细节，到很底层的细节。每一台设备去挤出能服务用户服务的量。为什么有这种大的不同考虑？后来自己也深入思考。七八年前国内开发人员的薪酬和成本跟美国薪酬开发人员成本还是有一定的差距，而且腾讯海量的服务，如果在某一台设备效率提升一点点，放大到上千上万的设备上，是更大的节省。我们发现系统架构设计，很多时候离不开经济因素的考虑，不同环境瓶颈不一样，要特别提升的效率可以是不同的情况。
当然，随着技术的进步、硬件设备的发展，不同硬件设备发展的速度也不一样。为什么我们说设计经常是一个动态的考虑，到今天我们也越来越注重开发人员的效率。因为国内开发人员的成本在过去这几年慢慢起来。我想这是一个非常有趣的话题跟角度去思考。在推动腾讯开放平台的过程中，有蛮多的感受。好比一个熟悉的操作系统一样，大家都需要很多资源的管理，不管CPU、内存、硬盘、IO还是开放资源、推广资源，资源有限、要服务的对象到底是系统上的进程，进程有大有小，有很多服务，同时在不同开放类型上有应用、满足不同的需求，也有不同的规模。套作系统上的API可以让我们管理不同的资源，也可以有一些机制做通知的体系，协助不同进程之间的沟通联系。同样我们在开放平台需要把一些资源在一些标准的接口下开放出来，怎么管理应用的沟通，怎么提供用户通知的体系，有很多类似的地方，硬件设备的标准更不用说了。
提到腾讯的开放平台，应该从08、09年的农场说起，当时QQ空间还是一个腾讯服务为主的封闭系统，是一个社交网络。当时看到国外很多的平台，甚至国内也有很多社交网络的平台，都跟着开放API，介入了第三方的应用，我们自己也在不断思考，到底应该怎么做。我们也发现真正要做好一个开放平台，所需要的能力或者所遇到的挑战还蛮多的。一开始尝试介入了农场来到平台，在跟第三方合作的过程中，发现服务海量的用户所需要的能力，对于架构上的要求还蛮高的。所以在发放使用或者尝试体验产品过程中怎么去放量。发现放得太快系统顶不住，服务停了，我们有建立怎么防雪崩的机制。我们设计各种各样的模拟器、外挂，又把很多经验带给第三方使用。把很多的数据分析、使用分析，怎么判断模拟外挂的行为能够开放出来给第三方使用。当然，数据的可靠性非常重要，我们做所有的事情、目的都是希望为用户提供更好的服务，让大家玩的开心、使用的放心。所以，怎么保障数据的可靠性，腾讯原来很多基础服务，对于存储这方面特别有高的要求，多份备份，多异地IDC的部署。怎么把这种能力更好的开放出来，而不是说需要每个开发商投入很大的精力做到多点分布，信息同步等一定要求的设计。怎么梳理内部的网络？
我记得当年我们做农场，要在两三个月内，从几十台的服务器，扩展到几千台的服务器，短时间内的扩容，就算我们想怎么去坎服务器，安装五千台服务器的规模，对于很多开发商是一个大的、高的要求。同时在增加设备的过程中，我们自己的网络是分布在不同的城市，有不同的机房。一开始设备在增长的过程中，不同的IDC里面找资源，先把压力顶住，再逐步优化，后来发现这种过于分散的设备资源，对于外网的压力也非常高。导致我们后来发现非常频繁访问、数据量不多、次数很多，高峰期每秒几十万次的请求，怎么样让内网架构支撑数据流量，也花了很多的工夫和工作。
我们发现要真正做好一个开放平台，要了解开发商有什么需求？不仅仅把API开放出来就完事。我们发现真正要提供稳定的服务给到用户，帮助开发商在海量用户的情况下，怎么服务好大家，是一个非常巨大的系统工程，也是为什么我们在开放平台的项目中，经常会说开放需要能力，也是这个原因。
怎么接触用户的场景，也是开发者的需要，提供安全稳定的环境，有一整套原来服务内部的云服务体系，也逐步开放出来，给到第三方的开发商使用，怎么建立很好的推广营销的渠道，逐步把精准的社交广告服务提供出来，让应用开发商接入平台，有一整套机制定向找合适他们服务的用户。当然，整个开放平台是一个商业的合作，也需要可持续的商业模式，腾讯这么多年所积累的支付体系，Q币支付体系，设计好分成规则让大家从中获得双赢。我们在整个开放平台的设计里面总结了五个非常重要的要点，我后面也会根据某个点展开，保证设计标准规范、确保规范的执行、保障数据的安全、设定资源分配规则、建立服务体系。
开放意味着标准、规范，有标准才能降低开发的门槛。欢迎大家自由常识，规范保障了用户的利益，保持公平的竞争。原来这里有一句话叫“整个开放平台最重要的意义是在于怎么让业界的合作能够开展起来共赢”，这是非常重要的环节。在很多其他的领域，手机、安卓作为开放的操作系统，还有传统PC的产业链、API的标准，会看到很多行业内的开发商，就是基于这些标准能够各自去发展，找到创新的机会。
怎么确保规范的执行？这非常重要，如果定了规范但不执行，等于没有规范，而且用户的利益、用户的需求是最重要的，在我们来看，开放只是一个手段，不是一个目的。目的还是回归到到底怎么提供用户最好的服务，多元化的应用。所以在整个规范的执行上，要充分考虑用户的利益，而且要保持整个生态上多个应用有一个公平竞争的环境，怎么提供运营数据的监控能够让我们极早发现应用运营商所出现的问题，以及告诉开发商及时去修正，这些都是怎么确保规范执行需要投入很多精力的地方。
保障数据安全，保障用户的利益。怎么确保用户的隐私得到保障？原来我们做开放的时候，经常遇到媒体的挑战，要怎样开放才算是真开放？其实这是非常片面的看法，刚才也提到，最重要其实是用户需要什么，或者用户在于什么？原来QQ的关系链是基于用户聊天的场景，有很强的保护，是不公开的信息，连好友都不能知道，我的QQ关系链里面有谁、什么人。如果我们随意的把用户这么重视、有这么高隐私性的信息公开出来给到第三方任意去用，这是会带来不可想象的后果。所以在整个过程中我们非常敏感、也非常有意识的怎么确保用户的隐私、确保用户的数据不要丢失。刚才提到的防外挂、防垃圾广告，都是最终在确保用户的体验。
设定资源分配的规则。前一阵子，在我们行业内，有一个电商平台的公司，出了比较多的媒体负面报道，也是围绕在资源分配上管理的问题。在开放平台内有大量的资源，这些资源往往都会给开发商带来巨大的利益，怎样去设计一套自动化的系统去分配，而不是依靠人工的干扰，这是非常重要的一个话题，等于我们的操作系统。难道每一个进程用什么资源都必须要运维人员主动设置，不停去调整才能达到最好的效果或者最高的效率吗？不是。我们建立的生态是完整的生态，必须能够调动开发商的积极性，而且给有能力开发商获得更好、更低的资源，才能把生态体系做得最好，有效率的发挥这些资源使用。
所以，怎么去设计一套没有太多人工干扰、人工运营的资源分配体系，也是我们做系统设计经常要考虑的地方，怎么去避免资源被垄断？在开放平台，当你有好的应用或者成功的应用，获取了大量的用户，是不是代表了开发商做下一款的应用是不是有同样的质量？很难说。我们不想因为一款应用的成功而变成为某一家开发商拿一些资源去导入其他的应用，甚至说把这些资源，少量的开发商垄断起来。这样对于创业者，对于中小开发商创新的机会有一定的影响。所以，在整个开放平台的设计理念，不管是分成的体系还是其他，绝对往中小企业倾斜。其实跟操作系统的资源分配理念有一定的类似，怎么避免本身相对比较轻的应用，需要资源的时候用上，而不是被一两个跑偏的把所有资源占用住，这里也有很多可以借鉴的地方。
资源成本的透明，怎么避免滥用。在早期做开放平台的时候，内部对于系统设备的使用成本计算还没有很好的体系，早期我们把这些成本都算到收入分成的体系里面。导致开发者对于资源的使用效率不太敏感。反正我能赚多少都是按分成比例计算的，用多少资源都是腾讯来承担的成本。所以导致系统资源的使用效率偏低，而且效率偏低不仅仅是浪费，甚至很多时候是影响性能、影响了用户体验。所以，我们后来更清晰地意识到必须要把P跟L两部分成本，成本和收入的部分能够区分开，把这些资源的成本，不管是推广的资源也好、设备资源也好、带宽资源也好，透明到开发商，让他们清楚不仅仅要充分的挖掘收入的部分，同时也要考虑怎么在成本的部分有更好的一个平衡。这样就会让腾讯有限地系统资源更好、更有效率的提供到各个开发商以及创业者都一样得到公平的机会。
建立一套服务体系，说白了就是怎么帮开发者成功？我们有各种各样的培训文档、系统，帮助开发者监控整套应用服务的运营体系，甚至还有推广。在PC年代我们做windows的应用都需要辅助开发商能够更有效率的开发这个应用。但是在开放平台，我们不仅仅是载帮助开发商去做软件，更重要的是提供服务，在互联网时代，服务是更直接能够接触到用户，是一个全方位体验的服务体系。怎么提供服务的twos（音）？需要一整套的服务体系，也是我们帮助开发商成功的工具。当然，开发商在这个开放平台上，不仅仅建立应用，接受稳定的服务，还需要推广营销的资源才能帮他们达到成功。
广告体系，怎么应用好友之间的传播，来帮助开发商的传播，把推广的ROI继续放大。我们看到很多不同的应用，比如说QQ农场，它的成功并不是到处打广告，而是很多通过自己邀请好友来玩，通过原来的腾讯所拥有的通讯体系、通知体系来初达用户，这是零成本的。怎么建立应用，可以在服务体系协助开发商成功的一个非常重要的内容。
我们其实是希望能够通过开放平台，建立一个健康的行业合作的生态链，而给到用户多元化的应用，能够给到广大的QQ用户有更多的选择。
当然，怎么维持一种长期持续的服务，这里有必须要有一个商业模式的支持。早期看到的、现在看到的很多游戏，有一个比较明确的商业模式，已经在开放平台上获得非常好的成绩。但同时下一步要想的是怎么帮非游戏类的应用找到它的商业模式。比如电商，如果通过这个开放平台带动电商的销售，相信很多的电商服务也很愿意给重点的应用分享收入，所以腾讯会针对不同的垂直领域思考，怎么为不同的垂直领域建立健康的商业模式。优秀可能跑得通，有些跑不通，我们无法逆转原来跑不通的服务在开放平台上一定能通。这也是跟开发商、跟业界一起探索的机会。怎么提高用户的能力，提升ROI，数据驱动自主优化，怎么让数据成为一个开发商各自能够使用的工具来不断完善他们的服务。
腾讯一个角色来承担这么多开发商的优化以及改善服务的工作，所以最有效的是给到大家最详细的数据，在不同环节不管是流程率还是营销的效率等各个方面来帮助开发商意识到在服务运营商的一些问题。
我在腾讯有一段时间抓研发质量、性能问题的工作比较多。当时有些产品比较慢，找团队开发的同事沟通这个问题。开发人员可能说因为某一段时间抖动，没关系，就把我打发掉了。我当时也在思考，怎么把团队里面这么多的开发人员对于性能、对于服务稳定的关注调动起来，后来发现最有效的方法就是拿数据说话，建立整套的体系，让全天每一个时间的性能、接口都受到监控，而且到了第二天的早上把每个接口有超过1%的请求，超过某个指标的话，会标红，发一个邮件会看到，甚至开发人员跟负责的KPI绑定，有标红在上面自然意识到需要重视而且要持续关注的地方，不再需要有人去找某个开发说，你看看到底是什么问题，开发可能说已经重构了某个部分，放心已经搞定了。不再是单点的处理工作。
对于开放平台整个服务体系的建设也一样，希望提供最完善的数据，能够驱动大家发现问题优化服务。
在整个开放平台的设计上，我们考虑很多跟做系统设计有很多类似的地方。简单说一下腾讯开放平台的成绩，我们有大概六万个已经上线注册的应用，多家月分成超过一千万，甚至超过两千万的，在服务体系里面看到各种各样的尝试，有些让我们非常高兴地看到很多非常创新的应用，非常公益的应用，有学车考试的应用。这个体系给开发商新的机会创造了很多成功的创业者，后面我们也希望发展很多非游戏的应用。今天开发商遇到的挑战很大程度是在于怎么从非常成功的游戏垂直领域扩散到更多的应用，这是今天腾讯开放平台团队不断思考到底要怎样调整规则，不管是商业模式分成的规则，或者本身应用的能做什么、不能做什么，这些都有挺多的考虑和沟通。
最后，我用马化腾先生曾经在腾讯开放平台启动的时候说过一句话结束：“腾讯过去一直在思考提供在线一体化的服务给到用户做最好的体验，但今天我们发现仅仅腾讯的一个力量是不足的，所以我们希望能够建立一个完善的行业生态链，欢迎众多的开发商跟我们一起提供最好的用户体验，能够在原来关注怎么种一棵树到现在关注怎么寻找整个生态，培养出一片非常茂盛的树林”。
希望开放平台跟大家一起成长，谢谢大家！
大家有没有什么提问，可以提问。
【主持人】很感谢您的分享，我感觉刚才分享的不但适用于腾讯的平台，基本上所有开放平台点都靠上了。要做很好的平台要做到PPT里面列的点。我比较感兴趣的是腾讯做开放平台的时候有没有像facebook、百度等做过一些比较，或者腾讯开放平台不同的点在哪里？
还有一个问题是，腾讯的开放平台的目的是复制的路还是走另外一条不同的道路呢？
【汤道生】腾讯的开放平台对外公布相对来说比较晚的，外面Facebook也好、ipad也好，他们开放平台已经跑了一段时间，思考过程中肯定有借鉴其他开放平台的做法，同时我们也清楚国内的产业毕竟跟产业链、行业的发展，跟国外的行业发展不太一样。所以我们在整个开放平台的设计，有很多针对本地情况的考虑，尽量避免看到在其他平台所出现的问题。
刚才我提到在整个分成策略、服务体系构建细节上的考虑，很大程度去倾斜于中小的创业者，确保少的应用开发商分到分成比例，比大的应用更高。比如说在十万以下月分成的收入，扣掉基本的渠道成本，100%是给到小应用开发商。在其他的开放平台，一般是统一的分成比例，有意的希望培育小的开发商应用，有一个更好的生存环境和发展的支持。
另一方面，我们是全球最多互联网用户的国家，而且这些用户集再一个时区，代表用户给系统压力。成功做出一款非常受欢迎的游戏时，国内互联网产业的发展相对其他国家还是比较短，我们架构师能力的积累，很多创业者 刚大学毕业已经去尝试，他们这方面系统架构的经验相对来说没这么丰富。我们考虑一整套的体系，如果开发商需要云服务，我们也提供这种云服务基础的能力，充分去利用腾讯已有的多个城市的IDC接入点，伸缩性很强的资源支撑或者多年内部的监控体系、运营体系、性能监控、设备资源使用情况监控都要开放出来。这些所考虑的点跟面往往要比其他的开放平台更多。这应该是腾讯开放平台和其他平台的区别。
【主持人】由于时间的关系，用更加有效的方式，通过腾讯微博进行交流。腾讯微博“会飞的鱼”提了一个问题，你认为最大的难点是在架构设计里面吗？
【汤道生】最大的难点是深度认识用户需求点在哪里？满足这些需求资源瓶颈在哪？往往一个成功的架构师对于产品的需要、用户的需要充分理解。同时对用户的行为充分理解。这样才能准确的判断在你手上各种资源中哪方面最可能成为你的瓶颈。所以在架构设计里面会特别去照顾到不要让可能成为瓶颈的资源有一个重组的储备。
【主持人】请汤总对国内几大开放平台都有那些各自鲜明的特点？可以做一个点评。
【汤道生】国内几大平台侧重点都不一样，是平台的建设应用平台所习惯、所期待的服务，对于不同的开放平台有不同的要求。比如百度更倾向怎么结合搜索，通过流量的入口来带动它的应用体系。在阿里系的淘宝也好或者相关电商平台，它们整个生态平台更侧重于服务好电商的卖家。我想不同的开放平台都有它的发展方向。
【主持人】腾讯如何思考开放平台战略的？这是一个比较艰难的决定，还是水到渠成的需要，背后的动因是什么？
【汤道生】这不是一个艰难的决定，产品发展到某一个阶段，开放是必然的。之前在其他的演讲里面有看产品发展的过程，首先抓某一个功能需求点的产品，发现用户喜欢这个产品，会逐步丰富产品变成多功能的产品。然后发现自己产品的领域已经不足以满足用户更多的需求，你会拓展到其他的功能点上，让你需要合作，就会找一些合作伙伴。从产品发展成为平台。
当用户非常频繁使用你的平台，能够满足更多的需求，自身少量的合作伙伴不能满足自然就要开放，能够调动更大行业有能力的人来参与这样一个平台的建设。一步步发展，我觉得开放是一个必然的过程，但是在内部也艰难的部分，毕竟腾讯原来也有很多应用的开发，转型的过程怎么去做内部协调。怎么在公司内部上下游一个统一的认识，花了不少的工作去做这个转型。
【主持人】由于时间的关系，汤道生的演讲到此结束！
#p#
【主持人】接下来让我们用热烈的掌声有请王宏！
【主持人（王宏）】接下来请四位嘉宾：
腾讯高级副总裁汤道生；
去哪儿CTO吴永强；
百度技术委员会主席廖若雪；
土豆网产品技术副总裁黄冬。
第一个问题在社区中讨论非常多、非常热烈，回答各种各样。这个问题是你们现在还写代码吗？
【廖若雪】还写一些。
【黄冬】个人爱好，写点。
【主持人（王宏）】你们觉得架构师这个角色应该写代码吗？
【廖若雪】我觉得需要。架构师如果不是持续写代码、不是持续对技术的东西做一些了解，知识会过时，会形成错误的概念、错误的方法论证。
【黄冬】我觉得必须写，而且更重要的是要看一些代码，理解他们怎么工作或者怎么做一些事情，这样才能真正理解自己架构的特性和应用是不是正确的。
【主持人（王宏）】从两位的回答中，架构师到一定级别，可能没有那么多时间写代码，但是一定要完成的是对自己系统了解、对底层深入的了解，这样在系统运营中有一些情况和问题能够快速解决这些问题，这是架构师最基本的能力。
架构师你觉得应该有什么样的最基本能力？
【汤道生】对于数据的敏感。不管写不写代码，看代码一定要的，很多时候架构一定是框架，框架里面填什么内容、细节怎么实现，其实是非常重要的。但是作为一个架构师，时间分配很多时候经常要了解细节，而且要做出判断，细节的体现很多时候不一定通过代码，需要更客观地去看一些数据，而且要考虑架构不仅仅是程序的架构，可以是网络的架构，可以是设备资源的独特性所带来的对于应用有不同的要求。最终我觉得是要深度了解整个服务体系在关键点上的数据表现充分的抓取分析，这是作为一个架构师非常重要的数据。
【吴永强】我觉得架构师第一步还是思维能力，重要的难题是鉴定问题。如果问题不清楚，之后所做的工作都是错的。
第二，基本方法论，需要抽象和简化，比较难，怎么样把抽象的问题变成简单的问题。
【主持人（王宏）】从几位回答过程中不难看出，架构师要有敏锐的观察力，对系统各个点到面上升到框架结构，之后不同的发展才有不同的路线问题。
这些基本素质以外相对已经做到CTO的级别，怎么样发觉一位好的架构师，看到闪亮点，放到合适的问题，这是很多架构师需要了解怎么看人的。
【黄冬】这个问题问的很尖锐，我觉得有几点很重要：
第一，如果好的架构师，应该在代码的编写，业务的理解、整个系统的运行以及运行之后整个项目的运营商要充分了解。所以一个好的架构师的基础是在四种工作上有多的经验。如果没有这个基础要素，做事情的时候有些判断更多是夺来品，不是自己思考的。
第二，要有敏锐的观察力，在这四种工作上或多或少产生好的抽象、好的运行结果。架构师还有一个特性，当一件事情难以解决的时候，承担起一个责任，一个判断、观察，并且勇于承担责任，产生好结果的循环要发现。有了基础的经验、素质外加一些特别事情的表现，是我认为有基础成为架构师的一个判断。当然，还有一个重要的话题是，也许在某一点上有了亮点之后，需要给它在另外几个层面一些培养的机会。我曾经让一个架构师从做开发到学习网络和面对整个系统的运营到业务层面，花了将近四年的时间逐一去经历，慢慢去成长。
【廖若雪】我再补充两点：第一，基础能力和学习能力。尤其是后期，很难说是去花很多精力补充非常基础的弱点。成功的架构师在自己相关领域的基础能力比较强。学习能力，怎么把握新知识要点的地方。
第二，架构师面临的问题和所有资源都非常清晰的了解。我们常说，这个事情是不是能够说清楚，说清楚说起来很简单，但是对很多问题的细节、方方面面，抓住问题的关键点都需要提出很高的要求，是不是能够在别人问你问题的时候，尤其是你看到问题，后续怎么补充、补足，使得认识加深，找到资源分配，给到方案。
第三，对于架构师来说，应该有一些追求。追求就是对架构上面的一种简单或者美的追求。不是把这事做完了能够满足目标就OK了，希望能够做出更好的东西，更美、更简单的东西。这是我的几点感受。
【吴永强】我只补充一点，我觉得架构上有一个很重要的是能不能应对变化。互联网公司大公司比较稳定，小公司变化非常多，而且系统的性能跟着流量、业务的复杂度发生变化，有没有办法自己突破设定很多结构性的东西，否则没办法跟上公司的发展。
【汤道生】几位专家把要点都说了，我非常认同学习能力很重要。架构师放在不同场景、不同领域能够很快速的抓到关键点，学习到新的领域，是一个基本的数值。如果在这样的基础下有机会在不同的岗位提炼一些经验、沉淀一些经验。在开发、运营、网络各个方面有机会积累的话，这个人的视野、看问题的广度会有一个更好的基础。
对于用户需求的了解，架构师的“架构”只是一个命词，是一个手段。架构是用来解决问题的，反过来说是解决问题的能力。我们看到有不少的架构师或者技术人员发展到一定的阶段遇到的瓶颈，是手上架构的能力，对于实际要解决的问题、目的有点远，脱离了。最后不理解用户的需求，或者不够充分的掌握服务要达到什么目的。很难通过架构的设计达到好的结果，我觉得这一点是一个架构师在个人发展过程不断提升的地方。
【主持人（王宏）】听了几位对架构师的要求做一个总结，架构师发展而来多数是程序员，以前在做程序员的时候做得是某一个点、某一块的功能开发，要上升到一个前瞻性、系统化。还有一个，一定要有远瞻性。
几位都提到一定要了解系统运营中实际的一些问题，要落地、接地气，不单单在技术层面上探讨所谓的深度、复杂性就可以了，一定要了解到自己系统运营的特色，这一点蛮有意思的。
【汤道生】落地就是通过不同的岗位上解决、提问题，刚才大家都有提到。
【吴永强】软件就是为了解决问题，不解决问题就没有价值，每个工程师都应该有这个概念。
【主持人（王宏）】原来我是作为工程，需求很明确，各方面需求来自设计部门、产品部门、运营部门，跟他们的需求很近。做到架构出现一个问题，我的需求太多、太远，导致试点上有些段，朝着某些方面深入下去，开始脱离了基本的业务需求，脱离业务线。若雪深有体会。
【廖若雪】我们做架构要解决实际问题，不是解决漂亮的问题。我们需求分析能力非常重要，如何才能把需求看东西，给出一个方案。这里有一个问题有一点感受。很多人说需求看不清楚怎么办。有时候需要根据实际情况，确实要看你的经验。看不到问题的时候，看架构师本身的潜在性能。是不是能够比别人看得更远一点，这就是核心的问题。
【黄冬】我经历过很多架构，单纯从视频网站的架构，自己经历有三个，土豆网的视频架构截然不同。反过来讲，截然不同的架构由一个架构师设计出来的时候，一定受到很多的挑战。一个优秀的架构师设计这个架构的时候，一定会遵从某一个甚至几个最需要解决的业务需求。但是业务人员也罢、工程师也罢，会不断的挑战。一个好的架构师在设计之初就应该知道如何用一个（K英文）在特定的业务下达到最好。我比较郁闷的是一些架构师会说某某某是怎样做的，我们也这样做，但是一个真正有效的架构师，能够有执行力的架构师，恰巧是把架构尖锐的问题解决好的同时，规避好架构在实际当中用法的问题。
我认为一个好架构的落地是非常艰辛的，整个系统运行过程中看到的数据，用巧妙的方法在不改变架构，不让大量工作废弃的情况下仍然运行良好。
【主持人（王宏）】作为架构师能够把架构上升到美的程度。把架构做得简单，所谓简单是系统结构，思维是简单的。新的系统上线要说服使用，成为一个成功的演说点。说难听点是忽悠，忽悠要基本能力的。当别人提到一个问题，怎么解决他们提出的问题，深刻地考验了一个架构师对系统每一个细节的了解。这里延伸出一个问题，作为一个架构师具备这么多的能力，到底在技术深度上做更多的发展，还是广度上发展。我们要了解各种各样的学科还是只是在一门。像腾讯、淘宝对数据库的基本代码很深入的研究下去，也有人做系统的。
【吴永强】我觉得这个东西跟学习一样的，一个好的人或者比较成功的人一定具备特别好的能力，一个归纳、一个演绎，可以把两点结合起来，广度要有，但是要学会归纳。深度也要有，要学会演绎。操作系统里面如果学的很深，基本上其他的软件结构都能演绎出来。
我认为架构广度和深度都要有。
【黄冬】首先，我认为一个架构师的出发点一定是足够深的深度，如果没有闪光点，没有机会成为一个架构师。所以在一开始的时候一定有深度产生的，也许是一个非常好的DPA，也许是一个非常好的写代码的工程师，也许是对硬件非常精通或者对业务非常精通的人，一定非常深入擅长。但是当他的职业生涯走向架构师，必须放弃往下钻，一定足够广，可以把自己的深度当成业务爱好，不能当成自己的工作。
作为一个好的架构一定是所有的层面都能有所了解，才能综合和抽象，我觉得是分前后期。
【吴永强】我觉得即使做了架构师以后应该在深度上继续深。
【黄冬】所以说是爱好。
【吴永强】我觉得跟爱好无关，是工作上的问题。
【廖若雪】如果不加深深度，广度做不上去，反过来也是一样的。很多是融会贯通的。融会贯通的时候，会发现深度和广度可以转换的。
【黄冬】如果这么讲，他的深度积累是积累下来的，正是因为有广度才转换的。深度是一个爱好，广度发挥大的价值。
【汤道生】这两个是相互帮助的。在某个地方可以转深，解决大的问题只有一个领域的知识不够，自然多方面的了解才能解决。单项考虑广度和深度两者是叠加的。很多时候有一个误区，不是说所有的语言都学一遍就很狂，这不是广度，只是在解决问题上面需要用到的工具。所以我觉得真正广度的体现，还是在于解决问题的时候是否考虑足够全面。甚至说，刚才主持人提到程序员原来很明确给我一堆需求，怎么按照这个需求实现就好了，我觉得那个时候也许离目标稍微远的时候，虽然感觉很明确，因为有人帮你过滤了怎么做，而不是真正了解，到底服务业务用户需要什么，视频服务商用户需要流畅、不卡一堆的要求，但经过很多重的翻译下来到一个开发人员的需求可能是播放器加一个断点重播或者其他的功能。这对于你实际的问题理解不足，可以说这是一个很缺乏对于广度在每一层所需要考虑的问题的广泛了解。
还是要端到端，中间的事情有设备的关系、网络的关系，甚至用户体验的关系，把这些都打通，才是一个架构师所需要的广度。
【主持人（王宏）】这个问题下面有很多人也有不同的想法。再讨论下去有各种各样的想法，稍微有一个暂停。
架构师虽然是统称，架构师有分类吗？
【黄冬】我觉得架构师在我所看到的层面，横向有几个不同层面：
第一，好的代码。现在知道很多好的框架，本身就是一个良好的架构。在代码、工程师的层面也是有架构设计和一些良好的架构，我们可以看到。
第二，结合整个系统的运行，会不会有良好的架构。比如（英文）结合系统资源、结合计算机处理能力。
第三，产品。如何给用户提供好的服务。
再往上走甚至可以提升到产业链、行业、商业模式的架构。比如说腾讯的开放平台，截然不同的架构，解决什么样的问题、该不该这样做。
纵向走的话，我认识几个非常资深的信息架构，只是做信息分类，有一个图片做图片库，怎么给图片建立一套体系结构，管这个人叫首席信息架构设计师。包括图书馆的分类也是截然不同的，信息架构是截然不同的东西，还包括硬件的架构，真的体现不同的行业不同的职位。
【主持人（王宏）】若雪是技术委员会的主席，看过很多架构师，怎么看？
【廖若雪】这里有一个核心的问题，定义什么是架构师。从能力上讲，很多架构师很像，他们的侧重点、相对的领域或者在架构层面上解决问题的思路和方法都有不同的地方。
从计算机领域来看，架构师从分类来看并不是很好的纬度，更多的是侧重点。侧重点是不是分成几类，在我看来并不是这样的，他们之间可以看到很好的作为策略的架构师。他们能力可以转换的。
【主持人（王宏）】这个问题只是跟上面一个进行呼应。在我看来，架构师的基础能力，最基础的算法，数据与数据结构、网络、TCB的东西，反而是架构师最根本、最需要掌握的知识，之后对这个知识进行总结、归纳，上升到高度之后看到全面才能有一定的深入了解。还要有一定的远瞻性，对公司未来的发展方向都要了解。
接下来把时间交给大家。
【提问】刚才谈了很多架构师优秀的地方，我比较关心的，比如说我是一个工程，定了这样的方向，如何培养自己的能力？如何一点点向这个方向走？架构师有一个机会的成分给你，公司给你环境，如何寻找这样的环境和抓住这个机会。
【黄冬】捉所以说横向和纵向都有不同领域，现在作为一名工程师，最需要做的事情就是仔细去琢磨讨论的代码。
什么叫架构？我自己是这么认为的，一个能够随着时间的变化和业务的变化不去发生改变的稳定的结构，称之为架构。一个架构师一定是对这样的东西加以设计、灵活运用，让这样的结构不轻易改变，能够持久运行做这样的设计来。
如果自己是一个程序员，每切到一个需求时，往前往左右想一步，看自己的代码能够运行多久，业务和时间的变化都不会产生影响。越能多写这样的代码，就证明在培养这样的能力。
第二，当自己所做出来东西越来越多的时候，看深度上能不能再深一些的同时，看自己能不能再做一些截然不同的东西。包括系统、运营的东西。
最后，有没有一个公司、环境多理解业务，能够让自己运用网络、系统代码和业务自己所设计的东西进行运行。这是一个听起来很漫长的过程，是一个有心人自己培养自己的过程。
【主持人（王宏）】这个问题挺有意思，架构的正面讲了，可以聊一聊架构的反面。架构的反面讲一天一夜都讲不完，失败是成功之母。
【提问】架构师和软件开发主管有时候意见不一致，架构师做交流的时候还是挺困难的。架构师成为独立的架构师也是一个发展方向。对于自己要不要成为软件开发主管兼架构师，还是独立的架构师？发展方向方面有什么建议？
【汤道生】这是管理问题，不是架构的问题了。程序经理也好、项目经理也好、架构师也好，纯粹说哪个级别或者哪个职位，太不科学了。我原来在不同岗位扮演过不同角色，最健康的合作方式还是拿数据说话，或者对于实际用户的行为能够有好的判断，真的能讲通为什么这个好、为什么不好。为什么这个阶段好，等到下一个阶段采取另外一个策略。
我记得有一次我们团队在讨论一个face的问题，300个好友怎么更新，300人不同的好友，看到的视图不一样。到底存储系统应该怎么设计才合理？有程序经理说，facebook是这样做，把更新发到一个存储来做。架构师说看着别人很稳定的，只是一个系统的设计，不一定是最优的。我们去分析到底用户的行为是怎样的？或者最终存储放什么在内存、放什么在硬盘。放在内存的信息最好是少量而且是不变的。最后想了另外一种方式，把个人的更新落地到存储，但是能够被内存存起来。这样的话只有更新的人落地，后来发现架构师通过实际用户的行为、实际的资源（英文）更准确的判断，用更少的IO，充分利用内存的特征来解决这个问题。最后我们发现我们的设计是跟原来facebook开源的不一样，但是实际的结果更符合我们的需求。那个人抓住重点，充分理解系统资源，最后按照数据来决定。
【主持人（王宏）】架构师到底需不需要具备人员管理能力？
【黄冬】手里没枪怎么能抢得了政权呢？
【廖若雪】跟各个公司的风格和管理相关的，可以不要。
【吴永强】管理层面太虚幻了，是实际的管理还是对人影响力。
【主持人（王宏）】随便你定义。
【吴永强】那就很广了。
【汤道生】如果你有能力，自然会得到。
【提问】性格决定命运，现在又提倡情商比智商更重要。性格方面有什么地方能够比较适合做架构师？
【汤道生】两个都要。
【吴永强】智商是必须的，智商如果高到一定程度，情商可以不要了。
【廖若雪】智商是一个必要条件。情商会更加有助于你成功，任何事情都是这样的，不光是做架构师。
【黄冬】我认为做架构师的特点就是智商一定要高，作为一个公司的管理必须情商高。
【主持人（王宏）】一个小时很快就过去了，聊到后面越来越尽兴，由于时间关系到此结束，非常谢谢大家！
