kubernetes(4) 微服务

一、什么是微服务

在 Kubernetes 中，控制器负责维持业务副本，但真正把业务“暴露”出去的是 Service。
一句话理解：

  • Service = 一组 Pod 的稳定访问入口 + 4 层负载均衡

  • Ingress = 7 层路由 + 统一入口 + 灰度 / 认证 / 重写等高级能力

默认情况下，Service 仅具备 4 层（TCP/UDP）能力，如需 7 层（HTTP/HTTPS）请使用 Ingress。

二、微服务（Service）的四种类型总览

类型作用与适用场景
ClusterIP默认值，集群内部虚拟 IP；仅供集群内部访问，自动 DNS 与服务发现。
NodePort在每个节点打开固定端口（30000-32767），外部通过 节点IP:端口 即可访问服务。
LoadBalancer基于 NodePort，再申请外部云负载均衡（或 MetalLB）；适用于公有云或裸金属+MetalLB。
ExternalName将集群内请求通过 CNAME 转发到任意指定域名；常用于外部服务迁移或跨集群调用。

三、Service 的默认实现：iptables vs IPVS

  • iptables 模式（默认）

    • 规则多、刷新慢，万级 Pod 场景下 CPU 抖动明显。

  • IPVS 模式（推荐生产）

    • 内核级四层负载，支持 10w+ 连接，性能稳定。

    • 切换后自动生成虚拟网卡 kube-ipvs0，所有 ClusterIP 被绑定到该接口。

3.1 一键切换到 IPVS 模式

1.所有节点安装工具

yum install ipvsadm -y

2.修改 kube-proxy 配置

    kubectl -n kube-system edit cm kube-proxy
# 找到 mode 字段，改为 "ipvs"

    如果什么都没有，说明是默认的使用iptables，这里我们加上ipvs

    修改配置后，要重启，这里可以删掉之前的网络配置pod，重新刷新新的pod出来，此时就是新策略的pod

    3.滚动重启 kube-proxy Pod

      kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pod "$1)
}'

      4.验证

        ipvsadm -Ln | head
# 出现 10.96.x.x:xx rr 即成功

        四、微服务类型详解

        4.1 ClusterIP —— 集群内默认访问方式

        4.1.1 标准 ClusterIP 示例
        apiVersion: v1
kind: Service
metadata:labels:app: timingleename: timinglee
spec:ports:- port: 80          # Service 端口protocol: TCPtargetPort: 80    # Pod 端口selector:app: timinglee    # 绑定到标签一致的 Podtype: ClusterIP     # 可省略，默认即 ClusterIP
        kubectl apply -f clusterip.yml
kubectl get svc timinglee
# NAME      TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
# timinglee ClusterIP  10.99.127.134 <none>        80/TCP    16s

        clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能

        追加内容，此时微服务和控制器就在一个配置文件里了

        只有集群内部的IP，集群外部的不暴露

        4.1.2 DNS 自动解析验证
        # 集群内部可直接解析
dig timinglee.default.svc.cluster.local @10.96.0.10
# ;; ANSWER SECTION:
# timinglee.default.svc.cluster.local. 30 IN A 10.99.127.134

        4.2 Headless —— 无 ClusterIP 的直连模式

        适用场景：StatefulSet 的稳定网络标识、客户端自己做负载均衡、自定义 DNS 策略。

        apiVersion: v1
kind: Service
metadata:name: timinglee
spec:clusterIP: None          # 关键字段ports:- port: 80targetPort: 80selector:app: timinglee

        之前有了无头服务，要删掉，不然影响实验

        没有了IP以后，后端就没有调度了

        此时我们可以用dns来写，把要访问的server直接指定到后端的服务器中去

        #开启一个busyboxplus的pod测试

        kubectl apply -f headless.yml
kubectl get svc timinglee
# NAME      TYPE       CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
# timinglee ClusterIP  None         <none>        80/TCP    6s

        DNS 结果直接返回所有 Pod IP：

        dig timinglee.default.svc.cluster.local @10.96.0.10
# ANSWER SECTION:
# timinglee.default.svc.cluster.local. 20 IN A 10.244.2.14
# timinglee.default.svc.cluster.local. 20 IN A 10.244.1.18

        4.3 NodePort —— 节点端口暴露

        4.3.1 快速示例
        apiVersion: v1
