![动图封面](https://pic4.zhimg.com/v2-12b040f6bf6e63a103d7359c964fb957_b.jpg)

你在直播间里，买过最贵的东西是什么？

*「口红，300 多吧」*

*「球鞋，原价 1000 多抢的，现在能值 3000 多了」*

*「M2 的 MacBook Pro，小两万呢」*

*……*

最后的「直播间购物冠军」，在我们一片惊呼中稳稳诞生——

*「电动车，四个轮那种，赶上最近大降价，全办下来 20 多万」*

有人在直播间里「9 块 9，上车！」，有人在直播间里「买车」，这合理吗？

下周准备提车的他，给了我们三个无法反驳的理由。

*（以下内容根据「冠军」口述整理）*


### 理由一：比起车商，我更相信主播



买车之前，我也是做足了功课。从「一年之中几月份买车最便宜」到「一天中几点买车最便宜」，各种买车攻略没有告诉我什么是真的划算，但我明白了什么是真的套路。

所以我就想，假如我有一个朋友，对电动车如数家珍，还正好负责卖车，岂不是……再一想，我还真有这么个朋友——电动之家。

自从打算买电动车开始，就一直关注电动之家，最新的电动车资讯，干货满满又不乏趣味的各种电动车测评，真正做到了有趣有料有新知的专业态度。所以前不久电动之家的直播间刚一开播，我就一直关注，与其和汽车销售斗智斗勇，不如相信这个懂行的「老朋友」。


![](https://pic1.zhimg.com/80/v2-6d504cda670d34ce6b6f38acace1ca1c_720w.webp)

### 理由二：直播拼单，划算



当然，在直播间里一下花掉几十万，多少还是令人心跳加速。但是让心跳超速的，是我不能拒绝的价格。

最近不少车型价格大跳水，惹得不少准车主线下跨省买车，路途遥远不说，其中的政策风险和后续养护也都是未知数。

其实更划算的价格就在电动之家的直播间中，这里为汽车厂商和消费者搭建起了桥梁，也正是因为直播带货的形式，能让天南地北对这款车有兴趣的准车主实现「拼单团购」，一起把车价「打下来」。


![](https://pic1.zhimg.com/80/v2-f9a5c5a7de2347276a8f7c1b37ea162c_720w.webp)

### 理由三：跑线下，不如先看直播间


直播间里买车，也有着颠覆传统的全新体验。

以往一家一家地跑 4S 店，没看几辆车，一个周末就过去了。而在电动之家的直播间里，各个品牌的电动汽车足不出户就能看到翔实充分的介绍，还能在直播间里和主播实时互动，想要了解的细节，通过直播镜头和主播的实时展示就能呈现。在直播过程中，可以跳转到 App 商品页面进行购买，完成整个交易闭环。

另外，在直播间里选中心仪的汽车，也难免再去线下实地体验，电动之家在直播间打通了用户和汽车厂商之间的信息壁垒，为客户在车企的维修保养等后续服务，提前打好基础。

对了，电动之家 App 的直播间，就是咱们七牛云企业直播解决方案搭建的，搭建简单上线快、功能丰富玩法多，都是基本操作啦……



![](https://pic4.zhimg.com/80/v2-2e7ac1fcd141d7a52e6f0a766353650b_720w.webp)


*「今天为大家带来的这款车型，纯电续航达到了……」* ，已经有同事打开了电动之家的直播间，看样子「冠军」上车的三个理由，确实说服了大家。

在未来，或许到直播间里买车买房会逐渐变成「基操勿 6」，七牛云企业直播解决方案，也会帮更多厂商在视频直播营销的趋势下，成功上车。


七牛云 X 电动之家：跨省买车？不如一键上车

***在七牛云校园黑客马拉松中，来自华南理工大学的SCUT01团队，为我们带来了UI精美、体验优秀的白板作品，在大赛中获得二等奖的好成绩。以下是这款在线协作白板的技术解决方案。***

![](https://pic1.zhimg.com/80/v2-f5d7e533dc9b6627fcbe87e6227c57d8_720w.webp)

## **背景**

疫情背景下，线上课堂、线上会议等业务背景下都有着在线协作白板的需求。如何实现图形的绘制和实时同步，这是核心的两个问题。本文介绍一种基于原生Canvas和Websocket通信协议的协作白板解决方案。

![](https://pic3.zhimg.com/80/v2-87a4c8468033786e8706881e19d43802_720w.webp)

## **基础技术介绍**

**Canvas**

**<canvas>** 元素是HTML5新增的，一个可以使用脚本( 通常为JavaScript )在其中绘制图像的HTML元素。它可以用来制作照片集制作简单的动画，甚至可以进行实时视频处理和渲染。  **<canvas>** 由API构成，除了具备基本绘图能力的 *2D上下文* ， **<canvas>** 还具备一个名为WebGL的 *3D上下文* 。

> API参考：Canvas - Web API 接口参考 | MDN ([http://**mozilla.org**](https://link.zhihu.com/?target=http%3A//mozilla.org))

### **WebSocket**

![](https://pic2.zhimg.com/80/v2-3bfc82729a7568972b2bae99d75c35e9_720w.webp)

WebSocket是在H5中常被使用的全双工通信协议，它有以下特点

* 建立在单个TCP连接上的全双工通信应用层协议，支持服务端主动向客户端推送消息
* 握手阶段采用HTTP协议 （101状态码，Upgrade），与HTTP协议良好兼容
* 既可以发送文本数据，也可以发送二进制数据

WebSocket完美继承了 TCP 协议的**全双工**能力，并且还贴心的提供了解决粘包的方案。

它适用于**需要服务器和客户端（浏览器）频繁交互**的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。

对于白板应用的同步功能实现，就使用了Websocket进行实现。

## **协作技术下WebSocket实践**

### **前置知识**

首先需要介绍一下浏览器与服务器是如何建立WebSocket连接的。

* 浏览器在 **TCP 三次握手**建立连接之后，都**统一使用 HTTP 协议**先进行一次通信
* 如果 **建立 WebSocket 连接** ，就会在 HTTP 请求里带上一些**特殊的header 头**

```text
Connection: Upgrade
 Upgrade: WebSocket
 Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n
```

* 服务器收到带有 `Connection: Upgrade`请求头的HTTP请求之后，会调用 `upgrade`方法，将连接更改为websocket连接，然后给该次HTTP请求响应101状态码
* 至此，Websocket连接已经建立，可以使用已经建立的连接进行双工通信

### **连接处理**

服务端采用高性能的Go语言进行开发，`github.com/gorilla/websocket`开源库已经封装好完成了upgrade、返回101响应等方法，这里我们直接使用该库进行开发

* 定义服务器结构体字段

```text
type WstServer struct {
   listener          net.Listener
   upgrade           *websocket.Upgrader
   onConnectHandlers OnConnectHandler
}
```

* 该结构体实现ServeHTTP方法，并在方法中调用 `Upgrade`方法实现websocket协议的切换

```text
func (thisServer *WstServer) ServeHTTP(w http.ResponseWriter, r *http.Request) {
   conn, err := thisServer.upgrade.Upgrade(w, r, nil)
   if err != nil {
      log.Println("[ws upgrade]", err)
      return
   }
   log.Println("[ws client connect]", conn.RemoteAddr())
   thisServer.onConnect(conn, r.URL.Path) //每个连接开启协程进行处理
}
```

**白板业务下的websocket服务架构**

![](https://pic1.zhimg.com/80/v2-90d3fbe78c83012c862b9d71649daca0_720w.webp)

* 将每一个白板抽象为一个Hub，所有进入该白板的Client都需要使用WebSocket进行连接到WebSocket服务器中白板对应的Hub；其数据结构定义如下

```text
type Hub struct {
   BoardId     string                                        //白板id
   Connections *utils.ConcurrentMap[string, *UserConnection] //当前白板下所有的连接
}
```

* *`BoardId`为该Hub对应的白板ID*
* *`Connections`为该Hub中所有已经建立的WebSocket连接，key为UserId*
* 当其中一个Client进行操作之后（如绘制、删除、移动一个图形等），Client将该操作抽象为一个 `Cmd`的消息，发送给WebSocket服务器
* WebSocket服务器会将来自Client的消息**广播**给其他Client，其他Client会调用注册的回调函数进行处理渲染

```text
func (hub *Hub) Broadcast(obj any) {
   //遍历每一个连接，发送消息
   hub.Connections.Data().Range(func(key, value any) bool {
      userId := key.(string)
      conn := value.(*UserConnection)
      err := conn.SendJSON(obj)
      if err != nil {
         log.Println("[Error] Send To ===============> ", userId, err)
         return true
      }
      return true
   })
}
```

### **Websocket集群解决方案**

如果在单机情况下，当websocket需要给用户推送消息时，由于用户已经与websocket服务建立连接，消息推送能够成功。

但如果在集群情况下，用户甲向websocket发起连接请求，有多台服务时，只能与一台服务建立连接（以服务器A为例），而这些websocket服务都是有可能会给用户甲推送消息，这时候的服务器B和服务器C并没有建立连接。

为避免这种情况，以及更方便实现同步，我们需要尽可能让同一个白板内的所有Client连接到同一台服务器上。

这需要引入MQ来实现。所有的websocket服务都绑定到一个名称为locate的exchange中并接收来自网关的定位消息。如果对应白板的连接管理（Hub）在本机中，就把本节点的IP和端口等信息发送给网关服务，网关与对应Websocket服务建立连接。如果都没有找到，说明目前白板的Hub尚未创建，便使用负载均衡等策略随机与某个Websocket服务器建立连接。

![](https://pic1.zhimg.com/80/v2-1fc2955fa0939742d66e4cdfff3f3a34_720w.webp)

**Web端白板应用实现**

**整体架构展示**

Web端使用React框架来搭建应用，整体架构分为三层：UI层，逻辑层，渲染层

* UI层：处理用户 **交互** ，显示最终展示白板的Canvas。
* 逻辑层：实现白板 **核心逻辑** （比如undo/redo，使用ws同步白板等），与渲染层进行交互。
* 渲染层：**渲染**整个**白板**以及其中的元素，使用**双缓冲**加快渲染效率。

![](https://pic3.zhimg.com/80/v2-388a99a6dcc148920d2b2a4d7a6db3ce_720w.webp)

**基于原生Canvas的白板渲染方案**

我们将白板及其包含的所有元素构成的 **画面** ，抽象为 **RenderScene** ，其负责渲染自身元素以及在渲染结束后将自身**传递到UI层**展现给用户。

### **元素状态**

每个元素都有两种状态：**激活**状态和**正常**状态，所谓激活状态就是容易发生变动的状态（比如说**被选中**时，或者 **正在创建中，** 这个时候就需要让其从**背景缓冲**中分离出来。

![](https://pic2.zhimg.com/80/v2-851b2c4f5d4461a50f1a9188b7666971_720w.webp)

**双缓冲**

渲染层中有两个Canvas画板，其中一个作为 **背景缓冲** ，另一个用于**整个白板**显示，从而提高渲染效率，渲染时先绘制背景缓冲，再绘制激活元素。

![](https://pic2.zhimg.com/80/v2-e9bd6c47ba0637a726d5ffd30048b8b1_720w.webp)

### **渲染流程**

* 当逻辑层调用RenderScene的render()方法时

  * RenderScene会先将**背景缓冲**绘制到**真实画布**上
  * 如果有被**激活**的元素，则再绘制被激活元素
* 当逻辑层激活场景内元素时
* RenderScene**重新绘制**整个 **背景缓冲** ，包括除了激活元素之外的所有元素
* 调用render() 进行渲染
* 当逻辑层取消激活场景内元素时
* RenderScene将激活元素绘制到**背景缓冲**上
* 调用render() 进行渲染

![](https://pic1.zhimg.com/80/v2-2a23b1d19e3c7f4e109007d25d4ea9d8_720w.webp)

### **事件传递机制**

UI层可能接收到两种事件，来自桌面端的鼠标事件MouseEvent和移动端的触摸事件TouchEvent

* 我们根据**window.devicePixelRatio**对事件坐标进行变换，从而实现**dpi的适配**
* 将其分别转化成**InteractMouseEvent**和 **InteractTouchEvent** ，两者都继承自InteractEvent，分别对外提供统一的接口type（类型，比如down，up...) 和 x， y，从而实现事件类型的统一
* 传递到场景时，再根据画布缩放比例 **scale** ，再次进行坐标变化，将其映射到场景画布中成为SceneEvent，场景事件的去向有两个。
  * 通过逻辑层与渲染层的 **桥梁** ——工具(**Tool**类)的**op**方法 **操作RenderScene** ，对激活元素进行操作
  * 通过dispatchSceneEvent方法传递给元素，由元素**反馈**该事件是否与 **自己相关** （通过范围判断，返回布尔值）。

![](https://pic3.zhimg.com/80/v2-877df4a4c410ef2738a5459400036766_720w.webp)

### **同步机制的实现**

### **数据结构**

* 前后端之间使用命令(Cmd)进行同步，Cmd和Cmd的载荷(CmdPayload)数据结构如下

```text
enum CmdType { //枚举从最后开始添加
    Add, // 添加元素
    Delete, // 删除元素
    Withdraw, // 撤回
    Adjust, //调整单个属性
    SwitchPage,  //切换页面
    SwitchMode, // 切换模式
    LoadPage // 加载新页面
}

class Cmd<T extends CmdType> extends SerializableData {
    id: string; // 命令id
    pageId: string; // 操作页面id
    type: T; // 命令类型
    elementType: ElementType; // 命令操作元素类型
    o?: string; // 操作对象的id
    payload: string;  // 操作的 payload, 由于go无法绑定到确定类型，使用string
    time: number; // 操作的时间戳
    boardId: string; // 操作所属的白板
    creator: string; // 操作创建人的userId
}

type CmdPayloads = {
    [CmdType.Add]: ElementBase, //需要增加的元素
    [CmdType.Delete]: null //需要删除的元素
    [CmdType.Withdraw]: Cmd<CmdType> //需要撤销的操作
    [CmdType.Adjust]: Record<string, [any, any]> //p键值为操作的属性，[0]:before, [1]:after
    [CmdType.SwitchPage]: {from: string, to: string} //从from页面切换到to页面
    [CmdType.SwitchMode]: number //新的mode
    [CmdType.LoadPage]: null
}
```

* 同时**Cmd**也是实现**撤销/重做**的OperationTracker的 **状态维护者** ，可以与逻辑层统一一个命令执行接口

```text
export class WhiteBoardApp implements IWebsocket, ToolReactor {

    /* ... */
    public cmdTracker:OperationTracker<Cmd<any>>;
    /* ... */   
   
}
```

### **同步机制**

* 每种工具都可能是 **创建者（Creator）** 或者 **修改者（Modifier** ），由逻辑层注册对应onCreate和onModify回调。
* 在创建或修改的时候，**构建**对应 **Cmd** ，通过**Websocket客户端**发送到服务器，服务器**广播**命令到房间内其他用户。
* 其他用户收到Cmd时，通过白板逻辑层的 add/delete/adjustElem **ByCmd** () 等接口，使用Cmd的**Payload**对白板进行**同步。**

![](https://pic3.zhimg.com/80/v2-d6c5073f33fe7162d9d7f3366592bd0a_720w.webp)

**频繁写场景下的存储架构实践**

对于白板类应用，在极大部分情况下数据的操作为更改操作（写操作），并且频率非常高；
应对如何应对高并发的频繁写入操作，成为白板技术下非常重要的问题。
Redis Buffer

如果写入操作直接操作数据库（如MySQL），高并发场景下，数据库的压力会非常大。所以我们选用分布式内存数据库Redis进行数据的缓存，待合适的时机将数据持久化到数据库。

![](https://pic2.zhimg.com/80/v2-c376c90ac490b88f7f2ec9ac72539d45_720w.webp)

**Redis数据结构的选择**

**Redis的数据结构包括以下五种：**

1. **`String`：字符串类型**
2. **`List`：列表类型**
3. **`Set`：无序集合类型**
4. **`ZSet`：有序集合类型**
5. **`Hash`：哈希表类型**

下面介绍一下页面上元素的数据结构：

```text
class ElementBase extends SerializableData {
    public id:string;
    public type:ElementType;
    public x:number; // 左上角点的x坐标
    public y:number;
    public width:number = 0;
    public height:number = 0;
    public angle:number = 0; // 弧度制
    public strokeColor:string = "#ff5656"; // 十六进制整数
    ...
 }
```

要存储这样一个含有许多属性的对象在Redis中，一般有以下两种方案：

* 方案一：将整个对象序列化为一个JSON字符串，使用Redis的简单String，进行存储；
  * 优点：实现简单
  * 缺点：如果每次修改只会更改其中某少量属性（如移动只会更改有元素x,y属性），但是采用简单字符串的方式每次都需要重新序列化整个对象，再进行覆盖存储，效率比较低（主要从网络传输的网络包大小考虑）
* 方案二：将对象存储于Hash结构中，field存储对象的属性名，value存储属性值
* 优点：可以实现对该对象的某个或多个属性的精准控制
* 缺点：实现起来复杂

在我们的应用场景下，只更改单个或少数属性的场景较多，所以我们选用Hash结构进行存储
同时，如果我们要知道一个页面内所有的所有的元素的集合，如果采用元素的key值内拼接页面id的方式，必须使用Scan进行全局键的遍历。为了避免全局，选用一个Set结构用于存储一个页面内所有元素的id
Redis Pipeline操作

在白板业务场景下，无法避免需要执行多个Redis命令的场景（如读取整个页面上的所有的元素数据的hash结构）
管道（pipeline）可以一次性发送多条命令给服务端，服务端依次处理完完毕后，通过一条响应一次性将结果返回，pipeline 通过减少客户端与 redis 的通信次数来实现降低往返延时时间，而且 Pipeline 实现的原理是队列，而队列的原理是时先进先出，这样就保证数据的顺序性。

![](https://pic1.zhimg.com/80/v2-e0c55d004243e6137fc9b5c7663dec00_720w.webp)

使用pipeline可以批量执行Redis命令，非常有效地提高系统吞吐量
Redis集群方案

在整个系统中，需要缓存页面上大量的元素数据，应用的拓展性受到Redis存储容量的限制，并且单节点Redis可用性较低。所以有必要在架构中引入集群方案。
Redis 集群提供了一种运行 Redis 的方式，其中数据在多个 Redis 节点间自动分区。Redis 集群还在分区期间提供一定程度的可用性，即在实际情况下能够在某些节点发生故障或无法通信时继续运行。

![](https://pic2.zhimg.com/80/v2-7ce48678d5a010480025fa7561cfe519_720w.webp)

**Redis集群有以下特点：**

* 每一个master节点都有其对应的一个或多个slave节点，他们之间为主从关系，会进行主从复制
* 每增加一个key会通过一定哈希算法分配到某一个master节点，理论上可以实现存储能力的扩展

在白板应用中一般读取的场景相对较少，所有每一个master节点有一个从节点即可实现高可用的架构。


在七牛云校园黑客马拉松中，来自华南理工大学的SCUT01团队，为我们带来了UI精美、体验优秀的白板作品，在大赛中获得二等奖的好成绩。以下是这款在线协作白板的技术解决方案。

SCUT01在线协作白板技术解决方案

***在七牛云校园黑客马拉松中，一款设计优秀、逻辑清晰的白板作品脱颖而出，获得第二名的好成绩，这就是来自郑州大学Since团队的White Rose白板，以下是他们的设计和架构分享。***

![](https://pic3.zhimg.com/80/v2-91b0aae0f0ec3200a7bc36d5804f143e_720w.webp)

### **一、前言**

White Rose是参加七牛云hackathon比赛的作品，赛题的主要内容是开发一个「多人协作白板」，旨在鼓励在校大学生用编程创造价值。

赛题核心需求包含三个：

1. 多人可以加入一个房间，同时进行绘画（尽可能多的形状随意绘制）
2. 所有操作可以撤销和恢复
3. 可以创建不同页面，支持只读模式（页面锁定后，所有人不可编辑）

### **二、产品设计**

### **（1）愿景**

基于hackathon的比赛要求，我调研了一些白板软件，这些软件不乏有一些「操作困难」「功能繁杂」等问题。所以，我定下一个产品愿景：「做一款从两岁到八十岁都能用的白板」

### **（2）追求**

基于以上愿景我也设立了几条产品追求：「功能一键即达」「界面极致简洁」「内容高度自由」

作为乔布斯的粉丝，印象中乔布斯当年设计iphone时，要求工程师所有的功能操作不能超过3步，而对于白板一个单独的软件来说「进入」一步，「功能选择」一步，所以留给我的只有一步了。

### **（3）界面**

为了让界面足够简洁，我将所有「扩展」功能全部放到了「上下左右」四个隐藏菜单里，从而让整个页面除了四个「必要数据」外，就只有一块“纯粹的白板”。

* 对于两岁的小朋友来说进入就可以直接随意的涂鸦。
* 对于八十岁老教授来说，这用起来跟教室的黑板一样。

下面分别是整体的界面效果。

![](https://pic1.zhimg.com/80/v2-c1de8dcec9a94a86621b99d380390b90_720w.webp)

无论多大的屏幕，什么形状的屏幕，都会无失真的自动扩张，因为它本质是一个高宽100%的矢量图。

因为不同屏幕的大小限制，这样的设计可能回导致小屏幕的人看到的内容没有大屏幕的「完整」。

对于有些软件的处理可能会有利用「拖拽页面」功能来确保每个人所能接收到的数据一致，这将意味着，用户的每次触屏操作，软件都要区分用户是想「拖拽页面」还是想「绘画」，而用户也需要在两个功能间频繁切换。

而我的理解：“白板”本质是一个大号的草稿纸，当我们给一群人讲一些内容的时候，「演讲者」可能随手会在白板上写下他讲的关键词「power point」，一般作为「演讲者」会写在一个大家都能看到的地方，这对「演讲者」不会增加太大负担，而对于「听众」一边听内容，还要一边还要拖拽页面去确认演讲者写在那里，这个负担更大。

回想一下我们在教室上课的时候，老师会尽量把内容写在中间靠上的位置，而不是底部，因为前排同学会挡到内容。

所以我摒弃了「拖拽页面」的功能。

当然「缩放」也不乏是另外一种解决方案，但是也会徒增操作者（缩放）的使用负担，并且还会引入另外一个问题就是「失真」。

关于颜色：

其实在选择白板的底色的时候，可能就是一个白色，但是其实白色也是五彩斑斓的，该用什么呢？

我想到一个词「青红皂白」，索性我就用「青红」和「皂白」调制了一个对眼睛更加柔和的 「青红皂白色」作为白板的底色。

### **（4）拓展功能**

设计好了整个页面，接下来就是功能设计，我在设计界面的时候，预留了4个隐藏菜单栏来放拓展白板功能，为了让所有功能「一键即达」，并且更简单的使用，我采用了icon + 文字描述的方式，让用户更易理解。

整体展开如下图所示：

![](https://pic4.zhimg.com/80/v2-3d1f5ff315386ce37858fbe274f13d4b_720w.webp)

为什么是这样的摆放呢？

1、功能分类

根据赛题要求的功能，我将所有功能分为了四类。

1. 形状拓展：用户可以选择圆、长方形、菱形、三角形、直线等形状。
2. 颜色拓展：用户可以修改所有形状轨迹的颜色。
3. 大小拓展：图形的大小和线条的粗细可以切换。
4. 页面拓展：页面可以添加删除和切换，另外页面的内容支持撤销和恢复。

2、何处安放

我在想这个问题的时候，想象了在一张纸上作画的场景。

* 一般我们习惯在桌子右侧放上各式各样的水彩笔，方便我们切换颜色，所以我将「颜色拓展」放在了右侧。
* 我们习惯在桌子的上方和左侧放尺子、圆规之类的用来拓展图形和丰富绘画形状的工具，所以我将「形状拓展」「大小拓展」放在了左侧和上侧。
* 当我们要做翻书、撕页等页面操作时，一般会从右下角开始，所以我将所有的「页面拓展」放置到了下侧，同时右下角有一个对应页面的页码，也因为大多数书的页码在这个位置。

### **（5）自由布局**

上面讲到，我根据我个人的想法将各个功能进行了分类，并且按照我所理解的「更方便的布局」进行了排放，但在实际操作过程可能并不符合一些其他用户的操作习惯，比如：左撇子。

因此我将每个功能做了集成，并且可以随意的改变不同功能所在的位置，也就是所有的功能布局，用户可以根据自己的想法进行布局上的DIY。

### **三、架构设计**

因为本次开发的周期只有21天，另外工作日的白天还需要上班，非常紧迫。所以需要采用非常简单且高效的架构设计，当然也需要考虑一些后续扩展的可能。

（1）整体架构

为了更好的「持续集成」我们采用自建的gitlab管理代理，并使用gitlab-runner完成自动化部署。

整体架构图如下图所示：

![](https://pic4.zhimg.com/80/v2-dd6713649adbc5c45f549e8e40e6d0df_720w.webp)

（2）交互模型

对于后端来说，为了更加高效的沟通，我将整个交互模型，定义为一个群聊，群内所有人的消息统一发给服务端，然后服务端再统一转发给其他人。

后端只需要确认三点：1.谁发的消息。2.发到那个群里的。3.消息类型。

整体交互结构如下：

```text
{
"type": 1234,  // 操作类型
"fromId": 123, // 发送人id
"roomId": 1234,// 所在房间
"time": 152150025421564 //时间戳，前端不需要发送
"data": {} // 操作内容
} 
```

这样做的两个好处：

1. 所有消息有一个统一的时序（即服务端时间）
2. 后端完全无需关注「data」的具体内容。只根据type区分「接收」「分发」「存储」操作。

（3）data模型

data模型主要是前端所发送的和接收到的message里的data结构。

data里面该放什么？我将用户的所有操作定义为option，将用户的所有option放到data里面完成用户操作的转发。option的结构如下：

```text
interface Op {
type: number // 页面操作or图形操作
graph?: {
op: number // 添加、旋转、缩放、平移
type?: string // 图形类别
key?: string // 图形所对应的key
page?: number // 图形所对应的页面
content?: any // 图形内容
}
page?: {
op: number //添加、删除、切换页面
key?: number // 页面对应的key
content?: any // 页面对应的内容
}
} 
```

这样的每个option，我们都会存放到操作栈里面，结合另外一个缓存栈，即可实现撤销和恢复。

（4）多人协同

对于多人的操作，其实是多个人对多个图形的操作，人与当前所操作的图形是一一对应的。

所以我通过一个令牌集的概念，来存放「所有的用户id」，以及每个用户当前「所操作的图形id」，这样就确定下来个每个用户正在操作什么。

不同用户的操作通过以下流程完成：

1. 操作者设定当前所操作图形的id，并更新令牌集。
2. 接收者同步更新令牌集。
3. 操作者发送操作数据（option）。
4. 接收者根据用户信息从令牌集中确定所操作的图形，再根据option修改具体的svg数据。

整体白板从产品的设计到架构的设计就结束了。

欢迎体验：[http://whiterose.cf.since88.cn](https://link.zhihu.com/?target=http%3A//whiterose.cf.since88.cn/)

前端代码：[https://**lab.since88.cn/whiteros**e/frontend](https://link.zhihu.com/?target=https%3A//lab.since88.cn/whiterose/frontend)

后端代码：[https://**lab.since88.cn/whiteros**](https://link.zhihu.com/?target=https%3A//lab.since88.cn/whiterose/backend)


在七牛云校园黑客马拉松中，一款设计优秀、逻辑清晰的白板作品脱颖而出，获得第二名的好成绩，这就是来自郑州大学Since团队的White Rose白板，以下是他们的设计和架构分享。

White Rose设计与架构的想法分享

来自上海应用技术大学的「SIT-board」团队，在七牛云校园黑客马拉松中勇夺冠军，以下是他们的参赛作品——SIT-board远程交互白板的实现过程。

SIT-board 远程交互式白板的实现

自从第一行代码被敲下的那一刻起，每一个个体都拥有了更多改变世界的机会。

「hello, world 」

这不仅是显像管上的问候语，也是一个新世界的开篇词。

这个由代码构建的世界，是你们的、我们的，更是年轻人的。

编程让我们离工程性的创造如此之近，让我们面对逆境寒冬都有着无穷的勇气。

所以，我们向学生朋友们发出邀请，参加「七牛云校园黑客马拉松」，用代码去释放创意，即刻点击链接，赶快报名吧！

| [http://s.31url.cn/CjvC8ROh](http://s.31url.cn/CjvC8ROh) |
| ----------------------------------------------------- |

![](https://pic3.zhimg.com/80/v2-ff94dd5440e00238db4b051e9ded9ebe_720w.webp)

![](https://pic4.zhimg.com/80/v2-5312dd399216062d12ec3b30afac0acb_720w.webp)

![](https://pic2.zhimg.com/80/v2-32c247d7d7b93483f9937e4f7c54b2bd_720w.webp)

![](https://pic4.zhimg.com/80/v2-ae0bbc0d4b0341b9572f7dfac450566f_720w.webp)

![](https://pic4.zhimg.com/80/v2-cb7fb4fd4e2d4c4319df30a61b62b247_720w.webp)

![](https://pic3.zhimg.com/80/v2-9ffd08efa631dce393f23ad15ac85baa_720w.webp)

![](https://pic1.zhimg.com/80/v2-d124ac171935d07d38b8d4c4c0b72598_720w.webp)


10 万奖金、实习 OFFER ! 校园黑客马拉松报名中

从实验室到产业，AI 正在越来越多的领域里为我们带来新变化。音视频赛道中，同样因为 AI 的结合，诞生出新的挑战与机遇。

视频画质怎样在 AI 的加持下得到提升？如何让机器对视觉关键信息由「感知」升级到「认知」？机器如何更加智能地理解语音？大量和 AI 相关的音视频场景，正在以颠覆传统的姿态进入产业并加速落地。

本期「七牛云音视频实践日 Live 2022-1024专场」，就将视野聚焦到「音视频 + AI 技术的探索与实践」。我们为大家特别邀请到七牛云高级视频编解码工程师李祖团，WPS CV 部门版面分析组负责人、算法经理黄达一，火山引擎智能语音解决方案架构师杨相会，他们将从不同领域，为我们带来「音视频 + AI」的技术实践，帮助你获得前沿技术视角，了解产业结合的最新动态。

**10 月 23 日 （本周日）下午两点**，让我们相约直播间，不见不散。

点击链接，加入直播群 https://www.wenjuan.com/s/ZFBreq4/?is=qrcode

直播过程中，我们还在直播间与直播微信群准备了丰富的礼品，提前祝大家「1024 程序员节」快乐！

**议程介绍**

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/499583151674432f994bc4421535ba26~tplv-k3u1fbpfcp-zoom-1.image)

---

**关于「音视频实践日 Live」**

「音视频实践日 Live」是由七牛云发起的技术直播活动，以分享交流音视频技术与实践为宗旨，聚焦音视频前沿领域。在系列活动中，由音视频领域专家、行业大牛组成的讲师团队，将从实时互动、直播等细分场景为大家带来深入浅出的专业分享。

![动图封面](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/947d9791b03a4e12a6115b10986fc4f4~tplv-k3u1fbpfcp-zoom-1.image)

点击链接，加入直播群 https://www.wenjuan.com/s/ZFBreq4/?is=qrcode


本期「七牛云音视频实践日 Live 2022-1024专场」，将视野聚焦到「音视频 + AI 技术的探索与实践」。10 月 23 日 （本周日）下午两点，让我们相约直播间，不见不散。

直播预告｜音视频 + AI 技术的探索与实践

执行SDK监管要求，助力产业健康可持续发展！

详情请见[全国SDK服务管理平台](https://sdk.caict.ac.cn/official/#/home)


七牛云接入全国SDK服务管理平台

在[之前的文章](http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=2652202350&idx=1&sn=55ceebc2e0dfc6c7ed3e0d54a8df278c&chksm=bd0153fb8a76daed8ab9ca4af0b43e69f839a421840b1f11ea284d6f0af76762cd591638408b&scene=21#wechat_redirect)中，我们为大家重点介绍了 HDR 的相关内容，相信大家已经能对「色域」、「动态元数据」、「码率」等概念如数家珍。七牛云全面支持 HDR，很多小伙伴们不仅有所耳闻，也在使用中享受到了七牛云功能强大、集成方便的转码服务。


## 屏幕：有用武之地

这年头，支持 HDR 的屏幕越来越多，但是用户在使用中，却往往会发出「这画面好像也没比之前强多少」的感叹。这个锅其实不能让屏幕来背，问题出在视频内容上。

虽然能够拍摄 HDR 的设备日益普及，但是目前市面上大多数的视频内容，仍然以 SDR 的标准来制作，这就导致用户拿着一块儿高质量的屏幕，但无法让它发挥出真正的实力。宛如 AWM 在手，弹夹却空空如也。

通过七牛云转码，SDR 内容可转码为 HDR，让视频平台能够为用户提供更具吸引力的内容，也让更多的好屏幕不被辜负。

![](https://pic4.zhimg.com/80/v2-b6a7ac6518f2e388ea56660f04dcd25f_720w.jpg)

## 画面：亮眼又出彩

从 SDR 转化为 HDR，最重要的特征就是变「亮」了，原本画面中「太阳」、「焰火」等元素，在 HDR 中终于能够让用户感受到如现实般的耀眼。这得益于转化过程恢复了 SDR 视频被压缩的动态范围，HDR 视频相比 SDR 视频，亮度峰值由 120nit 提升到 1000nit 甚至更高，从而使画面拥有更高的对比度。

在「亮眼」之外，「出彩」也是 HDR 视频的重要特质。与 SDR 的色彩空间相比，HDR 的表达范围从 0-255 提升至 0-1024， 色域空间为 bt2020，比 SDR 的 bt709 更加宽广，这意味着可以表现出更深、更丰富的颜色，与亮度提升一起，共同为用户带来更逼真的画面体验。

![](https://pic4.zhimg.com/80/v2-07ea9f1b7461c85222357f00511edecf_720w.jpg)
*亮度更高、颜色更深、色域更宽*

## 细节：不过曝，质量高

在 SDR 转化为 HDR 的过程中，往往会出现色彩失真、噪声、压缩失真等问题，导致亮度和色彩提升后，观感反而不如原画面。为了避免这些问题，七牛云 HDR 算法通过计算当前像素中 RGB 的差异来调整，使得相近位置相近颜色获得不同的增益强度，从而提升细节差异，防止过亮导致细节损失。

通过实测，相比于其他算法，七牛云转码后视频画面动态范围更大、细节更丰富、色彩更有层次感。

![](https://pic3.zhimg.com/80/v2-52d64838552e25a18c6a98d708753de6_720w.jpg)

目前，七牛云 SDR 转 HDR 功能已正式上线，欢迎大家实测体验。

更多的现实方法和技术细节，在下期「牛人说」中会为大家做详细介绍，敬请期待！
