Skip to content
当前页

微服务治理

概览

所属模块:微服务

适用对象:当前项目的所有用户

具体操作:登录微服务治理系统→进入微服务模块

查看服务统计

进入微服务模块,默认打开概览页。

概览页会显示当前项目、所在环境下的服务数和实例数统计。

查看调用统计

查看请求监控,包含 QPS、失败率、平均时延、P50 时延、P90时延、P99时延。通过在右上角选择日期,可以查看历史的统计。

查看 TOP 5 服务的QPS、失败率、平均时延、P50 时延、P90时延、P99时延。通过在右上角选择日期,可以查看历史的统计。

服务拓扑

所属模块:微服务

适用对象:当前项目的所有用户

功能描述:展示当前项目下以服务为中心的调用拓扑关系,可以通过拓扑节点快速查看某个服务的监控信息和治理信息,并可以快速跳转到某个服务操作页。

具体操作:登录微服务治理系统→进入微服务模块→服务拓扑

如图中所示,每个节点表示一个服务。节点间的连线表示服务之间的依赖关系,流量流向被调用方。连线上的数据分别表示 QPS、请求错误率。

选中某个节点,可以在右侧看到该服务的更多信息,并支持跳转到服务管理页面进行治理。

服务管理

所属模块:服务管理

适用对象:当前项目的所有用户

功能描述:管理当前项目在所选环境下的已发布服务。支持 HTTP、Dubbo2种协议服务统一视图管理。

具体操作:登录微服务治理系统→进入微服务模块→服务管理

概览

  1. 服务基本信息

    选中一个服务后,可以查看该服务的基本信息,包含:服务名称、负责人、创建时间、描述。

  2. 服务上下线

    点击“下线”操作,会在当前环境中移除该服务,不会影响该服务实例的运行,但相关微服务模块管理功能将对该服务的服务实例失效。可以通过上线重新恢复。

  3. 服务搜索

    可通过输入服务名,从服务管理中过滤出相应的服务。支持服务名的模糊匹配。

  4. 区域优先路由

    如需使用区域优先路由。接入时需为服务实例打上区域标签;标签 key

    为zone;选择开启区域优先路由功能。在路由时,将优先路由到同区域的提供者实例。

  5. 访问权限

    如需进行访问鉴权,可以打开访问权限开关。关闭时,所有请求均允许访问该服务。开启后,默认服务的所有接口都不允许访问。需要通过配置并启用接口鉴权规则,允许消费方访问。支持配置指定接口鉴权或所有接口鉴权。指定接口鉴权规则将覆盖所有接口鉴权规则生效。所有接口鉴权规则创建后,默认启用。

  6. 注销

    如果服务不再通过微服务进行管理,需要在当前环境删除。通过更多- 注销操作,注销服务在当前环境的发布信息。同时,服务的元数据不会删除, 仍可以通过知识库继续管理。

  7. 服务依赖

    展示所选服务的上下游调用拓扑。

监控

监控图分为两类:

  1. 聚合监控

    可以从服务、服务实例、服务版本、标签四个聚合维度进行筛选,提供最近一小时的数据曲线;监控指标包括:调用数、失败率、调用成功数、调用失败数,QPS限流、Thread限流数、超时次数,熔断数,平均时延、中位数时延、P90时延、P99时延、P995时延,点击相应监控指标即可得到相应指标的实时监控。

  2. 实时监控

    可以从服务、实例维度、服务版本、标签四个聚合维度、方法名的过滤。支持对调用频率、平均时延、失败率排序,指标具体包括:调用频率、平均时延、失败率、平均吞吐量、总吞吐量、熔断状态、实例数、90th时延、中位数时延、99th时延、99.5th时延。

前置条件:

实时方法级监控数据是基于治理方法进行采集的。需要在接入时,指定了平台可扫描的方法范围。生成Agent 配置文件时,选择高级配置 > 治理范围,指定工程项目下的 Package,Package尽量精确,严禁配置com.,参考:com.chinapost.provider.controller.

服务实例

所属模块:服务管理

适用对象:当前项目的所有人员

功能描述:包括当前服务的服务实例列表

具体操作:登录微服务治理系统→进入微服务模块→单击服务实例

