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

服务架构定义

定义

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

架构在方法选择上起着至关重要的指导作用。

单机架构

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

优点

• 实现简单

问题

• 普通设备很难应对C10K问题：C是指Client，而10K则是一万的意思。C10K就是单机同时并发一万个请求。同理c100k则是同时并发十万个请求，如今百万请求也十分常见了
• 运维需要停服，降低了用户体验
• 服务能力有瓶颈，承担不了大量请求

单体架构

分布式部署，即横向扩展，使多台机器作为服务器，设置一个分流机制将客户请求分给不同的机器处理。

优点

• 运维不需要停服
• 具备水平扩容能力
• 性能高、冗余小

问题

• 单体机器的职责还是太多，越来越臃肿，开发效率提不上去
• debug困难，模块相互影响
• 爆炸半径大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

SOA、微服务|水平切分

垂直应用架构

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

优点

• 一定程度上减少了后端进程职责，业务独立开发
• 一定程度上缩小爆炸半径

问题

• 没有根本解决单体架构的问题，每个业务还是单体
• 不同业务存在冗余

SOA (面向服务架构)

SOA 架构中，将应用的不同功能单元抽象为服务，以服务为中心，面向服务 ，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性，使各机器间可以协调处理请求。

分布式架构图

优点

• 各服务的职责更清晰，业务无关的独立服务

缺点

• 调用关系复杂，不同服务冗余
• 服务器bug可能导致服务瘫痪

SOA架构图

优点：

• 运维粒度减小到服务，爆炸半径可控
• 服务注册

问题

• ESB (企业服务总线) 往往需要一整套解决方案
• 整个设计是去中心化的
• 需要从上到下设计
• 重构困难

微服务

在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务，其职责和服务拆分的更加细致，去除了类似通信中转站的部分，提倡服务之间自由建立互通方式，避免中心化，耦合性更低。

优点

• 兼具 SOA 解决的问题
• 服务间的通信更敏捷、灵活
• 自下而上设计
• 业务独立设计，故障隔离

问题

• 数据一致性
  不同服务对于数据库的读取操作有可能出现脏数据
• 高可用
  可维护性
• 治理
  对于突发情况的承受力，容灾能力仍可提升
• 解耦 vs 过微
  横向扩展较大，运维成本提高

微服务架构概览

演变规律

• 需求量越来越大，终归要增加人手，以提高对外服务能力
• 越做功能越复杂，需要良好的通信机制使得各模块的开发者分工合作

架构演进的思路

• 需求越来越大，要对大规模的请求做划分
• 竖直切分：增加横向拓展的能力，即分布式
• 横向切分：每个模块独立更强，耦合性降低，即分层/模块化

企业级后端架构剖析

云计算

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

云计算基础

虚拟化技术

• 硬件层面（VM 虚拟机）- KVM/Xen/VMware
• 操作系统层面（Container 容器）- LCX/Docker/Kata Container
• 网络层面 - Linux Bridge/Open v Switch

使用方式

• 使用一台机器的全部资源
• 使用一台机器中的几台虚拟机

编排方案

• VM - OpenStack/VMWare Workstation
• Container - Kubernetes/Docker Swarm

使用方式

• 自我管理
• 托管

云计算架构

云服务

