大会背景
时间：2017.12.8~2017.7.9
地点：北京
会议：ArchSummit -北京 2017架构师峰会
日程：http://bj2017.archsummit.com/schedule
我关注的点
- 架构升级和优化
- 高可用体系的一些专题
架构升级和优化
爱奇艺移动端架构演进
- 分享了爱奇艺从php到java的技术转型中遇到的问题：技术栈的切换，开发人员的技术转型，技术组建更替迭代。
- 从三个方面爱奇艺的移动架构优化：快（cache+异步）、稳（熔断+限流+灾备）、准（系统监控+业务检测）
转转的推荐系统升级之路
分享了转转的推荐系统架构的升级之路：
- 粗力度的个性化推荐
- 细粒度多维度个性化推荐：增加用户画像，增强数据复用性，属性级别细化
- 实时的推荐系统：离线处理用户画像，用户兴趣实时化
- 基于ML的排序模型、找回模型、用户兴趣模型
知乎feed流架构演进
- 所有人的Feed 都一样(热门榜单)
- Feed 个性化，推模型：大V的粉丝难以实时分发、资源消耗大、排序难以实时调整、基于关系链的变更过滤难做
- Feed 个性化，拉模型 + 离线计算(预计算)：资源冗余大、rt长、计算策略复杂、算法难以实时调整
- Feed 个性化，拉模型，采用 Redis Module，将计算下沉接近存储：
高可用架构体系
滴滴的高可用架构
1.业务增加的压力下带来的架构演进 
2.高可用的抓手 
3.滴滴也搞了一套多活的架构，和集团不一样的地方是滴滴做的是同城多活，可以理解为同城下的单元化架构。 
4.滴滴在数据同步方面划分了不同维度的数据，使用了不同的数据同步方式。 
微博的弹性调度
微博的业务场景：热点事件，如鹿晗恋爱、谢娜怀孕
微博调度系统的架构演进：
- 人工：运维同学手动扩容
- 自动：根据QPS、AvgTime定时定量去扩容
- 智能化：根据RT/SLA/SUCCESSRATE做容量计算，每分钟进行采集和水位判定，达到预先设定的阈值水位进行自动扩容。
智能化弹性扩容中：
1. 为了防抖，每5分钟满足3次采集水位点才算达到阈值水位。
2. 为了计算准确性，去掉了性能最好和最差的百分之十的流量，计算中游的80%的流量。
看分布式服务化架构关键技术：左耳朵耗子
耗子哥的原标题是:不改一行代码提升系统的性能和稳定性并支持秒杀：看分布式服务化架构关键技术。看到这个标题还是很好奇的，带着疑问提前一小时来到耗子哥的专场，发现只有地下可以做了，再晚一点连站着的地方都没有了。
1.耗子哥分享了他们的统一监控架构设计，通过日志的收集->聚合->计算->执行监控。
2.基于网关的流量调度技术，吧很多的事情前置到网关层去做
3.提到了如何不改一行代码：做秒杀、提升稳定性
3.1. 先思考下，不改代码的情况下如何让一个性能很差的系统支持秒杀的场景？
耗子哥的案例中：通过流量网关，做一个随机数的规则开关，随机的结果不符合开关规则就会丢弃该请求，随机数的规则是根据请求数，以此达到随机流控的效果，间接的支持了秒杀。
3.2. 如何不改代码节省百万的成本：原系统使用阿里云存储，阿里云价格较为昂贵，想切换到其他存储方，但是小厂家的储存的稳定性没有保证。最后选择使用小厂家的存储做主存储，阿里云作为关键数据的灾备，既节省了成本又保证了数据可靠性。
启发：在听这个分享之前，我一直在思考如果是让我不改代码支持秒杀，我会怎么做，心中一直没给自己一个满意的答案，虽然今天在听了耗子哥的方式之后，会给我们一种标题党的感觉，但是回头认真思考会发现，其实作为技术人员，我们往往容易在做事情的时候吧自己限制在自己的思维空间呢，很多事情都行通过技术来改变，但是有些时候一些东西其实是可以换一种方式更轻松更高效的解决的。