服务实例列表包含:实例名、IP地址、版本号、区域、标签、状态、接入时间等。支持应用诊断操作,点击应用诊断,将启动Arthas,具体诊断方式参考https://arthas.aliyun.com/doc/arthas-tutorials.html,在诊断结束时及时使用 shutdown 命令来关闭,减少 arthas 对运行中的程序的影响。点击异常信息,可查看该实例相关的异常信息(如有);点击服务配置即可查看该实例接入治理平台的相关配置信息

服务治理

所属模块:服务管理

适用对象:当前项目的所有人员

功能描述:配置所选服务的治理规则,支持针对不同协议分别配置治理规则。

具体操作:登录微服务治理系统→进入微服务模块→服务管理→单击某个服务→单击HTTP治理

限流

对请求进⾏流控,防⽌请求激增导致服务提供方资源被过多消耗。

支持方法级别限流,根据 QPS (Queries Per Second,即查询量/秒) 、Thread设置限流阈值。

前置条件:

1.需要在服务的 Agent 配置文件中指定工程项目下的 Package,平台会自动获取 Package 下所有的方法列表。通过快速接入 > 生成配置文件 > Package 指定。

  1. 点击创建限流规则,填写参数。

    参数说明
    规则名称治理规则名称。
    规则范围选择当前治理规则所生效的服务版本、类、方法。
    限流维度可针对两种维度进行限流,QPS 或 Thread。
    阈值当限流维度选择QPS 或Thread时,需要填写相应的阈值;当限流维度为QPS,阈值表示请求数,一旦目标限流方法的被调用次数达到该阈值,即触发限流规则;当选择Thread时,阈值表示并发线程数量。
    缓冲区大小达到限流阈值时,保留一个缓冲区。
    等待时间缓冲区的请求超过等待时间未被处理,按限流处理方式返回。
    阻断返回触发治理规则后,支持不同处理方式。返回异常、返回固定值、Fallback方法(调用用户自定义 Fallback 方法)。

  2. 创建完成后,治理规则默认是停用状态。可以手动设置停用或启用;停用时规则不生效。

  3. 支持对规则中范围、阈值、缓冲区大小、等待时间,阻断返回的修改/规则的删除。

熔断

服务提供方因为某种原因导致服务不可用或响应过慢时,调用方服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回。当目标服务恢复后,调用方服务会恢复调用。

支持对方法配置熔断,当方法的调用达到熔断阈值时,将触发熔断。触发熔断后,可以返回异常、固定返回值、或者调用 Fallback 方法。

前置条件

1.需要在服务的 Agent 配置文件中指定工程项目下的 Package,平台会自动获取 Package 下所有的方法列表。通过快速接入 > 生成配置文件 > Package 指定。

参数说明
规则名称治理规则名称。
规则范围选择当前治理规则所生效的服务版本、类、方法。
熔断方式分为手工熔断和自动熔断。
熔断最小调用当在指定的时间区间内,请求数量达到最小调用次数,才会进行熔断判断。
超时阈值当请求响应时间超出该阈值,则计入熔断错误数统计。
错误率超过超时阈值和异常都认为是调用错误,当统计窗口内,错误调用除以总调用数大于错误率时,将触发熔断。
熔断恢复窗口熔断发生后,经过该窗口期,会进行恢复尝试。
阻断返回触发熔断规则后,支持不同处理方式。返回异常、返回值、Fallback方法(调用用户自定义 Fallback 方法)。
  1. 点击创建熔断规则,填写参数。

  2. 创建完成后,治理规则默认是停用状态。可以手动设置停用或启用;停用时规则不生效。

  3. 支持对规则中的规则范围、熔断试、熔断最小调用、超时阈值、熔断万利窗口、阻断返回等的修改/熔断规则的删除。

容错

为了保护服务消费方,调用外部服务失败后,进行错误重试处理。支持指定同实例、不同实例重试次数。

前置条件

1.如果需要对指定版本的消费方实例配置容错,实例接入时需要在Agent 配置文件中指定版本。

2.HTTP 容错触发条件:

Spring Boot 1.x: 500,502,503,504 14

