基于 KubeSphere 的 Kubernetes 生产环境部署架构设计及成本分析

转载:基于 KubeSphere 的 Kubernetes 生产环境部署架构设计及成本分析 

前言

导图

1. 简介

1.1 架构概要说明

今天分享一个实际小规模生产环境部署架构设计的案例,该架构设计概要说明如下:

  • 本架构设计适用于中小规模(<=50)的 Kubernetes 生产环境,大型环境没有经验,有待验证。

  • 所有节点采用云上虚拟机的方式部署,出于某些原因所有组件均自建,没有使用云上产品(有条件建议使用云上产品)。

  • 本架构设计不包含安全设备,不包含 Kubernetes 安全配置,安全要求高的环境不适用。

  • 本架构设计属于第一版, 也是我在 Kubernetes 生产集群架构设计实践之路上走出的第一步,难免有一些不合理的地方(欢迎各位指正),后续会根据线上遇到的问题持续进行优化改进。

  • 本架构设计是基于 KubeSphere 部署的 Kubernetes,后续的很多功能实现都依托于 KubeSphere。

  • 本架构设计时使用的当时最新的软件版本,拿到目前来看也有一定的参考意义,完全可以直接套用,换一下软件版本即可(具体怎么换,请看下文)。

本文只介绍选型分析部署架构图部署架构设计说明部署节点规划上云总成本分析等内容,具体的安装部署暂不涉及。

1.2 选择 KubeSphere 的理由

KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台,提供全栈的 IT 自动化运维的能力,简化企业的 DevOps 工作流。

KubeSphere 提供了运维友好的向导式操作界面,帮助企业快速构建一个强大和功能丰富的容器云平台。

  1. 完全开源,通过 CNCF 一致性认证的 Kubernetes 平台,100% 开源,由社区驱动与开发。

  2. 安装简单,使用简单,支持部署在任何基础设施环境,提供在线与离线安装,支持一键升级与扩容集群。

  3. 功能丰富,在一个平台统一纳管 DevOps、云原生可观测性、服务网格、应用生命周期、多租户、多集群、存储与网络。

  4. 模块化 & 可插拔,平台中的所有功能都是可插拔与松耦合,您可以根据业务场景可选安装所需功能组件。

  5. 具备构建一站式企业级的 DevOps 架构与可视化运维能力(省去自己用开源工具手工搭积木)。

  6. 提供从平台到应用维度的日志、监控、事件、审计、告警与通知,实现集中式与多租户隔离的可观测性。

  7. 简化应用的持续集成、测试、审核、发布、升级与弹性扩缩容。

  8. 为云原生应用提供基于微服务的灰度发布、流量管理、网络拓扑与追踪。

  9. 提供易用的界面命令终端与图形化操作面板,满足不同使用习惯的运维人员。

  10. 可轻松解耦,避免厂商绑定

除了上面的 10 条理由以外,更主要的是同类产品中 KubeSphere 属于最能打的,其它竞品在当年(2021 年)或多或少都有一些问题,无法走进我的心里。

其实一开始我是奔着 Rancher 去的,毕竟当年的 CloudStack 我也算是资深玩家。但是,Rancher 从上手到放弃我只用了一个下午,理由就不多说了,毕竟每个人的评判标准不一样,只是个人觉得不适合。

到了 2023 年的今天,虽然,KubeSphere 发展慢了下来、每次发布新版本或多或少都有一些问题、代码质量也不稳定(只用基本功能的话其实还好)。但是,在同类竞品中依旧是没有对手(如果有,请评论区留言告诉我)。

2. 部署架构设计

2.1 部署架构图

2.2 涉及软件版本

初次设计 v1.0 版时的主要软件版本

  • 操作系统版本:centos7.9

  • kubesphere:  v3.1.1

  • KubeKey版本:v1.1.1

  • Kubernetes版本:v1.20.4

  • docker版本:v19.03.15

  • GlusterFS:9.4

  • ElasticSearch:7.15

