低代码如何借助 K8s 实现高并发支持？

引言

数字化时代，互联网的普及和技术的飞速发展使得应用程序面临着前所未有的挑战，其中最为显著的就是高并发访问的需求。在电商大促、在线直播、游戏发布等高峰期，系统需要同时处理成千上万甚至数百万的并发请求。面对高并发场景，系统需要面对性能瓶颈，资源竞争，故障恢复等等挑战。如何确保应用在高并发场景下依然能够稳定运行、快速响应，成为了所有开发者和技术团队必须面对的重要课题。

幸好，针对高并发的场景，业界早已有了较为成熟的解决方案，K8s 就是其中之一。K8s 作为云原生时代的标志性技术之一，提供了强大的容器编排能力，具有自动扩充，负载均衡，自愈能力等功能，在解决高并发问题方面展现出了巨大的潜力。K8s 通过抽象底层资源，提供了一套高效、灵活、可扩展的容器管理方案，使得开发者能够更加专注于业务逻辑的实现，而无需过多关注底层基础设施的复杂性和运维难题。

K8s为应用的高并发处理提供了强有力的支持，与此同时，其复杂的配置流程和管理需求也对开发者的技术能力提出了较高的挑战。

使用传统的纯代码配合 K8s 支持高并发，面临着诸多困难，比如：

开发周期长：高并发系统需要精细的架构设计、复杂的逻辑处理以及大量的性能测试，使用纯代码开发需要投入大量的人力和时间；
技术门槛高：高并发系统涉及分布式事务、缓存一致性、并发控制等多个技术难点，对开发者的技术要求较高；
运维复杂：纯代码开发的系统往往需要复杂的运维流程，包括环境部署、监控报警、故障排查等，增加了运维难度和成本。

那么，有没有更为简便的方式可以帮助开发者使用 K8s 快速搭建一个可以处理高并发场景的应用呢？答案就是使用低代码开发平台。低代码平台是一种新兴的开发方式，通过图形化界面和模型驱动的方法，大大降低了软件开发的门槛和复杂度。

传统观念认为，低代码平台主要适用于快速开发简单的填报类应用或基础的数据增删改查操作，不适应高并发的环境。针对这一普遍的疑问，本文将深入探讨低代码平台如何与 K8s 结合，以支持并实现高并发的应用。

低代码平台简介

低代码开发是一种软件开发方法论，旨在通过减少手动编写代码的工作量，加快应用程序的开发速度和交付时间。它基于图形化的界面和可视化工具，使开发者能够使用拖放和配置等简单操作来创建应用程序。低代码开发具有以下的优势：

技术门槛低：低代码平台通过图形化界面和预定义组件，降低了技术门槛，使得非专业程序员也能参与应用开发。
开发效率高：由于减少了编写代码的工作量，低代码平台能够显著提高开发效率，大大缩短了开发周期。
灵活性与可扩展性：低代码平台支持自定义组件和业务逻辑，能够满足不同应用场景和需求，同时支持后续的功能扩展和升级。
易于维护与升级：低代码平台提供统一的开发环境和管理工具，采用模块化设计，使得应用程序的维护和升级更加简单高效。

未来，低代码平台将继续向更加智能化、集成化、云原生化方向发展，为企业提供更高效、更灵活的应用开发解决方案。同时，随着技术的不断成熟和市场的不断扩展，低代码平台将在更多领域和场景中发挥重要作用。接下来将进入到本文主要的部分，介绍如何使用低代码集成 K8s 实现负载均衡，应对高并发的应用场景。

低代码支持 K8s 实现高并发的具体步骤

了解了低代码的基础概念，接下来将会介绍如何使用低代码平台集成k8s并实现负载均衡。市面上代码开发平台较多，本文以葡萄城的企业级低代码开发平台——活字格为例，介绍活字格k8s的负载均衡方案。

环境准备

安装 K8s

环境是软件运行的基础，所以我们需要准备一个至少拥有两个节点的 K8s 环境：一台文件服务器，一个镜像仓库。k8s作为集群部署方案，硬件设备至少需要两个节点以上。在本示例中，准备了3个节点，节点情况如下：