Spring Boot 2.x: 500,502,503,504,408,429

  1. 点击创建容错规则,填写参数。

    参数说明
    规则名称治理规则名称。
    当前服务某个消费方服务。
    服务版本选择当前治理规则所生效的服务版本。
    容错范围选择容错规则针对的提供方服务。支持全部。
    接口提供方服务的某个接口
    容错方式Failover:在不同提供方服务实例上重新尝试建立连接;需设置新实例重试次数。 Failfast:不再重新尝试建立连接,即请求失败时会立即返回失败结果。 Failback:在同一个提供方实例上重新尝试建立连接;需设置同实例重试次数。 自定义:在同一个提供方实例上重新尝试建立连接。失败后,尝试在不同提供方服务实例上重新尝试建立连接。
    同实例重试次数在同一个提供方服务实例进行重试的次数。
    新实例重试次数在不同提供方服务实例进行重试的次数。

  2. 创建完成后,治理规则默认是停用状态。可以手动设置停用或启用;停用时规则不生效。

  3. 支持对规则中的接口、容错方式、同实例重试次数,切换实例次数的修改/容错规则删除。

路由

将特定请求路由到特定目标端实例,如灰度或者蓝绿等场景下。支持参数、指定权重分流。支持黑白名单、负载均衡。

前置条件

1.如果需要按照版本或标签进行路由,实例接入时需要在 Agent 配置文件中指定版本或者标签。

  1. 点击创建路由规则,填写基础配置。

    参数说明
    规则名称治理规则名称。
    服务版本选择消费方服务及版本。
    提供端服务选择提供方服务名称。
    描述添加描述。

  2. 填写黑白名单配置。选择消费端流量,根据白名单或黑名单策略允许/拒绝对提供端的访问。未匹配的消费端流量,不受此规则约束。

    参数说明
    黑白名单只有开启情况下,才可以进行规则设置;默认不开启。
    类型可选择不同的策略:白名单或黑名单。
    消费端过滤指定规则生效的消费端匹配条件
    提供端过滤指定规则生效的提供端匹配套件

  3. 填写分流配置,指定消费方与提供方之间的分流规则。如果请求的参数 符合分流规则,则将请求流入指定的分流目标实例;相反,不符合分流规则的 请求会流入分流目标实例之外的其他实例。权重分流不需要进行参数判断,直接为不同的提供方版本设置权重。

    参数说明
    分流状态只有开启情况下,才可以进行规则设置;默认不开启。
    分流类型参数取模、名单分流、权重分流。
    分流条件参数取模:将参数值对 100 取模,如果小于取模阈值,则符合分流规则;不符合条件的流量依照负载均衡规则进行路由。可选择不同类型的参数,包括 cookie、HTTP header 或者query string,参数在 url 中携带。 名单分流:用户提供一份参数的取值白名单,只要匹配到名单,则符合分流规则;不符合条件的流量依照负载均衡规则进行路由。 权重分流无需指定分流条件。
    分流目标通过服务版本或标签来指定提供方实例作为分流目标。

  4. 负载均衡。选择不同的均衡策略。

    参数说明
    均衡策略轮询:以轮询的方式选择服务器。
    随机:随机从服务器列表中选择一个进行访问。
    最大可用:先过滤出故障服务器后,选择一个当前并发请求数最小的。
    响应时间加权:根据平均响应时间计算所有服务的权重, 响应时间越快的服务权重越大被选中的概率越大。刚启动 时如果统计信息不足,则使用轮询。
    可用性过滤:先过滤出故障的或并发请求大于阈值一部分服务实例,然后再以线性轮询的方式从过滤后的实例清单中选出一个。
    会话粘连:在设定的会话保持时间内,会保证规则相关联的所有访问请求会被分配到同一实例上。
    会话保持时间请求发起时,先判断时间戳是否过期,如果没有,则使用原先缓存的服务实例,若过期则选择新的服务实例。默认为600秒。
    失败次数每次请求转发前会预先判断该服务实例是否仍可用,若不可用则进行失败重试。达到最大失败次数后仍无法拿到合适的服务实例,则退出方法,去获取新的服务实例。默认为5次。
  5. 确认路由规则配置信息,完成路由规则创建。

  6. 创建完成后,治理规则默认是停用状态。可以手动设置停用或启用;停用时规则不生效。

访问权限