kind: Service
metadata:name: timinglee-service
spec:type: NodePortports:- port: 80targetPort: 80nodePort: 31771          # 可省略，自动分配 30000-32767selector:app: timinglee
        kubectl apply -f nodeport.yml
kubectl get svc timinglee-service
# NAME      TYPE      CLUSTER-IP    EXTERNAL-IP  PORT(S)        AGE
# timinglee NodePort 10.98.60.22   <none>       80:31771/TCP   8s

        之前的服务设置了无头服务，这里要删除之前环境，重新运行

        多了一个端口

        这个端口用来直接对外暴露

        外部访问测试：

        curl 172.25.254.100:31771/hostname.html
# timinglee-c56f584cf-fjxdk

        nodeport在集群节点上绑定端口，一个端口对应一个服务

        直接负载到下面两个

        用clusterip来访问后端的

        访问模式

        对应的端口是不固定的，但是我们可以直接指定，但是有范围限制最大30000

        但是想要超过限制也可以，修改配置文件就行。但是集群会挂掉，要等待自愈

        加上这句话- --service-node-port-range=30000-40000

        刚刚还不能超过的限制，现在就可以了

        NodePort 默认端口范围 30000-32767；如需自定义范围，请修改 kube-apiserver 参数 --service-node-port-range=30000-40000。

        4.4 LoadBalancer —— 云或裸金属的外部 VIP

        4.4.1 公有云场景
        apiVersion: v1
kind: Service
metadata:name: timinglee-service
spec:type: LoadBalancerports:- port: 80targetPort: 80selector:app: timinglee

        在 云厂商（AWS/GCP/阿里云） 上，提交 YAML 后会自动为 Service 分配一个公网 VIP：

        kubectl get svc timinglee-service
# NAME      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
# timinglee LoadBalancer  10.107.23.134  203.0.113.10     80:32537/TCP   4s
        4.4.2 裸金属场景：MetalLB

        MetalLB 为裸金属或私有集群实现 LoadBalancer 功能。

        ① 安装 MetalLB
        # 1) 确保 kube-proxy 为 IPVS 模式（见第 3.1 节）
kubectl edit cm -n kube-system kube-proxy   # mode: "ipvs"
kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pod "$1)}'# 2) 下载官方清单
wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml# 3) 修改镜像地址（私有仓库）
sed -i 's#quay.io/metallb/controller:v0.14.8#reg.timinglee.org/metallb/controller:v0.14.8#' \metallb-native.yaml
sed -i 's#quay.io/metallb/speaker:v0.14.8#reg.timinglee.org/metallb/speaker:v0.14.8#' \metallb-native.yaml# 4) 推送镜像到 Harbor
docker pull quay.io/metallb/controller:v0.14.8
docker pull quay.io/metallb/speaker:v0.14.8
docker tag ... && docker push ...# 5) 部署
kubectl apply -f metallb-native.yaml
kubectl -n metallb-system wait --for=condition=ready pod -l app=metallb --timeout=120s
        ② 配置 IP 地址池
        # configmap.yml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: first-poolnamespace: metallb-system
spec:addresses:- 172.25.254.50-172.25.254.99     # 与本地网络同段
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:name: examplenamespace: metallb-system
spec:ipAddressPools:- first-pool
        kubectl apply -f configmap.yml

        再次查看 Service：

        kubectl get svc timinglee-service
# NAME      TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
# timinglee LoadBalancer  10.109.36.123   172.25.254.50   80:31595/TCP   9m9s

        集群外直接访问 VIP：

        curl 172.25.254.50
# Hello MyApp | Version: v1 | ...

        部署安装

        必须要把集群做成ipvs的模式

        并且重启网络方面的pod

        这个文档里的路径已经修改好了，如果是未修改的，记得把路径换成自己的软件仓库

        这个生效了之后，才能改配置

        之前这里还是正在生效，现在已经有了IP

        #通过分配地址从集群外访问服务

        已经自动分配对外IP

        4.5 ExternalName —— DNS CNAME 转发

        开启services后，不会被分配IP，而是用dns解析CNAME固定域名来解决ip变化问题

        一般应用于外部业务和pod沟通或外部业务迁移到pod内时

        在应用向集群迁移过程中，externalname在过度阶段就可以起作用了。

        集群外的资源迁移到集群时，在迁移的过程中ip可能会变化，但是域名+dns解析能完美解决此问题

        • 业务尚在集群外（如 RDS、COS、第三方 API）。

        • 迁移过程中保持调用方 域名不变，仅改 DNS 指向。

        apiVersion: v1
