这是我参与「第五届青训营」笔记创作活动的第9天

一、本堂课重点内容：

以下概念均使用兰师傅蛋糕店为例子进行类比解释。

什么是架构

定义

架构，又称软件架构：

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

简单来说，架构描述了系统的组成元素以及元素之间的交互，是从系统角度出发的。

与之相近的，框架描述组件的规范，具体实现某些功能，是技术实现层面的。

如果用建设一幢大楼来比喻，架构就是大楼的结构、外观和功能性设计，它需要考虑的问题可以延展到抗震性能、防火性能、防地表下陷性能等；而框架则是建设大楼过程中一些成熟工艺的应用，例如楼体成型、一次浇灌等。

单机架构

软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上。

思考：如何卖出更多蛋糕

优点是实现简单，缺点是

运维需要停服，用户体验较差
承载能力有限。可能出现 c10k 问题（单机处理 10k 个并发连接的问题 C10K 问题）

单体架构

我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。

大堂经理作用便是负载均衡。

优点：

具备水平扩容能力
运维不需要停服

缺点：

后端进程职责太多，越来越臃肿
爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

垂直应用架构（垂直切分）

在单体架构基础上，进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，再按照单体模式的思路，部署在多个机器上，就来到了垂直应用架构。

优点：

一定程度上减少了后端进程职责
一定程度上缩小爆炸半径

缺点：

没有根本解决单体架构的问题

SOA架构

SOA (Service-Oriented Architecture) 是面向服务的架构，即企业的 IT 系统是由服务组成的，也即企业的各个应用系统是由许多标准的服务件“组装”起来的，组成应用系统中的各个服务之间是一种非常松耦合的关系。

SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。
SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。（服务注册中心）

优点：

各服务的职责更清晰
运维粒度减小到服务，爆炸半径可控

缺点：

ESB (企业服务总线) 往往需要一整套解决方案

微服务架构（水平切分）

为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。因为中心化的方案形态较重，拓展性不佳，普及性不佳，我们跳过不讲。而去中心化的方向，最终的形态就是微服务架构。

优点：

兼具 SOA 解决的问题
服务间的通信更敏捷、灵活
各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高

缺点：

运维成本

小结

架构的演进初衷:好比做蛋糕。

需求量越来越大，终归要增加人手
越做越复杂，终归要分工合作

架构的演进思路:就像切蛋糕。蛋糕越来越大，一口吃不下终归要切分

竖着切 (垂直切分)
横着切 (水平切分)

最后，我们还需要回答垂直切分和水平切分所产生的一系列问题：

由单机部署演进来的分布式架构，如何解决数据一致性
服务越来越多，依赖越来越复杂，如何做到高可用（合作）
一个团队甚至一个人可能同时管理多个微服务，如何运维(容灾)
微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和『过微』之间取舍（运维成本）

企业级后端架构剖析

当蛋糕店从单机架构一步步演变成微服务架构，蓬勃发展的蛋糕店需要继续扩大规模，这便来到了企业级后端架构。

云计算

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

云计算基础：

虚拟化技术
- 硬件层面（VM 虚拟机）- KVM/Xen/VMware
- 操作系统层面（Container 容器）- LCX/Docker/Kata Container
- 网络层面 - Linux Bridge/Open v Switch
编排方案
- VM （虚拟机编排方案）- OpenStack/VMWare Workstation
- Container（容器编排方案） - Kubernetes/Docker Swarm

云计算架构：

云计算使用四层架构对外提供服务。

云服务
- IaaS (lnfrastructure as a Service) - 云基础设施，对底层硬件资源池的抽象
- PaaS (Platform as a Service) - 基于资源池抽象，对上层提供的弹性资源平台
- SaaS (Software as a Service) - 基于弹性资源平台构建的云服务
- FaaS (Function as a Service) - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流

图片右边从下往上即为每一层的云服务所提供的服务类型，当充分使用云计算所提供的服务时，蛋糕店就可以更关注于业务层面，比如活动策划、会员激励、新品研发等等。

云部署模式（拓展）
- 私有云 - 企业自用
- 公有云 - AWS/Azure/Google Cloud/Huawei
- 混合云

云原生

云原生，实际是云原生（计算）的简称，它是云计算发展到现在的一种形态。

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

01 弹性资源

基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。具体可以分为弹性计算资源和弹性存储资源两个方面。总结：将存储资源当成服务一样。

弹性计算资源类型

资源服务调度
- 微服务
- 大服务
计算资源调度
- 在线计算 - 互联网后端服务
- 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk
消息队列
- 在线队列 - 削峰、解耦
- 离线队列 - 结合数据分析的一整套方案，如 ELK

弹性存储资源类型：

经典存储
- 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
- 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
关系型数据库
元数据
- 服务发现
NoSQL
- KV 存储 - Redis
- 文档存储 - Mongo

02 DevOps