如需进行访问鉴权,可以打开访问权限开关。关闭时,所有请求均允许访问该服务。开启后,默认服务的所有接口都不允许访问。需要通过配置并启用接口鉴权规则,允许消费方访问。支持配置指定接口鉴权或所有接口鉴权。

  1. 在服务管理页面,选择某个服务,开启访问权限。

  2. 添加接口鉴权。配置规则名称、接口方法路径以及允许访问的服务。支持配置指定接口鉴权或所有接口鉴权。

    指定接口鉴权规则将覆盖所有接口鉴权规则生效。如对 Stock的接口设置鉴权规则,允许Order调用。Stock的接口设置为允许Order调用。

    image-20240715142834105

  3. 所有接口鉴权规则创建后,默认启用。

  4. 指定接口鉴权规则,需创建后手动进行启用/停用。

流量染色

流量染色将带有特定染色标识的流量路由到对应实例。可用于共用环境中调用链路逻辑隔离等场景。

前置条件

1.染色链路中的服务已部署携带染色标签的实例。

配置文件包含 nsf.application.mark 字段。value 为染色标识。

2.服务可以透传染色标识。

染色标识将携带在 HTTP 请求头 x-nsf-mark 中。Agent 治理模式支持透传。

image-20240715143207642

  1. 点击创建流量染色规则。

    参数说明
    染色标识通过染色标识,将特定的流量、服务实例相关联。流量携带key为 mark ,value为染色标识的 HTTP请求头。 染色实例携带key为 mark ,value为染色标识的标签。
    描述规则的备注信息。
    关联服务根据染色标识,自动获取具有染色实例的服务。 展示服务名称、染色实例/总实例。

  2. 创建完成后,治理规则默认是停用状态。可以手动设置停用或启用;停用时规则不生效。

  3. 支持创建入口流量染色。在流量入口为特定流量自动插入染色标识。

参数说明
流量入口NSF服务。
流量协议支持 HTTP、Dubbo。
入口服务如果是 NSF 服务,选择当前项目、环境下某个服务。
流量匹配协议为 HTTP,支持 HTTP Header、Query String、Cookie。
协议为 Dubbo,支持 Header、方法参数。
参数填写需要进行入口流量染色的参数匹配条件。
HTTP协议:流量匹配方式为HTTP Header、Query String、Cookie三种,参数为名称、匹配方式、参数值。
Dubbo协议:流量匹配方式为方法参数, 参数为Service,Method,Method参数序号、匹配方式、参数值。
匹配方式支持正则匹配、字符串匹配。字符串匹配支持多个参数值。

l HTTP

image-20240715143846829

l Dubbo

image-20240715143904412

服务配置

新增服务配置

所属模块:服务管理

适用对象:当前项目的所有人员

功能描述:使用配置管理,将配置动态发布和更新到服务实例。

具体操作:登录微服务治理系统→进入微服务模块→服务管理→单击某个服务→服务配置

前置条件

1.应用程序内使用@value,或者参考 Apollo 官方的使用方式获取配置

  1. 默认创建服务配置表application,配置类型为Properties。支持继续创建配置表。配置表类型支持Properties、Json、YAML、YML、XML,可根据开发框架的需要选择配置类型。其中,只有 Properties 类配置表可以按照表单显示配置项,其他配置类型只能按文本显示配置内容。

  2. 选择某个配置表的新增配置操作,新增配置项。

    参数说明
    配置的 key 值。
    配置的 value 值。
    备注配置的备注信息

  3. 新增后,配置表提示“有修改”标识,配置项为未发布状态。

  4. 支持以表格或文本的形式管理配置表。如修改、删除配置。支持继续对配置进行发布操作。

发布服务配置
  1. 选择某个配置表的发布操作。

    对于已修改的配置表,可以进行发布操作。配置表采用增量发布的方式,只对有修改的内容进行发布;发布时可以指定发布名称,如果不指定,系统会按照时间生成默认发布名称。

    注意:首次发布服务配置后,需要通过更新服务的方式使得服务实例获取配置表。后续配置项修改可以热生效。

  2. 发布后,已发布值被更新。配置项为已发布状态。

  3. 支持查看实例列表。查看该服务的所有实例的配置获取时间,是否已收到最新发布的配置。

  4. 支持通过发布历史查看服务的所有配置发布变更。

  5. 支持进行回滚操作。

回滚服务配置
  1. 选择某个配置表的回滚操作。

  2. 回滚操作可以将配置表回滚到发布的上一个版本。

