支持菜鸟仓储物流业务发展的技术体系分为四个部分，也是演讲的重点。一是仓储管理物流业务平台，重点讲解在业务平台化技术的探索和实践，平台型系统架构特点以及应对方案，抽取一个服务化，模块化以及扩展的典型案例。二是数据驱动的智能化仓储管理，数据技术的典型落地，数据驱动的智能化应用系统的技术挑战以及应对方案，尤其是“出库优化”这个仓储管理领域的世界级难题是怎么解决的。三是云化架构以及国际化架构，菜鸟网络在这方面的最佳实践。四是IoT场景下菜鸟网络的探索，以及平台如何应用无人仓的接入，仓储领域的自动化实践以及踩过的坑。

演讲提纲：

1. 菜鸟仓储物流平台介绍铺垫
2. “一笔订单从仓库发货”的小故事说起
3. 典型案例分析：仓储物流平台的平台型架构为什么做，怎么做以及效果分析
4. 数据驱动的智能化仓储管理，智能应用系统架构实战总结，出库优化和空间布局优化作为案例
5. 新加坡部署典型案例：云化和国际化的痛点以及挑战
6. IoT场景下的实践，自动化机器人作为案例
7. 总结：不同场景下的应对方案

听众受益点：

• 业务系统如何做平台化升级
• 了解业务系统如何做数据驱动的智能
• 了解IoT在仓储领域的挑战以及应对措施

在软件行业，我们观察到多代架构演进，旨在最大化系统可扩展性，如吞吐量，延迟和产品质量。扩大软件开发过程本身的问题已开始获得可见性，但尚未得到很好的解决。

LinkedIn 的 Feed 是我们业务的核心，因为它既是默认的登陆体验，也是不同类型内容(新闻文章，视频，图片，广告，工作或人员推荐等)的主要分发渠道。多年来，LinkedIn Feed 在用户参与度和业务影响方面显著增长。然而 Feed 产品迭代速度方面却受到严格限制：向 Feed 生态系统整合任何新类型的内容(例如视频)通常需要1到2个季度的开发工作。

为什么整合门新内容如此昂贵? 这主要是由于 Feed 生态系统本身的复杂性。该系统包括多个领域，如 Feed 前端，Feed后端，Feed 相关性和个性化，下游通知/推送/电子邮件以及跟踪和分析产品。在这个生态系统中加入一种新的内容类型需要与上面提到的每个域系统集成，因此成为一项高成本任务。

本次演讲，我会分享 LinkedIn 旗舰 Feed 的平台化工作，从而显著提高产品迭代速度。这项工作需要通过改善整个 LinkedIn 旗舰 Feed 生态系统的基础设施，推动我们现有技术的发展。通过平台化整个 Feed 服务堆栈，我们实现扩展软件开发并对工程效率产生正面影响。

听众受益点：

LinkedIn 旗舰 Feed 平台化工作对我们的工程效率和产品迭代速度​产生了​显著的正向影响。这一战略的核心思想是扩大的核心组件的演变灵活性，从而达到最大限度地重用现有组件和服务而不是从头开始重复构建功能。本议题会深度分析若干LinkedIn 旗舰 Feed 平台化的子项目实例，从而使听众了解到优化工程效能的可行策略。

过去15年中，互联网产业开始蓬勃发展，基于互联网的各类应用大放异彩，而在信息技术上，企业应用架构也逐渐从传统的ERP，JavaEE集中式应用开始走向互联网、云计算、分布式服务化架构的转型，在这个过程中，数据中心及应用的配置管理这个领域也发生了深刻的变化。

本次演讲会介绍在现代企业应用架构中，传统的围绕分散的配置文件为中心的配置管理方式在面对诸如微服务、DevOps、容器服务、云计算等新技术形式下面临的挑战。同时会探讨如何通过独立的配置中心服务集中式管理数据中心中的所有配置来解决这一挑战，也介绍阿里巴巴在该领域的开源建设的项目进展以及 OpenConfiguration 规范建设的最新进展。

演讲提纲：

