Lesson12 架构与服务开放｜青训营笔记

九. 架构

9.1 架构定义解析

架构，又称为软件架构：

• 是有关软件整体结构与组建的抽象描述
• 用于指导软件系统各个方面设计

重要性：

• 地基没打好，大厦容易倒
• 地基坚实了，大厦才能盖的高
• 站在巨人肩膀上，才能看得远

1.单机架构：

所有功能实现在一个进程里，并部署在一台机器上。

优点是简单，问题是C10K problem / 运维需要停服。

2.垂直应用架构：

按应用垂直切分。

优点是水平扩容 / 运维不需要停服，问题是指责太多，开发效率不高，爆炸半径大。

3.SOA(Service-Oriented Architecture) 架构：

将应用的不同功能单元抽象为服务，定义服务之间的通信标准。

问题：数据一致性 / 高可用 / 容灾 / 解耦 vs 过微

9.2 企业级后端架构剖析

9.2.1 云计算

云计算：是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石 基础：

• 虚拟化技术

• 编排方案 架构：

• 基础设施即服务(Infrastructure as a Service, IaaS)

  • 利用基础设施即服务 (IaaS)，云服务提供商可以拥有并管理那些运行您的软件堆栈的硬件。它包括服务器、网络和存储。如果您不想购买和维护基础设施，这便是一个可以大大降低成本的战略。但是您的 IT 团队仍有大量工作要做。在 IaaS 模型下，您的 IT 团队需要管理操作系统 、数据库、应用程序、功能和您的组织的所有数据。因此，与其它服务模型相比，您的 IT 团队将具有更大的控制力和灵活性。IaaS 是自助服务，您的 IT 团队可以通过 API 或仪表板获取所需资源。它的常见示例包括亚马逊 AWS、谷歌计算引擎和微软 Azure，您可以通过它们购买自己所需的容量。也就是说，它几乎不涉及约定，如果您认为自己的需求在不久以后会有变化，它就会体现出优势。如果您属于一个大型组织，您也可以通过您的企业的另一个部分访问 IaaS。

• 平台即服务(Platform as a Service, PaaS)

  • 下一级服务是平台即服务 (PaaS)。PaaS 与 IaaS 相似，区别在于您的云服务提供商还提供了操作系统和数据库。这意味着您的 IT 团队的工作量较少， 但您的组织仍然要负责应用程序、功能和数据。PaaS 为您的开发者提供了一个简单、可扩展的应用程序构建平台。它与 IaaS 非常相似，您可以根据需要购买更多资源。由于多个用户可以访问开发应用程序，因此 PaaS 可以简化工作流程并加强协调。PaaS 的示例包括 AWS Elastic Beanstalk 和谷歌应用程序引擎。

• 软件即服务(SaaS, Software as a Service)

  • 软件即服务 (SaaS) 为最终用户提供了最多的支持，是所有交付模型中最简单的一种。您可能已经在您的组织中使用过它。SaaS 可以在多租户架构中运行，软件的一个实例可以为多个用户提供服务。一般来说，SaaS 产品不需要下载或安装，您的最终用户不需要管理软件更新。他们只需要负责自己的数据。SaaS 的常见示例包括 CRM 软件、基于云的文件存储和电子邮件。

• 功能即服务(FaaS, Function as a Service)

  • 提供更深层次的服务。使用 FaaS，您的用户只需管理功能和数据。云服务提供商则管理您使用的应用程序。这种选项在开发者中特别常见，因为您无需在代码未运行时为服务付费。常见功能包括数据处理、数据验证或分类，以及移动和物联网应用程序的后端。FaaS 供应商包括 AWS* Lambda、Azure Functions 和谷歌云 Functions。

• 裸机即服务 (BMaaS)

  • 一些企业不喜欢将工作负载迁移到与其他客户共享的虚拟化云环境中， 便用裸机即服务 (BMaaS) 方案来替代 IaaS 和 PaaS。它为企业提供了专用服务器环境来补充虚拟化云服务，且该专用服务器环境与云具有相同的敏捷性、可扩展性和效率。特别是，对于需要在没有延迟或延时开销的情况下执行短期数据密集型处理（例如媒体编码或渲染农场）的企业来说，BMaaS 是一个不错的选择。