2023 年 8 月 适用的软件版本

  • 操作系统版本: CentOS7.9

  • KubeSphere:  v3.2.1生产不建议用 3.3.x、3.4.x系列

  • KubeKey: v3.0.10老版本也行,只要支持 KubeSphere v3.2.x 和 Kubernetes v1.24.x 即可

  • Kubernetes:v1.24.x

  • Containerd:1.6.4替换掉 Docker

  • GlusterFS:9.6按理说应该用10.x,不知为何 CentOS 的源里居然没有

  • ElasticSearch:8.x选最新的就行

2.3 网络规划

我们网络要求比较多。因此,根据不同功能模块,规划了不同的网段方便安全策略的控制。各位可根据需求合理规划,所有节点都放在一个网段也可以。

功能域网段说明
代理网关192.168.8.0/24代理网关作为南北向流量的转发节点,一定要和其他组件放在不同的网段
k8s 集群192.168.9.0/24k8s 集群内部节点使用
存储集群192.168.10.0/24持久化存储、日志存储域节点使用
中间件集群192.168.11.0/24独立在k8s集群外的,各种中间件节点使用

3. 部署架构设计说明

整体的部署架构设计采用了传统的分层、分域的思想(只是这思想被我乱用的分层有点多)概要为如下 10 层/域:

  • 用户访问层(最终用户)

  • 防火墙/WAF 等安全设备层(本文没有介绍,云上必备,内部可选

  • 代理网关层

  • 负载均衡层

  • Kubernetes 集群域

  • 持久化存储域

  • 日志存储域

  • CI/CD 域

  • 中间件域(在 K8S 集群之外,独立部署)

  • 运维域

3.1 用户访问层

泛指最终用户(无论从哪个渠道入口访问平台实际业务的用户)

3.2 防火墙等安全设备层

安全是重中之重,所有上线的业务,安全设备是必不可少的,本架构设计里只提到了防火墙、WAF,实际使用中应该还有更多,这个只能大家根据需求自行组合了。

因为,安全设备层不在我的职责范围内,我只能说必须有,但是很多细节我也说不清,索性就不过多介绍了。

3.3 代理网关层规划

在代理网关的选择上,第一版选择了利用 Nginx 自建的方案,并没有选择 Ingress、Istio 等高级方案(刚接触并不熟悉没敢用)。

采用 2 台服务器部署典型的 Nginx + KeepAlived 服务,实现高可用的 7 层流量转发网关,根据域名判断规则将流量转入后端 K8S 集群节点对应的 NodePort。

该方案的优点就是对于新手比较友好,部署、维护、配置比较简单,因为都是比较熟悉的属于运维必备的玩法了。缺点就是配置文件的变更、同步都需要人工操作(最多加点自动化手段),有出错的风险。

3.4 负载均衡层规划

负载均衡属于 Kubernetes 集群内部使用,有种可选方案。

  1. 采用公有云或是私有云平台上自带的弹性负载均衡服务(建议选择,很多云服务商内部的 SLB 是免费的)

需要配置监听器监听相应的服务端口

服务端口协议端口
apiserverTCP6443
ks-consoleTCP30880
httpTCP80
httpsTCP443
  1. 采用 HAProxy 或是 Nginx 自建负载均衡(此次选择

本架构设计由于某些原因,采用了 HAProxy 自建负载均衡的方案, 部署了 2 个HAProxy 节点,并使用 Keepalived 实现 VIP 故障切换保证了高可用。

这样的选择也增加了成本,毕竟 2 台 2C 4G 配置的机器一年的成本也有几千块,重点是还要自己部署维护。

所以,在公有云的场景下还是使用服务商提供的弹性负载均衡服务(SLB)比较好,内部使用的免费而且还不需要自己维护。

  1. 使用 KubeKey 自带的解决方案部署 HAProxy

从版本 v1.2.1 开始,KubeKey 提供了内置高可用模式,支持一键部署高可用集群环境。

KubeKey 的高可用模式实现方式称作本地负载均衡模式。具体表现为 KubeKey 会在每一个工作节点上部署一个负载均衡器(HAproxy),所有主节点的 Kubernetes 组件连接其本地的 kube-apiserver ,而所有工作节点的 Kubernetes 组件通过由 KubeKey 部署的负载均衡器反向代理到多个主节点的 kube-apiserver 。这种模式相较于专用到负载均衡器来说效率有所降低,因为会引入额外的健康检查机制,但是如果当前环境无法提供外部负载均衡器或者虚拟 IP(VIP)时这将是一种更实用、更有效、更方便的高可用部署模式。

目前,这种部署模式用的人也很多,他们给出的理由是部署简单。更多细节可以参考 使用 KubeKey 内置 HAproxy 创建高可用集群。

本架构方案初始设计时 KubeKey v1.1.1 并不支持该方式,个人建议生产环境不要用这种方案,而是采用独立部署的全局负载均衡器。

3.5 k8s 集群层规划

Kubernetes 集群初始部署采用 3 Master 和 N Worker 的架构,这样即实现了 Kubernetes 控制平面的高可用,也能满足前期业务部署对资源的需求,而且也有利于后期的升级扩容。

  • Master 节点:3 节点,部署 KubeSphere 和 Kubernetes 的管理组件、ETCD 等服务。

注意:本方案并没有把etcd单独部署,有条件或是规模较大的场景可以单独部署etcd

  • Worker 节点:前期选择 6 个节点,部署业务应用。各位可以根据实际需求决定初始化数量,但是,建议最少 3 个,后期扩容的时候增加节点的数量也是以 3 的倍数为单位。

Kubernetes 组件的高可用架构图如下:

这里,需要多说一句,不知道从何时开始互联网流行了一种 2 Master 的部署架构。从我做架构设计的经验来看,不建议各位使用 2M 的架构,毕竟既然考虑了高可用架构那么一定要顾及 ETCD ,2 节点的 ETCD 怎么玩高可用?

2M 的架构也只是解决了 Kube 组件的高可用,还是要找其他节点复用解决 ETCD 高可用的问题 。如果资源实在紧张可以选择 3 Master 复用为 Worker 的部署架构,也千万不要用 2M 的架构。

如果一定要用 2 M 的架构,那么只适用一个场景,那就是 ETCD 采取独立节点部署的方案。(如有不同意见,可以在评论区留言,欢迎真正的技术探讨

3.6 持久化存储域规划

本架构设计选择了使用 GlusterFS 作为 Kubernetes 集群的持久化存储

  • 3 个存储节点,安装部署 GlusterFS,其中一个节点安装 Heketi 作为管理端。

  • 每个节点 1T 数据盘

存储组件架构图

存储选型说明:

  1. 持久化存储候选者

    存储方案优点缺点说明
    Ceph资源多没有ceph集群故障处理能力,最好不要碰曾经,经历过3副本全部损坏数据丢失的惨痛经历,因此没有能力处理各种故障之前不会再轻易选择
    GlusterFS部署、维护简单;多副本高可用资料少部署和维护简单,出了问题找回数据的可能性大一些
    NFS使用广泛单点、网络抖动据说生产环境用的很多,但是单点和网络抖动风险,隐患不小,暂不考虑
    Longhorn官宣企业级云原生容器存储解决方案,还未实践
  2. 第一季入选者

    GlusterFS

  3. 说明

    • GlusterFS + Heketi 的存储解决方案,属于第一次做架构设计的尝试,属于摸着石头过河,也由于以前有过 GlusterFS 的运维经验,所以先用着,后期根据运行情况再重新调整。

    • 大家请根据自己的存储需求和团队运维能力选择适合的方案,有技术实力的团队还是尽量选择 Ceph 吧。

    • 因为我们的业务场景对于持久化存储的需求也就是存放一些 Log 日志,能承受一定的数据损失,也是选择 GlusterFS 的原因之一。

    • 存储规划中假设 1T 数据满足需求,没考虑扩容,后续会做补充。

本次选型使用的是 Heketi 的对接方案,使用比较广泛,网上的参考用例比较多,但是该方案也存在一定弊端,各位需要根据自己的情况选择。

  • 实现形式在底层创建了一堆的 LVM 卷,如果卷太多又太小的话,后期运维会比较麻烦,有一定的未知风险。

  • Heketi 项目官方已经停止更新了,项目处于维护状态,这就比较麻烦了,新入坑者慎入。(2023 年 7 月,该项目已经归档了)

3.7 日志存储域规划

日志存储选择了普遍使用的 ElasticSearch 作为日志存储方案,主要用于 KubeSphere 日志、事件等插件采集的日志数据的存储。

实际部署中采用了 3 个节点部署 ElasticSearch,利用 3 副本 实现数据的可靠性。KubeSphere 使用启用用户名和密码认证的 HTTP 协议去连接 ElasticSearch 存取数据。

由于不好预估日志规模,在磁盘空间规划上每个机器初期都分配了 1 T的数据盘。最后,我发现实际使用中30多个业务模块,日志按要求保留 180 天的场景下,500G 都用不了。

同时,初期在运维管理域部署了 Kibana 连接 ElasticSearch,实现可视化管理。后期,将 Kibana 移到了 K8S集群上,使用 Helm 的方式部署。

3.8 CI/CD 域规划

CI/CD 并没有使用太复杂的功能,主要使用了 KubeSphere 内嵌的 devops 插件,利用 Jenkins 流水线实现了应用自动构建、镜像上传、自动发布、审核发布等功能。

主要包含以下组件:

  • Jenkins,使用 KubeSphere 定制的 devops 插件(在 Kubernetes 集群上部署 Jenkins 及相应的构建任务容器)

  • GitLab,开发代码、运维代码管理,实现GitOps(在 K8S 集群外使用虚拟机独立部署)

  • Harbor,镜像仓库(在 K8S 集群外与 GitLab 在一台虚拟机上独立部署)

3.9 中间件域规划

有一些数据或是服务,在做架构设计时觉得部署在 K8S 集群上不靠谱,所以采用了在 K8S 集群外部的虚拟机上独立部署。

早期的规划是包含 MySQL、RabbitMQ、RocketMQ、Redis 等组件的,后来只独立部署了 MySQL,其他组件均安排到了 Kubernetes 之上。

  • 独立部署主从复制模式的 MySQL 数据库,适合中小规模使用。大规模需要专业运维人员或是使用云上成熟的产品,有条件建议使用云服务商的RDS产品

多说一句,中间件的选型上如果是在公有云环境,最好对比一下云上产品,如果成本差不多,更建议选择云上的成熟产品。

3.10 运维管理域规划

监控、告警、自动化运维、其他运维辅助工具都规划在了运维管理域,机器的分配可以根据实际情况规划。

主要包含以下组件:

  • Ansible,自动化运维管理工具,执行日常批量运维管理操作。

  • Prometheus、Alertmanager, 用于实现 K8S 集群和集群上部署的业务应用组件的监控和告警(初期计划是自己搭建,后来发现 KubeSphere 集成的也挺好用,就暂时放弃了自建)。

  • Kibana,对接 ElasticSearch,实现数据可视化管理。

4. 部署节点规划

先看一眼总数,整个集群使用了 23 台虚拟机,120 核 CPU、464 GB 内存、920 GB 系统盘、12500 GB 数据。

接下来我们详细说一下每一层的节点如何规划部署。(规划中没有包含防火墙、WAF等网络设备)。

4.1 代理网关节点规划

节点角色主机名CPU(核)内存(GB)系统盘(GB)数据盘(GB)IP备注
nginx代理nginx-12440192.168.8.2/192.168.8.1自建域名网关,暂时未采用 Ingress
nginx代理nginx-22440192.168.8.3/192.168.8.1自建域名网关,暂时未采用 Ingress
合计24880

4.2 Kubernetes 集群节点规划

节点角色主机名CPU(核)内存(GB)系统盘(GB)数据盘(GB)IP备注
负载均衡k8s-slb-12440192.168.9.2/192.168.9.1
负载均衡k8s-slb-22440192.168.9.3/192.168.9.1
Masterk8s-master-183240500192.168.9.4
Masterk8s-master-283240500192.168.9.5
Masterk8s-master-383240500192.168.9.6
Workerk8s-node-183240500192.168.9.7
Workerk8s-node-283240500192.168.9.8
Workerk8s-node-383240500192.168.9.9
Workerk8s-node-483240500192.168.9.10
Workerk8s-node-583240500192.168.9.11
Workerk8s-node-683240500192.168.9.12
合计11762964404500

重点说明: 由于初次上线怕资源不够,Master 节点的配置有点多,实际使用中 4C 16G 足够了(第二版的架构设计中已经改正了)。

4.3 存储节点规划

存储节点包含持久化存储和日志存储节点

节点角色主机名CPU(核)内存(GB)系统盘(GB)数据盘(GB)IP备注
存储节点storage-1416401000192.168.10.1
存储节点storage-2416401000192.168.10.2
存储节点storage-3416401000192.168.10.3
日志存储节点elastic-1416401000192.168.10.4
日志存储节点elastic-2416401000192.168.10.5
日志存储节点elastic-3416401000192.168.10.6
合计624962406000

4.4 中间件节点规划

节点角色主机名CPU(核)内存(GB)系统盘(GB)数据盘(GB)IP备注
MySQL-主db-master41640500192.168.11.2/192.168.11.1数据盘可以选高IO的SSD
MySQL-从db-slave41640500192.168.11.3/192.168.11.1数据盘可以选高IO的SSD
配置管理harbor41640500192.168.11.10安装 GitLab 和 Harbor (配置可缩)
Prometheusmonitor41640500192.168.11.11安装 Ansible,用于自动化运维
合计416641602000

上面的节点资源配置规划,多少有几点不合理的地方,或者可以说是可以优化改进的地方,欢迎各位在评论区留言讨论。

5. 成本分析

回顾一下汇总的资源总数,整个集群使用了 23 台虚拟机,120 核 CPU、464 GB 内存、920 GB 系统盘(不要钱)、12500 GB 数据。

看着这些汇总数据,我自己都有点害怕,降本增效的当下,这有点多啊(实际上还是有优化空间的,差不多能减下去三分之一)。

接下来我们根据节点规划详细算算账,这到底要花多少银子?

货比三家,特意选了三家公有云服务商,用官方提供的价格计算器算了算公开报价(所有报价均为 2023 年 8 月报价)

有三点需要特别注意:

  • 规划中没有包含防火墙、WAF等网络设备。

  • 本报价只是公开报价成本,仅供参考。(渠道不同,各大云平台折扣也不同

  • 为了对比报价成本,所有选型都用的参数类似的产品,实际使用中请根据需求调整,例如,CPU、硬盘的调整。

5.1 计算节点类型汇总及成本分析

配置规格汇总

配置类型数量
2C 4G4
4C 16G10
8C 32G9
合计23

公开报价汇总

公有云平台2C 4G(单价)2C 4G(4台总价 )4C 16G(单价)4C 16G(10台总价)8C 32G(单价)8C 32G(9台总价)备注
阿里云2,386.809,547.205,902.8059,028.0011,662.80104,965.20北京、通用型 g6(计算型)、系统盘(高效云盘)
华为云1,661.506,646.004,279.6042,796.008,419.1075,771.90北京、通用计算 S6、系统盘(高IO)
天翼云1,734.006,936.004,610.4046,104.009,057.6081,518.40北京、通用型、系统盘(高 IO)

说明: 阿里云只有计算型里有 2C 4G 的配置。

5.2 数据盘类型汇总及成本分析

因为,系统盘不用额外算钱,包含在计算资源之内(实际上在云主机选择的时候可以选择硬盘大小,大小不同价格也不同)。所以,我们只给数据盘买单。磁盘类型设计方案中使用了统一的高IO类型,实际中请根据服务需要选择。

磁盘规格汇总

数据盘规格数量
500G13
1000G6
合计19

公开报价汇总

公有云平台500G(单价)500G(13 块总价)1000G(单价)1000G(6 块总价)备注
阿里云2,146.2027,900.604,292.4025,754.40北京、高效云盘、0.245/时(500G)
华为云1,750.0022,750.003,500.0021,000.00北京、高IO
天翼云2,040.0026,520.004,080.0024,480.00北京、高IO

5.3 总成本合计分析

云平台计算资源总价(人民币/元/年)存储资源总价(人民币/元/年)最终总价
阿里云173,540.4053,655.00227,195.40
华为云125,213.9043,750.00168,963.90
天翼云134,558.4051,000.00185,558.40

综合算下来,这套架构使用的云上资源成本多少还是有点费钱的,预计公开报价总成本最少需要人民币 168,963.90 元/年。作为一个合格的运维架构师,架构设计中成本考虑是一个重要因素,要是拿不到很好的折扣价,老板估计要干掉我了。(至于实际价格就各凭本事喽!!!

5. 总结

本文分享了我设计的第一版基于 KubeSphere 部署 Kubernetes 集群的部署架构规划方案, 此方案是一个真实的小规模生产环境部署架构设计的案例,该生产环境基于 KubeSphere v3.1.1 和 Kubernetes v1.20.4 已经稳定运行了将近 2 年,运行期间只遇到过 3 个 重大问题。

  • 到一年期的时候更换证书(运维不当,证书到期后才发现,手工用命令更换证书,重启相关服务后解决)

  • GlusterFS 存储扩容 1T 硬盘(直接添加新硬盘,使用 Hekiti 扩容即可)

  • ElasticSearch 无法写入数据(这个是因为索引最大值配置造成的,更该配置后解决)

除上述 3个 问题之外,在运维得当的前提下,并没有发现其他重大故障。

概括一下,本文主要从以下几个方面介绍了第一版的部署架构设计方案:

  • 整个集群的部署架构图

  • 所有涉及的主要软件的版本

  • 网络规划设计

  • 部署架构分层设计思想及 10 层规划的详细说明(本文核心价值)

  • 部署节点规划及成本分析

这套部署架构设计方案是我设计的第一套 Kubernetes 生产环境部署方案,多少会有一些不合适的地方,比如 Master 节点资源分配过多数据盘分配的过大ElacticSearch 是否需要高可用等。(其它读者觉得不合理的地方,也欢迎评论区留言或是私信我讨论交流)。

所以,此架构方案运行的生产环境的持续运维中,我也根据出现的问题结合监控数据等可视化数据做了总结分析,设计了第二版的部署架构,也会在后期整理分享给大家,请持续关注哟!!!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/390405.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

C#对象和类型

属性、方法、字段 字段和属性的区别 在C#中&#xff0c;字段&#xff08;fields&#xff09;和属性&#xff08;properties&#xff09;都是类的成员&#xff0c;它们提供了类存储数据的方式&#xff0c;但它们在用途和功能上有着明显的区别。 字段 字段通常用来存储类…

Gstreamer配合srs服务器实现RTMP直播和WebRtc直播

前言 上一篇文章,实现了配合腾讯云直播的推流,但是需要花钱,于是就在思考能不能搞一个局域网内,免费的RTMP直播呢? 最终发现了可以使用srs服务器。如果成功了,以后也可以使用webrtc的直播推流。 以下是实现效果: 一、搭建srs服务器: 参考:ubuntu环境下搭建SRS服务器(…

MyBatis全方位指南:从注解到XML文件的数据库操作

目录 一.什么是MyBatis 入门程序初体验 二.MyBatis基本操作CRUD ▐ 增(Insert) 返回主键 ▐ 删(Delete) ▐ 改(Update) ▐ 查(Select) 起别名 结果映射 开启驼峰命名(推荐) 三.MyBatis XML配置文件 ▐ 增(Insert) ▐ 删(Delete) ▐ 改(Update) ▐ 查(Select) …

Linux:Xshell相关配置及前期准备

一、Linux的环境安装 1、裸机安装或者是双系统 2、虚拟机的安装 3、云服务器&#xff08;推荐&#xff09;——>安装简单&#xff0c;维护成本低&#xff0c;学习效果好&#xff0c;仿真性高&#xff08;可多人一起用一个云服务器&#xff09; 1.1 购买云服务器 使用云服…

基于环形拓扑的多目标粒子群优化算法(MO_Ring_PSO_SCD)求解无人机三维路径规划(MATLAB代码)

一、无人机多目标优化模型 无人机三维路径规划是无人机在执行任务过程中的非常关键的环节&#xff0c;无人机三维路径规划的主要目的是在满足任务需求和自主飞行约束的基础上&#xff0c;计算出发点和目标点之间的最佳航路。 1.1路径成本 无人机三维路径规划的首要目标是寻找…

【传知代码】Flan-T5 使用指南(论文复现)

当今&#xff0c;自然语言处理技术正在以前所未有的速度和精度发展。在这个领域中&#xff0c;Flan-T5作为一种新兴的预训练语言模型&#xff0c;正吸引着广泛的关注和应用。Flan-T5不仅仅是一个强大的文本生成工具&#xff0c;它还能通过提供高效的语义理解和多任务学习能力&a…

springboot配置多个数据源

实际业务中&#xff1b;在一个项目里面读取多个数据库的数据来进行展示&#xff0c;例如读取mysql&#xff0c;pgsql&#xff0c;oracle的不同数据库&#xff0c;springboto对同时配置多个数据源是支持的。 使用springbootmybatis的框架来进行演示&#xff0c; 在配置文件中配…

美国失业率大幅上升,增加九月份降息利率的可能性

令人失望的是&#xff0c;美国7月份经济增加了11.4万个工作岗位&#xff0c;低于预期的17.5万个和6月的17.9万个。平均小时工资持续下降&#xff0c;但失业率升至4.3%。美元继续走低&#xff0c;美国国债也在下跌&#xff0c;而黄金则获得了提振。 7月份的非农业支付数据令人失…

鸿蒙 IM 即时通讯开发实践,融云 IM HarmonyOS NEXT 版

融云完成针对“纯血鸿蒙”操作系统的 SDK 研发&#xff0c;HarmonyOS NEXT 版融云 IM SDK 已上线&#xff0c;开发者可在“鸿蒙生态伙伴 SDK 市场”查询使用。 发挥 20 年通信行业技术积累和领创品牌效应&#xff0c;融云为社交、娱乐、游戏、电商、出行、医疗等各行业提供专业…

react引入高德地图并初始化卫星地图

react引入高德地图并初始化卫星地图 1.安装依赖 yarn add react-amap amap/amap-jsapi-loader2.初始化地图 import AMapLoader from "amap/amap-jsapi-loader"; import { FC, useEffect, useRef, useState } from "react";const HomeRight () > {con…

普通人有必要学Python吗?学了之后能做什么?

目录 首先来说一下极其推荐的方向&#xff1a; 1、数据分析 2、科学计算 3、大数据框架 4、脚本开发 5、爬虫 6、Web框架 总结&#xff1a; 如果你还没有开始使用Python&#xff0c;答应我&#xff0c;把这个回答看完&#xff0c;如果你真的学习并深入使用过Python&…

我的最爱之《达明一派》

达明一派&#xff0c;是我最爱。刘以达(Tats)与黄耀明(Anthony Wong)在1980年代的香港组成的二人流行音乐组合&#xff0c;在90年代&#xff0c;网络还没兴起时&#xff0c;那是卡带流行的岁月。90年代&#xff0c;我与好友&#xff0c;同考大学&#xff0c;他留在了南充读读书…

使用labelme生成mask数据集(亲测可行)

1、下载label.exe文件 链接&#xff1a;github地址 2、安装一下anaconda&#xff0c;百度一下直接安装就行 3、打开labelme.exe文件&#xff0c;直接加载图片&#xff0c;然后编辑多边形&#xff0c;就是mask的位置 4、画好mask了&#xff0c;保存为json文件&#xff0c;记住这…

【qiankun微前端】基座主应用(vue2)+多个微应用(任意框架)

前言 前段时间对我们已有的工程进行了微前端改造,后来思考一下微前端的本质,查询了不少资料,从qiankun微前端示例中学到了不少。 微前端的核心,似乎应该是一个基座应用(含登录页,layout页,404和首页等),多个子应用(任意框架,提供内部页面内容),下面就对这个思路…

stm32入门-----软件I2C读写MPU6050

目录 前言 MPU6050 1.简介 2.相关参数 3.硬件电路 4.MPU6050框图 C编程实现I2C读写MPU6050步骤 1.MyI2C.c文件 &#xff08;1&#xff09;引脚的宏定义 &#xff08;2&#xff09;对SCL和SDA的操作以及初始化 &#xff08;3&#xff09;起始信号标志 &#xff08;4…

数据结构(面试)

目录 线索二叉树哈夫曼树并查集最小生成树最短路径拓扑排序二叉排序树平衡二叉树红黑树折半查找散列表堆排序归并排序 线索二叉树 原理&#xff1a;利用树节点的n1个左右空指针指向其遍历序列的前驱和后继&#xff08;线索&#xff09; 优点&#xff1a;简化遍历&#xff0c;不…

7.2 单变量(多->多),attention/informer

继续上文书写&#xff1a; 1 GRU Attention 收敛速度稳定的很多&#xff0c;你看这些模型是不是很容易搭&#xff0c;像积木一样&#xff1b; def create_model(input_shape, output_length,lr1e-3, warehouse"None"):input Input(shapeinput_shape)conv1 Conv…

【C++标准模版库】模拟实现vector+迭代器失效问题

模拟实现vector 一.vector成员变量二.构造函数1.无参&#xff08;默认&#xff09;构造2.有参构造3.拷贝构造1.传统写法2.现代写法 三.vector对象的容量操作1.size2.capacity3.clear4.empty5.reserve6.resize 四.vector对象的访问及遍历操作1.operator[]2.实现迭代器&#xff1…

免费【2024】springboot 大学生志愿者管理系统的设计与实现

博主介绍&#xff1a;✌CSDN新星计划导师、Java领域优质创作者、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java技术领域和学生毕业项目实战,高校老师/讲师/同行前辈交流✌ 技术范围&#xff1a;SpringBoot、Vue、SSM、HTML、Jsp、PHP、Nodejs、Python、爬虫、数据可视化…

windows下设置java环境变量

1.打开window的环境变量设置 右键开始菜单选择系统 选择高级系统设置&#xff1a; 点击环境变量 2.在系统变量 新增 JAVA_HOME&#xff1b;该变量的值 选择jdk所在的目录即可。 JAVA_HOME: D:\Program Files\Java\jdk1.8.0_131 3. 在系统变量新增 classpath; 该变量的值设置…