Willson Chen

Stay Hungry, Stay Foolish.

微服务基础

TTS

微服务

微服务架构特点

微服务是一种架构模式，将应用拆分成多个小型、自治的服务单元，每个服务单元可以独立部署、扩展和维护。

微服务与单体应用的区别：

单体应用 微服务
整体部署 拆分部署
紧耦合 松耦合
基于整个系统伸缩 基于服务伸缩
集中式管理 分布式管理
应用无依赖关系管理 微服务间较强的依赖关系管理
局部修改，整体更新 局部修改，局部更新
故障全局性 故障隔离、非全局
代码不易理解难维护 代码易于理解维护
开发效率低 开发效率高
资源利用率低 资源利用率高
重、慢 轻、快
部署简单 部署复杂

基本问题

分布式问题

微服务系统属于分布式系统，天然存在分布式问题。
CAP 定律：

  • Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）
  • CAP 三种特性无法兼得，只能取其二。
  • 要保证一致性和可用性，则不能保证分区容错性，即必须保证网络的可靠性不允许出现分区。
  • 事实是网络是不可靠的，分区容错性是必须的。
  • 所以只能在一致性和可用性之间做选择。

组织架构问题

康威定律：组织架构天然地决定了系统架构，即组织的划分和沟通关系决定了系统的划分和接口设计。
这种异质同态的潜在关系决定了，不能单方面地对系统进行微服务拆分，而应该有匹配的研发团队拆分和人员规模。

服务拆分

拆分的原则

  • 单一职责原则，多个独立且相关性不大的功能之间意味着可以拆分。
  • 高内聚低耦合原则，相关性大的功能最好放在一个服务内，避免服务间交互过于复杂。
  • 演进式拆分，粒度从粗到细，随着业务的深化和规模的扩张演进式拆分。
  • 避免循环依赖和双向依赖，服务关系过于复杂，理解困难、容易产生死锁。

拆分的方法

  • 按业务领域拆分，良好的业务领域划分往往具备单一职责和高内聚原则。
  • 业务对象的交互是强一致性的最好不拆分，支持最终一致性的才拆分。
  • 按性能拆分，将流量大的服务拆分出来便于扩容，避免对其他服务产生影响。
  • 按业务重要度拆分，重要程度高的业务确保更高可用性。
  • 按组织架构和团队规模拆分，避免粒度过细。

通信方式

通信模式

  • 同步
    • 请求方需等待响应方返回结果后才继续。
    • 优点：可靠性较高，容易保证顺序性。
    • 缺点：请求排队，线程阻塞，影响并发性能。
  • 异步
    • 请求方发送请求后继续执行，不等待响应方返回结果。
    • 优点：提高并发吞吐，耦合度低，故障隔离。
    • 缺点：调用流程复杂。
  • 发布-订阅
    • 一对多的通信模式，发布方发出消息后，可能被一个或多个订阅方处理。
    • 优点：耦合度极低，高可扩展性和灵活性。
    • 缺点：只适用于特定场景，发布方不关心有多少订阅方，不关心消息的处理结果。

接口协议

  • RESTful
    • 是一种基于 HTTP 协议的接口风格。
    • 将接口抽象为对资源的CURD。
    • 区别于普通的 HTTP 接口，在 URL 和 HTTP Method 上有特定的风格。
    • 常用于前后端之间的接口。
    • 比普通 HTTP 接口可读性更高。
  • RPC
    • RPC 是远程过程调用，目的是将网络通信简化为本地函数调用。
    • 常用的 RPC 框架如 gRPC，Thrift。
    • 基于 TCP 或 HTTP 协议。
    • 分为请求响应式 RPC 和流式 RPC。
  • 消息队列
    • 用于实现异步通信的中间件。
    • 常用的消息队列如 Kafka，RabbitMQ。
    • 基于 TCP 协议。
    • 分为点对点式队列和发布-订阅式队列。

按应用场景选择：

  • 低延迟：RPC
  • 强一致性：RPC实现TCC模式接口
  • 最终一致性：高可靠性的消息队列如 Rabbitmq
  • 大规模数据流处理：高吞吐消息队列如 kafka
  • 一对多通信：发布订阅式消息队列
  • 对接外部：标准协议，RESTful 或 gRPC
  • 前后端接口：RESTful

服务编排

Orchestration（编制）

  • 采用中心化控制方式，有一个流程控制服务（或编排引擎）负责协调各服务的执行流程。
  • 类比于管弦乐，有一个中心指挥手。
  • 优点：流程清晰，易于理解和监控。
  • 缺点：中心化容易变得臃肿复杂，难以维护。

Choreography（编排）

  • 采用去中心化的方式，每个服务自主控制，通过消息与其他服务协作形成业务流程。
  • 类比于编舞/爵士乐，没有中心化指挥家，每个舞手/乐手各司其职。
  • 优点：耦合度低，不存在复杂度高的中心化服务。
  • 缺点：流程不清晰，难以理解和监控。

服务治理

服务发现

  • 定义：自动注册和发现服务的技术。
  • 作用：
    • 使服务在运行时能动态发现依赖的其他服务并建立通信。
    • 由于服务实例的IP是动态变化的，故服务发现是必备的技术。
  • 实现：
    • 通过分布式键值对存储系统实现，如ETCD、ZK。
    • 服务启动时向注册中心注册，服务停止时从注册中心注销，客户端通过订阅服务列表获取服务实例信息。

统一配置管理

  • 定义：将配置信息集中存储和管理的技术。
  • 作用：解决服务发现，数据库、缓存、消息队列等配置信息管理问题。
  • 实现：
    • 通过分布式键值对存储系统实现，如ETCD、ZK。
    • 需支持不同环境的配置信息切换。

可观测性

  • 定义：通过日志、监控指标、链路追踪、告警等手段，对系统运行状态进行观测的技术。
  • 作用：加速故障的排查和修复，发现并优化性能瓶颈，辅助容量规划等。
  • 实现：
    • 监控工具：如Prometheus、Grafana等，可以用来收集和可视化微服务的性能指标。
    • 分布式追踪：如OpenTracing、Jaeger等，可以用来追踪微服务间的请求流转路径。
    • 日志记录：如ELK，可以用来收集和检索微服务的日志。
    • 云原生：CNCF标准化项目 OpenTelemetry。