• 自动秒收录
  • 软件:1973
  • 资讯:57811|
  • 收录网站:279872|

IT精英团

举例说明库伯内特公司的豆荚核心资源

举例说明库伯内特公司的豆荚核心资源

浏览次数:
评论次数:
编辑: 乐咏
信息来源: ITPUB
更新日期: 2022-09-06 15:53:50
摘要

目录一、Pod定义二、Pod入门yaml描述文件三、共享NetworkNamespace四、共享PID五、容器生命周期六、初始化容器6.1、简介6.2、与普通容器的区别6.3、实验七、Pod探针7.1

  • 正文开始
  • 相关阅读
  • 推荐作品

目录、Pod定义II、Pod yaml说明III、共享网络名称空间IV、共享PID V、容器生命周期VI、初始化容器6.1、简介6.2、与普通容器的区别6.3、实验VII、Pod Probe 7.1、livenessProbe7.2、readinessProbe7.3、startupProbe VIII、退出Pod进程9、HPA9.1、简介9.2、使用10、静态Pod10.1、简介10.2、实验11、更多Pod属性12、比较DockerCompose

推荐手机阅读原文:https://mp.weixin.qq.com/s/nR6P6eidE1r5A2viLCFHWA

推荐手机阅读:https://mp.weixin.qq.com/s/nR6P6eidE1r5A2viLCFHWA

推荐手机阅读:https://mp.weixin.qq.com/s/nR6P6eidE1r5A2viLCFHWA

00-1010如下图,K8S中资源调度的基本单位是Pod。

其实Pod是一个抽象的概念。Pod中是我们的业务容器(docker/containerd)。由资源调度对象如Deployment、StatefulSet和CronJob调度的资源都是Pod。

为了更好的理解Pod的概念,我们可以把Pod理解为一个VM虚拟机,把Pod中的容器理解为VM中的一个进程。这种理解意味着Pod中的容器进程可以通过localhost端口号直接互相通信,也意味着Pod中的容器可以达到互相直接读取输出到磁盘的文件的类似效果。

如上图:容器1访问:127.0.0.133608082可以访问容器2。

在实际应用中,比如我们有两个服务:服务A和服务B,它们只能通过本地环回网卡相互通信,所以我们现在应该把它们分配到同一个pod上。

什么是资源调度?简单来说,我们会:为Pod选择一个合适的物理节点,然后启动Pod中的容器对外提供服务。

00-1010简单,只需在Pod资源对象的containers字段中填充我们想要启动的Docker容器,然后通过kubectl命令创建Pod即可。K8S会为Pod选择一个合适的节点,并在这个节点上启动用户指定的容器。

下面是Pod的一个Yaml描述文件,其中定义了两个容器:nginx和shell。

ApiVersion: v1 #必需,API的版本号

Kind: Pod #必需,Pod类型

元数据: #必需,元数据

名称:demon-Pod #是必需的,这是符合RFC 1035的Pod名称。

spec:

集装箱:

-名称: nginx

Image :nginx3360latest #必需,容器使用的镜像的地址。

-名称:外壳

图: busybox

stdin: true

tty: true

使用kubectl命名Pod,您可以看到就绪号2和节点字段。

说明该Pod运行在叫node02的宿主机上

验证,找到node02

登录node02,查看node02上是否有相应的docker容器

可以看到K8S不光启动了nginx、busybox容器,还多启动一个叫pause的容器,大家也叫它infra容器。

Infra容器的作用:Pod中的所有容器会共享一个NetworkNamespace,因为在创建pod中的业务容器前,会先创建pause容器占用NetworkNamespace,后续创建的业务容器都加入到pause的网络中,相当于在Docker run命令中添加参数:--net=container:pause,这也是为什么Pod中的所有容器的ip其实都是pod的ip。

如下图,进入shell容器中,看到它的ip其实就是上图中的pod ip。

在nginx容器中,也能看到容器的ip就是pod的ip

三、共享NetworkNamespace#

如下图是K8S创建Pod时,Pod的网络协议栈的初始化过程

