什么是微服务 | 笔记

微服务架构介绍

系统架构演变历史

• 单体架构

  • 特点：把所有功能打包在一个项目中
  • 优势：性能最高，冗余小
  • 劣势：
    • debug难
    • 模块间相互影响（bug相互影响）
    • 模块分工、开发流程难以分配

• 垂直应用架构

  • 特点：按照业务线垂直划分
  • 优势：业务独立开发维护
  • 劣势：
    • 不同业务间存在冗余
    • 每个业务还是单体架构

• 分布式架构

  
  • 特点：抽出业务无关的公共模块
  • 优势：业务无关的独立服务层可以逻辑复用
  • 劣势：
    • 服务模块bug可导致全站瘫痪
    • 调用关系复杂
    • 不同服务冗余

• SOA架构

  
  • 特点：面向服务，有服务的核心思想
  • 优势：服务注册
  • 劣势：
    • 整个系统设计是中心化的
    • 需要从上至下设计
    • 重构困难

• 微服务架构

  
  • 特点：彻底的服务化，从下而上的业务独立的设计
  • 优势：
    • 开发效率高
    • 业务独立设计
    • 自下而上
    • 故障隔离
  • 劣势：
    • 治理、运维难
    • 观测难
    • 安全性
    • 分布式系统

演变原因

• 互联网的爆炸性发展
• 硬件设施的快速发展
• 需求复杂性的多样化
• 开发人员的急剧增加
• 计算机理论及技术的发展

微服务架构概览

• 网关：处理外界流量
• 服务配置和治理：针对服务的配置
• 链路追踪与监控：问题定位

微服务架构核心

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

微服务架构原理与特征

基本概念

• 服务（service）：一组具有相同逻辑的运行实体

  • 相同逻辑：代码是一样的
  • 运行实体：实例
  • 翻译：运行同一段代码的多个实例（如图）

• 实例（instance）：一个服务中，每个运行实体即为一个实例

• 集群（cluster）：通常指服务内部的逻辑划分，包含多个实例

• 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程（反之不常见）

• 常见的实例承载形式：进程、VM、k8s pod

• 有状态/无状态服务：服务的实例是否存储了可持久化的数据 (例如磁盘文件)

服务间通信

对于单体服务，不同模块通信只是简单的函数调用

对于微服务，服务间通信意味着网络传输

服务注册与发现

在代码层面，如何指定调用一个目标服务的地址(ip:port)?

• 不行的方案

  • hardcode：不行

    • 只能绑定一个地址，服务A拿服务B只有一个实例会收到请求
    • 服务地址会变化

  • DNS：问题很多

    • 本地DNS存在缓存，导致延时
    • 负载均衡问题
    • 不支持服务实例的探活检查
    • 域名无法配置端口

• 可行的方案=

  • 建一个统一的服务注册中心，用于存储服务名到服务实例的映射（即哈希表）

• 服务实例上线及下线问题

  

  • 管理员想要下线服务B的实例三

    0. 在服务注册中心将第三个实例的记录删掉（让服务A不会去调用服务B的实例三）
    1. 下线实例三（此时实例三没有流量，可以安全删除）

  • 管理员想要上线服务B的新实例

    0. 先在服务B中提起来新实例，随后进行此实例的健康检查
    1. 将实例注册到服务注册中心

流量走向

以流量的视角看微服务架构

• LoadBalance：负载均衡-网关

• 特点

  • 统一网关入口
  • 内网通信多采用RPC（性能高）
  • 内网调用链路

核心服务治理功能

服务发布

• 定义：让一个服务升级运行新代码的过程

• 难点

  • 服务不可用：服务升级的时候用不了
  • 服务抖动：实例升级时连接实例的流量会短暂的断开
  • 服务回滚：有bug，需要回滚

蓝绿部署

• 操作：将服务B分成蓝色部分和绿色部分，当要发布绿色部分时将绿色部分的流量切给蓝色部分，此时就可以将绿色部分更新，若没有问题将绿色部分的流量切回去。以同样步骤操作即可部署蓝色部分
• 优点：简单，稳定，回滚方便（只需要回滚一整个绿色部分）
• 缺点：一半的资源需要可以处理所有流量（需要在低峰期部署）

灰度发布（金丝雀发布）

• 操作：只放一部分新实例看看有没有问题，没问题再下线掉老代码
• 优点：简单，不需要两倍资源
• 缺点：需要进行精细化的流量控制，且回滚困难（需要一个个回滚）

流量治理

• 微服务下可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精细化的控制

• 如图例所示：

  • API gateway service：基于地区进行控制，60%进北京的服务
  • Service A：基于集群控制，10%进测试版本
  • Service B：根据机器进行流量划分，老机器处理的流量更少
  • Service C：测试功能的集群只有一个实例，常规的请求进正常的集群，内部用户(有测试资格的用户)可以将流量流入控制集群

负载均衡

• 负载均衡（Load Balance）：上游中的一个负载均衡组件（LB）负责分配请求在每个下游实例上的分布
• 常见的LB策略：Round Robin、Random、Ring Hash、Least Request

稳定性治理

• 为什么需要：线上服务总是会出问题的，这与程序的正确性无关
• 不可控的情况：网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调故障

微服务架构中典型的稳定性治理功能

• 限流：当服务A调用服务B且流量过大时，服务B的限制器（rate limit）组件回绝一部分请求
• 熔断：当服务A调用服务B连不上去时，服务A的熔断器（curcuit breaker）组件会停止连接服务B并回绝下游连接，并在服务B恢复期间间断尝试连接服务B，直到服务B恢复
• 过载保护：服务A调用服务B时，当服务B的 dynamic overload 组件发现自己CPU压力过大时回绝掉一部分或所有流量，让CPU压力下降
• 降级：当服务B高负载时，服务B的 degrade 组件识别出流量的优先级，回绝掉优先级低的流量