• 数据库即服务 (DBaaS)

  • 这是一种提供数据库访问权限的 PaaS。DBaaS 是一种很好的启用混合云的方法，因为应用程序可以在本地和云基础设施之间移动，但对最终用户没有任何影响。通过 DBaaS 集成新技术也简单得多，因为应用程序开发者不需要任何额外资源即可使用新技术。DBaaS 的一个示例是微软* Azure SQL 数据库。

9.2.2 云原生

云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。

云原生

• 弹性资源

  • 虚拟化容器
  • 快速扩缩容

• 微服务架构

  • 业务功能单元解耦
  • 统一的通信标准

• DevOps

  • 敏捷的开发模式
  • CI/CD

• 服务网格

  • 业务与治理结构
  • 异构系统的治理统一化
  • 复杂治理能力

9.2.3 企业级后端架构的挑战

挑战：

• 基础设施层面

  • 物理资源是有限的

    • 机器
    • 带宽

  • 资源利用率受限于部署服务

• 用户层面

  • 网络通信开销较大
  • 网络抖动导致运维成本提高
  • 异构环境下，不同实例资源水位不均

9.2.4 离在线资源并池

核心收益

• 降低物理资源成本
• 提供更多的弹性资源，增加收入

解决思路：离在线资源池

• 在线业务的特点

  • IO密集型为主
  • 潮汐性，实时性

• 离线业务的特点

  • 计算密集型占多数
  • 非实时性

9.2.5 自动扩缩容

核心利益

• 降低业务成本

解决思路： 自动扩缩容

• 利用在线业务潮汐性自动扩缩容（利用CPU的P50作为指标）

9.2.6 微服务亲和性部署

核心利益

• 降低业务成本
• 提高服务可用性

解决方案：微服务亲和性部署

• 将满足亲和性条件的容器调度到一个宿主机
• 微服务中间件与服务网格通过共享内存通信
• 服务网格控制面板实施灵活，动态的流量调度

9.2.7 流量治理

核心收益

• 提高微服务的调用容错性
• 容灾
• 进一步提高开发效率，DevOps发挥到极致

解决方案：基于微服务中间件& 服务网格的流量治理

• 熔断、重试
• 单元化
• 复杂环境（功能，预览）流量调度

9.2.8 CPU水位负载均衡

核心利益

• 打平异构环境算力差异
• 为自动扩缩容提供正向输入

解决思路：CPU水位负载均衡

• IaaS

  • 提供资源探针

• 服务网格

  • 动态复杂均衡

十. 将我的服务开放给用户

Host管理

• 背景：example公司建立了多个内部站点，公司的主机表包括办公（aa.example.com）、文档（wiki.example.com）、员工认证（passport.example.com）、人事（people.example.com）。

• 方法：网络运维人员使用主机表的方式来管理Host到IP的映射。即Host->ip映射

• 访问：员工通过HTTP协议来拉取Host的配置，从而达到访问不同系统的目的。

• 问题：随着example公司业务规模和员工数量的增长，问题出现：

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

使用域名系统

• 改进措施：使用域名系统（域名空间）替换hosts文件
• 域名：根->顶级域名（.edu教育、.com商业、.mil军事、.org非营业组织）->二级域名->三级域名->四级域名

域名购买与配置迁移

• 购买二级域名：example.com
• 修改配置：清空/etc/hosts。配置/etc/resolv.conf中nameservers为公共DNS。迁移原配置，通过控制台添加解析记录即可。

如何开放外部用户访问

• 方案：租赁一个外网IP，专用于外部用户访问门户网站，将 www.example.com 解析到外网IP100.1.2.3，将该IP绑定到一台物理机上，并发布公网route，用于外部用户访问。

