架构初探

本文来源于第五届字节跳动青训营活动，已收录到架构初探 | 青训营笔记 - 掘金 (juejin.cn) ，主要记录了对架构分析设计的学习

1. 什么是架构

定义

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

实现一个软件有很多种方法，架构在方法选择上起着至关重要的指导作用。

架构的重要性

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

1.1 问题

如何设计
如何开发
如何运营
…

1.2 单机

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

优点：简单，是最基本的架构

缺点

单体服务存在架构瓶颈（高并发连接问题，是单体架构本身的设计缺陷）
运维的时候需要停服，届时用户无法使用服务

单机服务的模式除了简单之外没有任何优点。当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段，但凡业务有发展和迭代的需求，就应该优先快速做架构迭代。

1.3 单体、垂直应用 | 垂直切分

把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。负载均衡层用于引导用户去正常工作的机器。

在单体架构的基础上进一步地再把不同应用的代码从之前的一个大的进程中拆分出来，就来到了垂直应用架构。

单体架构通过分布式部署逐步演化为分布式架构，垂直应用架构就是一种分布式架构。
垂直应用架构：按应用垂直切分单体并进行分布式部署的架构。
优点
- 水平扩容
- 运维不需要停服
缺点
- 职责太多，开发效率不高
- 爆炸半径大（即影响范围大），小变动可能会引起大范围的问题

根据应用把架构做垂直拆分仍存在缺陷，于是演化出了根据模块/职责对架构进行水平拆分。

1.4 SOA、微服务 | 水平切分

把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，并为它们之间的通信定义标准，便得到了SOA架构。

SOA(Service-Oriented Architecture)

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

两个重要概念

服务：根据功能抽象出来的概念。比如，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等。
通信标准：服务之间通信的基石。

为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。由于中心化的方案较重，拓展性差，普及性不高。这里就考虑去中心化方向。去中心化方向的最终形态就是微服务架构。

微服务架构：SOA 的去中心化演进方向
优点
- 不同模块的开发者可以各司其职，开发迭代效率得到显著提高
- 各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高

垂直切分和水平切分带来的一系列问题

单机部署演进而来的分布式架构，存在数据一致性问题
服务的不断拓展，依赖关系的复杂化，如何实现高可用
多个微服务的管理运维问题
微服务的目标是强化单一职责，控制爆炸半径，在解耦和过微之间取舍

小结

架构的演进初衷

需求量越来越大，需要增加人手
整体逻辑越做越复杂，需要分工合作

架构的演进思路

垂直切分：按照应用切分
水平切分：按照服务切分

2.企业级后端架构剖析

2.1 云计算

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

基础

虚拟化技术：硬件（虚拟机）、操作系统（容器）、网络
编排方案：虚拟机编排方案（OpenStack）、容器编排方案（Kubernetes）

架构

Iaas（Infrastructure as a Service）
Paas（Platform as a Service）
SaaS（Software as a Service）
Faas（Function as a Service）

2.2 云原生

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

云原生技术为在公有云、私有云、混合云等新型的动态环境中构建和运行可弹性拓展的应用提供了可能性。它的代表技术有

容器化
服务网格
微服务
不可变基础架构
声明式 API

基于这些技术，开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。

云原生主要涉及四个大方面

弹性资源：基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面，kubernetes 技术已经称为了业界的标准
微服务架构：微服务架构也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展；统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易
DevOps：设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致
服务网格：如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中 RPC 中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能

2.2.1 弹性计算资源

弹性计算资源类型

服务资源调度：微服务和大服务
计算资源调度：在线和离线
消息队列：在线和离线

2.2.2 弹性存储资源

弹性存储资源类型

典型：对象和数据
关系型数据库
元数据：服务发现
NoSQL

将存储资源视为服务

2.2.3 DevOps

DevOps 是云原生时代软件交付的利器，贯穿整个软件开发周期。

结合自动化流程，提高软件开发、交付效率

2.2.4 微服务架构

通信标准

HTTP（RESTful、API）
RPC（Thrift、gRPC）

微服务中间件 RPC vs HTTP

性能
服务治理
协议可解释性

云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做。

2.2.5 服务网格

服务网络（Service Mesh）

微服务之间通讯的中间层
高性能网络代理
业务代码与治理解耦

相比较于 RPC/HTTP 框架

异构系统治理统一化
与业务进程解耦，生命周期易管理

企业级后端架构的挑战

问题

基础设施层面：
- 物理资源是运有限的，机器和带宽
- 资源利用率受制于部署服务
用户层面
- 网络通信开销较大
- 网络抖动导致运维成本提高
- 异构环境下，不同实例资源水位不均

3.1 离在线资源并池

核心收益

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

解决思路：离在线并池

在线业务的特点
- IO 密集型为主
- 潮汐性、实时性
离线业务的特点
- 计算密集型占多数
- 非实时性

在同一个机器做离在线隔离，使用自动扩缩容

3.2 自动扩缩容

核心收益：降低业务成本

解决思路：自动扩缩容，利用在线业务潮汐性自动扩缩容

扩缩容依据的指标，微服务亲和性部署

3.3 微服务亲和性部署

核心收益

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

解决思路：微服务亲和性部署

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

3.4 流量治理

核心收益

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

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

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

CPU 水位负载均衡

核心收益

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

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

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

4. 后端架构实战

问题提炼

输入

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

关键点

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

4.1 自适应静态权重

方案

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

优点

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

缺点

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

4.2 自适应动态权重 Alpha

方案

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

优点

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

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

4.3 自适应动态权重 Beta

方案：服务网格上报 RPC 指标

优点：极端场景的处理成为可能

缺点

时序数据库压力较大
动态权重决策中心职责越来越多，迭代 -> 变更 -> 风险

4.4 自适应动态权重 Release

演进方向

微服务化
引入消息队列削峰、解耦
离在线链路切分
梳理强弱依赖
解决在线分析引擎的数据一致性问题：一致性哈希
解决时序数据库压力：将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算
离线分析：使用消息队列解耦、削峰
离线回馈在线

总结

没有最好的架构，只有最合适的架构

架构设计的流程

需求先行。弄清楚要解决什么问题
业界调研。业界都有哪些解决方案可供参考
技术选型。内部/社区都有哪些基础组件
异常情况。考虑清除应对各种异常问题的方案

参考资料

软件架构的演变-单体架构，垂直架构，分布式架构，SOA架构和微服务架构的演变历程 - 知乎

水平拆分 & 垂直拆分 - 知乎