成长加速度

网关过滤器是配置在具体服务下的，只作用于配置对应的服务。如果参数是key-value结构的，可以实现org.springframework.cloud.gateway.filter.factory.AbstractNameValueGatewayFilterFactory抽象类，实际上也是继承了AbstractGatewayFilterFactory。如果需要自定义，同样实现org.springframework.cloud.gateway.filter.GlobalFilter，重写filter方法。

实现org.springframework.cloud.gateway.filter.ratelimit.KeyResolver我们可以基于ip或请求参数等指定不同维度，然后在配置文件指定令牌生成的频率和桶的容量，定制自己的限流逻辑。对于限流，从一个完整的请求链路上来看的话，可以分几块，有nginx接入层网关的限流，微服务网关gateway的限流，在业务层我们也可以实现自己的限流逻辑，Redission和Google的Guava包本身也提供了一些限流工具。

当我们的应用从一个大单体拆分成多个微服务之后，服务间调用有多少种方式？服务间调用如果出现超时，如果避免雪崩，即如何做限流熔断机制，原理是什么？

在Nacos1.x版本，服务间消息通信采用HTTP1.1长轮询，而Nacos2.x升级为gRPC长连接后，除了推送性能提升，内存消耗也大幅降低。而作为配置中心，数据的实时性等不是首要的，但服务间配置信息不一致是不能接受的，Nacos采用JRaft协议实现AP模型。作为服务注册与配置中心，如果不可用，会直接影响到业务，Nacos采用自研的Distro协议实现AP模型；在微服务架构里边，我们主要用Nacos做两块应用，一块是服务注册与发现，一块是配置中心。

微服务项目配置从nacos读取，一直起不来nacos读取配置文件默认使用UTF-8，本地IDEA默认编码格式为GBK，编码不一致导致配置读取格式异常，像控制台打印的乱码启动参数添加 -Dfile.encoding=utf-8 指定格式...

这里只用到springcloud生态到zipkin组件做服务之间调用的链路跟踪配置以9411端口启动服务,这里不能用其他的端口,不然会抛异常,服务间调用的时候链路底层代码会触发这个端口的请求.这里service-name监听不到服务,很多人以为是版本的问题,最后从异常信息才看出问题.

断路器用于服务之间互相调用，当对方服务出现故障，直接调用定义的熔断方法返回，而不是等待请求超时。断路器所需依赖 <dependency> <groupId&amp

SpringCloud中服务之间RPC调用主要有RestTemplate+Ribbon和Feign客户端调用RestTemplate+Ribbon所需的依赖 <dependency> <groupId>org.springframework.cloud&a

SpringCloud微服务项目接口返回 后台控制台 缺少文件DataAccumulator，没在maven镜像中找到，单独引入

SpringCloud体系有分布式配置中心和配置客户端组件，开发者可将开发、测试、生产不同环境下的配置文件，包括微服务配置文件发布到仓库，配置中心对外提供访问接口用于读取配置信息，配置中心可作为微服务注册到服务中心，配置客户端用于从配置中心读取配置文件的特定信息。配置中心所需依赖 <dependency&amp

SpringCloud体系最常用网关组件为Zuul，网关Zuul通过配置文件约定的接口规则将请求转发到对应的微服务子项目去处理，这发挥的是其路由功能。除此之外，Zuul的路由功能可以处理前端的跨越问题。前端可以通过统一域名的请求，而实际的业务处理可能是在不同域名的服务下。Zuul网关还支持过滤器的处理，比如通过判断所有请求是否带临时票据token，token是否合法做权限拦截处理。

工程通过maven多module的方式管理子项目 在parent project引入公共依赖配置 <parent> <groupId>org.springframework.boot&am