这是我参与「第三届青训营 -后端场」笔记创作活动的的第7篇笔记
01 接入问题引入
问题引入
浏览器输入网站域名到网页加载出来，都经历了哪些过程？
域名解析
TCP建连
SSL握手
……
02 企业接入升级打怪之路
2.1 使用域名系统
2.1.1 Host管理
Host→ ip映射
随着业务规模和员工数量增长，面临问题：
- 流量和负载：用户规模指数级增长，文件大小越来越大，统一分发引起较大的网络流量和cpu负载
- 名称冲突：无法保证主机名称的唯一性，同名主机添加导致服务故障
- 时效性：分发靠人工上传，时效性太差
2.1.2 使用域名系统
使用域名系统替换hosts文件
域名空间：
- 树形结构
- 通过划分zone的方式进行分层授权管理
- 全球公共域名空间仅对应一棵树
- 根域名服务器：查询起点
- 域名组成格式：[a-zA-Z0-9_-]，以点划分label
2.1.3 域名购买与配置迁移
- 域名购买
- 域名备案
- 修改配置
2.2 自建DNS服务器
2.2.1 问题背景
- 内网域名的解析也得出公网去获取，效率低下
- 外部用户看到内网 ip 地址，容易被 hacker 攻击
- 云厂商权威DNS容易出故障，影响用户体验
- 持续扩大公司品牌技术影响力，使用自己的DNS系统
2.2.3 DNS记录类型
A/AAAA：IP指向记录，用于指向IP，前者为IPv4记录，后者为IPv6记录
CNAME：别名记录，配置值为别名或主机名，客户端根据别名继续解析以提取IP地址
TXT：文本记录，购买证书时需要
MX：邮件交换记录，用于指向邮件交换服务器
NS：解析服务器记录，用于指定哪台服务器对于该域名解析
SOA 记录：起始授权机构记录，每个zone有且仅有唯一的一条SOA记录，SOA是描述zone属性以及主要权威服务器的记录
2.2.4 权威DNS系统架构
站在企业角度，我们需要权威DNS、LocalDNS
常见的开源DNS：bind、nsd、knot、coredns
2.3 接入HTTPS协议
HTTP明文传输，弊端明显
常见加密算法
-
对称加密：一份密钥
- 密钥在传输过程中可能被截获
-
非对称加密：公钥和私钥
- 即使获取公钥，没有私钥也无法获取key
SSL的通信过程
- client random
- server random
- premaster secret
- 加密算法协商
→对称秘钥 session key
证书链
Client 收到会仍然需要验证:
- 是否是可信机构颁布
- 域名是否与实际访问一致
- 检查数字签名是否一致
- 检查证书的有效期
- 检查证书的撤回状态
2.4 接入全站加速
相应慢、卡顿
极大的流失了大部分的用户群体，NPS留存率数据不乐观。
解决方案
源站容量问题 增加后端机器扩容；静态内容，使用静态加速缓存 网络传输问题 动态加速DCDN
全站加速 静态加速+动态加速
静态加速CDN 缓存
动态加速DCDN 针对POST等非静态请求等不能在用户边缘缓存的业务, 基于智能选路技术，从众多回源线路中择优选择一条线路进行传输
2.5 四层负载均衡
定义： 基于IP+端口， 利用某种算法将报文转发给某个后端服务器, 实现负载均衡地落到后端服务器上。
三个主要功能：
- 解耦vip和rs
- NAT
- 防攻击：syn proxy
常见的调度算法原理
- RR轮询：Round Robin，将所有的请求平均分配给每个真实服务器RS
- 加权RR轮询：给每个后端服务器一个权值比例，将请求按照比例分配
- 最小连接：把新的连接请求分配到当前连接数最小的服务器
- 五元组hash：根据sip、sport、proto、dip、dport对静态分配的服务器做散列取 模
- 缺点：当后端某个服务器故障后，所有连接都重新计算，影响整个 hash 环
- 一致性hash：只影响故障服务器上的连接session，其余服务器上的连接不受影响
常见的实现方式FULLNAT
RS怎么知道真实的CIP？
- 通过TCP option字段传递，然后通过特殊的内核模块反解
4层负载均衡特点
- 大部分都是通过 dpdk 技术实现，技术成熟，大厂都在用
- 纯用户态协议栈，kernel bypass，消除协议栈瓶颈
- 无缓存，零拷贝，大页内存（减少 cache miss）
- 仅针对4层数据包转发，小包转发可达到限速，可承受高 cps
2.6 7层负载均衡
有一些7层相关的配置需求，该怎么做？
- SSL卸载：业务侧是 http 服务，用户需要用 https 访问
- 请求重定向：浏览器访问 toutiao.com 自动跳转 www.toutiao.com
- 路由添加匹配策略：完全、前缀、正则
- Header编辑
- 跨域支持
- 协议支持：websocket、grpc、quic
Nginx简介
- 模块化设计，较好的扩展性和可靠性
- 基于 master/worker 架构设计
- 支持热部署；可在线升级
- 不停机更新配置文件、更换日志文件、更新服务器二进制
- 较低的内存消耗：1万个 keep-alive 连接模式下的非活动连接仅消耗2.5M内存
- 事件驱动：异步非阻塞模型、支持 aio，mmap（内存映射）
异步非阻塞
- 传统服务器： 一个进程/线程处理一个连接/请求 阻塞模型、依赖OS 实现并发
- Nginx: 一个进程/线程处理多个连接/请求 异步非阻塞模型、减少OS 进程切换
提升CPU使用效率
-
合适的worker进程数 Worker进程数= CPU 核数
-
CPU亲和 每个worker 程绑定一个CPU核，提升缓存命中率
-
减少CPU开销
multi_accept允许worker同时接受新连接
accept_mutex解决惊群问题
reuseport 监听同端口，内核负载均衡
提升网络效率
- 连接复用 减少upstream建连
- 使用Cache 超时时间对业务的影响
- gzip压缩 会增加cpu开销，需平衡使用
- 开启proxy_buffering 谨慎设置proxy_buffer 大小，磁盘io读写