登录到k8s-server，并进行 k8s 的安装。k8s的安装流程可以参考如下文档：https://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux/
如果仅用于学习，可以选择使用 k3s 模拟。k3s 是一个完全兼容的 Kubernetes 发行版，策略与 k8s 几乎完全一致，且所需要的资源仅有k8s 的一半，很适合前期的学习与验证（本教程使用 k3s 进行环境的构建）。也可以使用 minikube 在个人计算机上来模拟k8s 集群。
当环境安装完成时，在 server 节点上应当可以正常使用 kubectl 命令对 k8s 进行管理。使用 kubectl get node 查看集群节点状态：

文件服务器

为确保节点中的公共资源可以共享，需要准备一台文件服务器，创建共享文件目录，并确保该共享路径可以挂载到每个节点的指定路径上。文件服务器的协议可以遵照服务器现有的标准进行制定，如NAS、NFS等。本文中，选择在 k8s-master 通过 NFS 构建共享文件目录。

为所有的节点安装 nfs 相关的依赖。
登录到k8s-master，创建文件根目录fgc-k8s-lbroot。下面的5个目录也可以分别创建在不同的文件服务器上，或者不同的目录下，根据实际情况创建即可（可自定义）。并在该目录中创建 5 个子文件夹（名称不可更改）。

# 用于共享的根目录
sudo mkdir /fgc-k8s-lbroot
# 附件存储目录
sudo mkdir /fgc-k8s-lbroot/ForguncyAttach
# 日志存储路径
sudo mkdir /fgc-k8s-lbroot/ForguncyLogs
# 备份存储路径
sudo mkdir /fgc-k8s-lbroot/ForguncyRestore
# 网站存储路径
sudo mkdir /fgc-k8s-lbroot/ForguncySites
# 网站可执行文件存储路径
sudo mkdir /fgc-k8s-lbroot/ForguncySitesBin