自建DNS服务器

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

DNS查询过程

1. 主机发出访问 www.163.com 请求。
2. 本地DNS服务器发现缓存里没有这个IP地址，向DNS根服务器询问。
3. DNS根服务器告诉本地DNS服务器可以去.com域服务器查询，本地DNS服务器向.com域服务器询问。
4. .com域服务器告诉本地DNS服务器可以去163.com域服务器查询，本地DNS服务器向163.com域服务器询问。
5. 163.com域服务器查询得出此域名IP地址为1.1.1.1并返回给本地DNS服务器。
6. 本地DNS服务器返回查询结果给主机，并将“www.163.com 的IP是1.1.1.1”的信息存入缓存。

DNS记录类型

• A/AAAA：IP指向记录，用于指向IP，前者为IPv4记录，后者为IPv6记录
• CNAME：别名记录，配置值为别名或主机名，客户端根据别名继续解析以提取IP地址
• TXT：文本记录，购买证书时需要
• MX：邮件交换记录，用于指向邮件交换服务器
• NS：解析服务器记录，用于指定哪台服务器对于该域名解析
• SOA记录：起始授权机构记录，每个zone有且仅有唯一的一条SOA记录，SOA是描述zone属性以及主要权威服务器的记录

权威DNS系统架构

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

接入HTTPS协议

• 页面出现白页/广告
• 返回了403的页面
• 搜索不了东西
• 搜索问题自带小尾巴，页面闪退频繁
• 页面弹窗广告：HTTP明文传输，弊端越来越明显
• 解决办法：将HTTP替换为HTTPS

对称加密和非对称加密

• 对称加密：加密数据在传输过程中是无规则的乱码，即使被第三方获取，在没有密钥时也无法解密数据，从而保证数据的安全性。

  • 问题：双方都要使用相同的密钥，在传输数据前要将密钥从一方传输给另一方，这样密钥在传输过程中就有可能被截获。

• 非对称加密：加密和解密采用两个不同的密钥，也就是公钥（锁头）和私钥（钥匙）。公钥和私钥是一对，使用公钥加密就需要私钥解密，私钥加密就公钥解密。

  • 例子：服务器拥有公钥和私钥。当客户端发起请求后，服务器将公钥返回给客户端。客户端生成密钥KEY，使用公钥加密后发送给服务器。服务器利用私钥解密获得密钥KEY。之后，双方使用密钥KEY进行对称加密传播。

SSL的通信过程

服务器和客户端都拥有以下四个属性：

• client random
• server random
• premaster secret
• 加密算法协商 由此生成对称密钥session key。

证书链

公钥存在证书，Server端发送是带签名的证书链，client收到会仍然需要验证：

• 是否是可信机构颁布
• 域名是否与实际访问一致
• 检查数字签名是否一致
• 检查证书的有效期
• 检查证书的撤回状态 此外，服务端会在发送前将证书摘要信息用私钥加密生成数字签名，客户端收到后用公钥解密数字签名，如果与证书摘要信息一致则说明传输无误。

接入全站加速

问题背景

• 源站容量低，可承载的并发请求数低，容易被打垮
• 报文经过的网络设备越多，出问题的概率越大，丢包、劫持、mtu问题
• 自主选路网络链路长，时延高
• 由此造成客户端响应慢、卡顿。 👉极大的流失了大部分的用户群体，NPS留存率数据不乐观。

解决方案

• 源站容量问题：增加后端机器扩容；静态内容，使用静态加速缓存
• 网络传输问题：动态加速DCDN
• 全站加速：静态加速+动态加速

静态加速CDN

• 针对静态文件传输，网络优化方式： 通过将服务器上的内容缓存到cdn节点上。当访问静态内容时，无需再访问源站，通过就近访问cdn节点就可达到相同的结结果，从而达到加速的效果，同时减轻了源站服务器的压力。此时主机从本地DNS获取的不是源站DNS的结果，而是cdn节点的解析结果。cdn使用自动调度DNS，根据静态拓扑等算法把一些合适的地址返回给client，并缓存地址。
• 优点：解决服务器端的“第一公里”问题、缓存甚至消除了不同运营商之间互联的瓶颈造成的影响、减轻了各省的出口带宽压力、优化了网上热点内容的分布