灰度发布
  1. 选择灰度发布操作。灰度操作将为配置表创建一个灰度版本。

  2. 灰度版本支持新增灰度配置。

  3. 新增灰度配置后,新增灰度规则。选择1个或多个要下发灰度配置的服务实例 IP。

  4. 灰度发布后,灰度规则匹配的实例将使用灰度值。可以通过灰度实例列表查看实例的配置获取时间,是否已收到最新发布的配置。

  5. 灰度版本通过全量发布或者放弃灰度操作终结。全量发布会将灰度的配置合并到主版本发布,所有的客户端都会使用合并后的配置。放弃灰度会将灰度版本删除,所有的客户端都会使用主版本的配置。

治理规则

所属模块:服务管理

适用对象:当前项目的所有人员

功能描述:查看该项目配置的服务治理规则。

具体操作:登录微服务治理系统→进入微服务模块→治理规则

全局配置

全局配置的功能与服务管理模块下的服务配置类似,不同的地方在于,全局配置管理的配置表,作用于当前项目所选环境下的所有服务。

认证管理

支持基于 AK/SK 的服务注册认证机制,服务注册需要携带项目下唯一的 AK/SK,否则将注册失败。

点击“认证管理”。即可看到当前项目在当前环境下的认证信息。该信息包括accessKey和secretKey两部分,可以通过复制按键复制到本机剪贴板;支持 Json和YML两种格式的认证信息复制。

当需要认证时,可以为该项目添加一个新认证。新老认证同时生效,待所有依赖方调整认证后,可以移除老认证。添加新认证时,如果希望指定认证的accessKey和secretKey,可以选择手动添加,如下图所示。

注意:删除认证后,所有使用该认证的客户端将无法访问,需谨慎操作。

快速接入

所属模块:服务管理

适用对象:当前项目的所有人员

功能描述:查看托管至微服务治理平台的服务实例。

具体操作:登录微服务治理系统→进入微服务模块→快速接入

前置条件

1.已通过认证管理,为项目下初始化 AK/SK

虚拟机部署接入
  1. 选择 Agent 接入,虚拟机部署,开始接入。

  2. 新建配置文件,选择【开始接入】操作

    参数说明举例
    服务名称从知识库中选择服务goods
    服务类型服务的协议类型(根据服务名称,服务版本自动判断)HTTP
    服务版本服务的版本号v1
    染色标识nsf.yml中mark对应的值color-mark
    区域服务的区域标签。用于区域优先路由。default
    自定义标签为服务版本实例添加标签,用于服务治理中路由分流等场景key/value
    Packages指定工程项目下的 Package,平台会自动获取 Package 下所有的方法列表。用于配置熔断、限流规则。com.cpbf.boot.service.business.*
    • 将下载的配置文件放置在代码工程 resources 目录下。

  3. 选择【下一步】操作。

  4. 填写 Agent 存储路径。用于存储配置文件、Jar 包文件。如应用启动目录下。Agent 在启动过程中需要写入一些配置和缓存数据到本地文件系统,因此需要保证 Agent 所在的目录具备可写权限,该权限用户需要与用户应用程序保持一致。

  5. 填写配置文件名称。默认为 nsf.yml。如需用于一个主机上多个服务共享Agent 场景,请修改配置文件名称以作区分。

  6. 选择【配置文件下载】操作,将配置文件下载后,上传至 Agent 存储路径。

  7. 选择【Agent 下载】操作。复制 Jar 包下载命令到 Agent 存储路径执行。

  8. 复制启动参数,将启动参数添加到业务启动命令中。

  9. 启动应用。

  10. 服务启动后,可在服务实例列表查看注册情况。

容器部署接入
  1. 生成nsf.yml配置文件同上步虚拟机部署相同,见虚拟机部署1至6;

  2. 将生成的nsf.yml放至resources目录下;

  3. 使用治理平台提供的Docfile模板(如没有联系治理平台相关获取),不同的环境需要使用不同的基础镜像(如x86使用对应的x86的基础镜像,arm64使用对应的arm64的基础镜像);

    image-20240715150126306

  4. 使用架构平台提供的Devops,容器云进行流水线打包,容器云部署启动服务。

知识库

所属模块:微服务

适用对象:当前项目的所有用户

功能描述:列出当前项目下所有服务以及其元信息,便于用户查询

