[Minutes] 8th July 2022 : Dubbo Weekly Meeting

[Albumen Kevin <al...@apache.org>]

Meeting time: 8th July 2022, 20:30 (GMT +8)
Participants: liujun, albumen, earthchen, xiongpin, goodjava, huazhongming,
etc.
Playback address: https://www.youtube.com/watch?v=IC0FuqtDosE
                               https://www.bilibili.com/video/BV1SV4y1n7vW/

This week's weekly meeting mainly discussed how Dubbo should be adjusted to
better fit such an architecture in the FaaS scenario.

## Current mainstream FaaS solutions in the community

### Based on Sidecar, forwarded via UDS
This solution combines and deploys Dubbo and other middleware into an
independent sidecar. Compared with the resident state of the user's
container, after the user's container is pulled up, the UDS request is
forwarded to the sidecar, and then the logic of the RPC request is
executed. In this mode, Dubbo degenerates into a gateway-like existence and
has been decoupled from users.

### Fat client, isolated via ClassLoader
This solution is a Java-based class isolation mechanism. Dubbo is deployed
independently by a classloader, and the FaaS scheduler will dynamically
load the business Jar package, and then pull up the user code. The Dubbo
used by users is provided by a unified Classloader. In this mode, Dubbo and
the corresponding JVM process need to be resident. In this mode, Dubbo
needs to improve the management of the life cycle. After the user process
is pulled up and dropped, it needs to deal with resource allocation and
recycling to ensure the isolation of the entire environment.

### Start with business code
This solution is to pull up Dubbo code and business code together. In this
mode, Dubbo needs to be transformed to achieve the goal of quick start and
quick availability. At the meeting, everyone felt that using Native Image
is a quick solution, and the community needs to improve the use of Native
Image mode in the future. In addition, when the cluster is pulled up
quickly, the push speed of the node can be quickly pulled up by
pre-registering and pushing the writable target after the node is ready.

会议时间：2022 年 7 月 8 日 20:30 （GMT +8）
参会人：liujun, albumen, earthchen, xiongpin, goodjava, huazhongming 等
回放地址：https://www.youtube.com/watch?v=IC0FuqtDosE
                  https://www.bilibili.com/video/BV1SV4y1n7vW/

本周周会主要讨论了在 FaaS 场景下，Dubbo 应该如何调整来更适配这样的架构。

## 当前社区主流的 FaaS 方案

### 基于 Sidecar，通过 UDS 转发
此方案将 Dubbo 和其他中间件合并部署到一个独立的 Sidecar 中，相较于用户的容器处于常驻状态，用户容器拉起后通过 UDS 请求转发到
Sidecar 中，然后再执行 RPC 请求的逻辑。这种模式下 Dubbo 退化成为类似网关的存在，和用户已经解耦出来了。

### Fat 客户端，通过 ClassLoader 隔离
此方案是基于 Java 的类隔离机制，Dubbo 独立一个 Classloader 部署，FaaS 调度器会动态加载业务 Jar
包进来，然后拉起用户代码。用户使用的 Dubbo 由一个统一的 Classloader 提供。这种模式下 Dubbo 和对应的 JVM
进程需要常驻存在。在这种模式下 Dubbo 需要完善生命周期的管理，在用户进程拉起和下掉之后需要处理资源分配和回收，保障整个环境的隔离。

### 和业务代码一起启动
此方案是将 Dubbo 代码和业务代码一起拉起的，这种模式下 Dubbo 需要进行改造，以达到快速启动快速可用的目标。会议上大家觉得使用 Native
Image 是一种快速拉起的方案，社区后续需要完善 Native Image
模式下的使用方案。此外对于集群快速拉起的时候，节点的推送速度可以通过预先注册，等节点 ready 后再推送可写标的方式来进行快速拉起。