Skip to main content

· 9 min read

Curve 是网易主导自研的现代化存储系统, 目前支持文件存储(CurveFS)和块存储(CurveBS)。

CurveBS 的核心应用场景主要包括:

  • 虚拟机/容器的性能型、混合型、容量型云盘或持久化卷,以及物理机的远程存储盘
  • 高性能存算分离架构:基于RDMA+SPDK的高性能低时延架构,支撑MySQL、kafka等各类数据库、中间件的存算分离部署架构,提升实例交付效率和资源利用率

CurveFS 的核心应用场景主要包括:

  • AI训练(含机器学习等)场景下的高性价比存储
  • 大数据场景下的冷热数据自动化分层存储
  • 公有云上高性价比的共享文件存储:可用于AI、大数据、文件共享等业务场景
  • 混合云存储:热数据存储在本地IDC,冷数据存储在公有云

使用 CurveAdm 部署 CurveFS

CurveAdm 是 Curve 团队为提高系统易用性而设计的工具,其主要用于快速部署和运维 CurveBS/CurveFS 集群。主要特性:

  • 快速部署 CurveBS/CurveFS 集群
  • 容器化服务
  • 运维 CurveBS/CurveFS 集群
  • 同时管理多个集群
  • 一键升级
  • 错误精确定位

安装 CurveAdm

bash -c "$(curl -fsSL https://curveadm.nos-eastchina1.126.net/script/install.sh)"

主机列表

主机模块用来统一管理用户主机,以减少用户在各配置文件中重复填写主机 SSH 连接相关配置。我们需导入部署集群和客户端所需的机器列表,以便在之后的各类配置文件中填写部署服务的主机名。

这里采用一台服务器,做单节点集群。

配置免密登陆

生成密钥并配置服务器免密登陆

# 一直回车即可
ssh-keygen

# 使用 ssh-copy-id 配置
ssh-copy-id root@172.31.98.243

# 验证免密
ssh root@172.31.98.243

# 无需输入密码登陆成功即可

导入主机列表

准备主机列表文件 hosts.yaml

$ vim hosts.yaml

global:
user: root # ssh 免密登陆用户名
ssh_port: 22 # ssh 端口
private_key_file: /root/.ssh/id_rsa # 密钥路径

hosts:
- host: curve
hostname: 172.31.98.243

导入主机列表

$ curveadm hosts commit hosts.yaml

查看主机列表

$ curveadm hosts ls

准备集群拓扑文件

CurveFS 支持单机部署和高可用部署,这里我们采用单机部署验证。

创建 topology.yaml 文件,只需修改 target: curve,其他都默认即可。

$ vim topology.yaml

kind: curvefs
global:
report_usage: true
data_dir: ${home}/curvefs/data/${service_role}${service_host_sequence}
log_dir: ${home}/curvefs/logs/${service_role}${service_host_sequence}
container_image: opencurvedocker/curvefs:v2.4
variable:
home: /tmp
target: curve

etcd_services:
config:
listen.ip: ${service_host}
listen.port: 2380${service_host_sequence} # 23800,23801,23802
listen.client_port: 2379${service_host_sequence} # 23790,23791,23792
deploy:
- host: ${target}
- host: ${target}
- host: ${target}

mds_services:
config:
listen.ip: ${service_host}
listen.port: 670${service_host_sequence} # 6700,6701,6702
listen.dummy_port: 770${service_host_sequence} # 7700,7701,7702
deploy:
- host: ${target}
- host: ${target}
- host: ${target}

metaserver_services:
config:
listen.ip: ${service_host}
listen.port: 680${service_host_sequence} # 6800,6801,6802
listen.external_port: 780${service_host_sequence} # 7800,7801,7802
global.enable_external_server: true
metaserver.loglevel: 0
braft.raft_sync: false
deploy:
- host: ${target}
- host: ${target}
- host: ${target}
config:
metaserver.loglevel: 0

部署集群

添加 my-cluster 集群,并指定集群拓扑文件

curveadm cluster add my-cluster -f topology.yaml

切换 my-cluster 集群为当前管理集群

curveadm cluster checkout my-cluster

开始部署集群

$ curveadm deploy
......
Cluster 'my-cluster' successfully deployed ^_^.

终端出现 Cluster 'my-cluster' successfully deployed ^_^. 即部署成功。

查看集群运行情况

$ curveadm status
Get Service Status: [OK]

cluster name : my-cluster
cluster kind : curvefs
cluster mds addr : 192.168.3.81:6700,192.168.3.81:6701,192.168.3.81:6702
cluster mds leader: 192.168.3.81:6702 / 7f5b7443c563

Id Role Host Replicas Container Id Status
-- ---- ---- -------- ------------ ------
6ae9ac1ae448 etcd curve 1/1 d3ecb4e81318 Up 17 minutes
c45e2f0b9266 etcd curve 1/1 8ce9befa54b8 Up 17 minutes
6c6bde442a04 etcd curve 1/1 cbf093c6605f Up 17 minutes
9516d8f5d9ae mds curve 1/1 f338ec63c493 Up 17 minutes
fe2bf5d8a072 mds curve 1/1 b423c3351256 Up 17 minutes
7f5b7443c563 mds curve 1/1 7ad99cee6b61 Up 17 minutes
e6fe68d23220 metaserver curve 1/1 d4a8662d4ed2 Up 17 minutes
b2b4dbabd7bf metaserver curve 1/1 65d7475e0bc4 Up 17 minutes
426ac76e28f9 metaserver curve 1/1 f413efeeb5c9 Up 17 minutes

部署 Rainbond

Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。

可以通过一条命令快速安装 Rainbond 单机版。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

执行完上述脚本后,耐心等待 3-5 分钟,可以看到如下日志输出,表示 Rainbond 已启动完成。

INFO: Rainbond started successfully, Please pass http://$EIP:7070 Access Rainbond

部署 MinIO

由于目前 CurveFS 只支持 S3 作为后端存储,CurveBS 后端即将支持。 所以我们需要部署一个 MinIO 对象存储。

通过 Rainbond 开源应用商店一键部署单机版 MinIO 或者集群版 MinIO。进入到 Rainbond 的 平台管理 -> 应用市场,在开源应用商店中搜索 minio 进行一键安装。

部署完成后,通过 Rainbond 提供的域名访问 MinIO 控制台,默认用户密码 minio/minio123456。然后需要创建一个 Bucket 供 CurveFS 使用。

部署 CurveFS-CSI

  • 前提:Rainbond 版本要在 v5.13+

通过 Rainbond 开源应用商店一键部署,进入到 Rainbond 的 平台管理 -> 应用市场,在开源应用商店中搜索 curve-csi 进行一键安装。

由于 CurveFS-CSI 没有 Rainbond 应用模型类的组件,都属于 k8s 资源类型,可在 应用视图内 -> k8s资源 下看到。

安装完成后,需要修改 curvefs-csi-cluster-role-bindingcurvefs-csi-role-binding 的 namespace 为当前团队的 namespace,如当前团队 namespace 为 dev,如下:

# curvefs-csi-role-binding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: curvefs-csi-role-binding
......
subjects:
- kind: ServiceAccount
name: curvefs-csi-service-account
namespace: dev # changed

# curvefs-csi-cluster-role-binding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: curvefs-csi-cluster-role-binding
......
subjects:
- kind: ServiceAccount
name: curvefs-csi-service-account
namespace: dev # changed

创建 storageclass 资源,同样在 应用视图内 -> k8s资源 -> 添加

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: curvefs-sc
provisioner: csi.curvefs.com
allowVolumeExpansion: false
reclaimPolicy: Delete
parameters:
mdsAddr: "172.31.98.243:6700,172.31.98.243:6701,172.31.98.243:6702"
fsType: "s3"
s3Endpoint: "http://9000.grda6567.1frt0lmq.b836cf.grapps.cn"
s3AccessKey: "minio"
s3SecretKey: "minio123456"
s3Bucket: "curve"
  • mdsAddr:通过 curveadm status 命令获取。

    $ curveadm status
    ......
    cluster mds addr : 172.31.98.243:6700,172.31.98.243:6701,172.31.98.243:6702
  • s3Endpoint:填写 MinIO 组件的 9000 端口对外服务域名。

  • s3AccessKey:MinIO 访问 Key,填 root 用户或生成 AccessKey。

  • s3SecretKey:MinIO 密钥 Key,填 root 密码或生成 SecretKey。

  • s3Bucket:MinIO 桶名称。

在 Rainbond 上使用 CurveFS

通过镜像创建一个 Nginx 组件,在 组件 -> 其他设置 修改组件部署类型为 有状态服务。在 Rainbond 上只有 有状态服务 可以使用自定义存储,无状态服务使用默认的共享存储。

进入到 组件 -> 存储 添加存储,选择类型为 curvefs-sc,保存并重启组件。

等待组件启动完成后,进入组件的 Web 终端内,测试写入数据。

然后进入到 MinIO 桶内查看,数据已写入。

未来规划

Rainbond 社区未来会使用 Curve 云原生存储作为 Rainbond 底层的共享存储,为用户提供更好、更简单的云原生应用管理平台和云原生存储,共同推进开源社区生态以及给用户提供一体化的解决方案。

· 11 min read

Gateway API 作为新一代的流量管理标准,对原有 Ingress 的扩展不规范、移植性差等问题做出了改进。从兼容K8s生态和优化网关体验出发,Rainbond 支持以插件的形式扩展平台网关能力,目前已经有多家社区提供了 Gateway API 的实现,将其制作成平台插件后,一键部署后即可在平台中使用拓展网关能力。我们可以制作不同的网关实现插件来应对不同的场景和需求,同时可以将自己制作的插件发布到应用商店供大家使用。

本篇文章将以 Envoy Gateway 为例详细介绍如何制作并发布你的 Kubernetes Gateway API 插件。最后发布到开源应用商店的 Gateway API 插件将可以被其他用户使用,同时积极参与贡献也有机会获得由我们提供的小礼品。

前提条件

  • Rainbond 版本大于 v5.13

  • Rainbond 已经对接过开源应用商店并拥有推送权限

Rainbond 与 Gateway API 集成机制

在 Rainbond 中,之前仅支持内置网关,应用定义好路由规则后,外部流量即可直接访问到对应应用。而 Gateway API 是以插件和能力扩展的形式与平台进行结合的。在平台中,只有安装了 Gateway API 自定义资源以及至少有一个网关实现后,才可以扩展平台网关能力。

如下图所示,如果 App 4App 5等应用想要使用支持 Gateway API 的网关实现,那么首先需要定义 Gateway API 的相关资源,而这类资源是由 Gateway API 基础资源插件提供的,它主要包含了 Gateway API 资源类型的定义以及相关的 WebHook 资源。同时它在平台上暴露了 GatewayClass 和 Gateway 类型的资源,在平台能力扩展中可以看到。这样用户可以自定义网关行为和配置。

因此我们只需要制作一个网关插件,即可读取 Gateway 类型的资源并生成对应的配置,向外提供网关能力。目前 Gateway API 已有多种实现,如 Envoy、Nginx、Istio 等。这里我们选择 Envoy 作为网关,这样外部流量进入 Envoy后,即可根据对应的路由策略到达 App 4 等应用上。

制作自定义网关插件的步骤

实现 Gateway API 插件的完整流程如上图所示,主要分为以下五步:

  1. 部署 Gateway API 基础资源:目前 Gateway API 主要由一系列自定义资源(CRD)组成,在集群中使用其能力时,需要先部署这些基础资源,才能使集群识别该类型的资源。
  2. 选择 Gateway API 网关实现:目前 Gateway API 已有多家 下游实现,这些网关实现都可以自由选择,提供对外服务的能力。
  3. 平台部署网关并测试:需要将网关实现转化为平台资源进行部署测试。只有这样最后才可以一键发布到开源应用商店供他人使用。
  4. 制作和发布插件:定义插件相关元数据,并发布到开源应用商店。
  5. 完善插件信息并上架:完善插件的介绍后,可以让用户更好的使用该插件。

下面将会针对这几个步骤详细说明。

部署 Gateway API 基础资源

在制作下游网关实现插件之前,我们需要安装 Gateway API 基础的 CRD 和控制器等资源,平台已经将这些资源打包成插件应用上架到开源应用商店。我们只需要在 平台管理->应⽤市场->开源应⽤商店->搜索 GatewayAPI-Base 并进行安装即可,由于 Gateway API 中 RBAC 相关资源对命名空间有依赖,所以我们需要在安装时,新建一个团队,团队英文名设置为 gateway-system,这样将会将其安装至 gateway-system 命名空间下,最好单独创建⼀个应⽤,应⽤的名称⻅名知意,便于后期管理。

选择 Gateway API 网关实现

k8s Gateway API 实现列表中有多个实现,制作的话可以去这里挑选,由于目前 k8s Gateway API 目前 HttpRoute 已支持到 Beta 版本,所以我们需要挑选 HTTPRoute 资源支持到 beta 版本的下游实现,如 IstioCiliumKong 等。由于 Envoy Gateway 已支持到 Beta 版本,所以我们本次使用其作为网关插件的扩展。

在Rainbond上部署并测试

挑选好实现后,你可以在实现的官网中看到如何安装实现,拿 envoy 为例,envoy 官网给出了两组 Yaml 如下:

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.3.0/install.yaml
kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/v0.3.0/examples/kubernetes/http-routing.yaml
  • install.yaml 此 YAML 文件中存放的便是我们插件所需的基础资源。
  • http-routing.yaml 这个 YAML 文件我们需要进行处理,只保留我们插件所需的 GatewayClass 资源和 Gateway 资源,HttpRoute 资源不需要保留,在平台定义网关策略后将会自动生成。

将整理好的资源 YAML 后,在应用视图的 k8s 资源管理处创建,功能位置:应用视图 ---> k8s 资源 ---> 添加

⚠️注意:如果有RoleBinding 等需要标识命名空间的资源,则需要确保标识的命名空间和当前上传的团队所对应的命名空间是否一致,以免造成权限不足等问题,示例如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
...
subjects:
- kind: ServiceAccount
name: certgen
namespace: envoy-gateway-system

上传创建完成后,我们还需要在 平台管理视图->扩展->能力 中处理一下 Gateway 资源,将网关的 Service 名称或前缀标记出来,后续在创建 HTTP 策略的时候便可获取并展示你的域名解析地址。

labels:
service-name: envoy-envoy-gateway-system-envoy

NodePort 是从节点上获取的 IP ,默认为 NodeInternalIP ,如果存在 NodeExternalIP 则优先使用 NodeExternalIP 。

LoadBalancerIP 是从 Service 资源上的 ExternalIPs 获取IP,如果不存在则不展示。

完成以上操作后,我们需要进行测试,主要检查以下几项。

  1. 检查组件是否都运行正常,状态是否都为运行中。
  2. 检查应用下的 k8s 资源是否都创建成功。
  3. 当所有资源的状态都正常后,参考 Gateway API 网关使用文档进行使用测试,查看是否可以正常使用。

制作和发布插件

如果想将该网关实现作为平台网关插件进行发布,那么还需要准备标志应用为插件的 RBDPlugin 资源,定义好该资源后,才可以在平台管理->插件中查看到该插件并进行管理。示例如下:

apiVersion: rainbond.io/v1alpha1
kind: RBDPlugin
metadata:
name: RBDPlugin 资源名称
spec:
alias: 插件别名
author: 插件制作人
description: 插件简介
icon: 插件图标
version: 插件版本

定义好该资源后,我们可以进行发布了,在应用拓扑图页面,点击左侧发布按钮,选择发布到云应用商店,即可将其发布到开源应用商店。

完善插件信息并上架

发布到开源应用商店的插件或应用,我们需要登录开源应用商店编辑其信息并上架后,该应用才可被其他用户查看和使用。可以参考如何分享插件或应用到 Rainbond 应用商店

登录完成后点击右上角控制台,选择管理应用。这时候应该可以看到刚刚发布的 Envoy 插件。点击应用名称进入详情页面,此时需要编辑应用的名称、Logo、详细信息。

当应用基础信息补充完成后,我们需要为其添加一个套餐,才可以上架。套餐在这里的作用主要是将应用的版本管理起来。用户使用不同的套餐安装的版本也不同。

在补充完应用的基本信息和套餐后,就可以准备上架了。只有上架的应用才可以被其他用户浏览和使用。回到管理应用的页面,选择上架即可。

最终效果

我们可以在开源应用商店查看到我们制作的网关插件,如下图所示,其余用户也可以在 Rainbond 中一键部署使用,具体使用可以参考 Gateway API 使用文档。

· 8 min read

流水线插件 是基于 Rainbond 插件体系 扩展实现,通过插件化的方式,可以实现对 Rainbond 构建体系的扩展。该插件由社区合作伙伴 拓维信息 参与开发并贡献,底层是基于 GitLab CI/CD 实现。

流水线构建与 Rainbond 源码构建的区别是:

  • Rainbond 源码构建:使用简单,固定的构建模式,用户只需提供源代码,但不是很灵活。
  • 流水线构建:自定义构建步骤,使用更加灵活。

本文将介绍使用流水线插件部署 RuoYi SpringBoot 项目,并实现提交代码后自动构建、自动部署。

安装 GitLab 和 Runner

流水线插件是基于 GitLab 实现,所以需要依赖 GitLab 和 GitLab Runner,如果已有则可跳过此步。

通过 Rainbond 开源应用商店部署 GitLab 和 Runner,进入到 平台管理 -> 应用市场 -> 开源应用商店 中分别搜索 GitLabGitLab-runner,选择版本进行安装,分别安装到同一个应用内。

部署完成后,访问 GitLab 默认的域名进行用户注册。然后关闭 GitLab 默认的 AutoDevOps:Admin -> Settings -> CI/CD -> Continuous Integration and Deployment 取消勾选 Default to Auto DevOps pipeline for all projects

注册 Runner

GitLab 和 Runner 都部署完成后,需要将 Runner 注册到 GitLab 中。

进组 Runner 组件内 -> Web 终端,执行以下命令进行注册:

  • <URL> 为 GitLab 访问地址
  • <TOKEN> 在 GitLab 的 Admin -> Runners 获取 Registration token
  • <TAG> 自定义 Runner 的标签。
gitlab-runner register \
--non-interactive \
--executor "docker" \
--docker-image alpine:latest \
--url "<URL>" \
--registration-token "<TOKEN>" \
--description "docker-runner" \
--tag-list "<TAG>" \
--run-untagged="true" \
--locked="false" \
--docker-volumes /var/run/docker.sock:/var/run/docker.sock \
--docker-volumes /root/.m2/repository \
--docker-privileged="true" \
--access-level="not_protected" \
--docker-pull-policy="if-not-present"

