markdown方式绘图

使用markdown mermaid可快速绘制：流程图，时序图，甘特图等，程序员绘图必备技能

官方Demo

直接先看看效果

流程图

markdow

1
2
3
4
5
6

graph TD
A[Hard] -->|Text| B(Round)
B --> C{Decision}
C -->|One| D[Result 1]
C -->|Two| E[Result 2]

流程图效果

时序图

markdown

1
2
3
4
5
6
7
8
9
10

sequenceDiagram
Alice->>John: Hello John, how are you?
loop Healthcheck
    John->>John: Fight against hypochondria
end
Note right of John: Rational thoughts!
John-->>Alice: Great!
John->>Bob: How about you?
Bob-->>John: Jolly good!

时序图效果

甘特图

markdown

1
2
3
4
5
6
7
8
9

gantt
section Section
Completed :done,    des1, 2014-01-06,2014-01-08
Active        :active,  des2, 2014-01-07, 3d
Parallel 1   :         des3, after des1, 1d
Parallel 2   :         des4, after des1, 1d
Parallel 3   :         des5, after des3, 1d
Parallel 4   :         des6, after des4, 1d

甘特图效果

登陆系统-时序图举例

markdown

1
2
3
4
5
6
7
8
9
sequenceDiagram
participant web as 前端
participant auth as 认证服务
participant db as 数据库

web->>auth: 用户名和密码认证
auth->>db: 检验用户名和密码是否匹配
db-->>auth: 返回结果
auth-->>web: 返回结果

登陆系统时序效果图

VScode预览mermaid绘图效果

  • vsCode 安装插件：Markdown Preview Mermaid Support

more about mermaid

codeReview

记录codeReview实践中关注的知识点

codeReview 每次review都必须留下评论，指出问题，建议，如果觉得写好不需要修改，也应该留下肯定鼓励的语句

about code
  • 时间复杂度：双重循环 循环操作DB
  • 常量：代码随意嵌入： 数字 中文常量
  • 恰到好处到注释：注释不应该到处都是，给比较难懂到地方加上注释即可
  • 方法太长：一个方法最好只做一件事情， 方法太长应该拆分或者提取逻辑为新方法
  • 性能问题：考虑业务数据量大，潜在性能瓶颈
  • 单一原则：一个方法只做一件事情
  • 命名规则：变量 方法命名规则
  • 参数检查：先检查参数，及时跑出异常；再执行业务逻辑
about git
  • commit信息 : 精准的commit信息描述

高可用散记

高可用目的：减少系统不能提供服务的时间。实现的理论：集群化，冗余，故障自动转移，当一台主机挂了，有backup(备份机器)顶上，实现高可用。

实现高可用方式
1
2
- keepAlive + vip （虚拟IP）
#keepAlive 支持虚拟ip方式实现高可用，高可用还可以通过集群来实现，使用VIP的好处是用户访问的IP一直是一样的，无感知变化。
负载均衡实现方式

程序访问系统组件需要实现负载均衡支持更多请求和并发，如：访问 kubernetes apiserver，mysql , redis，mq 等等。

1
2
- nginx 
- haproxy
组件负载 e.g mysql

e.g haproxy -mysql 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

frontend mysql
  bind *:3308
  mode tcp
  #timeout client 1h
  log global
  option tcplog
  default_backend mysql
  acl is_websocket hdr(Upgrade) -i WebSocket
  acl is_websocket hdr_beg(Host) -i ws

backend mysql
  mode tcp
  #timeout queue 1h
  #timeout server 1h
  #timeout connect 1h
  log global
  option tcplog
  balance roundrobin
    server mysql1 192.168.1.11:3307 check
    server mysql2 192.168.1.12:3307 check
    server mysql3 192.168.1.13:3307 check
服务之前调用负载 - 基于健康服务IP s
1
2
3
- 轮训
- 随机
springCloud robin组建实现负载

负载均衡散记

nginx - header 

1
2
3
4

header 里面的key-value 推荐不要带下滑线：如 RF_RPC: JSON_STUB
nginx 默认会去掉下划线， 导致访问404 
underscores_in_headers on # 也可以开启支持下划线

haproxy 实现会话保持

