2015qcon大会点滴记录

前言

三天的QCon大会过得挺快的，感受到了技术的热情，总体开拓了视野，对于大会中的一些印象比较深的TOPIC做一个记录，分享出来。

 

• 针对失效或者异常部分进行系统设计，在设计层面来规避问题的产生
• 《针对失效的设计-Uber》这一块是他们首席架构师讲的，片子内容不是很饱满，基本每个片子一个主题，然后围绕主题来进行演讲。总体感觉Uber的业务发展比较快，最开始的时候系统都是外包出去做到；
• 针对失效的设计，这一块回归目前的工作内容看，平时在系统设计的过程中，极端异常流程考虑的比较少，例如一个订单100个子订单，正常情况下不会超时，但是如果一个订单2000个子订单，这时候，会引发很多超时，带来的直接就是咨询以及占用技术的时间来进行问题排查，当然这个仅仅是一个比较典型的例子，最起码系统在设计的时候，就应该是100%的，否则实现起来，务必有折扣，针对失效或者说针对异常，来梳理整体的架构，从宏观和微观角度进行改善；
• 业务监控，在系统构建之初就考虑
• 《大众点评的CAT监控》这个TOPIC刚开始没打算听，因为看演讲者工作5年，可能经验不是很丰富，不过看介绍，在过去5年的时间中，差不多一直在业务监控领域，于是听了一下，整体的架构在听之前也猜得差不多，在架构这一块没有惊喜，但是对于系统运行过程中，对于内存、CPU的几个问题案例，印象比较深刻；
• 其实对于每位开发同学来说，在代码编写的过程中，就应该有意识的考虑监控怎么做，是简单的写日志，然后基于日志来做，还是基于业务数据来进行定时分析，需要考虑细致，这样健壮性自然就提升上来，最起码在有问题的时候，能够第一时间感知到；
• 针对证券交易系统的高性能、易扩展、高可用的分布式系统的模式介绍，目前看抽象相似问题，然后提供模式解决方案，设计模式在java 编码层面，细细想的话，想性能优化、系统稳定、架构高可用，其实够可以列举模式出来
• 组播，分组的策略，基于组播的服务发现和消息路由，总体来看，服务A和服务B之间进行调用或者发送消息，如果服务B是一个集群，那个A到B之间，怎么个调用或者投递，很有意思的一件事情，RPC的调用策略、消息投递、storm bolt节点的grouping都有体现；
• 使用消息总线来进行系统的异步化改造，在异步的同时能够解耦业务系统；
• Event Sourcesing，针对数据强一致的情况下的高可用架构，保留事件本身，使其可以追溯到，之后基于事件做业务逻辑或者数据分析；
• 分层架构，这个比较经典了，就不展开细说了；
• 线程池，队列模式，这一块在平时的代码中用的比较多，总体来看还是比较经典的生产者消费者模型；
• 消息中间件，目前对于互联网系统架构，已经必不可少了，业务异步执行来追求最终一致性，解耦业务逻辑
• 携程这个架构师讲解了他们的消息中间件，目前已经开源（Hermes），总体的存储是kafaka和mysql来可选；
• 系统核心概念，和公司的metaq、社区的Kafaka比较相近 ;
• 中间几个环节讲解了系统的优化，性能优化，一个繁琐细致的工作，需要在宏观和微观层面不遗余力的耐心找突破点，对于Hermes的数据库写入，索引优化、消息buffer、polling机制等等展开介绍；
• 听云科技基于Java Instrumentation来构建系统监控，APM领域这一次公司挺多，还有云智慧，他们都是专注一个环节，就是系统性能优化，针对系统层、网络、存储、业务系统层收集数据，进行分析，诊断性能瓶颈，总体都是若侵入的思路
• 基于JDK5的这个特性，很早公司也有做过，不过后来没有推广起来，弊端就是需要运维同学在每台机器上面安装java agent 从而注入字节码来获取性能分析所需要的数据；
• 除了通过instrumentation的方式，还可以采用spring aop的方式，对于性能数据的采集，能够针对URL、spring、SQL等收集，这种方式的注入是业务系统需要埋点代码（不过大部分是配置文件），好处是业务系统在build起来的时候，就可以有性能的数据，无需增加运维同学部署agent了；
• 高德，快速转型期的稳定性实践，目前的稳定性，对于经验丰富的同学来说，可以摸索出一套模式出来其实，例如限流、隔离、降级、依赖梳理、容量评估、性能优化、预案开关、性能压测、系统监控、异步化、并发执行、容量评估、系统扩容等
• 高德的这个片子大体听了一下，不过在听的过程中稍微深入想了目前大家做稳定性的方法，总体比较相似，相似指的是抽象层面的描述；
• 系统稳定性，保证高可用，虽然有成熟的思路可以参考，但是实施起来，说实话是个细活，需要持之以恒的深入挖掘；
• twitter的Heron 替代storm的流式计算系统，在设计的概念上保留了之前storm的大部分概念，但是在开发语言上，替换为C++、java、python来进行，目前在twitter已经全面替换掉storm了
• 这个说来比较有意思，twitter开源storm之后，很多公司使用，在很多公司使用的大好局面下，他们自己废掉了，根据演讲者的说明，主要是storm的开发语言比较小众，还有就是拓扑反向控制方面比较弱，同时对于topology的隔离，以及worker task的易于理解等方面有痛点，在是否在sotrm的基础上升级还是重写上，最终选择了重写；
• 替换中间件，说实话比较难得一件事情，尤其是类似storm在内部已经使用的非常广泛了，Heron采取的策略是兼容之前所有的API，这样业务系统在替换的时候，能够非常容易的切换；
• 新版的Heron的stream manager是核心的组件；
• 大型分布式系统的黄金原则，听上去很高大上的TOPIC，不过演讲这通过几个案例来说明了几个比较关键的事情，有点标题党，不过内容还算可以
• 深入反思，什么是好的监控，好吧，再一次提到了监控；
• 对于测试环境和线上环境的差别，要能够比较深入的认识；
• 系统可用性99.9%是不可以的；
• Sensors Data 核心成员来自百度的大数据部门，总体提供的还是数据分析的产品，可以SAAS访问，也可以独立部署，比较感兴趣的是，对于数据分析的场景做了抽象
• 事件分析，抽象事件模型，进行筛选、聚合、分组分析
• 漏斗分析，分析一个多步骤的过程每一步的转化情况和流失情况
• 留存分析，关注用户参与情况和活跃情况的分析模型
• 回访频率
• 技术管理之巅的作者，之前在一号店，现在去海尔了，讲了用数字来衡量软件开发的过程，总体感觉不错
• 虽然听了之后觉得不错，但是反思软件开发，并不像工业级作业，能够非常精确的计算出工时，毕竟，软件开发其实是一个创造性的工作；
• 量化可以量化的一切，部分情况下我们确实需要记录软件开发过程中的数字，例如过去三个月做了多少需求，多少项目，对于业务带来的价值，是否满足了业务的期望，同时业务对于技术的承诺是否兑现，等等；
• 关于Docker，目前很多公司的虚拟化采用docker来实现，再一次感受到了docker的火热
• docker是系统虚拟化的整体解决方案，会议期间总体的看了一下，没有十分深入；
• 使用docker来进行虚拟化，比较关心的是对于业务系统开发的影响，目前按看之前大多数JVM是跑在VM上的，现在JVM是跑在docker里面，总体感觉应该不会对于日常的开发对带来很大影响；
• 没有搞明白的是，为啥docker火起来了，空了深入研究一下；
• 写在最后
• infoq的活动组织的比较给力，考虑的比较周全，例如邮件多次提醒形成，现场的日程材料，吃饭的安排，会场的布置，演讲者的时间控制，都非常专业，对了，还有同声翻译也不错（不错翻译的妹子专业性有待提高）。
• 对于监控、性能分析、云端存储、Docker容器、消息服务、BAAS开发模式、移动数据分析、企业统计分析等等专业领域，感觉创业公司的热情十足，在专有领域深入，对于业务开发的同学提供选择，非常不错。
• 总体缺了啥，目前看在特定领域的介绍挺多，不过部分有做广告的嫌疑，对于平时做业务系统开发的我们来说，如何开发高可用、高扩展、高伸缩、高性能，以及低耦合、易维护的业务 系统，以及对于复杂业务系统的架构经验，少了一些介绍。