具体操作:登录微服务治理系统→进入微服务模块→知识库

服务列表及服务创建

  1. 点击“创建服务”来创建新服务。

    参数说明举例
    服务名称必填,需要全局唯一。goodsv1
    协议支持 HTTP、Dubbo。
    负责人从微服务治理平台的用户中进行选取,该服务负责人会接受该服务的所有告警信息,非必填。libinglei
    备注用于对服务进行描述,非必填。
    目标环境发布服务到对应的环境
    治理模式选择 Agent

  2. 点击立即创建完成服务创建。

  3. 点击发布配置将服务发布到某个环境。发布后,在指定环境的“服务管理”模块中将看到该服务。

  4. 点击“导入”操作,会弹出文件上传窗口,选择要导入的文件,将文件中的服务元数据自动加载至知识库。目前只支持Json 格式文件。如果导入数据与知识库数据冲突,导入数据会覆盖知识库原有数据。

  5. 点击“导出”操作,选择一个或多个要导出的服务,会将选中的服务元数据生成Json描述文件,并下载到浏览器本地。

服务元信息管理

查看服务的基本信息,进行服务基本信息的修改,或删除该服务。支持对接口信息、数据模型进行管理。支持导入 Swagger操作。

**注意:**只有撤销该服务的所有已发布信息,才可以删除该服务。

接口管理

进行服务接口的管理,可以进行 API 的创建、编辑、查看、删除。

  1. 在API编辑页面,可以填写该API的请求信息,响应信息,响应状态码,示例,并可以查看该API的修改记录。

  2. 填写好API的信息,可以预览该API文档,包括Swagger文档和 Markdown文档两种文档格式。

  3. 对于已经完成定义的API,可以随时查看Swagger和Markdown文档,Markdown文档支持下载。

数据模型

管理 API 所用的数据模型,可进行数据模型的创建、删除、编辑、查看操作。

  1. 点击“创建数据模型”,进入创建表单。填写模型名称和描述信息,点击创建新模型,可进入数据模型编辑页。

    注意:对于同一个服务,数据模型名称不能重复。

  2. 在该页面编辑数据模型的属性列表,点击“保存数据模型”后,该数据模型可在定义 API的Request Body和Response Body时用于指定参数类型。

发布信息

服务发布的管理,可以将该服务发布到指定环境,或从某个已发布环境中撤销。

  1. 点击“发布”,即可进入发布页面。

  2. 选择所要发布的目标环境及其他配置项。一旦成功发布,则该服务会出现在所发布环境的“服务管理”模块中,用户可以在服务管理中对该服务的运行信息进行管理操作,比如服务治理、流量控制、实例管理、配置管理等。

  3. 服务从某个环境中撤销,系统并不会终止该环境下的服务实例,只是将服务信息从该环境中清除,服务将无法继续被平台纳管。

支持 Dubbo

支持 Dubbo 服务的纳管和治理,具体包括:

  1. 支持基于Zookeeper的Dubbo服务注册与发现;

  2. 支持Dubbo服务的依赖关系查看,包括调用的所有服务,以及该服务被哪些服务调用;

  3. 支持查看 Dubbo 服务的实例列表;

  4. 支持查看 Dubbo 服务的监控指标;

  5. 支持对 Dubbo 服务进行动态配置管理;

  6. 支持对 Dubbo 服务进行访问控制;

  7. 支持对 Dubbo 服务的治理,包括限流、降级、容错;

  8. 支持对 Dubbo 服务的流量控制,包括路由、分流、负载均衡;

纳管Dubbo服务

前置条件

1.Dubbo 支持使用用户自建的 Zookeeper 注册中心,请联系治理平台相关人员将注册中心地址配置为自建的 Zookeeper 地址。

  1. 在知识库创建一个 Dubbo 服务。

  2. 改造Dubbo服务。Dubbo服务通常以Zookeeper为注册中心,并且在 Dubbo 配置中添加了相应的注册中心配置。通过平台纳管 Dubbo服务,需要Dubbo服务引入服务治理Agent,并在Agent配置中将服务类型设置为 Dubbo类型,具体参见“Agent使用”小节。

  3. 平台会从 Zookeeper 获取该服务的实例信息。注册成功后,即可在实例列表中看到相应的服务实例。

治理和流控

