您查看的活动已结束

由于疫情影响，本次分享调整为线上直播，欢迎大家入群与思否小姐姐一起学习分享~

SegmentFault D-Day，全称 SegmentFault Developer Day，是由 SegmentFault 发起主办的系列技术沙龙。自 2014 年启动，D-Day 技术沙龙已在北、上、广、深、杭等 10 个城市巡回举办了 19 场，涉及前端、云计算、后端、大数据、移动开发等众多主题，活动覆盖数千位开发者。

2021 SegmentFault D-Day 强势回归，传播前沿的技术实践内容，今年将于 7-11 月在北京、杭州、武汉、上海、深圳相继举行 5 场技术沙龙，聚焦云原生、大前端、技术架构、音视频技术、开源等领域。

杭州站 - 后端架构演进之路（70大大见面会！）

时隔两年，SegmentFault 再一次从帝都出发，在北京站的活动中，来自阿里巴巴、字节跳动、观测云、葡萄城等公司的前端技术专家为大家带来了精彩分享，现场座无虚席，讨论热烈。

这一次，思否小姐姐将携 SegmentFault 思否 CTO 70 大大（祁宁）一起为大家服务，来自网易、阿里巴巴、观测云、个推等一线大厂的工程师将为大家奉上关于后端技术架构的思考与实践分享。

日程安排

SegmentFault 思否 CTO 70（祁宁） 大大开场
5 位来自阿里巴巴、蚂蚁集团、网易有道、观测云、个推等一线大厂的技术专家，带来精彩分享

嘉宾及议题介绍

方杨，阿里巴巴技术专家《NOAH-面向业务价值的自适应高可用架构》

互联网后端系统 10 年研发经验。2017 年加入阿里，推动反应式架构（reactive programming) 在淘系业务系统落地。业界领先的将自动控制算法引入到系统负载保护，主导方案设计与在淘宝核心业务系统中的落地，现在淘系负责 Noah 自适应高可用体系的研发、推进端对端全链路系统保护方案和落地。

议题简介：

系统面临的流量不确定、日常业务迭代导致自身容量不确定性是线上业务常态的基础挑战/需求，还需要进一步为业务解决（进阶需求）：

1. 客户端大促活动入口潜在超大突发冲击流量下的确定性稳定性（如百倍于后端系统容量、百万千万 QPS）

2. 不同的业务请求（不同业务服务、同一业务服务不同场景）有不同的业务价值/优先级，期望系统能自动倾斜系统容量分配给高业务价值/优先级的请求

本次主题面向业务价值与端上大促入口突发冲击流量，从网关到业务系统全链路的应对不确定的业务流量的确定性稳定性方案，利用有限的系统资源实现业务价值的最大化。

NOAH 是淘宝自研的面向流量的全链路系统稳定性方案，以解决上面的基础与进阶需求：

• 业界领先的通过自动控制算法让系统在面对超额流量时，可以根据自身容量进行自适应的负载调节。

• 通过在统一接入网关的前置限流能力，借助统一接入网关的大流量处理容量来抵御大促入口突发冲击流量。

• 突破传统服务 api 划分边界的精细化流量划分

• 引入请求流量的业务价值/优先级表达结合自适应服务分组能力，实现不同业务请求面向业务价值/优先级系统自动倾斜与系统容量分配。

在众多双 11 核心业务落地解决了业务痛点并取得预期效果（如淘宝首页、直播、淘金币对主要业务接口的优先资源保障）

听众收获：

1. 淘系面对千万级大促流量的系统稳定性实践

2. 面向业务价值的系统容量自适应方案

蒋烁淼，观测云创始人《SRE工程的落地指南》

观测云创始人，资深系统架构师和软件架构师，Devops、SRE IAC理念推动者，也是国内最早一批投身云计算方向的创业者，在业界被称之为中国云计算试飞员，其创立的观测云品牌，快速推进了国内可观测性理念的发展，引领行业颠覆性数字化变革。

议题简介：

随着人类社会的进步，我们对于基于互联网应用的需求日益旺盛，任何一个互联网业务应用（电商，社交网络，游戏，云服务商，SaaS….）出现故障，将对用户，乃至于整个社会产生巨大的影响。在传统的故障处理模型不起作用的时候，SRE（Site/system reliability engineering) 工程这个新兴概念也应运而生了。SRE将以软件工程的方式重新考虑和定义运维。而如何运用系统的可观测性去具体落实SRE工程的实施，探究高效的跨团队组织协作模式，是本次演讲主要想讨论的议题。

听众收获：

1. 为什么需要SRE

2. 如何运用系统可观测性实施SRE

3. 如何搭建SRE团队

李能，每日互动股份有限公司（个推）服务端资深技术专家 《个推API网关演进之路》

2018年加入个推，现任个推基础架构研发主管。在大型系统架构设计和微服务方面有着丰富实战经验，曾亲历并负责个推消息推送系统多机房热备、推送私有云等大型系统的设计和攻坚，目前主要负责个推数据中台API平台的相关研发工作。