• 现代应用架构在配置管理上面临的挑战
  • 配置管理是软件生命周期的重要组成部分，头疼的配置飘移（configuration drift）问题
  • 分布式系统给配置管理带来的挑战
  • 云计算与配置管理，会介绍AWS以及阿里云在配置管理领域发展的最新进展
  • 容器化、调度与配置管理，会介绍阿里云容器服务(Kubernetes ConfigMap）与配置管理的最新探索和实践
  • 配置的安全与合规在云原生时代面临的挑战
• 业界在配置管理上的创新进展（包括介绍阿里巴巴以及Facebook等业界互联网公司在这一块的卓越工作）
  • Facebook的一揽子配置管理方案
  • Google的Config Push Service主要实践及应用场景
  • 阿里巴巴在配置管理上开源的最新进展 (Nacos在配置管理领域的最新发展和规范）
• 关于业界推进 OpenConfiguration 规范的倡议以及工作进展
  • OpenConfiguration 开源项目的主要规划与目标
  • OpenConfiguration 规范的主要框架的介绍
  • OpenConfiguration 主要参与方、贡献者介绍以及社区如何参与演进
  • OpenConfiguration 如何沉淀并影响微服务配置管理最佳实践

听众受益点：

• 帮助听众了解业界在配置管理上的新方法、最前沿的动态；
• 帮助用户了解在采用 Cloud Native，MicroService，DevOps 等新架构方法的现代应用在配置管理上面临的挑战，了解最新的最佳实践；
• 帮助听众在新技术形势下更好地解决如配置变更引起的可用性风险，业界知名的配置飘移，分布式架构的演进式架构等问题。

满帮业务核心是ToB的，使用者处于企业的各层级，有不同角色、职能，并且每个公司的业务场景千变万化，业务规模各不相同，发展阶段参差不齐。同时，B端客户还有包括稳定性、安全性、可扩展性在内的各种系统性要求。有一个稳定的基础设施平台，可以在上面灵活快速地进行业务开发和能力输出，是公司的核心竞争力之一。

从2016年开始，货车帮技术工程部在进行基础设施建设的时候，一个核心的任务就是提供一个云原生平台，为软件交付的过程服务。在综合考虑了各方面因素后，自主研发了包括API网关Lorentz，容器管理平台Planck，统一监控系统Galileo，微服务编程框架Maxwell，配置管理中心Kip等组件在内的Newton平台。

Newton交付使用后，对业务的稳定性、灵活性都有极大贡献。同时团队的lead time/MTTR/change fail rate/deployment frequency等核心指标也变得可视化，显著提高了技术团队的工作效率和质量。

演讲提纲：

1. 简单介绍

• 1.1 行业现状
• 1.2 货车帮业务特性

2. 做什么

• 2.1 云原生平台
• 2.1.1 非云原生阶段（自建／托管／IaaS）
• 2.1.2 云原生阶段（非结构化／结构化云原生平台）

3. 怎么做

• 3.1 别人怎么做？
• 3.2 我们怎么做？
• 3.2.1 系统架构
• 3.2.2 功能设计
• 3.2.2.1 编程框架/脚手架/最佳实践
• 3.2.2.2 持续构建/持续集成/持续测试
• 3.2.2.3 镜像化持续部署
• 3.2.2.4 API和架构治理
• 3.2.2.5 弹性基础设施
• 3.2.2.6 配置管理/运维工具
• 3.2.2.7 统一日志监控
• 3.2.3 实施路径
• 3.2.3.1 从运维切入
• 3.2.3.2 从研发切入
• 3.2.4 实施效果度量
• 3.3 为什么微服务编程框架不用Dubbo／Spring Cloud / Istio？
• 3.3.1 Dubbo
• 3.3.2 Spring Cloud
• 3.3.3 Istio

4. 后续计划

听众受益点：

从云到云原生，从Microservices到Service Mesh，DevOps到AIOps，这些年技术圈子的流行语一直在变。作为一个架构师甚至是技术管理者：

1. 如何在公司高速发展的工程中，根据团队和业务的发展阶段和特点，做出合理的技术选型；
2. 如何进行组织架构、流程规范、绩效考核等各方面保障架构得以实施和落地；
3. 如何通过代码化、自动化、可视化的管理手段，真正的提高研发团队的效率和质量。

滴滴每天服务几千万人次出行的过程中，产生了海量的行为、日志（log/binlog）数据，这些数据需要及时、完整的同步到大数据体系中，以满足数据仓库，实时计算、Trace与监控系统、安全管控平台，客服与Miss系统等场景的数据同步需求。面对数以万计的服务节点，数以千计的数据库实例，复杂的线上环境，严格的资源消耗，秒级的延时要求，提供一个稳定、及时、安全、易用的数据通道是一个充满挑战的问题。

本次我将分享滴滴在数据通道的架构过程中，踩过的坑、架构的演进、背后的思考。

演讲提纲：

1、问题与挑战

• 问题
• 挑战

2、架构与优化

2.1 架构1.0--简单、快

• 2.1.1 架构关注点
• 2.1.2 架构图
• 2.1.3 存在的问题

2.2 架构2.0--稳定、易用

• 2.2.1 架构关注点
• 2.2.2 架构图
• 2.2.3 存在的问题

2.3 架构3.0--及时、完整

• 2.3.1 架构关注点
• 2.3.2 架构图

3、总结与规划

听众受益：

1. 如何打造亿级TPS的实时数据通道，架构设计背后的思考，平台化建设的思路
2. 如何保障数据的及时性、完整性
3. 如何进行数据链路的延时与故障检测
4. 如何进行故障的快速恢复
5. 如何进行全局性的限流与降级

微信 PaxosStore 是一个分布式存储系统，创新的无租约 Paxos 工程实现，实现三园区多主多写，任意角色宕机时系统无需切换周期，真正实现实时可用，平滑服务。

PaxosStore 广泛支撑微信在线应用，峰值过亿TPS，运行在数千台服务器上。PaxosStore 在数据分区内部提供完整的串行ACID语义，支持键值/队列/集合等数据结构以及二维表，单表可超亿行并提供SQL接口支持业务快速开发，通过跨园区数据中心间的同步复制提供强一 致性和高可用性。该系统在2017年除夕夜实践中，平稳应对百亿级每分钟的挑战。

最近一年，特别是支付业务对 PaxosStore 提出了更高的要求。而本次演讲将会给大家带来 PaxosStore 在支付业务上的实践经验，面对复杂的支付业务，存储平台如何做到与业务解耦，操作流水入库如何做到不重不漏，金融级可靠的远距离容灾，不应该只是简单的改变数据副本的物理距离。

演讲提纲

1、问题与挑战

2、微信支付业务的支持

• 2.1业务数据结构抽象
• 2.2业务逻辑和存储解耦
• 2.3统一入库系统

3、远距离（上海 - 深圳 - 天津）容灾的高可靠存储设计

• 3.1服务高可用
• 3.2数据强一致、低延迟

4、集群的扩容与缩容

• 4.1基于范围的通用伸缩系统
• 4.2IDC自治，独立伸缩

5、未来规划

听众收益：

1. 了解支付业务的抽象以及解决方案；
2. 了解远距离容灾高可靠存储的设计要点。

微软小冰是微软（亚洲）互联网工程院基于2014年提出建立的情感计算框架，通过算法、云计算和大数据的综合运用，采用代际升级的方式，逐步形成向EQ方向发展的完整人工智能体系。

智能助手就是小冰其中的一个方向。本次演讲主要介绍了小冰智能助手目前的现状和未来的发展方向。其中小冰的感官可以分为初级感官，主要包括文字、图片、语音、视频等，这是一种更加依赖人工输入、不自然的沟通方式。与之相对的，就像人与人之间更自然的交互方式一样，我们称作高级感官，它包括全双工语音感官，和全双工视频感官。

本次演讲会重点介绍小冰在这全双工语音和全双工视频两个方向的经验与心得。

演讲提纲：

1. 全双工语音感官 
2. 全双工视觉感官 
3. 两种感官的结合

听众受益点：

• 了解智能助手未来发展趋势
• 了解小冰的全双工系统结构
• 了解如何结合语音与视频，更自然的服务用户