kind: Service
metadata:name: timinglee-service
spec:type: ExternalNameexternalName: www.timinglee.org   # 目的域名
        kubectl apply -f externalname.yml
kubectl get svc timinglee-service
# NAME      TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)   AGE
# timinglee ExternalName   <none>       www.timinglee.org   <none>    2m58s

        集群内 Pod 访问 timinglee-service 时，DNS 会直接返回 www.timinglee.org 的地址，无需维护 IP 变化。

        集群内部的IP在访问时，做的是域名解析

        把真实的微服务转化成其他主机上

        没有IP时如何被访问的，通过dns的域名解析

        验证 DNS 解析

        这行命令测试 Kubernetes 集群内部 DNS（10.96.0.10是集群 DNS 服务的 IP）是否能正确解析ext-service对应的域名：

        结果显示ext-service.default.svc.cluster.local（集群内部服务域名）被解析为www.baidu.com
        最终解析到百度的实际 IP 地址（103.235.46.115和103.235.46.102）

        得到了集群内部的主机

        微服务把集群外部的资源映射到集群内部，让集群内部可以使用

        五、Ingress-Nginx 全景实战

        Ingress = 7 层路由 + 多域名 + 灰度 + 认证 + TLS + 重写

        在service前面在加一个nginx

        在集群暴露时，再加一个反向代理

        一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层

        Ingress由两部分组成：Ingress controller和Ingress服务

        Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。

        业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

        5.1 部署 Ingress-Nginx（裸金属）

        # 1) 下载官方清单
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/baremetal/deploy.yaml# 2) 镜像同步到私有仓库
docker tag registry.k8s.io/ingress-nginx/controller:v1.11.2 \reg.timinglee.org/ingress-nginx/controller:v1.11.2
docker tag registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.4.3 \reg.timinglee.org/ingress-nginx/kube-webhook-certgen:v1.4.3
docker push ...# 3) 修改清单中的镜像地址
sed -i 's#registry.k8s.io/ingress-nginx/controller#reg.timinglee.org/ingress-nginx/controller#' deploy.yaml
sed -i 's#registry.k8s.io/ingress-nginx/kube-webhook-certgen#reg.timinglee.org/ingress-nginx/kube-webhook-certgen#' deploy.yaml# 4) 部署 & 等待就绪
kubectl apply -f deploy.yaml
kubectl -n ingress-nginx wait --for=condition=ready pod -l app.kubernetes.io/name=ingress-nginx --timeout=120s

        在部署文件里

        上传ingress所需镜像到harbor

        运行配置文件，并且查看是否建立了新的命名空间

        此时查看还是没有对外开放的ip的，因为微服还没有修改，现在还是只能集群内部访问

        #修改微服务为loadbalancer

        此时就有对外开放的IP了

        在ingress-nginx-controller中看到的对外IP就是ingress最终对外开放的ip

        测试ingress

        生成一下模板

        上面是控制器，下面是微服务

        默认 Service 类型为 NodePort，如需 LoadBalancer：

        kubectl -n ingress-nginx edit svc ingress-nginx-controller
# 把 type: NodePort 改为 type: LoadBalancer
kubectl -n ingress-nginx get svc
# NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
# ingress-nginx-controller   LoadBalancer   10.103.33.148   172.25.254.50   80:34512/TCP,443:34727/TCP

        5.2 基于路径的多版本分流

        5.2.1 部署两套版本业务
        # myapp-v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-v1
spec:replicas: 1selector:matchLabels: {app: myapp-v1}template:metadata:labels: {app: myapp-v1}spec:containers:- name: myappimage: myapp:v1
---
apiVersion: v1
kind: Service
metadata:name: myapp-v1
spec:selector:app: myapp-v1ports:- port: 80targetPort: 80
        kubectl apply -f myapp-v1.yaml
