美团点评境内度假事业部，在业务3位数增长、单日交易额破亿的同时，涌现了不同的交易系统，从标准单要素品类，到非标品类，和套餐品类，这对长远的用户体验统一和业务迭代带来了新的挑战。

通过对业务的深入思考，国内外分析，和架构设计，我们针对正向、逆向交易流程进行了统一建模，实现了从流程到数据的交易系统统一，更好的支撑了业务长期快速推进。融合后，新品类交易拓展速度大幅度提升

演讲提纲

• 交易系统融合的背景及问题；
• 融合的方案选型及挑战；
• 架构设计实践；
• 平台的不利因素以及如何规避。

听众收益

• 大型O2O电商平台交易系统架构实践；
• 融合多业务元素的交易平台建设中的架构选型和思考；
• 大规模交易系统分拆已属不易，系统合并又会遇到哪些挑战；
• 平台系统扩展性红利的背后，会带来哪些不利因素，如何通过更好的架构来规避。

在云计算场景下，分布式系统调度器面临着海量任务带来的性能挑战。如何提高调度器的吞吐率？如何加快云主机的创建速度？如何应对用户潮汐式的波峰购买行为？面对这些问题，传统云计算系统和调度架构已经很难给出应对方案。

CVM团队采用多调度器架构和乐观并发控制，有效提升调度系统的并发度和吞吐率；同时，尽量避免调度冲突，以较小的代价处理调度冲突。实现了一款经过公有云验证的高性能分布式调度系统。

听众受益

• 了解大规模分布式调度系统面临的性能挑战和传统调度器的性能瓶颈
• 了解多调度器并发架构的设计思路与实现细节
• 了解公有云调度系统的运营经验

摘要：

背景：知乎首页信息流根据业务类型（实时性，资源节省，算法排序）选择了 PULL 类型的架构，而且系统中存在大量过滤，会产生反复到底层 feed source 拉取的问题。响应时间受到了比较大的影响达到了 1.6s。

解决方案选型：尽量使计算接近存储，节省网络和序列化开销。使用最新的 Redis module 技术，定义针对首页业务逻辑的 Redis 接口。

方案介绍：将一部分计算逻辑迁移到 Redis 内部，使数据（使用 protobuf 压缩）和计算完全在内存中进行，减少无效网络传输，大大提高计算效率，降低了响应时间。而且 Redis 内部的计算逻辑改变时，不需要重新编译 Redis，只需要动态记载计算逻辑部分即可。

实施后效果说明：响应时间 p95 1.6s - 700ms，节省内存 1T，CPU 500 个，减少首页依赖服务 1/2 的 qps。

演讲提纲：

• 知乎 feed 流业务应用场景和需求介绍；
• Redis module （计算接近存储）的技术方案介绍：
  • a. 为什么选择 Redis module 技术（计算接近存储），介绍优势和劣势；
  • b. Redis 内部的存储 schema 设计；
  • c. Redis module 的基本原理和实践经验。
• 未来的规划与挑战：
  • a. Redis 单线程，CPU 过高问题的解决；
  • b. Redis module 部署问题的稳定性。

听众收益：

1. 了解 feed 流架构的设计经验和一般解决方案；
2. 了解新技术 Redis module 在实际生产环境的使用经验和教训。

在社交网络领域，基于社交关系的内容分发是整个信息架构的一个重要部分。传统的产品主要通过时间线的方式对这部分内容进行组织，但这种方式在内容分发效率上存在较明显缺陷。如何在原有的分发系统上进行演进，引入算法对Feed流进行个性化的分发，同时保持用户浏览体验不至造成混乱是一个很大的挑战。

musical.ly的服务器和算法团队在这个领域进行了较深入的探索，实践出一种可行的的设计方案。

演讲提纲

• 简单回顾推拉结合模式下的Feed流架构；
• Smart Feed的主要需求和挑战；
• Smart Feed的设计思路和架构；
• 实践中的重难点。

听众受益

• 了解大规模社交网络中基于时间线的传统Feed流架构；
• 了解大规模社交网络中Smart Feed的主要产品需求；
• 了解Smart Feed的设计思路和实现细节。

讲述了全民K歌从零到千万在线的产品发展过程中，后台服务架构的演进，通过对UGC系统，流媒体上传下载体系，道具礼物体系，注册登陆系统，排行系统等核心模块的不断优化与重构，以适应快速增长的用户规模，从根本上保证了产品的高速增长。同时，介绍了在产品发展过程中，遇到的层出不穷的黑色产业模式与内容，以及业务是如何与各式各样的黑产做对抗，为用户提供了一个相对安全，干净，公平的平台，保障了用户的利益。

听众收益：

1.海量服务架构价值观与实战；
2.黑产对抗技术与经验；
3.产品高速发展过程中技术与团队面临的问题与应对方式。

京东虚拟商品系统有十几个业务线，几十个系统，上百个服务，高峰期每天几百万订单。业务的多样性，带来系统、服务、业务流程和复杂度的差异。通过分析和解决这些系统遇到的各种不同难题，分享如何有针对性的进行分布式系统可用性架构设计和实践经验。

演讲提纲

• 简要介绍高可用性的度量和考虑；
• 京东虚拟商品系统的高可用架构设计实践。通过分析遇到的问题及解决方案，分享京东高可用性设计的经验：

1. 供应商系统集成（原始数据本地化、分批多次加载、异步化） 
2. 服务耦合（服务启动耦合，事件驱动设计） 
3. 服务降级 
4. 补偿 
5. CQRS 
6. 定时任务

• 系统部署的高可用性 
• 双十一高可用性保障

从压测演练、运维监控、场景故障模拟、应急方案等方面介绍如何保障系统在大促时的高可用性。

听众受益

• 高可用性系统设计的度量和权衡； 
• 服务高可用性架构设计、部署和实践； 
• 大促时系统的可用性保障措施。

当一个公司有多个业务订单，每个业务订单有不同的属性，不同的状态时，订单中心是分开，还是合并，是一个让人头疼的业务架构难题。

• 分：如何满足个人中心订单列表的需求？如何满足订单统一对账的需求？ 
• 合：如何满足各业务侧个性化的属性需求，状态需求？

本次演讲将介绍58到家的订单中心业务架构演进，分享58到家订单中心踩过的坑，以及填坑方案。最终达到既能满足统一的列表、对账需求，又能满足业务个性化需求的效果。

业界，99%的公司是中小公司，他们的业务在快速增长与迭代，架构面对需要“支持高扩展性与高可用性”的变换可能无所适从，58到家的系统架构演进，能够真正解决他们实际中的问题。

演讲提纲

• 分还是合，多业务订单中心的痛点；
• 架构分离的常见方案及优缺点；
• 架构合并的常见方案及优缺点；
• 58到家订单中心架构实践。

听众受益

• 了解多业务订单中心架构设计可能面临的潜在问题；
• 了解多业务订单中心分离架构的常见方案及优缺点；
• 了解多业务订单中心合并架构的常见方案及优缺点；
• 58到家订单中心的业务架构设计方法论，对其他业务架构设计的借鉴与启示；