笔记首页

# 1 什么时候需要拆分

# 1.1 一体化架构

  1. 优点
    • 开发简单直接，代码、项目集中化管理
    • 维护少，只需要维护一个项目，节省人力成本
    • 排查问题简单
  2. 缺点
    • 技术：数据库连接数瓶颈
    • 增加了研发成本，抑制研发效率提升
      • 代码维护，配合不容易
      • 功能耦合，重复造轮子
    • 部署成本：系统运维，构建时间，频繁上线等

# 1.2 微服务

  1. 独立服务：按照业务横向拆分，解决数据库层面扩展性
  2. 公共服务：公用服务抽取，下沉单独的服务

单一服务功能内聚，职责明确，熔断、降级等减少影响；构建速度提升；

# 1.3 微服务拆分原则

  1. 单一服务高内聚，低耦合
  2. 拆分粒度，先粗略拆分，再细化
  3. 避免影响日常迭代
    • 先拆比较独立的服务，减少业务影响
    • 先被依赖的服务（理清服务间调用关系）
  4. 接口可扩展

# 1.4 微服务问题

  1. 响应时间
  2. 依赖关系：故障蔓延（服务治理，限制问题范围)
  3. 排查问题难（分布式追踪）

监控报表：依赖服务、资源宏观性能表现

分布工追踪：单一慢请求性能瓶颈分析

# 2 RPC

# 2.1 高效通信

  1. 合适的网络模型
    • 阻塞、非阻塞；同步、异步
    • 多路IO复用
  2. 网络参数调优，tcp_nodelay（拒绝包合并，减少响应时间）
  3. 合适的序列化方式

# 2.2 服务发现

# 2.2.1 注册中心

  1. 服务地址存储
  2. 变化时通知客户端
  3. 优雅关闭，紧急扩容

# 2.2.2 服务状态管理

  1. 主动探测
  2. 心跳模式

# 2.2.3 问题

  1. 注册中心需要添加保持机制
  2. 通知风暴
    • 控制集群规模
    • 扩容注册中心节点
    • 规范注册中心使用，仅通知变更
    • 保护策略，控制消息量

# 2.2.4 重点

  1. 注册中心动态地RPC服务节点信息，对于扩容缩容，故障恢复，优雅关闭有重要意义
  2. 心跳机制是常见探测服务状态的方式
  3. 保护策略不可少，避免过度摘除

# 2.3 慢请求排查

# 一体化服务

# 微服务

  1. 静态代理
  2. 请求采样
  3. 分布式Trace

# 分布式Trace

  1. traceId：串起单次请求
  2. spanId：记录每一次RPC调用
# 注意
  1. 提供开关，随时关闭日志
  2. 采样率，先低，观察性能，再调到一个合适的数值
  3. 侵入低

# 2.4 负载均衡

提升系统的横向扩展能力

# 类型

  1. 静态策略
    • 轮询
    • 带权重
  2. 动态策略
    • 连接数最小
    • 根据响应时间动态计算权重

# 如何检测节点是否有故障

  1. Nginx_upstream_check_module：接口探测

# 3 API网关

# 3.1 分类

  1. 入口网关
    • 统一接入地址，协议转换
    • 服务治理策略
    • 认证授权的实现
    • 黑白名单
    • 日志记录
  2. 出口网关
    • 对外统一做认证、授权、审计、访问控制

# 3.2 如何设计

  1. 性能
    • 网络IO模型：IO多路复用
  2. 扩展性
    • 随时增加逻辑或下掉逻辑（责任链模式工）
  3. 提升网关并行处理能力
    • 线程池隔离
    • 线程配额

# 3.3 如何数据聚合操作

  1. 流量网关+业务网关
  2. 抽取服务层，做接口聚合（原子服务层，聚合服务层）

接口聚合业务的操作，更适合采用2方式，放在更近业务的服务层来做

# 4 多机房部署

# 4.1 难点

  1. 避免跨机房访问的性能问题

    • 同城 1~3ms

    • 异地 < 50ms

    • 跨国 100~200ms

# 4.2 方案

逐步迭代多机房部署方案

  • 同城双活
    • 主从分离的情况下，主库可做写，从库进行读，延迟问题通过缓存解决
    • 注册中心可以部署在单机房
  • 异地多活
    • 基于存储系统的主从复制
    • 基于消息队列
    • 基于用户属性分片，如ID，地域
    • 尽量避免跨异地远程访问，保证异地都有对方所有的东西
    • 数据异地需要同步

# Server Mash

# 微服务化过程通信与服务治理

  1. 通信：RPC框架
  2. 注册、发现：注册中心
  3. 排查调用慢：分布式Trace中间件
  4. 扩展性：负载均衡器
  5. 服务治理：熔断、降级、流控在API网关

# 挑战：

  1. 跨语言带来的挑战
    • 通信协议多语言友好：序列化方式
    • 服务治理策略无法使用积累的策略
    • 注册中心访问压力，多级缓存策略保证可用性
    • 负载均衡、熔断降级、流量控制、分布式追踪日志等，都要重新实现
  2. 如何解决
    • 服务治理细节，从RPC客户端中拆分出来，形成专门的层单独部署（关注点分离）
    • Service Mesh的核心思想

# What

# 定义：

主要处理服务之间的通信，它的主要实现形式就是在应用程序和主机上部署一个代理程序，Sidecar，服务之间的通信由原来客户端与服务端直接通信改为RPC客户端把数据先发给自身主机部署的Sidecar，在其中经过服务发现、负载均衡、服务路由、流量控制之后，经过记录访问日志、记录分布式追踪日志、限流之后，再将数据发送给RPC服务端。

# 好处

  1. 业务代码与服务治理策略隔离，服务治理策略下沉，成为独立的基础模块
  2. 跨语言，服务治理策略的自用
  3. 对Sidecar做统一管理

SideCar

  1. 数据平面

    • Sidecar：Envoy

  2. 控制平面

    • Mixer
    • Pilot
    • Istio-auth

数据转发：iptables透明流量转发

  • PreRouting：数据包入口
    • ->rerouting->istio_inbound-9080->istio_in_redirect->sidecar端口
  • OutPut：目的地为本机时，会流经链
    • ->output->istio_output->非sidercar流量->istio_redirect->sidercar端口
  • 特点：
    • 业务透明
    • 高并发下性能有损耗

  1. 轻量级客户端
上次更新: : 7 months ago

← 监控如何做 →