一、架构基础

• 架构定义：有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计
• 常见软件架构
  • 单机：所有功能都实现在一个进程里，进程部署在单台机器上，运维时需要停服
    • C10K问题（Concurrent 10,000 Connection）：服务器如何支持10K个并发连接，进行高性能网络编程。解决方式：采用IO复用模型epoll方法，在调用返回时，只给应用提供发生了状态变化的文件句柄，不需要轮询fd（文件描述符）
    • 单机架构瓶颈：
      • 需要大量进程 / 线程作为处理单元，需要占用大量内存空间
      • 进程 / 线程切换，系统调度代价高
    • 解决方案：采用协程（Routine），一个线程中，存在多个协程。协程实现如Go语言的轻量级线程Goroutine。协程由程序控制，在用户态中执行，在线程的基础上通过分时复用的方式运行多个协程
      • 协程适用场景：IO密集型任务，异步IO型任务（异步IO型任务包括：主动查询是否有数据；被动监听是否有数据状态）
  • 单体：分布式部署，进程部署在多台机器上，具备水平扩容能力（添加更多服务器），运维不需要停服
    • CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三项中的两项
      • 一致性：所有节点同时看到相同的数据
      • 可用性：读写总是成功的
      • 分区容错性：尽管任意消息存在丢失或部分系统存在故障，系统继续运行
  • 垂直应用：单体架构基础上，将进程按照应用垂直切分开的单体，在一定程度上减少了后端进程职责
  • 面向服务型架构（SOA，Service Oriented Architecture）：将进程按照不同的功能单元进行抽象，拆分为服务。SOA为服务间通信提供标准，采用重量级协议，如SOAP及其他WS标准
  • 微服务（Micro-Service）：SOA的去中心化的演进，每个服务都有自己的数据模型和数据库
    • 注意事项：
      • 数据一致性
      • 高可用
      • 治理、容灾
      • 解耦 vs. 过微
      • 权衡运维成本
• 架构演进方式：业务需求量逐渐增大、系统逐渐复杂
  • 水平切分：分层 / 模块化
  • 垂直切分：分布式

二、企业级后端架构

• 云计算：通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模数据分析和存储的基石
  • 虚拟化技术：对计算机资源的抽象，实现资源隔离与共享，资源异构性屏蔽，资源池化
    • 硬件层：VMware
    • 操作系统层：Docker
    • 网络层：Open V Switch（OVS），基于软件实现的开源虚拟交换机
  • 编排方案
    • VM：OpenStack（一款开源虚拟化平台） / VMWare Workstation
      • OpenStack各组件：
        • Horizon，Web前端服务
        • Nova，计算服务
        • Neutron，网络服务
        • Swift，对象存储服务
        • Cinder，块存储服务
        • Keystone，认证服务
        • Glance，镜像服务
        • Ceilometer，监控服务
        • Heat，集群服务
        • Trove，数据库服务
    • Container：Kubernetes、Docker Swarm
• 云架构
  • IaaS：Infrastructure as a Service，基础设施即服务，对底层硬件资源池的抽象。消费者在其中的角色是开发者或系统管理员。如阿里云的ECS云主机、Amazon EC2（2006年推出）
  • PaaS：Platform as a Service，平台即服务，基于资源池抽象，云中有完整开发和部署环境。消费者在其中的角色是开发者。如Google App Engine、Windows Azure Platform
  • SaaS：Software as a Service，软件即服务，基于弹性资源平台，一切不需要本地化部署的云服务软件产品。消费者在其中的角色是终端用户。如OA、CRM、E-mail服务
  • FaaS：Function as a Service，函数即服务，更轻量级的函数服务。开发者只需要编写业务代码，无需关注服务器，并且代码的执行由事件触发。如LeetCode的Online Judge系统、AWS Lambda