简单解读,理解pause容器是K8S网络模型中的精髓~

  1. kubelet通过CRI协议向底层的容器运行时(docker/containerd)下发命令,让它创建一个叫pause 的初始化容器,这个pause容器里运行着一个极简的C程序,具体的逻辑就是将自己阻塞中,目的是让pause容器快速占用并一直持有一个networkname
  2. 创建pause容器时,会携带参数--net=node意为不初始化网络协议栈,说白了就是除了自带的lo回环网卡外,不添加其他的网卡。
  3. kubelet通过CNI协议为pause容器初始化网络协议,也就是给它添加网络并分配IP
  4. Pod中定义的业务容器都加入pause容器的network namespace,它们都使用统一分配给pause的IP

疑问:为什么pause容器的网络协议栈不由容器运行时创建它时立即分配好呢?

答:这是个好问题,这么做也是呼应了K8S网络的核心目标思想:

  1. IP分配,换句话说K8S要保证在整个集群中每个POD要独立不重复的IP地址

  2. IP路由,换句话说K8S要保证在整个集群中各个POD的IP是要互通的

这也是它为什么设计这个流程的原因

四、共享PID#

默认情况下Pod中的各容器是不会共享同一个统一个PID Namespace的,需要手动添加参数shareProcessNamespace: true

apiVersion: v1  kind: Pod       metadata:         name: daemon-pod   spec:  # 共享pid namespace  shareProcessNamespace: true  containers:  - name: nginx    image: nginx:latest      - name: shell    image: busybox    stdin: true    tty: true

验证:如下图,在shell容器中可以看到nginx进程(通过这更好的将pod理解成虚拟机),同理登陆pod重点任意容器也能看到pid=1的进程是pause进程。

此时pause容器为Pod提供1号进程,在Uninx中,进程为1的进程被称作init进程。

这个init进程很特殊,因为它会维护一张进程表并不断的检测其他进程的状态,当出现:子进程因父进程的异常退出而变成“孤儿进程”或者是叫“僵尸进程”时,init进程(pause)会收养这个游离的进程,然后在它退出时,释放它占用的资源,否则会可能会出现大量的僵尸进程占用操作系统的进程表项。

在k8s1.8之前,默认是启用共享pid namespace

在k8s1.8之后,则需要像本小节一样,通过参数shareProcessNamespace显示的开启

问:既然共享了pause的pid有这么多好处,为啥后续版本的k8s不再默认开启了呢?

答:一方面:k8s推荐的做法是,单个pod里面放尽量少的容器,如只放你的业务容器,这样僵尸进程带来的影响几乎可以忽略不计,共享与不共享,意义不大。

另一方面:像一些特殊的如systemd镜像,启动需要获取pid1,否则无法启动

五、容器生命周期#

可以通过lifecycle字段在容器创建完成后以及关闭前执行指定的动作,如创建用户/创建目录,启动脚本等

apiVersion: v1 kind: Pod    metadata:     name: nginx   spec:   containers:    - name: nginx     image: nginx:latest     lifecycle:      postStart: # 容器创建完成后执行的指令, 可以是exec httpGet TCPSocket        exec:          command:          - sh          - -c          - 'mkdir /data/ '      preStop: # 关闭前的操作        httpGet:                    path: /              port: 80      #  exec:      #    command:      #    - sh      #    - -c      #    - sleep 9  restartPolicy: Always

spec.containers.lifecycle.postStart参数可以指定容器在创建完成后执行一段指令

回忆一下,容器还有个command参数即:spec.containers.command也可以指定一段指令。注意点如下:

  • 这俩command执行的先后并不能100%保证。
  • spec.containers.lifecycle.postStart的执行依赖于容器创建后的环境

spec.initContainers.command的不会依赖业务容器的环境,执行时间也会先于如上两个command。

六、初始化容器#

6.1、简介#

业务容器的启动依赖很多环境配置,如:

  • wget等可以从网络上下载文件的命令
  • 或者是有些命令需要以root的权限运行初始化,如修改文件的权限、修改内核参数

如果有攻击性的程序获得了使用这些命令的权限,就会有很大的安全隐患,为了安全,我们是不希望业务容器中包含这些危险的命令。

这时可以使用initcontainer完成这种工作,因为initcontainer运行结束后会退出,没有后续的安全隐患。

6.2、与普通容器的区别#

  • 初始化容器会依次执行,上一个运行结束,下一个才会执行。
  • 初始化容器不成功结束,不会启动业务容器,K8S会不断的重启该Pod。但是如果Pod的restartPolicy设置为Never,K8S就不再重启该Pod了。
  • init容器不支持:lifecycle、livenessProbe、readinessProbe、startupProbe探针

