migrate images

content/posts/go/gc.md

@@ -39,11 +39,11 @@ STW 是 Stop The World 的缩写，意思是 GC 的时候会暂停其它所有
 
 假设应用程序当前运行了四个 goroutine :
 
-![](/images/go/gc1.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc1.png)
 
 我们需要等待所有 goroutine 暂停，而暂停操作是需要出现一次函数调用才能完成，如果某个 goroutine 始终没有发生函数调用（比如一直在执行某个非常长的循环操作）而其它 goroutine 却完成了会怎样，就会如下图：
 
-![](/images/go/gc2.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc2.png)
 
 然而，必须所有的 goroutine 全部都暂停，垃圾回收才能继续进行，不然就会卡在这里一直等待，结果就是延迟越来越高。这个问题官方团队计划将在 1.14 版本通过优先策略进行优化。
 
@@ -54,14 +54,14 @@ STW 是 Stop The World 的缩写，意思是 GC 的时候会暂停其它所有
 
 进行标记，Concurrent 表示这个过程是并发进行的，不会 STW ，GC 会先征用 25% 的 CPU 资源，如下图：
 
-![](/images/go/gc3.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc3.png)
 
 GC 占用了 P1 逻辑处理器，而其它 goroutine 正常的并发运行。
 
 
 但是，有些时候 GC 的任务特别繁重，需要更多的资源，这个时候怎么办？开启 Mark Assit 协助工作，如下图中的 MA ：
 
-![](/images/go/gc4.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc4.png)
 
 标记完成，进行下一个阶段。
 
@@ -71,12 +71,12 @@ GC 占用了 P1 逻辑处理器，而其它 goroutine 正常的并发运行。
 
 标记终止。关闭 Write Barrier（写屏障），执行各种清理任务，然后计算下一次 GC 的目标，这个阶段也是需要 STW 的，平均 60 - 90 微秒：
 
-![](/images/go/gc5.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc5.png)
 
 
 一旦 GC 完成，goroutine 继续执行：
 
-![](/images/go/gc6.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc6.png)
 
 ### Sweeping - Concurrent
 
@@ -99,7 +99,7 @@ GODEBUG=gctrace=1
 
 通过指标数据可以看到各个过程及耗时情况，比如：
 
-![](/images/go/gc7.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/go/gc7.jpeg)
 
 
 2、使用 pprof

content/posts/influxdb/1.md → content/posts/influxdb/influxdb-1.md

@@ -92,12 +92,12 @@ field key = field value  键值对也是存储具体的数据，但不会被索
 
 示例：
 
-![image](/images/influxdb/line-protocol.png)
+![image](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/line-protocol.png)
 
 
 怎么去理解 series 和 point ？先看下图：
 
-![image](/images/influxdb/series-point.webp)
+![image](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/series-point.webp)
 
 
 这张图选取了三种时序数据库的历年排名得分情况。首先，整个图表可以看成是一个 measurement ，它包含了许多数据；然后我们根据 db 名称构建 tag ，把 score 排名得分作为 field ，那么所有数据行就类似于：
@@ -187,10 +187,10 @@ InfluxDB 为了更高的性能做了一些设计与权衡之道：
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/2.md → content/posts/influxdb/influxdb-2.md

@@ -32,7 +32,7 @@ shard 是什么？
 
 先来看数据的层次结构：
 
-![image](/images/influxdb/shard.webp)
+![image](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/shard.webp)
 
 如果所示，一个 database 对应一个实际的磁盘上的文件夹，该数据库下不同的 RP 策略对应不同的文件夹。
 
@@ -65,7 +65,7 @@ shard 从属于唯一一个 shard group ，shard duration 和 shard group durati
 
 默认情况下，shard group duration 根据 RP duration 的值来确定，对应关系如下图：
 
-![image](/images/influxdb/rp-duration.png)
+![image](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/rp-duration.png)
 
 
 
@@ -80,7 +80,7 @@ shard group duration 设置为多久才最好？
 
 默认配置对于大多数场景都运行的很好，然而，高吞吐量或长时间运行的实例将受益于更长的 shard group duration ，官方建议的配置如下：
 
-![image](/images/influxdb/rp-duration-config.webp)
+![image](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/rp-duration-config.webp)
 
 
 
@@ -96,10 +96,10 @@ RP 策略可以动态调整，删除一个 RP 将会删除其下的所有数据
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/3.md → content/posts/influxdb/influxdb-3.md

@@ -109,10 +109,10 @@ series-id-set-cache-size ：使用内存缓存的 series 集的大小，由于 T
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/4.md → content/posts/influxdb/influxdb-4.md

@@ -20,7 +20,7 @@ disableComments = true
 
 InfluxDB 数据的写入如下图所示：
 
-![write data](/images/influxdb/write-data.png)
+![write data](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/write-data.png)
 
 所有数据先写入到 WAL（ Write Ahead Log ）预写日志文件，并同步到 Cache 缓存中，当 Cache 缓存的数据达到了一定的大小，或者达到一定的时间间隔之后，数据会被写入到 TSM 文件中。
 
