- 博客(76)
- 收藏
- 关注
RSS订阅
原创 300分钟吃透分布式缓存-15讲：如何深入理解、应用及扩展 Twemproxy？
如下图所示，它可以封装资源池的分布及 hash 规则，解决后端部分节点异常后的探测和重连问题，让 client 访问尽可能简单，同时资源变更时，只要在 Twemproxy 变更即可，不用更新数以万计的 client，让资源变更更轻量。以 Memcached 访问为例，将业务的 Memcached 资源部署好之后，然后将 Mc 资源列表、访问方式等设到 YAML 文件的配置项，然后启动 Twemproxy，业务端就可以通过访问 Twemproxy ，来获取后端资源的数据了。至此一个请求的处理彻底完成。
2024-02-26 17:04:02
1283
原创 300分钟吃透分布式缓存-14讲：大数据时代，MC如何应对新的常见问题？
另外，设置的内存，也不完全是存储有效数据，我上一节课讲到，每个 Item 数据存储在 chunk 时，会有部分字节浪费，另外 key 在过期、失效后，不是立即删除，而是采用延迟淘汰、异步 LRU 队尾扫描的方式清理，这些暂时没有淘汰的、过期失效的 key ，也会占用不少的存储空间。因此，互联网系统的数据，有明显的冷热区分，而且这个冷热程度往往比 80/20 更大，比如微博、微信最近一天的数据，被访问的特别频繁，而一周前的数据就很少被访问了。除了抗峰，另外，还可以轻松应对局部故障，避免雪崩的发生。
2024-02-25 23:32:46
993
原创 300分钟吃透分布式缓存-13讲：如何完整学习MC协议及优化client访问？
回顾一下最近几节课的内容。首先，学习了 Mc 的系统架构，学习了 Mc 基于 libevent 的网络模型，学习了 Mc 的多线程处理，包括主线程、工作线程如何进行网络 IO 协调及处理，学习了 Mc 的状态机。其中 flags 是用户自己设计的一个特殊含义数字，Mc 对 flag 只存储，而不进行任何额外解析处理，expiretime 是 key 的过期时间，value 字节数是 value block 块的字节长度，而带上 noreply 是指 Mc 处理完后静默处理，不返回任何响应给 client。
2024-02-23 20:42:52
1324
原创 300分钟吃透分布式缓存-28讲：如何构建一个高性能、易扩展的Redis集群？
对于区间分布哈希，实际是一种取模哈希的变种，取模哈希是哈希并取模计算后，按哈希值来分配存储节点，而区间哈希是在哈希计算后，将哈希划分为多个区间，然后将这些区间分配给存储节点。在源节点接收到 migrate $host $port $key $destination-db 的指令后，首先 slot 迁移的源节点会与迁移的目标节点建立 socket 连接，第一次迁移，或者迁移过程中，当前待迁移的 DB 与前一次迁移的 DB 不同，在迁移数据前，还需要发送 select $dbid 进行切换到正确的 DB。
2024-03-13 12:40:33
918
1
原创 300分钟吃透分布式缓存-27讲：Redis是如何进行主从复制的？
Redis 在进行全量同步时，master 会将内存数据通过 bgsave 落地到 rdb，同时，将构建 内存快照期间 的写指令，存放到复制缓冲中，当 rdb 快照构建完毕后，master 将 rdb 和复制缓冲队列中的数据全部发送给 slave，slave 完全重新创建一份数据。如果 master 校验成功。而对于全量同步，slave 会首先进行，嵌套复制的清理工作，比如 slave 当前还有嵌套的 子slave，则该 slave 会关闭嵌套 子slave 的所有连接，并清理自己的复制积压缓冲。
2024-03-13 11:31:58
1025
原创 300分钟吃透分布式缓存-26讲：如何大幅成倍提升Redis处理性能？
线上 Redis 处理用户请求时，十万级的 client 挂在一个 Redis 实例上，所有的事件处理、读请求、命令解析、命令执行，以及最后的响应回复，都由主线程完成，纵然是 Redis 各种极端优化，巧妇难为无米之炊，一个线程的处理能力始终是有上限的。要想更大幅提升处理性能，命令的执行、事件的触发等都需要分拆到不同线程中进行，而且多线程处理模型也需要优化，各个线程自行进行 IO 读写和执行，互不干扰、等待与竞争，才能真正高效地利用服务器多核心，达到性能数量级的提升。主线程负责监听端口，注册连接读事件。
2024-03-09 23:06:13
1354
原创 300分钟吃透分布式缓存-25讲：Redis是如何处理容易超时的系统调用的？
Redis 在运行过程中，不可避免的会产生一些运行慢的、容易引发阻塞的任务，如将内核中的文件缓冲同步到磁盘中、关闭文件，都会引发短时阻塞，还有一些大 key，如一些元素数高达万级或更多的聚合类元素，在删除时，由于所有元素需要逐一释放回收，整个过程耗时也会比较长。BIO 线程启动时或持续处理完所有任务，发现任务队列为空后，就会阻塞，并等待新任务的到来。就会向对应的任务队列提交任务。Redis 启动时，会创建三个任务队列，并对应构建 3 个 BIO 线程，三个 BIO 线程与 3 个任务队列之间一一对应。
2024-03-09 23:02:28
477
原创 300分钟吃透分布式缓存-24讲：Redis崩溃后，如何进行数据恢复的？
这样即便 Redis 被 crash 或异常关闭后，再次启动，也可以通过加载 AOF，来恢复最新的全量数据，基本不会丢失数据。但是，由于 Redis 会记录所有写指令操作到 AOF，大量的中间状态数据，甚至被删除的过期数据，都会存在 AOF 中，冗余度很大，而且每条指令还需通过加载和执行来进行数据恢复，耗时会比较大。随着时间的推移，AOF 持续记录所有的写指令，AOF 会越来越大，而且会充斥大量的中间数据、过期数据，为了减少无效数据，提升恢复时间，可以定期对 AOF 进行 rewrite 操作。
2024-03-09 22:56:43
1892
原创 300分钟吃透分布式缓存-23讲：Redis是如何淘汰key的？
对于 lfu，要选择使用频率最小的 key，为了沿用 evictionPool 的 idle 概念，Redis 在计算 lfu 的 Idle 时，采用 255 减去使用频率相对值，从而确保 Idle 最大的 key 是使用次数最小的 key，计算 N 个 key 的 Idle 值后，插入 evictionPool，最后选择 Idle 最大，即使用频率最小的 key，进行淘汰。这种策略适合的业务场景是，需要淘汰的key带有过期时间，且有冷热区分，从而可以淘汰最久没有访问的key。
2024-03-09 22:49:26
1381
4
原创 300分钟吃透分布式缓存-22讲：怎么认识和应用Redis内部数据结构？
dict 字典中，有一个长度为 2 的哈希表数组，日常访问用 0 号哈希表，如果 0 号哈希表元素过多，则分配一个 2 倍 0 号哈希表大小的空间给 1 号哈希表，然后进行逐步迁移，rehashidx 这个字段就是专门用来做标志迁移位置的。由于 ziplist 是连续紧凑存储，没有冗余空间，所以插入新的元素需要 realloc 扩展内存，所以如果 ziplist 占用空间太大，realloc 重新分配内存和拷贝的开销就会很大，所以 ziplist 不适合存储过多元素，也不适合存储过大的字符串。
2024-03-07 08:50:56
1143
原创 300分钟吃透分布式缓存-21讲：Redis读取请求数据后，如何进行协议解析和处理?
对于非 quit 指令，以 client 中 argv[0] 作为命令，从 server 中的命令表中找到对应的 redisCommand。如果找到 cmd，则开始执行 redisCommand 中的 proc 函数，进行具体命令的执行。client 的读缓冲默认是 16KB，读取命令时，如果发现请求超过 1GB，则直接报异常，关闭连接。协议解析完毕后，将请求参数个数存入 client 的 argc 中，将请求的具体参数存入 client 的 argv 中。请求命令解析完毕，则进入到协议执行部分。
2024-03-07 08:39:50
458
原创 300分钟吃透分布式缓存-20讲：Redis如何处理文件事件和时间事件？
编译时，会按照性能和系统平台，选择最佳的 IO 多路复用函数作为底层实现，选择顺序是，首先尝试选择 Solaries 中的 evport，如果没有，就尝试选择 Linux 中的 epoll，否则就选择大多 UNIX 系统都支持的 kqueue，这 3 个多路复用函数都直接使用系统内核内部的结构，可以服务数十万的文件描述符。Redis 在启动时，在 initServer 中对监听的 socket 注册读事件，事件处理器为 acceptTcpHandler，该函数在有新连接进入时，会被派发器派发读任务。
2024-03-06 23:56:00
1055
原创 300分钟吃透分布式缓存-19讲：Redis系统架构中各个处理模块是干什么的？
在进行 key 读写定位时，首先对 key 做 hash，并将 hash 值对 16383 ，做 按位与运算，确认 slot，然后确认服务节点，最后再对 对应的 Redis 节点，进行常规读写。在主从复制功能中，psyn 在不断的优化，不仅在 slave 闪断重连后可以进行增量复制，而且在 slave 通过主从切换成为 master 后，其他 slave 仍然可以与新晋升的 master 进行增量复制，另外，其他一些场景，如 slave 重启后，也可以进行增量复制，大大提升了主从复制的可用性。
2024-03-06 23:49:47
817
原创 300分钟吃透分布式缓存-18讲：Redis协议的请求和响应有哪些“套路”可循？
对于 Jedis client，它的优势是轻量，简洁，便于集成和改造，它支持连接池，提供指令维度的操作，几乎支持 Redis 的所有指令，但它不支持读写分离。一个常规的例子，“$6\r\nfoobar\r\n”，对于空字串，可以表示为 “比如一个字符串块的数组实例，*2\r\n$3\r\nget\r\n$3\r\nkey\r\n。整数数组实例：”*3\r\n:1\r\n:2\r\n:3\r\n"，混合数组实例："*3\r\n :1\r\n-Bar\r\n$6\r\n foobar\r\n”，空数组：”
2024-02-28 00:31:27
524
原创 300分钟吃透分布式缓存-17讲：如何理解、选择并使用Redis的核心数据类型？
偏移量也可以是负数，倒数第一个是 -1，倒数第二个是 -2，依次类推。需要计算某个位置点 A 附近的人时，首先以指定位置 A 为中心点，以距离作为半径，算出 GEO 哈希 8 个方位的范围， 然后依次轮询方位范围内的所有位置点，只要这些位置点到中心位置 A 的距离在要求距离范围内，就是目标位置点。Redis 的 HyperLogLog 在统计时，如果计数数量不大，采用稀疏矩阵存储，随着计数的增加，稀疏矩阵占用的空间也会逐渐增加，当超过阀值后，则改为稠密矩阵，稠密矩阵占用的空间是固定的，约为12KB字节。
2024-02-28 00:04:23
1073
原创 300分钟吃透分布式缓存-16讲：常用的缓存组件Redis是如何运行的？
Redis 创建之初，使用方直接给 Redis 的节点分配 slot，后续访问时，对 key 做 hash 找到对应的 slot，然后访问 slot 所在的 Redis 实例。Redis 的 master 可以挂载多个 slave，同时 slave 还可以继续挂载 slave，通过这种方式，可以有效减轻 master 的压力，同时在 master 挂掉后，可以在 slave 通过 slaveof no one 指令，使当前 slave 停止与 master 的同步，转而成为新的 master。
2024-02-26 17:16:43
1374
原创 300分钟吃透分布式缓存-12讲：为何MC能长期维持高性能读写？
Mc 中，slabclass 中的 chunk 会首先用 Item 结构体进行初始化，然后存到 freelist 链表中，待需要分配给数据存储时，再从 freelist 中取出，存入 key/value，以及各种辅助属性，然后再存到 LRU 链表及 Hashtable 中，如下图所示。在存储期间，被哈希表、LRU 管理。当然，虽然 slabclass 分配 slab 失败，但并不意味着 Item分配会失败，前面已经讲到，可以通过同步 LRU 淘汰，回收之前分配出去的 Item，供新的存储请求使用。
2024-02-23 20:29:27
1071
原创 300分钟吃透分布式缓存-11讲：MC如何淘汰冷key和失效key?
直到遇到没失效的 key。Mc 中的 key 基本都会有过期时间，在 key 过期后，出于性能考虑，Mc 并不会立即删除过期的 key，而是由维护线程逐步清理，同时，只有这个失效的 key 被访问时，才会进行删除，从而回收存储空间。Mc 中，过期失效 key 的惰性主动删除，是指在 touch、get、gets 等指令处理时，首先需要查询 key，找到 key 所在的 Item，然后校验 key 是否过期，是否被 flush，如果过期或被 flush，则直接进行真正的删除回收操作。
2024-02-23 20:23:19
941
原创 300分钟吃透分布式缓存-10讲：MC是怎么定位key的?
实际上，除了在哈希表，在其他任何时候，只要涉及到在对 Item 的操作，都会根据 Item 中的 key，进行 Item 哈希锁桶加锁，以避免 Item 被同时读写而产生脏数据。Mc 在启动时，会根据设置的工作线程数，来构建 一个 Item 锁哈希表，线程越多，构建的锁哈希表越大，对于 4 个线程，锁哈希表有 4096 个桶，对于 10 个线程，锁哈希表会有 8192 个桶，Item 锁哈希表最多有 32k 个桶，1k 是 1024，即最多即 32768 个桶。本节课，将进一步深入学习这些知识点。
2024-02-22 22:15:33
821
原创 300分钟吃透分布式缓存-09讲：MC是如何使用多线程和状态机来处理请求命令的？
注意 conn_parse_cmd 的状态处理，只有读取到 \n，有了完整的命令首行协议，才会进入 process_command，否则会跳转到 conn_waiting，继续等待客户端的命令数据报文。如果读取失败，则进入 conn_closing 状态，关闭连接。& Worker 线程监听管道，当收到主线程通过管道发送的消息后，工作线程中的连接进入 conn_new_cmd 状态，创建 conn 结构体，并做一些初始化重置操作，然后进入 conn_waiting 状态，注册读事件，并等待网络 IO。
2024-02-22 20:37:53
972
原创 300分钟吃透分布式缓存-08讲：MC系统架构是如何布局的？
当需要查找给定 key 的 Item 时，首先计算 key 的 Hash 值，然后对哈希表中与 Hash 值对应的 bucket 中进行搜索，通过轮询 bucket 里的单向链表，找到该 key 对应的 Item 指针，这样就找到了 key 对应的存储 Item，如下图所示。一般情况下，Item 并不会将 chunk 填满，但由于每个 key/value 在存储时，都会根据 kev/value size，选择最接近的 slabclass，所以 chunk 浪费的字节非常有限，基本可以忽略。
2024-02-22 20:30:47
1272
原创 300分钟吃透分布式缓存-07讲：MC为何是应用最广泛的缓存组件？
虽然 slab 内的 chunk 大小相同，但不同 slab 的 chunk size 并不同，Mc 会按照一个固定比例，使划分的 chunk size 逐步增大，从而满足不同大小 key/value 存储的需要。Mc 并不是将所有数据放在一起来进行管理的，而是将内存划分为一系列相同大小的 slab 空间后，每个 slab 只管理一定范围内的数据存储。Mc 内部是通过 LRU 来管理存储 Item 数据的，当内存不足时，会从 LRU 队尾中剔除一个过期或最不活跃的 key，供新的 Item 使用。
2024-02-21 09:28:24
1063
原创 300分钟吃透分布式缓存-06讲：Hot Key和Big Key引发的问题怎么应对？
你可以通过提前熟悉 Cache 的经典问题，提前构建防御措施， 避免大量 key 同时失效，避免不存在 key 访问的穿透，减少大 key、热 key 的缓存失效，对热 key 进行分流。& 第一种方案，如果数据存在 Mc 中，可以设计一个缓存阀值，当 value 的长度超过阀值，则对内容启用压缩，让 KV 尽量保持小的 size，其次评估大 key 所占的比例，在 Mc 启动之初，就立即预写足够数据的大 key，让 Mc 预先分配足够多的 trunk size 较大的 slab。
2024-02-21 09:23:34
863
原创 300分钟吃透分布式缓存-05讲：缓存数据不一致和并发竞争怎么处理？
如下图所示，在缓存机器的带宽被打满，或者机房网络出现波动时，缓存更新失败，新数据没有写入缓存，就会导致缓存和 DB 的数据不一致。数据并发竞争，主要是由于多个进程/线程中，有大量并发请求获取相同的数据，而这个数据 key 因为正好过期、被剔除等各种原因在缓存中不存在，这些进程/线程之间没有任何协调，然后一起并发查询 DB，请求那个相同的 key，最终导致 DB 压力大增，如下图。数据并发竞争，是指在高并发访问场景，一旦缓存访问没有找到数据，大量请求就会并发查询 DB，导致 DB 压力大增的现象。
2024-02-20 15:42:24
448
原创 300分钟吃透分布式缓存-04讲：缓存失效、穿透和雪崩问题怎么处理？
在一般情况下，一致性 Hash 分布+rehash 策略可以很好得运行，但在较大的流量洪峰到临之时，如果大流量 key 比较集中，正好在某 1～2 个缓存节点，很容易将这些缓存节点的内存、网卡过载，缓存节点异常 Crash，然后这些异常节点下线，这些大流量 key 请求又被 rehash 到其他缓存节点，进而导致其他缓存节点也被过载 Crash，缓存异常持续扩散，最终导致整个缓存体系异常，无法对外提供服务。实际上，在缓存系统的设计架构中，还有很多坑，很多的明枪暗箭，如果设计不当会导致很多严重的后果。
2024-02-19 20:50:29
962
原创 300分钟吃透分布式缓存-03讲：设计缓存架构时需要考量哪些因素？
key 的数量也是一个重要考虑因素。在设计架构缓存时，你首先要选定缓存组件，比如要用 Local-Cache，还是 Redis、Memcached、Pika 等开源缓存组件，如果业务缓存需求比较特殊，你还要考虑是直接定制开发一个新的缓存组件，还是对开源缓存进行二次开发，来满足业务需要。平均缓存穿透加载时间在某些业务场景下也很重要，对于一些缓存穿透后，加载时间特别长或者需要复杂计算的数据，而且访问量还比较大的业务数据，要配置更多容量，维持更高的命中率，从而减少穿透到 DB 的概率，来确保整个系统的访问性能。
2024-02-19 18:55:10
2293
原创 300分钟吃透分布式缓存-02讲：如何根据业务来选择缓存模式和组件？
在部分数据变更后，直接删除缓存。这种模式的特点是，业务端处理所有数据访问细节，同时利用 Lazy 计算的思想，更新 DB 后，直接删除 cache 并通过 DB 更新，确保数据以 DB 结果为准，则可以大幅降低 cache 和 DB 中数据不一致的概率。
2024-02-18 23:33:11
1156
原创 300分钟吃透分布式缓存-01讲：业务数据访问性能太低怎么办？
不过在实际业务场景中，缓存中存储的往往是需要频繁访问的中间数据甚至最终结果，这些数据相比 DB 中的原始数据小很多，这样就可以减少网络流量，降低网络拥堵，同时由于减少了解析和计算，调用方和存储服务的负载也可以大幅降低。缓存的读写性能很高，预热快，在数据访问存在性能瓶颈或遇到突发流量，系统读写压力大增时，可以快速部署上线，同时在流量稳定后，也可以随时下线，从而使系统的可扩展性大大增强。然而不幸的是，任何事情都有两面性，缓存也不例外，我们在享受缓存带来一系列好处的同时，也注定需要付出一定的代价。
2024-02-18 21:51:46
864
原创 DevOps落地笔记-21|业务价值：软件发布的最终目的
通过将有价值的软件、满意的用户与企业的最终业务目标相联系，就能实现企业的业务价值，即商业目标，比如用户量的增长，收入的增加，成本的降低等。结合 DevOps 实践来说，假如搜狗搜索利用 DevOps 实践提高了搜索服务版本更新的速度和搜索的准确性，为更多的用户提供了更好的搜索服务，就会有越来越多的用户选择搜狗搜索，此时就会影响到二者的市场占有率。对于业务价值的度量需要从最终用户的角度出发，衡量用户对产品或服务的认可程度，以及企业在市场上的份额，因为只有这些数据，才能了解企业业务发展的趋势和问题。
2024-02-07 23:24:24
1764
原创 DevOps落地笔记-20|软件质量：决定系统成功的关键
产品的非功能性问题会最终影响用户满意度，一般通过用户反馈的缺陷和问题数量及严重程度来度量产品的可靠性，通过应用程序性能监控系统（APM） 度量产品的性能。既然软件质量如此重要，领导者需要了解当前软件质量是多少，存在什么问题，软件质量的发展趋势是什么，这些就是软件质量的度量。测试覆盖率是衡量代码质量的一个方法，是指自动化测试中代码的覆盖程度，包含单元测试、集成测试、回归测试的测试覆盖率。因此，软件的质量是企业研发的重中之重，也是企业实施 DevOps 的目标之一。总之，给用户带来的影响是不能正常的使用产品。
2024-02-07 23:16:22
2423
原创 DevOps落地笔记-19|响应速度：天下武功，唯快不破
如何度量团队的响应速度？任务的大小也是影响软件交付的因素，当任务的大小不一致，就会导致处理任务的时间不一样，就会产生等待。DevOps 平台中应该记录每次测试的信息，包含测试的总体时长，测试的用例数，测试的成功率等信息，测试的总体时长是测试效率的直接度量，影响因素有执行的用例数和测试的成功率。DevOps 平台中应该记录每次编译的信息，包括代码库、开始编译时间、结束编译时间、编译结果、编译人等信息，在数据统计时，可以统计每天的编译次数、编译时长的中位数，编译成功率，针对编译时长较长的代码库进行优化。
2024-02-06 19:04:11
1592
原创 DevOps落地笔记-18|团队能力：团队能力=交付能力
不同于上层应用程序的部署，私有云的部署是需要从操作系统开始安装，还会涉及改交换机的网卡，规划网络的 Vlan 范围，规划分布式存储的存储池等，这些都需要非常底层的专业知识，哪怕一个小问题都会影响整个云的部署和业务的可用性。我们都知道，软件开发是团队成员完成的，团队成员的能力在一定程度上代表了软件的交付能力。在搭建部署流水线的过程中，遇到过非常多的底层问题，当遇到问题时只能求助基础设施团队的专业同事，但其他团队的同事也会因为有正在处理的工作不能及时帮助解决，导致无法继续，部署工作一再延误。
2024-02-06 17:35:42
1001
原创 DevOps落地笔记-17|度量指标：寻找真正的好指标？
本课时并未详细的介绍任何一个具体的指标，主要介绍了什么样的指标是好指标，如何选择指标和如何使用指标，强调了度量指标在于精，而不是多。比如每个任务都要有开始时间和结束时间，每个事件都应该有发生、处理、解决的时间记录，事物之间的关联（如代码提交与任务或缺陷的关联，代码库与产品线的关联，流水线构建与代码库的关联等）。反馈循环是有效改进的基础，通过度量指标的反馈，有助于更加精准的调整团队的行动，改善整个组织的沟通。在一项重要的指标上哪怕花费更多的成本都是值得的，在一项无用的指标上投入再少的时间也是在浪费。
2024-02-06 16:07:38
1469
原创 DevOps落地笔记-16|案例分析：百度效率云是如何做代码审查的
iCode是基于开源代码评审工具 Gerrit 的代码托管平台，也是采用的 Change Request 机制，当开发人员提交代码后，就会触发 iCode 内置的代码检查和流水线检查，最大程度的保证代码入库的质量。当团队对提交代码的质量有严格要求时，需通过开启代码评审，进行代码检查，来控制提交代码的质量。该模型可以有效管控提交代码的质量，因为每次提交都会生成一个 Code Review，如果代码变更存在问题，那么此次变更就不会合入代码库中，根本不会影响到代码库中的代码。合入后，评审的状态显示为“已合入”。
2024-02-06 15:52:36
1080
原创 DevOps落地笔记-15|混沌工程：通过问题注入提高系统可靠性
混沌工程应该成为传统测试的补充，是经过传统测试后系统已经足够稳定，可以在生产环境中被任意“破坏”，来进一步增强系统的稳定性的工程。混沌工程的核心思想是以可控的方式主动注入故障，以验证系统的行为是否符合我们的预期，并在不正常的情况下进行修复，以此提高系统的稳定性。随着软件工程不断发展，近几年，出现了一种新的实践，这就是今天要介绍的内容——混沌工程，它通过在生产环境中对系统进行破坏，来不断增强软件的健壮性。场景中的攻击按顺序执行，可以更好地控制攻击的执行方式，并可以模拟较为复杂的故障。
2024-02-05 22:32:11
1254
原创 DevOps落地笔记-14|部署流水线：打造一站式部署的关键平台
部署软件是将软件部署到生产环境中，但部署的服务是否发布给用户是由业务决定的。自动化部署平台是部署流水线中的重要组件，通过封装统一的部署流程，提供易用的用户界面，对外提供统一的软件部署的能力。在进行自动化部署时，只需要提供部署的软件版本以及要部署的目标环境，采用什么样的部署策略（只对生产环境有效），点击“开始”按钮，所有的部署过程都是自动化的。因为不管是测试环境、还是生产环境都是相同的部署方式，在向生产环境部署之前，已经在测试环境部署了 n 次了，部署脚本已经非常健壮，能够大大降低向生产环境部署的风险。
2024-02-04 10:17:49
1293
原创 DevOps落地笔记-13|自动化测试：提高测试效率的不二之选
今天介绍的内容——自动化测试，就是将人工完成的测试尽可能地自动化，从而达到减少测试时间，提高测试覆盖率，提高软件质量的目的。这底层的单元测试需要做最多的测试工作，越往上的单元，测试工作越少。本课时的关键内容为与持续集成的流程图和相关组件，自动化测试虽然能带来一定的收益，但自动化测试不是免费的，需要开发相配套的平台来支撑自动化测试有效落地。但从整个测试的过程来看，自动化测试不仅仅是跟代码相关的测试，不仅仅是测试执行过程的自动化，还应该包含测试数据和测试环境的自动化，这里统一称为基础设施的测试。
2024-02-04 09:34:17
1218
原创 DevOps落地笔记-12|API管理：微服务时代的必备工具
API 管理就是有效管理企业内部各服务提供的 API 接口，管理 API 接口的创建、测试、发布等生命周期，以及 API 接口的版本、并提供 API 开发者门户供开发人员查看。服务的 API 接口在构建时自动的注册到 API 管理平台的 API Gateway 中，其他调用方可以通过 API Gateway 访问这些接口提供的服务，并基于 API Gateway 进行 API 的自动化测试，保证 API 的正确性和健壮性。随着时间的推移，API 的变化是不可避免的，比如有新需求可能会导致 API 的变化。
2024-02-03 21:22:22
1233
原创 DevOps落地笔记-11|持续集成：软件持续集成，发布信手拈来
它通过频繁提交，每天多次将团队成员的工作内容进行集成，并通过自动化测试平台验证集成后的系统是否可用，尽早地发现问题，修复问题，使得开发中的软件一直保持可工作的状态。不管是自研的还是开源的，对于应用持续集成实践，版本控制系统提供了基本的版本控制能力，能够记录哪个版本的代码是通过测试的，哪个版本还存在问题，并对有问题的版本进行回滚。要保证每次提交的内容都是有意义的，都是一个完整的任务。这里需要强调的是，虽然开发人员不需要关注除代码开发之外的事情，但对每次提交有要求，比如：要保证每次提交的是一个完整的功能项。
2024-02-03 17:11:04
1387
原创 DevOps落地笔记-10|环境管理：交付测试环境的迅猛方法
采用 Git 仓库存储创建环境的部署脚本的实践，和基础设施即代码的实践是一样的。采用基础设施即代码和 CMDB 结合的方式，在代码库中提供部署模板，在 CMDB 中提供具体环境的配置信息，在部署环境时将该环境具体的配置项替换到模板中，即可完成部署。这不仅降低了环境管理的成本和风险，能够快速的交付环境，并且自动化的过程使得环境的部署是可重复的、时间是可预测的。经过上面的步骤，创建环境所使用的部署脚本模板和相对应的配置项都已经准备好了，下面就通过部署平台将其进行组装，并执行具体的创建环境的任务。
2024-02-03 16:57:38
1270
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人