6.3、实验#

准备yaml,initContainer和业务容器共享挂载volume的方式,让业务容器共享initContainer的初始化文件

apiVersion: apps/v1kind: Deploymentmetadata:  creationTimestamp: null  labels:    app: test-init-container  name: test-init-containerspec:  replicas: 1  selector:    matchLabels:      app: test-init-container  strategy: {}  template:    metadata:      creationTimestamp: null      labels:        app: test-init-container    spec:      volumes:      - name: data        emptyDir: {}      initContainers:      - name: init01        image: busybox        volumeMounts:        - name: data          mountPath: /tmp        command:        - sh        - -c        - touch /tmp/test-init-container.txt      containers:      - image: nginx        name: nginx        volumeMounts:        - name: data          mountPath: /tmp

查看Pod执行的Event可以看到先执行了初始化容器的相关操作

[root@master01 initContainer]# kubectl describe pod test-init-container-79d689d7d8-fgz2s... Events:  Type    Reason     Age    From               Message  ----    ------     ----   ----               -------  Normal  Scheduled  6m47s  default-scheduler  Successfully assigned default/test-init-container-79d689d7d8-fgz2s to master01  Normal  Pulling    6m47s  kubelet            Pulling image "busybox"  Normal  Pulled     6m43s  kubelet            Successfully pulled image "busybox" in 3.781619189s  Normal  Created    6m43s  kubelet            Created container init01  Normal  Started    6m43s  kubelet            Started container init01  Normal  Pulling    6m42s  kubelet            Pulling image "nginx"  Normal  Pulled     6m11s  kubelet            Successfully pulled image "nginx" in 31.093619016s  Normal  Created    6m11s  kubelet            Created container nginx  Normal  Started    6m11s  kubelet            Started container nginx

验收

[root@master01 initContainer]# kubectl exec -ti test-init-container-79d689d7d8-fgz2s -- shDefaulted container "nginx" out of: nginx, init01 (init)# ls /tmptest-init-container.txt

七、Pod探针#

名称作用引入版本
startupProbe1. 用于判断容器内的应用进程是否成功启动。
2. 若配置了startupProbe。直到它检测通过前,会禁用其他探针
3. startupProbe检测未通过,会使用restartPolicy重启策略重启
4. startupProbe探测成功后将不再探测。
1.16
readinessProbe1. 用户探测容器内的程序是否健康,是否可以接收流量
2. 探测成功表示该容器已经完全启动,可接收流量。
3. 若未配置,默认返回success
livenessProbe1. 用于判断容器是否运行
2. 若探测失败kubelet根据重启策略重启容器
3. 若未配置,默认返回success

检测方式一:ExecAction

原理如下:执行一个脚本,返回0表示成功,返回非0表示异常

[root@master01 yamls]# touch 1[root@master01 yamls]# cat 1[root@master01 yamls]# echo $?0[root@master01 yamls]# cat 123123.txtcat: 123123.txt: 没有那个文件或目录[root@master01 yamls]# echo $?1
#!/bin/bash#K8S 的存活探针function liveness(){    result=`nmap 127.0.0.1 -p $Target_PORT | grep $Target_PORT/tcp | awk '{print $2}'`    if [ "$result" != "open" ];then        echo 'port not open'        return 1    fi}                    liveness

检测方式二:TcpSocketAction

通过Tcp连接检查容器内的端口是否是连通的,如果连通,认为容器健康。原理如下:

# 连通的情况[root@master01 yamls]# telnet 10.10.10.101 2380Trying 10.10.10.101...Connected to 10.10.10.101.Escape character is '^]'.^CConnection closed by foreign host.# 非连通的情况[root@master01 yamls]# telnet 10.10.10.101 2381Trying 10.10.10.101...telnet: connect to address 10.10.10.101: Connection refused

检测方式三:HttpGetAction

通过应用程序暴露的Http接口,来检查应用程序是否健康,若返回的状态码在[200,400)之间,认为程序健康。

7.1、livenessProbe#

目的:判断容器是否启动了,检测失败后会重启容器

参考

livenessProbe:      failureThreshold: 5      httpGet:        path: /health        port: 8080        scheme: HTTP      initialDelaySeconds: 60      periodSeconds: 10      successThreshold: 1      timeoutSeconds: 5

