第二天的演讲一样精彩，相对于第一天的大概念和开发模式而言，第二天的演讲更贴近开发者和架构师，Erich Gamma被冰岛火山灰困住了，没能成行是这一届qcon最大的遗憾。 Facebook的扩展Memcached实战Marc Kwiatkowski讲的十分实在，facebook在memcache上的确是花了很多心思，讲了很多在使用memcache过程中，在高请求数据量的情况下所做的演进和优化工作，相对于国内大并发请求网站处理有较高的参考价值。相较而言Nick Kallen在Twitter的可伸缩性数据架构中的演讲虽然也很精彩不过适用范围就比较狭窄一些了。P.S：Marc Kwiatkowski乍一看很像PB里的Alex Mahone，哈哈。 下午阿里巴巴国际站架构分析和镜像解决方案中我们听到了阿里巴巴在跨IDC的解决方案方面做出的努力，也不错，不过相较而言和第一梯队的技术解决方案而言还有很多需要catch up的地方。 监控和虚拟化技术在“去哪儿”中的应用，作为运维出生的大佬吴永强，监控的演讲十分精彩，很多时候我们防患于未然依赖的就是监控团队在问题浮出表面之前解决问题，网站要做到4个9的可用性也是个很有挑战性的话题。 人人网技术架构的演进演讲中黄晶也大致介绍了人人网的技术架构演讲过程，同时宣布了要开源两个项目Nuclear和Rose，前者是一个分布式存储后者是java的web开发框架，基本上都是服务于业务应用逻辑的东东。Nuclear如果真如介绍所言，那可能是国内最好的Dynamo实践了，当然偶更欣赏豆瓣的BeansDB的简约风格，够用就好。Rose对于我等不用java做前端的人而言意义不是很大，只有让做java前端的朋友评判去了。 构建可扩展的微博系统的杨卫华也就是我们熟知的Tim Yang或者@xmpp的演讲也很精彩，一是大致解释了twitter/微博类应用中常见的技术难题，二是讲解了针对国内情况所需要注意的地方，不过貌似国内的互联网应用界对事务性要求都不是非常关心，我所关心的并发写入队列的时序问题依然没有人回答。 第三天的演讲偏重的主题是SOA，REST部分的演讲个人而言觉得PPT做的不是很好，Jim Webber把一个架构的改造和REST服务的引进绞合在一起来说明REST的优点，感觉比较的牵强附会，在FAQ环节也不容回避的坦白了REST只适用于那些秒级亦或是百毫秒级的应用场景。 个人感觉REST是个好东西但并不是middleware的替代品和解决方案，而只是企业对外接口的一个策略性option和非常聪明的option。一个企业既有内部的ESB服务总线在和其他下游/上游企业/个人交互的时候提供两套接口，一套使用传统的middleware比如DCOM/CORBA/ICE/Thrift/AMQP，另一套采用REST/XML-RPC/SOAP类似的http协议级别的通讯接口，这样一来交互的开发者在初期可以使用REST这类开发接口上手，快速解决问题（比如flickr众多的插件功能），在后期如果上升到企业应用高性能要求的层面再去使用ICE/Thrift这类的高通讯性能接口会是比较稳妥平滑的解决方案。 性能和可扩展性再度归来：内存数据网格 - 萧百龄 好吧我承认oracle的确牛x，做事很多时候都能想前一步，p2p网络的思想与我想的未来的互联网的服务发展方向不谋而合，很多时候感觉oracle/mac就像海洛因，你用多了会high，但也要付出高昂的代价，阿熊还是偏向于自由、免费、分享的理念。 下午 深入浅出复合事件处理（CEP）蔡学镛的演讲中午回酒店一趟拿东西没听到开头，不过感觉支付宝这些年已经折腾了不少好东东，CEP不太了解，唯一担心的是那么大数据量长期放在内存中可靠性如何保证这一定是个难题，支付宝是如何解决的呢，并发写入的时序性是如何保证的呢？ 最后两场的演讲都很精彩 淘宝网前端应用与发展 小马哥把淘宝这四年来的演进史讲解了一遍，我想他们遇到的问题大多数团队都会遇到，而各个演讲路程的阶段性解决方案也适合各个成长中的团队借鉴学习。 最后一场是Douglas Crockford的JavaScript的现状和未来，大师的看法和角度已经不是我们普通开发者所站的角度在思考问题了，在web的各个标准层面去思考问题，对安全性的思考尤为重视。他是一位让人尊敬的勇士和斗士。大多数人都在热衷于增加功能（html5）和出于商业考虑兼容过去(IE6)而他却是忧心重重的在思考xss以及相关的安全问题。FAQ环节的第一位仁兄非常无脑的纠缠着namespace/model的问题不放，我真有心冲上去对他说：you havn't think in javascript way.后一位同学诉说了作为BCD(Boss Center Design)方式开发者的无奈，老板逼着你兼容IE6怎么办，老道的回答是尽量去做正确的事，如果我们继续兼容ie6，那它就会一直存在，只有我们联手去抵制它，web才能前进。 总的来说这届qcon还是受益良多的，国际上的领跑者已经在各个应用领域作出了很多研究，这里也分享了一些开发中遇到的问题，国内的领跑者也在前行中分享了不少开发中的经验和教训，也已经通过开发中的这些经验教训抽象总结出了不少好的作品做开源来推动国内的开源事业。只不过个人感觉互联网大公司之间的沟通交流还十分有限，都在着眼于各自的开发问题而造新的适合自己的轮子，如果将来能多做沟通形成标准，提出一套通用的类似Dynamo一样量级的解决方案或理论实践就更美好了。 BTW: 会展有很多细节做得还不太到位： 同声传译是个老问题，就第一天试了一下，后面还是干脆听原声来的清楚，明了不漏词。 座位没有学习电影院的排法，交错排放，前面人腰板一挺直，我就看不全ppt的幻灯。 主持人有些时候给人的感觉不太专业或者说不会把握FAQ环节的节奏，有些时候甚至该进入FAQ环节了人还没出现。
四
阿熊QCon笔记1
四
阿熊QCon笔记0
Michael Nygard 失败来临的征兆 基本上从经验上总结了系统的各个开发阶段可能出现的问题，qa并不能完全保证系统的可靠性，线上的情况很多时候无法预测， 所有着一些的Fault/Failture的预防方式给出了很多有益的建议，关键点是 尽可能完善的测试， 控制错误传播的范围， 降低服务间的耦合性以及服务间的依赖关系， 在SOA的体系中要有所谓的严重错误Breaker机制来预防蝴蝶效应带来的一系列严重后果。 另外举的一个服务压力由于突发性事件而导致的整个系统后端处理能力不足的问题，我想这也和bluedavy之前twitter里提到的的QOS不谋而合。 Paul King 动态语言的敏捷开发实践 总结了比较好的语言开发中的包括设计模式、语言特性等等开发方面的问题，但提出的解决方案groovy个人而言觉得思想上在现阶段的企业开发中还有所欠缺。 groovy也许可以提供更高速、敏捷的开发方式（或许在将来会是一个所有语言发展的趋势），但他依然存在动态语言的一个不容回避的问题-性能，尤其在企业SOA服务化的进程中，性能往往比较重要。paul在Q&A环节也遭遇到了这一问题，他也非常委婉的表达了动态语言的强项主要在敏捷开发上，同时底层依赖于java的服务，如果有必要则可以改写成java。 其实现有的企业解决方案中已经有了比较适合的方案，比如Cython之于python在豆瓣上的应用，又比如hiphop-php之于php在facebook的应用，虽然目前的应用面不广，语言跨度也仅局限于php和c++，但理念比较实用：动态语言编写，编译成静态语言和对应的字节码运行。这种理念即有了动态语言的灵活快速迭代开发的特性，又有了编译语言的高速高效，同时在系统逐渐稳定需求沉淀后，进一步对生成的静态语言代码做进一步优化和编译即可。 系统架构与最佳实践及创新的关系，李伟 关键词： 架构师：强制技术约束 Operational Concept 设计最佳实践： 并发能力，队列和调度 容错能力，识别，检测，评估，恢复，掩盖