针对 Dubbo 服务的特点,服务治理和流量控制的规则有相应的调整。

  1. 容错规则。由于Dubbo都是对接口和方法的治理,因此在容错范围中增加Service和Method两个字段。

  2. 路由-参数分流。参数分流表单中,同样增加了Service和Method字段,用于指定需要分流的Dubbo目标接口和方法。对于参数分流,将参数名改为参数序号,这是由于Dubbo是按照序号来确定参数而非参数名。分流目标,所选的是当前项目在 Zookeeper 中注册的Interface和版本。

  3. 路由-负载均衡规则。为负载均衡范围增加Service和Method字段。均衡策略提供轮询、随机和会话粘连三种类型。

    注意:此负载均衡策略由 服务治理Agent 提供,Dubbo框架提供的负载均衡将不再生效。

纳管Dubbo的限制

平台纳管 Dubbo 服务存在以下使用限制:

  1. 不支持 Eureka、Zookeeper 双注册;

  2. Dubbo application和服务治理配置文件(nsf.yml)的服务名、版本号必须一致;如果不一致,会强制使用 服务治理配置的服务名、版本号;

  3. 不同Dubbo application实现的interface不能重名,否则在使用以下类型规则时,会导致路由异常:容错、负载均衡、权重分流;

  4. Dubbo服务引入 服务治理Agent后,原Dubbo框架提供的负载均衡、权重将不再生效;

Agent使用

服务治理Agent 是由平台提供的一个基于动态字节码增强技术的代理服务,它可以通过简单易用的方式将用户的微服务接入微服务治理平台。另外,服务治理 Agent 通过一种代码无侵入的方式为应用提供了大量开箱即用的特性,例如消费端服务发现、限流、熔断降级、容错、路由、分流、认证鉴权、监控等,让微服务系统更灵活更可靠。

获取 Agent

开发或部署人员可以从微服务治理平台微服务模块控制台的快速接入页面下载服务治理Agent(nsf-boot.jar)。

Agent使用方式

启用 Agent

以xxx demo为例,启动命令变更为如下:

java -javaagent:[path_to_nsf_boot.jar]=[unique_key] -jar [jarfile_of_demo]

参数说明:

  • [path_to_nsf_agent.jar]为目标nsf-boot.jar文件的全路径名;

  • [unique_key]为agent对应配置的标识,要求同一环境下必须唯一不重复;

  • [jarfile_of_demo] 为微服务的jar文件;

实际应用举例如下:

java javaagent:/Users/admin/nsf/repo/nsf-parent/builds/nsf-boot.jar=nsf-test -jar goods.jar

如上配置的唯一id为nsf-test,agent在启动的时候首先会从agent所在的目录下寻找nsf-test.yml配置文件,如果找到了则使用这个配置;

否则从目标应用的resource目录下寻找,如果找到了则使用;

否则使用resource目录下的nsf.yml文件,如果存在的话;

如果都找不到且nsf.yml文件不存在的话,则agent加载失败。

打开调试模式

在jvm启动参数上添加 -Dnsf.log.level=debug 则开启调试模式,会输出agent的启动日志,并开启调试的接口,建议生产环境不要开启。

查看 Agent 日志

配置文件增加独立的日志配置项;也可以完全不配置,兼容以前的使用方式,这样日志会和应用程序放在一起。

简单的配置如下:

nsf:

log:

mode: user  #日志输出模式,默认user. all -都输出  服务治理agent自己处理自己的日志  user -统一输出到应用程序自己的日志下

path: /usr/local/nsf/logs  # 日志存放目录

level: debug # 日志等级 默认info

timePattern: yyyy-MM-dd # 影响日志文件的命名。默认为 yyyy-MM-dd 即每天一个,yyyy-MM-dd_HH 为每小时

pattern: "%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{36} - %msg%n" #日志输出格式,选填,此处的值即是默认值。注意此处有%这种特殊字符 值需要加上引号保证能被正确解析

maxFileSize: 1GB # 日志文件大小  默认1GB

maxHistory: 30 #最大的存放时间,默认 30. 单位与timePattern设置有关,timePattern为每天,则存放历史以天为单位

totalSizeCap: 10GB #所有日志文件最大占用空间 默认10GB

