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 后再推送可写标的方式来进行快速拉起。
