• 比特币诞生，是世界上首个区 块链应用系统。发展至今有力 地证明了区块链技术的创新性、 颠覆性和顽强的生存能力 中本聪 比特币Bitcoin 2013 • 以太坊发布以太坊白皮书， 引入智能合约，推出首个 图灵完备的区块链平台， 进入区块链2.0时代 以太坊Ethereum 新基建 • Linux 基 金 会 成 立 了 Hyperledger开源项目，IBM、 Intel、摩根大通等企业加入，开 数据状态发生变化的 一次操作请求，如一 笔转账交易 将一段时间内发生的 所有交易和状态打包 成为一个区块 区块以时间顺序前后相 连，组成一种块链式数 据结构，即“区块链” 一词的由来 多参与方各自部署，互 联互通，每个区块链节 点均会保存相同的链式 数据，通过冗余存储的 方式使数据难以被篡改 区块链技术定义 9 趣链科技 版权所有 ©2016-2021 9 趣链科技 版权所有 ©2016-2021 可编程货币 可编程⾦融 可编程社会 合约层 智能合约脚本 算法机制 合约执⾏引擎 哈希算法 数字签名 P2P⽹络 传播机制 验证机制 默克尔树 轮胎、悬架等 基础硬件配置 电路油路 等传导系统 引擎、动⼒系统 汽油等润滑系统 车载⾃动化功能 公路、越野等具体场景 公有链基础架构⾃下⽽上分为六层：数据层、⽹络层、共识层、激励层、合约层与应⽤层。如果将区块链⽐作⼀ 辆汽车

2019 ) 2020 © Changkun Ou · Go 夜读 · Go 2 Generics? A (P)review 主要内容 ● 泛型的起源 ● 泛型的早期设计 ● Go 2 的「合约」 ● 上手时间 ● 历史性评述 ● 展望 泛型的起源 Origin of Generics 2020 © Changkun Ou · Go 夜读 · Go 2 Generics? A (P)review SFINAE ● 只有泛型函数的支持，泛型 结构需要通过函数来构造 ● 接口二义性 interface X { Y(Z) } ○ Z 可以是类型或常量名 ● 不太可能实现可类型推导 Go 2 的「合约」 "Contracts" in Go 2 2020 © Changkun Ou · Go 夜读 · Go 2 Generics? A (P)review Generics: Problem Overview 15 if v0 > vv { return v0 } 16 return vv 17 } 18 } 合约是一个描述了一 组类型且不会被执行的函数体。 关键设计 ● 在合约中写 Go 语句对类型进行保障 ● 甚至写出条件、循 环、赋值语句 评述 ● 复杂的合约写法（合约内的代码写法可以有多少种？） ● 「一个不会执行的函数体」太具迷惑性 ● 实现上估计是一个比较麻烦的问题 [Revised]

个大小不一的金圆盘。僧侣们不断地移动圆盘，他们相信在最后一个圆盘被正确放置的那一刻，这个 世界就会结束。 然而，即使僧侣们每秒钟移动一次，总共需要大约 264 ≈ 1.84 × 1019 秒，合约 5850 亿年，远远超 过了现在对宇宙年龄的估计。所以，倘若这个传说是真的，我们应该不需要担心世界末日的到来。 12.5 小结 ‧ 分治是一种常见的算法设计策略，包括分（划分）和治（合并）两个阶段，通常基于递归实现。 request”按钮即可发起拉取请求。 第 16 章 附录 hello‑algo.com 371 3. Docker 部署 在 hello-algo 根目录下，执行以下 Docker 脚本，即可在 http://localhost:8000 访问本项目： docker-compose up -d 使用以下命令即可删除部署： docker-compose down 16.3 术语表 表 16‑1 列出了书中出现的重要术语，值得注意以下几点。

64 个大小不一的金圆盘。僧侣们不断地移动圆盘，他们相信在最后一个圆盘被正确放置的 那一刻，这个世界就会结束。 然而，即使僧侣们每秒钟移动一次，总共需要大约 264 ≈ 1.84 × 1019 秒，合约 5850 亿年， 远远超过了现在对宇宙年龄的估计。所以，倘若这个传说是真的，我们应该不需要担心世界末 日的到来。 12.5 小结 ‧ 分治是一种常见的算法设计策略，包括分（划分）和治（合并）两个阶段，通常基于递归实现。 request”按钮即可发起拉取请求。 第 16 章 附录 hello‑algo.com 373 3. Docker 部署 在 hello-algo 根目录下，执行以下 Docker 脚本，即可在 http://localhost:8000 访问本项目： docker-compose up -d 使用以下命令即可删除部署： docker-compose down 16.3 术语表 表 16‑1 列出了书中出现

64 个大小不一的金圆盘。僧侣们不断地移动原盘，他们相信在最后一个圆盘被正确 放置的那一刻，这个世界就会结束。 然而，即使僧侣们每秒钟移动一次，总共需要大约 264 ≈ 1.84 × 1019 秒，合约 5850 亿年， 远远超过了现在对宇宙年龄的估计。所以，倘若这个传说是真的，我们应该不需要担心世界末 日的到来。 12.5 小结 ‧ 分治算法是一种常见的算法设计策略，包括分（划分）和治（合并）两个阶段，通常基于递归实现。 刷新仓库网页，点击“Create pull request”按钮即可发起拉取请求。 3. Docker 部署 在 hello-algo 根目录下，执行以下 Docker 脚本，即可在 http://localhost:8000 访问本项目。 docker-compose up -d 使用以下命令即可删除部署。 docker-compose down