注册完成后,可以在Admin -> Runners 页面中看到如下图,Statusonline 则正常。

安装流水线插件

通过 Rainbond 开源应用商店部署 Pipeline 应用插件,进入到 平台管理 -> 应用市场 -> 开源应用商店 中搜索 Pipeline,选择对应的版本进行部署。

安装完成后,需要修改 Pipeline-Backend 服务的配置,进入到 Pipeline 应用内 -> Pipeline-Backend组件内,修改以下环境变量:

  • RAINBOND_URL:Rainbond 控制台访问地址,例如:http://192.168.3.33:7070
  • RAINBOND_TOKEN:Rainbond 控制台的 Token,可以在 右上角用户 -> 个人中心 -> 访问令牌 中获取。

修改完成后,更新或重启 Backend 组件生效。

进入到 Pipeline 应用内 -> k8s 资源 -> 编辑 rainbond-pipeline,修改 pipeline 资源中的 access_urls 配置,修改为 Pipeline-UI 组件的对外访问地址,如下:

apiVersion: rainbond.io/v1alpha1
kind: RBDPlugin
metadata:
labels:
plugin.rainbond.io/name: pipeline
name: pipeline
spec:
access_urls:
- https://custom.com
alias: Pipeline
author: Talkweb
description: 该应用插件是基于 GitLab CI/CD 实现,扩展 Rainbond 已有的构建体系。
icon: https://static.goodrain.com/icon/pipeline.png
version: 1.0.0

修改完成后,就可以在每个团队视图中看到 流水线 按钮选项了。

部署 RuoYi 项目

将 Gitee 中的 RuoYi 项目 Fork 到私有的 GitLab 中。

修改项目配置文件中的 mysql 连接地址:

# ruoyi-admin/src/main/resources/application-druid.yml
......
spring:
datasource:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
druid:
# 主库数据源
master:
url: jdbc:mysql://${MYSQL_HOST}:3306/ry?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8
username: root
password: root

部署 MySQL

通过 Rainbond 开源应用商店部署 MySQL 即可。部署之后打开 MySQL 对外服务端口,通过本地工具连接到数据库并创建 ry 数据库和初始化 sql 目录下的 quartz.sqlry_20230223.sql

部署 RuoYi SpringBoot

进入到 团队视图 -> 流水线

1.创建流水线

进入流水线管理,选择 Java Maven 单模块的模版创建。