@@ -36,7 +36,7 @@ Compactor 压缩器则负责具体的 Compression 压缩工作。
 
 为了处理文件，存储引擎通过 Writers/Readers 处理数据的写和读。另外存储引擎还会使用 In-Memory Index 内存索引快速访问 measurements、tags、series 等数据。
 
-![in-memory index](/images/influxdb/in-memory-index.png)
+![in-memory index](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/in-memory-index.png)
 
 
 存储引擎的组成部分：
@@ -92,7 +92,7 @@ IOPS（ Input/Output Operations Per Second ）：每秒读写数，衡量存储
 
 不同负载情况下的硬件配置参考如下：
 
-![hard config](/images/influxdb/hard-config.png)
+![hard config](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/hard-config.png)
 
 由于 SSD 固态硬盘的性能更高，官方也建议使用 SSD ，上图也是使用 SSD 的情况。
 
@@ -110,10 +110,10 @@ IOPS（ Input/Output Operations Per Second ）：每秒读写数，衡量存储
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/5.md → content/posts/influxdb/influxdb-5.md

@@ -116,13 +116,13 @@ bind-address = "127.0.0.1:8088"
 
 备份命令：
 
-![backup](/images/influxdb/backup.png)
+![backup](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/backup.png)
 
 
 
 恢复命令：
 
-![restore](/images/influxdb/restore.png)
+![restore](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/restore.png)
 
 
 
@@ -143,10 +143,10 @@ bind-address = "127.0.0.1:8088"
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/6.md → content/posts/influxdb/influxdb-6.md

@@ -325,10 +325,10 @@ EVERY 1h 大于 GROUP BY time(30m)，因此 CQ 每隔 1h 执行一次；FOR 90m
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/influxdb/7.md → content/posts/influxdb/influxdb-7.md

@@ -21,7 +21,7 @@ InfluxDB 开源的社区版本面临的最大的问题就是单点故障和容
 既然有单点故障的可能，那么索性写入多个节点，同时也解决了容灾备份的问题：
 
 
