8

微服务设计指导-实践springcloud+springboot+nacos+feign+hytrix

 2 years ago
source link: https://blog.csdn.net/lifetragedy/article/details/121954704
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

什么样的请求需要做成微服务

模块A→模块B。

而,模块B→请求模块C。

如果A和B本身又有其它的请求如:

模块D->模块A,模块E→模块B;

此时,对于:

  • 模块C,需要做成基于单根api的微服务provider;
  • 对于访问模块C的,需要做成微服务consumer/client;

忌讳的做法

  • 服务泛滥,例:把单表的增删改查都做成了微服务,到处调用;
  • 循环无止镜去调用微服务;
  • 什么都做成微服务;

需要记住的微服务开发规范

  • 单体的provider在1,000并发的情况下,必须在毫秒级(绝对不能超过1秒)完成请求;
  • 如果在固定的一个模块内己有服务101、服务102、服务103.而此时需要做一个服务104且服务104包括了(服务101、服务102、服务103),不得在consumer/client端直接组装(特别是还含有循环组装)己有微服务101、微服务102、微服务103. 而是在模块A内再包出一个微服务104(含服务101、102、103的业务逻辑)来给到consumer以避免微服务被”过度重用“;
  • 但是有些情况,微服务的循环调用是不可能避免的,此时遵守”线程数恒定且不能无限扩充、使用CPU时间片轮流转以总体时间可适当延长但是同一时刻微服务被调用数量永远恒定且控制在一个可调节阀值“的法则来做设计;
  • 记得对任何资源调用地方要及时释放;
  • 记得一轮循环必须要给到系统以喘吸时间,即:Thread.sleep(xxxx毫秒),在系统喘吸时间java会根据自身的jvm自行去释放被关闭了的资源(就算调了close,jvm也不会ASAP去释放。但不调close资源一定泄漏);

基于spring cloud的微服务技术栈

  • JDK_1.8_up079及以上;
  • eclipse Version: 2020-06 (4.16.0)+(强烈建议抛弃掉intellij吧,你会被沦为码家的,因为太方便了,要方便真的不要走编码路线);
  • spring boot2.0.x,每一个spring boot甚至是2.0.x后的x的不同都会导致你选择的spring cloud、熔断器、nacos版本的不同,我们这边假设用的spring boot是2.3.1;
  • spring cloud,Hoxton.SR7;
  • spring-cloud-alibaba,用来把spring boot和nacos连接起来的一个必要库,2.2.1.RELEASE;
  • nacos-discovery,服务自动注册发现,2.2.5.RELEASE;
  • hystrix,熔断器(包括服务降级/升级),1.2.3.RELEASE;
  • hystrix-dashboard,辅助类,1.2.3.RELEASE;
  • okhttp,spring-cloud的微服务底层用的是httpClient 4.x去实现的,性能不是最好,因此我们需要换成用okhttp去访问,4.0.0;

一个标准的微服务provider做法

maven pom.xml

application.yml内和微服务相关的配置

把一个spring boot服务注册上nacos的代码

就一个@EnableDiscoveryClient搞定了。

provider端controller的写法(标准spring boot controller)

好了,provider端搞定。

一个标准的微服务的consumer/client端做法

maven pom.xml

此处的org.sky.demo.timeout.TmeoutUserFacade是微服务的feign+hystrix的熔断出错处理作为子jar包引入到consumer/client端用的后面会给出代码。

application.yml内和微服务相关的配置

为什么这大一陀,比网上的丰富多了(网上很多复制粘贴都是错的)

ribbon: eager-load: enabled: true clients: TimeoutUser

处的clients指向provider的spring.application.name后所指的值。这是因为Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的,而是在调用的时候才会去创建相应的Client,所以第一次调用的耗时不仅仅包含发送HTTP请求的时间,还包含了创建RibbonClient的时间,这样一来如果创建时间速度较慢,同时设置的超时时间又比较短的话,很容易就会出现上面所描述的显现。这个问题和ESClient的第一次加载的梗是一样的。

书写“代理provider端“的proxy+熔断器

此处,我们把这个proxy+熔断器作为了一个工程的子jar包,引入到我们的consumer端主体工程内了。

feign+hystrix子jar包pom.xml

子jar包内的客户端(application.yml配置跟着consumer主体包内的application.yml走)

子jar内的熔断器TimeoutUserServiceProxyFallback.class(application.yml配置跟着consumer主体包内的application.yml走)

consumer端controller的写法(标准spring boot controller)

consumer启动类的写法

此处有两个annotation:

  • @EnableFeignClients

  • @EnableDiscoveryClient

把3个项目启动起来,然后通过http://localhost:9080/demo//timeout/advancedIndexWithLive记问。

然后你会看到因为该微服务连着的实际业务服务里有一个Thread.sleep(8000);而我们的微服务超时为:2秒。

因此你会看到AdvancedIndex工程内抛出一个熔断信息为“服务报错导致服务降级”的exception,进而打断服务。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK