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

前言

本文主要介绍企业级后端架构相关的知识。

重点内容

架构简介
企业级后端架构剖析
企业级后端架构的挑战

知识点介绍

架构简介

定义

定义：架构，又称软件架构（实现一个软件有很多种方法，架构在方法选择上起着至关重要的指导作用）

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

架构的重要性：架构对于一个软件的重要性，和地基对于一栋楼房的重要性是类似的

架构没设计好，软件容易崩，用户体验上不去。最终要么重构，要么放弃
架构设计好了，软件的稳定性上去了，用户体验高了，口碑一点点就打造出来了
良好的架构基础，也为软件的未来发展提供了更多的可能。为用户赋能，实现自身价值

单机架构

软件系统需要具备对外提供服务，单机就是所有的东西都在一个进程里，部署在一个机器上。

优点：

简单

缺点：

运维需要停服，用户体验较差
承载能力有限

单体架构

分布式部署，在单机架构的基础上，将进程部署到多个机器上。

优点：

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

缺点：

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

垂直应用架构

在单机架构基础上，将进程按照某种依据切分开。比如，A 软件和 B 软件的后端原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。

优点：

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

缺点：

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

SOA (面向服务架构)

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

优点：

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

缺点：

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

微服务

在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。

优点：

兼具 SOA 解决的问题
服务间的通信更敏捷、灵活

缺点：

运维成本

企业级后端架构剖析

云计算

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

基础：

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

架构：

云服务
- IaaS - 云基础设施，对底层硬件资源池的抽象
- PaaS - 基于资源池抽象，对上层提供的弹性资源平台
- SaaS - 基于弹性资源平台构建的云服务
- FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流
云部署模式（拓展）
- 私有云 - 企业自用
- 公有云 - AWS/Azure/Google Cloud/Huawei
- 混合云

云原生

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

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

云原生.png

弹性资源

基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。

弹性计算资源：

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

弹性存储资源：

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

在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。

DevOps

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

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

微服务架构

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

HTTP - H1/H2
RPC - Apache Thrift/gRPC

在 HTTP 和 RPC 之间选择

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

微服务架构.png

服务网格

服务网格：

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

服务网格相比较于 RPC/HTTP 框架：

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

服务网格.png

企业级后端架构的挑战

挑战

基础设施层面

物理资源有限
资源利用率受制于部署服务

用户层面

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

解决思路

离在线资源并池

考虑到在线业务的潮汐性，物理资源的用量不是一成不变的。离在线资源并池，可以：

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

离在线资源并池.png

自动扩缩容

降低业务成本，可以利用在线业务潮汐性自动扩缩容

自动扩缩容.png

微服务亲合性部署

微服务之间的通信成本较高：

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

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

微服务亲和性部署.png

流量治理

核心收益：

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

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

熔断、重试
单元化
复杂环境的流量调度

CPU 水位负载均衡