字节跳动青训营讲师非常用心给大家整理了课前、中、后的学习内容,同学们自我评估,选择性查漏补缺,便于大家更好的跟上讲师们的节奏,祝大家学习愉快,多多提问交流~
第七节:从需求到上线全流程
概述
课程背景: 作为后端研发同学,在一个完整的需求交付周期内究竟要做哪些事情?在各个阶段需要跟不同的角色和平台打交道。介绍常见的研发模式和迭代流程,以实际的例子让同学感受一下后端研发的日常,能够提升大家在团队中协作的能力。
课程目标:
- 提升对流程的认知
- 熟悉在公司大团队中协作开发
- 对职业生涯的日常有更直观的理解
课前 (必须)
词汇表
分类 | 英文 | 中文 | 解释 |
---|---|---|---|
研发模式 | Waterfall Model | 瀑布模型 | 瀑布模型(Waterfall Model)最早强调软件或系统开发应有完整之周期,且必须完整的经历周期之每一开发阶段,并系统化的考量分析与设计的技术、时间与资源之投入等。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制,因此能有效的确保系统质量,它已经成为软体业界大多数软件开发的最初标准 |
The Scaled Agile Framework(SAFe) | 规模化敏捷框架 | ||
Scrum | Scrum | 在软件工程中,Scrum是以经验过程为依据,采用迭代、增量的方法来提高产品开发的可预见性并控制风险的理论,Scrum不是一种过程,也不是一项构建产品的技术,而是一个框架,在Scrum框架中可以应用各种过程和技术,Scrum的作用是让开发实践方法的相对功效显现出来以便随时改进。 Scrum是敏捷(Agile)开发的一种实践模式,敏捷开发强调拥抱需求变化,快速响应不断变化的需求,并尽可能快地提供可以工作的软件产品,敏捷最强调的是可以正常工作的软件产品,文档等不是非常的强调(并非不要文档,只是需要必要的文档),敏捷理论认为面对面的沟通交流远比文档更有效。 敏捷开发的Scrum模式是以价值驱动(Value-Driven)的开发模式,即认为用户的需求并不一定需要100%实现,最重要的是将对用户最有价值的功能实现并交付. | |
流程中的概念 | Scrum Master | 敏捷教练 | Scrum Master是Scrum教练和团队带头人,确保团队合理的运作Scrum,并帮助团队扫除实施中的障碍 |
Product Owner | 产品负责人 | 产品负责人,确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品投资回报率负责; | |
Agile Release Train | 敏捷发布火车 | 敏捷开发的一种发布模式 | |
RD | 研发工程师 | RD一般指Research and Development Engineer,即研发工程师。 | |
PM | 产品经理 | 产品经理 | |
PRD | 产品需求文档 | 产品需求文档 | |
RD | 研发工程师 | RD一般指Research and Development Engineer,即研发工程师。 | |
UED | 交互设计师 | 用户体验设计师,交互设计师,界面设计师 | |
QA | 测试工程师 | 指理解产品的功能要求,并对其进行测试,检查软件有没有缺陷(Bug),测试软件是否具有稳定性(Robustness)、安全性、易操作性等性能,写出相应的测试规范和测试用例的专门工作人员。 | |
Backlog | 待办事项 | 产品订单(product backlog)是整个专案的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要生产什么样的产品。产品订单是开放的,每个人都可以编辑。产品订单包括粗略的估算,通常以天为单位。估算将帮助产品负责人衡量时程表和优先级(例如,如果"增加拼写检查"特性的估计需要花3天或3个月,将影响产品负责人对该特性的渴望)。
冲刺订单(sprint backlog)是大大细化了的文档,包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位,没有任务可以超过16个小时。如果一个任务超过16个小时,那么它就应该被进一步分解。冲刺订单上的任务不会被分派,而是由团队成员签名认领他们喜爱的任务。 | |
Grooming Meeting | Grooming会议 | 这个会议上面会由PO来描述下个迭代需要实现的功能,大家讨论要不要干 | |
Planning Meeting | Planning会议 | 这个会议讨论功能具体什么时候干,要估算任务的工作量 | |
基础知识 | CNCF | 云原生计算基金会 | 云原生计算是软件开发中的一种方法,它利用云计算“在现代动态环境(例如公共云、私有云和混合云)中构建和运行可扩展的应用程序”。 通过声明性代码部署的容器、微服务、无服务器功能和不可变基础设施等技术是这种架构风格的常见元素。 |
Kubernetes | K8S | 生产级别的容器编排系统。Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 | |
FAAS | 函数即服务 | 函数即服务。仅通过编写函数(function)就能够发布为一个 API 或者服务,实现业务功能的技术体系。由于处理单元为函数粒度,往往底层也能够支持自动扩缩容地更精细化使用计算资源,开发侧支持事件驱动,可由消息或多种 Hook 触发,同时拥有快速上线、按需付费等优点。 | |
APAAS | 平台即服务 | 是一个为应用程序服务提供开发和部署环境的云服务 | |
IDE | IDE | 用于提供程序开发环境的应用程序。一般包括代码编辑器、编译器、调试器和图形用户界面等工具 | |
Git | Git | 分布式的版本管理系统 | |
Merge/Rebase | 合并/变基 | 处理代码分支的操作,将不同的分支整合成一个的两种方式 |
课中
1. 为什么要有流程
团队规模和流程的关系
随着团队规模和问题复杂度的上升,一个人搞定一切就不可能了,超过了一个人,就需要进行团队协作,自然也就需要有流程。
常见的协作模式:
- 瀑布模型
- 敏捷开发
- 规模化敏捷
后端的定位
-
瀑布模式
-
按照时间节点参与会议,产出文档(系统分析,概要设计,详细设计,接口文档,提测文档等)
-
按照时间节点交付测试
-
按照时间节点发布
-
-
敏捷团队
-
跟随迭代制定规划,进行开发
-
参与待办事项整理会议(Backlog Grooming Meeting)
- PO描述下个迭代希望实现的用户故事
-
迭代计划会议(Sprint Planning Meeting)
- 选择迭代的任务和估算工作量
-
每日站会(Standup Meeting)
- 昨天你做了什么?
- 今天你将要做什么?
- 你有需要帮助的地方吗?
-
评审会(Retrospective Meeting)
- 小组向产品负责人展示迭代工作结果
-
反思会(Retrospective Meeting)
- 在每个迭代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好
-
团队协作
一个具体的迭代时间表:
2. 有哪些流程
需求阶段
- 不要浪费时间讨论不应该存在的问题
- 站在用户的角度思考
- 给出后端系统视角的建议,估算任务优先级
开发阶段
-
云原生下的开发:
- 容器化技术
- 微服务技术
- WebIDE
-
团队分支策略:
- 为什么会有分支策略
- 有哪些分支策略
- 合并的方式
-
代码规范
- 养成良好的注释习惯,超过三个月的代码,自己都会忘了当时在想什么
- 不要有魔法数字,魔法字符串
- 重复的逻辑抽象成公共的方法,不要copy代码
- 正确使用IDE的重构功能,防止修改错误
-
自测
- 单元测试
- 功能环境测试
- 测试数据构造
-
文档
- 大型改造需要有技术设计文档,方案评审
- 好的接口文档能更方便的和前端进行沟通
测试阶段
- 功能测试
功能测试,是为了测试一个新开发的功能,因此需要有能模拟线上的开发和测试环境,环境之间能相互隔离,这样可以独立验证不同的新功能
- 集成测试:集成测试,是为了把几个功能合在一起测试,因为可能各个新功能独立测试没有问题,但是合在一起却产生了bug
- 回归测试:回归测试是为了验证老的功能不被新的改动影响
发布阶段
-
各种发布模式
-
蛮力发布:简单粗暴,直接用新版本覆盖老版本。
-
金丝雀发布:由于金丝雀对瓦斯极其敏感,因此以前矿工开矿下矿洞前,先会放一只金丝雀进去探是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得名。
-
滚动发布:每个实例都通过金丝雀的方式逐步放大流量,对用户影响小,体验平滑
-
蓝绿发布:常备两个集群,先把流量全部切换到Group 1,升级Group2,然后再把流量全部切换到Group 2,升级Group 1。最终恢复流量。
-
红黑发布:与蓝绿发布类似,但是日常只有一个集群工作,发布时扩容一个集群升级新版本,切换流量后下掉老版本的集群。
-
-
发布过程要做的事
-
发布负责人
- 负责按照计划执行发布
- 需要通知各个相关人员发布进展
- 观察各个服务的发布状态,及时处理异常
-
变更服务的相关RD
- 按照上线checklist检查服务的日志,监控,响应上线过程中的告警
- 对于自己负责的改动,在小流量或者是预览环境进行功能验证
- 执行发布计划中的其他操作(如线上配置,数据处理等)
-
值班同学
- 发布过程中的监控和告警需要特别关注,如果有异常需要立刻判断是否由变更引起
- 如果有变更引起的告警或者用户反馈,需要及时中止发布
-
运维阶段
3. 怎样执行流程
DevOps
-
效率竖井
- 流程中实际产生价值的部分很短
- 大量的时间用在等待和传递上
- 人和人之间的沟通很慢
-
DevOps解决方案
- 代码管理
- 自动化测试
- 持续集成
- 持续交付
全流程自动化
-
通过效能平台串联各个阶段
- 需求发起研发流程的自动化
- 写代码,测试环境部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
-
减少无价值的等待
- 分析整个流程的耗时,计算真正产生价值的时间
- 不断优化流程,让有价值的流程时间占比上升
参考文献
- Scrum: zh.wikipedia.org/wiki/Scrum
- 常用的发布模式:www.cnblogs.com/Leo_wl/p/14…
第八节:打开抖音互联网会发生什么
概述
本节课程主要以刷抖音时的底层互联网交互作为切入点,带大家回顾了计算机网络的相关知识,并结合实际生产环境去理解网络的优化方向和稳定性建设。课程主要分为四个方面:
- 网络接入协议
- 网络传输协议
- 网络优化
- 网络稳定
课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念,同学们可以提前查询预习;课中部分主要结合实际生产环境理解课本中的一些知识;课后部分是一些问题和参考博客,帮助同学们在课后梳理本课程的重点。
课前
TCP/IP官方标准上并没有网络接入/网络传输协议的区别,这里作者是为了方便大家做一些区分,自己定义了这两大块知识,希望学员不要将这两个概念固化,尽量有自己的理解。
课程涉及知识点预习
结合课本知识/网络博客复习相关的知识点,主要如下:
网络接入协议/概念
- MAC地址
- 路由协议
- ARP协议
- IP协议
- NAT
网络传输协议
- DNS
- UDP
- TCP
- HTTP
- HTTPS
- HTTP2.0
- QUIC
课程涉及软件/环境安装搭建
操作系统
由于当下互联网的服务端程序以及网络环境大多都是Linux操作系统。所以强烈建议学员有一套可正常运行的Linux环境,如果你没有这个环境,可以:
- 参考一些互联网博客,将你的主机安装成Linux环境(需要安装界面版本,方便安装wireshark)
- 参考一些互联网博客,在你的主机上搭建Linux虚拟机
- 购买/试用一些云厂商的云主机服务(一半默认centos/debian等Linux内核的操作系统)
抓包软件
建议在Linux安装tcpdump软件(apt/yum命令安装,参考相关博客。如无法安装,可以下载源码安装www.tcpdump.org/)
安装wireshark(根据你的主机选择安装版本www.wireshark.org/,如果是Linux主机…
课前思考题
时间有限,我们无法尽善尽美的给出整个计算机网络的知识和应用,比如下面的这些知识,建议带着这节课的内容再去思考。
- 按照 TCP/IP 的模型示意图,能否画出数据包的拆包/封包?
- TCP 的拥塞算法有哪些?课件建议熟练掌握。
- 建议熟练掌握 socket 编程。
- 建议阅读 golang/java 等高级编程下的 net 相关库的源码。
- 了解 Linux kernel 的网络包从收到包到用户态,从用户态发包到网卡整个流程?
课中
引言
思考:为了让抖音工作,网络需要哪些交互?
网络接入
-
互联网的接入:网络拓扑的整体认知
-
路由发包原理:
- 同网段:配置网段即可默认添加静态路由。获取对端MAC直接发包
- 跨网段:配置网关路由。获取网关MAC地址发包
- 动态路由:BGP/OSPF等,路由表在动态变化
- 路由是网状的,不一定是对称的
-
ARP协议
- ARP广播/应答:协议原理
- 免费ARP:主动广播告知MAC地址
- ARP代理:虚拟网络/伪造MAC地址
-
IP协议
- IPv4:互联网终端节点的唯一标识
- IPv6:不仅仅是IP地址长度的增加
-
NAT
- NAT上网:家用路由器
- NAT出网:机房内网主机上外网
- NAT原理:注意不仅仅是源地址变换,源端口/校验和/SEQ等都会变化
网络传输
- 数据包:本质上是一段内存,里面存储的内存是有序的,一般是按照TCP/IP的多层协议去封装。拆包/封包都是按照协议去写内存/读内存。
- DNS递归迭代
-
UDP
- 协议简单
- 需要考虑可靠性的场景使用复杂
-
TCP
- 三次握手:确认传输的序列号/MSS/Option字段,建立连接
- TCP连接:是一个虚拟的概念,本质上两倍维持一段内存,记录连接状态,就是session
- TCP传输:理解sequence number/acknowledge number
- 丢包重传:理解丢包怎么感知并重传,理解快速重传发生在什么时候
- 滑动窗口:课后自学
- 流量控制:课后自学
-
HTTP
- HTTP比TCP好在哪里:方便
- HTTP1.1的优化:长连接是重点
-
HTTPS
- HTTPS的产生背景:加密/可靠/防劫持
- SSL/TLS握手:非对称加密/对称加密
网络提速
-
HTTP2.0
- 多路复用:依然有队头阻塞
-
QUIC
-
QUIC的产生背景和背后思考:
- 为什么在用户态实现?内核的更新迭代频率较低,不好推广
- 为什么用UDP?TCP的队头阻塞问题不好解决,推倒重来&复用所有操作系统基本都支持的底层协议
-
-
数据中心建设
- 多运营商接入:同运营商内部访问,避免跨运营商的流量
- 有边缘机房/汇聚机房/中心机房
- CDN静态缓存系统:边缘机房的建设,优先访问边缘机房,缓存命中视频/图片等静态内容
- DSA动态加速系统:分四层/七层动态加速。核心在于利用可控节点做路径探测和规划。
网络稳定
-
对容灾的理解
-
网络容灾的具体案例
- 机房专线故障:环路容灾,避免某条专线故障导致机房孤岛问题(专线是连接各个机房的网络物理路径)
- 单机房接入节点故障:DNS容灾,摘除故障的节点-字节GTM系统
- 云控容灾:云端交互,服务器/云上下发命令到终端-字节TNC系统
- cache容灾:源站不可用,降级到之前的缓存内容-字节TLB/ByteCDN等系统的容灾建设
-
故障排查
- 加强故障沟通-明确故障
- 故障止损要在第一时间做(灾备预案的建设)
- 熟悉常用的故障排查命令
-
故障排查的具体案例
- 服务端配置异常(健康检查异常)
- 客户端某个例异常(客户端自己配置错误)
- 外部运营商故障
- 复杂故障的排查:需要抓包,具体问题具体分析
课后
课后作业1- UDP socket 实现 ack,感知丢包重传
作业要求:
- 学会 UDP socket 编程
- 先从简单的 ack 学习,客户端等待 ack 再发包
- 什么时候客户端认为是丢包?
- 重传怎么考虑效率?
- 能不能不阻塞只穿丢掉的中间的段?
课后作业2- 三台同网段内的服务器,模拟实现一个路由器
方法一: Linux 操作系统配置法
提示:
- 了解Linux的路由配置方式
- 确保是同网段直连可达的环境。在三台机器上另外配置IP网段和路由
- 一台机器做客户端,一台机器做路由器,一台机器做服务端
- 客户端配置到达服务器的下一跳指向路由器,路由器上配置到达服务端的路由
方法二: 用户态 socket 编程实现简易 route 软件
提示:
- 收到指定的包后,做转发
- 注意是修改报文的 MAC ,不是修改 IP
- 实现一个对称路由。这样可以实现 TCP 交互
- 可以通过 ping 来验证
- 可以支持 traceroute 吗?
文献推荐
- 《TCP/IP 详解》-计算机网络指导手册
- 《Linux Kernel develepment》-初步窥探内核实现
- 《深入理解 Linux 网络技术内幕》-TCP/IP 底层编码
第九节:将我的服务开放给用户
写在前面
本手册在开讲前会提前发放给用户,意在让学员提前学习接入依赖的基本组件都有哪些以及相关的有名词;因为此次课程是偏实践性质的课程,故会让学员提前了解和熟悉组件工具的使用;
因为大部分的接入都需要有网络等底层基础设施的支持,而此次课程由于学员数量多,资源申请以及管理都比较麻烦,故会尽可能的让同学们使用本地网络去模拟实际的接入过程,有些组件例如全站加速由于缺乏实际的基础设施难以去模拟故会跳过。
一、专有名词 (必须)
- 权威DNS:保存了相应域名的权威信息。权威DNS即通俗上“这个域名我说了算”的服务器
- LocalDNS:缓存+递归查询,运营商(集团网)部署的本地DNS服务器,直接接受网内客户端请求
- 根DNS服务器:全球有13台,LocalDNS未命中缓存查询的起点服务器,其公网地址具体可参考www.iana.org/domains/roo…
- DNS Update:DNS主服务器master接受外部的变更指令
- DNS Notify:DNS主服务器master接受变更命令后,会自增自身的serial号,同时将变更的serial号告知从服务器slave
- DNS IXFR:DNS从服务器slave以增量的形式向master要求获取本次变更的内容
- DNS AXFR:DNS从服务器slave以全量的形式向master要求获取当前的全量数据
- 对称加密:使用相同的秘钥来加密传输内容,一端加密后,对端收到数据会用相同的秘钥来解密
- 非对称加密:如果用公钥对数据进行加密,只有用对应的私钥才能解密;如果用私钥对数据进行加密,那么只有用对应的公钥才能解密。
- 静态加速:针对视频、图片等不变的内容,将其缓存在靠近用户的边缘节点,缓存预热后用户直接从边缘获取,从而加速访问速度;
- 动态加速DCDN:针对API类返回值不同的请求,通过特殊的网络优化方式(路由优化、传输优化)等技术加速其达到源站的速度。
- VIP:虚拟IP,一般作为四层反向代理的入口,client看起来一直在与VIP交互
- RS:Real Server,VIP后实际承受client请求的服务,可能是物理机/虚拟机/容器POD
- DPDK:Data Plane Development Kit,主要用户4层负载均衡,用于转发的网络加速领域比较多;以极大提高网卡报文的处理性能和吞吐量,提高数据平面应用程序的工作效率
- SSL/TLS:(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议
- DPDK:Data Plane Development Kit,一种从数据面去加速网络报文处理的工具,可以极大提高数据处理性能和吞吐量,提高数据平面应用程序的工作效率
二、实验工具准备 (必须)
基础条件:使用Linux/MacOS操作系统,windows可以安装虚拟机,Ubuntu或者Centos都行
开源软件:bind9、nginx、ngrok(ngrok.com/download)
备注:bind9和nginx使用apt-get或者yum命令安装即可
三、实操环节
3.1 后端准备
准备一个网站,这里html等内容的建设步骤不在本次分享范围内,我们就以最简单的helloworld为例;
http访问监听的IP端口就返回‘Hello, World!’
3.2 host劫持实验
一般来说,操作系统会优先查看本地/etc/hosts目录去匹配相应的IP,而不是再去查询DNS系统,使用此类方式可以在本地将域名劫持到特定的ip上,以用来调试目的
在/etc/hosts文件追加一行:'{$劫持的ip} www.toutiao.com' 此处以 www.toutiao.com 举例
3.3 权威DNS及LocalDNS搭建实验
这里拟采用著名的开源软件bind9作为DNS服务的server
3.3.1 权威侧zone文件准备
新建zone文件/etc/bind/example.com.zone,并编辑为以下内容
$TTL 10M
@ IN SOA ns1.example.com admin.example.com. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS ns1.example.com.
; 这里ns1主机的ip地址可以换成本机地址
ns1 A 10.227.89.58
; 这里www主机的ip地址可以换成本机地址
www A 10.227.89.58
3.3.2 bind9配置准备
直接编辑/etc/bind/named.conf即可,配置参考如下:
logging {
channel default_log {
#这里注意提前创建log目录
file "/var/log/named/named.log" versions 10 size 200m;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
channel query_log {
file "/var/log/named/query.log" versions 10 size 200m;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
channel resolver_log {
file "/var/log/named/resolver.log" versions 10 size 200m;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
category default {default_log;};
category queries {query_log;};
category query-errors {query_log;};
category resolver {resolver_log;};
};
options {
#这里的ip地址可以换成本机地址
listen-on port 53 { 10.227.89.58; };
directory "/etc/bind";
dnssec-validation no;
#支持递归查询
recursion yes;
#转发到公共DNS优先,而不是自己去迭代查询,节省网络IO资源消耗
forward first;
forwarders {
223.5.5.5;
223.6.6.6;
};
allow-query { any; };
};
zone "example.com" {
type master;
file "example.com.zone";
};
3.3.3 使用dig命令验证
- 验证权威DNS服务命令:dig @10.227.89.58 www.example.com (10.227.89.58可以换成上面监听的本机地址),命中本地托管的zone example.com,直接吐数据
DNS请求日志见query.log
- 验证LocalDNS服务
dig @10.227.89.58 www.toutiao.com (10.227.89.58可以换成上面监听的本机地址),未命中本地托管的zone数据,直接向任一forwarders(公共DNS)请求,获取结果后缓存到本地
DNS 请求日志见 query.log
3.4 四层负载均衡实验
这里没有选择使用专业的LVS+keepalived作为4层转发的样例,这一层对于个人站点搭建来说是可有可无的,学员们需要有这一层概念即可,此次实验选择nginx的stream模块作为4层负载均衡实验的基础软件。
实验目的
- 将到达本机的53端口的udp报文转发到DNS服务器
- 将到达本机的80端口的tcp报文转发到自己准备的hello_world后端服务上。
3.4.1 修改DNS服务监听的端口
因为我们都是在同一台Linux机器上进行实验,不能监听相同的端口,故这里我们修改下DNS服务监听的端口,这里我们将53端口改成其他端口,从而腾出53端口给VIP(这里VIP等于本机IP)使用。
options {
#这里的ip地址可以换成本机地址
listen-on port 8053 { 10.227.89.58; };
directory "/etc/bind";
......
};
3.4.2 nginx stream配置准备
编辑/etc/nginx/nginx.conf,新增stream模块
ps:若nginx未安装stream模块,则自行添加stream模块或者重新编译nginx即可。
#四层转发,tcp/udp协议转发
stream {
log_format proxy '$remote_addr [$time_local] '
'$protocol $status $bytes_sent $bytes_received '
'$session_time "$upstream_addr" '
'"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';
access_log /var/log/nginx/access.log proxy;
open_log_file_cache off;
upstream dns_proxy {
server 10.227.89.58:8053;
}
upstream hello_proxy {
server 10.227.89.58:8080;
}
server {
listen 53 udp reuseport;
proxy_pass dns_proxy;
}
server {
listen 80;
proxy_connect_timeout 1s;
proxy_timeout 300s;
proxy_pass hello_proxy;
}
}
3.4.3 流量转发验证
- UDP流量
此处dig的验证效果和4.3.3表面上看似无异,但是4层流量是经过nginx stream模块转发的,这里我们可以查询转发日志查询UDP流量转发详情。
- TCP流量
访问效果和直接访问后端无异
转发日志如下:
3.5 七层负载均衡实验
这里需要使用nginx的http module在四层负载均衡和后端服务之间添加七层负载均衡服务,这里以880端口为例,修改如下:
将四层负载均衡的后端设置为7层监控的端口880
upstream hello_proxy {
server 10.227.89.58:880;
}
http模块配置如下:
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
upstream backend {
server 10.227.89.58:8080;
}
server {
listen 880;
server_name www.example.com;
location / {
proxy_pass http://backend;
proxy_set_header HOST $host;
proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
}
}
}
访问本地服务80端口现象与上相同,nginx四七层转发日志如下:
3.6 SSL自签证书实验
下面我们来支持使用https协议访问我们的后端,SSL卸载的任务一般落在七层负载均衡这一层。
3.6.1 使用工具签发自定义证书链
-
签发根证书
命令:./certmaker -gen root -cn "Test Root Ca"
结果:生成文件为根证书私钥rootCA.key和证书文件rootCA.pem -
签发中间CA证书
命令:./certmaker -gen intermediate -cn "TestIntermediateCA" -issuer rootCA.pem -issuerkey rootCA.key
结果:生成中间CA证书私钥TestIntermediateCA.key和证书文件TestIntermediateCA.pem -
签发域名证书
命令:./certmaker -gen cert -cn "*.example.com" -issuer TestIntermediateCA.pem -issuerkey TestIntermediateCA.key
结果:生成域名证书私钥_.example.com.key和证书文件_.example.com.pem
3.6.2 nginx配置准备
- 增加443端口转发四层配置
upstream hello_proxy_ssl {
server 10.227.89.58:8443;
}
server {
listen 443;
proxy_connect_timeout 1s;
proxy_timeout 300s;
proxy_pass hello_proxy_ssl;
}
- server块增加ssl配置
server {
listen 880;
listen 8443 ssl;
server_name www.example.com;
# 引用中间CA证书
ssl_certificate /etc/nginx/ssl/TestIntermediateCA.pem;
ssl_certificate_key /etc/nginx/ssl/TestIntermediateCA.key;
# 引用域名证书
ssl_certificate /etc/nginx/ssl/_.example.com.pem;
ssl_certificate_key /etc/nginx/ssl/_.example.com.key;
# 自动跳转到HTTPS
if ($server_port = 880) {
rewrite ^(.*)$ https://$host$1 permanent;
}
...
}
3.6.3 访问https
- 443端口四七层转发日志:
- 浏览器使用https协议访问:
3.7 将本地服务开放外网访问
有的同学可能觉得部署这一套可能太复杂,在项目前期有没有什么比较简单有效的方法将我本机的服务开放在公网供别人访问。这里简单介绍一种成熟的的解决方案。
项目地址:ngrok.com/
命令:./ngrok http 8080(将本地8080端口开放到公网)
服务状态:
访问工具提供的域名:
GitHub仓库 (必须)
参考文档
域名系统 zh.wikipedia.org/wiki/%E5%9F…
DNS解析过程 www.cnblogs.com/ximu-xin/p/…
HTTPS原理 segmentfault.com/a/119000002…
CDN静态加速原理 www.jianshu.com/p/1dae6e168…
全站加速 help.aliyun.com/document_de…
LVS+KeepAlived wsgzao.github.io/post/lvs-ke…
nginx官网 nginx.org/
nginx指令集 nginx.org/en/docs/dir…