day13 架构定义解析 | 青训营笔记

yeyr2
118 阅读11分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天,今天讲解架构的一些基础知识.

一.什么是架构

1.定义

  • 架构,又称软件架构,
    • 是有关软件整体结构与组件的抽象描述
    • 用于指导系统各个方面的设计
  • 架构的重要性
    • 架构没设计好，软件容易崩，用户体验上不去。最终要么重构，要么放弃
    • 架构设计好了，软件的稳定性上去了，用户体验高了，口碑一点点就打造出来了
    • 良好的架构基础，也为软件的未来发展提供了更多的可能。为用户赋能，实现自身价值

2.常见软件架构:

  • 单机
  • 单体
  • 垂直应用
  • SOA (Service Oriented Architecture)
  • 微服务 (Microservice)

3. 单机架构

All in one，所有的东西都在一个进程里，部署在一个机器上。

一个进程负责全部功能.

优点：

  • 简单

缺点：

  • 运维需要停服，用户体验较差
  • 承载能力有限。了解下 c10k 问题

4. 单体架构

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

一个进程负责多个功能,多个进程一起工作,干相同的活,需要具备所有功能的全部过程,非常庞大.

优点：

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

缺点：

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

5. 垂直应用架构(垂直切分)

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

一个进程负责一个功能,多个进程分工合作,但依然需要完成功能的全部过程,依然比较庞大.

优点：

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

缺点：

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

6. SOA (面向服务架构)

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

一个进程负责一个功能的部分功能,多个进程分工合作,只需要完成功能的部分过程.

优点：

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

缺点：

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

7. 微服务(水平切分)

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

一个进程负责一个功能的部分功能,多个进程分工合作,只需要完成功能的部分过程,是SOA去中心化的演进方向,将所有功能划分更加清晰.

挑战:

  • 数据一致性
  • 如何保持多个进程之间交流,保证进程的可用性
  • 如何在一个进程出错后使整个服务不受影响或减轻影响
  • 运维成本提高了,是否值得

优点：

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

缺点：

  • 运维成本

二.企业级后端架构剖析

1. 云计算

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

  • 基础

    • 虚拟化技术 - 整租 vs 合租
    • 编排方案 - 业主 vs 租赁平台

  • 架构

    • image.png

    • IaaS (基础架构服务)

      • 屏蔽底层一些概念,只需要直接使用,不用处理一些琐碎的事情.
      • IaaS 客户通过互联网等广域网 (WAN)访问资源和服务，并可以使用云提供商的服务来安装应用程序堆栈的其余元素。
      • 例如，用户可以登录IaaS平台创建虚拟机（VM）；在每个虚拟机中安装操作系统；部署中间件，如数据库；为工作负载和备份创建存储桶；并将企业工作负载安装到该 VM 中。然后，客户可以使用提供商的服务来跟踪成本、监控性能、平衡网络流量、解决应用程序问题和管理灾难恢复。
      • 买房子 vs 房屋租赁平台

    • PaaS (平台服务)

      • 允许客户提供、实例化、运行和管理模块化捆绑包，其中包括计算平台和一个或更多的应用程序，无需构建和维护通常与开发和启动应用程序相关的基础设施的复杂性；并允许开发人员创建、开发和打包此类软件包。
      • 清包 vs 全包

    • SaaS (软件服务)

      • SaaS 是一种软件分发模型
      • SaaS 应用程序有时称为基于 Web 的软件、托管软件。
      • SaaS 应用程序都在 SaaS 提供商的服务器上运行。提供商管理对应用程序的访问，包括安全性、可用性和性能。
      • 上手成本很低
      • 从零培训 vs 雇佣培训过的师傅

    • FaaS (功能服务)

      • 允许客户执行代码以响应事件，而无需管理通常与构建和启动微服务应用程序相关的复杂基础设施("微服务")。
      • 纯手工制作 vs 蛋糕机批量生产

  • 虚拟化技术

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

2. 云原生

云原生是在云计算环境中构建、部署和管理现代应用程序的软件方法.

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

简介

  • 弹性资源

    • 虚拟化容器
    • 快速扩缩容器

  • 微服务架构

    • 业务功能单元解耦
    • 统一的通信标准

  • DevOps

    • 敏捷开发
    • CI/CD

  • 服务网络

    • 业务与治理解构 : 业务更进一步解耦,把服务和网络通信解耦.
    • 异构系统的治理统一化 : 对于可能使用的不同语言,为这些语言提供统一的通信方案
    • 复杂治理能力