-![double write](/images/influxdb/double-write.png)
+![double write](https://raw.githubusercontent.com/RifeWang/images/master/influxdb/double-write.png)
 
 1、在不同的机器上配置多个 InfluxDB 实例，写入数据时，直接由客户端并发写入多个实例。（为什么不用代理，因为代理自身就是个单点）。
 
@@ -46,10 +46,10 @@ InfluxDB 开源的社区版本面临的最大的问题就是单点故障和容
 
 ---
 相关文章：
-- [时序数据库 InfluxDB（一）](/posts/influxdb/1/)
-- [时序数据库 InfluxDB（二）](/posts/influxdb/2/)
-- [时序数据库 InfluxDB（三）](/posts/influxdb/3/)
-- [时序数据库 InfluxDB（四）](/posts/influxdb/4/)
-- [时序数据库 InfluxDB（五）](/posts/influxdb/5/)
-- [时序数据库 InfluxDB（六）](/posts/influxdb/6/)
-- [时序数据库 InfluxDB（七）](/posts/influxdb/7/)
+- [时序数据库 InfluxDB（一）](/influxdb-1/)
+- [时序数据库 InfluxDB（二）](/influxdb-2/)
+- [时序数据库 InfluxDB（三）](/influxdb-3/)
+- [时序数据库 InfluxDB（四）](/influxdb-4/)
+- [时序数据库 InfluxDB（五）](/influxdb-5/)
+- [时序数据库 InfluxDB（六）](/influxdb-6/)
+- [时序数据库 InfluxDB（七）](/influxdb-7/)

content/posts/kubernetes/docker-guide.md

@@ -22,7 +22,7 @@ disableComments = true
 
 一张图慢慢讲：
 
-![](/images/docker/docker1-1.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker1-1.jpeg)
 
 1、本地开发写好了 code ，首先我们需要通过 build 命令构建 image 镜像，而构建的规则呢，就需要写在这个 dockerfile 文件里。
 
@@ -50,7 +50,7 @@ disableComments = true
 
 Docker 中的镜像到底是什么？它是一个可供执行的文件系统包，里面包含了运行一个应用程序所需要的代码、库、环境变量和配置文件等等所有内容。
 
-![](/images/docker/docker2-1.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker2-1.jpeg)
 
 镜像是分层的。它是由一个或多个文件系统叠加而成，最底层是 bootfs 即引导文件系统，我们几乎永远不会与这个东西有什么交互，而且当容器启动时 bootfs 会被卸载掉。第二层是 rootfs ，通常是一个操作系统，其包含了程序运行所需的最基本环境，也称之为基础镜像。第三、第四、第N层，是由我们自己指定的其它资源文件。
 
@@ -168,7 +168,7 @@ Volume 翻译为卷，因为基本上用于挂载数据，所以也常常直接
 
 所谓的挂载数据卷，实际上就是把宿主机本地的目录文件映射到 docker 容器内部的目录下。也就是说实际的目录文件是存放在本地磁盘上的，docker 容器通过挂载的方式可以直接使用本地磁盘上的文件。
 
-![](/images/docker/docker3-1.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker3-1.jpeg)
 
 如上图所示：
 
@@ -182,7 +182,7 @@ Volume 翻译为卷，因为基本上用于挂载数据，所以也常常直接
 
 如果有多个容器都需要挂载数据卷，难道需要每一个容器都挂载一遍到本地？当然不是。
 
-![](/images/docker/docker3-2.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker3-2.jpeg)
 
 如上图所示，这里引入了数据卷容器（图中的 Data Container ），其实就是一个普通的容器，我们只需要通过数据卷容器挂载（ -v ）一次数据卷，其他需要挂载的容器直接连接（ --volumes-from ）这个数据卷容器就行了，而再不需要知道实际的宿主机本地目录。
 
@@ -238,7 +238,7 @@ app.listen(PORT);
 
 这样 web 容器便可以连接上 redis 容器了，如下图所示：
 
-![](/images/docker/docker4-1.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker4-1.jpeg)
 
 使用 link 方法，其会在容器启动时（容器每次启动都会默认配置不同的虚拟网络）找到连接的目标容器并在本容器内部设置环境变量并修改 /etc/hosts 文件，这也是我们可以直接使用连接别名而不用指定具体 IP 地址的原因。
 
@@ -248,7 +248,7 @@ app.listen(PORT);
 
 1、net 方式一，如下图所示：
 
-![](/images/docker/docker4-2.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker4-2.jpeg)
 
 我们先将 redis 容器的端口暴露到本地宿主机，然后在 web 中指定本地宿主机具体的 IP 地址，这样也可以实现连接，但是需要注意的是，在 web 中不能直接使用 localhost ，因为前面已经提到了，每个容器都有自己独立的虚拟网络，使用 localhost 将会指向的是这个容器内部，而不是宿主机。
 
@@ -257,15 +257,15 @@ app.listen(PORT);
 
 2、net 方式二，如下图所示：
 
-![](/images/docker/docker4-3.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker4-3.jpeg)
 
 这里与前一种方式不同的是，我们直接通过 --net host 指定容器直接使用宿主机网络，这样在 web 中就可以直接通过 localhost 连接到 redis 了，不用知道宿主机具体的 IP 地址，对比上一种方式看似有一点小的改进。
 
 但是这种方式的问题在于，对于 MacOS 系统无法使用，因为在 MacOS 上 Docker 仍然是跑在一层虚拟机中的，这种方式目前还无法穿透这层虚拟机直接将 localhost 映射到宿主机本地，同时，直接使用宿主机网络，容器其实会全部暴露出来，存在安全隐患，因此也不建议使用这种方式。
 
 3、net 方式三，如下图所示：
 
-![](/images/docker/docker4-4.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker4-4.jpeg)
 
 这里通过 --net container 的方式直接指定 web 使用与 redis 相同的网络，这样既避免了无谓的端口暴露，同时又能保持容器与宿主机之间的隔离，这种方式是建议使用的。
 
@@ -284,7 +284,7 @@ docker network create -d bridge my-network
 
 将 web 和 redis 容器连接到同一个自定义的网络中，并直接在 web 中的 redis host 指向 redis 容器的别名，即可完成连接，如下图所示：
 
-![](/images/docker/docker4-5.jpeg)
+![](https://raw.githubusercontent.com/RifeWang/images/master/docker/docker4-5.jpeg)
 
 对于自定义网络，我们不仅能够在容器启动时通过 --net 直接指定，还能够在容器已经启动完成后通过：
 

content/posts/kubernetes/k8s-crd-operator.md

@@ -75,7 +75,7 @@ spec:
 
 执行 `kubectl apply -f my-crontab.yaml` 就可以创建我们自定义的 CronTab，执行 `kubectl get crontab` 就可以查询到我们自定义的 CronTab 列表。
 
-![](/images/k8s/crd-operator/crd.png)
+![](https://raw.githubusercontent.com/RifeWang/images/master/k8s/crd-operator/crd.png)
 
 通过 `CRD` 自定义资源的优点是，我们无需操心自定义资源的数据存储，也无需再额外实现一个 http server 去对外暴露操作这些自定义资源的 API 接口，因为这些 k8s 都帮我们做好了，我们只需要像其它内置资源一样使用自定义资源即可。
 
@@ -85,7 +85,7 @@ spec:
 
 `Operator` 其实就是 custom resource controller（自定义资源的控制器），它干的事情就是监听自定义资源的变更，然后针对性地做一些操作。例如，监听到某个自定义资源被创建后，`Operator` 可以读取这个自定义资源的属性然后创建一个 pod 去运行具体的程序，并将这个 pod 绑定到自定义资源对象上。
 
-![](/images/k8s/crd-operator/k8s-operator-1800x1013.webp)
+![](https://raw.githubusercontent.com/RifeWang/images/master/k8s/crd-operator/k8s-operator.png)
 
 那 `Operator` 以何种方式存在呢？其实它跟普通的服务一样，可以是 `deployment`，也可以是 `statefuleSet`。