动态加速DCDN

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

DCDN原理

DCDN会计算从用户到核心、用户到边缘、边缘到汇聚、汇聚到核心等的RTT（Round Trip Time）时间，然后进行常规请求耗时计算，选择最优路径。

使用全站加速

• 用户首次登录抖音，注册用户名手机号等用户信息：动态加速DCDN
• 抖音用户点开某个特定短视频加载后观看：静态加速CDN
• 用户打开头条官网进行网页浏览：静态加速CDN+动态加速DCDN

四层负载均衡

• 服务混杂，端口多，部门人员在执行操作的时候可能会出错
• 把所有的服务都部署在一台物理机上，如果物理机突然挂掉，容灾怎么处理？

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

• 三个主要功能：

1. 解耦vip和rs
2. NAT
3. 防攻击：syn proxy

常见的调度算法原理

• RR轮询：Round Robin，将所有的请求平均分配给每个真实服务器RS

• 加权RR轮询：给每个后端服务器一个权值比例，将请求按照比例分配

• 最小连接：把新的连接请求分配到当前连接数最小的服务器

• 五元组hash：根据sip、sport、proto、dip、dport对静态分配的服务器做散列取模

  • 缺点：当后端某个服务器故障后，所有连接都重新计算，影响整个hash环

• 一致性hash：只影响故障服务器上的连接session，其余服务器上的连接不受影响

常见的实现方式FULLNAT

• 包含入向流和出向流。
• 在发出外网报文请求后，会经过外网核心设备，然后再转发给4层负载均衡GW。GW通过VIP接收请求，但是在内部不能把VIP当作client，所以GW的另一个网卡绑定了LIP，LIP是一个内部IP，能够通过new一个IP与RS进行通信，从而将请求转发给RS，再转发给物理机，然后物理机再将请求回传给GW，然后GW再把请求通过IP转换，通过VIP回传给client。 ❓RS怎么指定真实的CIP？ 👉通过TCP option字段传递，然后通过特殊的内核模块反解

4层负载均衡特点

• 大部分都是通过dpdk技术实现，技术成熟
• 纯用户态协议栈，kernel bypass，消除协议栈瓶颈
• 无缓存，零拷贝，大页内存（减少cache miss）
• 仅针对4层数据包转发，小包转发可达到限速，可承受高cps

7层负载均衡

• 四层负载对100.1.2.3只能bind一个80端口，而有多个外部站点需要使用，该如何解决？ 还有以下问题：
• SSL卸载：业务端是http服务，用户需要用https访问
• 请求重定向：浏览器访问toutiao.com自动跳转 www.toutiao.com
• 路由添加匹配策略：完全、前缀、正则
• Header编辑
• 跨域支持
• 协议支持：websocket、grpc、quic

Nginx简介

• 最灵活的高性能web server，应用最广的7层反向代理。
• 模块化设计，较好的扩展性和可靠性
• 基于master/worker架构设计
• 支持热部署：可在线升级
• 不停机更新配置文件、更换日志文件、更新服务器二进制
• 较低的内存消耗：1万个keep-alive连接模式下的非活动连接仅消耗2.5M内存
• 事件驱动：异步非阻塞模型，支持aio、mmap（内存映射）

Nginx反向代理

• 代理服务器功能：Keepalive、访问日志、url rewrite重写、路径别名、基于ip的用户的访问控制、限速及并发连接数控制

事件驱动模型

将每种动作都归纳成一个个独立的事件，而事件之间相互独立，没有影响。可以理解成一个个任务task，然后给每一个task设置一个回调函数。在系统中启动多线程，每一个线程监听一个事件的队列，如果队列不为空，就从队列中取出相应的对象执行回调函数即可。