微服务架构简介

系统架构演变历史

• 单体架构
  • all in one process
  • 优势：
    1. 性能最高
    2. 冗余小
  • 劣势：
    1. debug困难
    2. 模块相互影响
    3. 模块分工、开发流程
• 垂直应用架构
  • 按照业务线垂直划分
  • 优势：
    1. 业务独立开发维护
  • 劣势：
    1. 不同业务存在冗余
    2. 每个业务还是单体
• 分布式架构
  • 抽出业务无关的公共模块
  • 优势：
    1. 业务无关的独立服务
  • 劣势：
    1. 服务模块bug可导致全站瘫痪
    2. 调用关系复杂
    3. 不同服务冗余
• SOA架构(Service Oriented Architecture)
  • 面向服务
  • 优势：
    1. 服务注册
  • 劣势：
    1. 整个系统设计是中心化的
    2. 需要从上至下设计
    3. 重构困难
• 微服务架构
  • 彻底的服务化
  • 优势：
    1. 开发效率
    2. 业务独立设计
    3. 自下而上
    4. 故障隔离
  • 劣势
    1. 治理、运维难度
    2. 观测挑战
    3. 安全性
    4. 分布式系统

核心要素

• 服务治理
  • 服务注册
  • 服务发现
  • 负载均衡
  • 扩缩容
  • 流量治理
  • 稳定性治理
  • ...
• 可观测性
  • 日志采集
  • 日志分析
  • 监控打点
  • 监控大盘
  • 异常报警
  • 链路追踪
  • ...
• 安全
  • 身份验证
  • 认证授权
  • 访问令牌
  • 审计
  • 传输加密
  • 黑产攻击

微服务架构原理及特征

基本概念

• 服务(service)：一组具有相同逻辑的运行实体。
• 实例(instance)：一个服务中，每个运行实体即为一个实例。
• 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程（反之不常见）
• 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例。
• 常见的实例承载形式：进程、VM、k8s pod .......
• 有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如磁盘文件）
• 服务间通信
  • 对于单体服务，不同模块通信只是简单的函数调用。
  • 对于微服务，服务间通信意味着网络传输。

服务注册及发现

• 在代码层面，如何指定调用一个目标服务的地址(ip:port)?
  • 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。

流量特征

• 统一网关入口
• 内网通信多数采用RPC
• 网状调用链路

核心服务治理功能

服务发布

指让一个服务升级运行新的代码的过程。

• 难点：
  • 服务不可用
  • 服务抖动
  • 服务回滚
• 蓝绿部署
  • 简单，稳定但需要两倍资源
• 灰度发布（金丝雀发布）

流量治理（流量控制）

稳定性治理

限流、熔断、过载保护、降级