加速Docker多阶段构建
多阶段构建虽然能够减小镜像体积,但是构建的速度慢了许多。原因在于:一是相比于原先的单阶段构建,多了一些构建步骤;二是缓存失效,多阶段编译之后只保留最终镜像的缓存,中间镜像的缓存丢失。其中缓存失效的问题在CI环境中尤为显著。 加快多阶段构建的措施有两项:并行构建和保留缓存并行构建 从Docker 18.09开始引入了并行构建,启用方法有两种: 临时启用:设置环境变量DOCKER_BUILDKIT=1; 原构建命令: docker build -f Dockerfile -t test_name . 增加DOCKER_BUILDKIT=1后的命令: DOCKER_BUILDKIT=1 docker build -f Dockerfile -t test_name . 默认启用:在/etc/docker/daemon.json中设置{ "features": { "buidkit": true }}。 保留缓存 不仅保留最终镜像的缓存,还保留中间镜像的缓存。 do...
(Address already in use xxx) or (No buffer space available (maximum connections reached) connect)
No buffer space available (maximum connections reached?): connect Address already in use xxx 123一般可以先查看代码中是否有一些连接未关闭1. 比如es的restclient,或者其他的httpclient2. 再或者可以检查下是否有长时间占用未被释放的jdbc connection
BigDecimal工具类小记
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120...
uniq命令
语法1uniq [-cdu][-f<栏位>][-s<字符位置>][-w<字符位置>][--help][--version][输入文件][输出文件] 参数: -c或--count 在每列旁边显示该行重复出现的次数。 -d或--repeated 仅显示重复出现的行列。 -f<栏位>或--skip-fields=<栏位> 忽略比较指定的栏位。 -s<字符位置>或--skip-chars=<字符位置> 忽略比较指定的字符。 -u或--unique 仅显示出一次的行列。 -w<字符位置>或--check-chars=<字符位置> 指定要比较的字符。 --help 显示帮助。 --version 显示版本信息。 [输入文件] 指定已排序好的文本文件。如果不指定此项,则从标准读取数据; [输出文件] 指定输出的文件。如果不指定此选项,则将内容显示到标准输出设备(显示终端)。
xargs命令用法
xargs 一般是和管道一起使用。 命令格式: 1somecommand |xargs -item command 参数: -a file 从文件中读入作为 stdin -e flag ,注意有的时候可能会是-E,flag必须是一个以空格分隔的标志,当xargs分析到含有flag这个标志的时候就停止。 -p 当每次执行一个argument的时候询问一次用户。 -n num 后面加次数,表示命令在执行的时候一次用的argument的个数,默认是用所有的。 -t 表示先打印命令,然后再执行。 -i 或者是-I,这得看linux支持了,将xargs的每项名称,一般是一行一行赋值给 {},可以用 {} 代替。 -r no-run-if-empty 当xargs的输入为空的时候则停止xargs,不用再去执行了。 -s num 命令行的最大字符数,指的是 xargs 后面那个命令的最大命令行字符数。 -L num 从标准输入一次读取 num 行送给 command 命令。 -l 同 -L。 -d delim 分隔符,默认的xargs分隔符是回车,argument的分隔符是空格,这里修改...
NodeJs整合elk+zipkin,输出日志到logstash
依赖 web框架(要求2.7+) 1"koa": "^2.13.1" 日志(基于tcp协议) 12"log4js": "^3.0.5","log4js-logstash-tcp": "^2.0.0" zipkin 12"zipkin-instrumentation-koa": "^0.22.0","zipkin-transport-http": "^0.22.0" 代码(ziplin部分)1234567891011# 下游(上游略,上游改localServiceName即可)const {Tracer, BatchRecorder, ExplicitContext} = require('zipkin');const {koaMiddleware} = require('zipkin-instrumentati...
Node项目中使用ESlint
ESLint1、介绍 ESLint是最流行的JavaScript Linter。 Linter 是检查代码风格/错误的小工具。其他类似的 Linter 工具还有:TSLint、stylelint。 它包含三个功能: (1)check syntax (2)find problems 前两个可以统称为 Code-quality rules,例如 no-unused-vars 规则。 (3)enforce code style 最后一个可以称为 Formatting rules ,例如 keyword-spacing 规则。 下面介绍的 Prettier 就只有这一个 Formatting rules 功能。 2、安装1234npm install -g eslint全局安装。npm i -D eslint局部安装。 3、使用 (1) 生成配置文件 1234下面的命令,可以在项目的根目录创建.eslintrc.js配置文件。eslint --init按照交互提示,依次选择进行: (2) 校验文件 12345eslint yourfile.js命令行会返回出现...
koa+cls+log4js实现全链路日志系统
什么是全链路日志 在线上项目运行期间,经常会出现各种莫名奇妙的bug,而且一个请求往往会经过多个项目的接口调用,比如电商中的下订单,可能会调用到商品服务,优惠券满减服务,会员服务之类的,假如某一时刻下单失败,前端报了个系统异常,怎么样快速定位到底是哪个服务发生了异常,以及定位发生异常的服务具体是报了什么异常日志呢。这就是全链路日志要做的事情,它把这个请求内调用到的所有请求通过全局id串起来,通过全局id可以把所有涉及到的系统日志都快速的定位出来。 日志开发架构图 之后logstash后可能需要加queue为后续大数据做准备 技术栈 功能 技术栈 日志 log4js 异步资源追踪 cls-hooked web框架 koa node 12 rest-传递header[trace-id] axios 思路12341. 请求打进来, 由网关下发全局唯一id2. koa框架可以获取同步请求的上下文, 但在异步中需要上下文持久的问题(比如async_hook)3. 需要保证当前项目所有category的log可用,且打印trace-id4. 需要考虑解耦...
linux安装node
历史版本可从https://nodejs.org/zh-cn/download/releases/下载 通过ftp工具上传到linux服务,解压安装包1tar -xvf node-v10.16.0-linux-x64.tar.xz 移动并改名文件夹(不改名也行)123cd /usr/local/mv /var/ftp/pub/node-v10.16.0-linux-64 . //后面的.表示移动到当前目录mv node-v10.16.0.0-linux-64/ nodejs 让npm和node命令全局生效(方式选择任一)方式一:环境变量方式(这种方式只对登录用户有效) 1)、加入环境变量,在 /etc/profile 文件末尾增加配置 12vi /etc/profileexport PATH=$PATH:/usr/local/nodejs/bin 2)、执行命令使配置文件生效 1source /etc/profile 方式二:软链接方式(推荐)12ln -s /usr/local/nodejs/bin/npm /usr/local/bin...
探究分布式事务原理1
分布式事务<谨供参考> 分布式事务顾名思义就是要在分布式系统中实现事务,它其实是由多个本地事务组合而成。 关于分布式事务目前也有许多种解决方案,常说的几种如2pc,3pc,TCC,本地消息表,消息事务,最大努力通知 关于几种方案的介绍可以看下敖丙的文章<分布式事务的六种解决方案> 无论是哪种解决方案,目的都是希望保证多个系统的事务方法统一提交,要么全成,全么全败(原子性),所以这篇文章指在建立这样的想法上,手写一个分布式事务解决方案的demo,以为之后的分布式事务框架以及知识学习做积累在开发之前需要知道一点,spring的事务管理是基于(jdbc/java.sql.xxx)进行拓展,所以我们可以从这里着手 修改获取Connection的逻辑 设计图如下 图中画了四个角色 服务调用者(server1) 服务被调用者(server2) 全局事务管理者(tx-manager) 中间协调者(global-tx)-负责和tx-manager交互的 整个调用链路如下: 123456789101. 访问server1接口,server...