• 云原生（Cloud Native）：构建和运行可弹性拓展的应用
  • 弹性资源
    • 弹性计算资源：虚拟化容器、快速扩缩容
      • 服务资源调度
        • 微服务
        • 大服务：调用量多
      • 计算资源调度
        • 在线计算：互联网后端服务，如热销榜单
        • 离线计算：大数据分析，MapR / Spark / Flink，如热销榜单更新
      • 消息队列
        • 在线队列：削峰、解耦
        • 离线队列：结合数据分析的一整套方案，如ELK
    • 弹性存储资源：将存储资源当成服务一样
      • 经典存储
        • 对象存储：视频、图片等
        • 大数据存储：应用日志、用户数据等
      • 关系型数据库
      • 元数据：
        • 服务发现：程序如何通过一个标志来获取服务列表，并且这个服务列表能够随着服务的状态而动态变更
      • NoSQL
        • KV存储：Redis
        • 文档存储：MongoDB
  • 微服务架构：提供业务功能单元解耦，提供统一的通信标准。微服务将单一应用程序划分成一组小的服务，每个服务域进行在独立的进程中。云原生场景下，微服务不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做
    • 通信协议：轻量级的通信机制
      • HTTP（RESTful API）
      • RPC（Thrift，gRPC）
    • 微服务中间件RPC和HTTP：选用时从性能（RPC提供大量压缩方案）、服务治理、协议可解释性（HTTP的JSON格式）来考虑
    • 微服务的部署方式
      • 虚拟机
      • 容器
        • 解决了应用程序运行环境依赖
        • 实现计算资源、网络、存储的隔离
        • 提高部署密度和计算资源的利用率
      • 无服务器模式（Serverless）：由开发者实现的服务端逻辑运行在无状态的计算容器中，由事件触发，完全被第三方管理
        • 无需管理基础设施
        • 事件驱动
        • 自动化构建部署
        • 无服务器计算 = FaaS + BaaS（Function as a Service + Backend as a Service）
  • DevOps：贯穿整个软件开发周期
    • 敏捷开发
    • CI / CD（Continuous Integration / Continuous Delivery，持续集成 / 持续交付）：实现应用开发中高度持续自动化和持续监控
  • 服务网格（Service Mesh）：微服务之间通信的中间层，一个高性能的四层网络代理，数据平面代理与业务进程采取进程间通信的模式，将流量层面的逻辑（包含治理）与业务进程解耦
    • 业务与治理解耦，生命周期易于管理
    • 异构系统的治理统一化
    • 具有复杂治理能力

三、后端架构的挑战

• 基础设施层面
  • 存在问题：
    • 离线任务（主要为CPU密集型，非实时性）和在线任务（主要为IO密集型，潮汐性、实时性）的物理资源用量峰期不同。
    • 物理资源有限、带宽有限，资源利用率受限于部署服务
  • 解决思路：
    • 离在线资源并池：采用混合资源池，按时间段划分离线资源池和在线资源池，提高物理资源利用率
    • 同一个机器上的离在线隔离：使用容器对CPU核心做隔离，使用cgroup统一对离在线进程进行分组
    • 利用在线业务潮汐性自动扩缩容，扩缩容的依据指标：如CPU使用率的P50数值（中位数值）、内存利用率等
• 用户层面
  • 存在问题：
    • 网络抖动导致运维成本提高
    • 异构环境中，不同实例间的算力差异（CPU型号差异、网络请求差异）
  • 目标：打平异构环境算力差异，为自动扩缩容提供正向输入
  • 解决思路：如何屏蔽异构环境的算力差异？CPU水位负载均衡
    • IaaS：提供资源探针（Probe）
    • 服务网格：动态负载均衡
