背景 目前业务后端代码的通信方式是通过go-micro组件完成的，然而go-micro并没有提供一个可以对微服务进行治理的平台，这样就导致对微服务的治理变得不透明。
Seamiter平台的目标是能够对go-micro微服务之间的调用透明化治理，这包含服务的熔断、限流、热点、服务间的灰度以及跨服务调用接口的Mock等。通过透明化的治理，
以此提高go-micro微服务的可靠性、容错性，同时减少相关代码的研发投入，节省研发资源。
目标 1、提供透明化的UI管理平台，操作简单、分类清楚，同时能够通过UI了解项目的实时的资源情况，如QPS、CPU、内存使用率等
2、提供微服务治理的通用功能，如接口Mock、接口限流、熔断、降级、热点限流、灰度、接口管理等通用功能，同时操作需准实时生效
3、高可用，管理平台自身及为业务提供的服务高可用，业务自身需和管理平台解耦，不能因为管理平台的可用性影响到业务，管理平台不能成为业务系统瓶颈
4、接入成本低，对业务基本无侵入，接入复杂度较低，需要在单位时间内完成（如0.5h），接入不需要了解新的知识
5、高性能，接入后原则上需要对原系统系能基本无影响
6、使用简单，功能操作必须简单易懂，同时有丰富的帮助文档以便研发快速接入，学习成本较低
7、故障隔离，原则上在Seamiter引入的故障可以在不修改代码的情况下动态下线相关功能
8、维护
9、Api，需要提供业务自我定制的功能，也可以在没有UI的情况下对业务系统提供Api进行管理
设计原理 基本概念 资源
是一个抽象概念，可以是一个RPC接口，也可以是一个HTTP Controller，也可能是一个Kafka消息等，常规来说我们可以把一个接口作为一个资源。
规则
围绕资源的实时状态设定的规则，可以包含流控规则、熔断规则、降级规则、Mock规则、重试规则、灰度规则。所有规则可以动态实时调整
设计思想 Seamiter主要划分为两个部分，分别为规则配置、规则槽位。
规则配置：
主要负责规则的增删改查、规则校验。规则配置本身不影响业务执行，也和业务之间不直接交互。但是系统执行过程中可以收集业务执行数据，以便达到监控的目的。由于规则配置具备业务无关性，因此原则上来看，所有地区只需要一份部署就可以达到配置存储的目的。
规则槽：
规则槽会拦截业务执行逻辑，按照规则配置处理响应逻辑。规则槽可以按照一定逻辑排序，同时支持自定义规则槽，可插拔。
“规则配置”和“规则槽”是相互独立的两个部分，“规则配置”可以通过统一的dashboard配置，也可以通过代码固化到业务中，也可以通过外部的持久化文件（File/DB/Etcd/ZK等）
加载或者事件监听加载。规则槽是按照配置实时作用到业务请求中，如限流、熔断、降级等，两者相互解耦，提高了系统的扩展性和可用性。
目前固化的槽位包含：
全局处理：包含全局入口流量统计、CPU、系统负载、平均RT及并发数统计，目前这些数据可以用于全局处理与监控。
资源流控：这是指对特定资源的流量控制，流量控制的结果可能为拒绝、等待或者通过。
并发隔离：这是指对特定资源的并发度进行隔离，避免某个资源的并发数过多导致系统不可用。
热点防控：这是指对特定参数的流量控制。
熔断：特定资源的熔断规则，目前熔断支持RT时长、错误率、错误数等配置
Mock：资源Mock，可以对入参、方法等Mock数据
数据统计：这些是其他规则生效的基础，也会数据监控的基础
灰度：支持基于条件、标签、权重的灰度路由算法
系统组成 系统主要由两个部分组成：seamiter规则管理平台及seamiter-sdk。
规则管理平台：
负责规则的增删改查、权限控制、服务的注册与发现、告警与监控、GRPC接口的拓扑与压测、OpenApi等。seamiter规则管理平台本身并不负责业务逻辑。
为SDK提供了OpenApi，以便SDK感知规则的变更。规则管理平台提供的是Restful服务，原则上只需要业务打通和管理平台的网络，
则规则管理平台只需要部署一份就可以服务于全部地区。目前为了方便业务、同时做到环境隔离，规则管理平台目前会在各个地区同时部署一份。
sdk：
负责规则生效，如限流、熔断、降级、Mock、热点等功能，同时监听规则变更并实时拉取并实时更新到规则中。项目启动时，sdk会主动向规则管理平台上报必要信息，
以便被管理平台管理。seamiter-sdk会实时记录规则的作用效果，以便把数据汇报给规则管理平台做数据的实时分析。seamiter-sdk不仅可以监控管理平台的规则变化，
也可以监控如File、Etcd、ZK、DB等的变化以便实时更新到业务，因此seamiter-sdk本身并不强依赖于规则管理平台。目前
sdk第一期支持的组件为Gin-Web、gRpc、go-micro、go-microv2、go-microv4、EA。
设计模型 如下图是Seamiter的基础模型：
1、用户在seamiter dashboard配置规则并打开开关
2、Seamiter客户端监听规则变化
3、Seamiter客户端从Seamiter Server规则中心拉取最新的规则配置、更新本地内存及持久化文件配置，做作用到业务
功能模块
目前Seamiter划分为基础模块、限流模块、熔断模块、热点模块、Mock模块、重试模块、灰度模块、压测模块及防护模块，依次解释如下：
基础模块：包含监控、面板、权限及应用
服务Mock：服务Mock通过无代码嵌入的方式将Consumer对Provider的请求进行拦截，动态的对Consumer的请求进行放行或者返回用户自定义的Mock数据。
从而解决在前期的开发过程中，Consumer所依赖的Provider未准备就绪时，造成的Consumer开发方阻塞的问题。目前Seamiter提供的Mock方式可以在Consumer
方，也可以在Provider方的Provider执行前。服务Mock和单元测试中的Mock有一定差别，服务Mock主要解决联调、测试等协作流程的处理，
但是也可以用于单元Mock
重试模块：重试模块的原理是监控接口的异常、异常码，在业务接口出触异常时可以根据对应的策略进行重试，目前seamiter提供了多种会退策略，如立刻重试、
固定休眠、指数退避、均匀回退，重试策略包含超时重试，最大重试及无限重试
灰度模块：目前Seamiter提供了三种灰度模式，分别是条件路由、标签路由、权重路由，所提供功能可以轻松实现白名单、金丝雀发布等服务治理诉求
压测模块：此模块主要通过Restful接口转GRPC接口达到RPC接口的调用，同时提供固定压力、脉冲压力、阶梯压力的压力模型，以便达到对业务服务的压测目的
限流模块：限流模块的原理是监控应用的QPS指标，当指标达到设置阈值时即拦截流量，避免应用对瞬时的流量高峰冲垮，从而达到保护应用的目的。
目前Seamiter提供了直接限流、关联限流、链路限流的限流方式
熔断模块：熔断模块的原理是seamiter监控业务内部或者下游的响应时间、异常比例、异常数指标，当达到指定的阈值后，熔断对应的下游依赖。在指定
的时间内，系统不会在调用不稳定的资源，通过通过探针测试依赖是否恢复，以此达到对应用的防护功能
热点模块：热点是指针对特定接口的特定参数值调用频率较高的参数，对此类参数进行限流，以便达到对系统的保护
接口管理：seamiter通过grpc反射技术生成接口文档，使用此功能，测试可以通过平台查看业务的全部grpc接口、入参、出参及版本变更历史
服务压测：seamiter可以在不引入任何依赖的情况下，对远程GRPC接口发起测试，方便快速调整和验证Grpc服务
防护模块：防护模块主要是根据业务上报的指标，在指标达到设定的阈值时，系统会自动发送告警，以便业务技术处理
架构模块 架构V1
seamiter最初架构如图，主要包含portal服务、Admin Service服务、RuleService服务及Client
RuleService：单独服务于Client，用于规则的获取，Rule Service之间通过Etcd实现注册发现
Client: Client和Rule Service保持长链接，通过推拉结合模式（push&poll）,实现规则的实时更新，保证规则变更不丢失
Admin Service:主要服务于Portal,包含规则的增删改查及监控指标的查看
Portal:主要为用户提供操作Portal、权限、操作历史等操作
架构V2 架构V1是没有什么问题的，因为业务内部公用一套etcd实现注册发现，但是如果要扩展到其他团队，这就会涉及到Etcd及跨机房问题。
为了解决这个问题，Seamiter引入了RegisterService，以便实现跨组件/跨机房的注册发现。RegisterService一方面以Restful接口的方式实现注册与发现，另外一方面
推模式涉及到跨机房的网络联通性，为了解决这个问题，我们下掉了推模式，只保留拉模式，同时服务上报时上报当前规则版本，以便和Server进行对比，
如果不一致超过一定阈值后，触发告警通知Seamiter处理
和V1架构相比，此处引入了Register Service，同时Client的注册不是在通过内网IP保持，而是修改了广域网（此处为内网），这样跨机房访问就不会再有问题了。
同时规则也有推拉结合完全修改为了拉模式。Client端会保存自己当前的版本，以便和Rule Service进行交换，当两者不一致时，则会发生规则的拉取。同时为防止
版本比较出现问题，Client还会定时全量拉取。
工作机制 seamiter的工作机制如下：
1、seamiter会对主流框架进行适配，如gin/go-micro/grpc/echo等，定义需要保护的资源，并对资源进行实时统计及链路分析。
同时seamiter会提供API，以便业务自定义资源。
2、seamiter-sdk根据预设的规则，依据对资源的实时统计信息，对流量进行控制，如限流、熔断、降级、灰度等。
同时seamiter提供了接口，以便业务定义或者改变规则。
3、seamiter会对业务统计数据上报，同时对上报数据生成实时试图，以便业务快速了解系统的当前状态。
原理分析 整体分析
在业务接入Seamiter-SDK后，Seamiter会拦截业务业务请求，并依次经过如上规则槽位。
针对流量型规则槽入系统规则、流量规则、隔离规则、热点规则、熔断规则，会产生请求通过或者拒绝的作用效果；
对于Mock规则，请求会在此处匹配后返回，并不会真正的继续请求外部服务；
对于灰度规则，规则的结果是产生新的请求路由；
这些规则执行后，都会进入到规则统计槽，这块会对以上规则的结果进行统计，计算系统的QPS、成功率、失败率、响应时间等，以此反馈给前面的规则槽；
同时统计指标也可以上报道监控平台，入promethues
Mock 在项目测试中，我们发现需要测试的类有很多依赖，同时这些依赖也会有依赖，这会导致测试没办法在单位时间内完成，因此需要Mock。
此处所指的Mock主要是指接口的Mock，如GRPC、WEB等，此处的Mock区别于单元测试，此处主要是指在dev联调或者QA测试阶段的Mock。
Mock的主要目的在依赖没有Ready的情况下，通过插桩Mock掉相关依赖，以便使流程继续流转下去。
原理分析
（1）seamiter对于各种组件增加了对应的拦截器，拦截器会对请求参数、请求头等信息填充给规则槽
（2）SDK会在业务启动时把业务对应的规则缓存到本地中，并组合对应的处理策略
（3）流量进入Mock规则后，SDK会根据资源名称获取对应的规则配置及处理策略（本处为内存操作，因此对系统性能几乎无影响）
（4）如果资源没有配置对应对应的Mock规则，则会按照正常流程进行请求
（5）如果有配置对应的规则，SDK会根据规则配置判断是否要缓存此请求，并异步上报请求。（异步上报主要是为了异步Mock时的请求回查，以便业务可以对异步任务进行自动化）
（6）请求头检查。对于HTTP请求，此处是校验header中的kv，对于go-micro，此处校验Meatadat。此处要求任何Mock接口的请求中必须配置请求头，
这是为了避免影响正常的业务请求。其中规则中的匹配值，是通过dashboard配置。
（7）路由到对应的处理策略。策略分为两种：Mock整个方法、Mock具体的一个请求
（8）Mock效果决策：分为Mock数据、Mock异常、Mock超时、请求替换、响应替换
（9）对于响应替换，是指接口的响应体依赖于请求体，此处SDK会根据请求体替换对应的响应体
（10）规则匹配后，返回对应的Mock数据
（11）SDK适配不同组件的拦截器的响应体结构并转型
通过以上内容的分析，可以看出Mock的实现是非常清晰并简单的，同时seamiter的mock也解决了历史Mock平台的一些痛点：
（1）Go-Micro服务的PB依赖：由于SDK是直接作用于业务，因此并不存在依赖PB文件的情况
（2）Mock数据检查：seamiter知道GRPC接口的入参、出参，可以对于Mock的数据进行检查，避免不正确的数据录入
（3）Mock录入数据源：接口的返回部分时候是非常复杂的，怎么快速构造数据就是业务操作的一个痛点；seamiter会自动捕获一份正常请求辅助业务数据录入
（4）EA支持：go-micro的业务项目是通过GRPC通信的，EA是通过json协议通信的，seamiter适配了这种修改
（5）稳定性：seamiter的mock规则存在于本地及业务配置的外部存储中，因此稳定性不会受到server的影响
场景分析 场景1：QA验证环节，依赖方没有Ready
项目提测后，QA在验证过程中往往会由于依赖方没有Ready或者处理有BUG时会阻塞项目的进度，此时比较适合使用Mock返回预期的任务，
以便达到流程流转的效果。
场景2：QA测试自动化
QA的自动化测试是我们项目日常防护的手段，这个流程的目的主要是验证业务自身系统的可靠性。然而由于测试环境并不稳定，同时部分依赖
方不一定有对应的环境，因此此时Mock对应的接口，可以帮助QA构建稳定的自动化脚本
灰度 灰度发布是实现新旧版本平滑过渡的一种发布方式，即让一部分服务更新到新版本，如果这部分服务没有什么问题，在将其他旧版本的服务更新。
实现灰度较简单的方式可以通过发布的版本号，新更新的服务不会调用旧版本的服务提供者实现。复杂的场景可以通过版本号和路由功能来实现。
路由就是在业务在发布一次GRPC调用时，Clien先拿到所有的服务提供者列表，根据规则过滤，然后再把过滤后的列表作为最终GRPC调用的备选
提供者。因此发起一次GRPC调用会先经过路由规则过滤，在到负载均衡最终选出服务提供者进行调用。
传统的金丝雀发布、滚动发布和分批发布采用的思路是先部署少量的服务机器进行观察，在逐步部署剩余机器，以此来控制变更发布上线的风险。
这种方式往往不具备精确引流和中间件隔离的能力。
而此处的灰度发布提供了更加精确的流量计验证规则。
目前seamiter提供了如下几种灰度模式：
标签路由：标签灰度是针对某一接口中的特定Key进行打标，下游依据此打标标签的Key和Value进行数据路由，
支持以服务提供者Provider为维度的路由规则支持
条件路由：条件灰度是指Cookie/Header/Param/Metadata等中的值满足某种条件时的路由规则，
支持以消费者或者服务提供者的维度配置路由规则
权重路由：是指接口流量根据权重配置路由的对应的接口上
原理分析
（1）seamiter会在接口调用（consumer）前增加拦截
（2）如果被调接口（consumer）配置了灰度规则，seamiter会根据灰度配置，计算出新的consumer
（3）发起最终调用
（4）如果需要灰度标签传递，seamiter会把标签放入到metadata中
（5）如果路由规则计算后新的consumer并不存在，可以选择强制调用，此时会返回接口不存在错误；如果非此选项，则会回退到原始接口调用
以上的解决办法主要是针对go-micro的解决方案，这要求灰度中的切换接口是需要兼容的；如果并不兼容，可以通过seamiter的API建立自定义资
源关联，同时consumer做一定的修改也可以达到灰度的效果。
由于go-micro并没有接口的多版本控制，因此接口版本的切换可以通过两个类同接口实现（如接口命名为v0,v1）,也可以通过接口的多种实现加版本
注释解决。（如接口实现增加注释 @version v0,@version v1，这种思路需要修改go-micro的服务注册发现）
灰度后的效果如图（标签灰度），接口（consumer）会按照标签进行路由到不同的接口服务(provider)：
针对条件路由，seamiter支持多条件匹配，如需要通过匹配来源(FromServer)和参数值（param1 value=1），同时支持AND/OR操作。
针对权重路由，seamiter是通过桶算法实现的，以下是大致的原理图：
权重的大致思路是桶算法，
把请求均匀划分到桶中，每个接口占用固定的桶数量。针对随机的请求，使用一种比较随机算法mod桶数量，就得到了当前桶路由到具体哪个接口中。
场景分析 场景1：灰度发布
业务引入一个新功能，通过灰度版本的控制，实现符合灰度策略的对象，优先进入灰度服务进行体验，此功能观察和验证后才可以推广到全部用户。
场景2：异构服务共存
根据不同的策略，有根据不同的渠道、地域等，优先使用不同的服务。
场景3：同等级服务调用
例如，业务场景，根据不同的渠道和来源进行下单。通过这样的方式，上层业务无须调用何种具体服务统一底层进行负载调用，
实现业务的解耦和服务的可插拔配置；
场景4：VIP业务流量重保
将VIP流量业务引流到专属的环境，来做重保护航，避免系统上不同业务抢占资源和故障印象。例如大促期间对重点商家、VIP可以流量做重点保驾护航
场景5：预案、故障演练
通过流量标签，可以对部分接口进行高风险操作，如异常、超时等操作，常态化进行反脆弱验证，保证容灾能力
场景6：日常多项目开发、测试
通过构建多版本接口进行流量隔离，达到多项目并发时的互相冲突干扰，提高研发效率。如常规版本走V1，新接口版本走V_latest，consumer使用标签
走到新版本
重试 在业务系统遇到非致命性错误时（如偶现接口超时、并发失败等），业务可以通过重试的方式来避免最终失败。seamiter对GRPC接口提供了自动重试策略，
也可以自定义资源及自定义重试策略进行重试。
目前seamiter提供了两种方式的重试捕获：
白名单/黑名单异常：一旦接口抛出固定类型的异常时进行重试
业务错误码：一旦接口返回值包含固定错误或者错误信息时进行重试
原理分析
图10 seamiter重试原理图
具体流程大致如上图，
组件的基本原理就是一个构建器的设计模式，此构建器会设置重试策略、回退策略、关注异常/排除异常以及匹配模式等。
组件把业务的重试都用抽象为一个模板，模板参数需要一个实现了组件重试接口的实例，通过模板的excute方法就可以自动的完成重试功能。
模板执行中，如果捕获到异常，会按照业务异常的设置模式进行匹配。如果符合异常分类且满足重试条件，业务代码会自动进行重试。
在重试中，为了减少重试带来的业务代码的碰壁，模板提供了多种退避策略，以便业务有更多的选择。
重试策略：主要定义在被调方出现错误时怎么进行重试，其中重试策略包含如下几种：
1、NeverRetryPolicy：从不重试，这种策略无论在业务是否发生异常时，都不进行重试
2、SimpleRetryPolicy：简单重试，这种策略可以配置重试的次数，只要发生符合逻辑的错误，就会进行立即重试，而不进行重试规避
3、MaxAttemptsRetryPolicy：最大重试次数策略，这种策略若业务发生异常，只要重试次数小于配置的策略则进行重试
4、TimeoutRtyPolicy：超时重试策略，若业务接口出现错误，且接口没有没有超过对应的超时时间则重试
5、AlwaysRetryPolicy：无穷重试，只要接口出现错误，则进行重试
6、ErrorClassifierRetryPolicy：异常分类重试，错误符合对应的异常策略则进行重试
7、CompositeRetryPolicy：组合重试策略，多种重试策略的组合
回退策略：是指在错误发生后，下次重试前应该怎么处理
1、NoBackOffPolicy：无任何回退，直接重试
2、FixedBackOffPolicy：固定时间间隔回退策略
3、ExponentialBackOffPolicy：指数回退策略，需要设置最小回退值，递增倍率，最大回退值
4、ExponentialRandomBackOffPolicy：具备随机倍率的指数回退策略，和ExponentialBackOffPolicy相比，每次递增的倍率为[1，递增倍率]的随机整数
5、UniformRandomBackoffPolicy：均匀回退策略，需要配置最小回退值，最大回退值，每次回退时是[最小回退值，最大回退值]的随机值
用于重试/不重试的异常：如果两者都为空，则表示任意异常都进行重试，两个配置不能同时满足
异常匹配：默认任意异常都会进行重试，目前支持如下几种：
1、ExactMatch：精确匹配
2、PrefixMatch：前缀匹配
3、SuffixMatch：后缀匹配
4、ContainMatch：包含匹配
5、RegularMatch：正则匹配
6、AnyMatch：只要不为空，则匹配
场景分析 场景1：接口显示的抛出timeout异常
场景2：接口正常返回，但是返回值包含错误码
场景说明 以下场景建议不要设置自动重试规则：
1、不要对致命错误（Fatal Error）重试，重试条件策略一般采取白名单机制（如只对超时异常、限流异常重试）。
典型的报错像Error、Interface not exist这些都建议您不要进行重试，业务错误建议您不要进行重试。
2、重试需要注意幂等性，非幂等的操作在部分场景下重试（如超时，请求已到达对端）可能会不符合预期。
3、前端应用，超时时间长且慢的接口，建议您不要进行重试。
限流 监控应用或者接口的QPS指标，当指标达到预先设置的阈值时，立刻进行拦截，避免应用被瞬时的流量高峰冲垮，从而保障应用的高可用。
原理分析
网络流量的到达具有随机性，而系统处理是有限的。对于业务，每次大促的流量都会数倍于日常流量，这种突发的流量会对系统的稳定性造成威胁。
流量控制的主要目的是能对流量进行整形，如上图。
目前seamiter主要从如下几个维度对流量进行整形:
1、关联：两个资源互相影响，如read_db、write_db，部分场景下write_db优先级高，此时就会对read_db做限流整形
2、链路：资源的调用链路可以理解为A调用B，B调用C，则A→B→C共用一个链路。链路限流可以理解为入口限流整形
3、直接：可以理解为是针对此资源的流量整形
控制效果：
1、快速失败，多出的流量则拒绝
2、排队等待，多出的流量进入排队队列，在排队时间内获取到Token则通过请求，否则拒绝请求。
Token策略：
流量请求只有在获取Token后才能发出正常请求，目前系统支持三种Token生成策略。
1、Direct：如果还有Token未使用完，则直接分配Token；
2、WarmUp：这种策略主要是参照了Java中的RateLimiter的实现，这种策略对于数据库资源的分配比较适用，也比较适合于大促时的策略，
避免一次性分配了太多的Token，而业务可能还没有预热好的情况。
3、内存自适应： 此种策略对内存划分为低内存及低内存对应的阈值，高内存及高内存对应的阈值，其中低内存阈值>高内存阈值，因为在
应用的内存使用率低时，可以承载更多的流量。此种策略可以根据系统的内存使用率子使用流控算法。
如果系统的内存使用率<低内存阈值时，限流阈值为低内存阈值，
如果系统的内存使用率>高内存阈值时，限流的阈值为高内存阈值，
如果系统的内存使用率在两者之间时，阈值=（内存使用率-低内存值）/（高内存值-低内存值）*（高内存阈值-低内存阈值）+低内存阈值
seamiter会在业务资源请求时，增加一些固化的槽位，同时业务也可以自定义槽位，作用到资源中。
滑动窗口：
seamiter-sdk底层是通过滑动窗口来实现QPS统计的，滑动窗口的作用原理如图
图12 滑动窗口计数原理图
如上图，滑动窗口的长度是1000ms,默认分为5个窗口，则当前请求按照计算都可以落入到其中的一个窗口中，每一个窗口维护一个计算器，每次请求落入窗口，
则进行计数加1，同时由于窗口则不断移动，则新的请求落入到新的窗口中。
如图，当时间戳为910ms时，落入到窗口5，当前的QPS为50，窗口移动后，由于最后一个窗口的计数为12，则此次的QPS为52。
排队等待：
针对排队等待的实现原理说明如下：
可以理解为均匀限流，如果阈值设置为10，那么就是0.1秒下发一个请求，意味着100ms下发一个请求
案例分析：
假设QPS阈值为：10
当前时间：10:00:00:000
场景1:请求同时到达
10:00:00:000 req1 0 100ms 0ms 10:00:00.000 第一次请求，最近请求通过时间为0 10:00:00:000 req2 10:00:00.000 100ms 100ms 10:00:00.100 并发到达，第一个请求通过后，最近请求通过时间修改为10:00:00.000 10:00:00:000 req3 10:00:00.100 100ms 200ms 10:00:00.200 并发到达，req2修改后，最近通过时间修改为10:00:00.200 10:00:00:000 req4 10:00:00.200 100ms 300ms 10:00:00.300 并发到达，req3修改后，最近通过时间修改为10:00:00.300 场景2:请求陆续到达，请求间隔小于100ms
10:00:00:000 req1 0 100ms 0 10:00:00.000 第一次请求，最近请求通过时间为0 10:00:00:050 req2 10:00:00.000 100ms 50ms 10:00:00.100 陆续到达，第一个请求通过后，最近请求通过时间修改为10:00:00.000,
最近修改时间10:00:00.000+预期等待时间100ms-当前时间为10:00:00.050
=50ms
休眠50ms后下发
10:00:00:080 req3 10:00:00.100 100ms 120ms 10:00:00.200 陆续到达，req2修改后，最近通过时间修改为10:00:00.200,
最近修改时间10:00:00.100+预期等待时间100ms-当前时间为10:00:00.080
=120ms
休眠120ms后下发
10:00:00:120 req4 10:00:00.200 100ms 180ms 10:00:00.300 陆续到达，req3修改后，最近通过时间修改为10:00:00.300
最近修改时间10:00:00.200+预期等待时间100ms-当前时间为10:00:00.120
=180ms
休眠180ms后下发
场景3:请求路由到达，请求间隔大于100ms
10:00:00:000 req1 0 100ms 0ms 10:00:00.000 第一次请求，最近请求通过时间为0 10:00:00:200 req2 10:00:00.000 100ms 0ms 10:00:00.200 陆续到达，第一个请求通过后，最近请求通过时间修改为10:00:00.000,
当前时间为10:00:00.000+预期等待时间100ms=10:00:00.100<10:00:00.200，
立刻下发
10:00:00:400 req3 10:00:00.200 100ms 0ms 10:00:00.400 陆续到达，req2修改后，最近通过时间修改为10:00:00.200,
当前时间为10:00:00.200+预期等待时间100ms=10:00:00.300<10:00:00.400，
立刻下发
10:00:00:600 req4 10:00:00.400 180ms 0ms 10:00:00.600 陆续到达，req3修改后，最近通过时间修改为10:00:00.400
当前时间为10:00:00.400+预期等待时间100ms=10:00:00.500<10:00:00.500，
立刻下发
Token WarmUp策略：
模型的本质是令牌桶算法，在初始时将令牌桶中的令牌“填满”，预热期间扣减令牌，用剩余的令牌与斜率推导出每秒可以扣减额令牌数，从而动态得出预热期间的限流阈值。
X轴：令牌桶数量
Y轴：每个令牌的生成间隔
warningToken：令牌预警数量，即当令牌桶中的剩余数量到达预警值时，预热结束
maxToken：令牌桶的最大容量，当令牌桶达到最大值后，生成的令牌将会被丢弃
slope：斜率，用来计算当前令牌生成的时间间隔
warmUpPeriodSec：系统预热时间，单位秒
假设当前令牌桶桶的令牌数为X，X在warningToken和maxToken之间，则生成一个Token的间隔为
稳定时时间间隔+（x-warningToken）*slope
当预热时间后，生成一个Token的时间间隔为 稳定时的时间间隔，
下面我们分析一个案例：
假设下项目设置的阈值为100，预热时间为10秒，冷却因子coldFactor为3，项目的滑动窗口的统计时间为1000毫秒，
通过公式：
warningToken = (WarmUpPeriodSec * Threshold) / (WarmUpColdFactor-1)=10*100/(3-1)=500
maxToken = warningToken + 2WarmUpPeriodSecThreshold/(1.0+WarmUpColdFactor)=500+210100/(1+3)=1000
slope = (WarmUpColdFactor-1.0) / Threshold /( maxToken-warningToken)=(3-1)/100/(1000-500)=0.00004
可以计算得出初始始token的时间间隔为：稳定时时间间隔+（x-warningToken）*slope=1/100+（1000-500）*0.00004=0.03
也就是说每秒可以通过的QPS=33.33
随着预热时间的推移，每秒通过的QPS在逐步增大；当预热结束时（此处为10秒），在持续的请求下，则QPS为100并稳定不变；
如果过了流量高峰，则token会恢复到maxToken，进入新的预热期
场景分析 场景1：削峰填谷，使流量匀速通过
流量具有峰谷、峰底的特点，seamiter会把峰谷的流量排队等待匀速通过，以便保证最大化请求，又能保证用户体验
场景2：资源争抢时预留足够资源给优先级高资源
假设query_account和open_account代表UC的两个操作，为了保证open_account的成功率，在资源不足时，优先保证open_account，这时
open_account的优先级大于query_account。当open_account的操作比较频繁时，query_account资源会被限流
场景3：预热启动避免流量突发增大
在大促时，短时间流量会增加数倍，而此时DB/系统可能还处于冷备状态，这可能瞬间把系统压垮。seamiter可以通过预热使流量缓慢增加，
以便系统预热。
熔断 微服务架构中，服务的调用链路比较长，因此链路的可靠性变得更加重要。如果服务的某个调用链路不可用，这会导致请求时间变长，
进而使链路请求堆积，最终可能导致调用方的资源耗尽使整体服务不可用。场景如图：服务A调用服务B、D完成业务，服务B、D依赖服务C、E，
如果服务E临时不可用，会导致服务A的调用变长，如果此时可以快速熔断服务E，则可以使服务A的整体堆积降低，最终保护了整体链路。
图17 熔断应用场景
seamiter会监控系统应用内部及下游的响应时间和异常比例，当达到指定的阈值后，seamiter会立刻降低下游的优先级。在指定的时间内，
系统对下游调用进行熔断，不会调用不稳定的资源，避免应用收到影响，从而保证应用的高可用。在指定的时间内，系统会有一定的探针，
以便恢复系统调用。
目前提供了三种熔断判断方式：
慢比例调用：如果请求的RT时间超过设置值，则会被标记为慢请求，当单位时间内达到阈值时，则熔断
异常比例：如果请求出现了异常，则会被标记为异常请求，如果单位时间内异常比例达到阈值，则熔断
异常数： 如果请求出现了异常，则会被标记为异常请求，如果单位时间内异常数达到阈值，则熔断
调用资源被熔断后，并不是不在调用下游，而是根据熔断时长和探针数来间断性的请求来判断下游是否可用，当探针内数据全部正常时，则在此关闭熔断开关。
图18 熔断状态图
熔断的状态图包含三种状态，分别为关闭、打开、半开，
当单位时间内的请求全部成功或者错误率低于阈值时，熔断开关是关闭的，一旦失败达到阈值，则熔断开关会被打开，当熔断窗口结束后，会进入半开状态，
此时会探测性测试接口是否可用，如果全部探针都成功了，则关闭熔断，如果有一个失败，则继续把状态更新为打开状态
场景分析 场景1：慢调用熔断
当调用第三方调用，但是第三方调用响应较慢，会影响当前接口，则可以对其熔断；
场景2：弱依赖异常调用熔断
当页面展示时，有多个第三方接口聚合，如果第三方接口出现异常，可以熔断，以便提高用户体验
场景3：慢SQL熔断
数据库读写时有慢SQL，可以对慢SQL做熔断，以便保护业务
热点
热点防护主要是针对热点资源的保护，这种资源并不是某一个固定的接口，而可能是针对特定的资源接口参数的防护，如热点账户或者热点商品等。
针对Gin-Web、Go-Micro等特定组件类资源，seamiter-sdk会在请求时自动拓扑出请求参数，业务只需要配置对特定资源的限流就可以达到预期效果。
针对非标准类资源，业务需要自己实现参数的拓扑。在seamiter-sdk中，会将业务流量分为常规资源和热点流量，其中常规流量会按照特定资源的配
置进行限流或者无配置时直接通过，而针对热点流量，seamiter-sdk会按照热点资源的配置走对应的限流及熔断，
可以对同一个资源设置多种规则，如userId=1的规则1，userId=2的规则2，以便达到对特定资源的热点配置。未来seamiter-sdk会按照某些配置做到
热点资源的主动发现，以便用户做出更多精准的配置。
目前对于热点参数的统计是根据最近最久统计算法及令牌桶算法达到对参数的限流。
场景分析 场景1：秒杀场景
对于大促促销商品，会导致短时间内流量较大，以至于业务无法正常响应，而这种流量较大的特点是针对个别商品，而并非整个SKU。对于这种场景，
可以配置热点参数，以便达到保许系统的功能。
场景2：调用请求频繁，需占用过多的系统资源
对于业务，往往存在大商家的场景，这种用户的单位时间内订单较多，每一个订单完结都需要修改用户的额度信息，进而导致下游压力较
大，针对这种场景可以限制此用户的并发度，降低依赖系统的压力。
并发隔离 并发隔离控制是指基于访问的并发协程数来控制对资源的访问，避免因为资源的异常导致协程耗尽。
接口管理 Seamiter实现了对GRPC及Go-Micro接口的自动的自动拓扑，并通过server进行统一管理。在seamiter启动时，会通过grpc的反射方法获取业务中所有的grpc接口，
Seamiter-server会主动拉取业务的pb proto file文件，并解析pb描述文件中的接口信息，生成完成的接口信息。同时业务每次变更时，server都可以拿到最新的接
扣信息，因此server可以维护接口的变更历史。
Seamiter同时接口的版本变更历史，以便业务快速生成接口文档。
场景分析 场景1：快速生成接口文档及接口变更历史
目前跨团队交互是通过接口文档维护的，然而接口文档的维护代价是很高的，seamiter提供了准确的接口变更信息，并提供导出功能，可以有效降低维护成本
场景2：restful接口调用GRPC接口
跨业务的接口交互往往是跨协议的，restful接口形式是一种好的跨协议的交互方式。seamiter依赖接口信息，可以构造从restful数据转GRPC接口的调用
压力测试 压力测试是指seamiter可以构造压测模型，以便对接口进行测试。压力测试计划提供对restful接口及GRPC接口的压力测试。压力测试会提供多种测试模型，
如固定压力模型、阶梯压力模型、脉冲压力模型，同时压测可以收集压测的执行结果，以便生成压测报告。目前此部分的功能还在研发中，暂未交付。
场景分析 场景1：大促压测
信贷产品在每次大促时都需要对业务进行压测，通过维护压测脚本的管理，可以降低每次压测的投入成本
场景2：测试自动化-并发构造
目前live的线上问题，很多来源于并发场景，然而常规的功能测试很难发现这些问题；通过常态化压力测试，可以在测试环境更多发现并发的问题
操作指南 配置Mock规则 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择服务Mock
3.单机新增
图21 新增mock规则
页面参数明细说明如下：
方法Mock:
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 业务自身为规则定义的名称，任意名称，长度255内 my-test 资源名称 待mock的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
gin-web: GET:/user/query3/:id
go-micro: accountService.AccountService.Query
作用类型 方法/入参；如果为方法，则无论参数为什么，都会返回统一的Mock数据；
如果为入参：Mock会按照参数进行，匹配后返回Mock
控制效果 Mock数据：规则命中后返回Mock数据
抛出异常：规则命中后，抛出对应的异常
休眠：规则命中后，sleep规定时间
休眠后抛出异常：规则命中后，先sleep规定时间，然后抛出对应异常
休眠后Mock：规则命中后，先sleep规定时间，然后返回Mock数据
什么也不做：命中规则后，继续后续流程
附加参数 必填，规则只有在附加参数匹配是，才生效；对于gin-web，附加参数添加到
Header中；对于Micro，附加参数添加到MetaData中
附加参数值 附加参数Key对应的Value 开关 开关为“开”时规则生效，否则规则不生效 参数Mock：mock选择为“参数”->功能按钮“参数例外”->“添加”
标签名称 自定义名称，长度小于255 参数名称 gin-web：请求参数名称
go-micro：请求体属性中对于的json属性名称
参数类型 string：请求参数类型为string，对于string可以有如下匹配方式：
“精确匹配”、“前缀匹配”、“后缀匹配”、“包含匹配”、“正则匹配”
参数值 在参数匹配时，只有参数值也匹配才生效 Mock替换 “否”：仅做Mock功能
“替换Mock响应”：根据请求体中的参数名称对应的值替换Mock数据中“替换属性”的值，
一般用于响应结果依赖请求参数的场景
“替换真是请求”：把请求体替换为“Mock数据”的请求体，并继续发起远程请求，一般
如果请求体的某些属性比较难时需要此种类型，如请求体中有time.Now()，而验证请求
希望是历史时间
“替换ctx超时”：go-micro GRPC超时时间默认是5s，如果希望修改此超时时间使用此选项
“替换Mock响应”：如请求体中有“orderId”，
返回体中也有“orderId”，希望使用请求体中
的“orderId”替换响应体中的“orderId”；
如果结构体只有一层，“替换属性”直接写orderId就
可以了；如果是结构体中还有结构体
控制效果 见上 附加参数 见上 附加参数值 见上 开关 见上 高级设置-参数关系 多参数匹配的情况下，参数间的关系；如果为“或”，则任意一个参数匹配，则返回规则数据；
如果为“且”，只有全部匹配的情况下，才会返回规则数据
告警设置-其他参数 见上 功能按钮 新增：新增一个Mock规则
编辑：修改Mock规则配置
删除：删除这条规则配置
参数例外：当作用类型为“参数”时，展示“参数例外”按钮，用户配置参数规则
请求上报：打开后，请求体会上报到平台
复制：复制一份此条规则，便于快速构建
同步：把此规则同步到其他环境，Dev环境可以同步到其他Dev环境或者Test环境，Test环境可以同步到Test环境或者UAT环境，依次类推
批量同步：规则批量同步到其他环境
参数例外-上移/下移：修改规则的优先级，最上面的规则优先匹配
配置灰度规则 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择灰度规则
3.单机新增
图22 新增灰度规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 业务自身为规则定义的名称，任意名称，长度255内 my-test 资源名称 待mock的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
gin-web: GET:/user/query3/:id
go-micro: accountService.AccountService.Query
来源应用 此规则对那些应用生效，默认是全部应用 灰度标签 如果有此值，则会在contex增加对应的标签值；key为grayTag，
value为配置的“灰度标签”，此值会在context中传递
路由策略 条件路由：条件匹配，则进入灰度；否则规则不生效
标签路由：对于go-micro，metadata中的标签值匹配是，规则生效，
权重路由：按照一定的权重，路由到多个灰度接口
链路传递 “灰度标签”是否在上下文中传递
强制返回 "否"： 当路由结果为空，降级请求tag为空的提供者;
"是"：当路由结果为空，直接返回异常
白名单 录入则规则只在指定IP生效，否则不生效 开关 开关为“开”时规则生效，否则规则不生效 条件路由：
新建->路由策略“条件路由”→"条件集合"→“新增”
图23 新增条件路由
页面参数明细说明如下：
目标资源 规则命中后路由到的具体资源接口 目标版本 暂时保留 生效地址 规则生效时的地址，暂时保留
开关 开关为“开”时规则生效，否则规则不生效 灰度条件 “所有”：所有规则都满足时才生效，否则不生效；
“任意”：任意一条规则满足时就生效，否则不生效
参数集合 参数类型：Cookie、Header、Body、Param、Metadata，其中gin-web对应类型：Cookie、Header、Body、Param；go-micro对应类型：Param、Metadata
参数Key：要匹配的Key
运算符：=，!=，>，>=，<，<=，IN，NOT IN，%100
参数值：参数key经过运算后要匹配的值
权重路由：
新建->路由策略“权重路由”→"权重集合"→“新增”
图24 新增权重路由
页面参数明细说明如下：
目标资源 规则命中后路由到的具体资源接口 目标版本 暂时保留 生效地址 规则生效时的地址，暂时保留
权重 此条规则所占用的权重，数据路由时具体的分发比例计算公式=（当前规则的权重）/sum(规则权重) 开关 开关为“开”时规则生效，否则规则不生效 标签路由：
新建->路由策略“标签路由”→"标签集合"→“新增”
图25 新增标签路由
页面参数明细说明如下：
目标资源 规则命中后路由到的具体资源接口 目标版本 暂时保留 生效地址 规则生效时的地址，暂时保留
标签Key 需要匹配的标签key，gin-web为header中值；go-micro为metadat中值 匹配标签 标签key对应的值 开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个灰度规则
编辑：修改灰度规则配置
删除：删除这条规则配置
条件集合-上移/下移：规则优先级设置，优先级高的优先匹配
特别说明：seamiter支持的灰度属于功能灰度，对应的路由接口需要兼容
配置重试规则 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择重试规则
3.单机新增
图26 新增重试规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 业务自身为规则定义的名称，任意名称，长度255内 my-test 资源名称 待重试的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
gin-web: GET:/user/query3/:id
go-micro: accountService.AccountService.Query
重试策略 永不重试：永远不进行重试
简单重试：规则匹配后，直接重试3次
超时重试：在接口处理没有超过timeout的情况下一直重试
最大尝试重试：在规则匹配后，重试“最大重试”次
无限重试：规则匹配后，只要没有成功，则一直重试
回退策略 在规则匹配后的下一次重试前的策略；
立即重试：立刻发起重试，不休眠
休眠规定时长：重试前休眠固定的时间
指数退避：在重试前按照延长时常*倍率进行重试，每次倍率幂次增加休眠时常，只到达到最大间隔
随机倍率退避：和指数退避类似，只是在每次休眠时间的倍率为[1,倍率]间的随机数
均匀随机回退：重试前休眠[最小回退，最大回退]间的随机数
异常包含 要匹配的异常关键字符，多个“,”分割；“异常包含”和“异常排除”不能同时满足
异常排除 要排除的异常包含关键字 响应属性 在没有异常的情况下，匹配相应体中的属性，“响应属性”和“属性值”匹配时进行重试 属性值 要匹配对应的属性值 开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
配置应用压测 应用压测计划支持restful接口和GRPC接口压测。目前Restful接口还在规划中，GRPC接口暂时只支持部分功能
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择应用压测
3.单机新增
图27 新增压测规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 场景名称 为本次压测定义一种场景，任意名称，长度255内 my-test 服务名称 应用服务所提供的服务名称
前提：接入seamiter-sdk，并打开反射配置
请求参数 GRPC调用所需的请求参数体
seamiter会自动填充默认请求体及类型 超时时间 GRPC接口的请求超时时间，超时后client会中断
打印日志 seamiter会对压测流量打标，打开日志后，会打印压测请求；打开日志会影响性能，建议压测时关闭
压测模型 TPS吞吐量，系统每秒处理事务的数量，目前只支持这一种 流量模型 固定压力：以配置的固定并发值进行施压；
阶梯压力：设置最大值、最小值、递增时长等信息。从最小值开始按照阶梯逐步递增，达到最大值后按照最大值持续施压
脉冲压力：设置峰值、谷值以及持续时间等信息，施压流量以峰值、峰谷的锯齿波的形式进行施压
TPS 每秒处理的事务数 压测时常 压测的持续时间 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
执行一次：对此规则执行一次，一般用于验证联通性
启动压测：按照对应的配置，开始启动压力测试
停止压测：中断正在进行的压力测试
结果查看：查看压测的执行结果
配置流控规则 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择流控规则
3.单机新增
图28 新增流控规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 对流控的接口命名，以便于识别 资源名称 待流控的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
my-test 来源应用 此规则对那些应用生效，默认是全部应用
阈值类型 QPS：接口达到对应的阈值后，启动限流
并发协程数：接口的并发度达到对应的阈值后，doing限流
单机阈值 单节点启动限流的阈值
集群 是：启用集群统一限流，暂不支持
否：单机限流
流控模式 直接：此配置仅仅应用于当前接口
关联：具有优先级的接口，如写接口的优先级高于读接口优先级；当此接口达到对应的阈值后，对关联资源进行限流；如果关联资源不存在，则直接通过
链路：对调用链路的限流，一般关联到链路入口
Token策略 直接：按照配置的固定值生成token，是一种令牌桶算法
WarmUp：在预热时间内逐步达到对应阈值
内存自适应：根据高低水位内存，进行动态的调整token策略
开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
配置熔断规则 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择熔断规则
3.单机新增
图29 新增熔断规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 对流控的接口命名，以便于识别 资源名称 待流控的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
my-test 来源应用 此规则对那些应用生效，默认是全部应用
熔断类型 慢调用比例：当设置了接口的“最大RT”时间，如果请求的响应时间大于“最大RT”时间，则被统计为慢请求。如果“统计时间”内，请求数大于“最小请求数”且慢请求所占的比例大于“比例阈值”，则会触发熔断。在达到“熔断时长”后，会根据探针数量进行重试
异常比例：在“统计时间”内，如果请求书大于“最小请求数”，且请求异常数大于“比例阈值”则进行熔断。在达到“熔断时长”后，会根据探针数量进行重试
异常数：在“统计时间”内，如果请求书大于最小请求数，且请求异常数大于“异常数”则进行熔断。在达到“熔断时长”后，会根据探针数量进行重试
开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
配置热点规则 限流规则是针对整个接口的，热点规则是针对某个接口的某个参数值的限流。
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择热点规则
3.单机新增
图30 新增热点规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 对流控的接口命名，以便于识别 资源名称 待流控的资源名称，对于gin-web:名称为 请求方式：请求链接；
对于GRPC：GRPC服务名称.接口名称
my-test 来源应用 此规则对那些应用生效，默认是全部应用
限流模式 支持QPS和协程数
参数/参数索引 指具体针对那个参数进行限流 单机阈值 针对这个参数的QPS 超时时长 请求最大等待时长 集群 目前只支持单节点限流 参数例外 针对具体某个参数值的限流 开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
参数例外：设置针对某个参数的特定值的限流
配置系统规则 作用于某个业务节点的所有接口
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择系统规则
3.单机新增
图31 新增系统规则
页面参数明细说明如下：
应用名称 规则所属应用，需为seamiter管理的应用 规则名称 对流控的接口命名，以便于识别 阈值类型 Load：节点的Load1负载，超过对应的阈值则进行限流
RT：接口的响应时间，超过这个值，则进行限流
协程数：节点的并发协程数超过这个值，则进行限流
入口QPS：请求入口的总QPS，超过这个值，则进行限流
CPU使用率：节点的CPU使用率，超过阈值则进行限流
阈值 触发限流的最小值 开关 开关为“开”时规则生效，否则规则不生效 功能按钮 新增：新增一个规则
编辑：修改规则配置
删除：删除这条规则配置
资源集合 seamiter-sdk会在业务请求中进行埋点，对于资源的第一次成功的请求，seamiter会记录请求的资源名称、请求返回，以便快速构建规则数据。
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择资源集合
图32 系统资源集合
功能按钮 流控：快速创建一个流控规则，如果规则已经存在，则跳转到配置
熔断：快速创建一个熔断规则，如果规则已经存在，则跳转到配置
热点：快速创建一个热点规则，如果规则已经存在，则跳转到配置
Mock：快速创建一个Mock规则，如果规则已经存在，则跳转到配置
监控：监控此接口的QPS，响应时间，错误率等指标
实时监控 是对系统的全部接口进行实时监控，如QPS，RT，异常数，成功数，通过数等进行监控
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择实时监控
图33 系统实时监控
功能按钮 接口管理 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择应用列表
3.选个一个应用->方法列表
图34 接口管理
图35 接口明细
功能按钮 历史版本：接口变更的历史
编辑：编辑接口描述，如是否必填、DB映射、描述等
全部导出：导出接口入参、出参、描述、字段映射等
导出Html：把接口描述以Html格式导出
导出Word：把接口描述以word格式导出
导出历史变更：把接口的历史变更信息导出
OpenApi 功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择OpenApi
3.增加一个AccessToken
图36 AccessToken管理
页面参数明细说明如下：
Api名称 开放Api名称标识 描述 名称描述 应用名称 标记此设置针对那个应用生效
Urls 需要开放访问的Urls swagger验证地址：
mock-增加： /openapi/mock/add mock-更新： /openapi/mock/update mock-移除： /openapi/mock/remove mock-加载By： /openapi/mock/loadBy mock-加载： /openapi/mock/load mock-增加Item： /openapi/mock/addItem mock-更新Item： /openapi/mock/updateItem mock-移除Item： /openapi/mock/removeItem mock-加载ItemBy：/openapi/mock/loadByItem mock-加载Item：/openapi/mock/loadItem
AccessToken 访问Token，此Token需要增加到请求头中 案例：
功能按钮 新增：新增一个应用Token
编辑：修改应用中的访问Url
删除：删除这个应用Token
备注：
规则通过Api设置后3秒后生效，也就是业务设置后需要休眠3s，如果想等待时间短一些，需要sea.yaml中做如下配置
sea :
dashboard: fetchRuleIntervalMs: 100 系统管理 应用归属于分组，分组内的用户可以查看应用的配置信息
菜单归属于角色，角色控制菜单权限、导航权限
用户分配分组、角色、平台权限，这样可以操作具体的平台下的数据
功能入口 1.登入Seamiter-Dashboard
2.在左侧导航栏选择系统管理
功能按钮 用户管理：管理用户的角色、分组、密码、可查看的平台等
角色管理：管理系统当前分配的角色
菜单管理：管理导航栏、按钮
分组管理：管理分组及分组下的用户
平台管理：管理所有的地区、环境的平台地址
常规管理 为应用登入后首页的数据
功能入口 1.登入Seamiter-Dashboard
2.在导航栏右侧常规管理
功能按钮 平台切换：快捷切换到各个平台的数据
退出登录：退出seamiter
CPU：当前应用的CPU指标数据
状态码统计：web请求的状态码统计
CPU Top：当前情况下的CPU使用率倒叙
QPS数据：最近5分钟内的请求QPS
防护事件：最近触发的系统保护事件
异常统计数据：最近接口的异常统计
异常TOP：最近接口的异常统计
TOP列表：最近QPS TOP、流控QPS TOP、平均RT TOP
可用性分析 某台RuleService下线 无影响 RuleService无状态，客户端重连到其他Rule Service服务 所有RuleService下线 客户端无法读取最新的规则 运行中机器或者机器重启可以读取本地缓存。
新机器扩展，配置ZK、Etcd等外部持久化文件，
启动时拉取
某台Portal下线 无影响 Portal域名解析绑定到多台服务器，用户重试连接到其他Portal 全部Portal下线 客户端无影响，Portal无法更新
数据库宕机 客户端无影响，Portal无法更新配置 运行中的服务器可以读内存缓存，重启后可以读本地缓存，配置读取不受数据库宕机影响 监控相关 组件支持 Gin 1.8.x ALL Echo 待支持 更新中 Gear 更新中 更新中 Go-Micro v1,v2,v4 >= v0.1.179-release EA
= v0.1.179-release Kafka 支持 ALL,需要手动埋点 RocketMq 支持 ALL,需要手动埋点 xorm 支持 ALL,需要手动埋点,待支持自动埋点
接入步骤 以上是一个go-micro项目接入的简单案例，gin-web项目雷同
步骤一：seamiter-dashaboard增加应用
登入seamiter->应用列表→添加
图 添加应用
备注：此处的应用名称，建议使用英文，此名称需要需要和SDK的配置中的名称一致
步骤二：增加seamiter-sdk
应用源码->go.mod→添加SDK包→go mod tidy & go mod vendor
步骤三：增加seamiter-sdk对应的配置文件（默认使用sea.yaml）
sea: closeAll: false app: name: "seamiter-dashbord录入的server地址" type: 0 log: dir: "sea" usePid: false
level: 1 metric: singleFileMaxSize: 52428800 maxFileCount: 7 flushIntervalSec: 1 dashboard: server: seamiter-server地址 openConnectDashboard: true sea.closeAll：如果希望本环境不启用，则设置为true，否则为false
sea.app.name：此名称为在seamiter-dashboard配置的名称，此名称必须正确，否则会导致项目注册不上去
sea.log.dir：seamiter-sdk输出日志的目录名称
sea.log.level：打印日志的级别，如果希望看到更加详细的地址，可以设置为debug
sea.dashboard.server：seamiter-server的地址，参见地址列表
sea.dashboard.openConnectDashboard：是否连接dashboard获取规则，如果为true，则会主动拉取；如果为false，则可以通过API手动设置规则
步骤三：初始化
import (
)
func init() { err := sea.InitWithConfigFile("resources/config/sea.yml") if err != nil { logging.Warn("Upexpected error:", "err", err) } } 其中sea.InitWithConfigFile使用的是相对路径，
步骤四：增加拦截器
//--------------order------------------------- goMicroOrderClient := micro.NewService( micro.Name("AccountService"), micro.Client(client.NewClient(client.Wrap(sea_micro.NewClientWrapper( ))))) goMicroOrderClient.Init() AccountService = pb.NewAccountService("accountService", goMicroOrderClient.Client()) 主要是增加sea_micro.NewClientWrapper()拦截器
验证效果：
启动业务项目，会在10s内发现业务项目注册到seamiter-dashboard则表示接入成功
图 注册成功案例