# 同理再建 myapp-v2.yaml（镜像改为 v2，service 名为 myapp-v2）

         

        装了两台主机，两台主机呈现不同web页面

        核心动作都是nginx完成的

        调用nginx类，访问微服务的80端口

        当我们去访问我们刚刚设立的对外IP时，它带我们去看的时myappv1的80端口里的内容

        5.2.2 创建基于路径的 Ingress
        # ingress-path.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-pathannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- path: /v1pathType: Prefixbackend:service:name: myapp-v1port: {number: 80}- path: /v2pathType: Prefixbackend:service:name: myapp-v2port: {number: 80}
        kubectl apply -f ingress-path.yamlcurl http://myapp.timinglee.org/v1   # Version: v1
curl http://myapp.timinglee.org/v2   # Version: v2

        此时直接访问是不行的，因为没有设定默认发布目录

        可以设定一下

        5.3 基于域名的多业务入口

        # ingress-domain.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-domain
spec:ingressClassName: nginxrules:- host: myappv1.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v1, port: {number: 80}}- host: myappv2.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v2, port: {number: 80}}
        kubectl apply -f ingress-domain.yamlcurl http://myappv1.timinglee.org   # Version: v1
curl http://myappv2.timinglee.org   # Version: v2

        子集写在最前面也行，写最后面也行

        此时我们

        5.4 HTTPS（TLS）一键启用

        5.4.1 自签证书 & Secret
        openssl req -x509 -newkey rsa:2048 -nodes -keyout tls.key -out tls.crt -days 365 \-subj "/CN=myapp-tls.timinglee.org"kubectl create secret tls web-tls-secret --cert=tls.crt --key=tls.key
        5.4.2 启用 TLS 的 Ingress
        # ingress-tls.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-tls
spec:ingressClassName: nginxtls:- hosts: [myapp-tls.timinglee.org]secretName: web-tls-secretrules:- host: myapp-tls.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v1, port: {number: 80}}
        kubectl apply -f ingress-tls.yamlcurl -k https://myapp-tls.timinglee.org   # HTTPS 成功

        生成证书去加密

        设置非交互式输入

        此时生成的证书与集群无关

        把证书变成资源，能被集群调用

        里面有两个文件

        查看资源信息，它们以键值的方式保存了

        要把加密的模式保存到配置文件中去

        一次性可以给多个设备加密 host

        最终要调用的资源里的证书

         

        查看新建的ingress的详细情况，是否加密成功

        此时直接访问已经不行了

        https:// 表示使用 HTTPS 协议 访问，符合 Ingress 配置中强制 HTTPS 的要求，因此不会被重定向。
        -k 参数的作用是 跳过 SSL 证书验证。如果你的 Ingress 使用的是自签名证书（而非可信 CA 颁发的证书），curl 会默认验证证书并报错（如 SSL certificate problem）。加上 -k 后会忽略证书验证，从而成功建立连接并获取响应。

        5.5 Basic Auth 用户认证

        5.5.1 生成密码文件并写入 Secret
        dnf install -y httpd-tools
htpasswd -cm auth lee        # 输入两次密码
kubectl create secret generic auth-web --from-file=auth
        5.5.2 在 Ingress 中开启认证
        # ingress-auth.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: ingress-authannotations:nginx.ingress.kubernetes.io/auth-type: basicnginx.ingress.kubernetes.io/auth-secret: auth-webnginx.ingress.kubernetes.io/auth-realm: "Please input username and password"
spec:ingressClassName: nginxtls:- hosts: [myapp-tls.timinglee.org]secretName: web-tls-secretrules:- host: myapp-tls.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v1, port: {number: 80}}

        用户级别的访问限制

        此时的文件还是没有关系和集群

        要通过这个命令，把这个叫做htpasswd的文件抽象成集群中的资源

        编辑配置文件，要用到参数

        在调用时，也会验证这些参数

        错误情况：

        这里会错误，是因为他默认调用auth这个名字，而之前创建用户密码时，储存的文件名不是它，系统此时访问不了

        修改名字：

        删除之前储存的资源

        重新建立资源

        删除之前运行的配置文件

        重新运行一次就行了

        kubectl apply -f ingress-auth.yamlcurl -k https://myapp-tls.timinglee.org          # 401 Unauthorized