sudo chown nobody:nogroup /fgc-k8s-lbroot/*
sudo chmod -R 777 /fgc-k8s-lbroot/*

# 该文件是 NFS 服务器的配置文件之一，过编辑此文件，系统管理员可以控制哪些文件系统可以通过NFS协议被远程主机挂载和访问
sudo vim /etc/exports
# 在文件内加入如下配置，使其变为共享，编写完成后保存退出
/fgc-k8s-lbroot *(rw,sync,no_subtree_check)
#退出后刷新配置，确保生效
sudo exportfs -arv

目录 /fgc-k8s-lbroot 便可以被其他服务器进行挂载并读写。需要进入到所有的 worker 服务器上将该目录进行挂载。

# 登录 worker 服务器
ssh  k8s-worker1
# 创建挂载路径
sudo mkdir -p /mnt/fgc_k8s_lb
# 打开系统挂载的配置文件
sudo vim /etc/fstab
# 在配置文件中配置将文件管理共享出的目录地址
198.19.249.12:/fgc-k8s-lbroot /mnt/fgc_k8s_lb nfs hard,intr,rw 0 0

需要留意，上一步挂载配置会在节点重启后进行自动挂载，如果没有重启，则需要通过 mount 命令手动挂载。
文件共享挂载的工作完成后，可以在任何一个节点的挂载路径下读写共享文件目录。

现在，活字格的 k8s 环境已经搭建完成，接下来正式进入安装环节。

安装活字格服务器

安装Helm

为了方便k8s 的包管理，我们需要引入 Helm 来管理活字格服务的配置模板。

#下载安装包并安装
wget https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz
sudo tar -zxvf helm-v3.14.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm
#查看版本
helm version

安装完成后，执行查看版本命令得到如图结果：

下载活字格负载均衡服务器安装文件

点击Hzg-K8S-HelmChart-10.0.3.0.zip,下载文件，并解压到本地目录,会看到如下目录文件：

详细设置如下：

values.yaml ：为主要配置文件，如果使用离线仓库，请修改仓库地址和Tag，否则默认使用官网镜像，请将文件服务器地址改为实际使用的地址。
Chart.yaml：可以修改Chart的名称，一般不需要修改，保持默认。
service-redis.yml：默认启动一个redis服务，不需要的可以删除本文件，删除时将文件deployment-redis.yaml一并删除。
service-influx.yml：这是日志服务的service文件，负载均衡情况下，日志运行在一个独立的POD下，并且不支持负载均衡，只能有一个pod，一般不需要修改。
service-fgc.yml：活字格服务的service文件，一般不需要修改。
pvs.yaml：K8S的PV文件，请根据自身的存储情况进行修改，如果是NFS协议的文件服务，一般不需要修改。
pvcs.yaml：K8S的PVC文件，一般不需要修改。
deployment-redis.yaml：默认启动的redis的POD文件，不需要的话可以删除本文件，删除时将文件service-redis.yaml一并删除。
deployment-influx.yaml：活字格日志的POD文件，一般不需要修改。
deployment-fgc.yaml：活字格服务的POD文件，一般不需要修改。

修改chart文件的内容

从上方详细设置内容可知，template 中的配置与 value.yaml是我们关注的重点。一般情况下，template 的配置项无需修改，只修改 value.yaml 中的变量值即可。对于本文中的环境，修改value.yaml文件如下：

image:
  repository: grapecitysoftware/hzg-k8s  #活字格 server 的镜像仓库地址
  tag: 10.0.3.0  #活字格 server镜像的tag
persistentVolume:
  storage: "10Gi" #存储数据大小
  nfs_atach:
    path: "/fgc-k8s-lbroot/ForguncyAttach"  #附件存储路径
    server: "198.19.249.12"  #共享存储服务器路径
  nfs_log:
    path: "/fgc-k8s-lbroot/ForguncyLogs"  #日志存储路径
    server: "198.19.249.12"  #共享存储服务器路径
  nfs_restore:
    path: "/fgc-k8s-lbroot/ForguncyRestore"  #备份存储路径
    server: "198.19.249.12"  #共享存储服务器路径
  nfs_site:
    path: "/fgc-k8s-lbroot/ForguncySites"  #网站存储路径
    server: "198.19.249.12"  #共享存储服务器路径
  nfs_bin:
    path: "/fgc-k8s-lbroot/ForguncySitesBin"  #网站可执行文件存储路径
    server: "198.19.249.12"  #共享存储服务器路径

打包并安装

配置完成后，在 chart 所在的根目录上，直接运行 helm package your-chart-name 即可将 k8s 配置打包成一个后缀为 tgz 的标准的 chart 文件。之后运行 helm install 命令，将活字格服务对应的 chart 进行 k8s 安装。

#打包，执行下面打包命令后，会生成一个forguncy-k8s-server-10.0.0.0.tgz文件，即为helm的安装文件
helm package mychart-forguncy
#使用上面输出的forguncy-k8s-server-10.0.0.0.tgz文件，安装活字格服务（下面命令中的myfgcchart-test3为自定义的安装名称，建议不要太长）
helm install myfgcchart-test3 forguncy-k8s-server-10.0.0.0.tgz

执行上述命令后，活字格负载均衡服务已经安装完成，进入配置阶段。如果需要更新或者卸载，请执行对应的helm命令，如：

#使用新的values.yaml文件更新
helm upgrade myfgcchart-test3 /root/forguncy-k8s-server-10.0.0.0.tgz --values /root/mychart-forguncy/values.yaml
#卸载安装的活字格服务
helm uninstall myfgcchart-test3

至此，活字格服务已经成功安装在 k8s 集群上，我们可以通过 kubectl 命令来查看活字格服务的状态：

服务说明

我们会创建 3 个 deployment，分别是forguncy-pod，redis-pod，influx-pod：

forguncy-pod：活字格服务的 pod 集声明，运行活字格的所有服务，包括控制台以及发布的业务应用。活字格服务的主程序POD，可以有多个副本。
redis-pod：redis 服务的 pod 集声明，运行 redis 服务，用于活字格应用负载均衡时的状态共享。功能性上和原有的负载均衡策略的 redis 类似。是redis服务，可选安装。
influx-pod：influxDB 服务的 pod 集声明，运行 influxDB 服务，服务于活字格的日志模块。活字格服务的日志系统POD，只能有一个副本。

同时，针对于对应的 deployment，会创建相应的 service。服务会通过 service 暴露的端口进行提供。外部可以通过任何一个 k8s 节点 IP 加端口号的方式访问到活字格的服务，例如访问活字格管理控制台的访问地址为：http://198.19.249.12:32666/UserService/AdminPortal/。其中，198.19.249.12 是 k8s-server 的 IP，32666 是 forguncy-service 对外暴露的端口。直接在浏览器中访问结果如图：

配置负载均衡

开启负载均衡

活字格服务安装好以后，默认不是负载均衡状态，需要手动开启相关设置。在单 pod 的前提下，我们登录到活字格服务器管理控制台中，开启负载均衡。

对应的负载均衡入口没有发生变化，仍处于设置列表中。当开启负载均衡后，需要将用户信息数据库配置到外联数据库中。此外，redis 的服务也同样需要配置。需要注意，考虑到 k8s 的特性，每次 pod 的创建与销毁，其 IP 都会发生变化，所以这里 redis 服务应当配置为 service 的名称，而不是特定的 IP。

ps：默认安装的 redis 服务是没有密码的。

测试连接成功后，点击保存，会重启活字格的服务，会重新生成新的 forguncy-pod。

此时，为了确保后续应用与节点的正常访问，需要确保活字格集群已经激活 k8s 对应的授权。

动态扩容

当我们开启负载均衡并重启成功后，活字格侧的操作就完成了。后续所有的扩容、自愈行为都依赖于 k8s 本身的行为策略进行执行。

目前活字格的服务只有一个 pod ，现在可以根据实际需求去动态的扩展节点。

# 将 pod 的节点升级到 6 个
kubectl scale deployment fgc-chart-test-forguncy-pod --replicas=6

该命令为 kubectl 自带的动态扩容命令，k8s 会基于设定的 replicas 值去动态的创建包含服务的 pod 并自动负载。可以通过 kubectl get pod 查看当前的 pod 状态。也可以在扩容的时候通过参数 —watch 查看 pod 的变化过程。

如果需要查看请求被指向了哪个节点，可以通过修改对应的配置项开关来实现。对应的配置路径位于：

/fgc-k8s-lbroot/ForguncySites/SettingsFolder/ForguncyRouterConfig.json

将其中的 ShowXUpstream 的值设置为 true 即可。重置 pod 数量后，可以通过 cookie 查看被指向的 pod 节点名称。

应用发布与路由

现在可以向集群发布应用了。当应用发布成功后，应用的设置域名会自动配置为 http://{publishserver}/{appname}，例如：http://198.19.249.12:32666/stock-management，其中：

{Publishserver} 198.19.249.12:32666是在设计器中配置发布的服务器。

{Appname} stock-management是在设计器中发布的应用程序名称。

需要注意，由于应用服务是基于集群的，所以必须使用外联库，使用内建库的应用会访问异常。

当然，在实际的运维场景中，我们可能需要对应用服务进行路由。对于活字格的一些服务来说也需要会话保持功能，所以我们需要开启 k8s 中 Ingress 和 Service 的会话保持配置（Service已在安装脚本中默认配置，如果有使用到Ingress。则需要手动添加规则）。

Ingress 可为 Service 提供外部可访问的 URL、对其流量作负载均衡、终止 SSL/TLS，以及基于名称的虚拟托管等能力。当然，您也可以自己使用 nginx 的 ip_hash来模拟类似的效果。

如 Ingress 增加基于 Cookie 的注解：

nginx.ingress.kubernetes.io/affinity: "cookie"

总结

以上就是低代码如何集成K8s实现负载均衡应对高并发场景的全部内容，感谢阅读。

活字格企业级低代码开发平台 | 下载试用

活字格是葡萄城基于在专业控件领域 40 年的技术积累而推出的企业级低代码开发平台，由简单易用的可视化设计器和部署灵活的服务器构成，能帮助开发人员、IT 技术人员和业务人员快速构建美观易用、架构专业、安全可控的企业级多终端应用，并随需而变。活字格高度开放灵活，支持云部署和本地部署，能与微信、钉钉及各行业应用软件无缝集成，并可对接智能硬件、AI 等技术，全面支撑核心业务系统开发。

了解更多关于活字格企业级低代码开发平台内容，请点击此处访问官网，立即下载体验。