会话保持基本流程：后端生成session-id 以及存储一些数据，返回给浏览器以cookies方式存储，下次前端请求带上cookies里面到值session-id，后端根据session-id获取到对应客户端到数据。

三种方式实现：

1
2
3
- 地址hash
- cookies
- stick-table

基于haproxy-cookies实现会话保持

场景：后端session-id 对应缓存用户信息在本地内存，后端多实例场景下，需要实现每次请求击中同一服务器实例。

nginx session stick模块基于cookies实现会话保持

核心配置如下，原理：后端生成cookie 返回给前端，前端后面的请求http带上cookie值，nginx根据cookie值击中到后端固定服务,实现会话保持.

1
2
sticky name=JSESSIONID domain=cmrh.com hash=index;
server 10.244.17.10:9900  weight=1  max_fails=1 fail_timeout=10s;

haproxy-cookies实现会话保持几种模式：

1
2
3
4
- insert: 在回复中本模块通过Set-Cookie头直接插入相应名称的cookie。

- prefix: 不会生成新的cookie，但会在响应的cookie值前面加上特定的前缀，当浏览器带着这个有特定标识的cookie再次请求时，模块在传给后端服务前先删除加入的前缀，后端服务拿到的还是原来的cookie值，这些动作对后端透明。如："Cookie: NAME=SRV~VALUE"。
- rewrite: 使用服务端标识覆盖后端设置的用于session sticky的cookie。如果后端服务在响应头中没有设置该cookie，则认为该请求不需要进行session sticky，使用这种模式，后端服务可以控制哪些请求需要sesstion sticky，哪些请求不需要。

sesssion 共享实现会话保持

现在多采用微服务架构，后端分布式多实例。将session对应到数据缓存到本地存在弊端。

目前主流session共享实现方式：

1
2
3
4
将session-id 对应到数据存储到远端，任何实例和服务都可根据客户端cookies传过来的session-id获取对应客户端用户的数据。

- redis 
- memercache

nginx 性能优化

1
2
- worker_connections  1024  # 最大链接数量 默认1024
- worker_processes    8     # 进程数 一般设置为cpu内核数

Selenium Grid容器化-分布式测试

本文分享技术的关键词

  • Selenium Grid 容器化
  • Demo演示（容器环境下分布式自动化测试）
  • 基础镜像 （python+selenium依赖容器化）

本文分享的目的：实现Selenium Grid容器化，大大提高部署分布式测试环境效率，减少环境依赖。内容将介绍在容器环境中一键部署Selenium Grid，动态伸缩node节点，制作测试脚本的基础镜像。

Selenium Grid

Selenium作为web应用程序自动化测试利器之一，它支持多种客户端脚本（如：Java,Python,JavaScript等），并且可运行在多种浏览器中（如：chrome,firefox等）。Selenium经常被用于测试web应用程序在不同浏览器的兼容性。在企业级自动化测试中，常常结合Selenium组件Selenium Grid实现多节点分布式自动化测试。

Selenium Grid由中心管理服务Hub和多个node节点组成，node节点需要注册到Hub服务中。使用传统方式部署分布式测试环境比较繁琐和费时，本文将介绍使用docker-compose的方式实现一键部署Selenium Grid分布式测试环境。

image

如上图所示，要实现分布式测试，需要client测试脚本，HUB中心服务以及NODES执行节点。具体解释如下：

1
2
3
HUB: 中心节点服务，用于管理多个node节点，接受Client测试脚本的测试任务，将任务分配给多个node节点执行。
NODES: 真正执行测试任务的节点服务，支持多种浏览器进行测试，如：chrome firefox, node服务需注册到Hub中心服务，由中心服务统一分发任务。
Client: 这里是抽象概念，可理解为执行测试逻辑到客户端（代码），Client客户端需连接到Hub服务，执行测试脚本时由Hub中心服务统一分发给node节点进行执行。

docker-selenium

docker-selenium 实现了在容器环境中使用docker-compose方式快速部署Selenium Grid，伸缩node节点，下面通过详细步骤介绍部署方法。

step-1: 环境准备

1
2
3
4
5
6
docker  --version         #确认已安装docker
docker-compose  --version #确认已安装docker-compose