curl -k -u lee:lee https://myapp-tls.timinglee.org   # 200 OK

        5.6 URL 重写（Rewrite）与正则

        5.6.1 根路径重定向
        nginx.ingress.kubernetes.io/app-root: /hostname.html
        5.6.2 正则捕获与重写
        # ingress-rewrite.yaml
metadata:annotations:nginx.ingress.kubernetes.io/use-regex: "true"nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:rules:- host: myapp-tls.timinglee.orghttp:paths:- path: /lee(/|$)(.*)          # 匹配 /lee 或 /lee/xxxpathType: ImplementationSpecificbackend:service: {name: myapp-v1, port: {number: 80}}
        curl -k -u lee:lee https://myapp-tls.timinglee.org/lee/hostname.html
# 实际返回 /hostname.html 内容

        匹配正则表达式

        测试：

        六、金丝雀（Canary）发布

        6.1 核心思路

        • 先少量、后全量：降低新版本全量故障风险

        • Ingress-Nginx 支持 Header / Cookie / 权重 三种灰度策略

        • 发布过程 只增不减：Pod 总数 ≥ 期望值，业务无中断

        6.2 基于 Header 的灰度

        6.2.1 正式流量 Ingress（v1）
        # myapp-v1-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: myapp-v1-ingress
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v1, port: {number: 80}}

        部署老版本的

        升级后的访问是要基于什么情况下访问

        要写参数来设置了

        当携带timinglee的值是6时，就访问new的

        6.2.2 灰度流量 Ingress（v2）
        # myapp-v2-canary-header.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: myapp-v2-canaryannotations:nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "version"nginx.ingress.kubernetes.io/canary-by-header-value: "2"
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- path: /pathType: Prefixbackend:service: {name: myapp-v2, port: {number: 80}}
        kubectl apply -f myapp-v1-ingress.yaml
kubectl apply -f myapp-v2-canary-header.yaml# 测试
curl http://myapp.timinglee.org                # v1
curl -H "version: 2" http://myapp.timinglee.org # v2

        6.3 基于权重（Weight）的灰度

        # myapp-v2-canary-weight.yaml
metadata:annotations:nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"   # 10%nginx.ingress.kubernetes.io/canary-weight-total: "100"
        kubectl apply -f myapp-v2-canary-weight.yaml# 100 次采样脚本
for i in {1..100}; do curl -s myapp.timinglee.org | grep -c v2; done | awk '{v2+=$1} END{print "v2:"v2", v1:"100-v2}'
# v2:10, v1:90   # 符合 10% 权重

        脚本测试：

        测试没有问题了

        就修改权重

        直到最后没有问题，old的版本就可以删除了

        调整权重只需修改 annotation 后 kubectl apply，即可实现 平滑全量滚动。

        七、一键清理

        kubectl delete ingress --all
