Zuul

微服务   微服务架构是一种以一些微服务来替代开发单个大而全应用的方法，每一个小服务运行在自己的进程里,并以轻量级的机制来通信, 通常是 HTTP RESTful API。微服务强调小快灵， 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务。   微服务是一种生态，不是一种具体技术 微服务的特性 自主性（松耦合）   可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。 专用性   每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。 灵活扩展   通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。 轻松部署   微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。 目前微服务的发展状况   目前主流的就是springCloud和dubbo了，那么我们对他们做一个对比： Dubbo   一款高性能、轻量级的开源Java RPC框架

经过仔细检查，全部配置映射都没问题，springboot-admin 监控中心所有服务状态全部显示绿色正常 但就是通过 zuul 访问服务提示 500错误 这个情况，一般是请求超时所致 调整请求超时时间即可 zuul服务本地报错提示：com.netflix.zuul.exception.ZuulException: Forwarding error 原始配置示例： hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 12000 ribbon: ReadTimeout: 6000 ConnectTimeout: 6000 zuul: host: socket-timeout-millis: 6000 connect-timeout-millis: 6000 from www.1b23.com 全部改成： hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 12000 ribbon: ReadTimeout: 12000 ConnectTimeout: 12000 eureka: enabled: true zuul: host: socket-timeout-millis

来源网站： www.wangdatao.com 前言 分布式系统中经常会提到限速和降级的概念。所谓限流，可以认为是服务降级的一种，限流就是限制系统的输入和输出流量， 以达到保护系统的目的 系统上线之前，一般都会进行压测，压测之后吞吐量是可以被测算的，为了保证系统的稳定运行， 一旦达到了设定限制的阔值，就需要限制流量并采取一些措施以完成限制流目的。常见的限流方案为：延迟处理、拒绝处理和部分拒绝处理等。一般高并发系统常见的限流有：限制总并发数（比如：数据库连接池、线程池）、限制瞬时并发数、限制时间窗口内的平均速率；其他还有如限制远程接口调用速率、限制MQ的消费速率；另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。 1、常用算法 1.1、计数器算法 算法思想： 规定一个时间周期，统计在一个周期内总共请求的次数，如果时间超过一个周期，则次数计入到下一个周期内。比如：当接收到第一个请求时，记录第一次的时间 beginTime, 计数器Counter设置为1，当第二个请求来时，判断第二个请求的时间与beginTime的间隔有没有超过最初设计的时间周期，如果没有超过，判断Counter是否超过设置的最大速度数，都满足时Counter加1；如果超过设计的时间周期，beginTime时间改为第二次请求的时间，Counter重置为1。 //不严谨的算法代码 public class

API网关是提供服务开放和共享的企业级PaaS平台，提供发布管理、统一认证鉴权、流控、协议转换、服务审计等功能，帮助用户实现内部多系统间，或者内部系统与外部系统之间实现跨系统、跨协议的服务能力互通。 为什么需要API接口开发？ 随着微服务架构的流行，API网关也越来越受欢迎。在微服务体系架构中，将应用程序划分为几个低耦合的服务（称为微服务），每个服务都有其独特的功能。尽管微服务提供了许多好处（最显着的是使它更易于开发，部署和维护应用程序的不同部分），但它们却使客户难以快速，安全地访问他们所需的信息。 API网关接口开发可以充当使用这些微服务的客户端的中央接口，从而解决其中的一些问题。客户端不必访问数十个单独的服务，而是可以向API网关发送单个请求，而API网关本身将聚集微服务。API网关的主要功能称为路由，但是使用API网关的原因还有很多。 对于服务数量众多、复杂度比较高、规模比较大的业务来说，引入API数据接口平台也有一系列的好处： ● 聚合接口使得服务对调用者透明，客户端与后端的耦合度降低 ● 聚合后台服务，节省流量，提高性能，提升用户体验 ● 提供安全、流控、过滤、缓存、计费、监控等API管理功能 在【数商云】与客户合作的技术实践中，客户往往需要通过统一的API接口平台进行服务能力的共享，提供发布、管理、保护和监控接口API的能力，实现跨系统、跨协议的服务能力互通。