议题简介：

API网关是随“微服务”概念而兴起的一种架构模式。在微服务拆分过程中，API规模成倍增长，使用API网关进行API的发布和统一管理逐渐成为一种主流手段。

个推消息推送、效果广告、金融风控等业务的核心系统均基于微服务架构，部分系统也存在自建的网关模块。随着不同系统之间的依赖越来越多，接口治理也面临越来越多的问题和挑战。因此，我们希望引入统一的API网关来解决权限控制、流控、服务降级、灰度发布、版本管理等一系列问题。

个推API网关基于Golang自主研发，全Web化配置，实现所有API接口的标准化、可视化；除解决网关基础需求外，也支持了插件热更新、多协议转换、数据推送、集群级别资源隔离等进阶需求。除了整合到系统微服务架构中，个推API网关同时也作为公司数据中台流量入口，日均承担数十亿级的访问量。目前个推API网关新版集群已经稳定运行一年以上，在保障系统稳定运转的同时我们也在持续进化，围绕云原生探索更多的可能性，为业务提供稳定高效的基础平台。

听众收获：

1. 理解API网关在微服务架构中的作用

2. 了解个推API网关建设中的实践经验和深度思考

3. 了解常见的API网关核心组件及功能实现

4. Golang的网络模型解析和优化策略分享

毛雯蓓，网易有道资深开发工程师《自建私有云or公有云 —— 有道少儿团队的云原生实践与思考》

2014年入职网易有道，先后参与和负责有道云笔记、有道口语、有道思维启蒙、有道乐读等多个业务服务的研发。深度了解有道少儿团队部署在有道私有云和AWS公有云上的两套业务系统，参与技术选型和开发运维，推进其向云原生架构的转变。

议题简介：

随着技术更新和团队发展，有道私有云已基本实现了容器化、微服务等云原生特性，应用程序具备了动态伸缩能力，支持快速迭代和频繁发布。相比而言，公有云在按需交付、多地部署、弹性服务方面有更好的支持。
主讲人所在团队目前负责着乐读、思维启蒙、小班课等多个业务系统，由于不同项目阶段团队诉求的差异， 这些系统分别运行在自建私有云和AWS公有云两种平台上，它们在服务架构、技术选型、运维方式、团队分工上都有明显差异：

1. 对于业务团队，两种平台有各自的优点，私有云在数据安全、运维支持、集团内资源利用、使用成本方面有一定优势；公有云则是更成熟的云原生平台，拥有近乎无限制的缩放性和高可靠性；

2. 两种平台上皆可实现云原生的解决方案，同时使用两个平台会形成对比，引发团队持续思考与讨论；

3. 同时使用两种平台也存在一定挑战，主要在于两点：团队学习和合作成本、跨平台的子系统交互复杂度。

其中的差异对企业关心的工作效率、业务敏捷性、可扩展性、可用性以及成本的影响又是怎样的呢？
本次主题从云原生的4个主要方面：容器、微服务、持续交付、DevOps分别展开，分享团队对私有云和公有云在云原生上的一些实践和思考。

听众收获：

1. 团队就云原生的实践经验，如何在生产环境中运行云原生应用程序，如何设计云原生模式的应用程序；

2. 自建私有云和领先公有云对云原生支持的对比，实际使用中有显著区别的地方，如何综合利用其优点。

周斌杰，蚂蚁金服技术专家《service mesh 落地之后:为 sidecar 注入灵魂》

花名铭渊，ACG爱好者，前有赞中间件工程师，专注于基础设施与云原生领域，目前在蚂蚁集团中间件团队负责MOSN、Layotto等项目的研发工作。

议题简介：

随着 Service Mesh 在蚂蚁集团内部的大规模落地，我们逐渐遇到了新的挑战，这让我们迫切的寻找新的解决方案。
Service Mesh 通过引入 sidecar 来简化服务治理，但是随着探索实践，我们发现 sidecar 能做的事情远不止于此。一方面，给 sidecar 添加 Multi-Runtime 能力可以帮助基础设施团队更好的和业务团队解耦，简化多语言治理；另一方面，中立的 Runtime API 可以抽象基础设施、简化编程，帮助 k8s 生态成为真正的“分布式操作系统”，也帮助应用彻底和厂商解绑，保证多云环境的可移植性；与此同时，在 WebAssembly 日益火爆的当下，WASM 也能帮助 sidecar 实现 FaaS、业务系统 sdk 下沉等功能。

那么，Service Mesh 落地之后，架构演进的思路是什么？我们的思路是：为 sidecar 注入灵魂

听众收获：

1. 了解蚂蚁集团在 Service Mesh 大规模落地以后遇到的新问题以及对于如何解决这些问题的思考。

2. 了解 Multi-Runtime 解决的问题及实践经验。

3. 了解中立的 Runtime API 解决什么问题，以及相关实践经验

4. 了解 WASM 在 FaaS 等方向的探索。

特别鸣谢