kubectl delete svc --all -l app=myapp-v1,app=myapp-v2
kubectl delete deploy --all -l app=myapp-v1,app=myapp-v2

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

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

        相关文章

        Pandas 2.0 + Arrow 加速、Dask vs Ray、Plotly 可视化：数据分析的未来

        Pandas 2.0 + Arrow 加速、Dask vs Ray、Plotly 可视化：数据分析的未来

        在大数据与人工智能时代，数据分析与可视化的技术栈正在快速演进。过去十年，Pandas 几乎是数据科学家的“瑞士军刀”，Matplotlib 和 Seaborn 是最常用的可视化工具。但如今，随着数据规模与分析需求的增长，新的趋势正在出现： Pandas 2.0 引入 Apache Arrow 后端，性能显著提…
        阅读更多...
        windows扩展（外接）显示器位置调节

        windows扩展（外接）显示器位置调节

        概述有的时候我们想把屏幕往左或往右拖动&#xff0c;默认情况下&#xff0c;屏幕都是默认往右拖动的&#xff0c;如果想往左拖动&#xff0c;则需要进行设置。具体步骤如下&#xff1a;当然不止这些还可以往上调&#xff0c;下调等多个位置可调至&#xff0c;这里只显示左右调…
        阅读更多...
        【分数求和2】

        【分数求和2】

        题目&#xff1a;分数求和&#xff08;1/22/33/44/55/66/77/88/9&#xff09;代码实现&#xff1a;#include <stdio.h>int main(){double sum 0.0;int i;for(i2;i<10;i){sum((i-1.0)/i);}printf("1/22/33/44/55/66/77/88/9%f\n",sum);return 0;} 注&#x…
        阅读更多...
        软件SPI实现（3）：SPI协议测试（使用W25Q64）

        软件SPI实现（3）：SPI协议测试（使用W25Q64）

        0 参考资料 SPI通信协议中文版(SPIV3).pdf 1 SPI协议测试（使用W25Q64） 1.1 测试方法 这里使用W25Q64作为SPI从机，测试实现的软件SPI工作是否正常。测试步骤如下： （0）使用SPI模式0 （1）使用sw_spi_tx_rx_nbyte API向W25Q64起始地址0写入32字节数据 （2）使用sw_spi_tx_…
        阅读更多...
        Redis 04 Reactor

        Redis 04 Reactor

        Reactor 设计模式是事件驱动的并发处理模式&#xff0c;高效处理多个输入源的请求。多路分解事件&#xff0c;同步分发到处理器。 单线程 reactor 模型 redis6.0 之前采用单线程 reactor 模型。即业务线程完成网络IO及命令处理。 reactor 模型处理三类事件&#xff1a; 连接事件…
        阅读更多...
        基于多分类的工业异常声检测及应用

        基于多分类的工业异常声检测及应用

        摘 要 随着工业4.0的快速发展&#xff0c;工业设备的智能化监测与维护成为保障生产安全与效率的关键环节。工业异常声检测作为一种非侵入式、实时性强的监测手段&#xff0c;能够有效识别设备运行中的潜在故障&#xff0c;具有重要的应用价值。本文提出了一种基于多分类的工业…
        阅读更多...
        AirReceiverLite：轻松实现手机隔空投屏

        AirReceiverLite：轻松实现手机隔空投屏

        在多设备互联的今天&#xff0c;屏幕镜像功能成为了许多用户在演示、教学、娱乐等场景中的重要需求。AirReceiverLite作为一款运行在Android平台上的应用程序&#xff0c;为用户提供了便捷的解决方案。它允许用户通过AirPlay协议将iPhone、iPad、Macbook等iOS设备以及Windows P…
        阅读更多...
        双指针和codetop复习

        双指针和codetop复习

        双指针和codetop复习1.双指针1.[移动零](https://leetcode.cn/problems/move-zeroes/description/)递归1.[计算布尔二叉树的值](https://leetcode.cn/problems/evaluate-boolean-binary-tree/)2.[Pow(X,n)](https://leetcode.cn/problems/powx-n/)3.[两两交换链表中的节点](htt…
        阅读更多...
        抽丝剥茧丨PostgreSQL 系国产数据库%SYS CPU newfstatat() high 调优一例（一）

        抽丝剥茧丨PostgreSQL 系国产数据库%SYS CPU newfstatat() high 调优一例（一）

        最近一个客户从 Oracle 迁移到 PostgreSQL 系的国产数据库后&#xff0c;CPU一直接近100%&#xff0c;但是再仔细分析&#xff0c;发现%system CPU占到60%左右&#xff0c;当然这是一种不正常的现象。之前我写过《如何在 Linux 上诊断高%Sys CPU》&#xff08;https://www.anbo…
        阅读更多...
        [Linux] Linux提权管理 文件权限管理

        [Linux] Linux提权管理 文件权限管理

        目录 Linux提权管理 su命令 准备一个用户 sudo命令 sudo配置 Linux文件权限管理 文件系统权限介绍 rwx 权限解读 文件系统权限管理 chmod 命令 针对文件 针对目录 chown chgrp 命令 验证文件权限rwx效果 验证目录权限rwx效果 权限补充说明 管理文件默认权限 u…
        阅读更多...
        Kubernetes（2）pod的管理及优化

        Kubernetes（2）pod的管理及优化

        【一】Kubernetes 资源管理与操作方式 1.1 资源管理介绍 Kubernetes 把一切抽象为“资源”&#xff0c;用户通过操作资源来管理集群。 集群中运行服务 运行容器&#xff0c;而容器必须放在 Pod 内。 最小管理单元是 Pod&#xff0c;但通常不直接操作 Pod&#xff0c;而是借…
        阅读更多...
        深入剖析 TOTP 算法：基于时间的一次性密码生成机制

        深入剖析 TOTP 算法：基于时间的一次性密码生成机制

        标准原文&#xff1a;https://datatracker.ietf.org/doc/html/rfc6238 在数字化时代&#xff0c;信息安全至关重要&#xff0c;身份验证成为保障系统和数据安全的第一道防线。传统的用户名加密码方式已难以应对日益复杂的安全挑战&#xff0c;基于时间的一次性密码&#xff08;…
        阅读更多...
        Centos7 服务管理

        Centos7 服务管理

        注&#xff1a;从Centos7开始systemd代替了init&#xff0c;使用systemd机制来管理服务优势&#xff1a;并行处理所有服务&#xff0c;加速开机流程命令相对简单&#xff1a;所有操作均有systemctl命令来执行服务依赖性检测&#xff1a;systemctl命令启动服务时会自动启动依赖服…
        阅读更多...
        数据库索引视角：对比二叉树到红黑树再到B树

        数据库索引视角：对比二叉树到红黑树再到B树

        当我们谈论数据库索引时&#xff0c;选择合适的数据结构至关重要。不同的数据结构在性能、复杂度以及适用场景上都有所不同。本文将通过对比二叉树、红黑树和B树&#xff0c;探讨它们如何影响数据库索引的表现。一、二叉树特性定义&#xff1a;每个节点最多有两个子节点。应用场…
        阅读更多...
        Redis-plus-plus 安装指南

        Redis-plus-plus 安装指南

        &#x1f351;个人主页&#xff1a;Jupiter.&#x1f680; 所属专栏&#xff1a;Redis 欢迎大家点赞收藏评论&#x1f60a;目录1.安装 hiredis2.下载 redis-plus-plus 源码3.编译/安装 redis-plus-plusC 操作 redis 的库有很多. 此处使⽤ redis-plus-plus.这个库的功能强⼤, 使…
        阅读更多...
        vue3动态的控制表格列的展示简单例子

        vue3动态的控制表格列的展示简单例子

        动态的控制表格列的展示&#xff0c; 可以勾选和取消某一列的显示本地存储上一次的配置表格内容支持通过slot自定义内容例子1 <script setup> import { reactive, ref, watch } from "vue"; import one from "./components/one.vue"; import One fro…
        阅读更多...
        微积分[4]｜高等数学发展简史（两万字长文）

        微积分[4]｜高等数学发展简史（两万字长文）

        文章目录前言解析几何学微积分学级数理论常微分方程&#xff5c;(1) 萌芽阶段&#xff5c;(2) 初创阶段&#xff5c;(3) 奠基阶段&#xff5c;(4) 现代发展阶段前言 高等数学通常仅是相对初等数学而言的&#xff0c;其内容并无身份确切的所指&#xff0c;大凡初等数学以外的数…
        阅读更多...
        系统思考—啤酒游戏经营决策沙盘认证

        系统思考—啤酒游戏经营决策沙盘认证

        下周&#xff0c;我们将为企业交付——《啤酒游戏经营决策沙盘—应对动态复杂系统的思考智慧》内部讲师认证课。啤酒游戏沙盘&#xff0c;我已交付过上百场。但这次的讲师认证班&#xff0c;不仅仅是分享课程技巧&#xff0c;更多的是分享“心法”。有些关键点&#xff0c;直到…
        阅读更多...
        深入详解PCB布局布线技巧-去耦电容的摆放位置

        深入详解PCB布局布线技巧-去耦电容的摆放位置

        目录 一、基础概念与核心作用 二、布局五大黄金原则 三、模拟电路的特殊处理 四、高频场景优化方案 和旁路电容是保障电源稳定性和信号完整性的核心元件。尽管它们的原理和作用常被讨论，但实际布局中的细节往往决定成败。 一、基础概念与核心作用 去耦电容：主要用于抑制…
        阅读更多...
        布隆过滤器的原理及使用

        布隆过滤器的原理及使用

        背景介绍在互联网中&#xff0c;我们经常遇到需要在大量数据中判断目标数据是否存在的情况。例如&#xff0c;在网络爬虫中&#xff0c;我们需要判断某个网址是否已经被访问过。为了实现这一功能&#xff0c;通常需要使用一个容器来存储已访问过的网址。如果将这些数据直接存储…
        阅读更多...
        最新文章

        Copyright @ 2022~2023