7.2、readinessProbe#

目的:探测容器中的应用是否是正常的

检测通过:表示应用可以接收流量,READY状态变成1/1

[root@master01 yamls]# kubectl get podNAME    READY   STATUS    RESTARTS   AGEnginx   1/1     Running   0          54s

检测失败,READY状态变成0/1,且RESTARTS且0,表示不会重启容器

[root@master01 yamls]# kubectl get podNAME    READY   STATUS    RESTARTS   AGEnginx   0/1     Running   0          54s

参考

readinessProbe:      failureThreshold: 3      httpGet:        path: /ready        port: 8181        scheme: HTTP      periodSeconds: 10      successThreshold: 1      timeoutSeconds: 1

7.3、startupProbe#

在有了livenessProbe和readinessProbe之后,为啥还整一个startupProbe出来呢?

可用来应对极端情况:应用启动时各种加载配置,导致启动的特别慢。 最终导致livenessProbe检查失败,当livenessProbe检查失败时,k8s会重启容器。 重启之后应用启动还是慢,livenessProbe还是失败,就进入了死循环

startupProbe其实就是将等待探测应用正常启动的步骤从livenessProbe中提取出来,放在livenessProbe步骤前。若配置了startupProbe,livenessProbe和readinessProbe会先被禁用,等startupProbe通过后,livenessProbe和readinessProbe才会生效。

实验:

apiVersion: v1  # 必选,API的版本号kind: Pod       # 必选,类型Podmetadata:       # 必选,元数据  name: nginx   # 必选,符合RFC 1035规范的Pod名称spec:   # 必选,用于定义容器的详细信息  containers:   # 必选,容器列表  - name: nginx # 必选,符合RFC 1035规范的容器名称    image: nginx:latest    # 必选,容器所用的镜像的地址    ports:  # 可选,容器需要暴露的端口号列表    - name: http          # 端口名称,如果需要暴露多个端口,需要保证每个port的name不能重复      containerPort: 80 # 端口号      protocol: TCP     # 端口协议,默认TCP    startupProbe:       httpGet:  # httpGet检测方式,生产环境建议使用httpGet实现接口级健康检查,健康检查由应用程序提供。        path: /api/successStart # 检查路径        port: 80  restartPolicy: Always 

因为没有/api/successStart接口,所以startupProbe检测不通过

如下:pod的status为running,但是Ready为0

[root@master01 yamls]# kubectl get podNAME    READY   STATUS    RESTARTS   AGEnginx   0/1     Running   0          19s

查看详情:

startupProbe会按照继续按策略探测,当失败的次数达到预期后,会重启,如下重启了4次了

[root@master01 yamls]# kubectl get podNAME    READY   STATUS             RESTARTS      AGEnginx   0/1     CrashLoopBackOff   4 (27s ago)   2m57s

可以将HttpGet检测方式换成TcpSocket去检测80端口,startupProbe校验即可通过

apiVersion: v1 kind: Pod       metadata:         name: nginx   spec:    containers:    - name: nginx    image: nginx:latest       startupProbe:       tcpSocket:        port: 80  restartPolicy: Always 
[root@master01 yamls]# kubectl get podNAME    READY   STATUS    RESTARTS   AGEnginx   1/1     Running   0          14s

八、Pod退出流程#

当我们关闭或者删除pod时,Pod的状态会变成:Terninating

[root@master01 yamls]# kubectl get podNAME    READY   STATUS     RESTARTS   AGEnginx   0/1     Terninating   0          2m16s

另外你会发现,执行delete命令时,会等待一段时间

[root@master01 yamls]# kubectl delete pod nginxpod "nginx" deleted

这个等待的时间是k8s给pod留出来的一段宽限期,可以通过kubectl edit pod xxx查看pod的配置,默认情况下有一个叫terminationGracePeriodSeconds: 30的参数,值为30秒,表示在pod被delete之后,有30秒的宽限期。

在这个宽限期中会做收尾的工作如:

  • 将pod所属的service的endpoint对应记录删除
  • 执行lifecycle 的 preStop 定义的命令

上文说过lifecycle,重新贴出来,如下:

lifecycle:      postStart: # 容器创建完成后执行的指令, 可以是exec httpGet TCPSocket        exec:          command:          - sh          - -c          - 'mkdir /data/ '      preStop: # 容器关闭前的操作        httpGet:                    path: /              port: 80        exec:          command:          - sh          - -c          - sleep 9

