基于 C++ 手写 Muduo 高性能网络库
大纲
前言
本文将基于 C++ 开发一个类似 Muduo 的高性能网络库,项目代码大部分都是从 Muduo 移值过来,同时去掉 Boost 依赖,并使用 C++ 11 进行代码重构,重点是学习 Muduo 的底层设计思想(尤其是 Multiple Reactors 模型)。
Kubernetes 中实现 Nginx 配置信息自动热加载
Nginx 配置信息自动热加载
在生产环境中,Nginx 的配置信息通常是通过 Kubernetes 的 ConfigMap 进行存储和管理。为了在 ConfigMap 更新后,让 Nginx 自动加载最新的配置信息(即热加载,不会重启 Pod,不会中断现有请求),可以采用以下几种方案:
| 方案序号 | 方案名称 | Nginx 是否可以直接 Reload | 优点 | 缺点 |
|---|---|---|---|---|
| 方案一 | 容器之间共享进程命名空间 | 可以 | 简单有效 | 依赖 shareProcessNamespace(共享进程命名空间),容器间进程可见,安全性较低 |
| 方案二 | 部署 Reload Agent | 可以 | 安全隔离 | 实现复杂一点 |
方案选择建议
- 如果是在开发或测试环境中简单实现 Nginx 配置信息自动热加载,推荐使用方案一(容器之间共享进程命名空间)。
- 如果是在生产环境中实现 Nginx 配置信息自动热加载,推荐使用方案二(部署 Reload Agent),避免跨容器进程控制,隔离性更好。
分库分表后,生产环境如何实现不停机迁移数据
Kubernetes 入门教程之一
大纲
- Kubernetes 入门教程之一、Kubernetes 入门教程之二、Kubernetes 入门教程之三
- Kubernetes 入门教程之四、Kubernetes 入门教程之五、Kubernetes 入门教程之六
- Kubernetes 入门教程之七、Kubernetes 入门教程之八、Kubernetes 入门教程之九
- Kubernetes 入门教程之十
Kubernetes 简单介绍
各种部署方式的区别
传统的应用部署方式是通过插件或脚本来安装应用,这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新、回滚等操作;当然也可以通过创建虚拟机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。新的方式是通过部署容器方式实现,每个容器之间互相隔离,每个容器有自己的文件系统,容器之间进程不会相互影响,能区分计算资源。相对于虚拟机,容器能够快速部署,由于容器与底层设施、机器文件系统解耦的,所以它能在不同云、不同版本操作系统间进行迁移。容器占用资源少、部署快,每个应用可以被打包成一个容器镜像,每个应用与容器间成一对一关系也使容器有更大优势,使用容器可以在 build 或 release 的阶段,为应用创建容器镜像,因为每个应用不需要与其余的应用堆栈组合,也不依赖于生产环境基础结构,这使得从研发到测试、生产能提供一致环境。类似地,容器比虚拟机轻量、更 “透明”,这更便于监控和管理。