开发联调阶段通过zuul网关给app提供接口。但调用接口时好时坏，有时抛出如下异常。 { "timestamp" : 1590461140265 , "status" : 500 , "error" : "Internal Server Error" , "exception" : "com.netflix.zuul.exception.ZuulException" , "message" : "TIMEOUT" } 只知道是TIMEOUT，有一定的概率发生，但具体是哪里超时无法确定。也只能让接口调用者先不停的retry。 zuul超时 ? ribbon超时 ? hystrix超时 ? 搜索timeout配置项毫无发现 抛出的堆栈信息包含重要信息。 以下是一些调试的技巧。 打断点： 选择一个地方作为入口。 逐行跟踪： Step Over ， Step Into ， Force Step Into ， Step Out ，Drop Frame ， Return to Cursor ， Resume Frame 。 这是了解一个软件(插件） 内部执行逻辑最好的方法。只有一步步调试下去，一定能找到到底是哪里出错了。 其余一些捷径。 点击包名即可进入到包内。 包内进行搜索 timeout。 最终在hystrix包内检索到 execution.isolation.thread

每个服务都有自己的接口，通过Swagger来管理接口文档。在服务较多的时候我们希望有一个统一的入口来进行文档的查看，这个时候可以在Zuul中进行文档的聚合显示。 下面来看下具体的整合步骤以及采坑记录。Cloud版本：Finchley.SR2， Boot版本：2.0.6 加入Swagger的依赖： 1. <!-- Swagger --> 2. <dependency> 3. <groupId>io.springfox</groupId> 4. <artifactId>springfox-swagger-ui</artifactId> 5. <version>2.9.2</version> 6. </dependency> 7. <dependency> 8. <groupId>io.springfox</groupId> 9. <artifactId>springfox-swagger2</artifactId> 10. <version>2.9.2</version> 11. </dependency> 增加聚合代码： 1. @EnableSwagger2 2. @Component 3. @Primary 4. public class DocumentationConfig implements SwaggerResourcesProvider { 5. 6.

SpringCloud的Hoxton版本，和之前的版本相比，用新的组件替换掉了原来大部分的组件，老的组件现在处于 停更不停用 的状况。 详情见下图（ × 的表示之前的组件，现在停更了的； √ 的表示新的替换后的组件）： 描述： 服务注册中心： Eureka：官方停止更新，并且已经有更好的替代产品了，可以使用，但是官方已经不建议使用了（重度患者）。 Zookeeper：某些老系统，以前是用的Zookeeper + Dubbo，后来做技术升级，结果发现SpringCloud的Eureka停更了，然后就用了最少的技术切换，那么就用了Zookeeper做注册中心。 Consul：go语言开发的，也是一个优秀的服务注册框架，但是使用量较少，风头都被Nacos抢了。 Nacos：来自于SpringCloudAlibaba，在企业中经过了百万级注册考验的，不但可以完美替换Eureka，还能做其他组件的替换，所以强烈建议使用，是学习的重点。 服务调用： Ribbon：也进入了维护状态，停止更新了，但是Spring官方还在使用（轻度患者）。 LoadBalancer：Spring官方推出的一个新的组件，打算逐渐取代掉Ribbon，但是现在还处于萌芽状态。 服务调用2： Feign：Netflix 公司产品，也停止更新了。 OpenFeign：Spring社区等不了Netflix更新了

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ SpringCloud微服务 微服务的模式和形式我在前面已经进行部分的提及，但是一直没落实到技术层面，这段时间我也在次研究了一下微服务，下面我先贴出SpringCloud整体涉及的结构： 上面展示的这些是SpringCloud整体的结构 先对这些空间做一个初步的介绍： Ribbon，客户端负载均衡，重试机制。 Hystrix，客户端容错保护，服务熔断、请求缓存、请求合并、依赖隔离。 Feign，声明式服务调用，本质上就是Ribbon+Hystrix（优化代码，避免直接使用RestTemplate的混乱）Bus，消息总线，配合Config仓库修改的一种Stream实现，独自启动不需要依赖其它组件。 Eureka，服务注册中心，特性有失效剔除、服务保护。 Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。Zuul，API服务网关，功能有路由分发和过滤。还有其它服务空间，包括configuration等等 那么什么是注册中心呢？ 注册中心，是服务的提供者发布自己服务的地方，传统手写的restful接口提供的服务会涉及到服务发布者的端口IP等等，通过注册中心可以直接调用已经发布在上面的服务，只需要通过服务名即可 从图中可以看出

https://cloud.tencent.com/developer/article/1082821 Zipkin和微服务链路跟踪 本期分享的内容是有关zipkin和分布式跟踪的内容。 首先，我们还是通过spring initializr来新建三个项目。一个zipkin service。另外两个是普通的业务应用，分别叫service和client。 zipkin service client service 如上我们引入了web 、zipkin client两个依赖。 新建zipkin server应用 先打开zipkin-service项目。 我们来看看依赖情况： <dependency > <groupId >org .springframework .cloud < /groupId > <artifactId >spring -cloud -starter -zipkin < /artifactId > < /dependency > <dependency > <groupId >org .springframework .boot < /groupId > <artifactId >spring -boot -starter -web < /artifactId > < /dependency > 上面是默认的依赖。这里需要把这些依赖都换掉，否则zipkin

场景： 数据量大，打开zipkin页面有时候报错，打不开。 加载页面过慢，因为span数据太多。 原因：使用spring-cloud-sleuth后，feign 访问Controller后得span得名字 当使用restful风格后，span的名字就图像如上。 触发此事件的场景： 1.浏览器直接调用 解决：修改spring sleuth Controller 的 源码： org.springframework.cloud.sleuth.instrument.web.client.AbstractTraceHttpRequestInterceptor.publishStartEvent(HttpRequest) 2.服务之间调用（feign） 解决：修改spring feign sleuth 源码： org.springframework.cloud.sleuth.instrument.web.client.feign.TraceFeignClient.execute(Request, Options) org.springframework.cloud.sleuth.instrument.web.client.feign.TraceFeignClient.getSpanName(Request) 3.服务之间调用（java网关，gateway(默认根据http 类型，不会有问题)