九、HPA#

9.1、简介#

全称:Horizontal Pod Autoscaler

可以根据CPU、内存使用率或者是自定义的指标完成对Pod的自动扩缩容

查看K8S集群的HPA相关API

  • v1版本是稳定版,只支持CPU指标
    • v2beta1支持CPU、内存、自定义指标
  • v2beta2支持CPU、内存、自定义指标、额外指标ExternelMetrics(公有云厂商提供)

9.2、使用#

使用限制:

  • 不能对如DaemonSet类型的资源进行扩所容。
  • 必须安装了metrics-server
  • 必须配置requests参数

准备测试环境

# 创建模版yamlkubectl create deployment nginx-dp --image=nginx --dry-run=client -oyaml > nginx-dp.yaml# 更新resources      containers:      - image: nginx        name: nginx        resources:          requests:            cpu: 10m# 创建deploymentkubectl apply -f nginx-dp.yaml# 查看pod的CPU指标[root@master01 yamls]# kubectl top podNAME                        CPU(cores)   MEMORY(bytes)busybox                     0m           0Minginx-dp-84c4fd8fc6-s7mnx   0m           6Mi# 为dp暴露一个servicekubectl expose deployment nginx-dp --port=80

可以通过如下命令使用HPA

# 当CPU使用率超过10%就扩容,扩容最大数Pod数为10,最小数为1kubectl autoscale deployment nginx-dp --cpu-percent=10 --min=1 --max=3

压测,可以观察到pod会被自动扩容

while true; do wget -q -O- http://192.168.217.66 > /dev/null;done

注意点:如果CPU或者是Memory的飙升的源头是数据库压力,那么我们对pod进行扩容不仅没有好转,返回适得其反。

十、静态Pod#

10.1、简介#

静态Pod是由kubelet直接管理的,且只能在该kubelet所在的Node上运行。

静态Pod不受ApiServer管理,无法与ReplicationController、Deployment、DaemonSet进行关联。

kubelet也无法对静态Pod进行健康检查。

有两种方式创建静态Pod,分别是使用:静态文件/Http,若使用静态配置文件创建pod,需要在kubelet的启动参数statucPodPath中指定静态Pod的yaml描述文件的位置。

10.2、实验#

只要将pod的yaml文件放入指定的目录中,过一会便能通过kubectl查看到pod。

尝试通过kubectl删除Pod,会一直处于pending状态,这是因为kubectl会通过apiserve

r下发删除的命令,而apiserver无法管理静态pod。故,若想删除静态Pod,需要将对应的pod的yaml文件移出statucPodPath

十一、更多Pod属性#

十二、对比DockerCompose、DockerSwarm#

像Docker公司推出的集群调度工具:Docker Compose或是Docker Swarm它们调度的基本单位都是Docker容器。

点击查看白日梦的笔记:玩转Docker容器调度-DockerCompose、DockerSwarm

而在K8S中集群调度的基本单位是上文中长篇介绍的Pod,他们两者维度是不同的。Pod显然是站在更高的维度上。

因为在容器编排领域中,难点不是为容器选择一个合适的节点然后将容器启动好。难点是解决应用间复杂的相互依赖关系。

比如下:

  • 不同应用之间通过本地文件相互通信
  • 不同应用之间通过Http协议/RPC协议相互通信
  • 不同应用之间通过localhost+端口号互通
  • 在所有宿主机上均启动一个Pod副本

前文说了,大家可以把Pod理解成传统意义上的虚拟机,Pod中的容器相当于虚拟机中的不同应用,Pod中有哪些容器由开发人员说了算。

这样其实就是变相的将容器编排最为复杂环节的皮球重新踢给了开发人员,由他们自己描述好,也就实现了天然的解决了应用的复杂依赖关系编排这一难点。K8S调度时也要以Pod为基本单位去选择一个相对合适宿主机,批量的启动好Pod中的容器就行。

十三、参考#

Kubernetes官网

《Kubernetes权威指南》

《Kubernetes网络原理与实践》

