分类目录归档：DevOps

架构师图谱·番外篇之研发效能

1. 如何理解研发效能

研发效能的完整定义应该是：团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三个方面。简单来说，就是能否长期、高效地交付出有价值的产品。

在互联网行业内卷加剧的情况下，如何能更好的破局，而不是一味的推崇996，研发团队的效率就显得格外重要。开发流程的顺畅是生产优质软件的关键因素，只有这样才能最大程度地释放开发者的创造性和积极性，所以提高“研发效能”，我们更多的是围绕整个软件开发的生命周期，这里就不得不说一下“DevOps”和“云原生”。

2. DevOps

DevOps=Developers+Operators，字面上看，是指开发团队和运维团队一体化，通过工具辅助开发完成运维的部分工作，减少成本，尽可能地为公司创造更多价值。但是我们知道，任何一个产品或者项目从最初的需求意愿到最终的上线交付，中间不仅仅是只有开发、运维两两个角色就能完成，还包含产品、测试、QA、甚至商务、销售团队的人员共同参与才能完成。 因此在人们不断的实践过程中，DevOps逐渐扩展为整个软件研发过程的管理思想和方法论，它：​

  • 是一组过程、方法与系统的统称，包含开发、测试和运维；
  • 重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例，改善团队之间的协作关系；
  • 用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合；
  • 透过自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠，按时交付软件产品和服务；

DevOps在实施的过程中，往往是由最了解整个系统的开发人员来负责生命周期，包括自动化测试、线上服务观测，而传统的测试团队来为测试平台、工具提供支撑，运维（SRE）团队为运维平台、工具提供支撑。 DevOps其实就是通过打通Dev和Ops来提高研发效能，结合持续集成、持续交付、持续部署来提升交付效能。为了实现DevOps，除了团队协作、文化这些软性因素，更重要的是CI/CD流水线的建设。

2.1 CI/CD

CI/CD是指持续集成（Continuous Integration, CI)、持续交付（Continuous Delivery, … 阅读全文

容器化架构迁移升级实战

背景

我们现在主体业务已经是部署在某云上了，但整个技术体系，还是基于传统的虚拟机去承载的，由于我们产品本身的媒体属性，导致了不可避免的会经常遇到突发流量，相比与一直比较平稳的流量，这种对服务端的考验更高，核心关注点还是在怎么保障在这种时刻用户都能得到良好的体验。

另一方面，由于云平台本身的一些不可抗力因素，不能保证百分百的高可用，怎么降低单点依赖的风险，也是我们需要重点考虑的。

经过综合性的权衡，我们决定把主体业务迁移到华为云，并且优化升级原来的架构，以便更好的支撑海量用户访问。前端机也从VM过渡到docker，迁移后的整体架构图如下

各个资源的迁移过程

1. mc迁移

现在业务上使用mc只是做临时缓存，cache miss会从存储（DB、ES等）拉一份写进去，并且业内也没有比较成熟的mc存量与增量迁移方案，所以这部分数据可以忽略，等上线前，预热一部分热点数据进去。不过使用上有一些区别，原平台使用的是服务端集群，现在是客户端集群，需要建立MC连接的时候，添加所有的服务器列表以及权重。

2. mq迁移

mq主要用来解耦业务模块，生产端生产一份数据，消费端可能有多个，迁移的话，需要先配置好资源的vhost，exechange还有queue，服务端先更新配置上线，数据写入到新资源，消费端在旧资源消费完成后，切换到新资源的消费上。

3. redis迁移

redis的迁移需要区分两个场景的数据，一个是缓存数据，可以按照mc的迁移策略忽略，另一部分是持久化数据，主要是业务上的各种计数，这部分数据要求尽量精确快速的迁移到新资源，当时考虑了两种方案

  • 一种呢，是基于快照文件迁移 存量数据可以通过RDB快照，只需要原平台有备份RDB的权限，在新资源通过快照回放完成全量数据的迁移。 这种方案优点比较突出，操作简单快速，但缺点是不支持增量同步。
  • 另一种呢，基于业务迁移 首先，读
… 阅读全文

Nginx、FPM配置及优化

Nginx配置

nginx的配置主要分为6个区域，main（全局设置），events（工作模式），http（http服务），upstream（负载均衡），server（主机设置），location（url规则）。

main
events {

}
http {
    upstream domain {

    }
    server {
        location {

        }
    }
}

main模块

… 阅读全文

详解nginx及FPM平滑重启

平滑重启

GR是Graceful Restart（平滑重启）的简称，是一种在协议重启时保证转发业务不中断的机制。 GR机制的核心在于：当某设备进行协议重启时，能够通知其周边设备在一定时间内将到该设备的邻居关系和路由保持稳定。在协议重启完毕后，周边设备协助其进行信息（包括支持GR的路由/MPLS相关协议所维护的各种拓扑、路由和会话信息）同步，在尽量短的时间内使该设备恢复到重启前的状态。在整个协议重启过程中不会产生路由振荡，报文转发路径也没有任何改变，整个系统可以不间断地转发数据。这个过程即称为平滑重启。

nginx平滑重启

nginx进程分为master主进程和worker工作进程，nginx的平滑重启通过信号HUB控制。

hup.png | center | 827x338

注：在POSIX兼容的平台上，SIGUSR1和SIGUSR2是发送给一个进程的信号，它表示了用户定义的情况。

为了详细分析nginx的平滑重启过程，我们持续监控nginx进程变化。 发送HUP信号

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

nginx_1.png | center | 827x126

nginx_2.png | center | 827x136

nginx_3.png | center | 827x83

通过观察，可以分析出大致的平滑重启过程为： 1. master使用新配置 fork出n-1个worker及新master 2. 新worker处理新情求，旧worker执行完退出 3. … 阅读全文