个大小不一的金圆盘。僧侣们不断地移动圆盘，他们相信在最后一个圆盘被正确放置的那一刻，这个 世界就会结束。 然而，即使僧侣们每秒钟移动一次，总共需要大约 264 ≈ 1.84 × 1019 秒，合约 5850 亿年，远远超 过了现在对宇宙年龄的估计。所以，倘若这个传说是真的，我们应该不需要担心世界末日的到来。 12.5 小结 ‧ 分治是一种常见的算法设计策略，包括分（划分）和治（合并）两个阶段，通常基于递归实现。 刷新仓库网页，点击“Create pull request”按钮即可发起拉取请求。 3. Docker 部署 在 hello-algo 根目录下，执行以下 Docker 脚本，即可在 http://localhost:8000 访问本项目： docker-compose up -d 使用以下命令即可删除部署： docker-compose down 16.3 术语表 表 16‑1 列出了书中出现的重要术语，值得注意以下几点。

Client devices Edge AI • 随着大模型的发展，AI 计算对算力需求大 幅且快速增长 AI应用到越来越多的边缘场景 分布式协同AI 概念 将人工智能相关的部分任务部署到边缘设备，基于边缘设备、边缘服务 器、云服务器，利用分布式乃至分布式协同方式实现人工智能的技术 数据在边缘产生 边侧逐步具备AI能力 分布式协同AI 核心驱动力 分布式协同AI核心驱动力 技术挑战 边云协同AI框架 第二部分 首个分布式协同AI开源项目Sedna 基于KubeEdge提供的边云协同能力，支持现有AI类应用无缝下沉到边缘 为分布式协同机器学习服务 ✓ 降低构建与部署成本 ✓ 提升模型性能 ✓ 保护数据隐私 SIG成员近年发表分 布式协同AI顶会论文 10+ SIG成员在AI顶会IJCAI 上分享分布式协同AI论文 Sedna斩获中国信通院云边协 同应用创新大赛最佳创新奖 数据集等 3. Worker ⚫ 执行训练或推理任务, 训练/推理程序, 基于现有AI框 架开 ⚫ 按需启动, docker容器或function ⚫ 不同特性对应不同的worker组, 可部署在边上或云 上, 进行协同 4. Lib ⚫ 面向AI开发者和应用开发者, 暴露边云协同AI功能给 应用 Cloud Edge Local Controll er KubeEdge

自动化测试不能并行 2. 开发过程透明度无改善 3. 代码审核形同虚设 4. 部署过程依然没有完全自动化 简单 激情 速度快 聚焦 极致 可信赖 简单 激情 速度快 聚焦 极致 可信赖 持续…… 1.持续集成 Continuous Integration(CI) 2.持续发布 Continuous Delivery 3.持续部署 Continuous Deployment 简单 激情 速度快 聚焦 激情 速度快 聚焦 极致 可信赖 实现方案 HEAVEN 简单 激情 速度快 聚焦 极致 可信赖 实现方案 HEAVEN 部署 简单 激情 速度快 聚焦 极致 可信赖 流程 开发 Commit 创建PR 代码审核 自动测试 合并代码 自动测试 部署 简单 激情 速度快 聚焦 极致 可信赖 Keep Calm And Let‘s Demo 简单 激情 速度快 聚焦 极致 连接Travis与Slack 简单 激情 速度快 聚焦 极致 可信赖 代码覆盖率 简单 激情 速度快 聚焦 极致 可信赖 代码规范 gometalinter ./… 简单 激情 速度快 聚焦 极致 可信赖 部署 语法：bot deploy[:rollback] app[/branch] [to stagging|production|ip,…] bot deploy app bot deploy app/develop

方案诞生的背景 第一部分 方案诞生的背景 几种常见的同机通信场景： 1. 微服务合并部署（亲和性部署、sidecar 部署） 2. 本地基础组件：mesh sidecar、风控 sidecar、分布式网关... 方案诞生的背景 微服务化拆分： 1. 序列化 2. 网络开销 3. 服务治理 微服务合并部署 function call remote call 方案诞生的背景 微服务合并形态：sidecar 微服务合并形态：sidecar 进程通信 方案诞生的背景 微服务合并形态：亲和性部署 方案诞生的背景 怎么放大本地通信的优势？ 低延迟 提升用户体验 低开销 降低计算成本 常见的本地通信方案：回环 IP、UDS、共享内存IPC 方案诞生的背景 以性能较优的 IPC 方案 share memory ipc 为例分析性能瓶颈： 注：方案 github 地址：https://github. uds 和 rpal 的性能差异： 注：以上仅测试包含序列化开销的性能对比，benchmark测试受影响因素较多，实际收益需结合业务场景。 性能压测 性能收益与业务展望 1. 字节跳动微服务合并部署场景下，部分服务通过接入 RPAL 整体取得了 1-5% 的 CPU 收益， 以及 RPC 链路 1-6ms 的 P99 延迟下降。 2. 将某项 Mesh 提供的治理功能进行同步 RPAL Call，对比同进程