将我的服务开放给用户 | 青训营笔记

76 阅读5分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的第 4 篇笔记

01 问题引入

1.1 浏览器抓包

image-20220521110542416.png

1.2 字节接入框架

image-20220521110620774.png

02 企业接入

2.1 域名系统

2.1.1 Host管理

员工通过FTP协议拉去主机Host配置。

随着example公司业务规模和员工数量增长,使用该方式面临诸多问题:

  • 流量和负载:用户规模指数级增长,文件大小越来越大,统一分发引起较大的网络流量和cpu负载
  • 名称冲突:无法保证主机名称的唯一性,同名主机添加导致服务故障
  • 时效性:分发靠人工上传,时效性太差

2.1.2 使用域名系统

使用域名系统替换hosts文件

关于域名空间:

  • 域名空间被组织成树形结构
  • 域名空间通过划分zone的方式进行分层授权管理
  • 全球公共域名空间仅对应一棵树
  • 根域名服务器:查询起点
  • 域名组成格式:[a-zA-Z0-9_-],以点划分label

image-20220521111355005.png

2.1.3 域名购买与配置迁移

域名购买

购买二级域名

域名备案

2.1.4 如何开放外部用户访问

方案:租赁一个外网ip,专用于外部用户访问门户网站,将www.example.com解析到外网ip 100.1.2.3,将该ip绑定到一台物理机上,并发布公网route,用于外部用户访问。

image-20220521111935339.png

2.2 自建DNS服务器

2.2.1 问题背景

内网域名的解析也得出公网获得,效率低下; 外部用户看到内网ip地址,容易被hacker攻击; 云厂商权威DNS容易出故障,影响用户体验; 持续扩大公司品牌技术影响力,使用自己的DNS系统

2.2.2 DNS查询过程

image-20220521112257866.png

2.2.3 DNS记录类型

image-20220521112625982.png

image-20220521112813260.png

SOA类型举例:

image-20220521112856825.png

2.2.4 权威DNS系统架构

站在企业角度思考,我们需要的是哪种DNS服务器? 权威DNS,LocalDNS(可选)

常见的开源DNS:bind、nsd、knot、coredns

2.2.5 权威DNS系统架构

image-20220521133225645.png

2.3 接入HTTPS协议

2.3.1 背景

HTTP明文传输弊端越来越明显

2.3.2 对称加密和非对称加密

常见的加密算法

对称加密:一份密钥

非对称加密:公钥和私钥

非对称加密算法 RSA

公钥加密后只能用私钥解密。

私钥加密后可以用公钥解密(这种方式就是数字签名)。

2.3.3 SSL的通信过程

image-20220521133823122.png

2.3.4 证书链

Sever端发送是带签名的证书链

2.3.5 使用https

image-20220521134442076.png

2.4 接入全站加速

2.4.1 问题背景

外网用户访问站点,一定是一帆风顺的吗?可能出现的问题有哪些?

源站容量低,可承载的并发数低,容易被打垮。 报文经过的网络设备越多,出问题的概率越大,丢包、劫持、mtu问题。 自主选路网络链路长,时延高。

极大的流失了大部分的用户群体,NPS留存率数据不乐观

2.4.2 解决方案

image-20220521135550198.png

2.4.3 静态加速CDN

image-20220521141254840.png

静态加速的优势:

image-20220521141557194.png

2.4.4 动态加速DCDN

针对POST等非静态请求等不能在用户边缘缓存的业务,基于智能选路技术,从众多回源路线中择优选择一条线路进行传输。

image-20220521141851141.png

2.4.5 DCDN原理

RTT:

  • 用户到核心:35ms
  • 用户到边缘:20ms
  • 边缘到汇聚:10ms
  • 汇聚到核心:10ms

image-20220521142506879.png

2.4.6 使用全站加速

1、用户首次登录抖音,注册用户名手机号等信息 动态加速DCDN

2、抖音用户点开某个特定的短视频加载后观看 静态加速CDN

3、用户打开头条官网进行网页浏览 静态加速CDN+动态加速DCDN

image-20220521142824533.png

2.5 4层负载均衡

2.5.1 背景

在运营商租用的100.1.2.3的公网IP,如何在企业内部使用最合理?

直接找一个物理机,ifconfig将网卡配上这个IP,起Sever监听即可 应用多,起多个server监听不同端口即可 租用多个公网IP

资源有限!

2.5.2 什么是4层负载均衡?

基于IP+端口,利用某种算法将报文转发给某个后端服务器,实现负载均衡地落到后端服务器上。

image-20220521143218860.png

2.5.3 常见的调度算法原理

  1. RR轮询:Round Robin,将所有的请求平均分配给每个真实服务器RS。

  2. 加权RR轮询:给每个后端服务器一个权值比例,将请求按照比例分配。

  3. 最小连接:把新的连接请求分配到当前连接数最小的服务器。

  4. 五元组hash:根据sip、sport、proto、dip、dport对静态分配的服务器做散列取模。 缺点:当后端某个服务器故障后,所有连接都重新计算,影响整个hash环。

  5. 一致性hash:只影响故障服务器上的连接session,其余服务器上的连接不受影响。

2.5.4 常见的实现方式FULLNAT

image-20220521144153317.png

2.5.5 4层负载均衡特点

image-20220521144311102.png

2.5.6 使用4层负载均衡

image-20220521144518598.png

2.6 7层负载均衡

2.6.1 问题背景

image-20220521144614577.png

2.6.2 Nginx简介

image-20220521144843860.png

2.6.3 Nginx和Apache性能对比

image-20220521144920945.png

2.6.4 Nginx简介

image-20220521145037967.png

2.6.5 Nginx反向代理示意图

image-20220521145115835.png

Nginx内部架构:

image-20220521145142241.png

2.6.6 事件驱动模型

image-20220521145552981.png

2.6.7 异步非阻塞

image-20220521145707170.png

2.6.8 提升CPU使用效率

image-20220521150047887.png

2.6.9 提升网络效率

image-20220521150220638.png

2.6.10 使用7层负载均衡

image-20220521150331404.png

03 动手实践

3.1 DNS服务器搭建

image-20220521150709623.png

3.2 四层负载均衡实验

image-20220521150739146.png

image-20220521150839521.png

image-20220521150853124.png

3.3.7 7层负载均衡实验

image-20220521150939997.png

3.4 SSL自签证书实验

3.5 如何将本地服务开放外网访问

Ngrok,Expose your localhost to the web

使用条件:使用Guthub账户授权登录即可使用。

image-20220521151431330.png

image-20220521151451890.png