基于 C++ 手写 Muduo 高性能网络库
大纲
前言
本文将基于 C++ 开发一个类似 Muduo 的高性能网络库,项目代码大部分都是从 Muduo 移值过来,同时去掉 Boost 依赖,并使用 C++ 11 进行代码重构,重点是学习 Muduo 的底层设计思想(尤其是 Multiple Reactors 模型)。

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