日志实现使用的是logback,所以配置文件里的日志配置项基本和logback的AndTimeBasedRollingPolicy配置类似,可以进一步查看其配置的内容来理解服务治理agent的日志配置。

  • mode:可选项为all、nsf、user。all代表服务治理agent自己输出一份日志,应用日志内也会输出;nsf代表仅服务治理agent自己输出一份,应用程序不会携带服务治理agent的日志;user及统一由用户程序输出

  • path:即日志目录,注意最终的日志命名为{applicationname}-agent-{timePattern:yyyy-MM-dd}.%i.log,一般情况一个用户程序的多个实例不会跑在一台机器上,所以不会有多个实例往一个日志文件写日志的情况,但如果你是这种情况请注意区分日志目录

    一般来说用户只要配置以上两个,其他无需配置使用默认的即可,有需要再自定义。

通过环境变量注入配置

服务治理的部分配置支持环境变量注入,主要包括nsf.yml里的各项配置和AK/SK。

环境变量名与配置项对应关系如下:

  • NSF_TYPE --> nsf.type

  • NSF_VERSION --> nsf.version

  • NSF_SERVICENAME --> nsf.application.name

  • NSF_SERVICEVERSION或SKIFF_SERVICEVERSION --> nsf.application.version(SKIFF开头为cicd保留环境变量优先级更高)

  • NSF_ENVCODE或SKIFF_BASICENV --> nsf.application.envCode (SKIFF开头为cicd保留环境变量优先级更高)

  • NSF_APPLICATION_ZONE --> nsf.application.zone

  • NSF_APPLICATION_PROJECTCODE --> nsf.application.projectCode

  • NSF_APPLICATION_GROUP --> nsf.application.group

  • NSF_AUTHORITY_ACCESSKEY --> nsf.authority.accessKey

  • NSF_AUTHORITY_SECRETKEY --> nsf.authority.secretKey

  • NSF_APPLICATION_TAGS_--> nsf.application.tags (tag的环境变量前缀为:SKIFF_APPLICATION_TAGS_

  • 如NSF_APPLICATION_TAGS_k1=v1 这样一条环境变量即代表tag key=k1 value=v1)

配置优先级

Agent 支持多种获取配置的方式,读取配置项的优先级(由高到低):

  1. 服务端下发

  2. 环境变量

  3. 配置文件

  4. 默认值

字段详解

  1. 基本信息

    nsf:

    type: http

    version: '2.0'

    nsfServer: 'http://nsf-server.sgp-pre.chinapost.com.cn'

  • type 表示服务的协议类型。

  • version 表示该 yml 配置的协议版本;

  • nsfServer 表示所要注册的 NSF Server 地址;

  1. 服务信息

    nsf:

    application:

    name: goods

    version: 0.0.2

    zone: regionA

    group: default

    projectCode: yplsxt

    projectEnv: prod

    tags:

    -key: k1

    value: v2

包含服务名称,服务版本号,服务类型,描述信息以及标签;

  • name 表示该实例的服务名,需要与知识库名称保持一致;

  • version 表示该实例的服务版本号,选填,默认值为 0.0.1;

  • projectCode 表示服务归属的项目标识,必填;项目标识可通过控制台的项目管理模块查看;

  • envCode 标识服务归属的环境标识,必填;环境标识可通过控制台的基础环境模块查看;

  • zone 表示该实例的区域标识,选填,默认值为 default;

  • group 表示服务的分组表示,选填,默认值为 default;

  • tags表示标签,需分别定义 key 和 value,支持多个标签;选填;

注意:不同的服务请确保服务名称唯一不重复,否则会当成相同服务处理;

  1. 鉴权设置

    nsf:

    authority:

    accessKey: bc69346c54bd4f4d95dfcc2f20f76e43

    secretKey: d7c1f31caacd435392aae1332d54064b

    accessKey 和 secretKey需要从微服务治理微服务管理平台中根据实际的项目获取和设置。

  2. 治理方法配置

    nsf:

    manager:

    patterns:

    • className:

    com.cpbf.boot.service.business.controller*

配置需要治理的方法名称,支持到具体的方法名称,如下:

nsf:

manager:

patterns:

  • className:

com.cpbf.boot.service.business.controller.*

methods: # 如果方法节点不填写代表包下面的所有方法

-name: getPrice# 上述匹配路径下的具体方法名称

上次更新: