低代码如何借助 K8s 实现高并发支持？
引言
在当今这个数字化时代，互联网的普及和技术的飞速发展使得应用程序面临着前所未有的挑战，其中最为显著的就是高并发访问的需求。随着用户数量的激增和业务规模的扩大，如何确保应用在高并发场景下依然能够稳定运行、快速响应，成为了所有开发者和技术团队必须面对的重要课题。
Kubernetes（K8s），作为云原生时代的标志性技术之一，凭借其强大的容器编排能力、自动化部署和扩展功能，在解决高并发问题方面展现出了巨大的潜力。K8s通过抽象底层资源，提供了一套高效、灵活、可扩展的容器管理方案，使得开发者能够更加专注于业务逻辑的实现，而无需过多关注底层基础设施的复杂性和运维难题。
然而，尽管K8s为应用的高并发处理提供了强有力的支持，但其复杂的配置和管理流程仍然对开发者的技术能力提出了较高的要求。为了降低这一门槛，让更多的开发者能够充分利用K8s的优势，低代码平台应运而生。低代码平台通过提供可视化的开发环境、拖拽式的组件库以及自动化的部署和管理工具，极大地简化了应用的开发、测试和部署流程，使得开发者能够用更少的代码和更短的时间完成高质量的软件开发。
因此，本文将深入探讨低代码平台如何与K8s结合，以支持并实现高并发的应用。
K8s 简介
早期，各个组织是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在同一台物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。
因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。
虽然虚拟化技术也提高了资源利用率，但每个虚拟机都运行自己的操作系统内核，这导致了较高的资源消耗，包括内存和存储空间，随而来之的便是较高的成本和不足的灵活性。于是乎，容器部署变得流行起来。容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
容器是打包和运行应用程序的好方式。在生产环境中， 你需要管理运行着应用程序的容器，并确保服务不会下线。 例如，如果一个容器发生故障，则你需要启动另一个容器。 如果此行为交由给系统处理，是不是会更容易一些？于是就轮到Kubernetes登场了，Kubernetes 提供了一个可弹性运行分布式系统的框架。 满足系统的扩展要求，可以实现负载均衡，存储编排，自我修复等多个功能
Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。 Kubernetes这个名字源于希腊语，意为“舵手”或“飞行员”。用来"驾驶"容器，实现各种各样的功能。K8s 这个缩写是因为 K 和 s 之间有 8 个字符的关系。
低代码平台简介
低代码开发是一种软件开发方法论，旨在通过减少手动编写代码的工作量，加快应用程序的开发速度和交付时间。它基于图形化的界面和可视化工具，使开发者能够使用拖放和配置等简单操作来创建应用程序。低代码开发具有以下的一些特点：
- 技术门槛低：低代码平台通过图形化界面和预定义组件，降低了技术门槛，使得非专业程序员也能参与应用开发。
- 开发效率高：由于减少了编写代码的工作量，低代码平台能够显著提高开发效率，缩短开发周期。
- 灵活性与可扩展性：低代码平台支持自定义组件和业务逻辑，能够满足不同应用场景和需求，同时支持后续的功能扩展和升级。
- 易于维护与升级：低代码平台提供统一的开发环境和管理工具，使得应用程序的维护和升级更加简单高效。
低代码开发具有以下的优势：
- 快速开发：无需编写大量代码，大大缩短了开发周期。
- 降低门槛：非技术人员也能轻松上手，降低了应用开发的门槛。
- 易于维护：由于采用模块化设计，应用易于维护和扩展。
- 节约成本：降低了人工成本和时间成本，为企业节省了开发费用。
未来，低代码平台将继续向更加智能化、集成化、云原生化方向发展，为企业提供更高效、更灵活的应用开发解决方案。同时，随着技术的不断成熟和市场的不断扩展，低代码平台将在更多领域和场景中发挥重要作用。接下来将进入到本文主要的部分，介绍如何使用低代码集成K8s实现负载均衡，应对高并发的应用场景。
低代码支持 K8s 实现高并发的具体步骤
介绍完基础概念之后，我们就可以介绍如何使用低代码平台去集成k8s实现负载均衡了，市面上有许多的代码开发平台，那此次就以企业级低代码开发平台——活字格为例，介绍活字格k8s的负载均衡方案。
环境准备
安装K8s
环境是软件运行的基础，所以我们需要准备一个至少拥有两个节点的K8s环境,一台文件服务器，一个镜像仓库。k8s作为集群部署方案 ，硬件设备至少需要两个节点以上。在本示例中，准备了3个节点，节点情况如下：
- 登录到k8s-server，并进行 k8s 的安装。本文不介绍k8s的安装，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 命令手动挂载。
- 文件共享挂载的工作完成，您可以在任何一个节点的挂载路径下读写共享文件目录。
OK，现在活字格的 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文件如下：
打包并安装
配置完成后，在 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 增加基于 Cokkie 的注解：
nginx.ingress.kubernetes.io/affinity: "cookie"
总结
至此低代码如何集成K8s实现负载均衡应对高并发场景到这里就分享完了，感谢大家的阅读
扩展链接：
