比较早的预定了这次的北京qcon会议，中间出了点变化，差点此行不能启程，正应了那句老话，夜长梦多，后来总算是顺利出发，算是好事多磨吧。
这是第二次去qcon，第一次是去年qcon的杭州站，由阿里集团联合主办，这次的北京是百度，这种的会议少了当地的大型企业很难支撑起来，这个也是为什么qcon这么多年了，但是一直没来上海，因为上海本土缺少一个重量级，在国内说的上话的IT企业，而且最好是互联网企业，但是听说10月份会来上海，不知道是会和谁一起承办，这个公司出了BAT三家之外能进入qcon的视野的话，基本算是在上海技术界拥有比较大的话语权了，盛大在没落，携程是业务驱动型企业，点评还未成气候，1号店在电子商务领域还只是沧海一粟，豆瓣？可能吧，到时候就知道了！
这三天，选择性的听了一些课程，有好有坏，好的专题也并不是说醍醐灌顶的给你一个很好的解决方案，在大的技术层面，一般的公司大多还只是在炒冷饭，将一些已有的概念结合自身的特殊业务，加上包装，再拿出来卖弄下。目前也就google可以创造性的提出一些东西，类似mapReduce之类的学术论文。
还是回到主线，本次会议接受到好的东西就是那些大规模的公司把你一些想法加以验证是否可行，这个就足够，明确了大致的方向，具体的操刀还是靠你自己把握。打算其中的两个演讲做个详细记录，其他的大多没什么可取之处，会单独开篇的一笔带过。分别是Architecture Design and Architects和分解应用程序以实现可部署性和可扩展性。两个主题演讲在一头和一尾，是否可以认为好的东西是放在最前面和最后面呢？
林仕鼎：Architecture Design and Architects （架构设计与架构师）
讲的还是蛮落地的，但是有一些人觉得他太过虚，个人感觉还是有料，梳理了之前个人对于架构，对于设计中的一些概念，因为没有落地到具体的技术实现上，所以让人感觉比较虚。不同层面的架构设计原则又是不同的，很难很全面的去阐述，而且在最后的实际案例中举了三个不同业务模型下的架构设计，实虚结合，算是好的分享。有时候好的分享并不是具体到某某框架的具体实现才算是。几个核心的观点总结：
代码=数据结构+算法
软件=代码+架构
系统=软件+资源
大规模系统=系统+分布式架构
云=大规模系统+人+数据
最后的云，通过分析数据+人改进原来的架构以更符合我们的业务场景，很重要的一点是做业务架构不要考虑什么重用，只需要考虑可伸缩即可，因为你的业务就是特殊的。
架构中的组合方式：
- 1.结构：高层次的分解及模块的划分
- 2.交互方式：划分后要解决的是模块之间的划分方式 同步还是异步。 异步通常是为了解决系统之间的偶尔和提升性能两点上。
- 3.发布部署模式：嵌入式、独立部署、唯一实例等方式
架构师的要求
- 1.把握全局：抽象业务，划分未及格模块，几个功能
- 2.降低复杂度：分解和划分
- 3.把握过程：敏捷、迭代等方式
常见的模型解决方案
实例--存储
- 存储结构：File Object Table
- 数据特点：可变性，大小，数据结构
- 访问模式：实时读写、批量读 实时读、流式读、范围查询
- 实时性：非实时性、高实时性、一致性
矛盾：
1.延迟与吞吐
2.随机与顺序
3.规模与实时性
可采用考虑的模型
1.B+树 (实时、随机)
2.Log-based (批量、顺序)
两种方案有各自的有点
对于大的数据可以按照B+树，顺序性能好
对于小的数据可以按照LogTable：随机性能好
正因为这两种处理模型有自己的优缺点，所以在一个系统我们根据系统局部的不同特性选择其中合适的一个，但是有点会违反我们的设计的一致性。
其他的解决方案
1.弱化需求，是否有必要一定是实时性、高一致性
2.局部数据的特性处理，例如热点数据的处理
3.按照实时性、空间进行切割：例如一行数据只有一个字段的数据是热点数据，那么针对该字段做特殊的处理，可以剥离这个字段，也可以冗余这个字段(读取这个数据就是依据最符合业务逻辑的数据)。在解决分布式读写的R+W >N的解决方案中采用的就是类似方案
tips：
实时性：系统大之后就必然是分布式，那么分布式最大的一个问题是CAP中的C如何处理，多节点之间的实时性和一致性。
总结：分解系统的时候，只考虑我们关注的几个点，简化问题，再使用对应的模型，再在外面封装一层，满足自己的个性化需求。
实例--服务模型
因为服务是一个不平衡的流量分布，所以存在高点和低点，我们要处理的就是在高点时保持系统的可用性。所以我们的目标是
1.高吞吐
2.极限压力下的稳定输出
基本的处理模型
1.基本：threadpool + queue
2.复杂：Event-drivn 也就是我们所提出的EDA架构
两种的模型基本思路：并行和异步
稳定性保证：
1.减少资源分配粒度，主动调度 因为我们的请求是不均匀的，那么近
2.流量控制 ：
负载反馈、Throttling 极端情况下的服务降低等操作。
延迟截断 分级队列
这个是对于并行和异步的更细粒度描述，以保证系统的可用性。
实例--计算模型
- 大致分两种
- 数据密集型
- MapReduce、Scan-Filter
计算密集型
seti@Home
通讯密集型
- 机器学习系统
- 矩阵计算
到目前为止，上面就是我们常见的模型，要做的就是在实际的开发中选择合适的模型并在迭代中进行反复，直到找到适合的模型或是多个模型的组合。
架构师的三板斧
1.看清需求
tradeoff：
1)无法满足所有需求
2)无须同等对待所有需求
发现根本需求
1)分解、抽象、降维
2)定义primitive和组合规则
了解需求随时间的变化
对于不合理的需求say，但是要给出端到端的解决方案
2.选择方法、
- 测算、模拟、实现
- 分解、迭代
- 设计模式、设计原则、OO设计原则等等
3.把握节奏：
- 规划可达路径
- 定期产出
更多是从项目的把控上，更多是多方资源之间的协调
- 编程、重构是内力
- 学术论文是招式
- 项目是我们的实际经验
在上面的三个之间循环的迭代，不断的修炼自己。