标签:容器 进程 重启
如何在C#程序中注入恶意DLL?
« 上一篇 2022-09-06
百度工程师教你玩设计模式(工厂模式)
下一篇 » 2022-09-06
  • 如何在Ubuntu中保留文件系统并备份当前开发板镜像
    0阅读 0条评论 个赞
    在Ubuntu保留文件系统或者说备份当前开发板镜像的需求在不断增加。比如Ubuntu文件系统需要安装库文件的话直接使用apt-get工具就可以下载,但由于需要下载的核心板较多,比较费时间,这时需要将安……
  • 国产核心板全志T507助力消防系统升级
    0阅读 0条评论 个赞
    9月16日下午,位于湖南长沙市区内的中国电信大楼发生火灾,建筑高度218米,现场浓烟滚滚,数十层楼体燃烧剧烈。消防救援人员赶到现场后很快将火势控制住,目前大楼火势已被扑灭,所幸未发现人员伤亡。湖南电信……
  • 教大家如何处理Spring Boot易流中的用户和群体!
    0阅读 0条评论 个赞
    1.准备工作2.用户操作2.1添加用户2.2修改用户2.3删除用户2.4查询用户3.组操作3.1添加组3.2修改组3.3删除组3.4查询组4.查看表详情虽然说我们在实际开发中,……
  • 从PG15开始WAL压缩优化
    0阅读 0条评论 个赞
    PG15传闻中的超级令人激动的功能大多数跳票了,年初我也写过一个关于PG15新功能跳票的文章。PG15BETA已经发出几个月了,似乎PG15里令人激动人心的功能不多,不过从长长的新功能列表里,……
  • 深入了解美团叶子发射器开源方案
    0阅读 0条评论 个赞
    大家好,我是树哥。之前我们有聊过「如何设计一个分布式ID发号器」,其中有讲过4种解决方案,分别是:UUID类雪花算法数据库自增主键Redis原子自增美团以第2、3种解决方案为基础,开发出……
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
  • 如何在Ubuntu中保留文件系统并备份当前开发板镜像
    0阅读 0条评论 个赞
    在Ubuntu保留文件系统或者说备份当前开发板镜像的需求在不断增加。比如Ubuntu文件系统需要安装库文件的话直接使用apt-get工具就可以下载,但由于需要下载的核心板较多,比较费时间,这时需要将安……
  • 中国台湾的建设:有效登陆中国台湾的六脉神剑
    0阅读 0条评论 个赞
    在数字化时代,数字化体系的建设需要的是系统化的规划和产品化的迭代的模式,基于企业核心业务能力体系,做中台化的持续建设与落地,则是一种不错的选择。所以,企业业务中台的建设和落地,是关系到企业数字化战略成……
  • 全网最全Linux命令汇总!(史上最全 推荐收藏)
    7阅读 0条评论 个赞
    今天,给小伙伴们带来一篇史上最全Linux命令总结的文章,命令有点多,建议小伙伴们先收藏后阅读。好了,我们开始今天的正文。列出目录内容ls-a:显示所有文件(包括隐藏文件);ls-l:显示详细……
  • 1 Docker安装Nexus3
    0阅读 0条评论 个赞
    1.1创建目录在硬盘上创建Nexus3的主目录:mkdir-p/Users/yygnb/dockerMe/nexus3为该目录添加权限:chmod777-R/Users/yygnb/d……
  • 基于ASP.NET核心6.0的简洁架构
    0阅读 0条评论 个赞
    背景最近尝试录制了一个系列视频:《ASP.NETCore6.0+Vue.js3实战开发》,本节是视频内部整洁架构的理论和实战的文字稿。因为在录制之前,我通常会编写完整的文字内容作为视频文案,这……
  • Python自学教程7:字典类型有什么用
    0阅读 0条评论 个赞
    字典是Python中的一个重要操作,如果字典玩得顺,很多其他的数据类型就可以一通百通。Python字典的定义字典使用一对大括号进行定义,键值对之间使用逗号隔开,键和值使用冒号分隔。键必须是不可变类型,……
  • 能够在JAVA中自定义和扩展Swagger 自动生成参数值的含义 提高开发效率
    0阅读 0条评论 个赞
    大家好,又见面了。在JAVA做前后端分离的项目开发的时候,服务端需要提供接口文档供周边人员做接口的对接指导。越来越多的项目都在尝试使用一些基于代码自动生成接口文档的工具来替代由开发人员手动编写接口文档……
  • 基于iframe的微前端框架——青田
    33阅读 0条评论 个赞
    vivo互联网前端团队-JiangZuohan一、背景VAPD是一款专为团队协作办公场景设计的项目管理工具,实践敏捷开发与持续交付,以「项目」为核心,融合需求、任务、缺陷等应用,使用敏捷迭代、小……
  • [PostgreSql]生产级数据库安装需要考虑哪些问题?
    0阅读 0条评论 个赞
    大家好,我是字母哥(coder)!我让公司的小伙伴写一个生产级别的PostgreSQL的安装文档,结果他和我说:“不是用一个命令就能安装好么?还用写文档么?”。我知道他想说的是这个命令:yumins……
  • SQL Server操作系统的任务调度机制
    0阅读 0条评论 个赞
    简介SQLServerOS是在Windows之上,用于服务SQLServer的一个用户级别的操作系统层次。它将操作系统部分的功能从整个SQLServer引擎中抽象出来,单独形成一层,以便为存……
  • Python条件语句的用法
    0阅读 0条评论 个赞
    python条件语句使用if表达式,难度不高,需要注意的是嵌套用法,以及如何设置对应的条件。if条件判断语句python语句是按固定顺序执行的,先执行前面的语句,再执行后面的语句。如果你像要程……
  • 谈ASP.NET核心认证与授权
    0阅读 0条评论 个赞
    使用asp.netcore开发应用系统过程中,基本上都会涉及到用户身份的认证,及授权访问控制,因此了解认证和授权流程也相当重要,下面通过分析asp.netcore框架中的认证和授权的源码来分析……
  • i.MX8MQ自制背板无PCIe问题详解
    9阅读 0条评论 个赞
    在飞凌嵌入式OKMX8MQ-C开发板上有两个PCIe接口,对应着两个PCIe差分时钟,两路PCIe分别用作了M.2接口卡槽KEYE(P37)和KEYM(P34)。很多使用FETMX8MQ-C核心板的用……
  • 渗透攻击和防御网络-简单的SQL注入
    0阅读 0条评论 个赞
    1背景京东SRC(SecurityResponseCenter)收录大量外部白帽子提交的sql注入漏洞,漏洞发生的原因多为sql语句拼接和Mybatis使用不当导致。2手工检测2.1前置知识……
  • 记录一次数据库满CPU的故障排除过程
    0阅读 0条评论 个赞
    1前言近期随着数据量的增长,数据库CPU使用率100%报警频繁起来。第一个想到的就是慢Sql,我们对未合理运用索引的表加入索引后,问题依然没有得到解决,深入排查时,发现在orderbyida……
  • 让自己更有价值的5种能力
    0阅读 0条评论 个赞
    如何让自己更值钱?回答这个问题,需要用到黄金圈理论。什么是黄金圈理论?黄金圈理论,是国际知名营销专家、作家SimonSinek在2011年提出的,这是一种由内向外的思维模式。黄金圈理论提倡由Why、……
  • springboot集成docsify实现可移植文档
    0阅读 0条评论 个赞
    需求分析文档可以和项目一起进行版本管理文档可以在线访问文档可以与springboot项目集成,不需要分开部署MarkDown支持文档跟随,打包jar也可以访问技术选型对于网上已有的方案,大致分为如下几……
  • 一个没有写代码的案例 让我们看看Flowable为我们提供了哪些功能
    3阅读 0条评论 个赞
    其实松哥之前已经写过文章和大家介绍了flowable-ui的玩法了,这是官方提供的一个工具,这个工具不仅可以用来绘制流程图,还可以用来部署一个流程应用,通过这个流程应用我们可以体验一把flowa……
  • 国产核心板全志T507助力消防系统升级
    0阅读 0条评论 个赞
    9月16日下午,位于湖南长沙市区内的中国电信大楼发生火灾,建筑高度218米,现场浓烟滚滚,数十层楼体燃烧剧烈。消防救援人员赶到现场后很快将火势控制住,目前大楼火势已被扑灭,所幸未发现人员伤亡。湖南电信……
  • [设计模式] Java设计模式-工厂模式
    3阅读 0条评论 个赞
    目录【设计模式】Java设计模式-工厂模式简介1、普通工厂(SimpleFactory)模式①、定义类②、定义简单的工厂类③、实例2、抽象工厂(AbstractFactory)模式①、定义类②、……
最近发布资讯
更多