
基于 Spring Cloud 使用一致性哈希算法实现分布式 WebSocket. / 基于 RabbitMQ 广播实现分布式 WebSocket.

### WebSocket 协议

参考 [RFC](https://tools.ietf.org/html/rfc6455) 标准规范。

### 思路

核心问题在于具备 WebSocket 服务端的 SpringBoot 或 SpringCloud 等微服务应用是**有状态**的。服务端的内存中存在维持连接的
Session。客户端连接服务器时，只能和集群中的唯一一个服务实例来连接，而且数据传输过程中也直接和此实例通信。

解决方案有很多。

#### 方案一：将状态放到应用之外的存储中，但不可行

这个方案非常类似于 HTTP 协议的 Token 实现（非 JWT），Java 中具体的例子就是 Spring Session 以及 Spring Security 的 Token Store，比如 RedisTokenStore 实现了将
OAuth2 Token 存放到 Redis 的逻辑。此方案的核心前提是可序列化。WebSocket 协议和 HTTP 协议并不同，一个 WebSocket Session 对应于一次 TCP Socket
连接而非数据，新的连接将会基于新的四元组，不可能做到序列化。

#### 方案二：一致性哈希

像微服务注册中心一样，维护一个全局映射关系 —— 当前客户端的 WebSocket
连接是和哪一个实例/节点保持的。每次通信都经过此注册中心或哈希，查询到具体的服务实例，将连接交给它。同样会遇到一些问题，比如：哈希环的实现、如何解决一致性问题（单节点故障的 Session 迁移重连将代价降到最低）、CAP
取舍、实例的区分依据是什么（IP ? 实例
ID？）、可能与注册中心构成强依赖、以及部署环境的变更带来运维上的挑战等难题。这个方案实施有一定的成本和技术限制，可以参考[这篇文章](https://segmentfault.com/a/1190000017307713)的大体思路，理解了核心的哈希环的概念(如下图)，再配合注册中心、服务上下线消息，就能完成基本的实现。我利用
Nacos、Redis、RabbitMQ 基于 Spring Cloud 写了一个通过一致性哈希来实现的全栈项目，前端和后端都已开源 ——
[WebSocket 集群的一致性哈希实践(Spring Cloud 后端) - GitHub](https://github.com/Lonor/websocket-cluster)
, [WebSocket 客户端模拟与服务列表(React 前端) - GitHub](https://github.com/Lonor/websocket-cluster-front),
最近刚刚写好基本的功能，参考 [@ufiredong](https://github.com/ufiredong)
的方式利用 [Java 语言的 Docker SDK](https://github.com/docker-java/docker-java) 实现模拟 WebSocket 实例的上下线。未来还会稍微做细微的优化。

<div>
    <github user="Lonor" repo="websocket-cluster"></github>
</div>

![HashRing:虚拟节点上线后部分客户端需要迁移节点](/images/websocket-cluster/hashring.png)

另外，Nacos 作为微服务的注册中心是国内比较流行的选择。但有人早就向 Nacos 社区提出了[维护哈希环的议题](https://github.com/alibaba/nacos/issues/2114)；姑且不说此议题是否合理，但
Nacos 的维护人员竟然没有能够理解这样的需求，还是有点令人诧异。

最终效果如下, 上线一个新的服务实例后，客户端会自动根据最新哈希环重新路由到最新节点上，收发消息一切正常：

<div class="embed">
  <iframe src="//www.bilibili.com/blackboard/html5mobileplayer.html?bvid=BV1sg411q78V&danmaku=0&high_quality=1"
  ></iframe>
</div>

#### 方案三：广播队列

每次连接都需要通知到所有实例，实例各自都判断连接状态在不在自己这里，不在的话直接忽略，在就处理。类似于发布订阅模型，可以通过 MQ（RabbitMQ、Kafka、RocketMQ 等）或 Redis
做到。此方案实现简单，适用于集群规模不大的场景，因为需要所有的节点进行判断或计算。我愿称之为：分布式事件驱动。

以下基于 RabbitMQ 做了简单实现。

##### 简单广播实现 WebSocket 集群

[声明式 API](/blog/declarative-programming) 的好处就体现在这里：短短几行就直接利用了 RabbitMQ 的 Java SDK 创建好交换机和队列以及绑定关系。

```java
package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.AnonymousQueue;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Slf4j
@Configuration
public class MqConfig {

    private static final String FANOUT_EXCHANGE = "websocket-exchange";

    @Bean
    public FanoutExchange fanoutExchange() {
        log.info("创建广播交换机 [{}]", FANOUT_EXCHANGE);
        return new FanoutExchange(FANOUT_EXCHANGE);
    }

    @Bean
    public AnonymousQueue queueForWebSocket() {
        log.info("创建用于 WebSocket 的匿名队列");
        return new AnonymousQueue();
    }

    /**
     * @param fanoutExchange    交换机
     * @param queueForWebSocket 队列
     * @return Binding
     */
    @Bean
    public Binding bindingSingle(FanoutExchange fanoutExchange, AnonymousQueue queueForWebSocket) {
        log.info("把匿名队列 [{}] 绑定到广播交换器 [{}]", queueForWebSocket.getName(), fanoutExchange.getName());
        return BindingBuilder.bind(queueForWebSocket).to(fanoutExchange);
    }

}
```

然后是生产者和消费者。生产者将消息发送到队列中进行广播，集群的消费者监听队列，判断此 WebSocket Session 是否在当前消费节点再做进一步处理。

消息生产方，一般是外层接收到消息通信请求，然后调用进行集群内广播：

```java
package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class FanoutSender {

    @Autowired
    private FanoutExchange fanoutExchange;

    @Autowired
    private RabbitTemplate rabbitTemplate;

    public void send(Object message) {
        log.info("开始发送广播: [{}]", message.toString());
        rabbitTemplate.convertAndSend(fanoutExchange.getName(), "", message);
    }

}
```

消息消费方，多节点共同消费同一消息，区分是否需要自己来处理：

```java
package me.lawrenceli.websocket.server.configuration;

import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

@Slf4j
@Component
public class FanoutReceiver {

    @RabbitListener(queues = "#{queueForWebSocket.name}")
    public void singleReceiver(Object message) {
        log.info("队列接收到了消息: [{}]", message.toString());
        // 判断 WebSocket Session 是否在当前节点
        // 一般维护在一个 ConcurrentHashMap 静态变量中，这里叫 sessionMap
        // message 中有类似 SessionId 的字段
        if (sessionMap.contains(sessionId)) {
            log.info("WebSocket Session 在当前节点");
            // 执行相应的流程
        } else {
            log.info("当前节点无此 WebSocket Session");
            // 什么都不用做，直接忽略
        }
    }

}
```

注意，方案 2、方案 3 都没有解决单节点故障问题，因为从本质上讲，没有实现 WebSocket Session
的全局共享。但是方案二能够依赖哈希环的更新，最大程度上地降低迁移连接的代价，客户端会有重试的机制来针对单节点故障问题做容错。如果规模较大，项目复杂，且客户端连接数多，推荐使用一致性哈希的方案二，当然下面也有其他的社区方案。

### 其他案例

即刻 App 后端基于 Node.js 使用了 [socket.io](http://socket.io) 实现多端实时通信，Joway
的[这篇文章](https://blog.joway.io/posts/socket-io/)交代的一些细节也涉及了分布式部署的问题。

socket.io 官网也提供了[多节点的使用方法](https://socket.io/docs/v3/using-multiple-nodes/index.html)，不外乎 IP Hash 之类的方案。

### Kubernetes 内的 Websocket 集群

如果部署环境基于 Kubernetes 内的 WebSocket
集群，也可以参考[阳明的这篇文章](https://www.qikqiak.com/post/socketio-multiple-nodes-in-kubernetes/)来实践 （利用 Service
的 `sessionAffinity` 会话亲和确保每次将来自特定客户端的连接传递到同一 Pod：使用 `ClientIP` 声明）。


WebSocket 在 Spring Cloud 中如何实践分布式集群：一致性哈希的实现和 Fanout 广播

WebSocket 集群方案


命令式编程注重过程，声明式编程注重结果。前者强调代码本身的逻辑，需要开发者重视程序每个阶段的上下文，以一步一步地实现应用功能。后者基于完善的 API / SDK，告诉（声明）程序需要达到的状态（一种状态机），程序会主动、不遗余力地向其驱动一直到达到声明的目标，应用层人员无需在意底层实现。

优雅的 API 往往是声明式的，通常也非常简洁明了。

这里我举一个电风扇和空调的例子：

电风扇：为了实现体表温度的控制，人类利用电动机发明了电风扇，一个命令式风速调节客户端 —— 大部分你需要自己手动地调节电风扇的风向、风速，让身体接受风扇的水平气压梯度力，以让体表流体流动速度上升从而达到吸热的目的。你可能已经间接地知道了它的实现**原理**，尽管这个流程并不复杂。

空调：它是声明式的。你**无需关注**空调自身的实现原理，只需要通过遥控器**声明**它应当达到的温度即可，空调就会驱动自身来实现密闭空间的恒温调节到达期望值 —— 哪怕空间的温度骤变。

虽然栗子并不够恰当，但是用户已经意识到：空调调节起来多简单方便！

软件开发亦如此。

我们其实早已经频繁地和声明式编程打交道了：其实 HTML、CSS、SQL 这些语言自己就是声明式语言；纯函数编程语言也被认为是声明式语言，这非常有趣。另外，前端流行的 React、Vue 都利用了 Virtual DOM 和 diff 算法实现了声明式的 JavaScript 用户界面框架，再也不需要前端开发者去使用 jQuery 或原生写法来操作 DOM。

Java 开发者在开发阶段使用声明式 API 的最典型例子就是运用注解。比如 Spring 提供 `@Autowired` 注解实现 Bean 对象的依赖注入，其实现是基于 Java 语言的反射。Spring 更是提供了大量内置的注解简化了开发人员的开发: `@Transactional` 实现声明式事务, `@Component` , `@Value`, `@Data` ...

首个毕业于 CNCF 的项目 [Kubernetes](https://k8s.io) 中也在充分地让 DevOps 拥抱声明式。它提供了基于 YAML 语法的配置文件（manifest，用以描述容器集群期望的拓扑状态），自动地向配置的声明驱动。云原生应用的一个必要特性就是声明式。

GraphQL 让原本的 REST 更加声明式。这是一个非常适合全栈开发的 HTTP 接口规范，热度最近有在攀升，能否颠覆传统的 REST 不得而知。

Apple 在 WWDC 2019 上发布的 [SwiftUI](https://developer.apple.com/cn/xcode/swiftui/) 和 Google 开源的 [Flutter](https://flutter.cn/docs/get-started/flutter-for/declarative) 一样都是移动端、跨多个操作系统的声明式 UI 框架。

Maven、Gradle、npm、pip、go module 等提供了 Java、JavaScript / TypeScript、Python、GoLang 开发者声明式依赖管理工具，现代的应用开发几乎离不开它们。我还记得第一次手写 Makefile 的痛苦。

GitHub Actions、GitLab、Jenkins Pipeline 提供了基于声明式配置文件（大部分为 YAML）的持续集成流水线，可以让开发人员也能低成本地学习实践 CI/CD。这里 Jenkins Pileline 的实现是基于另一门 JVM 语言 Groovy 的 DSL。

在软件测试领域，BDD (Behavior Driven Development，行为驱动开发) 同样也是声明式。BDD 是为了能让熟悉业务但是不懂编程的用户也能实现业务范畴的自动化测试。 Gherkin 剧本语法面向业务人员提供特定的领域语言来描述软件行为。

开发声明式 API 是很困难的，往往需要开发人员对语言以及框架的拥有深刻认知，并且是一种的利他主义美德:

> 将复杂留给自己，将方便留给别人。

单纯作为用户而言，效率、便利、无副作用是声明式 API 的目的。而作为软件开发者，去意识到这些声明式应用或框架的背后原理往往会更加明白创作者的真实意图，也能更清晰自己所做的声明、或是充分优化应用层代码，而避免陷入[路径依赖与货物崇拜编程](https://lawrenceli.me/blog/path-dependence-and-cargo-cult)的怪圈。

Links:

[https://spring.io/guides/gs/rest-service/](https://spring.io/guides/gs/rest-service/)

[https://www.infoq.cn/article/rest-apis-are-rest-in-peace-apis-long-live-graphql](https://www.infoq.cn/article/rest-apis-are-rest-in-peace-apis-long-live-graphql)

[https://kubernetes.io/zh/docs/tasks/manage-kubernetes-objects/declarative-config/](https://kubernetes.io/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)


Declarative programming - 声明式编程

声明式编程


A problem that Homebrew's author complained.

---

Invert a binary tree. Problem from leetcode.

Here's the input:

```txt
     4
   /   \
  2     7
 / \   / \
1   3 6   9
```

and the out put looks like:

```txt
     4
   /   \
  7     2
 / \   / \
9   6 3   1
```

This problem was inspired by this [tweet](https://twitter.com/mxcl/status/608682016205344768).

<div>
    <tweet id="608682016205344768" />
</div>

Here's the solution implemented in Java.

```java
/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode(int x) { val = x; }
 * }
 */
class Solution {
    public TreeNode invertTree(TreeNode root) {
        if(null != root){
            TreeNode leftChild = root.left;
            root.left = root.right;
            root.right = leftChild;
            root.left = invertTree(root.left);
            root.right = invertTree(root.right);
        }
        return root;
    }
}
```

There's much different logic behind software engineering with computer science. [Max replied this question about it on quora.com after 2 years.](https://bit.ly/2HqaTe5)


Invert binary tree


维基： [https://zh.wikipedia.org/wiki/没有银弹](https://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9)

文献：Brooks, F. P.，"No silver bullet—essence and accidents of software engineering, " in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.

结论：不会有任何单一的软件工程上的突破（银弹），能够让程序设计的生产力得到一个数量级的提升。

「**人月神话**」

维基：[https://zh.wikipedia.org/wiki/人月神话](https://zh.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E7%A5%9E%E8%AF%9D)

豆瓣：[https://book.douban.com/subject/1102259/](https://book.douban.com/subject/1102259/)

结论：人力和时间并不呈现线性关系。以大量人员和较短的时间，并不能缩短软件的开发进度。

公式：

沟通管道数量（n 为一个项目团队中的人数，显然，人数越多，沟通成本越大）：

```txt
p = n(n-1)/2
```

Brooks 法则：

> Adding manpower to a late software project makes it later.

组织：

提倡类似外科手术团队的组织。在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。

系统设计的民主与专制：

整体性：需要专制，设计必须出自于一个人的想法，或是极少数人的一致决定。

评价标准：功能概念复杂度比。功能多不见得是好事。

避免第二系统过度设计。


◳Lawrence Li

Tagged with `programming`

Tagged with programming

Tagged with `programming`