这是我参与「第三届青训营 -后端场」笔记创作活动的第9篇笔记
架构
架构的演变
单机架构
单机架构优点是简单，但是缺点也很明显，就是开发维护都很慢，且服务用户量小
单机架构向单体架构演变
单机中只有一个应用处理请求，为了拓展业务，最简单的办法就是同时部署很多应用同时处理这些请求
这些应用是重新部署的应用，不同的应用可以负责不同的业务
单体架构向SOA、微服务演变
为了增强某个模块的性能，可以将应用进行水平切分，不同的模块负责不同的职责，模块之间互不干扰，且可以通过增加特定模块提升模块性能
进一步的，将应用划分为模块，模块之间进行有需要的通信，这样使得模块具有可拔插的特性，使得整个系统耦合性更低
但是分布式系统又带来了全新的挑战，比如以下的问题：
数据一致性问题：分布式的数据存储如何保证数据一致性
高可用：模块之间相互的调用很复杂，如何保证在某个模块出现故障的时候，系统还能正常运转
治理：如果在某个模块彻底出现故障的时候，如何对这种情况做容灾呢（问题，容灾是什么）
运维成本：怎样权衡运维成本与服务的拆分
企业级后端架构剖析
背景
云计算
云计算能力，提供计算资源的服务网络
使用云计算的架构可以分为这几种：
1. IaaS(Infrastructure as a Service) 基础架构，也就是服务器，如果使用云计算的服务器那就相当于在租房子，如果不使用云计算的服务器则自己需要买一台服务器并进行相关部署
2. PaaS(Platform as a Service) 运维平台，也就是服务器的日常维护，如果使用云计算的维护则云计算平台则会负责服务器的日常维护，包括清理磁盘、增加缓存等等
3. SaaS(Software as a Service) 平台软件，云计算平台有专用的适配软件，甚至可以一键部署，而不使用云计算的服务的话则需要自己手动去调试部署
4. FaaS(Function as a Service) 平台函数，云计算平台有专用的接口可以直接调用，软件很成熟，而不使用云计算的服务则需要自己手动去创建函数调用
云原生架构解析
在共有云、自由云、混合云等新型的动态环境中，帮助企业构建和运行可弹性拓展的应用，这样的虚拟化技术的集合就是云原生技术
弹性资源，虚拟化容器提供的资源是可以自动扩容缩容的
微服务架构，使用微服务架构，可以将业务单元进行解耦，使得业务单元职责比较清晰，并且服务之间有一套统一的通信，使得业务单元能够紧密联系。由于服务之间是松耦合的，使得业务形态呈现多样化的可能
DevOps，使用敏捷的开发流程
服务网格，把服务和网络通信进行解耦，使得业务只用专注于业务，业务之间的调用使用服务网格进行传输处理。同时由于服务网格是作为服务之间的中间件，所以能够为异构系统的治理提供统一化，不管是各个微服务模块是使用什么语言编写的都能够使用服务网格来完成业务的调度
弹性计算资源：
服务资源的调度：根据CPU和内存的使用量来进行划分
微服务、大服务
计算资源的调度：根据分析的数据量来进行划分
在线资源、离线资源
消息队列：为计算资源服务
为在线消息服务（有非常大的吞吐量、以及服务之间的解耦）、为离线资源服务（为大数据服务的套件）
弹性存储资源：（作为一个服务进行调用）
经典存储：
对象存储（宣传的视频）、大数存储（用户消费记录）
关系型数据库：
收银记录（强关系属性）
元数据：
服务发现（微服务的通信地址）
NoSQL：
KV存储（常用的缓存、分布式的事务）
DevOps：
云原生时代交付利器，贯穿整个软件开发周期
结合自动化流程，提高软件开发、交付效率
有很多开源的软件作为DevOps来帮助企业进行开发，
在设计阶段首先要将系统架构统统考虑清楚，在开发过程中开发测试上线是同时进行的，DevOps提供了快速开发测试上线回滚的功能，
微服务架构：
很多组件会提供HTTP或者RPC的接口的能力
RPC与HTTP的选择：
RPC相比于HTTP做了数据的压缩，拥有更好的性能
中间件会提供使用RPC的服务治理能力，也就是在重发消息与分派消息上有专门的处理
云原生场景下，微服务不必在业务逻辑中实现通信标准的交互逻辑，而是交给框架来做
可以通过消息队列从数据库中读取数据来刷新缓存
服务网格：
微服务之间通信的中间层
数据平面与服务发现，提供高性能的网络代理，提供了网络通信的桥梁
使用数据平面，使得业务代码与治理解耦
使用数据平面，实现异构系统治理统一化的能力
与业务进程解耦，生命周期易管理
后端架构的挑战
降低物理资源成本：
离在线资源并池
使用容器实现
自动扩缩容
利用在线业务潮汐性自动扩缩容
根据不同场景选择自动扩缩容的指标，对于绝大部分微服务来说，CPU就是核心指标，使用cpu的某一个分位数，经常使用p50也就是50的百分位数作为指标来衡量服务使用资源的情况。有时有的微服务也会使用一部分内存，这时可以将cpu和内存同时作为衡量的指标。但是在当前业界中，使用IO或者是QPS作为自动扩缩容的指标是一个比较难的挑战，这些指标是很难量化的
微服务亲和性部署
微服务之间会有紧密且量级很大的通信，这时候就可以将两个服务安排到同一台宿主机上。这时候微服务中间件和服务网格之间就可以通过共享内存通信，这样就可以尽可能的降低微服务通信、协议解析、序列化拷贝等等开销，使得其核心CPU利用率得到提高
尽管将密切通信的微服务安排到同一台宿主机上，但还是在网络上会有一部分流量，这时就可以通过服务网格控制面实施灵活、动态的流量调度
服务发现与服务网格
中间件的服务发现能做到的事情是有限的，服务网格Service Mesh控制面
流量治理
提高调用的容错性、容灾、提高开发效率
基于微服务中间件 & 服务网格的流量治理
熔断、重试 解决单次请求失败
单元化 解决同一类请求不会影响另一类的请求
更复杂环境下的流量调度 快速验证新开发的功能
CPU水位负载均衡
针对不同宿主机由于CPU型号或者是网络请求的差异，业务调度不能是随机的，而是以CPU使用率作为指标进行业务调度，分配不同的业务打到不同的宿主机上，最终使得宿主机的CPU使用率达到一致，
这里最关键的一步就是获取调度业务、运维的关键指标，IaaS层面提供资源探针，可以获取宿主机资源使用率；服务网格层面提供动态负载均衡，平衡不同宿主机的资源使用率
后端架构实战
系统输入：
使用服务网格数据面的控制能力，利用服务网格天生自带权重的负载均衡策略，利用权重来调整流量的分布
注册中心存储了所有容器的权重信息和服务发现
IaaS提供宿主机资源使用情况
关键点：
调度系统出现了问题，比如分配资源不合理，首先导致上面的服务器被打挂掉，然后所有请求涌入到下面的服务器，下面的服务器也被打挂掉，如何做这种场景的紧急回滚
系统怎么在大规模的场景下运作，处理系统的稳定性和瓶颈
如何处理服务的极端场景
自适应静态权重
权重可以影响调用的网络，在每个宿主机上搞调权代理，每个宿主机根据自身资源的利用情况，来自主调节容器的权重
优势：
复杂度低，实现简单，每个宿主机上部署一个调权代理，每个调权代理只会关注自身资源的使用情况
完全分布式，可用性高，当一个宿主机上的调权代理挂掉了不会影响其他机器
微服务中间件无适配成本，对业务进程是无感知的
缺点：
如果调权代理改错了，无紧急回滚能力
缺乏运行时自适应能力，只能感知到系统资源，但是无法感知到服务状态的变化，不能及时的做调整
自适应静态权重Alpha
相比于前一个版本，系统增加了一个动态权重决策中心，从分布式的部署改为从各个宿主机拉取对应宿主机的资源使用率
决策中心会从注册中心获取服务注册信息，并且根据宿主机的资源使用率，使用一定算法来动态调整权重，之后会写回注册中心完成权重的调整
优势：
增加了紧急回滚能力，如果动态权重出现了问题，服务网格就可以切换会静态权重完成紧急回滚
缺点：
会出现过度流量倾斜等异常情况
自适应静态权重Beta
相比于前一个版本，系统除了搜集宿主机的资源信息之外，还会搜集数据面RPC的指标，以防止流量出现过度倾斜，导致容灾、调度出现问题
优势：
增加了极端场景的处理能力
缺点：
随着动态权重决策中心的职责越来越多，其存储、处理的数据也会越来越多，其存储数据使用的时序数据库会出现压力，并且决策中心的迭代变更都会有一定风险
自适应静态权重Release
将决策中心微服务化，整体分为入口层、在线分析层、离线分析层，并引入了消息队列做数据的削峰与解耦
不需要在线实时分析的数据打到离线的分析引擎，以做一些机器学习等分析计算，传入在线分析参加权重的计算
需要分析的数据传到在线分析引擎，做权重的分析计算，快速反馈到注册中心完成权重的调整