DevOps 是云原生时代软件交付的利器贯穿整个软件开发周期。结合自动化流程，提高软件开发、交付效率。

设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致。

03 微服务架构

由单机服务演变而来的微服务架构，也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展；统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易。

微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。

HTTP - H1/H2 （RESTful API）
RPC - Apache Thrift/gRPC

如何在 HTTP 和 RPC 之间选择？

性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如熔断、降级、超时等
可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

所以使用时可以根据实际场景的特点结合协议特点进行协议种类选择。云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做。

04 服务网格

如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中 RPC 中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能。

什么是服务网格？

微服务之间通讯的中间层
一个高性能的 4 层网络代理
将流量层面的逻辑与业务进程解耦（业务代码与治理解耦）

没有什么是加一层代理解决不了的问题，服务网格相比较于 RPC/HTTP 框架：

实现了异构系统治理体验的统一化
服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理

云原生蛋糕店

企业级蛋糕店架构:

售卖
蛋糕制作(肉松、慕斯)
会员激励
满意度分析
研发新品

企业级后端架构的挑战及解决方案

挑战

基础设施层面：

Q：我们总说，云是弹性的，也就是说，在用户的角度，云提供的资源是无限的。然而，云背后的物理资源是有限的。在企业级后端架构里，云如何解决近乎无限的弹性资源和有限的物理资源之间的矛盾？

Q：闲事的资源就这么空着呢？如何提高资源利用率，提高物理资源的价值转换率？

用户层面：

Q：上了云原生微服务后，服务之间的通信开销较大，应该如何做成本优化？

Q：微服务看起来没有那么美好，抖动导致的运维成本较高，如何解决？

Q：异构的物理环境应该对用户是透明的，如何屏蔽这些细节？（异构环境下，不同实例资源水位不均）

离在线资源并池

在线业务的特点

I0 密集型为主
潮汐性、实时性

离线业务的特点

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

考虑到在线业务的潮汐性（存在晚高峰），物理资源的用量不是一成不变的。离在线资源并池的核心收益：

提高物理资源利用率
提供更多的弹性资源

同一台机器如何做离在线隔离，可以通过隔离CPU池实现。

自动扩缩容

将离在线资源并池后，就要考虑两种资源池分配的方法，这里利用在线业务潮汐性自动扩缩容，并且需要根据不同的场景，设置扩缩容依据的指标，一般在微服务中使用CPU利用率作为核心依据。核心收益 : 降低业务成本。

微服务亲合性部署

微服务之间的通信成本较高，是否可以：

形态上是微服务架构
通信上是单体架构

亲合性部署，通过将微服务调用形态与资源调度系统结合，将一些调用关系紧密、通信量大的服务部署在同一个机器上，并且使用 IPC 代替 RPC 的方式，降低网络通信带来的开销。核心收益 : 降低业务成本，提高服务可用性。

将满足亲合性条件的容器调度到一台宿主机，这样微服务中间件与服务网格就可以通过共享内存通信，服务网格控制面实施更灵活、动态的流量调度。

流量治理

核心收益 : 提高微服务调用容错性、容灾、进一步提高开发效率，DevOps 发挥到极致

解决思路 : 基于微服务中间件 & 服务网格的流量治理

熔断、重试
单元化
复杂环境 (功能、预览) 的流量调度

CPU水位负载均衡

Q：基础设施层往往是个复杂的异构环境，比如，有些机器的 CPU 是英特尔的，而有些是 AMD 的。就算是同一个品牌，也可能是不同代际。如何将这些差异屏蔽掉，使用户尽可能不感知呢？

Q：什么情况下，我们觉得，服务需要扩容了？异构环境会对这个评判标准产生怎样的影响？

物理异构环境产生容器资源水位差异。

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

laaS
- 提供资源探针
服务网格
- 动态负载均衡

核心收益:

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

后端架构实战

问题

如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，打平不同宿主机异构环境的算力差异。也就是CPU水位负载均衡，应该如何设置？

1.需要哪些输入?
2.设计时需要考虑哪些关键点?

问题提炼

输入:

服务网格数据面
- 支持带权重的负载均衡策略
注册中心存储了所有容器的权重信息
宿主机能提供
- 容器的资源使用情况
- 物理资源信息 (如 CPU 型号)

关键点：

紧急回滚能力
大规模
极端场景

自适应静态权重（版本1）

方案:

采集宿主机物理资源信息
调整容器注册的权重

优势:

复杂度低
完全分布式，可用性高
微服务中间件无适配成本

缺点:

无紧急回滚能力
缺乏运行时自适应能力

自适应动态权重 Alpha（版本2）

方案:

容器动态权重的自适应调整
服务网格的服务发现 & 流量调度能力

演进方向:

解决无法紧急回滚的问题
运行时权重自适应

缺点:

过度流量倾斜可能会有异常情况

自适应动态权重 Beta（版本3）

方案:

服务网格上报 RPC 指标