以下为2012年全球架构师峰会ArchSummit第二天早上的文字实录。
【主持人】大家早上好！我叫郑柯，今天上午有三个主题演讲：
第一，Pinterest的架构衍变过程。
第二，网络架构疑难杂症解析。
第三，郁闷的架构师。
第一，Pinterest是继Facebook之后成长最快的社交平台，两位讲师Marty Weiner、Evrhet Milam都是Pinterest的工程师，在Pinterest整个架构里面起到很大的作用，有相应的体验教训分享，跟大家分享现在遇到的问题以及未来的规划。
第二，由ChinaNetCloud创始人兼CEO、CTO，Steve Mushero带来的疑难杂症解析。现在中国网络环境在硬件基础设施层面上某些方面可能是退步了，Steve Mushero给我们讲一讲有哪些问题可以解决，做好不同的规划。包括不同的地区怎么做、不同行业的特点需求不一样、单线多线的接入也是谈到的东西。还有怎么利用国外的服务做国内的网站。
第三，Simon Brown是独立的软件工程师，创了Coding the Architecture，标题是郁闷的架构师，更多从思维方式的角度讲，作为一个架构师是怎样的要求或者应该怎么思考问题。他的要点，架构师需不需要敏捷起来呢？浮现式设计的真正意义是什么？做软件有什么意义？这些意义对世界赖讲会怎样？
今天下午有三场专题，第一个是海量数据之快准狠，主持人友友天宇COO张矩，接下来由张矩来跟大家介绍！
【张矩】大概在一个月以前我看到了一个非常震惊的地图，最近160年以来所有地震分布的图，用点的颜色和大小表示地震的强度以及造成的破坏的程度。当这张地图呈现在你面前的时候，你会非常清晰地看得出来，地震的分布和地球地块的形状有非常高的吻合程度，毋庸置疑证明了绝大多数地震的发生由地壳运动冲撞导致的。有时候有很多的规律和研究的成果，通过数据的量很清晰的呈现出来。
大数据的课题大家不陌生，而且听说过很多次，大数据从数据产生的量变到质变，给大家带来崭新的问题。计算机科学在大数据量成长到一定程度后变成一个全新的领域。
今天下午请到了业内非常前沿的四位从业者为大家介绍关于大数据存储处理上崭新的思路，相信会给大家带来很多的惊喜。
我觉得大数据这件事，可能在一定程度上是技术上的挑战，我更希望看到、更相信大数据的发展为各个行业打开一扇更高更多的可能性。相信在座的很多都是大数据从业者，坚信我们的工作有一天对整个社会有非常大的推动作用。有可能利用数据的量发现现在不能治愈疾病的治愈办法，有可能更有效地避免经济危机或者战争。或者说没有找到更好的办法规划星球的发展。正是这些可能性是促使大家在这么炎热的季节跑到这么炎热的城市参加这么热门的讨论。
下面我介绍一下今天下午四位演讲者的情况。
第一，来自EMC研究院的陶隽，介绍MapReduce在数据处理的应用，深度分析如何处理好数据的使用。
第二，雅虎研究院的资深架构师韩轶平带来的基于Hadoop的海量数据工作流平台。
第三个是Linkedin高级工程师Lei Gao带来的Linkedin的数据处理架构，从数据总线到消息系统到数据的剖析。
最后压轴的是Pinterest著名社交网站中的工程师，Marty Weiner、Evrhet Milam，他们介绍对于数据库的使用，以及大数据下分片如何做到的。
希望大家踊跃参加，下午见！
【主持人】今天下午第二个专题是移动互联网的案例分享，主持人是腾讯手机游览器后台开发组总监张凯。
【张凯】各位嘉宾、各位朋友、各位行业内的技术牛牛们，大家早上好！刚才上一个主持人说了，非常炎热的城市，欢迎大家到深圳来，我是腾讯无线游览器传输的技术总监张凯，加入腾讯已经有8年时间了，不光看到了移动互联网从2G到3G，甚至到3.5G、4G的发展，同样也看到了在整个行业的发展过程中，全国各地很多的团队、很多的架构师们一起在风生水起的行业里拼搏。如果传统行业30年河东、30年河西，在移动互联网行业就是三年河东、三年河西。这几年看到了安卓的新生、苹果的崛起，也看到了诺基亚的没落。在这样一个行业里会有非常多的机会和挑战。记得09年1月份3G牌照正式发放。从09年4月份，IT时代周刊有一句话说下一座金矿是移动互联网。09年到现在3年半的时间，3年半的时间行业发生了哪些变化，有哪些历程。今天非常有幸邀请到四位架构师做分享：
第一个是大众点评网应用架构师屠毅敏。
第二位是由我来给大家分享一下手机QQ浏览器X架构的历程和演变。
第三位是网易杭州研究院的高级工程师李武先生分享网易移动应用的架构。
最后，由东软集团UniSDP首席架构师、产品运营经理孙广宇为大家分享HTML5的技术以及基于HTML5构建统一的智能设备应用平台。
我们在一号分会场不见不散。
【主持人】第三个专题是系统安全设计面面观，主持人是殷钧钧。
【殷钧钧】架构师们在做架构权取舍的时候，安全性是一个非常让人感到头疼的问题，非常不好的量化，现实中变化非常多，种类非常多，新技术层出不穷，传统的管理方式很难做一个量化。今天下午邀请到两位非常资深的两位安全架构师以及非常资深的黑客。一方面如何满足系统的要求，另一方面如何更好的面对安全威胁，这两个角度做一些分享。下面介绍一下今天下午的演讲嘉宾和主题。
第一位，Coding the Architecture的创始人Simon Brown，演讲的题目是“如何设计安全的架构”，分享过往的架构里面会有怎样的安全考量，面对不同的场景怎么做安全威胁的分析，更好实现安全的架构。
第二位，来自于支付宝团队的苗霖，支付宝要求非常高的线上系统，大家非常好奇如何在设计里面更好保障架构权衡和演变过程中确保安全性。今天下午跟大家分享支付宝的安全交易架构。
第三位，非常有艺术家气质的方小顿，是黑客组织80sec创始人、wooyun漏洞报告平台创始人，江湖人称剑心，今天下午分享的浅谈甲方安全建构建设之道，分享在某著名的互联网企业如何推行他的架构措施的血和泪，有非常多的干货和亮点。
第四位，方兴，是南京瀚海源CEO和创始人，方总的名字年轻一点不太熟悉，往回推个N年在黑客里面鼎鼎大名。方总是独立发现高危级别发现漏洞最多的一个，微软聘去当顾问，现在为很多一线的互联网厂商提供安全资源和服务。今天下午的演讲是“基于安全漏洞的攻防对抗技术”，讲很多现实的东西，出现问题的案例，同时谈到了现在最流行的威胁攻击的方式。
更多干货、更多分享，尽在安全架构专场！安全架构专场，喜欢您来，喜欢您再来！
【主持人】10月份的QCon已经组织了，邀请了谷歌、Facebook工程师过来，欢迎关注，今天上午首先带来的演讲是Pinterest工程师Marty Weiner和Evrhet Milam，大家欢迎！
#p#
【Marty Weiner】大家好！我是Marty Weiner，Pinterest一年之内游览量达到非常惊人的数字，去年是比较年轻的公司，快速的增长，不知道用什么样的技术讲讲战略故事，有很多的选择。Pinterest网上的贴图板让我们组织分享带来灵感的图片，现在看到的是我自己Pinterest的主页，有一些画板，可以贴图。结合了图形和照片，非常特别，不管在什么地方找到图形，比如说一个产品很喜欢，追溯到哪里买的。为什么用户觉得很特别，可以关注他们的画板，关注的时候如果贴一张图，也可以获得这张图。他们贴图我们也会收到。
如果进入数据库的模式，现在看到的是数据的结构，有一个用户有画板，可以贴图，其他的用户自己有自己的画板，另外还有其他一些关系的方法，可以转贴，表示喜欢他的贴图。2011年5月刚刚推出这个网站，很多意义上来说，可以看到我们做了一些设计的功能，那个时候找RockSpace来托管，一个工程师就够了，网站开发我们也不知道开发到哪个阶段，保持灵活，不大量投资。2001年1月，我们的创始人说现在还是处于一个隐身模式，大家没有听过我们的名字。这时稍稍有一点知名度，我们用了Amazon，他们给我们做托管。接下来的的9个月已经忘了睡觉是什么滋味了，加强建设，网站发展太快，每天翻倍，每天有各种失误，我们要保障很多问题，很快问题一发不可收拾。
我们不想看这里有多少的东西，可以感受一下这里有多少的技术、多少复杂性，把PPT所示的技术结合在一起，都有自己微妙的工作方式，每天带来各种头疼、各种麻烦，有三名工程师处理恶梦，因为扩张太快，肯定有问题。我们第一个经验教训是这个系统会有问题的，所以尽量保持简单。
对未来的架构来说，一定要保障我们的架构，我们不想用一些太复杂的技术和方法，希望能够让过程变得简单，比较容易去修改或者维修。
2012年的时候，我们架构不断的演变，这时基本上已经成形了，大量的简化，用了66个MySQL的数据库，这时已经成形了，从这个模式上进行增长，不会有太多的问题。我们有MySQL和Memcache，有6名工程师，也做了分片的服务器。几个月之后，比较接近今天的现状，我们增加了一些设备，但是目前来说架构已经从1月份以来成型固定了，有25名工程师。重点是扩大我们的团队。
Amazon很好用，有很多周边有很多工具帮助管理公司，不想管理也可以做缓存，帮助你做数据库管理。也许在以后我们也可以让Amazon来帮我们做周边的管理。更重要的一点是如果要再做一此第三个原因用Amazon，因为几秒钟之内生成一个实力，发展很快不知道用什么东西，5秒钟形成一个新的实力。缺点是选择比较少，可能就几个设备，就这些选择，比如说26G，那时买不了X60或者更快的选择。但是选择不多也是好处，不需要太多的动心，不需要挑乱眼。
MySQL也是系统的基石，一致的为我们带来很好的表现，26年的历史了，非常成熟，非常多人知道，很喜欢，工程师有自己的经验，我自己也做MySQL，我也经常使用也做管理，很多人是这方面的专家，我也为MySQL编过码，几乎很少有大量数据缺失，这是硬件问题不是软件问题，反应时间可以随着请求率进行增长。有一定的技术到一定的量响应时间是掉下来了。但是MySQL可以随着线性扩张的，对明天有所预见，而且社区非常活跃，搜MySQL肯定有很多东西帮忙，很多公司给支持，而且MySQL是免费的。当然，作为一个小的网页公司，当初的资金有限，用MySQL资金是一个解决条件。
Memcache非常成熟，功能表现非常好，而且很多人喜欢，也知道怎么用，很少有失效和崩溃的时候，而且失效模式非常少。因为比较简单，没有什么可以出错的地方，还有一点非常好，免费，免费谁不喜欢呢？
Redis是新的公司，有自己的一些小玩意，有自己的复制和持续性，而且结构非常好，想进行分类、进行散列都有这个功能。很多功能都可以用得上，而且这还是比较新的公司，但是很多人都非常喜欢它。我在社区里面听过很多人表示好评，也进行大量的使用。我们听了好评声去使用，表现非常好，有一定的失效模式，比MySQL稍微多一点，但至少还是可以的。另外，还是免费。
到底用集群还是分片，我们肯定要调整架构的，网站发展有太多的技术可以进行全自动化的调整。很多人说买了这个设备可以自动的进行分配，如果这个盒子坏了，另外一个盒子能够备用。我们到底是不是真的想要集群呢？后来用分片，发现分片手动性强一点，集群和分片是非常多的选择，对于集群来说，是自动化的数据，数据可以迁移的，可以重新分配装载容量。另外一端是分片，是用手工进行数据的。换句话说，必须要用编码，一定不是自动化的，这是一个决定。数据进入某个分片以后，基本上不再移动了。同时数据进行分解，数据一半放这个片，一半放那个片，每一片有更多的容量分配数据。而且结点之间不了解，不会互相沟通的。
所以，用集群有什么样的好处，我列出了一些例子，比如说像集群的技术。比如说Cassandra、MemBase等可以自动扩展，非常容易设置，5分钟就可以设置了。可以空间分配来，数据有非常高的可用性，均衡而且没有单一的失效点。
如果一切美梦成真的话，什么事都不用干了，但是会有什么事出错呢？如果什么都好的话为什么不用集群呢？做了几年之后还是非常复杂的，而且比较复杂、历史也不长，社区支持也比较少。没有太多人推动这个技术，寻找帮助社区对你的帮助非常有限，现在有这个知识的工程师为数不多。比如说我了解的Clustering的工程师不多。
有时候会觉得非常害怕，原来从0.8到0.3有一点步骤要做，做了又不一定会成功，运气好做好，运气不好突然会失效，我觉得比较不幸的是影响到我们好几次的。首先看我们集群，所有东西都是绿色的，大家很开心，但是突然服务器不行了，一般来说找一个替代的服务器换上去，把所有的东西分到新的服务器。出现什么问题呢？看到里面的服务器每个都使用同样的算法来计算，之前也是前期沟通的，希望服务器有问题和漏洞的话，所有的服务器都有问题，项目沟通的漏洞也会转移到其他的服务器上。
你写的一条比较复杂的代码影响到所有的节点，出现的问题首先包括数据在均衡会失效。很多个盒子，把东西分到不同的盒子里，发现镜头80%停下来，只能取消。另外，所有的节点都有数据的损坏，托管层有漏洞的话会影响下面的成绩。每个漏洞导致每个服务器出现数据损坏。另外，无法有效治愈的错误的平衡。不同的服务器加了90%的数据，剩下1%不到，怎么办呢？可能需要一个技术手动进行分布。另外数据授权的失灵，其中有一个盒子可以说是主本，做一个副本，大概做了80%的时候副本才能决定到底数据从哪来的。副本拿80%的时候，其他觉得80%的副本是主服务器，把信息再拉进来，导致主服务器出现偏移，从而无法进行正确的传输。这些技术发展的时间比较短，现在有些问题让人比较害怕。为什么要做分片的，分片是手动操作的，把数据库分开来增加容量，可以在空间上进行分布，高可用性进行负载均衡。我们放置数据的算法非常简单，写下来之后有一天在进行测试，非常小的算法。我们用很简单的机制来生成ID，下面有请我的搭档Evrhet Milam讲一讲什么时候该做分片，怎么做分片。
【Evrhet Milam】首先，要做分片的话，板式设计、模式设计更加困难，要放对地方才行，等稳定了才能分辨，等太久，转移数据更困难。所以要选择一个合适的时机，把你的数据从一个模式转到另外一个模式。另外，在做分片的时候，设计靠得住的，就像我们有的用户以及图板、贴图等。这就是我们网站的设计，网站设计先确定下来，还要确定后端的架构怎么样。
下面所有的连接和复杂的查询要取消掉。现在很多连接非常麻烦，分片是独立开的数据库，加上复杂的查询不行。加上缓存会好很多。让分片发挥系统的功效。我们的数据库、系统中有很多不同的贴图，贴图放到数据库里面，让不同的分片发挥功效。另外，如果你的网站不断发展、不断增长的话，最好用分片的技术。有些人网站到了一定技术，不用分片，如果量不断增加，用分片比较好。
这是不断迁移不断发展的过程。
先是有一个服务器，有外件、有很多的连接，比如说有一个用户通过连接和贴图连接在一起，把数据进行非正规化做得更快一点。很多数据重复的，我们也做了很多的高速缓存。我们还有读取的仓库，再把数据分片，分成不同功能范围的分片。比如说有一个分片里面专门放用户信息，有些是专门放贴图的，还有专门放客户用户的评论的。
我们当时比较早的采用分片来应对我们的数据，如果做得稍微迟一点的话，分片就比较困难了，毕竟有很多外件牵涉到其中。我们做了最后一个跨越，通过ID进行数据库的分片。不同的数据库能够更好以一种水平的，而非垂直的方式把数据进行分类，放到不同的分片里。
如果做分片，会发现原来有这么多的连接必须要拿走，不能放在里面去了。当然，做分片无法实现数据交易。不用分片方式可以实现其中的交易，现在做分片不可能了。另外，确保一些独特的约束，比如说有一些特殊的数据库，用户的信息、电子邮件等。必须要有特别的系统确保不同的分片、不同的运输。更换摆设的话要很长时间，要做非常多的工作才行。
另外，报告。原来选择一个搜索把数据找出来，现在有上千个数据库，写一些脚本反复执行找到查询的结果。下面看一看我们怎么分片的。
现在看到的这张图，所有的数据库都放在这里，我们一开始有八个物理服务，每个上面都有512个数据库，都是DB0001和00513、3072数据量都一样，里面ID分开不同的数据，包括用户数据、贴图的数据。另外，多主库的应用。每一个服务器都有它的主库，有很高的可用性，非常的强大。不同的会崩溃，如果有问题的话，把里面导出来传输其他的服务器就可以了。
我们有八个服务器，但是服务器上面有太多的用户信息了，数据负载太大怎么办？有512个数据库，可以把数据分开放到数据库里面。比如说DB0001放到其他的服务器上。我们做同样的工作，分开来放进去就可以了。
下面看怎么改变ID的，对我们ID的分片非常重要的，我们的对象有独特的ID，64位的，根据不同的类型进行分片、进行分离。比如说刚才讲的数据库有不同的编号，有它的类别，要么是图板、要么贴图、要么评论、要么用户。是不同类型，类型也是能够给他专业性。看数据看有没有把东西放混了，把用户的数据放到评论的数据里面了。
分片的ID到底放在哪个数据库里，现在用的表里面我们属于哪个位置的。本地ID看这个表里面具体的放置信息有什么作用，是关于评论还是用户信息的。我们看看有简单的映射，整个管理数据库，还有反向的图。我们的系统代码可以有效的找到相关的过滤信息。如果想找用户信息，就看一看到底分片的ID在哪里。找到后在分片的ID里面具体找到1057，再在1057里面找到具体需要的类别，找用户。这样的分片使到我们工作非常的简单。从这样ID的结构，新的用户就是随机分布在不同的分片里面，希望能够根据不同类型的信息放到不同的分片里面。至少在本地你把用户需要的东西和需求连接在一起会比较简单。
我们可以使用自动增量放在本地ID上，系统里面每个分片就是根据ID在里面存储信息的具体情况。如果建立好ID能有6万个不同的分片。现在只用了4096个。所以现在还有很多的ID空间可以使用，而且可以能够以水平的方式进行不断扩张。
在数据库中，有一些比较简单的模式或者板式，每个角色都有它的ID，通过映射对应到图表里面，进行序列化。有索引表和映射表，用户喜欢哪些图板，建了哪些图。就像传统的系统一样，很快找到表的有效信息。重点是这些映射从一个完整的ID到另一个ID产生映射。对于系统来说，喜欢某个贴图或者喜欢某一个用户的贴图，整个ID都是完整的，把所有的连接在一起，当然时间戳也非常有价值，分类的时候确保ID是独一无二的。我们的查询都是组件查找和索引的查找。如果数据库过于拥挤可以进行分移，但是不会移动分片上的数据。所有的分片上都会装在所有的映射表。这样的话不需要进行范式的更改。因为不需要担心有任何的改变，比如说增加一些新的索引的话，就可以使用索引来形成新的映射表。所有的分片上都有映射表。比如说我们网站是怎样运作的，看某个用户的主页，想提取用户的数据，渲染用户主页，抽取画板和贴图，从此来渲染。很多一两次查找进行搜索就可以了。而且因为这些非常容易，可以在本地进行连接。很多工作是重复性的，可以进行大量高速缓存。一些很简单的MySQL的操作，在高速缓存中提取就可以了。而且我们还可以去抵消一些操作。
如果是提取150个贴图，可以根据这些操作取消一些对冲和抵消的操作。另外，还要编写脚本，这些数据需要进行清理，数据库设置的时候有不同的格式，我们需要把这些不同的格式进行整理才能放入分片里面。我们用的Pyres，这个工具比较容易，可以简单进行数据调整。我们有5亿的贴图，16亿的关注者，我们做一些脚本，不断测试，把这么多的数据进行分片。另外，考虑数据怎么产生，用简单的脚本来进行所有分片的过滤。
从这点往后，MySQL将会成为主流，而且也会成为正确的选择，集群会慢慢成熟。目前来说，这个技术还是分配在几个不同的公司当中，我们的公司比较关注于自动的分片。MySQL上面进行自动的分片，我们觉得这个是可行的。另外，集群将在以后会大有作为，但是不是现在。现在集群技术目前来说，对数据来说还是有各种问题的，还是要等个五到十年才能硬化。原来有一个单片的系统，我们开始进行分片的系统，转为一个基于服务的架构。有几个不同的原因，因为规模不断扩大的时候，会有越来越多连接上限，不断达到连接上限。还需要把所有的盒子连接在一起，连接的上限也是一个很大的问题。比如说100多个ATI要连上缓存的服务器，使到服务器瘫痪，而且功能要进行隔离和分离，比如说把某些服务进行分区。当然，这也是我们继续做的方向，帮助我们清理系统。同时，安全的隔离也是很重要的，因为安全性很有方法。因为隔离之后有安全性了。如果在一个单片或者非常复杂的环境中很难跟踪的，最重要在未来不断扩大团队的人数，现在有很多的工程师，随着用户的增加、人力也要增加。除了提供基于服务的架构，确保架构简单。现在不断招人，现在的工程师招人绝对是简单易用的，隔离开来区别对待，这样工程师不用面对整套的大摊子，工程师上手非常容易的。
最后一个跟大家分享的经验，要保持乐趣。
工作当中有很多压力，每天晚上熬夜加班肯定不好玩，如果网站运行非常顺畅，带来大量的满足。一定要让工作保持乐趣，而且让这一切能够井井有条。
【Marty Weiner】我们5点10分有另外的讲座，比较深入讲一下怎么分片的。如果大家想了解怎么缓存、怎么分片具体的内容，大家可以在下午来到分会场。现在还没有问题？
【提问】讲个非常精彩，有几个问题，您可以选择是不是回答。在设计当中有哪些设计功能？第二个问题，扩展性是你现在容量的16倍，因为开放了4000多个ID，总量6万多个空间，只开放到4000多个，扩展空间有16倍，是不是要重新设计架构呢？第三，有没有考虑要设计自己的存储架构？会不会用一些开源的解决方案。因为有一些编写代码不是特别好用，用别人编写的代码可能有问题，未来会不会考虑自己的一些编程，编写自己的。
【Marty Weiner】第一个没太听清楚，先回答第二个和第三个。第二个问题是扩展16倍，我们有4096个分片是分布在8个数据库，也就是说，8个数据库都可以能够在进行扩张。所以，我们可以每一个数据库都可以扩展512倍。我们的扩展实际上可以进行几千倍的扩展性。第三个问题，怎么编写自己的数据库和存储的数据库，我们也在考虑这个问题，如果一个地方出了问题，是不是用自己的方法解决呢？首先我们要组建我们的团队，有这样的人力才这样做。因为要写自己的信息、基础设施。我们用的公司也非常好，可以把不同的日志放在不同的地方。自己考虑编写一些编码，或者优化一些编码，加入了一些结构。第一个问题？
【提问】现在的设计当中，会不会有新的功能进行调整的架构呢？如果有一些新的功能，但是现在架构不支持这个功能会不会调整呢？
【Marty Weiner】我们有几种想法，只是要增加一些缓存、增加一些功能问题就不大了，因为分片有一个好处，很灵活，我们用分片的时候也有几个是热点，这时可以考虑一下刚好分到分片上，问题得到解决。
【提问】我们流量有大幅度的增长，如果有自动的扩展就简单了。但实际上我们用一些脚本进行数据的迁移。很快电脑节点就超载了，要考虑其他的问题。其实我们有很多的自动扩展，不光是数据库。系统层面上有自动扩展的功能。如果负载增长的太快，网站在ATI的盒子可以自动伸缩，这是网站级别、系统级别的自动扩展能力。
【Evrhet Milam】数据库还是比较稳定一致的，两到四个星期就要把数据库进行一次分割，这是比较稳定的。对我们来说也很容易去观察、跟踪。比如说我们应用多了，ATI多了，复杂性强了，我们就选择用自己的系统进行自动的扩展。不知道有没有回答你的问题。
【Marty Weiner】我们的网站也会做一个扩展。
【提问】选择架构不仅要看是不是免费的，在中国选择合适的架构，要看优先级怎样才行。
【Marty Weiner】免费不是最重要的，甲骨文如果做好的话，肯定会选择甲骨文，跟MySQL差不多，甲骨文要费用，MySQL不用费用，肯定用MySQL。我们选择免费的软件，是因为在这样的条件下，必须要选择在预算之内开源的软件，而且发挥不错的效用。
【主持人】接下来用热烈的掌声感谢两位工程师，休息十分钟，十点带来第二个主题演讲！
#p#
【主持人】接下来是ChinaNetCloud的创始人Steve Mushero，为大家介绍网络架构疑难杂症解析。
【Steve Mushero】大家上午好！我是Steve Mushero，接下来讲一讲互联网出现问题的应对以及一些有意思的事情，互联网的结构以及与客户打交道遇到的问题，现在的工作和以前的工作，战略战术实践以及怎么更好的解决问题和吸取的教训。
我在上海管理ChinaNetCloud，在中国已经待了七年了，我原来在硅谷，在系统基础架构设施开发等方面有很多经验。当年我和各位一样负责建造开发系统。大家刚才听了Pinterest的演讲，他讲的内容我举双手赞成，对中国客户讲是非常有用、非常不错的信息。换个角度来看，看整个中国互联网的架构，ChinaNetCloud08年由硅谷的技术人员在上海成立，我们管理中国互联网及游戏的服务系统，有性能数据库、系统数据库、服务器数据库，有上千个服务器、上百个客户，说实话林子大了什么鸟都见过。包括服务器系统、电商、体育系统、金融系统、IPTV，看到所有的这些相关的问题。
我以前在土豆网做过CTO，对中国的互联网提供一些游戏、视频以及基础架构有非常丰富的经验。中国是世界上最大的互联网群体。虽然说量很大，用户数量是美国的四倍，但是问题会多很多。尤其在提供高交付性的用户体验非常困难。比如说电子商务、网上交易以及在游戏方面。为什么会出现这些问题呢？有非常先进的ipad、手机应用，需要不同的基础架构。有些好，有些做的差一些。在中国这方面的运作比较困难一点，最重要的是提供性能、服务，是我们利润所在。在美国也是一样，如果更快的下载，网络上传速度越快，赚的更多，这一块中国做得不怎样，极待提高。
中国互联网群体超过5亿的用户，每年增加一到两千万，可以说互联网遍布世界各地。但是看用户分布在哪里，有年轻人有老人，中国互联网发展很先进的，在家一二兆，在办公室五到十兆，在美国带宽都比不上中国。从基础设施讲，有区域问题、网络堵塞问题，带来很多的麻烦。
我们确实很快，但是另外一方面发展路走得不是特别顺。到底遇到什么样的问题？
在中国分成不同区，有中国电信、中国网通，北方主要是网通，辽宁省、河南省、山东省网通为主，南方用中国电信，21个省市自治区，像浙江、广东等。这个问题是分离的问题。另外，中国移动的GPS，中国联通iphone和赛尔网络等。很多客户不理解为什么中国的网络格局如此分裂，进入中国市场就是一个问题。如果西部的话，成都、新疆甚至用不同的IP。去年移动买了铁通、电信买了CDMA业务，外国的公司越来越搞不清楚互联网的格局了。
有什么问题？非常差的连接性，很多人在网上看视频，喜欢用BT下载、迅雷下载，占用很多带宽，对我们游戏来讲，复杂度太高了。在中国不同的区域之内，甚至在区域之间。像深圳、广州、东莞，不同的区域之间的联系成了大问题。每一个ISP是区域性的，比如说中国电信分布每个省市自治区的子公司，但是这些可以说没有交集的。因此向全国性的服务太困难了，要买数据中心、买带宽。知道带宽从哪来的。到中国电信买没问题，但是要知道从哪个中国电信买的。在某个地方可能很便宜，在西安很便宜，可能在长沙就很贵。在昆明买的话，服务能不能用到长沙、北京呢？所以要了解哪个ISP买，到底能不能联系。
瓶颈是区域之内、区域之间南方和北方有连接的问题。在广东深圳有一些服务器，但是提供到北京很难了，但是南方提供到北京天津，必须有好的策略。很多公司不管这个。在深圳广东有一些服务器，这里的带宽便宜，提供这里的客户就行了。但是有野心、有抱负，在全国范围内开展用户，来自于厦门、福州、北京、上海、天津的用户有效的使用这个服务器才行。
另外，移动互联的问题。原来GPRS玩简单的游戏没问题，现在iphone来了，iphone是联通和移动的连接就有些问题了。或者说可以用wifi，移动互联网上发现移动网络公司不想买带宽，如果是联通的话，找一个运营商买带宽才行。现在不想买。当然有些情况出现改变，有些用移动IDC，但是提供服务太糟了，所以有一些瓶颈需要克服。一些问题解决不会带来太多的钱，就不管的。
很多系统使用代理、赛尔网，服务器在北京很偏的地方，放一个服务器，每个月付很少的钱就行了，才不管这些东西。在很多地方都有BGP，在中国不是很常见。五年前BGP几乎不可用，但是现在的BGP，中国五个地方在用了，但是才五个地方。相对价格会高一点，所以很多人不愿意用。可能会用多重线路。在天津可以用，网通用电信或者中国移动几条线共用。BGP现在还是慢慢受人的青睐。但是有很多客户不太清楚BGP，只会找中国电线，会带来一些问题。从全球的角度讲，和世界各地进行互联的角度讲，中国这方面的连接做的非常差。有很强的联系。另外，光线通道非常繁忙，很多东西根本传不过来。有些时候上美国的网站行，后来突然发现未来的一小时，甚至一天、一个礼拜、一个月服务器用不了，如何上美国的网站。可能会有一些例外的情况，但是真的使用海外的服务器，确实非常麻烦，必须要找到海外相对比较好的供应商才行。
有很多客户、电商，要求越来越高，学生非常时尚、消费，但是很难接触，学生使用的赛尔网，比如说网游肯定不可能和赛尔网连接在一起。像一些大的品牌，像诺基亚，可以通过手机信息传输给学生。
移动也是很大的问题，大家都跟移动有关。有三大运营商，中国电信、移动、联通。都是分开来的，有些用智能手机，但是用一类，另一类的客户只做奢侈品，只用iphone，别的看都不看，是另外一群人，分割是一个问题，把服务放在移动IDC上是可以。但是今天只针对移动的话，60%都用wifi，离开了这个房间就没有wifi了，必须用中国电信、中国移动了。所以三通必须配才可以，我觉得三通非常常见的。包括北京上海越来越多。这个行业来自不同的行业有自己的挑战，包括电子商务如何响应时间、可靠性、速度，快速得到服务很重要。稍候会讲到广告，广告关系到表现。
游戏有不同的响应时间，有一个多用户的分区，以及有大数据的下载。BGP已经谈到了，如果能够付得起钱就用。如果买BGP必须要理解买的是什么，不是所有的BGP都一样，有两线、三线、八线BGP，八线BGP非常少。必须要知道买的是什么，而且非常贵，中国的价差最便宜到最贵可能相差十倍。两通到八通，在哪里买。在北京买八通要贵十倍，必须要考虑花得起多高的价钱。带宽是你最重要的考虑。买BGP的话，不一定往往是有效的，有的时候看到带宽的限制，买了100G后来发现不是100G，5G和10G，有些有想不到惊吓。数据中心每天都有问题。部署架构的时候，每天会碰到新的问题。在哪里选择数据中心，这些很重要。包括移动资金都很重要。而且带宽变化很多的。很多时候有些带宽很好，但是表现非常差。
我们的顾客有一半在数据中心受到攻击。选择什么样的数据中心呢？是不是信任他们管理的服务呢？服务也是大的问题，扩展也是大的问题，比如说有十个服务器，两个服务器。本来有两个服务器，突然之间一下子全部堵住了，再打电话加服务器，没了。必须要考虑一下，一旦火了怎么扩展，会带来架构的问题。再找一个数据中心，两三天内增加数据中心非常复杂的。这是数据中心的问题。服务也是很大的麻烦。
这么多的问题该怎么解决？我从运营的角度谈一下，而不是从互联网的架构角度。我们觉得这个建议很简单的，但是我们的顾客往往不太理解该怎么做。当一个新的顾客第一问题就是问，你在什么地方？用户在哪里？电子商务游戏的占点，可能突然发现用的移动中心根本就不搭的，所以地点非常重要，选了一个地点要搬就不容易了，看单点还是多点。作为一个架构师两三个点，但是公司要去做两三个数据中心的布点，在中国是非常不容易的。
当然，我知道有些游戏可能有不同的分区，有不同的故障恢复的站点。刚才讲到一定要挑好的地点，尽量保持简单。选一个地点一定要发展之后占点多了在有新的站点。我们的选择是花得起钱的最好的站点。不一定找一个三级城市挑一个三级的IDC。我看很多人找不到地方，是哪个叔叔舅舅认识什么人，找一个三级的数据中心。
有多少钱都要避免三级城市，避免三级的IDC，现在考虑到怎么样应对移动的应用，考虑到怎么样扩展，而且我们要考虑到云。云往往有一些新的因素。在中国对于云来说比较早的，云的选择要考虑，目前来说不太现实。
选择IDC的地点之后，看买什么，买能花得起钱的。不光是带宽，还要考虑连接性。认真对待业务要看数据中心会不会受到攻击，数据中心有没有保护，如果公司火了之后，很多人会帮助你，有没有提醒防护。所以，一定要考虑在哪里花钱。同时，要获得好的服务，很多IDC的服务真的不怎样。很多数据公司不接受你的到访，要体现预约。要去数据中心的话，要提前预约，打电话就可以来。突然跟北方连接不上了，打电话打不通，帮不上忙。
另外，连接性和带宽，还是那句话，只要花得起钱，就买最好的。要保持简单，但是要买你能够花得起钱最好的。在你的资金范围内，买最好的数据中心、最好的硬件、最好的带宽。可能是几千块一个月，要考虑钱花在什么地方，要考虑对用户的地点。单线、多线，有移动要考虑wifi。从绩效来说，很多用户说基本工夫没做到位。比如说网上的架构、网上的编码。但是很多顾客很基本的主页就有20兆，主页上的照片太大了。所以你觉得要做到完美，但实际上并不完美，所以一定要考虑到，有快速的表现。所以一定要以终端用户为中心，考虑怎么样让它满意。要考虑怎么样小心化、快速化，用什么样的图形。
有些东西做得很漂亮，但是太漂亮做得太大了。而且应该遵循一下最佳实践，进行测试。有很多网站、书籍帮助你进行这样的测试，很多人忘了做测试，可以很清晰通过测试得到报告，有什么样的问题。这种测试服务是很有用的，会带来终端用户体验巨大的差别。
有可能的话用AJAX，很多人可能在用AJAX，每页是动态的渲染，每天阅读几百个页面，是动态的，有大量的服务器，用AJAX系统，这种系统可以做出很大的转变了。首先把这个网页搞好之后，AJAX是真正帮助你的第二步，可以帮助你更好的上传。在中国很有用的，真正帮助提升用户体验。如果不能用AJAX，还是要考虑一下怎么用缓存。尽量一个页面是电商的页面，可能五分钟、十五分钟，一个小时才能够渲染出来的画面。高速缓存确实真正能够提高表现。如果很大流量，上网买东西的话，速度一定要快。所以AJAX的缓存是很有用的，而且要考虑其他的对象。
最新的趋势是有更多的Push和Async，我们是推送给顾客的方法，特别是一些动态的游戏，顾客可以下载一些静态的数据，可以把动态的数据推送给他们，这个体验是很好的，我们静态的数据都已经缓存下来很固定了，推送给用户的体验是非常流畅非常好的。听起来很简单，架构、编码、资料库都有很大的工夫要做，但是最终的效果是很好的。比如说页面是静态页面，动态推送给客户。但是需要时间理解掌握。每个用户PCB连接到你的网站。在香港有300万个同步用户，应该来说不是很多，但是同时300万都连上网站没有多少人做到了，实际上要考虑你的拓展性。所以这个系统要考虑到扩展，每个服务器接待多少用户。可以做到的话，可以得到非常令人惊讶的效果和满意的用户体验。这是最终极追求，进行高响应的界面。刚刚进入中国，没有多少人用，但是非常期待的。
我们讲了最佳实践，讲了（英文）网站，可以找一些基本的问题，很多都可以做。我们看太遗憾了，网页非常慢，自己应该做检查，不通过检查CDI做得再好都不能解决主页只有5兆的事实。
我是CDN很大的粉丝，在中国CDN很有用的，可以带来两大好处：第一，提升用户的体验，有一个缓存。第二，静态用户、终端用户体验快速流畅，而且可以降低带的价格，如果带宽的价格降下来，就可以买一些高质量的带宽了。
比如说钱不是很多，把钱有效的拿出来，到八通的BGP，是中国最好的，大概一兆是800块钱，可以把其他部分降下来，用到BGP上面，性能非常高，花的总钱数没有多多少。花了更多钱在视频和图片上，不可能花钱来应对带宽的要求。所以要看到全局里面看怎么区分我们带宽。一方视频可以多一点，简单图片少一点，分配使用成本。
稍候我会讲到云端计算，讲云也用了CDN，很多人没有意识到云计算的时候，用CDN。监控也非常的重要，重要性不言而喻，因为在运营过程中我们会监控。我们要监控200到300个服务器，要有安全的情况。另外，非常重要的一点，有钱要监控服务器之外的情况，中国最好多游戏网站、最好的电商，看看做得怎么样。比如说我在深圳有服务器，在成都做得怎么样？昆明做得怎么样？武汉做得怎么样？可以跳出自己的框框，按照CDN和不同的运营商了解整个市场的情况。当然，有些做起来是比较贵的，比如说电商公司在中国各地卖我的产品，肯定想知道我的网站对于成都那些客户来讲 网站响应速度怎么样，产品卖不卖得出去等，如果不去了解，永远不不知道他们的想法怎样。这样的服务虽然花点钱，但是可以了解到客户对你的网站和服务怎么看的。
我们也非常喜欢云计算，ChinaNetCloud提供云计算很多年，是市场先行者，现在跟阿里云等开展合作，最终希望达到AWS的水平，向中国提供。当然还有上海的世纪互联也很有前景，尤其是阿里云。可以随便加服务器，使用不同的服务，存储非常简单，甚至可以使用云来为服务器存储一些相关的服务。在美国没有人在服务器里面存图片，都存到云端。在中国也可以考虑这个方法。如果没有存储，不知道怎么分享相应的资产，可以了解一下其他人是怎么做的，直接放到云端就行了，而且成本很低，在中国原来做不了，今年有机会。希望大家考虑一下云端存储、云端服务器，基础设施等。我们认为未来会非常流行，希望越来越多的公司上云。这也是很好的消息，目前只能说限制在中国大陆之内的。
另外，使用云计算的时候，要知道你的目标怎样，像阿里云一样成为AWS还是有其他的目标。如果只是一个服务器，用起来比较简单，PHP就够了。如果更大的1到21个服务器，带来什么问题。列表告诉大家什么最重要，带宽等小问题都会产生举足轻重的影响。阿里云做得也还不错。如果用云计算、云服务的话，千万不要因为小的问题给你吓了一跳。当然，如果用公共IP的话，还要为此付费等。这些都要搞清楚。我会把我们评估的标准、关于中国的云计算的相关评判标准，正式公布，大家就可以了解到了。
我想在座很多都希望不仅仅在国内金融服务，还希望走出过门。可以跟亚马逊、rackspace合作。有些客户既要满足国内需求还要满足国外的需求。很多又要搞中国的系统，又要搞美国的系统，很困难。很多把服务器放在香港，在香港放服务器，给中国大陆的客户提供服务，再给美国客户提供服务。如果是一个小公司、小系统放在香港没问题。但是，如果是一个大公司，有合适的架构同步所有的信息。确保美国信息和中国信息是同步的，比如说总部信息和子公司信息一样。这里很难说你用一个简单的系统来支持美国、中国的市场。中国的服务器支持美国市场、日本市场的话，很困难的。
在香港没有Amazon，在东京用Amazon，可以更好的接触客户。这个问题看起来还没有起色。
中国的互联网是很大的产业，很多的事态发展，变化很快。虽然电信业的巨头买了另外一个公司，行业格局出现变化，BGP、CDN都可以改变行业的格局，必须有更好的经验监控行业，另外选IDC位置地点非常重要。在中国看性能怎么样，关键因素是IDC放在哪里，怎么更好的提供服务。像架构编写等都可以影响到CDN使用的成效，还要监控服务器的作用性能。确保在市场产生足够的影响，而且在中国赚到钱。在中国只要做得快，客户满意就开心了。我就讲到这里！
【主持人】谢谢Steve，刚才讲了中国网络服务，云计算服务哪些难处，我有一个问题是关于亚马逊云服务的，我觉得亚马逊在中国没有数据中心吧！有没有一些中国公司使用亚马逊云计算的成功案例，可以针对中国用户和国际用户。
【Steve Mushero】亚马逊目前在中国没有公开的服务中心，最近在日本，未来会在香港设一个，可能也会在中国大陆有，目前来讲还没有。我不太清楚有哪些大的公司使用亚马逊的云服务。就算中国用的话，只是一小部分，很难扩展，不可能复制出来做出更大的成功案例。现在阿里云和亚马逊的云服务是可以借用的，在中国用阿里云就可以了。
【提问】找数据中心和买房一样，地点、位置最重要的。在中国做网站成功的话，还面对一个问题是政府的限制。
【Steve Mushero】不好意思能不能再重复一下。
【提问】中国的网站，国外的服务器用中国的网站。
【Steve Mushero】对我来讲，在中国打开美国的网站蛮快，在美国打开中国的非常慢，可能有一些限制，路由的优先级不一样。中国很多人喜欢看美国、欧洲的网站，相对讲有这样的流量促进，所以快一点。美国欧洲没人看中国网站，自然打开慢。另外，防火墙是不是会影响到这个呢？出去容易进来来？不知道是不是这个。之前没有具体了解过，有时候在香港放一个东西。香港带宽也会受限，效果也不是很好，谢谢！
【主持人】大家用热烈的掌声感谢Steve。休息十分钟，11点带来第三个主题演讲！
#p#
【主持人】接下来有请Coding the Architecture创始人Simon Brown为我们带来“郁闷的架构师”。
【Simon Brown】大家上午好！首先，讲一下软件架构师的认知是什么意思？如果你是一个架构师，往往有人觉得做大型前端设计、懂UML就是架构师。
我不是一个很有力的架构师，不会画出大量的架构图解，我的工作不是做画大量的图。其实有很多的热门词汇来描述软件架构师的角色。最近听过一些热门词，比如说架构师是“业务技术战略家”，业务、技术、战略家三个词我懂，放一块我不懂了。我有一次开会，有人问我，怎么样把MongoDB放在当中，他们高层告诉我MongoDB是什么。有很多的热门词，热门词有必要的，用术语、用热门词。往往太多了，就忘了软件开发基本的知识了，我们离软件学问越来越远。所以我是一个软件程序员，是架构师，是团队一样。也喜欢编写代码，大家举手有谁喜欢编代码的。挺多的。
我们考虑架构师是什么地位。我入行的时候是一个工程师，是一个软件程序员，慢慢晋升到架构、团队领导的工作。我有两个很有意思的时期，在UML的时候，我最早开始做架构的工作，主要是画UML的设计图。6个月写UML的文档，对我来说我觉得是一种浪费。
我在一个大型的管理咨询公司服务，他们招我进来做软件架构师，每天也编写代码，他们不理解，让做软件工程师为什么要编写代码呢？在大型企业往往是事业的阶梯，你是一个高级程序员、架构师，慢慢升上去，离开了这个队伍，进入了管理团队，这是很令人遗憾的。大部分的技术人员，最好在这个团队里还是发挥作用的。在团队里面，很多时候英国一些公司，因为技术源做得好进入了管理层，公司反而失去了动力。
我有一个网站叫Coding the Architecture，觉得架构离不开这个编码范畴的。很多人说软件架构师是一个名片上的职位、头衔，拿到这个头衔工资高一点。但是这是一个角色，是慢慢发展才能进入的角色。
大家进入Linked讨论的话，说是一个高级程序员晋升到架构师，说我该干什么，有些人进入到架构师反而不知所措。
谁想做到敏捷？有些人喜欢敏捷，敏捷是未来大的理想。软件开发做到敏捷，是很酷。但是，我觉得我们是不是忘了一些什么？特别是软件架构的时候是不是忘了什么？
我们讲一下敏捷这个词，敏捷有很多相关的热门词：自动测试、精简、瘦，这些都相关，而他们都是很好。其他表现、扩展性、安全、团队的共同目标，很多人忘了这些其他的重点。
很多人把敏捷强加在很多的名词前面。我看到很多都会把什么词前面都加一个敏捷，说卖什么东西就卖敏捷的什么东西，听起来很酷。到底什么是一个敏捷的架构师呢？敏捷的架构师是不是不用UML的架构师呢？这种概念有些时候没有什么意义，但是听起来很酷吧。
Hi，大家好！我是一个敏捷的架构师，听起来很棒！
这是敏捷的架构吗？在我培训过程中，有人画图的时候用即时贴进行画图，这就敏捷了吗？架构在敏捷的方式当中，架构在什么位置呢？用不同的Skills时间框。按照项目的过程在不同的阶段进行不同的设计，这是不是也是一种敏捷呢？
很多人认为只是做了一个架构，希望最好的结果。很多人觉得敏捷是一个借口，做了敏捷看效果好不好。
很多人跟我说，我们不需要软件架构，因为我们做的是测试驱动开发。TDD就是一种测试驱动开发，但是跟软件架构不是一会事，TDD是大的代码，从基层的角度讲，架构从高层角度。
最后负责时刻，这个词我不太喜欢，很多人作为一种借口，迟迟不做决定，这就是敏捷，最后负责的时候做决定，往往最后的负责时刻成为不负责时刻。很多的敏捷书籍，要自我组织的团队是一个扁平式的组织，没有组长，大家通力合作，这个听起来很好，因为扁平式的合作更加快捷，但是有些时候这种团队不行，但是没有人告诉你有些自我组织的团队，他们可能有几个有经验的人，比如说有高级，如果把高级和低级放在一起自我组织不行了。有时候有些人说，你为什么对敏捷有这么大的意见呢？其实我喜欢敏捷，并不是要抨击敏捷，有些人觉得敏捷太多让我们觉得很酷的东西，但是忘了一些最基本的工夫。
我觉得我们应该要回顾一下，回顾也是敏捷的热门词。我觉得我们忘的东西比学的更多。在软件行业来说，学的不如忘的多。有多少人在项目当中还在用UML的？数量很少。在欧洲的比例也差不多，如果五年、十年前问这个问题，每个人都举手。今天用这个问题很少人举手。不是有什么取代它，而是很多人忘了它。
15年前出了一本书《颜色编码》，用颜色编码的UML的工作方式，这个很好，很多人忘了。因为用颜色可以清楚的做一些图解，还有CLC，类-责任-协作，很好的方式，可以做分析储存的分配，找一些人做了一块，找了一个用力，进行分解。满足用力的特点，跟每个类分配一些责任，同时找到不同工作中协作的过程。这是软件系统进行分解很好的方法。用团队分解，现在很少人用这个方法了。
边界、控制器和实体，这是系统结构很好的方法，面向服务的架构方法。同样还有基于组件的开发、面向模式的软件架构。整本书都会讲面向模式的软件架构，这种书出版很久了，虽然是一本老书，里面的内容在今天来说跟当时出版同样有意义，但很多人没有读这本书了。
Rational统一过程，是一种增量式很直观的过程方法。敏捷也是增量式的过程方法。Rational的统一过程是围绕架构做一个核心，以这个核心做各种活动，让架构不断的演变。
刚才跟大家突出强调了一些过去的方法，这些方法很不错的，不是让大家回去按照这个做，我们要实际一点考虑，看看老的工作里面有哪些经验教训和诀窍给我们用。觉得可用的话，可以在具体的工作里面可用一下。
这些经典的东西谁在教你？没有人教你，因为经典的东西看上去不酷。我们书架里面有书，有看板、有经义、有程序设计等。现在人不讲了，觉得没有意思了。
很多人是做软件架构师的，实际上没有搞清楚做软件架构师是干什么。我在伦敦工作的时候，招日招软件架构师，面谈看简历情况。这时有一个企业的架构师，描述他的工作，做得工作就是大企业里面做一个软件架构师，给自己加上一个实际上根本没有负责的头衔，让人听起来感觉很不舒服。
经常发生这样的情况，人们发现软件开发像接力赛一样，实际上解决方案的架构师会问一些情况，或者要求之后，会做一些架构把它以文件的形式记录下来，非常厚的文件，文件交给团队就跑掉了。
团队拿到文件之后，要负责把架构真正付诸于实施，我不喜欢这种方式，这个人做了架构跑掉了，团队不知道怎么做出来的，内容团队有问题的话，不可能问原来设计的人。我给它起了一个名字，AaaS，读音是屁股的意思，把架构服务交给团队不对的。就像接力赛一样，一个棒给下一个运动员就跑掉了，其实不行的。
项目的成功不仅仅是关注与实施，很多人认为实施好就行了，并不是这样的。
现在看到的图里面有非常多的图表，人们非常愚蠢的期待结果，做了价格，不知道能不能行通就丢给别人。有一次有人让我们来看一个项目，当时架构里面就一个软件架构师，做技术指导工作的。我看架构的时候发现了软件系统里面的问题、难处，其中有安全的问题，还有功能根本用不上，另外做了负载测试结果不好，文件的记载也不怎么样。这个项目不小，是战略平台的第一步，要先做了价格，未来几个月、几年把服务加在上面。
对我来讲，一个软件架构师，要杜绝PPT上列的这些问题。我觉得做文件记载非常重要，但是现在讲所谓的敏捷的软件架构设计，很多人不记录文件，敏捷的人不会把文件记录下来，根本不增值、只做增值的事情。当然厚厚一叠文件给别人也不行。我们需要提供文件，而且精简，不用太多，搞清楚问题就行了。
在英国以及在欧洲，我发现有些人根本不了解干什么，尤其是大团队里面，大家对决策不清楚，刚才Pinterest讲到团队扩展，团队扩展会带来一些问题，大的团队在一片混乱中工作，不知道自己在构建什么，而且不知道怎么样构建，根本没有蓝图，大家都是随心所欲，根本没有指导性的目标。出现这种情况的话，在这样一个混乱的系统里面，最关键的是把它停下来，在系统里面工作非常慢，无法扩展，没有任何安全感，感觉编码像一滩烂泥一样做不好。我希望编码非常清楚、有好的结构和次序做出什么。要打破混乱，有好的愿景，让写代码的时候知道方向，按照这个方向来走。原来哪些人做项目有很大的文件，就是让大家分享他的想法。但是如果这么多的文件，会太长没人看。既然没人读你的文件，初衷没有得到实现，大家也是失去了方向。
现在我们做敏捷了，有些文件可能在白板上画一些东西，但是别人不知道画什么，就像无稽之谈一样，没有共享的愿景，别人画的东西搞不清楚。
给大家举一个例子，来自于有一次我看到的系统的图示，我觉得完全没有意义，根本不知道这里面硬件还有软件以及不同的节点发挥什么作用。这个比较典型，一片混乱搞不清楚做什么。所以我们必须要把我们所工作的方式可视化。我们看敏捷、看板、故事强。用易贴纸在墙上，就知道流程是什么样的。我们不可能系统用图的方式来做。还是要考虑用UML来画出来。
以上是我演讲的第一部分，作为软件架构师对行业感到的挫败感。
我们希望团队成员共享愿景，知道发展方向怎样，很多时候在公司里面会请一个软件架构师，会成为这个架构师的头头。开发人员接受架构师的指令，团队就是这样工作的。我们感觉软件架构师在象牙塔里面使令，在开发团队做的事情没有任何交集。软件程序员不会理会架构师的建议，觉得建议是一派胡言，用不上，要避免这种情况。
怎么做呢？
我们请一个软件架构师，把他当成领导安排工作，希望与团队合作，能够提供指导，提供相应的辅助性的工作。要把软件架构师和软件程序员放在一起，缩小差距，慢慢实现共鸣，这样的话非常有意思了。在一个结构里面大家可能都是软件架构师，这是一个非常乐观的情况。不让他们都成架构师的话，缩小差距，慢慢也会实现工作中的互联互通。
我们要请一个软件架构师选什么样的人？
T型的人，首先要有深度，T下面的一竖，有扎实的技术功底，至少懂基础的语言来做。打交道知道技术怎么回事才知道技术。T下面的一横，要知道不同的方式，知道不同的结构，解决代码问题、扩展问题，要看不同的系统怎么做出来。Pinterest两位发言人讲得非常有意思，可以从那里学出来。架构的词英文到底来自于什么意思？最原始的意思是建筑师。原来建筑师拿一些石头、砖头盖房子。架构师也是一样，我们也是盖东西，成为这方面的大师、专家，成为通才化的专才，是软件架构师应该有的角色。有专业的专才同时有不同的领域。
有一位英国的先生jasongorman加入了软件的运动，在微博里面写，我现在不写代码了，觉得行业里面资深的人有奇怪的想法，已经很资深，不写代码了，会不会雇一个不会编码的架构师？
现在看到的是从比较高端的角度界定一下软件架构师做一些什么东西，保证了解要求、组织的约束到核心的技术、设计软件、评估软件设计，确保用得上至少信心满满说肯定用起来。编码，软件架构师核心的工作。软件架构师不是做一件事情就固定不动了，遇到新的要求就要不断的演进，根据不同的需求满足不同的变化。质量保证也非常重要。教练和指导，这是之前讲过的，找一个架构师与团队协作，提供辅导的机会带领前进。
软件程序员看一些代码、测试、软件的编制，架构师不太一样，架构师要后退一步看看全局。所以这个时候并不只是看代码级别的内容，为什么呢？想象一下有一项要求，做一个软件架构来解这个要求，怎么做？要把要求进行分解，从功能性和非功能性分解。所以，可能在环境当中有一些局限性，在工作大部分的情况下，技术选型有限制许可证和软件等都有一些局限性。不知道架构有哪些局限性，而且有一些原则要进行。有些要在整个软件开发当中，从始到终遵守一致的原则。解决问题有不同的方案。从编程语言到选择技术案例。找到一个最好的方法，找到最好的选择。不同的要求，不同的局限扔到一个盒子里，找出最合理的一项。至于在软件编成的过程中，敏捷可以看到很多时候大家不用UML的工具，我也会用UML的工具，用它来做一些图解，需要一些正规的流程图，可以用它来做流程图。但是在设计软件的时候可能就不会做这么正规的流程图，可能会用白板、易贴纸等。如果三四个人挤在我的电脑前用UML工具，就很麻烦，但是可以在大的白板前面一起合作就很简单了。
我很喜欢画画，很多人不喜欢画画，不用UML，我是怎么画画的？基本上按常理出牌，画一个高层的概念，把它分解，在分解筐子里进行考虑，分解数据服务、数据库、架构等。在每个服务器又把服务器进行分解。更多的细节可以按不同的类来分解。所以这叫做C4的方法，是非常有效的草图法，可以很简单非常精益的做出非常好的草图。
为什么说架构师是一个总的建筑师呢？如果是你会不会把系统进行编码？是的话还好，如果据的编码不合胃口就麻烦了。如果架构师不懂背后的编码，会问出这个不合理的问题。
文件很麻烦，有时候会做厚厚的技术文档，很快过时。从另外一个角度来看，从精益角度来看文档说明。我们把它看成旅行手册，如果看任何的旅行指南，会有地图告诉你怎么走，这就是我们的代码基础了。有这个草图就是我们的地图了。我们看一下景点，哪些地方不可错过要看一番，要看有历史文化的景点。比如说这个地方怎么慢慢演变到今天的局面的，使用的信息，怎么建立和配置我们的系统。所以我们说精益想敏捷要减少浪费、增加价值。关键是要言简意赅把要说的东西说出来，而且要增加价值。如果画出一些类的图解。本身看代码就能知道，本身也能够理解，他们是程序员，看代码就看得懂了。所以要描述一些代码没有的东西。通过示意图像地图一样，帮助程序员或者别人通过你这个找出文档当中所要的东西。
这是不是大型的程序设计呢？其实并不是的。如果你看十年前，我们会有一些非常糟糕的方法。另一方面，我们有敏捷的方法，比如说极端的编成，Scrum等，这是演变性的价格设计方法。但不幸的是，有些人觉得两者都不做是最好的，左边前期什么都做好，另外一个极端什么都不做最好的。实际上我们不一定要走极端，可以两者取其中。比如说像RUP统一过程，这是两者之间的做法。是轻量级的，同时也是增量型的，对架构不放过。我的答案是刚好够用。做的前端设计是刚好够用，符合你的项目，而且是合理的，这是非常好的项目，这是一个好的指引，但是并没有告诉你，多少才算是够用，这就是我们回答重要的问题了，多少才是够用呢？
Scott Ambler是在IBM工作的人，倡导敏捷包，有一个网站倡导一句话可以概括了，你的架构应该建立在要求上，要轻装上阵。轻装上阵是一个敏捷要刚刚够用，同时要用实实在在的经验和实验来证明你的架构。
什么叫做实实在在的实验呢？用一个圆形和概念证明的方法，做一个薄薄的切片，把软件切出薄片测试软件的功能、扩展性。你怎么知道应该做哪一种的概念原形证明呢。必须要知道，哪些部分在架构上是有重要意义的。架构当中哪些是重要的，进行这些测试。我们围绕着核心架构有很多的其他内容，我们必须要把核心的架构搞对。这就回到我们说一定要把主要的风险排除在外，消除我们的风险。
有些时候发生了风险就会有不利的效果，当然要在软件的项目当中避免这种风险发生。当然，风险可以量化的，只要把它在一个概率和影响的举证就可以进行量化了。如果是非常低概率的风险以及非常小影响的风险，只要知道就行了，不需要做什么。如果有一个风险是高概率、很可能发生的风险，而且影响破坏很大，这种情况下，高影响，整个系统架构要重换。整个风险因素就要提早进行考虑。所以很多不同的风险优先次序不一样。我发现一个问题，软件团队不太善于列出风险，觉得很无聊，把风险给写下来，这个可以解决。在我的培训当中，网站里面有一个内容，有一个风险的脑力风暴。让他们去识别风险，会画一些草图，让他们就这个架构草图放在墙上，然后把团队、程序员、测试员，所有的人员坐在一块，让它看架构草图。你们觉得系统有什么风险？哪里有风险？升级性、扩展性、技术的选型还是可用性？每个人有自己的想法，把这个想法汇总在草图上，这样的话可以视觉化的通过贴纸的形式看到大家的想法。所以风险也可以是主观性的。
当然，我们找到风险之后，必须要处理、缓解风险，不是找到风险就完了。我们举一个例子，什么叫风险。我在丹麦去年开了一次会议，他们说，我们对敏捷项目的一个回顾，Linda Rising会有不断的回顾，发现什么问题的时候，会把问题写在一个卡片上，粘在墙上，不同颜色的卡片代表不同的感受，有些是快乐的卡片，有些是挑战困惑的卡片。红色的卡片是愤怒的卡片。当他们觉得问题是非常愤怒就写一张红卡片。Linda Rising把所有的卡片铺在地上，一边是起点，一边是终点。在项目的终点时，用技术用得实在很恼火，但是应该在项目开始提出来，而不是终点找到痛点。
我今天讲得是软件架构师的过程和角色不是一回事。软件架构师的角色根据不同的团队各有不同，角色不一样，有个人写了一本书《从混乱到自组团队》，列出不同风格的团队，有的团队是混乱型的，有的是自我组织型的。不同团队有不同的领导力，在混乱团队当中有非常严明的领导把混乱加以控制，但是在自组团队当中每个人都可以是领导，当然中间有不同的阶段。这就是软件架构师的角色，这个角色在团队当中跟不同人之间的关系不一样。软件架构师的过程又不一样。一方面前期设计，另一个极端做了之后也不管，看最后的效果如何。如果想把这两个极端用图描绘出来的话，刚刚够用的架构刚好处在中间。并没有大型的前期设计，没有什么都不管，讲的是中庸之道。架构有哪些结构的重要要素，在前端设计要关注的。这时前端要识别主要的风险、消除风险。但是要有共同的愿景，让团队围绕这个愿景合作。在自组团队每个人可以做领导。
敏捷软件开发的项目是不是需要软件架构师呢？我的答案是肯定的。你的项目就是敏捷或者不同的结构，但是架构是不可回避的。就算敏捷的项目也可能是很复杂，也可能有高安全性、高扩展性、高性能的要求，这些都是希望从架构师的角度解决的。
或者我们可以把这个问题反过来问，敏捷性怎么影响到软件架构行业的？很多公司做大型的前期设计，设计上带来系统分析、带来瘫痪，想得特别多，敏捷性搭不上的。有什么建议呢？如果团队处于混乱之中，没有共同的愿景，回到一开始，重新界定一下到底软件架构师做什么的，至少团队中有一个人是技术的领导者，他来确定方向。你规划出他到底做一些什么东西。比如说八个盒子，每个框里面到底哪些工作是怎么做的。另外，软件架构师中一些手工活，别老用电脑来做，一些草图用手里画，画的比较简单一点，贴在墙上，要想敏捷行动要快，行动快的话和别人很好的沟通，很好构图的方式就是画草图。我们要做的软件系统是发挥作用的，能够工作的、能够扩展的，能够不断的升级的。
作为一个软件架构师，实际上就是一个技术方面的领导者，要非常积极主动，带动团队而且以身作则。如果看到一个问题，直接上去解决就行，其他人就会效仿你，看到问题也会解决。
我们要为未来做好准备，未来有其他的软件架构师，要提供管理、培训，确保未来成功出师，能够培养出来。不管做什么，只要适合你就行。因为我们面对不同方案、不同技术，要做的是选择一个用起来最舒服，发挥最大效用的，所有的团队都一样。像敏捷性是热门词汇，很吸引人。但是敏捷对于你来说没有四海而皆准的方法帮你解决问题。
我就讲到这里，谢谢各位！
【主持人】由于时间关系，只提一个问题。
【提问】谢谢！刚才在您的幻灯片里面，我想起来以前听说过雅虎的软件架构师跟雅虎的CEO说，如果说我们要炒人的话，最先要炒的就是职位里面有架构师或者有所谓的项目管理人员、职业头衔的人，你是怎么看的？
我是这么看的，不是把这些架构师炒掉，而是架构师要挑合适的人才行，有非常扎实的技术功底，而且也能够做不同的事情。因为架构师选对人才能有好的领导。
【主持人】掌声感谢Simon Brown！上午到此结束！