如未安装请参考：
https://docs.docker.com/install/         #先安装docker
https://docs.docker.com/compose/install/ #安装docker-compose

step-2: docker-compose一键拉起Hub和nodes

创建文件名为：docker-compose.yml，将如下内容填充到docker-compose.yml中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
version: '2'
services:
  firefox:
    image: selenium/node-firefox:3.14.0-gallium  #node服务镜像，支持firefox
    volumes:
      - /dev/shm:/dev/shm                        #挂在目录 /dev/shm 
    depends_on:
      - hub                                      #depends_on 注册到Hub服务
    environment:
      HUB_HOST: hub

  chrome:
    image: selenium/node-chrome:3.14.0-gallium  #node服务镜像，支持chrome
    volumes: 
      - /dev/shm:/dev/shm                       #挂在目录 /dev/shm 
    depends_on:                                 #depends_on 注册到Hub服务
      - hub
    environment:
      HUB_HOST: hub

  hub:
    image: selenium/hub:3.14.0-gallium          #中心服务hub镜像
    ports:
      - "4444:4444"                             #暴露容器端口为4444，后面client代码需要访问这个端口

step-3： 启动服务

1
docker-compose up -d  # 启动服务

step-4: 动态扩缩容node节点

1
2
docker-compose scale chrome=3    #指定支持chrome节点的实例数量
docker-compose scale firefox=3   #指定支持firefox节点的实例数量

step-5: 访问

1
http://localhost:4444/grid/console #访问Hub，能看到node节点都已注册上。

image

Client Demo演示

上面通过docker-compose已成功部署了Selenium Grid，其中心HUB服务端口为4444，测试脚本需要指向该端口。下面通过一个简单的测试Demo进行演示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

chrome = webdriver.Remote(
          command_executor='http://localhost:4444/wd/hub',
          desired_capabilities=DesiredCapabilities.CHROME)
firefox = webdriver.Remote(
          command_executor='http://localhost:4444/wd/hub',
          desired_capabilities=DesiredCapabilities.FIREFOX)

chrome.get('https://www.baidu.com')
print(chrome.title)

firefox.get('https://www.baidu.com')
print(firefox.title)

基础镜像

Demo演示需要依赖python以及selenium，才能执行测试脚本。试想如果我们把该测试脚本放到不同环境中，又需要安装一次python和seleniumyi依赖，很是繁琐。我们可以考虑将测试脚本需要的依赖做成一个基础镜像。

step-1: 编写Dockerfile

1
2
3
4
FROM python:3
COPY test.py ./
RUN pip install selenium
CMD [ "python3", "./test.py" ]

step-2: 制作image

1
2
docker build -t  selenium-base:latest .
#在Dockerfile所在目录执行如上命令， 镜像名为：selenium-base

step-3:使用基础镜像运行测试脚本

1
2
docker run -it  --net=host selenium-base
#执行成功输出：百度一下，你就知道

总结

本文介绍了使用docker-compose一键拉起Selenium Grid分布式测试环境，简单python脚本Demo执行自动化测试，最后将python的依赖统一做成基础镜像，演示了从部署到执行脚本完全容器化到流程。例子很简单，旨在提供一种容器化思路。当部署程序步骤比较繁琐且需要重复进行，都可以考虑将其容器化。

参考文档

docker-selenium-github:https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-Started-with-Docker-Compose
python-dockerHub:https://hub.docker.com/_/python
selenium-grid:https://seleniumhq.github.io/docs/site/en/grid/components_of_a_grid/

高并发下-Zuul参数调优

What is Zuul?

官方介绍:

1
2
3
4
5
6
7
Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application.
As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. 
It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.

#Zuul相当于是设备和网站到Netflix流应用程序后端的所有请求的前门
#Zuul旨在实现动态路由，监控，弹性和安全性等
在微服务架构中常基于Zuul实现服务网关(API Gateway)服务器

在项目实践中，使用jemeter多线程并发访问微服务中的接口时候，在Zuul层出现异常、超时等，从而导致整个请求失败。经过实践，通过调整Zuul的参数、设计高可用架构等可提升TPS、QPS。