弹性计算资源类型

  • 服务资源调用 : 根据服务占用资源量进行拆分
    • 微服务 : 和面,雕花
    • 大服务 : 烤箱
  • 计算资源调度 :
    • 在线 : 热销榜单
    • 离线 : 热销榜单更新
  • 消息队列 :
    • 在线 : 削峰,解耦
    • 离线 : 大数据分析
  • 经典
    • 对象 : 宣传视频
    • 大数据 : 用户消费记录
  • 关系型数据库
    • 收银记录
  • 元数据
    • 服务发现 : 蛋糕店通讯录
  • NoSQL
    • KV(key,value) : 来个XX蛋糕

将存储资源当成服务一样

DevOps

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

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

image.png

微服务架构

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

  • 通信标准

    • HTTP(RESTful API)
    • RPC(Thrift,gRPC)

  • 微服务中间件 RPC vs HTTP "

    • 性能 : RPC会有通信压缩,一般可能比HTTP好一点
    • 服务治理 : RPC的中间件可能具备一些服务治理的能力,比如超时的控制,跳过事件请求其他事件.
    • 协议可解释性 : HTTP使用的JSON有比较好的协议可解释性.

image.png

服务网格

  • 服务网格

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

  • 相比于 RPC/HTTP 框架 :

    • 异构系统统治统一化
    • 与业务逻辑解耦,生命周期易管理 : 框架升级与业务升级解耦,不必一同绑定升级

image.png

云原生蛋糕店

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

image.png

三.企业级后端架构的挑战

1.问题 -- 挑战

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

image.png

2.离在线资源并池

  • 核心收益

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

  • 解决思路 : 离在线资源并池

  • 在线业务特点

    • IO 密集型为主
    • 潮汐性,实时性

  • 离线业务特点

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

image.png

问题 : 同一个机器如何做离在线隔离?

可以使用容器化的方式,对CPU的核心做隔离,离线用离线的,在线的用在线的.

3. 自动扩缩容

  • 核心收益 :
    • 降低业务成本
  • 解决思路 :
    • 自动扩缩容
    • 利用在线业务潮汐性自动扩缩容

image.png

问题 : 扩缩容依据什么指标

根据不同场景进行设计,针对绝大部分使用场景,CPU的使用量可能会比较高,内存使用量不会特别高,可以使用CPU的某一个统计的分配数作为指标,来衡量这个服务整个资源的使用情况;对于内存要求高的,可以把内存和CPU结合起来作为指标.
业务的请求量级作为扩缩容指标,是不容易量化的,是比较困难的.

4.微服务亲合性部署

  • 核心收益 :

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

  • 解决思路 : 微服务亲合性部署

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

image.png

5. 流量治理

  • 核心收益

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

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

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

6.CPU水位负载均衡

  • 核心收益 :

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

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

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

image.png

根据宿主机提高资源探针,告诉CPU使用量,内存使用量,然后尝试反馈到负载均衡层面,进行调节.

四.后端架构实战

1.CPU水位负载均衡,应该如何设计

  • 问题细分:

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

  • 输入

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

  • 关键点

    • 紧急回滚能力
    • 大规模
    • 极端情况

image.png

2. 自适应静态权重

  • 方案
    • 采集宿主机物理资源信息
    • 调整容器注册得到权重
  • 优势
    • 复杂度低
    • 完全分布式,可用性高
    • 微服务中间件无适配成本
  • 缺点
    • 无紧急回滚能力
    • 缺乏运行时自适应能力

image.png

3.自适应动态权重 Alpha

  • 方案
    • 容器动态权重的自适应调整
    • 服务网络的服务发现 & 流量调度能力
  • 演进方向
    • 解决无法紧急回滚的问题
    • 运行时权重自适应
  • 缺点
    • 过度流量倾斜可能会有异常情况

image.png

4. 自适应动态权重 Beta

  • 方案
    • 服务网络上报RPC指标
  • 演进方向
    • 极端场景的处理成为可能
  • 缺点
    • 时序数据库压力较大
    • 动态权重决策中心职责越来越多,迭代 -> 变更 -> 风险

image.png

5. 自适应动态权重 Release

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

image.png

参考

第五届字节跳动青训营学习资料
青训营知识讲解掘金课程
什么是PaaS

avatar
文章
阅读
粉丝