• IaaS(Infrastructure 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
• 混合云

使用了云计算，开发者就可以把专注于最上层业务的实现，而不用关注底层的实现细节。

类比于蛋糕店：

云原生

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

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

• 弹性资源
• 微服务架构
• DevOps
• 服务网格

弹性资源

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

弹性计算资源

• 服务资源调度

  • 微服务(使用的核数比较少，可以快速的完成)
  • 大服务

• 计算资源调度

  • 在线计算 - 互联网后端服务，比如热搜、头条的展示是在线的计算资源
  • 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk，分析热搜的热度，是否需要调整榜单位置等的计算服务放到离线中去调度

• 消息队列

  • 在线队列 - 削峰、解耦，具有非常大的吞吐量，能对入队的海量数据进行削峰处理，使得用户只负责把消息排到队列里
  • 离线队列 - 支持很多大数据分析的套件，把数据分析的流程搭建起来，结合数据分析的一整套方案，如 ELK

弹性存储资源

• 经典存储

  • 对象存储 - 视频、图片等宣传手段。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
  • 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验，如用户的消费记录

• 关系型数据库

  • 比如收款记录与信息，这些字段间具备强关系性的数据库

• 元数据

  • 服务发现，让关键信息作为索引，比如通讯录中的名字，提高查询的效率

• NoSQL

  • KV 存储 - Redis，输入一个Key给出一个Value
  • 文档存储 - Mongo

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

DevOps

敏捷开发，有很多开源软件和公司提供支持，是云原生时代软件交付的方式，贯穿整个软件开发周期的工作流。

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

软件的生命周期：

微服务架构

微服务架构下，业务功能单元解耦，划分职责清晰，具备统一的通信标准，使得服务之间可以进行通信，产生多样化业务形态。服务之间的通讯标准是基于协议而不是 ESB 的。

通信标准有：

• HTTP - RESTful API
• RPC - Apache Thrift/gRPC

微服务中间件(提供了RPC和HTTP的能力) RPC vs HTTP：

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

服务网格

什么是服务网格？

• 异构系统的治理统一化，使得不同语言编写的程序都可以运行
• 复杂治理能力
• 微服务之间通讯的中间层
• 一个高性能的 4 层网络代理
• 将流量层面的逻辑与业务进程解耦，业务代码与治理解耦，把服务和网络通信解耦

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

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

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

云原生背景下，以运营蛋糕店为例的架构设计：

企业级后端架构的挑战

挑战分析

基础设施层面

• 物理资源是有限的
  • 机器
  • 带宽
• 资源利用率受制于部署服务

用户层面

• 网络通信开销较大
• 网络抖动导致运维成本提高
• 异构环境下，机器的处理能力是不一样的，部署相同服务所占用的资源量级(如CPU使用率)是不一样的

应对方案

离在线资源池

将离在线资源池合并，由于在线业务具备潮汐性，即不同时间段用户的请求量是不同的，所以物理资源的用量不是一成不变的，故混合资源池可以造成的核心收益为：

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

• 在线业务的特点

  • IO密集型为主
  • 潮汐性(根据用户量不同的时间段进行不同的资源划分)、实时性(延迟比较敏感)

• 离线业务的特点

  • 计算密集型占大多数，任务可能花较长时间才能结束
  • 非实时性

在、离线在CPU资源上是隔离的，即各用各的，但在不同的场景可以对离、在线资源池进行资源的分配。由此利用在线业务的潮汐性实现了自动扩缩容，业务感知上降低了成本。

扩缩容依据的指标：CPU的某一个分位数，比如CPU的P50(50的百分位数)，同时由于一些服务对内存要求较高，要把内存和CPU结合在一起作为指标。

微服务亲和性部署

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

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

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

微服务亲和性即联系紧密，有大量的网络通信的架构设计，其核心受益为：

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

解决思路：

• 将满足亲和性条件的容器调度到一台宿主机
• 微服务中间件与服务网格(具有中心化的控制面，能够感知到各容器的流量大小，可以使得各容器的流量均衡)通过共享内存通信，降低网络开销，降低调度方和被调度方的CPU利用率
• 服务网络控制面实施灵活、动态的流量调度

流量治理

核心受益

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

解决思路：

• 基于微服务中间件 & 服务网格的流量治理
• 熔断、重试
• 单元化
• 复杂环境(功能、预览)的流量调度

CPU水位负载均衡

核心受益

• 打平异构环境算力差异
• 为自动扩缩容提供正向输入 解决思路
• IaaS
  • 提供资源探针
• 服务网格
  • 动态负载均衡

根据资源探针检测各容器中的CPU和内存利用率，来实时确保各容器的负载能处于相对均衡的状态。

CPU水位负载均衡，如何设计？

分析背景

• 需要哪些输入？
  明确各宿主机的工作效率，能者多劳
• 设计时需要考虑哪些关键点？
  考虑各宿主机效率的动态变化以及动态更新、容灾等

问题提炼

输入

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

关键点

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

解决方案

自适应静态权重

方案

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

优势

• 复杂度低
• 完全分布式，可用性高
• 微服务中间件无适配成本，只需要感知流量

缺点

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

自适应动态权重Alpha

方案

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

演进方向

• 解决无法紧急回滚的问题
• 运行时权重自适应，出现问题时可以随时切回静态权重

缺点

• 过度流量倾斜可能会有异常情况，如一个部署上的服务的权重太高
• 出现网络故障，没有指标作为参考来调制权重

自适应动态权重Beta

方案

• 服务网络上报RPC指标，作为流量调节的指标
• 增加数据面分析

演进方向

• 极端场景的处理成为可能

缺点

• 时序数据库压力较大
• 动态权重决策中心职责越来越多，迭代->变更->风险，类似于单体服务

自适应动态权重Relese

演进方向

• 微服务化
• 引入消息队列削峰、解耦
• 离在线链路切分
• 梳理强弱依赖

通过在线分析引擎快速得到得到各宿主机的权重，离线分析进入离线数据库，作为在线分析的参考数据。

以上内容若有不正之处，恳请您不吝指正！