Zuul参数剖析

routes

zuul下的routes节点可配置路由转发规则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
zuul：
   routes：
     echo：
       path：/ myusers / **
       serviceId：myusers-service
       stripPrefix：true

myusers-service：
   ribbon：#负载
     NIWSServerListClassName：com.netflix.loadbalancer.ConfigurationBasedServerList
     listOfServers：http：//example1.com,http：//example2.com
     ConnectTimeout：1000 
    ReadTimeout：3000 
    MaxTotalHttpConnections：500 
    MaxConnectionsPerHost：100

如上面的配置，HTTP请求中满足 /myusers/** 规则转发到myuser-service服务。结合ribbon，可支持myusers-service多实例的动态负载。实际项目中可集成eureka或者consul等自动获取listOfServers(多实例服务hosts列表)。

semaphore

在spring cloud Zuul中有2种对路由的隔离机制，其默认的是信号量（semaphore）对路由做隔离，默认值是100，当一个路由请求的信号量高于100就返回500。

1
2
3
4
5
6
7
8
9
10
zuul:
  semaphore:
    max-semaphores: 5000 #设置全部路由最大信号量
  routes:
    orchestration:
      service-id: orchestration
    resource-manager:
      service-id: resource-manager
      semaphore:
        max-semaphores: 5000 #针对单个服务的路由设置最大信号量

设置信号量，可在Zuul节点下对所有路由统一设置信号量（semaphore）大小，在实际项目中推荐为每个服务设置不同的信号量（semaphore）。

ribbon

SpringCloud中ribbon提供负载均衡能力，实际项目中后端不同服务都是多实例，因此从Zuul路由到某个服务也需要支持负载均衡。

1
2
3
4
5
6
7
8
9
10
11
zuul:
ribbon:
  OkToRetryOnAllOperations:true     #全部请求开启重试机制
  ReadTimeout: 6000                 #请求处理超时时间
  ConnectTimeout: 6000              #请求连接超时时间
  MaxTotalHttpConnections: 1000     #最大http连接数
  MaxConnectionsPerHost: 100        #每个host最大连接数
  MaxAutoRetries: 10                #最大重试次数
  MaxAutoRetriesNextServer: 10      #切换实例的重试次数
  eureka:
    enabled: true

在高并发或者后端服务由于网络等原因，导致请求某一瞬间发生故障，也许后端服务只是暂时不可达或者响应比较慢。通过调整响应时间以及重试次数提高请求成功率。

hystrix

hystrix(熔断)，当通过服务网关（基于Zuul实现）调用后端服务时候，难免会出现网络、响应超时等情况。通过hystrix可断掉与后端服务的连接，防止拖垮网关服务器。也可以通过hystrix实现服务降级，当发生异常时候，通过fallback处理熔断（比如：返回一些用户能看懂的错误提示等）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#关于hystrix的参数很多，这里列举一些常用的参数
#更多参数，阅读：https://github.com/Netflix/Hystrix/wiki/Configuration

hystrix:
  threadpool:
    default:
      coreSize: 1000   #线程池数量
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000  #发生熔断的超时时间
          strategy: SEMAPHORE   #隔离策略
          semaphore:
            max-semaphores: 2000 #信号量大小
高并发下常见Zuul异常

在高并发下，针对不同的系统架构、业务场景。需要自己调整Zuul各组件参数来满足性能需求。我们在使用jemeter进行并发测试，发现Zuul（服务网关）层出现了一些异常信息，解决了这些异常信息，QPS,TPS都提高了不少。

无法获取信号量(semaphore异常)

异常信息-1:

1
2
spring cloud zuul : could not acquire a semaphore for execution and no fallback available.
#无法获取信号量，系统默认每个路由的信号量为100，当后端一个实例且并发大于100就会经常出现这个异常信息

调优配置-1:

1
2
3
4
zuul:
  semaphore:
    max-semaphores: 5000
#可根据系统需要支持的并发数适当增加信号量的大小

超时

异常信息-2:

1
2
connect time out...
#当并发访问时，有些服务所在主机响应可能会比较慢，或者某些业务本身比较耗时（比如上传一个大文件的接口）。如果在Zuul层设置的超时时间小于足业务的耗时，会导致正常的业务请求失败。

调优配置-2：

1
2
3
4
5
ribbon:
  ReadTimeout: 6000                 #请求处理超时时间
  ConnectTimeout: 6000              #请求连接时间
   
# 根据业务可适当调大超时时间

熔断

异常信息-3：

1
2
short-circuited and no fallback available
#并发访问时，后端某些服务发生熔断

调优配置-3：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000  #发生熔断的超时时间

# 调整熔断超时时间，熔断时间太短，些耗时的业务部不能work
# 熔断时太长，Zuul服务器可能会被拖垮。所以根据具体业务找到一个合适值。

ribbon:
  OkToRetryOnAllOperations:true     #全部请求开启重试机制
  ReadTimeout: 6000                 #请求处理超时时间
  ConnectTimeout: 6000              #请求连接超时时间
  MaxAutoRetries: 10                #最大重试次数
#调整重试次数，实际项目中由于网络或者资源不够，偶尔会出现后端服务不能访问，一次访问失败不能代表后端服务就挂了。
#因此开启重试机制，调整重试次数。在一定时间内，重试几次都失败，我们才认为后端服务挂了。

Zuul高可用

我们知道无论在Linux或者windows下，一个进程支持的并发数是有限制的，在实际项目中，服务网关作为微服务架构的入口至关重要。Zuul结合服务发现、负载均衡等启动多个实例做到高可用。如下图:

如上图，启动多个Zuul实例，在Zuul前加一层负载（常用nginx做负载），每个实例承担一些请求，整体支持高并发能力也会提高很多。

Zuul版本 - 1.x vs 2.x

截止目前Zuul发布了2个版本，在架构和实现方式以及支持并发的情况都有所不同。

Zuul-1.x


Filter是Zuul的核心，用来实现对外服务的控制。Filter的生命周期有4个，分别是“PRE”、“ROUTING”、“POST”、“ERROR“

  • PRE：过滤器在请求经过路由前被调用。利用这种过滤器可实现身份验证。
  • ROUTING：过滤器将请求路由到微服务。这种过滤器用于构建发送给后端微服务的请求，使用Apache HttpClient或Netfilx Ribbon请求微服务。
  • POST：过滤器在路由到微服务以后执行。这种过滤器可为响应添加标准的HTTP Header、收集统计信息和指标、将响应发送给客户端。
  • ERROR：在其他阶段发生错误时执行该过滤器

Zuul-2.x


2.x的Zuul基于netty处理请求，netty（高性能、异步事件驱动的NIO框架，提供了对TCP、UDP和文件传输的支持，Netty的所有IO操作都是异步非阻塞的）。相对于1.x版本，很明显把同步改成了异步，把阻塞改成了非阻塞。据官方进行的并发测试，2.x相比1.x性能还是提升了不少。不过2.x相对1.x要复杂一些，如果需要支持很高的QPS、TPS，可以尝试下2.x。

总结：

  • 1.x 同步阻塞，编程模型简单，社区成熟，通过调整参数能满足生产性能需求
  • 2.x 异步非阻塞，相对编程模型复杂，刚出来也许还有些坑(bug)，追求更好性能可以尝试
最后

当高并发情况下，服务网关服务器(Zuul)可通过以下方法提高支持并发的能力。

  • 调整Zuul组件参数
  • 支持Zuul高可用，多实例
  • 选择异步、非阻塞版本
参考文档

Zuul-github ：https://github.com/Netflix/zuul
Zuul-wiki：https://github.com/Netflix/zuul/wiki
blog：https://www.cnblogs.com/lonelyJay/p/10076441.html

mysql

备份

1
2
mysqldump  -uroot  -p  --all-databases>backup.sql
mysqldump  -uroot  -p  --databases dbname1 dbname2>backup.sql

恢复

1
mysql  -uroot  -p  <backup.sql

排查最大连接数

1
2
3
show global status like 'Max_used_connections'; 查询设置的最大连接数
show variables like '%max_connections%';  查询历史最大连接数
set GLOBAL max_connections=256; 更新最大连接数

导出mysql结构

1
mysqldump -h localhost -uroot -pwise2c2017 -d builderdb > dump.sql

mysql-用户授权

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE USER 'permission'@'%' IDENTIFIED BY 'permission'; 
#创建用户 % 允许远程用户访问  用户名：permission 密码：permission

show grants for permission;
#查看permission用户的权限

grant SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES  on bldr.* to permission@'%'
#给db中的 bldr数据库实例授权

grant SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES  on *.* to permission@'%'
#给全部数据库实例授权

GRANT ALL PRIVILEGES ON *.* TO 'permission'@'%'
#授予全部db权限

revoke  select, insert, update, delete  on *.* from permission@'%';
#撤销权限

mysql-问题排查

执行计划
1
2
EXPLAIN select * from test; 
#查看sql执行计划
慢日志
1
2
3
4
5
6
7
8
9
10
# 慢日志参数
slow_query_log                  # 是否开启慢查询日志 1:开启 0 关闭
slow-query-log-file             # 慢日志输出的路径
long_query_time                 # 设置慢查询时间阈值 1 表示1秒
log_queries_not_using_indexes   # 查询为使用索引 被记录
log_output                      # 日志存储的方式 默认：FILE  可以是： FILE,TABLE

# 命令更新参数
set global slow_query_log = 1   
show variables like '%slow_query%'

db权限说明

所有库都需要都权限

  • grant SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES on dbname.* to permission@’%’
    第三方组件 grafana 权限 （需要DROP权限）
  • grant SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, REFERENCES，DROP on dbname.* to permission@’%’
    autocommit (需要开启)
  • set global autocommit = 1

查看mysql 链接数状态

1
show processlist

清理mysql-binlog

当mysql集群开启了主从同步，会产生大量当binlog, 耗费大量的磁盘空间

方法：

1
2
3
- 关闭主从
- 设置expire_logs_days 超过过期时间自动清理
- 手动清理日志

mysql 8 小时超时

1
2
interactive_timeout  默认8小时超时 8小时不连接自动端口， 用户mysql 客户端
wait_timeout   默认8小时超时 8小时不连接自动断开， 用于类似jdbc 连接

sonarQube+jenkins持续审查

SonarQube是管理代码质量一个开放平台，可以快速的定位代码中潜在的或者明显的错误，为提高代码质量提供帮助

基于Docker部署sonarQube

//安装psql 创建数据库：sonar
docker run --name postgresqldb -e POSTGRES_USER=root -e POSTGRES_PASSWORD=root -d postgres
docker exec -it $containerid /bin/sh
psql -Uroot -droot
\l
create database sonar;

//安装sonarqube
docker run --name sonarqube \
    --link postgresqldb \
    -e SONARQUBE_JDBC_USERNAME=root \
    -e SONARQUBE_JDBC_PASSWORD=root \
    -e SONARQUBE_JDBC_URL=jdbc:postgresql://postgresqldb:5432/sonar \
    -p 9000:9000 -d sonarqube


* IP:8001 访问 默认sonarqube用户和密码：admin

汉化sonarqube

  • 下载sonar-l10n-zh-plugin-1.20.jar
  • 放在 extensions/plugins , 重启sonarqube

jenkins集成sonarQube

1、 安装sonarQubeScaner 系统管理->管理插件->可选插件


2、 获取sonarQube的token sonarQube->配置->用户->令牌

3、 配置sonarQubeServer 系统管理->系统设置


4、 配置sonarQube scaner 系统管理->全局工具设置


5、 在构建中添加sonarqube，其中src表示源码的目录，build编译代码后的目录


6、成功后，可在sonarqube查看扫描代码的结果

tips：通过分析结果中的bugs、漏洞、坏味道可提高代码规范和质量.

Kubernetes-项目中pod调度使用法则

前言

kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求，比如：某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。使用kubernetes中的节点调度、节点亲和性、pod亲和性、污点与容忍可以灵活的完成pod调度，从而满足项目中较为复杂的调度需求。下面用一些项目中的使用场景聊聊pod调度使用法则。

pod调度主要包含以下内容
1
2
3
4
- nodeSelector
- nodeAffinity
- podAffinity
- Taints & tolerations(污点与容忍)

Read More