• 微服务层面
  • 存在问题1：微服务间的高通信成本
  • 目标：降低业务成本，提高服务可用性
  • 解决思路：微服务亲和性部署，满足亲和性条件的容器微服务中间件采用IPC（Inter-Process Communication）通信，不满足亲和性条件的容器通过服务网格RPC（Remote Procedure Call），从而减少网络通信。
    • 将满足亲和性条件（调用关系紧密、通信量大的服务）的容器部署到一台宿主机
    • 微服务中间件与服务网格通过共享内存通信
    • 服务网格控制面实施灵活、动态的流量调度
  • 存在问题2：流量治理问题
  • 目标：提高微服务调用容错性、提供容灾、DevOps提高开发效率
  • 解决思路：基于微服务中间件和服务网格的流量治理
    • 熔断、重试
    • 单元化
    • 复杂环境（功能、预览）的流量调度

四、后端架构实战

• 如何做架构设计
  • 需求先行：问题定义
  • 业界调研：可参考的业界解决方案
  • 技术选型：内部 / 社区中的基础组件
  • 考虑异常情况：考虑某服务不行了怎么办
• 基本概念
  • 负载均衡（Load Balancing）：将工作负载分布到多个服务器来提高服务的性能和可靠性
  • 服务发现（Service Discovery）：容器部署在集群时，服务地址（IP和端口）是集群动态分配的。服务发现解决了在微服务中如何精确的定位需要调用的服务IP及端口
  • 服务注册（Service Registry）：服务提供者将自己的服务地址等信息登记到服务注册中心
  • 注册中心：服务提供者和服务消费者之间的桥梁，提供管理和查询服务注册信息的API。当服务提供者的实例发生变更时，服务注册表更新最新的状态列表，并通知服务消费者
    • 如Zookeeper、Netflix Eureka
  • 宿主机（Host）：可以是物理机或虚拟机
  • 容器（Container）：包含了完整的运行时环境，基于内核的轻量级虚拟化技术。容器允许同一物理或虚拟服务器上毫不冲突地运行多项工作负载
  • 时序数据（Times Series）：与时间序列相关的数据，如哨兵监控的指标数据、业务数据（JVM GC、时延）
  • 一致性哈希（Consistent Hash）：由于HTTP协议的无状态，服务器可能选择存储会话日志来记住用户，从而减少身份验证。因此，在添加或删除服务器时，需要尽可能减少对其他服务器的影响
    • 一致性哈希算法的步骤：
      • 将服务器节点哈希映射到[0, 2^32-1]的整数圆环上
      • 将请求哈希映射到圆环上
      • 从请求哈希映射的顺时针方向找到其右侧最近的服务器
    • 作用：增加 / 删除服务器时，最多只有一台服务器会受到服务器数量变化的影响
• 问题：如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，屏蔽不同宿主机异构环境的算力差异？
  • 输入
    • 服务网格数据面：支持带权重的负载均衡策略，服务发现，流量调度
    • 注册中心：存储所有容器的权重信息
    • 宿主机：提供容器的资源使用情况、物理资源信息（如CPU型号）
  • 关键点
    • 紧急回滚能力
    • 大规模场景中使用：主要考虑系统稳定性和计算瓶颈
    • 极端场景
• 架构演进方向
  • 方案一：自适应静态权重。采集宿主机物理资源信息，调权代理调整容器注册的权重，缺少紧急回滚能力
  • 方案二：自适应动态权重。动态权重决策中心从注册中心获取和更新服务注册信息，从配置中心获取服务在注册中心的名字，通过计算赋予服务运行时自适应动态权重，具备紧急回滚能力
  • 方案三：在服务网格层面上报RPC指标（e.g. 实例：X:9090，延迟P50:10ms，延迟P99:100ms），防止权重调节过于偏颇。动态权重中心除了方案二的作用以外，还采集所有服务容器指标，使得极端场景处理成为可能，但时序数据库压力较大
  • 方案四：构建更复杂的动态权重决策中心
    • 微服务化进行拆分（如分为入口层、离线分析层、在线分析层等）
    • 引入消息队列削峰、解耦
    • 离在线链路切分
    • 梳理强弱依赖

 参考文献

[1]兰新宇. 架构初探-谁动了我的蛋糕. 参考链接