如果没有 SonarQube 代码扫描步骤可以删除,修改 编译构建物 步骤:

  • 制品目录:ruoyi-admin/target/*.jar

修改 构建镜像 步骤:

  • 脚本命令:
cp ruoyi-admin/target/*.jar app.jar
docker login -u ${REPOSITORY_USERNAME} -p ${REPOSITORY_PASSWORD} ${REPOSITORY_URL}
docker build -t ${REPOSITORY_URL}/${ORG}/${MODULE}:${DEVOPS_VERSION} .
docker push ${REPOSITORY_URL}/${ORG}/${MODULE}:${DEVOPS_VERSION}

在流水线的变量内,指定 Docker 相关的环境变量用于打包镜像和推送镜像:

  • REPOSITORY_URL:镜像仓库地址,如:registry.cn-hangzhou.aliyuncs.com
  • ORG:镜像仓库组织,例如:goodrain
  • REPOSITORY_USERNAME:镜像仓库用户名
  • REPOSITORY_PASSWORD:镜像仓库密码

2.创建应用服务

  • 服务编码:唯一的
  • 服务名称:自定义
  • 流水线:选择流水线模版
  • 仓库配置:填写仓库地址,如:http://gitlab.test.com/root/ruoyi.git
  • 认证配置:可选用户密码或Token

创建应用服务后,可在 GitLab 仓库内看到多了两个文件 Dockerfile.gitlab-ci.yml ,这是由流水线插件服务自动生成并提交到仓库内。

3.构建服务

进入 代码管理,应用服务选择 ruoyi,点击 构建 按钮开始构建。可以在持续集成页面看到构建状态以及步骤,点击步骤可跳转至 GitLab 详情页。

4. 部署后端服务

等待构建完成后,即可在镜像仓库中看到构建的镜像版本,接下来就可以通过该版本进行部署,可选择部署到当前团队下的哪个应用内。

部署完成后,可在部署历史页面看到部署历史,点击部署详情跳转到 Rainbond 组件内。

编辑依赖关系

接下来进入到应用内,切换到编排模式将 ruoyi 服务依赖至 MySQL 服务,并更新 ruoyi 组件。

进入到 ruoyi 组件内 -> 端口,添加 80 端口并打开对外服务,即可通过默认的域名访问到 ruoyi UI。

配置自动构建和自动部署

编辑已经创建的应用服务,打开自动构建和自动部署按钮,下次提交代码时将会自动触发整个流程。

最后

通过流水线插件可以更灵活的扩展构建过程,比如增加代码扫描、构建成功后的消息通知等等。流水线插件也会持续迭代,欢迎大家安装使用!

· 16 min read

随着云计算的普及,越来越多的企业开始将业务应用迁移到云上。然而,如何构建一套完整的云原生 Serverless 平台,依然是一个需要考虑的问题。

Serverless的发展趋势

云计算行业从 IaaS(基础设施即服务)到 PaaS(平台即服务),再到 Serverless(无服务器)的发展,经历了一个逐渐从底层到上层,从IT基础设施提供商到应用开发者的转移的过程。

IaaS 时代,云计算提供商主要提供基础设施服务,包括计算、存储、网络等,用户需要自己搭建运维应用。这个阶段主要面向IT运维人员和企业内部的应用开发团队。

随着 PaaS 的出现,云计算提供商开始提供更高层次的服务,包括开发框架、数据库、消息队列等,用户只需要关注应用开发,无需关心底层设施。这个阶段主要面向应用开发者和创业公司,可以大大提高开发效率和降低成本。

而 Serverless 的出现,则更进一步解放了应用开发者的手脚,将服务器管理交给云计算提供商,应用开发者只需关注业务逻辑的实现,无需关心服务器的管理和维护。Serverless的出现使得应用开发更加灵活和高效,也降低了开发和运维成本,因此受到了越来越多的关注。

总体来看,从IaaS到PaaS再到Serverless的发展,是云计算服务不断向上层抽象和自动化的过程,提高了IT基础设施和应用开发的效率,降低了成本,推动了数字化转型的进程。随着技术和市场的不断变化,未来云计算服务还将不断地向更高层次的抽象和自动化发展。

自建 Serverless 的意义与困境

建设私有化的云原生 Serverless 平台具有重要的意义和必要性。首先,相比于公共云平台,私有化的云原生 Serverless 平台可以更好地满足企业的特定需求,保障数据的安全性和隐私性,同时也能够更好地管理和控制计算资源的分配和利用。其次,随着数字化转型和云原生技术的普及,企业对于 Serverless 架构的需求也越来越大,建设私有化的 Serverless 平台可以更好地满足企业的需求,提高企业的业务效率和运营效果。

然而,建设私有化的云原生 Serverless 平台也具有一定的难点。首先,需要企业拥有一定的技术实力和人才储备,包括云计算、容器、微服务等多种技术的掌握和运用。其次,需要进行系统的架构设计和资源规划,包括容器集群的搭建、网络的配置、存储的规划等。此外,私有化的Serverless平台需要满足高可用、高性能、高安全的要求,需要进行多方面的测试和优化。最后,建设私有化的Serverless平台需要考虑成本的控制和效益的提升,需要综合考虑多种因素,包括硬件设备、软件开发和维护等成本。因此,建设私有化的云原生Serverless平台需要企业在技术、资源、人才和经济等多方面进行全面的规划和考虑,确保平台的稳定性和可持续性。

ServerLess 的特点

目前,Serverless 并没有一个业界统一的标准规范,因为 Serverless 并不是一种具体的技术或架构,而是一种基于云计算的应用运行和部署方式,这种部署方式凸显出开发人员不必关心服务器等基础设施。一般情况下,我们认为一个云原生的 Serverless 平台应该提供以下能力:

  1. 弹性伸缩:平台应该支持应用自动扩缩容,以便应对变化的负载和流量。
  2. 容器编排:平台应该支持容器编排,以方便管理应用的生命周期和资源分配。
  3. 无服务器计算:平台应该支持无服务器计算模式,以提高开发者的效率和降低成本。
  4. 自动化运维:平台应该支持自动化运维,包括自动部署、自动扩容、自动恢复等功能。
  5. 服务发现与负载均衡:平台应该支持服务发现和负载均衡,以确保应用的高可用性和稳定性。
  6. 日志监控和告警:平台应该支持日志监控和告警,以便及时发现和解决应用问题。
  7. 安全管理:平台应该支持安全管理,包括身份认证、访问控制、审计服务等功能,以确保应用的安全性和隐私性。
  8. 自动化CI/CD:平台应该支持自动化CI/CD,以便实现快速迭代和部署。
  9. 多云支持:平台应该支持多云环境,以便应用可以跨多个云平台部署和运行。

如此多的能力要求,为自建云原生 Serverless 平添了不少难度。那么是否可以选择一个开源的方案来完成这个目标呢?

基于 Rainbond 自建

Rainbond 是一款开源的云原生应用管理平台,它可以帮助用户快速构建和管理云原生应用,其很多功能特性都与 Serverless 的无服务器理念不谋而合。Rainbond 提供了一系列的工具和服务,包括应用编排、容器编排、自动化部署、监控告警、应用管理等功能,可以帮助用户实现应用的快速迭代和部署。此外,Rainbond 还支持多语言、多框架、多云环境的部署,用户可以根据自己的需要选择不同的部署方式。

server-1

原生支持多云管理

Rainbond 可以架设在多种不同的云之上,原生支持多云管理。这种多云管理能力可以帮助用户抹平多种不同云计算供应商之间的差异,提供一致的应用部署、应用管理体验。无论是公有云、私有云或混合云,对用户而言都变成透明层,用户的应用可以借助Rainbond提供的能力完成跨云的快速迁移。 server-2

简化应用部署

Rainbond 支持用户部署由不同开发语言开发而来的应用,这个过程不需要用户编写 Dockerfile,不需要了解容器镜像如何打包。被支持的语言类型包括:Java、Python、Golang、PHP、NodeJS、.NetCore以及静态Html语言。用户在操作时仅需要提供代码仓库地址,或者直接上传 Jar、War 包即可将构建任务交给 Rainbond ,后者会自动识别语言类型,并自动配置语言的构建环境与最终运行环境。构建任务完成后,应用会自动运行起来,整个过程不需要用户过多参与。

部署过程中,用户可以自己选择以哪种 Workload 类型来部署应用,Rainbond 除了支持常见的 Deployment、StatefulSet 之外,也支持部署 Job、CronJob 类型的 Workload。

弹性伸缩能力

弹性伸缩能力是 Serverless 场景中最受关注的能力之一,自动化的弹性伸缩能够提升对计算资源的利用率。用户可以借助这种能力,自动化应对业务的峰谷流量。Rainbond 能够根据 CPU/MEM 资源利用情况进行实例数量上的 1-N 自动伸缩,用户仅需要做非常简单的一次设置即可。在更高阶的场景中,Rainbond 能够旁路感知Http业务的平均响应时间、吞吐率等性能指标,并据此实现自动伸缩能力。

微服务能力

Serverless架构与传统的微服务架构类似,都是基于分布式系统的思想,将一个应用拆分成多个小的、相对独立的服务单元来进行开发、部署和管理。而微服务框架可以帮助开发人员更好地设计和开发这些服务单元,提高系统的可维护性、可扩展性和可靠性。Rainbond内置灵活高效的ServiceMesh微服务框架,能够完成跨语言、跨协议、跨架构的微服务编排,并且提供全面的微服务治理、容错机制等能力。

自动化运维

Rainbond提供完善的自动化运维能力,能够极大的解放开发人员。许多应用运维工作都将由平台来接管,包括定时数据备份、健康检测、故障自愈等。

可观测性中心

可扩展的全方位可观测性能力,提供上至应用组件,下至平台的监控视图。全局日志功能与链路追踪能力,能够帮助开发者快速定位问题。实时告警能力,则保证了每一次异常都会得到开发者的关注。

自动CI/CD

Rainbond 能够对接 Git 或 Svn 类型的代码仓库,简化用户创建应用以及配置自动化 Webhook 的流程。开发者仅需要提交一次代码,就可以触动整个CI/CD链条,自动化完成代码更新后的上线。

一键配置网络入口

用户不需要学习复杂的负载均衡配置,仅仅需要一键,就可以开启 L4/L7 的网关策略,将应用的端口对外暴露,平台将会根据要求自动生成 IP:Port 或域名形式的访问地址。

安全管理

平台中采用双因素认证方式保证登录安全,并提供基于 RBAC 的设计方案来确保对应用的权限控制。除此之外,Rainbond 提供全局的操作日志审计功能,保留用户对应用的每一次操作记录。

Rainbond 作为一个开源的云原生应用管理平台,能够帮助企业应对建设私有化的云原生 Serverless 平台的难点。首先,Rainbond 提供了丰富的组件和工具,使得企业可以轻松构建容器集群、微服务架构、CI/CD流水线等,极大地降低了技术门槛。其次,Rainbond 提供了完善的应用管理和监控机制,包括应用部署、服务编排、负载均衡等功能,大大简化了应用开发和运维的工作量,实现了应用管理的自动化和免运维。此外,Rainbond 提供了网关组件,可通过一键即可对外暴露L4/L7层服务,提高了应用的安全性和可访问性。Rainbond 还支持 Job 任务类型或 CrontabJob 定时任务类型,使得企业能够方便地进行定时任务调度。最重要的是,Rainbond 提供了 ServerMesh 微服务框架和内置的应用编排模型,帮助企业轻松实现应用拓扑的编排和管理,实现应用的快速迭代和更新。此外,Rainbond 还能够对接 Git 类型代码仓库,实现自动化 CI/CD 流程,进一步提高了开发效率和运营效果。

写在最后

通过借助 Rainbond 建设私有化的云原生 Serverless 平台,企业能够更好地应对技术难点,提高平台的稳定性和可持续性。同时,Rainbond 还提供了完善的文档和社区支持,帮助企业更好地了解和掌握相关的技术和应用。因此,借助 Rainbond 建设私有化的云原生 Serverless 平台不仅能够解决技术难点,也能够提高企业的开发效率、降低运维成本,是建设私有化 Serverless 平台的理想选择。

· 6 min read

背景

Rainbond 本身具有基于源码构建组件的能力,可以将多种编程语言的代码编译成 Docker 镜像,但是在持续集成的过程中,往往会需要对提交的代码进行静态检查、构建打包以及单元测试。之前由于 Rainbond 并没有 Pipeline 这种可编排的机制,所以用户往往只能通过集成外部的 CI ,如 Jenkins、Gitlab CI 等。这给开发者的使用增加了门槛。

所以为了更有效的帮助开发人员做代码测试,编译缓存,甚至代码质量分析等,结合 Rainbond 的插件体系,拓维信息基于 GitLab CI 能力实现了更加灵活,更加多样化的源码构建的功能。

流水线插件

功能

基于 Rainbond 的插件体系,拓维信息贡献的流水线插件主要功能包括以下五部分:

  1. 流水线管理: 开发者使用流水线模块自定义应用服务所需要的流水线,以及流水线的各个阶段

  1. 应用服务: 应用服务就是 Gitlab 上某一个项目的代码仓库,应用于开发, 管理代码仓库。通常对应Rainbond 中的组件,如果一个仓库下包含多个微服务,则可能对应多个 Rainbond 组件

  1. 代码管理: 管理代码仓库中各分支与 CI 的持续集成流程,可以查看到对应代码仓库分支的最近提交和持续集成的历史信息。

  1. 镜像仓库: 持续集成生成的 image 制品和版本均会在此展示,可以在这里将生成的镜像手动部署到指定环境。

  1. 部署历史: 镜像仓库版本部署到 Rainbond 应用下的历史记录,可以从部署详情中跳转到对应组件进行管理。

安装

流水线插件已经发布到应用市场,可通过开源应用商店一键安装。目前该插件使用需要满足以下前提条件:

  • Rainbond v5.12.0 版本
  • 有可用的 Gitlab 和 Gitlab Runner

Gitlab 和 Gitlab runner 也可通过开源应用商店一键安装。安装流程如下:

  1. 平台管理-应用市场-开源应用商店 中搜索 GitlabGitlab runner 一键安装并进行配置;
  2. 平台管理-应用市场-开源应用商店 中搜索 Pipeline 一键安装;

具体配置和使用参考:Pipeline 使用文档

使用

在插件全部运行起来以后,回到团队视图进行刷新,可以看到左侧边栏有 Rainbond 流水线 选项,点击即可进入。流水线插件主要使用流程如下图所示,主要分为四步:创建流水线模版->创建应用服务->构建->部署到平台

创建流水线模版

用户可以在模版中定义流水线的各个阶段,默认提供了NodeJS、Java、Go、Python的流水线模版,可以在内部自定义流水线的各个阶段。

创建应用服务

在有了流水线模版之后,我们需要去创建一个应用服务。应用服务实际上是将代码仓库和流水线模版关联起来,最终实现该代码仓库的代码通过该流水线模版进行构建。

构建代码

代码管理->分支管理中手动触发流水线构建,构建过程可以在代码管理->持续集成中查看。构建完成后,镜像会推送到流水线模版中定义的镜像仓库地址。可以在镜像仓库查看镜像制品。

部署业务

完成第一次构建后,可以在镜像仓库查看到镜像信息,此时选择部署,可以选择该团队下的应用,组件的名称将以应用服务的名称进行定义。部署完成后,可以在部署历史中查看到该次部署详情,点击查看详情即可跳转到对应组件进行管理,后续提交代码即可实现自动构建和部署。

· 5 min read

Loki 是一个由Grafana Labs 开发的开源日志聚合系统,旨在为云原生架构提供高效的日志处理解决方案。

Loki 通过使用类似 Prometheus 的标签索引机制来存储和查询日志数据,这使得它能够快速地进行分布式查询和聚合,而不需要将所有数据都从存储中加载到内存中。Loki还使用了压缩和切割日志数据的方法来减少存储空间的占用,从而更好地适应云原生环境下的高速增长的日志数据量。

Loki的架构由以下几个主要组件组成:

Promtail: 负责采集应用程序和系统的日志数据,并将其发送到 Loki 的集群中。

Loki: 负责存储日志数据,提供 HTTP API 的日志查询,以及数据过滤和筛选。

Grafana: 负责 UI 展示日志数据。

Loki vs ELK

Loki 和 ELK(Elasticsearch, Logstash, Kibana)都是常用的日志处理系统,它们各自具有一些优点。下面是 Loki 相对于 ELK 的几个优点:

  • 存储效率更高:Loki 使用了压缩和切割日志数据的方法来减少存储空间的占用,相比之下,ELK 需要维护一个大的索引,需要更多的存储空间。

  • 查询速度更快:Loki 使用类似 Prometheus 的标签索引机制存储和查询日志数据,这使得它能够快速地进行分布式查询和聚合,而不需要将所有数据都从存储中加载到内存中。而ELK需要将数据从存储中加载到内存中进行查询,查询速度相对较慢。

  • 部署和管理更容易:Loki 是一个轻量级的日志聚合系统,相比之下,ELK 需要部署和管理多个组件,需要更多的资源和人力成本。

安装和配置 Loki

前提

参阅 Rainbond 快速安装 文档进行安装。

安装 Loki

Loki 应用已发布到开源应用商店,可通过开源应用商店一键安装。

平台管理 -> 应用市场 -> 开源应用商店 中搜索 Loki 并安装。

安装完成后,该应用内包含 Loki Grafana 组件:

同时还有 k8s资源,其中包括 promtailDaemonset 以及 SA 等资源。

配置 Loki

进入应用内 -> k8s资源,修改 ConfigMap promtail-configurl 部分,URL 通过 Loki 的 组件内 -> 端口 -> 访问地址 获取,如下:

apiVersion: v1
data:
promtail.yaml: |
clients:
- url: http://gre4f2a2:3100/loki/api/v1/push # Changed
......

进入应用内 -> k8s资源,修改 ClusterRoleBinding promtail-clusterrolebindingnamespace 部分为当前应用的命名空间。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: promtail-clusterrolebinding
......
subjects:
- kind: ServiceAccount
name: promtail-serviceaccount
namespace: dev # Changed

如果使用的容器运行时是 Containerd 需要修改 promtail-daemonset 资源,如果容器运行时是 Docker 则不用修改。

......
volumeMounts:
- mountPath: /var/lib/containers # Changed
name: varlibdockercontainers
readOnly: true
......
volumes:
- hostPath:
path: /var/lib/containers # Changed
type: ""
name: varlibdockercontainers

修改后更新 Loki Grafana 组件,应用内 -> 更新即可。

使用 Loki

访问 Grafana,应用内点击访问按钮即可通过 Rainbond 默认提供的域名访问 Grafana

进入 Explore 内通过 Labels 筛选 POD 日志,选择 namespace pod Labels,会自动生成查询表达式,点击 Show logs 即可查看日志。

查询表达式

除了通过 Grafana 界面选择 Labels 之外,还可以手动写查询表达式,比如:

{container="rbd-api",namespace="rbd-system",pod="rbd-api-5fdd795546-j5679"}

目前支持以下标签匹配运算符:

  • = 等于
  • != 不等于
  • =~ 正则匹配
  • !~ 正则不匹配

例如:

{namespace=~"dev|rbd-system"}

最后

总之,Loki是一个轻量级、高效的日志聚合系统,它在处理云原生环境下大规模日志数据方面表现出色。Loki 相比于 ELK具有存储效率更高、查询速度更快、部署和管理更容易。结合 Rainbond 一起使用,使我们的应用和日志管理都非常简单。

· 8 min read

微服务后端开发的最大痛点之一就是调试困难,非常影响我们的开发效率。

如果我们想与其他微服务进行联动调试,则需要在本地环境中启动对应的微服务模块,这可能需要大量的配置和构建时间,同时也会占用我们本地很多资源,可能还会出现”带不动“的情况。

虽然说我们可以在测试服务器上进行调试,但整个流程也是比较漫长,提交代码 -> 触发CI/CD -> 等待构建成功,可能简单的 BUG 我们提交代码打个日志就能解决问题,当遇到复杂的 BUG 时通过这个方式在服务器上调试就非常难受了,太浪费时间了,提交 -> 等待,反反复复,始终没有本地开发工具直接调试的方便。

下面介绍的工具将远程和本地融为一体,让本地开发更加流畅。

Telepresence

Telepresence 是一个开源工具,用于在本地开发环境中模拟 Kubernetes 集群中的微服务,它允许开发人员在本地开发环境中运行和调试微服务,而不必担心环境的复杂性和配置困难。

简单来说 Telepresence 将 Kubernetes 集群中服务的流量代理到本地,Telepresence 主要有四个服务:

Telepresence Daemon: 本地的守护进程,用于集群通信和拦截流量。

Telepresence Traffic Manager: 集群中安装的流量管理器,代理所有相关的入站和出站流量,并跟踪主动拦截。

Telepresence Traffic Agent: 拦截流量的 sidecar 容器,会注入到工作负载的 POD 中。

Ambassador Cloud: SaaS 服务,结合 Telepresence 一起使用,主要是生成预览 URL 和一些增值服务。

全局流量拦截

全局流量拦截是将 Orders 的所有流量都拦截到我们本地开发机上,如下图。

个人流量拦截

个人流量拦截允许选择性地拦截服务的部分流量,而不会干扰其余流量。这使我们可以与团队中的其他人共享一个集群,而不会干扰他们的工作。每个开发人员都可以只针对他们的请求拦截 Orders 服务,同时共享开发环境的其余部分。

个人拦截需要配合 Ambassador Cloud 使用,这是一项收费服务,免费用户可以最多拦截 3 个服务。

结合 Telepresence 开发调试 Rainbond 上的微服务

安装 Telepresence

MacOS:

# Intel
brew install datawire/blackbird/telepresence

# M1
brew install datawire/blackbird/telepresence-arm64

Windows:

# 使用管理员身份打开 Powershell

# 下载压缩包
Invoke-WebRequest https://app.getambassador.io/download/tel2/windows/amd64/latest/telepresence.zip -OutFile telepresence.zip

# 解压缩包
Expand-Archive -Path telepresence.zip -DestinationPath telepresenceInstaller/telepresence
Remove-Item 'telepresence.zip'
cd telepresenceInstaller/telepresence

# 安装
powershell.exe -ExecutionPolicy bypass -c " . '.\install-telepresence.ps1';"

安装 Telepresence 流量管理器到集群中

可以使用 Telepresence 快速安装 Traffic Manager,本地需要有 kubeconfig 文件 ~/.kube/config

$ telepresence helm install
...
Traffic Manager installed successfully

或者在 Kubernetes 集群中使用 Helm 安装 Traffic Manager

本地连接远程服务

本地使用 telepresence connect 连接远程 Kubernetes API Server,本地需要有 kubeconfig 文件 ~/.kube/config

$ telepresence connect
connected to context <your-context>

在 Rainbond 上快速部署 Pig 微服务应用

通过 Rainbond 开源应用商店快速部署 Pig 微服务应用,部署后如下图

后面会以 pig-auth 这个服务为例,演示本地开发调试的流程,这里需要做一些小改动:

  1. 从应用商店安装的应用默认 Workload 是字符串,需要修改 Workload 为易于查看的,这里以 pig-auth 为例,进入组件中编辑组件名称,修改组件英文名称为 auth

  2. 简单来说 telepresence 的工作原理就是代理 k8s service,默认 gateway 到 auth 是使用的 nacos 做的负载均衡,这样的话 telepresence 是无法拦截到流量的,我们需要修改 gateway 配置使用 k8s service 做负载均衡。

    • 打开 pig-register 组件的 8848 对外端口,访问 nacos,修改 pig-gateway-dev.ymlspring.cloud.gateway.routes.uri: http://gr795b69:3000gr795b69:3000 通过 pig-auth 组件内的端口访问地址获取。
  3. 如果本地只启动一个 pig-auth 服务,pig-auth 需要连接 pig-register 和 redis,那么就需要将这俩服务的对外端口打开,并修改配置文件让本地的 pig-auth 服务可以连接远程到 pig-register 和 redis。

在本地调试 auth 服务

使用 IDEA 或 VScode 在本地启动 pig-auth 服务。

在本地使用 telepresence 拦截 pig-auth 流量,命令如下:

$ telepresence intercept <workload> --port <local-port>:<service port name> -n <namespace>

命令拆解:

# <workload>
# 需要拦截流量的服务 workload
$ kubectl get deploy -n zq
NAME READY UP-TO-DATE AVAILABLE AGE
pig-auth 1/1 1 1 146m

# <local-port> 本地端口

# <service port name>
# 需要拦截流量的服务的 service port name
$ kubectl get svc gr795b69 -n zq -o yaml
...
ports:
- name: http-3000
port: 3000
protocol: TCP
targetPort: 3000
...

# <namespace> 命名空间

最终命令:

$ telepresence intercept pig-auth --port 3000:http-3000 -n zq
Using Deployment pig-auth
intercepted
Intercept name : pig-auth-zq
State : ACTIVE
Workload kind : Deployment
Destination : 127.0.0.1:3000
Service Port Identifier: http-3000
Volume Mount Error : sshfs is not installed on your local machine
Intercepting : all TCP requests

我们在本地给退出登陆这块逻辑打上断点,然后通过线上的前端退出登陆,打到我们本地 IDEA上,整体效果如下:

最后

Telepresence 可以帮助我们简化本地开发流程,同时保证代码的正确性和可靠性。还能使我们在集群中轻松调试和测试代码,提高开发效率。结合 Rainbond 的部署简化,从开发到部署都非常的简单,让我们专注于代码编写。

· 9 min read

很多小伙伴在学习 mall 电商项目时,都会在部署上折腾许久,虽然目前已经提供了很多种部署方式,比如 在 Linux 上部署 mall使用 Docker 或 DockerCompose 部署 mall ,但对于正在学习的我们都显得比较复杂,需要理解并学习这些容器技术。而本文将使用 Rainbond 部署 mall 电商项目,通过 Rainbond 部署 mall 商城项目非常方便、简单,让我们专注于代码,Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,轻松的在 Kubernetes 上部署应用并体验 Kubernetes 带来的能力。

本文介绍在 Rainbond 上的两种部署 mall 电商项目的方式:

  1. 通过 Rainbond 开源应用商店快速部署 mall
  2. 从 0 开始部署 mall 项目所有服务

前提

安装可用的 Rainbond 环境,Linux、Mac、Win上均可安装,参阅 Rainbond 快速安装

通过应用商店快速部署 mall

mall 电商项目已发布到 Rainbond 开源应用商店,可以通过开源应用商店一键部署,在 平台管理 -> 应用市场 -> 开源应用商店 中搜索 mall 并安装。

此时 Rainbond 会自动构建、启动 mall 所有服务,只需等待即可,部署完成后拓扑图如下:

访问 mall-admin-web 前端项目验证部署,默认用户密码:admin / macro123

mall-portalmall-search 暂时没有前端,可以访问后端 swagger 验证部署 http://xxx/swagger-ui/,如下:

从零开始部署 mall

中间件部署

mall 需要用到的中间件有:Mysql Redis RabbitMQ MongoDB ElasticSearch,这些中间件都可以通过 Rainbond 开源应用商店部署。

安装 Redis

在开源应用商店中搜索 Redis 并安装 5.x 版本

安装 MongoDB

在开源应用商店中搜索 MongoDB 并安装 4.x 版本

安装 RabbitMQ

在开源应用商店中搜索 RabbitMQ 并安装

安装 MySQL

在开源应用商店中搜索 MySQL 并安装 5.7 版本

  1. 在 Mysql 组件 -> 端口 打开对外端口服务,通过 IP:PORT 连接,默认用户密码 root / root
  2. 通过工具连接并导入 mall sql 数据。

安装 ElasticSearch

在开源应用商店中搜索 ElasticSearch 并安装 7.15.2 版本

  • ElasticSearch 应用包含了 Kinbana,如不需要可删除 Kinbana 组件
  • ElasticSearch 默认开启了密码验证,在 组件 -> 环境配置 -> 配置文件设置 编辑配置文件将 xpack.security.enabled 设置为 false 并更新组件生效。

安装中文分词器 IK Analyzer

  1. 首先在 团队视图 -> 插件 -> 新增插件 -> 通过应用商店安装插件 搜索 ES-IK-Analysis 并安装插件
  2. 为 ElasticSearch 组件添加存储,组件 -> 存储 -> 添加存储
    • 名称:自定义
    • 挂载路径:/usr/share/elasticsearch/plugins
    • 类型:共享存储
  3. 进入 组件 -> 插件 -> 未开通,开通 ES-IK-Analysis 插件
  4. 更新或重启 ElasticSearch 组件即可生效。

部署 mall 后端服务

修改项目代码配置

注释主 pom.xml 文件中的 execution 部分,不需要在项目中配置 Docker 打包项目,打包工作交给 Rainbond 处理,pom.xml 配置如下:

<!-- 
<execution>
<id>build-image</id>
<phase>package</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
-->

修改 mall-admin 服务的 application-dev.yml 文件,内容如下:

spring:
datasource:
url: jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false #MySQL连接地址
username: ${MYSQL_USERNAME} #MySQL用户
password: ${MYSQL_PWD} #MySQL密码
......
redis:
host: ${REDIS_HOST} #Redis连接地址
......

修改 mall-portal 服务的 application-dev.yml 文件,内容如下:

spring:
datasource:
url: jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false #MySQL连接地址
username: ${MYSQL_USERNAME} #MySQL用户
password: ${MYSQL_PWD} #MySQL密码
......
data:
mongodb:
host: ${MONGODB_HOST} #MySQL连接地址为环境变量
port: 27017
database: mall-port
redis:
host: ${REDIS_HOST} #Redis服务器地址
......
rabbitmq:
host: ${AMQP_HOST} #RabbitMQ 连接地址
virtual-host: ${RABBITMQ_DEFAULT_VHOST} #RabbitMQ virtual host
username: ${RABBITMQ_DEFAULT_USER} #RabbitMQ 用户
password: ${RABBITMQ_DEFAULT_PASS} #RabbitMQ 密码
......

修改 mall-search 服务的 application-dev.yml 文件,内容如下:

spring:
datasource:
url: jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=false #MySQL连接地址
username: ${MYSQL_USERNAME} #MySQL用户
password: ${MYSQL_PWD} #MySQL密码
......
elasticsearch:
uris: ${ES_HOST}:${ES_PORT} #ElasticSearch连接地址
......

为什么都要改成环境变量的方式呢,因为这样更灵活,只需修改简单的变量配置可以让 mall 项目在任何环境中运行。而在 Rainbond 中,组件之间建立了依赖关系之后,会自动注入被依赖组件的环境变量,这样我们连环境变量都不用配置,更加方便,原理可参阅 Rainbond 组件之间的环境变量注入

部署后端组件

在团队视图或应用视图 新增从源码创建组件:

  • 组件名称:自定义
  • 组件英文名称:自定义
  • 仓库地址:https://github.com/zzzhangqi/mall.git
  • 代码版本:master

以上仓库已经修改了上述的代码配置

此时 Rainbond 会检测到项目为多模块项目,进入多模块项目构建:勾选 mall-admin、mall-portal、mall-search 并构建。

进入每个组件内 -> 端口,删除默认的 5000 端口,添加新的组件对应端口:

  • mall-admin:8080
  • mall-portal:8085
  • mall-search:8081

建立组件间的依赖关系

在应用内,切换到编辑模式,按照以下依赖关系并建立连接:

给组件之间添加依赖

部署 mall 前端服务

很多时候我们的后端服务一般是不对外提供访问的,如果采用现在的配置那么在部署的时候,config/prod.env.js 中后端的地址就必须与前端的访问地址一样,如果不一样则会产生跨域,如下:

module.exports = {
NODE_ENV: '"production"',
BASE_API: '"https://admin-api.xxx.com"'
}

如何不暴露后端服务的同时又能解决跨域,可以使用 Nginx 反向代理后端服务。

config/prod.env.js 定义一个不存在的接口,比如 /api

module.exports = {
NODE_ENV: '"production"',
BASE_API: '"/api"'
}

比如现在前端访问登陆接口的 URL 是 /api/admin/login ,显然 /api 不是我们的接口,/admin/login 才是,那么通过 Nginx URL 重写,把 /api 重写,访问到后端的接口就是 /admin/login 此时接口正确就可以正常返回数据,也能解决跨域问题同时后端服务也不用对外暴露。

server {
listen 80;

location / {
root /app/www;
index index.html index.htm;
}

location /api {
rewrite ^/api/(.*)$ /$1 break;
proxy_pass http://127.0.0.1:8080;
}
}

部署前端组件

在团队视图或应用视图 新增从源码创建组件:

  • 组件名称:自定义
  • 组件英文名称:自定义
  • 仓库地址:https://github.com/zzzhangqi/mall-admin-web.git
  • 代码版本:master

以上仓库已经添加了上述配置

添加 mall-admin-web 依赖于 mall-admin

验证部署

访问 mall-admin-web 前端项目验证部署,默认用户密码:admin / macro123。mall-portalmall-search 暂时没有前端,可以访问后端 swagger 验证部署 http://xxx/swagger-ui/

最后

下一期出在 Rainbond 上部署 mall-swarm 微服务项目实践。

· 6 min read

关于 ACNS

龙蜥云原生套件 OpenAnolis Cloud Native Suite(ACNS)是由龙蜥社区云原生 SIG 推出的基于 Kubernetes 发行版本为基础而集成的套件能力,可以提供一键式部署,开箱即用,以及丰富的云原生基础能力,主要包括:

  • Kubernetes 基于 ACK-D , 作为开源的发行版以及 ACK 的下游,ACK-D 经过大规模的生产的验证,保证了组件的稳定性、可靠性;同时在网络插件上支持 Calico、Hybirdnet,可同时支持网络的 Overlay 与 Underlay,除了 Overlay 满足容器网络的同时,可以部署成 Underlay 模式是使得 POD IP 直接被外部访问,同时提供比较好的性能;存储插件上支持本地存储 Open-Local、利用 LVM 提供了灵活的本地磁盘能力,以及共享存储 Minio。
  • Runtime 同时支持 runC、runD 和 Kata,以及 runE (未来版本),满足各种对共享、隔离以及安全场景下使用。
  • 镜像管理上提供了开箱即用的 Nydus + Dragonfly,使用 Nydus 可以在集群内部使镜像按需加载,可以大大提高集群的动态弹性的能力;Dragonfly 则是提供镜像在集群的 P2P 的能力,这两个能力主要面向 Kubernetes 集群提供 Serverless服务,以及动态弹性的场景,AI大数据镜像数据集群内分发的场景等。

关于 Rainbond

Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。

ACNS 与 Rainbond 结合

龙蜥云原生套件 ACNS提供一键部署集群的能力,Rainbond 提供一键部署应用的能力,Rainbond 与龙蜥云原生套件 ACNS 结合提供一站式的云原生体验:

  • 基础设施:Anolis OS 是 OpenAnolis 社区推出的完全开源、中立、开放的发行版,它支持多计算架构,也面向云端场景优化,兼容 CentOS 软件生态。
  • 容器层:龙蜥 ACNS 提供了经过大规模生产验证的 ACK-D 集群,同时也提供了 Kata 安全运行时、Dragonfly 文件分发、Nydus 镜像加速。
  • 应用层:Rainbond 提供了应用开发、应用市场、微服务架构、应用交付、应用运维等开箱即用的能力。

部署 ACNS 与 Rainbond

服务器信息:

操作系统IP
Anolis OS 8.6 ANCK172.31.98.243
Anolis OS 8.6 ANCK172.31.98.242

部署龙蜥 ACNS

在任意节点上下载 sealer 可执行文件

wget -c https://cloud-native.oss-cn-shanghai.aliyuncs.com/bin/amd64/sealer-latest-linux-amd64.tar.gz && tar -xvf sealer-latest-linux-amd64.tar.gz -C /usr/bin

使用 sealer 下载集群镜像

sealer pull cloud-native-registry.cn-shanghai.cr.aliyuncs.com/kubernetes/anoliscluster:v1.0

定义 Clusterfile 文件,Clusterfile 用于定义集群相关信息,例如:节点IP、参数等,通过 Clusterfile 一键式部署集群。

$ vim Clusterfile

apiVersion: sealer.cloud/v2
kind: Cluster
metadata:
name: my-cluster # 自定义集群名称
spec:
image: cloud-native-registry.cn-shanghai.cr.aliyuncs.com/kubernetes/anoliscluster:v1.0
env:
- ContainerRuntime=containerd # 使用 containerd 运行时
- SkipPreflight=true
- SupportKata=true # 使用 Kata 容器
- SupportNydus=true # 使用 Nydus
- SupportDragonfly=true # 使用 Dragonfly
- YodaDevice=/dev/vdb # Node 节点未使用的磁盘,用于 Dragonfly 存储数据
ssh:
passwd: xxxx # 节点 root ssh 密码
hosts:
- ips: [ 172.31.98.243 ] # master IPS
roles: [ master ]
- ips: [ 172.31.98.242 ] # node IPS
roles: [ node ]

开始部署 ACNS

sealer apply -f Clusterfile

配置 Dragonfly

等待部署完成后,在 Node 节点上配置 Containerd 使用 Dragonfly,在 Containerd 中配置镜像的 Mirror,如下:

$ vim /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["http://127.0.0.1:65001","https://registry-1.docker.io"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."sea.hub:5000"]
endpoint = ["http://127.0.0.1:65001","https://sea.hub:5000"]
[plugins."io.containerd.grpc.v1.cri".registry.configs."sea.hub:5000".tls]
insecure_skip_verify = true

配置完成后重启 Containerd 生效。

systemctl restart containerd

在 ACNS 上部署 Rainbond

修改集群的 Coredns 配置,让 sea.hub 私有镜像仓库可在集群中使用

$ kubectl edit cm coredns -n kube-system

apiVersion: v1
data:
Corefile: |
.:53 {
hosts {
172.31.98.243 sea.hub
fallthrough
}
}

# 重启 Coredns POD
$ kubectl delete pod -l k8s-app=kube-dns -n kube-system

使用 Helm 部署 Rainbond

创建 rbd-system 命名空间

kubectl create namespace rbd-system

添加 Rainbond Helm 仓库

helm repo add rainbond https://openchart.goodrain.com/goodrain/rainbond

执行 Helm 命令安装 Rainbond 并指定镜像仓库信息,复用 sealer 的 registry

helm install rainbond rainbond/rainbond-cluster -n rbd-system \
--set Cluster.imageHub.enable=true \
--set Cluster.imageHub.domain=sea.hub:5000 \
--set Cluster.imageHub.namespace=rainbond \
--set Cluster.imageHub.username=sealer \
--set Cluster.imageHub.password=sealer

当名称包含 rbd-app-ui 的 POD 为 Running 状态时即安装成功。POD rbd-app-ui-xxxx-xx 为 Running 状态时,表示 Rainbond 安装成功。

复制如下命令,在集群中执行,可以获取到平台访问地址。如果有多个网关节点,则任意一个地址均可访问到控制台。

kubectl get rainbondcluster rainbondcluster -n rbd-system -o go-template --template='{{range.spec.gatewayIngressIPs}}{{.}}:7070{{printf "\n"}}{{end}}'

最后

在未来,Rainbond 会与龙蜥云原生 ACNS 更加紧密的合作,提供给用户最佳的一站式云原生体验。

· 25 min read

软件产品只有交付到用户手中才有价值,本人在面向政府等 ToG 场景的软件交付领域具有数年的工作经验,深知其中痛点。今天借助这篇文章,分享这些痛点以及我的解决之道。

提出问题

本人供职的公司,其主要客户群体是省内的政府部门,所开发的业务系统是服务于政府内网之中的移动APP。作为交付负责人,我一直苦恼于如何将一套基于 Spring Cloud 框架开发而来的服务端业务系统交付给我的客户。完成软件系统的交付只是万里长征第一步,如何处理后期的运维工作也是必须面对的问题。政府场景的特殊性,为我的工作平添了许多不利因素,这些 ToG 场景交付的痛点,且听我娓娓道来。

离线环境交付

与公网环境隔离,与公司网络隔离,完全的离线场景是政府交付工作中的标配特征,也是 ToG 交付最大的痛点。相信离线环境交付是所有的交付工程师都不想面对的场景,这意味着所有的交付物必须在事先准备好,交付过程中一旦出现任何遗漏和错误,都意味着明天必须再来现场一次。

交付环境不统一

如果你从事过面向政府的交付工作,那多半会遭遇过交付环境不统一的情况。由于各级政府部门的 IT 建设脚步不一样,同样一套业务系统,在交付到市级部门时,得到的硬件设施可能是一台物理服务器,而到了省级部门时,则可能得到了私有云提供的数台虚拟机。值得庆幸,物理机与虚拟机的差异并不大。然而近年来政府的 IT 建设一直在向国产自主可控的方向前进,当省级部门要求使用鲲鹏Arm架构CPU,亦或是使用国产麒麟操作系统进行交付时,和市级部门交付环境的差异就已经非常大了。我甚至不得不将同一套业务系统在两级部门的交付当作完全不同的两个项目来对待。这体现出不同交付环境之间的差异,而当我转身看向公司开发环境时,开发环境与交付环境的差异,已经开始让我听到自己头发落到地面的声音了。我很难确定事先准备好的交付资源,在甲方环境部署时会否遭遇操作系统以及硬件设施差异所导致的依赖性冲突问题。这种问题在离线环境下又被放大,我甚至不具备连接公网安装软件包来调试解决依赖性冲突问题的能力。

缺乏自动化运维能力

将软件交付到客户环境中,只是最初级的目标,在合同期内维护软件系统稳定运行是对交付质量更高层次的考验。依照个人经验,在一个软件交付项目中,交付部署的工作量,不及后期运维工作量的一半。我们是不希望所有的软件问题都需要工程师亲自抵达现场解决的,一来无法保障 SLA 服务协议中的时间承诺,其次也会消磨工程师的工作热情。在离线环境下如何构建起一套具备自动化运维能力的软件运行环境,变得尤为重要。依靠自动化运维能力,让一些软件故障得以自愈,在一定程度上降低了政府交付场景中的运维难度。但选择任何一种技术实现自动化运维的目标都是需要付出代价的,这意味着我需要在软件系统交付之前,先行在交付环境中组装一套稳定可靠的自动化运维平台。

过度依赖核心人员

在离线化的政府交付场景中,常常面临如下问题:一是交付环境难以统一时,其中特殊之处只被少数全程参与项目交付的工程师所了解,而实际经验告诉我们,这些特殊之处往往是一些异常情况的根源;二是离线的工作环境使得工程师通过查询资料来解决问题变成一种奢望,反向提高了对于工程师的经验和技能的技术要求,因此,“合格”的驻场运维工程师很难招到。以上问题造成了一些运维工作过分地依赖某些核心技术人员的局面,一旦核心技术人员离职或者调岗,对当前的业务连续性将会造成较大影响。所有的这些对人的依赖,都在某个靠谱的驻场工程师希望另谋高就,向我提出辞职申请时痛击我的脑神经。

持续交付困难

软件交付并非一次性工作。从项目管理的角度来说,用户很难在一开始就提出具体且可落实的需求,具体的项目范围会随着项目的推进逐渐确定,这是一个渐进明细的过程。而在软件产品交付的过程中,这种渐进明细体现在交付的产品会经过多次迭代,每次升级后的产品,都距离用户的最终需求更近一步。而这个持续交付的过程,在离线环境中,所遭遇的难处并不亚于首次交付,甚至会在某些需要回滚的场景中更加复杂。在微服务时代,一套完整的业务系统往往包含了几十个独立的组件,组件数量也为持续交付添加了复杂性。

驻场开发难

驻场开发是一种在政府交付场景中常见的需求。标准的软件产品往往是不能直接满足甲方需求的,这就需要我们的开发人员可以在甲方办公室直接定制开发指定的几个组件,并快速更新到线上环境中去,供甲方验证。在实际场景中,多数微服务功能是固定的,只有一两个 jar 包需要频繁更替。

以往的经历

我经历了公司软件产品交付的完整变革流程。从最开始的 jar 包交付,继而引入容器化技术交付镜像,到后来采用 Kubernetes 容器编排技术,我们始终围绕着复杂的离线环境进行软件产品的交付工作。每个阶段或多或少的解决了上述各种痛点,所付出的代价也不尽相同。最终我们拥抱了云原生技术,将业务系统整体作为新的对象实践了较为简单可靠的离线环境交付,同时兼顾了以往各种痛点。

Jar 包交付

得益于 Java 开发语言,我们可以将代码打包成为仅依赖 JDK 运行环境的二进制交付产物——Jar 包。彼时我们的软件产品还处于初级阶段,业务系统由10个 Jar 包、Mysql数据库、Redis 缓存、前端Nginx组成。

一次交付工作中,首先要搭建起基础运行环境,完成 JDK 的安装。Mysql、Redis 等中间件依靠很原始的 rpm 包进行安装,这个过程经常会遭遇包依赖冲突问题。最后将所有的 Jar 包运行起来,启动之前免不得进行一系列的人工配置工作。

这种交付方式比较原始,我们会写一些脚本来达成一定程度上的自动化,然而这只在一定程度上提升部署效率,自动化运维能力基本为零。中间件的安装部署对操作系统的绑定程度很高,一旦服务器的操作系统和我们预先了解的稍有偏差,都可能导致依赖冲突,导致安装失败。而配置过程对人工依赖过重,这在高可用部署的环境中表现的尤为突出,配置各种 IP 很容易出错。

做一个总结,这个阶段我们实现了简单业务系统的离线交付,然而没有解决其他任何一个 ToG 场景交付痛点。

引入容器化技术

为了抹平交付环境不统一所带来的复杂度,我们开始引入容器化技术,通过将所有组件容器化,我们只需要确保客户的服务器能够运行 Docker 容器,就不需要再担心底层操作系统的问题了。官方提供静态编译版本的 docker 二进制文件,我们再也不用和软件依赖打交道了。这个阶段,我们的业务系统也开始扩展,组件的数量上涨到了几十个,这导致我们不得不同时引入 docker-compose 以及 docker-swarm 技术来解决单机或高可用场景下的组件编排问题。这些技术同时提供了较低程度的故障自愈能力,距离真正的生产可用还有距离。

容器化技术解决了交付环境不统一的问题,但是其他方面的痛点提升有限。随着业务功能的扩展,一个新的痛点逐渐展现出来,我们需要携带数十个容器镜像进行交付,交付复杂度被交付物数量裹挟着不断上升。

转向 Kubernetes 技术

在交付团队掌握了容器化技术之后,为了解决自动化运维问题,我们开始向 Kubernetes 转型。Kubernetes 技术是可以为业务系统的交付和运维赋能的,借助于它,我们的业务系统实现了较高程度的自动化运维能力。

Kubernetes 技术在故障自愈、弹性伸缩等方面的能力提升使我们非常受用,业务系统真正做到了生产可用。但是同时也带来了新的痛点,那就是它本身过于复杂,无论是开发人员还是现场运维交付人员,都必须对它有足够的了解才可以驾驭。换句话说,这种技术的引入大幅度提高了对核心技术人员的依赖程度,甚至提高了对技术团队全员的入门门槛。离线化的交付场景下,对交付环境的前期一次性建设的成本大幅度提高,我们必须事先在离线环境中准备好可靠的 Kubernetes 集群,光这一项工作,就大幅度阻碍了 Kubernetes 技术在交付团队中的推广。

新的痛点

经过了前面的几个阶段,我认为面对离线化的复杂交付场景,继续在容器技术以及 Kubernetes 容器编排技术方向上前进是没有问题的,每一次技术选型,都在一定程度上解决了很多痛点,我们在交付的过程中已经不惧怕离线环境、交付环境不统一、缺乏自动化运维能力等痛点,但也引入了一些新的问题,是待解决的。

  • 业务功能扩展会同步提升交付复杂度。这一新痛点从本质上来说,是由于我们将每一个组件独立看待,而非将整个业务系统作为整体看待。这样做的结果就是交付物的数量和交付复杂程度直接挂钩,如果能将业务系统作为整体交付,而非每个组件单独交付,那将极大的降低交付复杂度。
  • 每一次新的选型,都引入了新的复杂度,这一点在转向 Kubernetes 技术时尤为突出。这项技术对业务系统的赋能能力是毋庸置疑的,但无论是一个新环境的首次部署,还是后期的运维难度,对交付团队成员技术能力的要求是直线上升的。为了降低交付团队新成员的入门难度,我们开始选型一些能够降低 Kubernetes 使用难度的图形化工具,易用性是选型的首要影响因素。
  • 持续交付困难以及驻场开发难这两大痛点,依然没有被很好的解决。这二者都需要我们提供机制,解决业务系统在交付环境中持续变更的问题,前者注重业务系统整体框架的迭代升级,后者注重某个组件的个性化快速迭代。

我们开始将目光放在了逐渐火热起来的云原生技术领域。首先,云原生技术是基于容器化技术和 Kubernetes 技术的,我们已经具备了一定的技术基础。其次,云原生技术也注重软件交付领域的各种最佳实践,其中一些实践非常契合前文中的痛点。经过一段时间的内部测试选型,我们最终使用了 Rainbond 云原生应用管理平台作为交付工具,实现了全新的复杂场景离线交付模式。

云原生离线交付实践

最开始,交付团队内部的一名成员从开源渠道偶然了解到了 Rainbond 这款产品,并推荐给开发团队人员使用。当时仅仅作为图形化的 Kubernetes 管理工具来使用,以此降低新手开发人员学习 Kubernetes 的门槛。但随着对产品的了解,我们逐渐发觉,Rainbond 真正的用途在于能够解决软件产品的交付问题。

将业务系统抽象为应用

以往的交付过程中,我们总是将业务系统中的每一个组件单独看待,但是在 Rainbond 体系中,管理的单元可以放大到业务系统级别,这种管理单元被称之为应用。应用内部的组件部署和编排都是基于图形化操作的,使用起来不难理解。组件间的调用关系基于拓扑图展现,一目了然。最重要的是,基于应用这种抽象,我们实现了将组件数量和交付复杂度脱钩,无论应用中有多少组件,我们始终视之为一个应用。这么做的好处在交付过程中体现的非常明显。

应用模板的离线导出导入

应用一旦部署编排完成,就可以发布成一个应用模板并导出,导出的产物是单独管理的一个包。离线的模板包在导入时完全不依赖于外部网络,导入完成就可以在离线环境中一键安装,复原为发布时的样子。组件之间的相互依赖关系、配置信息都得以保存,不需要在交付现场重新配置。这一能力完全改变了交付的逻辑,从单独交付数十个容器镜像,变成了交付一个涵盖整个业务系统的包,其中难度的下降可想而知。

简单易用

Rainbond 底层基于 Kubernetes 技术实现容器的调度,提供全面的自动化运维能力。并且将常见的配置从 Yaml 声明式配置转化成为图形化界面操作,极大的降低了入门门槛。引入 Rainbond 体系之后,新入职的工程师可以在简单的培训后,一日之内掌握 Rainbond 的使用方式并可以独立交付业务系统。

原生多云管理

Rainbond 原生支持面向 Kubernetes 的多云管理能力。政府交付场景虽说与公网隔离,然而其实同个系统内往往具有想通的内部网络。借助 Rainbond 的多云管理能力,我们将省内多个城市政府部门的交付场景统一管理了起来,在省会建立了统一的管理控制台。这样的部署模式为业务系统快速在多个数据中心的交付提供了机制,极大的降低了业务系统在全省范围内交付的成本。

持续交付机制

Rainbond 应用模板支持版本管理,当业务系统有较大改动时,只需要将应用整体重新发布一次,重新导入到交付环境中去后即可一键升级或回滚,极大提升了业务系统升级效率。在以往处理数十个容器镜像的升降级和配置工作,需要的时间成本是按天计算的,引入Rainbond 应用模板的版本控制机制之后,升降级的时间成本降低为分钟级,操作成本则可以忽略不计。

驻场开发快

当甲方要求某个组件做出些许改动时,使用整个应用级别的模板离线导入显然得不偿失。此时,只需要现场开发人员在个人开发笔记本上打包出 Jar 包,通过上传 Jar 包构建组件的能力快速构建指定的组件,简单的拼装后即可替换对应的组件。这个过程中开发人员只需要提供 Jar 包,甚至不需要学习容器化技术了解镜像打包的机制,Rainbond 会自动处理后续的工作。

总结

我司交付团队借助云原生技术, 极大的降低了面向政府的复杂离线场景交付工作成本。这种成本节约体现在交付时间缩短、人员技术要求降低、人员操作成本降低、交付物数量减少、配置工作量减少等多个方面。降低成本的同时,也成功为业务系统赋能,能够自动处理很多异常场景,实现了自动化运维。方便驻场开发,能够快速的响应甲方客户的需求,提升客户满意度。

然而 IT 工程领域的发展过程就是在不断面向新的痛点解决问题。目前使用云原生技术也并非能够解决所有的问题,在政府交付场景中,也曾经遭遇这一类场景,甲方提出了比较严苛的要求,禁止使用容器技术进行交付。这种要求从根源上阻绝了云原生交付技术的落地,然而如何优雅的回退到 Jar 包交付的路线中去就成了一个问题,期待社区提供支持,将应用模板转化成为裸机环境可用的交付物,这是后话。

· 4 min read

在现有的监控告警体系中 Prometheus + AlertManger + Grafana 一直是主流,但对于中小团队或个人来说,这种体系显的较为复杂。而 HertzBeat 能让中小团队或个人很快速的搭建监控告警系统,并通过简单的配置实现应用、数据库、操作系统的监控与告警等。

HertzBeat

HertzBeat赫兹跳动 是一个拥有强大自定义监控能力,无需Agent的实时监控系统。网站监测,PING连通性,端口可用性,数据库,操作系统,中间件,API监控,阈值告警,告警通知(邮件微信钉钉飞书)。

Rainbond

Rainbond 是一个云原生应用管理平台,使用简单,遵循 以应用为中心 的设计理念,统一封装容器、Kubernetes和底层基础设施相关技术,让使用者专注于业务本身, 避免在业务以外技术上花费大量学习和管理精力。

快速部署 HertzBeat

HertzBeat 已发布到 Rainbond 开源应用商店,你可以在开源应用商店中搜索 HertzBeat 一键安装。

安装后,可以通过 Rainbond 默认提供的域名访问 HertzBeat,默认用户密码 admin/hertzbeat

HertzBeat 快速使用

仪表盘

应用服务监控

应用服务监控支持多种方式,如:

应用服务监控说明
PING连通性检测域名或 IP 的连通性
HTTP API调用HTTP API接口,查看接口是否可用,对其响应时间等指标进行监测,可自定义请求头
JVM 虚拟机监控 JVM虚拟机的通用性能指标
SpringBoot2.0监控 SpringBoot2.0 actuator 暴露的通用性能指标
全站监控监控网站的全部页面
端口可用性监控服务暴露的端口
SSL 证书监控网站 SSL 证书过期时间以及响应时间

数据库监控

支持监控多种类型数据库,如:MySQL、Redis、PostgreSQL、SqlServer、ElasticSearch、Oracle、MariaDB、OpenGauss、达梦数据库。

操作系统监控

支持对主流的 Linux 和 Windows 系统进行监控,例如:Centos、Ubuntu、Windows等。

告警配置

支持自定义告警阀值,告警通知支持 邮箱、WebHook、企业微信机器人、钉钉机器人、飞书机器人。

最后

HertzBeat 还支持中间件的监控、对容器的监控以及自定义 Prometheus 监控等,小伙伴们可以自行探索。 通过 HertzBeat 让我们用简单的配置即可监控、告警我们的业务,让我们在监控告警这块节省更多时间、成本。

· 6 min read

在开发之前,你需要在本地安装各种开发工具和服务,比如:Mysql、Redis、Nacos 等等,我们都知道在个人电脑上安装这些服务相当的繁琐,可能会遇到很多问题,环境问题、依赖问题等等。

在需要团队协作业务联调的时候,由于同事们的操作系统不统一,有 Mac、Win、Linux,可能还会遇到操作系统依赖、字符集等问题。

在上线之前,你在本地开发调试都完全没问题,部署到服务器就不能用了。经典再现:我本地好好的,咋到你部署就不能用了。

使用 Rainbond 本地开发的好处

部署方便

在对于新的项目或者新的团队时,都需要搭建新的开发环境,这个过程需要进行几个小时,而且还会遇到奇奇怪怪的问题。在团队协作时,来了新人后,同样还是需要花费几个小时去搭建环境。使用 Rainbond 将基础环境打好包,新项目、新人来了安装即用,让我们尽量避免在搭建环境上浪费时间。

统一环境

对于中小企业来说,没有太多的成本支持搭建公用的开发环境。那么就使用 Rainbond 统一开发环境,不管是 Windows、Mac 都可以安装 Rainbond,同时如果测试、生产环境也使用 Rainbond,可以直接导出应用包在测试、生产环境运行。

在本地部署 Rainbond

无论是 Windows、Mac 都可以很轻松快速的部署 Rainbond,只需要你的环境有 Docker Desktop 即可。

Mac

支持在 Mac x86、M1 上部署

curl -o install.sh https://get.rainbond.com && bash ./install.sh

Windows

docker run --privileged -d  -p 7070:7070 -p 80:80 -p 443:443 -p 6060:6060 -p 8443:8443 ^
--name=rainbond-allinone --restart=on-failure ^
-v rainbond-data:/app/data ^
-v rainbond-opt:/opt/rainbond ^
-e EIP=<你的IP地址> ^
registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond:v5.10.0-dind-allinone

资源占用

在本地搭建这样一个云原生平台,最关心的当然是资源占用。因为本地的配置通常都不是很高,我的配置是 M1Pro 16G,部署 Rainbond 后在 Docker Desktop 中查看资源占用情况如下图,整体占用不大,CPU占用 ≈ 10%、内存占用 1.1GB。

基础环境搭建

你可以通过 Rainbond 开源应用商店快速的安装基础环境所需要的服务,比如:Mysql、Redis、ZK、Kafka、ES、Nacos 等等。都可以一键安装,非常简单便利。

业务部署、统一环境

通过 Rainbond 部署业务,让我们不再关心底层的 Docker 镜像用的是什么,Dockerfile 怎么写等等,由 Rainbond 统一开发环境、测试环境、生产环境,你本地能在 Rainbond 上成功部署,那么在测试、生产中同样也可以。再也不用经典再现了:“本地可以,线上咋不行”。

使用 Rainbond 在本地搭建业务,可以通过多种方式部署,Jar War包部署、源码部署都可以。

开发模块共用

在一个项目内有许多模块是公用的,比如说基础环境 Mysql、Redis,还有些用户模块、权限模块等等,我们在本地的 Rainbond 上搭建好后,将其发布到应用市场,其他同事需要直接安装,然后再开发自己的模块。

应用商店应用发布分为两种方式:

  1. 发布到内部组件库:这种方式需要导出应用包给其他同事再自己环境再导入
  2. 发布到开源应用商店:这种方式是存放到 Rainbond 的开源应用商店,其他同事直接在线拉下来,不过别的开源用户也能安装,对于项目私密的不推荐。

将我们已经部署好的应用发布到内部组件库,应用视图 -> 发布 -> 发布到组件库,进入平台管理 -> 应用市场 -> 导出应用。将下载的包给其他同事在自己的本地环境中安装即可。

最后

通过 Rainbond 在本地开发非常便捷,对于资源也占用不大,同时也能统一开发测试环境,借助 Rainbond 的应用市场功能能实现许多场景,比如上面提到的模块共用,也可以实现本地开发完就交付到演示环境、测试环境、生产环境。

· 3 min read

在应用的发布过程中数据库的结构变更一直是最复杂也是风险最大的环节,而 Bytebase 可以对这一过程进行全生命周期的管理。在 Rainbond 中安装 Bytebase,轻松管理部署在 Rainbond 上的所有数据库。

Bytebase 是什么?

Bytebase 是一个开源的数据库 CI/CD 工具,弥补了 GitLab 所缺乏的数据库变更管理能力。它为 DBA 和开发人员提供了一个基于 Web 的协作平台,以安全高效地管理数据库变更。

Rainbond 是什么?

Rainbond 是一个云原生应用管理平台,使用简单,遵循 以应用为中心 的设计理念,统一封装容器、Kubernetes和底层基础设施相关技术,让使用者专注于业务本身, 避免在业务以外技术上花费大量学习和管理精力。

快速部署 Bytebase

Bytebase 已发布到 Rainbond 开源应用商店,你可以在开源应用商店中搜索 Bytebase 一键安装。

安装后,可以通过 Rainbond 默认提供的域名访问 Bytebase。

Rainbond 使用 --external-url 提供 Bytebase 的外部访问。如需自定义外部URL,可以到Bytebase组件 -> 环境配置,修改 EXTERNAL_URL 环境变量。

Bytebase 快速体验

支持主流开源数据库

Bytebase 支持对接多种数据库,例如 Mysql、PostgreSQL、TiDB、Snowflake、ClickHouse等。

工单驱动的变更管理

Bytebase 支持以工单的形式对变更请求进行管理,提供多环境流水发布、批量发布等能力应对复杂的变更场景,同时实现了与代码仓库集成,允许通过提交 PR/MR 自动生成工单

SQL 自动审核

Bytebase 支持数据变更的自动审核,目前已覆盖业界常见规范,同时可以将审核能力与代码仓库进行集成,在 PR/MR 中自动审核 SQL 脚本。

在线 SQL 编辑器

Bytebase 支持在线的 SQL 编辑器,你可以查看数据、表结构,共享 SQL 脚本等等。

还有许多功能小伙伴们可以自行探索,比如自动备份、GitOps 数据变更自动触发、多租户等等。

· 14 min read

由于数据隐私和网络安全的考虑,大多数toB场景的客户需要私有化应用交付,也就是需要交付到客户的环境里,这样的客户有政府、金融、军工、公安、大型企业、特色行业等,这些私有化场景限制很多,如何提高私有化应用交付的效率是个难题,本文将介绍,私有化应用交付有哪些技术?他们都各自有什么特点?私有化应用交付的发展历程。

ToB应用私有化交付的困难点

环境网络限制,影响交付效率

  • 交付实施过程中不能方便查找资料;
  • 在交付过程中,交付人员需要跟公司的开发进行沟通,网络限制会影响协作工具的使用,有些客户环境甚至不能带手机,会影响解决问题的效率,环境越复杂影响越大;
  • 在离线环境内,安装软件包也没办法直接下载,我们需要将安装文件或配置文件打包成离线包,在客户环境导入。由于业务的复杂性会导致镜像很多且很大,只能有交付人员带移动硬盘到客户现场导入,导致在导入离线包就会花费较多时间。甚至有些环境只能刻录光盘在客户环境导入,光盘本身存不了太大的包,只能分多个光盘刻录;

客户基础设施差异,需要适配过程

  • 在私有化场景,不同客户的安装环境也不一样,有些使用物理服务器,有些使用虚拟机,不同的虚拟机厂商也有差异。操作系统也各有不同,例如常见的操作系统有CentOS/Debian/Ubuntu/Redhat,当前还有很多国产化操作系统。CPU架构也可能不同,有X86、ARM等;
  • 资源准备周期长,需要审批流程;
  • 交付的应用需要很重的适配过程,要么在公司适配,要么在客户现场适配;
  • 由于环境差异很大,应用交付完需要完整测试和验证,需要大量的人力和时间投入;

交付人员的技术门槛高

  • 交付人员需要懂底层硬件和网络;
  • 交付人员需要懂操作系统和系统运维,需要懂服务治理、高可用、安全、性能分析、备份恢复、交付开发等等;
  • 交付人员要能独立排查交付应用的问题,需要很强的技术基础;

定制化交付迭代效率低

  • 在定制化交付场景,客户会参与到开发过程中,客户需要看到效果后反馈问题,再持续迭代,直到客户满意,过程中需要频繁升级产品;
  • 如果开发人员在公司定制开发,升级过程复杂,沟通低效;
  • 如果开发人员在客户现场,没有好的开发工具和环境,开发效率低,人力投入大;

后期维护难度大

  • 应用交付完成后,后期需要保障应用运行的稳定性,离线环境远程没办法运维,报警没办法发出来,运维的难度大;
  • 产品有bug、一些预期内的变更或产品升级都需要出差客户现场,支持的成本比较高;

传统应用交付

传统的应用交付是直接交付二进制的可执行文件或软件包:

  • 二进制的可执行文件: java 的Jar,Linux 的可执行文件,windows的exe等。
  • 软件包: CentOS 使用 RPM 包,Debian 使用 DEB 包,Java Web 使用 WAR 包。

安装他们都需要先安装依赖的环境和基础软件,YUM 和DEB 有自己的管理依赖的软件源,但离线环境用不了,如果客户的操作系统不同,还需要另外想办法解决,运行这类服务为了解决启动和自动重启的问题,还需要通过 systemd 或 supervisor 的方式来管理。如果交付单体架构的应用传统应用交付方式还能胜任,但如果是复杂的微服务架构,传统应用交付方式将难以胜任。

在传统应用交付过程中,管理这些运行环境和操作系统差异是一个痛点,容器的出现解决了这个问题。

当前云原生技术应用交付

云原生应用交付主要使用的容器 和 kubernetes相关技术。

Docker 镜像交付

Docker 将业务和依赖的库一起打包成 Docker 镜像,在这个镜像中包含所有环境和应用,这样就可以达成一处打包、到处使用,我们可以将该镜像在任何支持 Docker 的操作系统上运行。Docker 的特性的确解决了很多开发、交付以及其他许多问题,因此 Docker 容器概念迅速的被普及。

在微服务架构场景,需要多个服务或应用一起交付,服务之间有依赖,还有复杂的配置,Docker-Compose解决了这个问题。

Docker-Compose应用交付

docker-compose 将多个服务或应用使用 YAML 的方式管理,可以利用docker-compose命令安装部署和管理,对于一个微服务架构的应用,利用docker-compose命令就可以在任何操作系统实现一键安装和运行,当然前提是需要安装好Docker 和 docker-compose。

对于单机场景docker-compose可以适用,当应用需要高可用或多节点分布式部署,docker-compose就不能胜任,Kubernetes的出现解决了容器的高可用和分布式调度问题。

Kubernetes YAML应用交付

在 Kubernetes 中部署业务我们需要定义 Deployment Statefulset Service 等资源类型,通过调整副本的方式 Kubernetes 会自动调度到多个节点实现业务高可用,在交付时我们只需要将这些 YAML 资源和 Image 导出,在客户的 Kubernetes 环境中部署并交付给客户。这种交付方式需要客户环境有Kubernetes或在客户环境安装Kubernetes。

当我们将Kubernetes YAML交付很多客户的时候,就需要参数配置、版本管理和简单的安装和升级,Helm在Kubernetes YAML的基础上解决了上述问题。

Helm 应用交付

Helm 是 Kubernetes 资源的包管理器,它可以将一组资源定义成 Helm Chart 模版,提供了基于 Helm Chart 模块的安装和升级,安装时可以配置不同的参数。Helm 同样也是在 Kubernetes 交付中大多数人选择的工具。

Helm最大的问题是需要开发者学习容器和Kubernetes整个技术栈,而且客户环境必须要有Kubernetes,学习和使用的门槛太高。抽象的应用模型是一个解决方案。

面向未来的云原生应用模型交付

应用模型强调以应用为中心的理念,让开发者专注在业务本身,在应用级抽象和包装底层复杂的技术,应用模型跟底层基础设施完全解耦,根据对接和交付的基础设施不同,自动转换和适配,真正实现一次开发,处处自动化部署。

基于OAM的KubeVela应用交付

OAM(Open Application Model) 是一个描述应用的标准规范。有了这个规范,应用描述就可以彻底与基础设施部署和管理应用的细节分开。通过将应用定义与集群的运维能力分离,可以让应用开发者更专注于应用本身,而不是”应用部署在哪“这样的运维细节。KubeVela基于OAM实现了应用跨云、跨环境持续交付。当前KubeVela对离线场景的应用交付支持较弱。

基于RAM的Rainbond应用交付

Rainbond 是一个云原生应用多云管理平台,Rainbond 遵循以应用为中心的核心理念,统一封装容器、Kubernetes 等复杂技术,将 Kubernetes 资源统一抽象成 RAM(Rainbond Application Model)应用模型,使用户能非常简单的使用 Kubernetes,降低用户使用的门槛,使用户专注于应用开发、应用交付和应用运维。

在对于离线交付场景,Rainbond基于RAM可以导出三种离线交付包:

  • Rainbond应用模版包,其中包含了复杂微服务架构交付的所有要素,支持升级和回滚,但要求客户环境安装Kubernetes和Rainbond;
  • 非容器的软件包,非容器包按照传统应用交付方式打包,但易用性更好,包中包含了环境依赖,并采用静态编译,适合大多数操作系统,使用 Systemd 管理;
  • Docker-Compose离线包,支持在标准Docker Compose 环境一键启动和管理;

综合对比

交付门槛微服务支持多节点调度 自动化运维离线迭代效率客户环境支持
传统交付不支持不支持服务器
Docker镜像不支持不支持容器/K8s
Docker Compose支持不支持容器
K8s Yaml支持支持K8s
Helm Chart支持支持K8s
KubeVela支持支持K8s
Rainbond支持支持K8s/容器/服务器
  • 应用交付门槛,传统方式交付门槛最高;Docker、Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela交付的门槛中等,因为需要学习会容器和Kubernetes相关技术;Rainbond使用最简单,不需要学习容器和Kubernetes。
  • 微服务支持,除传统应用交付和Docker镜像,其他方式都支持微服务编排和打包交付。
  • 多节点调度和自动化运维,Kubernetes Yaml、Helm、KubeVela和Rainbond支持Kubernetes的多节点调度。
  • 离线迭代效率,传统方式交付效率最低;Docker镜像有版本,而且一个命令就可以导出一个离线包,所以迭代效率高;Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela需要手工逐个打出镜像离线包,复杂架构效率不高,而且手工容易出错;Rainbond支持自动化导出一个离线包,导入离线环境,可以一键升级和回滚,迭代效率很高。
  • 客户环境支持,不同客户有不同的运行环境,交付的包需要根据客户环境选择,传统应用交付方式适合老的一些基础设施,操作系统版本老,没办法安装运行容器;客户环境没有Kubernetes,也不允许安装Kubernetes,可以选择Docker镜像和Docker-Compose;Kubernetes Yaml、Helm、KubeVela和Rainbond支持有Kubernetes的环境。

· 40 min read

开发人员与运维人员是 IT 领域很重要的两大人群,他们都会参与到各种业务系统的建设过程中去。DevOps 是近年间火爆起来的一种新理念,这种理念被很多人错误的解读为“由开发人员(Dev)学习一大堆新的技能,从而掌握运维人员(Ops)该处理的事情”。然而能力越大,责任越大,当维持生产环境稳定为要位的运维责任落到开发人员的肩头时,多数程序员发出了 扯淡的DevOps,我们开发者根本不想做运维! 的呼喊。那么在云原生时代,到底应该怎样达成 DevOps 的体验呢?我的观点是由平台工程来衔接这两大人群,各自做好各自领域的事情。

令人“厌恶”的DevOps

首先,我非常希望你能先看一看引言中提到的 扯淡的DevOps,我们开发者根本不想做运维! 这篇文章。这篇文章从亚马逊云科技社区参与负责人 Emily Freeman 的一条推特入手,观察了很多留言后,得出了文章标题这种类似咆哮一般的结论。从绝大多数回复这条推特的 IT 从业者的口中,我听到了对于将运维职责强加给开发人员这种 DevOps 体验深恶痛绝。

开发人员对于 “谁构建,谁运行” 这种大义凛然的话表示无感,对于学习运维领域的新技能,亦或是将自己加入轮班支持人员的行列都感觉力不从心;运维人员的本职工作被剥离之后,则对本专业的前景惶惶不安,会害怕运维团队的重新洗牌。

开发与运维,的的确确是两个不同的工种,有着类似“车床工与管道工”的区别。

开发人员运维人员
专业技能开发语言、开发框架、中间件、数据库硬件、操作系统、网络、存储、虚拟化
日常工作理解需求、开发文档写作、开发代码安装部署、监控、日志、问题排查、变更
文化标签自由、创造保守、责任

一些公司认为从表格中把大量的运维人员管辖的工作,一股脑的“左移”给开发人员就是 DevOps。在专业技能和日常工作领域带来的缺口,可以通过开发人员的勤劳学习加以补足,然而在文化标签领域的冲突,将会是导致开发人员厌恶这种 DevOps 体验的根本原因。

DevOps 的真意与平台工程

在我看来,DevOps 的真意是利用软件工程思维,解决复杂且繁重的运维问题。真正适合做 DevOps 工作的人,是具备一定软件工程能力的运维专家,在这里,对运维能力的要求更重要。

DevOps 工程师,可以通过设计或选择一款平台产品,来将复杂的运维工作抽象为产品化的运维特征。从这个角度上讲,开发人员将会是这个平台产品的用户,他们能够在不了解复杂基础设施的情况下,操作并维护应用程序。DevOps 工程师,应该是更懂开发人员需求的运维工程师

在追根溯源,找到了这条推特之后,我了解到了更多 IT 业内人士对 DevOps 的看法,从中找到了很多和我有共鸣的声音。

To me that's a sign we haven't made ops intuitive/easy enough for most devs to be able to handle it.

对我来说,这表明我们还没有让运维变得足够直观/简单,以至于大多数开发人员都无法处理它。

​ —— @Liz Fong-Jones (方禮真)

The "platform" should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform. Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform.

“平台”应该做繁重的运维,缺乏真正的平台时运维团队就是平台(DevOps/are/platform team)。然后,开发人员可以使用平台提供的旋钮和杠杆专注于其应用程序的应用程序级操作。

​ —— @pczarkowski

IT 行业近年来的发展趋势,一直是不断以平台能力的提升,来解决复杂基础设施的使用问题的。最开始,程序开发人员需要面对的是一台物理服务器,在缺乏运维能力的情况下,会由运维人员处理有关服务器的一切,包括操作系统、网络配置等等。而到现在,程序开发人员已经很少需要跟服务器打交道,甚至我见过的很多程序员并不掌握任何有关命令行的知识,就可以面向服务器开发应用系统。这种转变让程序开发人员更加专注于业务代码本身,不必分神去做一些繁重且琐碎的运维事务。带来这种转变的,是处于发展过程中的平台工程,在让基础设施不断变得简单易用。

1

最原始的裸机时代,并没有开发运维之分。从底层基础设施,一直到最顶层的业务系统都是同一批人在处理,这一批老程序员可以被称为真正的全栈工程师。但毫无疑问,每一个开发人员,都希望能够抛却运维工作,更专注于自己开发的代码。

云计算时代的兴起以虚拟化技术为基础,软件定义基础设施变得炙手可热起来。运维人员通过建设并维护一套 IaaS 云平台,将计算资源进行池化。开发人员按需申请自己需要的虚拟机,从而得到一个操作系统界面来进行交互。与操作系统打交道,对开发人员依然是个巨大的挑战,在 IT 领域,操作系统就像一座漂浮在海上的冰山,看似只露出冰山一角,然而其庞大的知识领域“身躯”都隐藏在海平面以下。和裸机时代相比较,开发人员和运维人员已经是两个完全不同的群体,开发人员已经可以将自己的大部分精力放在业务系统上了。值得一提的是,对操作系统的掌控是不折不扣的运维领域技能。

容器技术以及 Kuberentes 的横空出世,成为了云计算时代的分水岭。软件定义基础设施的技术手段已经被发挥到了极致,并且成为了现阶段运维人员的标配技能。运维人员通过建设并维护一套 PaaS 云平台,终于将操作系统这一座最后的“大山”从开发人员的身上搬开。开发人员可以将更多的精力放在业务系统上了,除了他们依然需要学习容器技术和 Kubernetes ,至少他们要学会如何面向 Kubernetes 编写业务系统所需的声明式配置文件。运维人员也通过 PaaS 云平台得到了自己想要的能力,容器技术和 Kubernetes 为他们带来了弹性、便捷性的巨大提升。

跟随时代的变迁,我得出了一个结论:从开发人员与运维人员的关系上来看,IT 领域的演变,就是运维人员通过不断向上接手开发人员眼中“跟开发无关的杂活”,来不断为开发人员减负。开发人员在得到了解放后,可以将视角更多的聚焦在自己开发的业务系统上,释放出自己的创造力。

那么跟随结论中的趋势,解放开发人员负担的脚步绝对不会停止。DevOps 的工作,就是以开发人员为用户群体,打造一套可以让开发人员毫无障碍的使用基础设施的“云原生平台“。

云原生是一种面向云设计应用的思想理念,充分发挥云效能,组织内 IT 人员相互协作构建弹性可靠、松耦合、易管理、可观测的云应用系统,最终目标是提升软件交付效率,降低运维复杂度。相比上文中提到的 PaaS 平台,起码要能够避免开发人员去编写复杂的 Kubernetes 声明式配置文件。

现有开源产品情况

在云原生平台领域,已经有不少项目在深耕。在这里我列举了三个各具特色的云原生领域的平台级产品:RancherKubeSphereRainbond ,后续的具体设计思路中,也会关注已有产品的实现。

这三款开源产品中,Rancher 是元祖级容器管理平台,加入 SUSE 后,能够明显感觉在云原生生态领域不断发力,Rancher 在各个层次可以集成的云原生领域工具集已经非常丰富。Rancher 专注于帮助 DevOps 团队面对多集群情况下的运维和安全挑战,从这一点来说,Rancher 更偏向于运维人员的使用体验,而非面向开发人员提供更高的易用性。

KubeSphere 是来自青云的 “面向云原生应用的 容器混合云”。除了对 Kubernetes 集群内的各种资源的管理能力之外,Kubesphere 主打即插即用的插件式生态扩展能力。

Rainbond 由北京好雨科技出品,从其介绍来看,它是一款主打易用性的云原生多云管理平台。

降低业务部署难度

诚实地讲,为现代开发语言开发而来的业务系统制作容器镜像并不是什么难以掌握的技能。但是不可否认的是,绝大多数 IT 从业人员依然会将制作镜像这件事情归为运维人员管理,而不是开发人员要关心的事情。

那么 DevOps 工程师就有必要考虑,如何在开发人员对容器技术一无所知的情况下,使之可以直接从代码开始部署业务系统。

在这个方面,Heroku 是无可争议的先行者。Heroku 是一个支持多种编程语言的云平台即服务产品。在2010年被 Salesforce.com 收购。 Heroku 作为最元祖的云平台之一,从2007年6月起开发,当时它仅支持 Ruby,但后来增加了对 Java、Node.js、Scala、Clojure、Python 以及 PHP 和 Perl 的支持。

开发人员在使用云原生平台时,只需要在界面中填写代码仓库的地址,对应的用户名密码等基础信息,就可以等待代码构建成为镜像,并自由的运行在 Kubernetes 云环境中去。

现有开源产品也在这方面给予了一定的支持:

RancherKubeSphereRainbond
实现方式通过集成 Epinio 项目,继而深入集成了Paketo Buildpacks 来实现源码构建提供定制化的基础镜像来结合用户代码构建项目基于 Heroku buildpack 定制的源码构建能力
支持语言类型Java、GraalVM、Golang、.NetCore、Nodejs、PHP、Ruby、PythonJava、Nodejs、PythonJava、Golang、.NetCore、Nodejs、PHP、Python、Html静态
使用体验全部命令行操作,使用复杂图形化操作,直接提供代码地址,构建产出镜像,进而部署业务图形化操作,提供代码地址即可完成构建与部署,构建参数可配置,自由度高

更进一步的设计,是将代码的提交、检测、部署等流程都集成到 CI/CD 流水线中去,开发人员只需要进行代码的提交,后续的流程会自动触发完成,生成检测报告,并完成代码的上线部署。而与之相关的第三方工具集,由 DevOps 团队负责进行维护,开发人员可以充分的发扬拿来主义——拿来用就好。

在这方面 KubeSphere 做的更加全面,通过集成 Jenkins 实现了基于图形化的流水线配置,这种方式对于以前就在使用 Jenkins 的团队很友好。并且这种实现继承了 Jenkins 生态原有的高自由度,可以更好的将其他第三方CI工具纳入流程之中。

Rainbond 通过在构建流程中加入自制的自动触发能力,也可以完成部分流水线工作。这种配置相对编写 Jenkinsfile 来说更简单一些,能够满足一些基本场景。然而其扩展性和自由度不足,能够接纳的第三方CI工具不够丰富。

Rancher 并没有在产品中集成 CI 方面的能力,在 CD 方面通过集成 fleet 项目来实现 GitOps ,使用的门槛较高。

2

这样的使用体验还有一个优点,从始至终都不需要开发人员去编写格式严苛的 Kubernetes 声明式配置文件。这对开发人员而言无疑是一个极大的利好,Kubernetes 虽好,但学习曲线非常陡峭。Kubernetes 默认通过 yaml 格式的声明式配置文件来部署业务系统,其中绝大多数的字段定义都是运维特征的体现,换句话说,绝大多数的字段定义,都不应该是开发人员关注的事情。

DevOps 工程师应该抓住开发人员使用 Kubernetes 的痛点,避免其接触复杂运维事务。云原生平台理应提供这种使用体验,让开发人员对 Kubernetes 完全无感知的情况下,完成业务系统的部署工作。换句话说,让 Kubernetes 变得对开发人员“透明”。

从这个方面来说,通过对三款开源云原生平台的体验,发现 Rancher 和 KubeSphere 虽说均可以基于图形化界面来部署自己的业务组件,然而这些图形化配置只是 yaml 声明式配置文件的 “翻译”,对于 Kubernetes 不够熟悉的用户想要顺利使用,还是有一定的门槛。Rainbond 这一点则做的非常不错,部署业务时完全感受不到 Kubernetes 的存在,对于不熟悉 Kubernetes 的用户而言非常友好。然而产品化定制的程度越高,跟随 Kubernetes 前进的脚步就越难,上游 Kubernetes 不断在推出新的功能特性,如何将新特性抽象成为用户易于理解的功能将会是个挑战。最新版本的 Rainbond 推出了 Kubernetes 属性这一功能特性,允许用户以 yaml 形式编辑 workload ,也是为打破自设的“天花板”。

降低操作基础设施的难度

既然要设计一款平台级的软件产品,那么就需要将复杂且不易被掌握的技术,抽象成为用户易于理解的功能。DevOps 工程师设计的云原生平台产品,首要任务之一,是能够降低开发人员使用基础设施的门槛。这个章节主要讨论的,是开发人员自行管理自己业务系统的运维特征。

就拿存储这件事来说,开发人员到底关注什么呢?

围绕存储这个概念,我们可以说出一堆名词,块设备、文件系统、对象存储、本地磁盘、磁盘阵列、NFS、Ceph等等。这些名词毋庸置疑都与存储相关,也的确会被各种业务系统所使用,但我相信,绝大多数的开发人员对这些名词并不关心。

作为用户,开发人员只关心一件事情,我所负责的业务系统,指定目录中的数据需要被持久化的保存下来。

大多数情况下,业务系统涉及到的存储场景都应该是简单的。在云原生时代,我们甚至呼吁开发人员在开发业务系统的时候,应该尽量做到“无状态化”,即在业务系统中,不存在限制实例横向扩容的状态数据,至少做到不同实例之间,数据可以共享。根据这一点,DevOps 工程师们完全可以为开发人员提供一个能够适应大多数场景的默认存储类型,各个云厂商提供的 NAS 类型存储是个很好的选择。

使用复杂存储的场景更多见于业务系统所调用的各种中间件中,比如数据库需要高速稳定的块设备类型存储,再比如大数据领域的“存算分离”场景下对接对象存储等等。然而在大多数场景下,这些复杂中间件的维护并不是开发人员应该关心的事情。它们由专门的运维人员进行维护,开发人员只需要得到访问它们的地址即可。

所以在这种简单存储场景下,开发人员最好可以仅仅填写一下自己需要被持久化的目录地址,由云原生平台来实现底层存储的配置。对存储基础设施的操作,开发人员并不需要关心。

3

从使用体验上来说,Rancher 和 KubeSphere 可选择的存储类型很多,这是因为它们的产品生态优于 Rainbond ,比如 Rancher Lab 直接推出了轻量级的存储解决方案 Longhorn,对于各大公有云厂商提供的存储产品驱动也都有集成。 Rainbond 依然在易用性方面做的够好,实现了上文中仅关注业务系统持久化目录的使用体验。然而仅对 NFS 类型的存储支持比较完善,对于其他类型的存储支持,需要在底层基础设施中自建驱动,安装起来不如前二者方便。

易于理解的应用模型

从工作负载层面上讲,Kubernetes 只通过 Deployment、Statefulset 等抽象描述单个组件的特征,然而多数情况下,开发人员开发出的业务系统会包含若干微服务组件。那么如何对整个业务系统进行统一的管理就变成了一个问题。解决方案之一,就是通过云原生应用平台,在单个组件之上,抽象出应用这个概念。应用应该是由人为规定的一组服务组件(workload)组成,服务组件之间具有显式或隐式的关联调用关系,彼此之间有机组合成为一个整体,作为一套完整的业务系统对外提供服务。

开发人员可以将所有的服务组件视作一个整体来进行管理,而非机械的单独管理每一个服务组件,这种操作体验无疑会更简单,也便于开发人员理解。对应用的管理可以包括统一的生命周期管理、统一的安装升级卸载,灵活拼装服务组件之间的调用关系,更合理的处理业务系统的交付流程。

目前 Kubernetes 领域内较为成熟的交付工具 Helm ,其设计也暗合此类模型,一条简单的 helm install xxx 命令,即可安装起一大堆组件以及围绕这些组件的配置。

4

Rancher 并没有实现自己的应用模型,其应用的安装方式集成了 Helm ,并没有体现出应用管理能力。

KubeSphere 则更进一步,在项目下的应用负载中提出了应用的概念。在应用中可以通过 Helm 或自建的形式部署服务,集成了微服务治理、单个组件的版本控制、路由管理、灰度发布等能力。其对 Helm 模板的支持,使得其从理论上可以支持任何市面上已有的 Helm Chart 包的安装部署。

Rainbond 的应用概念是最完善的,除了常规的生命周期操作、整个应用级的版本控制这样的常规能力之外,还有些非常易用的自研功能,能够简化开发人员对自己应用的管理。比如基于泛解析域名机制实现的对外服务域名,点击开启对外服务,就会生成一个公网可用的域名访问自己的应用,这比一层一层的配置 Ingress 规则容易太多。又比如应用复制能力,可以批量的将整套应用复制到另一个工作空间,而不必重新手动搭一套。

应用模板是 KubeSphere 和 Rainbond 均提出的一个概念,应用模板存在的意义是可以将开发好的应用复制到不同的环境中去,是一种制备新一代制品并交付分发的技术。应用模板的基础使用体验,是可以快速方便的安装整套应用系统,最好是一键化的体验,KubeSphere 和 Rainbond 都提供了应用商店,供用户快速安装一些已经制作好的应用模板。应用模板更高层次的使用体验,则是开发人员可以无任何技术负担的开发出自己的应用模板,而不仅仅是从应用商店拉取别人制作好的应用模板。

易于掌控的微服务架构

微服务架构也是云原生平台不可缺少的一个元素。微服务架构旨在帮助开发人员建设高类聚、低耦合的现代应用系统,将以往烟囱式的业务系统架构,拆散成为一大堆彼此间更为独立,包含自身功能特点的微服务模块。容器与相关编排技术的成熟,为微服务架构的落地打下了基础。云原生应用平台,则为开发人员更简单的入手微服务框架提供了可能。

云原生平台首选的微服务框架,应该是以 Istio、Linkerd 为代表的 Service Mesh 微服务框架, 也被称为“服务网格”。相对于 Spring Cloud 、 Dubbo ,这种微服务框架提供了更高的自由度和适应性,开发人员不需要被某种开发语言或产品绑定,只需要回归网络编程即可将自己的业务系统连接成为一个整体。这里要重点提出的是微服务架构对业务代码无侵入,只有无侵入的实现,才能最大限度降低开发人员花费精力学习其他领域知识的可能性。

DevOps 工程师可以通过设计云原生平台功能来进一步优化配置微服务的使用体验,大胆设想一下,开发人员只需要在两个服务组件之间拖动一条表征微服务调用关系的线,就可以生成对应的微服务配置。这样的操作体验完全可以使注册中心、控制平面这种微服务领域中复杂的概念对开发人员屏蔽。本质上讲,维护注册中心或者控制平面也是运维人员需要关心的工作。

5

Rancher 由于其自身的定位,产品中没有集成任何微服务相关的能力,用户需要手动安装 Istio 等微服务框架, 通过复杂的 yaml 配置,来引用微服务能力。

KubeSphere 和 Rainbond 都在应用层面默认集成了 Service Mesh 微服务框架,不同之处是前者集成了 Istio 方案,而后者的 Service Mesh 微服务框架是自研的。从使用体验上来说, KubeSphere 产品化的包装了 Istio,大幅度降低了 Istio 的使用体验,但这不意味着用户可以完全抛却 Istio 这一层的概念,应用内部的拓扑依靠事先的配置来体现。Rainbond 自研的微服务框架易用性更高一些,已经实现了拖拉拽式的微服务拼装模式,这一点还是很惊艳的。然而自己造的轮子过多,外部的其他方案有好的特性时想要快速集成接纳,就需要在微服务规范的对接层次更上层楼,毕竟 Istio、Linkerd 这些 Service Mesh 微服务框架一统江湖的情况下,其他生态的结合都会以它们为标准,而非自研框架。目前 Rainbond 也提供集成方式接纳了 Istio 治理模式,但还没有得到大量用户的使用验证。

对运维人员友好

之前的探讨,都是以开发人员为受众去考量的,但我们不应该忘记维护着底层基础设施正常工作的运维人员。任何软件的稳定运行都只是暂时的,出问题只是一个时间问题。云原生平台本身作为开发人员的基础设施,也需要被持续的维护。如何优化运维人员的管理体验,也是在云原生平台设计过程中的重点。

当今时代,Kubernetes 的使用与维护、容器化技术都已经成为了运维人员的标志性技能,对操作系统的掌控以及命令行工具的使用则是运维人员的看家本领。所以云原生平台在面向运维人员的设计中,不必要在易用性或图形化上考虑过多,更多要考虑的是可靠性、安全性、底层基础设施生态的兼容性。

6

Rancher 在运维层面的表现非常出众。得益于其丰富的周边生态,Rancher 在各个领域都得到了自家其他产品的原生支持。首当其冲的就是 RKE/RKE2/K3S 这几个 kubernetes 发行版,降低了不同场景下 Kubernetes 的安装难度。容器安全方面有 NeuVector 容器安全平台负责全生命周期的管理。基础设施方面有轻量级分布式块设备存储系统 Longhorn。除了丰富的生态之外,Rancher 产品界面的设计尤其符合运维人员的喜好。个人体验过程中认为 Kubectl Shell 非常惊艳,这是一个分屏式的命令行操作界面,运维人员可以一边在下半分屏 Shell 交互分页中敲命令,上半分屏中实时观察操作结果。

KubeSphere 也比较适合运维人员维护和管理。尤其是在监控报警层面,KubeSphere 制作了大量符合自身产品理念的可观测性图表,体验很不错。对于集群或节点的控制也做了图形化的设计,便于运维人员掌控。生态方面,KubeSphere 背靠青云,也在不断发展围绕自身的云原生项目,可以利用自家的驱动对接青云的云平台、云存储,以及负载均衡等基础设施。其内置的可插拔式的组件管理系统,可以快速扩展出平台级的其他能力。

Rainbond 对运维人员不太友好,甚至是一种“遗忘”了运维人员的设计理念。体验之后发现所有的运维操作依然离不开登录服务器这个前提。没有提供图形化亦或者命令行交互界面来操作集群和节点。对接多集群时,提供了图形化安装 Kubernetes 集群继而安装 Rainbond 的能力,体验还算不错。产品生态相较 Rancher 不够丰富,好在官方提供了很多文档支撑,来对接很多其他的云原生生态产品。比如提供文档对接阿里云ACK、华为云CCE、腾讯云TKE等云基础设施的安装方式。

在用户权限管理方面,Rancher 、KubeSphere 沿用了 Kubernetes RBAC 这一套体系,Rainbond 依然有些特立独行,权限管理体系并没有完全对照原生 Kubernetes RBAC 设计,甚至在使用 Rainbond 的时候,完全没有感觉到有 RBAC 体系的存在。对接外部的身份管理系统时,KubeSphere 主推 LDAP 协议,而 Rainbond 使用了 Oauth2.0 协议的实现。

其他方面,诸如稳定性、行为审计、监控报警方面三款产品各自有实现,没什么太大的区别。

写在最后

相对于招聘文武全才的“全栈式”开发人员搞定所有的 IT 事务,我更倾向于找到不同领域的专家来搞定各自领域的问题。在运维事务的领域里,构建并维护一套功能齐备的云原生平台,能够更好的解决 IT 业务系统从底层基础设施到开发过程,最终到达生产上线的运维支持问题。这是对 DevOps 理念比较合理的一种落地方式。

文中重点提到了 Rancher 、KubeSphere、Rainbond 这三款云原生平台级产品各自不同的实现。

归纳起来,Rancher 更偏向运维人员使用,来管理企业内部的各类 Kubernetes 基础设施。开发人员想要很好的使用 Rancher ,必须具备 Kubernetes 操作能力以及容器化技术。从这个角度来说,Rancher 的定位应该位于 PaaS 与云原生平台之间。

KubeSphere 和 Rainbond 都属于以应用为中心的云原生平台产品,二者的设计思路不同之处见仁见智。 KubeSphere 以可插拔式框架纳入了云原生领域的其他项目为己所用,将这些项目的能力串联起来为最终用户提供一站式的使用体验,然而这样的使用体验必然是有门槛的,每纳入一个项目,最终用户难免需要同时学习该项目和 KubeSphere 自身。Rainbond 的设计思路则更加的内聚,多数功能都自研。这样做的好处是功能体系高度自我契合,最终用户的使用体验非常好,功能之间衔接关联更符合人类思维,却容易自我限定,提高了纳入其他云原生生态的门槛。

DevOps 团队可以直接选择既有的云原生平台级产品使用,也可以基于开源项目二次开发。更落地的方式是选择其中多款进行混合部署,各取所长,以提到的三款产品为例,DevOps 团队完全可以选择 Rancher + KubeSphere 或 Rancher + Rainbond 的组合,它们之间并没有冲突,向下对接基础设施,管理集群的安全性与合规性是 Rancher 最擅长的事情,向上为最终开发人员提高易用的云原生平台的使用体验则交给 KubeSphere 或 Rainbond,最终的目标,是开发人员通过云原生平台的支持,从以往的运维工作之中解放出来,将精力更多的放在所开发的业务之上。

· 13 min read

Kubernetes 作为基础平台,提供了强大的容器编排能力。但是在其上部署业务和服务治理上,仍然会面对一些复杂性和局限性。在服务治理上,已经有许多成熟的 ServiceMesh 框架用于扩充其能力,如 Istio、Linkerd、Dapr 等。本文将主要介绍如何使用 Istio 扩充 Kubernetes 灰度发布的能力。

而在部署上,则会利用开源项目 Rainbond 作为基础平台来进行实践。Rainbond 是一个云原生应用管理平台,它使用以应用为中心的设计模式。基于这一设计模式抽象出了标准化的应用模型。从使用的体验上不需要学习和编写YAML,即可实现业务应用的全生命周期管理。因此使用它简化业务的部署和管理。同时 Rainbond 支持 ServiceMesh 框架的替换,使我们可以按需选择与业务最匹配的 ServiceMesh 框架进行服务治理。

Kubernetes 中如何实现灰度发布

当你在 Kubernetes 集群中部署业务时,可以利用 Kubernetes 原生提供的灰度发布的方式去上线业务。这种方式是通过在旧版本和新版本的服务之间,定义一个差异化的 Label,根据不同版本之间的公共 Label 负载流量到后端 Pod,最终实现根据 Pod 的副本数控制流量的百分比。

如下图所示:用户定义了两个 Deployment 对象,其中旧版本名为 frontend-stable,有3个副本。新版本为 frontend-canary,有1个副本。此时定义了一个 Service 对象,使用它们之间公共的 Label 进行选择。这就使得用户访问 frontend 这个 Service 时,能以 3:1 的比例同时访问到两个版本。并且还可以通过调整副本数持续控制流量比例,最终达到完整上线。

k8s-canary.png

Kubernetes 默认的实现方式在简单的部署场景下很有效,但是在一些复杂场景中,仍然会有较大的局限,如:

  1. 业务配置自动伸缩后,会直接影响灰度发布的流量比例

  2. 低百分比的流量控制占用资源高,如 1 % 的流量到达新版本,则至少需要 100 个副本

  3. 精确的流量分发控制,使访问到新版本中的用户一直是同一批,而不是某个用户访问时随机切换

Istio 灰度发布简述

由于 Kubernetes 提供的灰度发布方式的局限性,在一些复杂场景下,我们就需要使用 Istio 来实现更精细的灰度发布策略。在使用 Istio 进行灰度发布时,我们需要了解两个重要概念:

  1. Virtual services: 虚拟服务定义了请求到服务的路径。可以包含一组路由规则,使匹配到对应规则的请求能到达指定目标。

  2. Destination rules: 目标规则可以管理到达该目标的流量,如对服务后端所对应的实例池进行分组,再结合 Virtual services 定义的路由规则,最终将流量转发到正确的实例上。

如下图所示,以 istio 官网提供的 Bookinfo 示例程序为例,给出了 virtual services 和 destination rules 的主要定义。其中 virtual services 主要分为两块,主机名和路由规则。主机名是客户端向服务发送请求时使用的一个或多个地址。当请求到达 virtual services 时,则会根据其定义的路由规则匹配。图中就定义了邮箱以 gmail.com 结尾的用户流量只会到达 v3 版本的实例上。而其他用户则以 1:9 的比例分别访问到 v1 和 v2 版本的服务。这种方式实现了精确的流量分发控制。

当用户流量来到 reviews.demo.svc.cluster.local 这个 Service 上时,可以看到 destination rules 的规则定义中根据 version 这个 label 定义了不同的实例集,实现了流量比例与副本数的解耦。不管 reviews-v1 有多少实例。始终只有 10% 的流量到达 destination rules 的 v1 子集中。这就解决了业务副本数与流量比例的冲突问题,也使得资源使用更加合理。

istio-canary.png

Istio 灰度发布在 Rainbond 上的实践

基于以上理解,我们接下来以 BookInfo 为例来体验 Istio 的灰度发布。

1. 准备工作:

在开始之前,我们需要提前安装好所需要的环境。

1) 安装 Rainbond

参考 Rainbond 官方文档 快速安装,安装完成后可以通过对接 Helm 商店一键安装 Istio 以及相应组件。

  1. 安装 Istio 以及 Kiali

登录到 Rainbond 控制台后,先创建一个团队,团队英文名对应 Kubernetes 中的命名空间,Istio 默认安装的命名空间为 istio-system ,因此团队英文名填写istio-system,名称可以填写为 istio项目。接下来对接 Helm 商店,通过 应用市场 -> 点击➕号 -> Helm 商店 对接。商店名称随意填写,地址填写 https://openchart.goodrain.com/goodrain/rainbond。商店对接完成后,我们即可点击安装 istio、kiali 等应用。详细可参考 Istio 安装

2. 部署 BookInfo 应用

在部署 BookInfo 之前,我们需要在 Rainbond 中创建一个团队和应用,并将应用的治理模式切换为 Istio 治理模式。在 Rainbond 中应用治理模式切换是指可以无侵入地变更应用下组件间通信治理模式。

如下图所示,一个完整应用会包含多个微服务模块,而 ServiceMesh 框架则是对所有业务容器注入 Proxy,根据注入Proxy的差异可以支持多种类型的 ServiceMesh 实现,比如:Istio、Linkerd、Dapr,应用可以按需开启 ServiceMesh 能力,或更换实现框架。为了让 BookInfo 这个应用使用到 Istio 的治理能力,所以需要切换到 Istio 治理模式

service-mesh.png

  1. 准备镜像

BookInfo 这个应用程序由 6 个微服务组成,它们之间的依赖如下图所示。其中 Productpage 这个服务提供了访问页面,从 Details 这个服务中获得书籍详细信息。从 Reviews 服务中获得书籍评价。其中 Reviews-v2 和 Reviews-v3 会从 Ratings 这个服务中获得书籍的评级信息。这六个微服务的镜像如下:

docker.io/istio/examples-bookinfo-productpage-v1:1.17.0
docker.io/istio/examples-bookinfo-details-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v2:1.17.0
docker.io/istio/examples-bookinfo-reviews-v3:1.17.0
docker.io/istio/examples-bookinfo-ratings-v1:1.17.0

bookinfo.png

  1. 部署组件

我们在应用下,选择添加组件 -> 指定镜像 -> 填写镜像地址 -> 新建组件 -> 确认创建,即可依次创建出这 5 个微服务对应的组件。

  1. 生成可用的 Service

刚刚我们仅完成了所有服务的部署,还未定义这些微服务的访问策略。以 Productpage 为例,我们通过点击拓扑图中 Productpage 这个组件,即可进入这个服务的管理页面。找到 端口 -> 添加端口 -> 端口号填写9080 -> 打开对外服务 -> 点击生成的路由,即可访问成功。 此时会发现 Productpage 这个组件的页面还无法拉取到书籍评价信息。这是由于它默认使用 details 和 reviews 这两个 Service 名称连接到它依赖的组件。此时我们部署的 Reviews-v1 等组件还没有正确的 Service 名称。因此还是进入组件管理页面,组件端口 -> 添加端口 -> 端口号填写9080 -> 修改使用别名 -> 内部域名填写为 reviews-v1 -> 打开对内服务。details、reviews-v2、ratings 等组件都是如此,填写其对应的 Service 名称后,打开对内服务即可。

最后在应用的 K8s 资源下,我们还需要创建一个如下的 Service,用来在 Reviews 的三个版本之间负载流量。

apiVersion: v1
kind: Service
metadata:
labels:
app: reviews
service: reviews
name: reviews
spec:
ports:
- name: http
port: 9080
protocol: TCP
targetPort: 9080
selector:
component: reviews # 需要在 Reviews 三个版本中,均添加 Kubernetes 属性,设置上该 Label,才能正确生效
sessionAffinity: None
type: ClusterIP
  1. 编排依赖关系

完成以上操作后,访问 Productpage 应用,可以看到书籍评论能正确在三个版本中切换了。此时,可以在应用视图下,切换到编排模式,根据上述 BookInfo 应用的架构图进行连线,实现拓扑图的编排。如下图所示,这样编排的好处是后期可以将这个应用整体发布出去,其他用户直接安装下来即可得到一样的拓扑关系,再也不用担心找不到各个服务依赖的组件。

topological.png

3. 灰度发布

在完成以上部署操作后,我们得到了一个完整的 BookInfo 程序,但此时还未定义 Istio 相关配置,所以还需要通过 Kiali 去定义流量规则。实现灰度发布。

  1. 配置路由规则

访问 Kiali 管理页面,即可看到该应用。在左侧边栏选择 Services,找到 reviews 这个 Service,点击进入,右上角 Actions 选择 Traffic Shifting,即可看到如下配置:拖动滑块选择流量比例。下图中 30% 的流量将会访问到 reviews-v1 上,70% 的流量访问到 reviews-v2上。点击创建后,即可看见页面左下角,Kiali 自动为你生成了 virtual services 和 destination rules 资源。你可以点击进去根据自己需求再次编辑。

kiali.png

  1. 验证路由规则是否生效

找到最开始部署的组件 Productpage,进入组件管理页面,点击右上角访问入口,可以看到书籍详情和评级,反复刷新页面,可以看到不带星级的评价信息(reviews-v1)与黑色星级评价信息(reviews-v2)出现的比例大概是 3:7。红色星级评价信息(reviews-v3)从未出现。

  1. 验证组件扩容对流量的影响

找到部署的组件 reviews-v1 ,进入组件管理页面 -> 伸缩 -> 实例数量设置为4,此时再次访问 Productpage 页面,反复刷新页面,可以看到 reviews-v1 扩容后,访问到 reviews-v1 与 reviews-v2 的比例仍为 3:7,组件实例数的多少对流量分发策略没有影响。

· 23 min read

云原生的本质和最终效果

要明白什么是云原生,就要先弄明白云计算是什么有什么问题,云计算将计算资源、网络、存储等基础设施统一管理,通过资源规模化和自动化管理,实现降低资源的成本和提高资源的管理效率,云计算本质上解决的是资源的自动化管理问题,但数字化和信息化的关键在应用,云计算没有解决应用的管理问题,应用的管理和运维是难题,对人依赖度很高,云原生的出现就是为了解决应用的管理问题,应用管理比资源管理复杂很多,涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理,还要配合应用解决资源自动化管理问题,云原生本质就是解决应用的自动化管理问题。

从效果来看,云原生的最终目标是让开发者聚焦自己的业务,业务之外(基础设施、应用架构、应用运维)的事情不用关心,只需要懂业务就能创造出自己想要的应用,并能按需交付客户。

使用 Kubernetes 落地云原生困难重重

当前云原生相关的技术很多,其中最关键是容器、微服务架构、Kubernetes ,他们颠覆式的解决了应用管理自动化问题。

  • 容器技术解决了应用打包和部署自动化问题,通过容器打包保证了应用基础环境的一致性,实现了一次打包,处处运行。同时容器可以定义应用运行资源,部署时按需占用资源,实现从应用角度解决资源管理自动化。

  • 微服务架构解决了复杂应用的解耦和治理问题,当业务越大越复杂,微服务架构将业务拆分和解耦成多个模块,并通过服务治理实现微服务运行和管理的自动化。

  • Kubernetes解决了应用编排和调度自动化问题,它是应用自动化管理最关键的拼图,底层基于容器、SDN、SDS,能实现各类型应用和微服务部署和运维过程自动化。

为了实现应用管理自动化,还有很多云原生相关的技术,像SDN(网络自动化管理)、SDS(存储自动化管理)、Helm(复杂应用交付自动化)、Service Mesh(无侵入扩展服务治理能力)、Monitoring(监控自动化)、Logging(日志自动化)、Tracing(性能分析自动化)、Chaos engineering(容错自动化)、Gateway(网关自动化)、SPIFFE (应用访问安全自动化)等等,这些技术可以跟Kubernetes结合起来使用,解决应用各个运维特征的管理自动化问题。

上面这些技术主要围绕着Kubernetes,所以落地过程主要是Kubernetes落地,Kubernetes落地过程一般分为两部分,Kubernetes的搭建和Kubernetes的使用。对于Kubernetes搭建,基于以上技术自主搭建完整的Kubernetes集群非常复杂,既要学习这些技术还要了解他们的原理,最困难的是要把他们有机的组装起来。不过大多公司有专职的维护工程师,可以抽出大把时间来学习和尝试。或者,选择公有云厂商提供的Kubernetes商业服务,所以,搭建Kubernetes是有路径落地的。

相比搭建Kubernetes,Kubernetes的使用一般是开发人员,开发人员人数众多,使用习惯和学习门槛决定了开发人员的接受度,而云原生平台的使用不仅要改变开发习惯,还要学习很多新技术,落地过程困难重重。

  1. 需要学习很多新概念和技术。 云原生相关的技术和概念有很多,光 Kubernetes就有很多新的概念和抽象,像Workload、Pod、Service、Ingress、ConfigMap、PV等,如果要用好还需要学习Kubernetes周边的很多概念和技术。

  2. 已有应用需要改造,开发习惯需要改变。 已有的应用要运行在 Kubernetes上,需要会写 Dockerfile 和 YAML,如果要改造成微服务架构,还需要按照框架的SDK改造代码,跟之前的开发习惯会有很大变化。

  3. 如何将应用高效交付给客户,Kubernetes及上面这些技术并没有解决。 应用只有交付给客户才能产出价值,当前交付客户的自动化程度不高,Kubernetes并没有解决交付过程自动化的问题。在 To C的场景,业务频繁迭代,交付的频率很高,需要保质保量。在To B场景,交付更加复杂,不同的客户有不同的要求,需要针对不同客户有不同的交付模式,比如SaaS、私有交付、离线交付、个性化交付等,交付也是成本里的大头。

应用抽象模型是云原生可落地的关键(实现思路)

云原生落地的难点在使用,如果能将云原生底层复杂的技术包装成开发者熟悉的应用层属性和动作,开发者就不用学习新的概念和技术;如果能将业务跟运维能力解耦,跟微服务框架解耦,就能实现开发者按需扩展运维能力和切换微服务框架,实现对业务按需赋能;如果能实现根据不同客户类型,自定义交付流程和自动化交付,就能大大降低交付成本,提升客户满意度;当以上三点都能解决,就可以让开发者聚焦在业务本身,业务之外的事情不用关心,有更多精力关注客户价值输出。

基于以上思考,通过应用抽象模型是个解决思路,对应用整体进行包装和抽象,包含应用运行所需的全部运行定义,与底层技术和概念隔离。向上用户不需要再学习和了解系统级概念和技术,应用内部把业务和扩展能力解耦,使用应用级概念开发和管理,需要扩展服务治理、运维、安全等能力时按需开启插件。向下则包装Kubernetes的概念和抽象,屏蔽掉底层基础设施的差异,实现应用抽象模型可以运行在各类基础设施上。

应用抽象模版核心设计在三方面:

  1. 应用级抽象
  2. 架构充分解耦
  3. 使用应用模版交付

应用级抽象能简化理解和使用

应用级抽象是“以应用为核心”的抽象模型,对用户暴露应用级的概念、属性和动作,底层Kubernetes和系统级的概念和技术,要么完全实现自动化,要么包装成应用级的属性和动作。 为了实现灵活的应用编排和自动化调度,Kubernetes 定义了很多概念,提供丰富的扩展机制,并以YAML的方式跟它交互,Kubernetes的这些可编程的体验,对管理和扩展Kubernetes的人来说,是非常好的特性,但对于普通开发者,门槛太高,并且很多概念和技术跟自己开发的业务并没有直接关系,所以对于普通开发者来说需要更加友好的操作体验,不需要学习就能使用。

应用级抽象和Kubernetes概念 粗粒度的对应关系:

应用级属性Kubernetes概念
应用运行环境Containers
应用运行属性Workload
应用网络属性SDN
应用存储属性SDS
应用对外服务属性Ingress
应用对内服务属性Service
应用插件Pod
应用配置ConfigMap

应用级抽象并不是要将Kubernetes概念全部隐藏起来,而是对于不同的使用者,职责不同展现不同的交互界面。 对普通开发者职责是开发业务,只需要关心应用级的概念,提供应用级的操作界面。但对于云原生平台的管理人员,除了关心应用级的概念,还要关心Kubernetes的管理和维护,有能力的话还可以扩展平台的能力,所以对于平台管理人员,提供高级的暴露Kubernetes概念的操作界面,或者直接操作Kubernetes也可以管理平台上的应用,通过这种方式也规避了,由于包装概念产生的“黑箱”导致对平台的可观测性和可掌控性不足。

架构充分解耦,根据使用场景按需组合

基于应用级的抽象,应用模型通过标准的Kubernetes API实现跟基础设施的解耦,所有符合标准Kubernetes API 的基础设施都可以实现对接和部署,比如各公有云厂商的Kubernetes实现、K3s、KubeEdge等,通过这样的解耦,开发者只需要关心业务和能力扩展,不用在关心基础设施的差异,对接应用模型的应用不需要改动就能透明部署到公有云、私有云和边缘设备上,实现了应用级多云。

通常在应用里,还会包括一些跟业务无关的功能,他们的作用是为了让应用更好的运行,比如:服务治理、微服务框架、运维工具、安全工具等,这些能力跟应用有强耦合关系的,需要改代码扩展能力,将这部分能力解耦,应用就只需要关注在业务了,而且扩展的能力有很强的复用性,其他应用也需要。

应用中扩展能力的解耦使用 Kubernetes 的 Pod,Pod中包含一个或多个容器,所有容器共享网络、存储,应用运行在一个容器,扩展的能力通过扩展容器的方式运行,通过共享的网络和存储实现了应用和扩展能力的解耦,这种解耦方式对业务完全无侵入,扩展的能力用插件的形式包装,就可以实现应用按需安装和启动插件,根据网络流向和容器启动顺序可以定义几种类型插件:

插件类型说明
入口网络插件网络流量先到入口网络插件,然后到业务容器。例如:网关、WAF、安全工具、限流
出口网络插件网络流量先到业务容器,然后到插件容器。例如:负载均衡、断路器、加密访问
出入网络插件网络流量先到插件容器,再到业务容器,再回到插件容器。例如:Service Mesh proxy
旁路插件网络上旁路运行。例如:性能分析、监控 、调用链分析、日志管理
初始化 插件Pod的Init容器,Pod启动先启动Init容器。例如:数据库初始化

按照Pod机制实现的插件只能扩展单个业务容器的能力,而要对应用扩展微服务架构能力,需要对每一个业务容器扩展服务治理的插件,这跟Service Mesh的实现机制一致,Service Mesh的Data Plane需要对每个业务容器注入Proxy,对于完整应用就是扩展Service Mesh能力,对完整应用扩展的能力是应用级插件,根据注入Proxy的差异可以支持多种类型的Service Mesh 实现,比如:Istio、Linkerd、Dapr,应用可以按需开启Service Mesh 能力,或更换实现框架。当应用跟微服务架构解耦,每一个业务容器不再受微服务框架和开发语言限制,每个业务容器只需要专注业务本身,业务容器之间也同步实现了解耦。

通过将架构充分的解耦,解耦后的业务、插件、对接多云的能力都能实现随意组合,开发者选择喜欢的开发语言开发业务组件,根据业务契约编排依赖关系,根据服务治理和运行稳定性要求,按需开启Service Mesh插件和其他运维插件,运行的基础设施环境,也根据实际需要自动对接。

应用模版成为能力复用和应用交付的载体

应用模型以应用模版的形式具象化展现和存储,应用由源码、容器镜像和插件拼装而成,然后一键导出成应用模版,应用模版设计主要围绕使用者,让使用者能用起来,让应用交付并产出价值,从而拉动应用的迭代和开发。从使用体验上,应用模版可以一键安装和一键升级,通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性,应用模版支持不同颗粒度大小,模版和模版能拼装出新的模版,新的模版还可以持续拼装,颗粒的大小由使用者决定,由使用者赋予它意义。应用模版可以交付到兼容Kubernetes API的分支版本,实现一键安装和升级,或将应用模版存放到应用市场,实现即点即用的效果。

应用模版需要具备四个特点:

  • 模块化,可以形成可复用的能力单元,按需拼装使用场景。
  • 自治,自给自足,可以独立安装、升级和管理,确保组合的灵活性。
  • 可编排,模版和模版可以拼装出新模版,具备无限拼装能力。
  • 可发现,通过内部服务和外部服务两种方式体现,可供业务和技术、开发者和其他应用访问。

通过应用模版实现可复用模块和能力的打包。 应用的架构充分解耦后,业务组件和扩展插件理论上可以复制到其他应用中,但直接复制代码或镜像非常低效,而且还有很多运行环境相关的配置需要考虑,将业务组件和扩展插件打包成应用模版,并将应用模版发布到应用市场供其他人使用,可以最大程度实现模块和能力的复用,减少重复造轮子。

通过应用模版实现SaaS、私有化和离线环境的自动化交付,和个性化场景模块拼装。 应用模板中包含应用运行态所需的全部资源,对接到客户运行环境,就可以实现一键安装和运行,屏蔽了客户环境差异,一套产品模版可以交付所有类型客户,对于离线环境,应用模版以文件的形式导出,到客户离线环境再导入运行即可。对于功能需要个性化的场景,利用应用模版对业务模版打包的能力,先拼装已经模块化的能力,然后再定制化开发,新开发的功能,如果可复用还可以继续发布成应用模版,供后续复用。

不懂 Kubernetes 实现云原生的体验

基于以上的设计思路,让开发者专注于业务本身,回到用户效果和价值体现的原点上,不用关心底层复杂的技术和不相关的概念,全面实现应用自动化。

开发应用的体验:

  1. 代码无需改动,就能变成云原生应用。 对于新业务或已有业务,代码不需要改动就能将其容器化。不需要懂 docker 、Kubernetes 等技术,就能将应用部署起来,具备云原生应用的全部特性。
  2. 业务积木式拼装编排。 可复用的业务模块积累到应用市场,当由新业务需要开发,基于应用市场已经业务模块,通过“拖拉拽”的方式拼装,然后再开发没有的业务能力,当积累的业务模块越多,开发新业务的速度越快。
  3. 开箱即用的Service Mesh微服务架构,并可一键更换Service Mesh框架。 不用学习微服务框架的SDK,通过无侵入的方式实现Service Mesh微服务架构,主流的Service Mesh框架以插件的形式存在,需要时开启,如果觉得不好还可以随时更换。

使用应用的体验:

  1. 像安装手机 App 一样安装云原生应用。 云原生应用以应用模版的形式存放到应用市场,当对接各种基础设施或云资源,实现应用即点即用或一键安装/升级。
  2. 普通开发者不需要学习就能实现应用运维。 通过应用级抽象,普通开发者了解应用级属性就能实现应用运维,并通过插件扩展监控、性能分析、日志、安全等运维能力,应用运维不再需要专用的SRE。
  3. 复杂应用一键交付客户环境。 复杂应用发布成应用模版,当客户环境可以联网,对接客户环境一键安装运行,当客户环境不能联网,导出离线应用模版,到客户环境导入并一键安装运行。

实现方案

基于上面的设计思路,我们在Kubernetes基础上实现了Rainbond,并将它开源。Rainbond提供开箱即用的体验,使用简单,不需要懂容器和Kubernetes,支持管理多种Kubernetes集群,提供企业级应用的全生命周期管理。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。

· 10 min read

别再担心线上 Java 业务出问题怎么办了,Arthas 帮助你解决以下常见问题:

  • 这个类从哪个 jar 包加载的?为什么会报各种类相关的 Exception?
  • 我改的代码为什么没有执行到?难道是我没 commit?分支搞错了?
  • 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗?
  • 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现!
  • 是否有一个全局视角来查看系统的运行状况?
  • 有什么办法可以监控到 JVM 的实时运行状态?
  • 怎么快速定位应用的热点,生成火焰图?
  • 怎样直接从 JVM 内查找某个类的实例?

Arthas(阿尔萨斯)是一款线上监控诊断产品,通过全局视角实时查看应用 load、内存、gc、线程的状态信息,并能在不修改应用代码的情况下,对业务问题进行诊断,包括查看方法调用的出入参、异常,监测方法执行耗时,类加载信息等,大大提升线上问题排查效率。

Arthas 采用命令行交互模式,同时提供丰富的 Tab 自动补全功能,进一步方便进行问题的定位和诊断。

同时 Arthas 也支持通过 Web Console 进入命令行交互模式,这适用于开发人员没有服务器权限时通过 Arthas Web Console 诊断业务。

Arthas 在 Rainbond 上集成

1. 插件集成

通过 Rainbond 插件的机制,从 Rainbond 开源应用商店一键安装 Arthas 插件并在组件中开通,组件启动时会自动下载 arthas-agent.jar 结合环境变量配置使用 javaagent 方式启动。

2. Arthas Tunnel 集成

当我们的微服务业务有 10+,这时通过 Arthas 去诊断就会比较麻烦,开发人员没有服务器的权限并且通过 Web Console 访问的话也会由于访问地址太多导致特别混乱。这时就需要通过 Arthas Tunnel Server/Client 来远程管理/连接多个 Agent。

Arthas Agent 会通过 WS 注册到 Arthas Tunnel 中,实现统一管理。

Arthas Tunnel 可通过 Rainbond 开源应用商店一键安装。

3. Arthas Web Console

对于 Spring Boot 应用则无需通过 Arthas Tunnel 访问 Web Console,在组件内添加8563端口即可访问 Web Console。(注意:域名访问需开启 Websocket 支持

使用Arthas诊断Rainbond上的Spring Boot应用

本小节使用若依SpringBoot作为示例。

首先需要安装 Rainbond云原生应用管理平台,可参阅文档 安装 Rainbond Allinone

1. 部署 Spring Boot 应用

团队 -> 新增 -> 基于应用商店创建组件 -> 在应用商店中搜索 若依SpringBoot 进行一键部署。

2. 安装 Arthas Java Agent 插件并配置

2.1 安装插件

团队 -> 插件 -> 从应用商店安装插件 -> 在应用商店中搜索 Arthas-Agent 进行一键部署。

2.2 开通插件

ruoyi-admin 开通 Arthas Agent 插件,在组件内 -> 插件 -> 未开通 -> 开通插件。

2.3 环境变量配置

ruoyi-admin 组件配置环境变量,在组件内 -> 环境变量 -> 添加变量。

变量名变量值
JAVA_OPTS-javaagent:/arthas/arthas-agent.jar
ARTHAS_APP_NAMEruoyi-admin
ARTHAS_AGENT_IDruoyi-admin

2.4 添加端口并更新

ruoyi-admin 组件添加 8563 端口并打开对外服务,更新组件完成后可通过默认域名访问 Web Console。

使用Arthas诊断Rainbond上的SpringCloud应用

使用 Arthas 诊断部署在 Rainbond 上的微服务 Spring Cloud Pig,并通过 Arthas Tunnel 统一管理 Arthas agent。本小节将使用 Spring Cloud Pig 作为示例。

首先需要安装 Rainbond云原生应用管理平台,可参阅文档 安装 Rainbond Allinone

1. 部署 Spring Cloud Pig

团队 -> 新增 -> 基于应用商店创建组件 -> 在应用商店中搜索 SpringCloud-Pig 进行一键部署。

2. 部署 Arthas Tunnel

团队 -> 新增 -> 基于应用商店创建组件 -> 在应用商店中搜索 Arthas-Tunnel 进行一键部署。

3. 安装 Arthas Agent 插件并配置

1. 安装插件

团队 -> 插件 -> 从应用商店安装插件 -> 在应用商店中搜索 Arthas-Agent 进行一键部署。

2. 开通插件

为每个微服务组件都开通插件,进入微服务组件 -> 插件 -> 开通插件 Arthas-Agent

3. 配置环境变量

为每个微服务组件配置环境变量,在组件内 -> 环境变量 -> 添加变量。

变量名变量值说明
JAVA_OPTS-javaagent:/arthas/arthas-agent.jarJAVA 启动参数
ARTHAS_APP_NAMEregisterarthas app name,根据实际情况修改
ARTHAS_AGENT_IDregisterarthas agent ID 不可与其他 ID相同,是唯一的

4. 配置依赖关系

将所有微服务组件依赖至 arthas tunnel,应用视图切换到编排模式进行拖拉拽。

5. 批量更新

更新/重启所有微服务相关组件。可在 列表 中批量操作。

4. 通过 Arthas Tunnel 连接到其他 Agent 进行诊断

1.可通过 Arthas Tunnel 8080 端口默认生成的域名访问 Web Console。

2.在 Web Console 中的 IP:PORT 填写 Arthas Tunnel 7777 的对外服务端口,7777 端口是 Agent 连接到 Tunnel 的。所以在通过 Web 远程连接到其他服务时修改 AgentId 即可连接

Arthas 使用入门

1. Arthas 命令使用

Arthas 采用命令行交互模式,同时提供丰富的 Tab 自动补全功能,进一步方便进行问题的定位和诊断,以下是部分命令,详细请参阅文档 Arthas命令列表

  • dashboard - 当前系统的实时数据面板
  • getstatic - 查看类的静态属性
  • heapdump - dump java heap, 类似 jmap 命令的 heap dump 功能
  • jvm - 查看当前 JVM 的信息
  • logger - 查看和修改 logger
  • mbean - 查看 Mbean 的信息
  • memory - 查看 JVM 的内存信息
  • ognl - 执行 ognl 表达式
  • perfcounter - 查看当前 JVM 的 Perf Counter 信息
  • sysenv - 查看 JVM 的环境变量
  • sysprop - 查看和修改 JVM 的系统属性
  • thread - 查看当前 JVM 的线程堆栈信息
  • vmoption - 查看和修改 JVM 里诊断相关的 option
  • vmtool - 从 jvm 里查询对象,执行 forceGc

以下是部分命令的使用截图:

2. 生成火焰图

profiler 命令支持生成应用热点的火焰图。本质上是通过不断的采样,然后把收集到的采样结果生成火焰图。
以下命令均在Arthas Tunnel Web Console 中执行。

1.启动 profiler

$ profiler start
Started [cpu] profiling

2.停止 profiler 并生成火焰图

默认情况下,结果文件是html格式,也可以用--format参数指定:

$ profiler stop --format html
OK
profiler output file: /app/arthas-output/20220907-214802.html

3.通过浏览器查看火焰图

上一步生成的 html 文件在指定的微服务组件中,所以需要在该微服务组件中查看火焰图。

进入到该微服务组件中,例如:pig-auth,在组件端口中添加 3658 端口并打开对外服务并访问 http://domain/arthas-output

最后

Arthas 是款非常好的 Java 诊断工具,而在 Kubernetes 中使用较为复杂。Rainbond 底层基于 Kubernetes,在此之上抽象了应用模型,使用户更方便的在 Kubernets 中部署管理应用,并且通过 Rainbond 的插件机制让用户更便捷的使用 Arthas 诊断业务,降低了在 Kubernetes 中使用 Arthas 的门槛,用户只需关注业务。