碎片式的技术笔记

2021-09-24 11:16:52 浏览数 (1)
异地多活

定义：广域的分布式架构；

目的：容量扩展，资源弹性；

实质：多个不同地域不同规模的数据中心；

收益：更强的容灾能力，用户就近接入能力；

容器集群

特点：开箱即用；

优点：从多业务复杂性→生产多样性；

管理：服务标识&版本标记，便于集群管理；

原理：基础镜像配置多个服务节点，可通过预分发方式达到热启动；

弹性调度
  1. 扩容
    1. 垂直扩容：选择合适的机器；
      1. CPU繁忙程度
      2. 网络流量情况
      3. 内存容量情况
      4. 单节点实例数量
    2. 水平扩容：
  2. 缩容：实例迁移合并，避免资源散碎；
  3. 注意事项
    1. 控制每台物理机上最大可部署实例数；
    2. 高性能&核心业务集群，单台物理机实例数＜逻辑CPU数量；
    3. 非核心业务集群，单台物理机实例数可以＞逻辑CPU数量；
监控体系

作用：指标监控、数据展示、告警订阅通知；

支撑：为性能测试&性能优化场景提供数据支撑和问题定位能力；

特性：实时监控、可视化、统计报表、长期存储及复盘支撑能力；

CICD三部曲
  1. 自动化执行（提交&检查&编译&打包&测试&部署&运营）
  2. 一切皆服务；
  3. 一切皆资源；
服务框架选型
  1. I/O模型
  2. 代码规范
  3. 通信协议
  4. 负载均衡
  5. 序列化协议
  6. 开源框架对比
分布式架构改造

目的：让系统无状态化/有状态的信息封装在一定范围内，避免影响系统水平扩展；

前提条件：

  • 应用微服务化；
  • 分布式服务框架：服务注册&发现&管理 RPC框架 消息队列 分布式数据库/文件系统
  • 分布式session：可以通过Redis或者分布式ID等服务来解决；

什么是去IOE？

  • IBM小型机：分布式缓存；
  • Oracle数据库：MySQL&PGSQL&NOSQL&TSDB；
    • 业务数据：线上业务热数据→关系型数据库（事务）
    • 非业务数据：监控&离线计算&非实时性数据
  • EMS高端存储：分布式文件系统→HBASE、Spark等

解决了什么问题？

  • 水平扩展：应用层、容量规划
  • 垂直扩展：按业务域做垂直拆分（避免业务扩展带来的逻辑复杂度提升）
  • 按照业务类型或者功能做划分
    • 应用：展示层，webview等，只做数据展示和渲染；
    • 服务：按照业务类型和逻辑划分处理，类似DDD模型；
    • 数据：按照业务域做垂直拆分，分库分表拆实例；

常见的架构类型

  • 主从模式：master-slave，可用性较高；
  • 选举机制：leader选举机制，维护机制比较复杂；

配置中心运行模式

  • 常见的配置中心组建：Apollo、Nacos
  • config推送：主动推送最新配置数据到client（低时延，适合数据量较小的情况）
  • config拉取：client定时拉取最新的配置数据（复杂，管理client状态/心跳，延时较高，无法及时通知，适合数据量大的情况）
  • 优化思路：通过配置信息版本号，比对决策是否需要更新（更新需要proxy）
分布式消息框架

消息类型

  • 实时消息：MQ、kafka
  • 延时消息：可以理解为Job调度任务
  • 作用：应用间的消息传递

实时消息

  • 异步解耦
    • 降低系统耦合；
    • 区分调用与被调用者的处理逻辑；
    • 解决不同系统之间语言&数据结构&速率差异（削峰填谷）
  • 注意事项
    • 最终一致性：消息最终可达/不可达反馈（订阅&投递&确认&回执）；
    • 消息有序性：接收发送消息时间的先后顺序；
  • 典型问题
    • 消息是否被消费？
    • 成功/失败（重试机制）
    • 增长消费状态标识（ACK，失败放单独队列，重试）
    • 容错处理
    • 失败/异常重试；
    • 消息持久化存储；
分布式数据分层

解决了什么问题？

  • 分库分表：数据水平切割，通过sharding路由规则访问；
  • 主备切换：一主多备高可用架构，数据写主库读从库；
  • 读写分离：需要注意数据一致性问题以及数据同步延时问题；
应用服务化改造
  1. 分层设计
    1. 对DB访问层统一抽象封装，形成数据访问层（DAL），降低重构和DB拆分难度；
    2. 垂直划分
    3. 服务层：web（webview）和app（application）
    4. 业务逻辑层
    5. 数据层
    6. 说明：上层依赖下层，下层不依赖上层；
  2. 分层判断原则
    1. 层级职责是否清晰
    2. 层级设计收敛（不同层的修改是否会影响其他层级）
    3. 尽量使用源生数据类型·
  3. 微服务化改造
    1. 水平划分、服务颗粒度细化为单一的功能单元（DDD领域驱动设计）
    2. 优点是提升系统可维护性（模块化）、扩展性（水平扩容）和研发效率；
    3. 拆分时需要注意，独立&重要&稳定的业务服务做拆分，避免高频业务更新影响全局；
服务调度与负载均衡

服务调度：摘除故障节点，更新可用服务的地址列表

负载均衡：随机分配&权重选取

服务发现：服务与提供服务的机器解耦

服务注册：传递类名、方法名、参数类型、版本号

统一SDK：封装统一的client/server标准接口规范(协议(http/TCP)&失败重试机制&参数传递规范)

分布式 微服务 负载均衡 负载均衡缓存

0 人点赞