背景

service-centric architecture

以服务为中心的架构，和 SOA 的区别是？

服务治理的模式

server-side pattern：容易集中管控，易单点失败。
client-side pattern：不容易集中管控，不易单点失败。

演化流程

  • 基础治理能力：通信协议统一、命名服务的统一、监控预警、运营平台
  • 高性能/易用性：通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化
  • 全方位的治理能力：全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建
  • 业界前言探索：SET 化高扩展架构/云原生架构治理

治理体系

该有的治理能力都要有。

注册中心

  • 服务注册
  • 服务概要
  • 提供者
  • 消费者

监控报警

  • 节点监控
  • 性能监控
  • 业务监控
  • 异常监控

服务运营

  • 配置管理
  • 服务分组
  • 节点管理
  • 服务鉴权

数据分析

  • 性能指标
  • 来源去向
  • 主机分析
  • 数据报表
  • 调用链路

关键组件-本地代理

比如 LocalAgent，能够做到：策略下沉，解耦功能，对业务服务侵入性低。

但 Provider/Consumer 还需要使用自己的 sdk，它和远端的 naming service 服务，管理本地服务列表缓存、配置列表。

这样可以让通信简单化。

健康检查服务

Scanner 是专门的服务，负责检查和更新服务节点状态。这也可以有中心化和去中心化的设计。中心化的设计简单一点。

由健康检查服务可以实现平滑发布：

  • 先修改服务为不可用，kill 掉服务。
  • 发布成功，修改服务为启动中。
  • 然后进行健康检查。
  • 健康检查成功-服务修改为正常。
  • 逐步导入流量。

这种发布要近端和远端协同，涉及状态机涉及，在关闭流程中，先改服务治理远端状态，再处理本服务器问题；在启动流程中，先处理本服务器问题，再改服务治理远端状态。

Mesh 化

完全 sidecar 化的 agent，完全独立的 agent 进程，这样所有服务治理的功能都用治理流量的方式来做。之前的 agent 只治理服务治理流量，sidecar 化以后也治理业务流量。

SRE 可以自主升级。业务可以更加聚焦业务核心逻辑。

单元化/基础设施

set 只是逻辑机房（数据中心）的一种称呼。

使用 set（或者其他方式）可以实现全链路流量隔离。这种全链路流量隔离，可以提供：