这是我参与「第三届青训营-后端场」笔记创作活动的第10篇笔记。
1.什么是架构
架构又称软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。
架构在软件实现方法的选择上起着至关重要的指导作用。
好的架构：稳定、功能可拓展、容易实现。
1.1 单机
把所有功能都实现在一个进程里，并部署在一台机器上。
优点：简单。
问题：C10K问题（单机1万并发连接）、运维需要停服。
演进：如何扩大并发数？增加服务器。
1.2 垂直切分（单体、垂直应用）
单体架构：分布式部署，每个服务器拥有完整功能，用一台服务器实现负载均衡，将请求均匀分发给其它服务器。
垂直应用架构：按应用垂直切分的单体，每个服务器实现特定功能，用一台服务器接受请求，然后按需转发给对应服务器。
优点：水平扩容。运维不需要停服。
问题：每台机器职责太多，开发效率不高。爆炸半径大（只要职责中的一步做不了了，整个职责链都受影响）。
演进：如何提高效率？分工协作。
1.3 水平切分（SOA、微服务）
SOA（Service-Oriented Architecture，面向服务的体系架构）的两个特性：
- 将应用的不同功能单元抽象为服务。
- 定义服务之间的通信标准。
微服务架构：SOA的去中心化演进方向。
SOA倾向于有一个中心服务器用于协调各个功能之间通信（所有服务器通过中心服务器通信）；微服务架构倾向于服务之间直接按需通信。
问题：数据一致性。高可用（服务之间如何通信才能保持架构稳定运行）。容灾治理。解耦vs过微，如何权衡。
2.企业级后端架构剖析
- 服务器是买还是租？
- 服务是自己设计还是调用他人？
- 资源有限情况下，是应该保持质量还是应该扩大服务？
- 未来发展是深度钻研还是广度扩充？
2.1 云计算
通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。
基础：
- 虚拟化技术（把一台物理机虚拟成多台逻辑机）
- 编排方案（自动化管理分配资源）
云计算的架构可分为4层：
- IaaS（Infrastructure as a Service）将基础设施作为服务。对计算、存储、网络等资源提供云服务。
- PaaS（Platform as a Service）将平台作为服务。所有云平台都是PaaS，且都基于自己的IaaS。
- SaaS（Software as a Service）将软件作为服务，通过云来使用软件，这些软件可以不安装在本地机器中。
- FaaS（Function as a Service）将函数、功能作为服务。
2.2 云原生
云原生技术为组织（公司）在共有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。
云原生能够提供：
- 弹性资源：虚拟化容器，快速扩缩容。
- 微服务架构：业务功能单元解耦，并通过统一的通信标准连接。
- DevOps：敏捷开发手段。CI/CD（Continuous Integration，Continuous Delivery，Continuous Deployment，持续集成，持续交付，持续部署），将一些繁琐的步骤自动化，比如提交软件之后自动编译运行之类的，从而使每个人对其他人透明，只需要完成自己的工作然后提交就可以了。
- 服务网格：业务与治理解构（服务和网络通信解构）。异构体系的治理统一化（中间层沟通异构体系，如不同代码语言）。复杂治理能力。
2.2.1 弹性计算资源
- 服务资源调度：微服务、大服务。
- 计算资源调度：在线、离线。
- 消息队列：
- 在线：大吞吐量的削峰、解耦
- 离线：大数据分析
2.2.2 弹性存储资源
- 经典：对象。大数据。
- 关系型数据库
- 元数据：服务发现（用服务的名字作为地址）
- NoSQL：key-val型存储
2.2.3 DevOps
是云原生时代软件交付的利器，贯穿整个软件开发周期。结合自动化流程，提高软件开发、交付效率。
2.2.4 微服务架构
通信标准：HTTP（RESTful API）、RPC(Thrift，gRPC）
微服务中间件 RPC还是HTTP：
- 性能
- 服务治理
- 协议可解释性
云原生场景下，微服务不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做。
2.2.5 服务网格
服务网格（Service Mesh）：
- 微服务之间通讯的中间层
- 高性能网络代理
- 业务代码与治理解耦
相比较于RPC/HTTP框架：
- 异构系统治理统一化
- 与业务进程解耦，生命周期易管理
3.企业级后端架构的挑战
有什么问题挑战：
基础设施方面，物理资源（机器、带宽）是有限的，资源利用率受制于部署服务。
用户层面，网络通信开销较大，网络抖动导致运维成本提高，异构环境下不同实例资源水位不均。
3.1 离在线资源并池
核心收益：
- 降低物理资源成本
- 提供更多的弹性资源，增加收入
在线业务的特点：
- IO密集型为主
- 潮汐性（白天有晚上无的周期）、实时性 离线业务的特点：
- 计算密集型占多数
- 非实时性
问题：同一个机器怎么做离在线隔离？容器化、虚拟化。隔离cpu资源，将部分cpu用于在线，部分用于离线。
3.2 自动扩缩容
核心收益：降低业务成本
利用在线业务潮汐性自动扩缩容。
问题：扩缩容依据什么指标？对于大多数微服务不考虑内存而是只考虑cpu使用情况的p50（中位数，pX指样本从小到大排序后位于X%处的数据大小）。如果服务确实有内存方面的要求再考虑cpu与内存结合的方法。目前难以使用IO作为指标。
3.3 微服务亲和性部署
核心收益：降低业务成本、提高服务可用性
- 将满足亲和性条件的容器调度到一台宿主机（当两个服务消息传播密切，可用一台主机容纳两个服务，降低沟通成本）。
- 微服务中间件与服务网络通过共享内存通信。
- 服务网格控制面实施灵活，动态的流量调度。
3.3 流量治理
核心收益：提高微服务调用容错性。容灾。进一步提高开发效率，DevOps发挥到极致。
通过微服务中间件与服务网格进行流量治理
- 熔断、重试。
- 单元化。
- 复杂环境（功能、预览）的流量调度。
水位负载均衡
核心收益：打平异构环境算力差异。为自动扩缩容提供正向输入。
- IaaS提供资源探针（每台主机有一个进程探测资源还剩多少）
- 服务网格动态负载均衡
4.后端架构实战
每台机器性能不同，如何给他们分配流量？
- 需要哪些输入？
- 服务网格数据面：支持带权重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机提供的容器资源使用情况和物理资源信息（如cpu型号）
- 设计时需要考虑哪些关键点？
- 紧急回滚能力
- 如何处理大规模数据
- 极端场景如何应对
方案1：采集宿主机物理资源信息，调整容器注册的权重
优势：复杂度低。完全分布式，可用性高。微服务中间件无适配成本。
缺点：无紧急回滚能力。缺乏运行时自适应能力。
方案2：容器动态权重的自适应调整。充分发挥服务网格的服务发现和流量调度能力
优点：解决了无法回滚的问题。运行时可以进行权重自适应。
缺点：过度流量倾斜可能出现异常情况。
方案3：服务网格上报RPC指标
优点：极端场景的处理成为可能。
缺点：时序数据库压力较大。动态权重决策中心职责越来越多，迭代和变更可能形成风险。
演进方向：
- 微服务化
- 引入消息队列削峰、解耦
- 离在线链路切分
- 梳理强弱依赖
