这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记
GO-学习笔记
什么是架构
- 软件整体结构和组件的抽象描述，指导软件系统的各方面设计
架构分类
- 单机架构，所有的功能都实现在一个进程里，部署在一台机器上
- 运维需要停服
- C10K problem
- 单体架构，分布式部署
- 垂直应用架构，按照应用功能区分单体
- 职责太多，效率不高
- 垂直架构，根据业务进行拆分
- 业务独立开发维护
- 不同业务存在冗余
- 分布式架构，抽出业务无关的公共模块
- 业务无关的独立服务
- 调用关系负责，不同服务冗余
- SOA，Service-Oriented Architecture，水平切分，面向服务
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准，通过服务注册进行管理
- 微服务架构，SOA的去中心化演进方向
- 维护成本，数据一致性，链路稳定，故障容灾
- 微服务架构，彻底服务化
- 业务独立开发，自下而上，故障隔离
- 治理、观测、安全有难度
企业架构
云计算
- 通过软件自动化管理，提供计算资源的服务网络
- 虚拟化技术，拥有整个服务器的资源/拥有一个服务器的部分资源
- 编排方案，自行安排整个资源的分配/划分一块容器空间进行资源分配
- 架构
- IaaS Infrastructure as a Service，不需要管理物理资源
- Paas Platform as a Service，不需要管理系统基础设置
- Saas Software as a Service，不需要自己写服务功能
- FaaS Function as a Service，不需要自己写完整的系统
云原生
- 在公有云，自由云，混合云等新型动态环境中，构建和运行科弹性拓展的应用
- 弹性资源
- 虚拟化容器，快速扩缩容
- 服务资源（微服务/大服务）、计算资源（在线/离线）、消息队列（在线/离线，解耦消费者和生产者）
- 将存储资源当成服务一样，经典存储（对象/大数据），关系型数据库，元数据（服务发现），实时缓存数据
- 微服务架构
- 业务单元解耦
- 统一的通信标准，HTTP(RESTful API)/RPC(Thrift/gRPC)
- 不需要关注通信标准
- DevOps，开发和运维
- 敏捷开发
- CI/CD，Continuous Integration/Continuous Delivery/Deployment，持续开发/持续交付和部署
- 贯穿软件开发周期，自动化开发和交付
- 服务网格，中心化控制面，可以感知服务的具体情况
- 业务与治理解耦，与调用通信解耦
- 异构系统的治理统一化，不同语言实现的系统的统一治理
- 复杂治理能力
企业架构挑战
- 基础设置层面，物理资源有限（机器、带宽），利用率受制于部署服务的个数
虚拟化后，物理机利用率较低
- 用户层面，网络通信开销加大；网络抖动导致运维成本提高；异构环境下，不同机器处理能力不同，相同服务，CPU使用率不同
资源利用率
- 降低物力资源成本，提供更多弹性资源
离在线资源并池，离线服务和在线服务用统一的资源，根据处理量和时间进行调度
- 在线业务，IO密集型、潮汐性、实时性
- 离线业务，计算密集型，非实时性
- 同一台机器实现离在线的隔离
cgroup，隔离CPU核心，使用不同个数的CPU，资源分块
自动扩缩容
- 降低业务成本
- 利用在线业务潮汐性自动扩缩容
根据业务调用频率的时间性，进行资源调配
- 扩缩容的指标
- 根据服务的CPU使用量，P50，达到CPU百分之50的使用率
- 内存利用率
微服务亲合性部署
- 针对两个耦合性高的服务，降低业务成本，提高服务可用性
- 将满足亲合性条件的容器调度到一台宿主机上
- 微服务中间件与服务网格通过共享内存通信
- 服务网格控制面实施灵活，动态的流量调度
流量治理
- 提高微服务调用容错性，提高开发效率
- 基于微服务的中间件和服务网格的流量治理
CPU水位负载均衡
- 打平异构环境算力差异，为自动扩缩容提供正向输入
- IaaS，提供资源探针，监控容器资源使用情况
- 服务网络，实现动态负载均衡，最大化不同容器的相同服务的利用率
- 支持带权重的负载均衡策略
- 注册中心存储所有绒的权重信息
- 宿主机提供容器的资源使用情况和物理资源信息
- 紧急回滚、大规模、极端
- 自适应静态权重
- 采集宿主机物理资源信息，调整容器主机的权重，每个宿主机包含一个调权代理
- 复杂度低，集成在宿主机上，无适配成本
- 无紧急回滚能力，缺乏自适应
- 自适应动态权重
- 配置动态权重决策中心，集成服务网格的服务发现和流量调度，获取相应服务信息，存在过度流量倾斜
- 服务网格上报RPC指标，通过RPC指标进行调度，避免极端场景，时序数据库存储RPC指标，压力较大，动态权重决策中心职责越来越大
- 动态权重决策中心微服务化，引入消息队列削峰、解耦；离在线链路切分；
微服务
- 核心要素
- 服务治理
- 可观测性
- 安全
基本概念
- 服务，一组具有相同逻辑的运行实体，一个服务有多个实例
- 实例，一个服务中，每个运行实体即为一个实例
- 实例与进程，实例可以对应一个或多个进程
- 集群，服务内部的逻辑划分，包含多个实例
- 有状态/无状态服务，服务的实例是否存储了可持久化的数据
- 服务间通信，对于微服务，意味着网络传输
- HTTP
- Thrift
- gRPC
- 服务注册中心，用于存储服务名到服务实例的映射
- 流量特征，用户通过HTTP访问服务路由，内部服务通过RPC互相调用
服务治理
- 发布，让一个服务升级运行新的代码的过程
- 服务不可用，上线新服务，避免停止旧服务
- 服务抖动，避免上线过程中影响使用
- 服务回滚，上线完有bug
- 流量治理，基于地区、集群、实例、请求等维度的精细化控制
- 负载均衡，将请求量均匀分配给服务的各个实例
- 稳定性治理，线上服务总会出问题
- 网络攻击、流量突增、机房断电...
- 限流、熔断、过载保护、降级
请求重试案例
- 远程调用，需要请求重试，提高SLA，Service-Level Agreement
- 网络抖动
- 下游负载高、机器宕机、熔断、限流
- 请求重试的优点
- 降低错误流
- 降低长尾延时，可能是网络问题导致的长尾请求
- 容忍暂时性错误，忽略网络抖动
- 避开下游故障实例
- 默认不用重试
- 操作幂等性
- 重试风暴，导致雪崩，微服务调用链路很深，每一级都存在重试，到最后一个服务的请求数非常多
- 超时设置
- 重试策略
- 限制重试比例，设置比例阈值，重试次数占所有成功的请求比例不超过该阈值
- 防止链路重试，只有最下一层发生重试
- Hedged requests，对冲请求，对可能超时的请求，重新进行请求
