LindDotNetCore~Polly组件对微服务场景的价值

回到目录

Polly是一个开源框架,在github上可以找到,被善友大哥收录,也是.App vNext的一员!

App vNext:https://github.com/App-vNext

GitHub:https://github.com/App-vNext/Polly

NanoFabric是一个开源的微服务架构,也是善友大哥推荐的:https://github.com/geffzhang/NanoFabric

对于NanoFabric来说,它集成了很多.net core开源项目,其中包括了Consul + .NET Core + Polly + Ocelot + Exceptionless + IdentityServer,你是否闻到了某种味道!

Polly给我们带来了什么

  1. 对http请求提供重试机制
  2. 对指定异常进行特殊的处理
  3. 提供了多种策略

程序中的使用

封装一个方法,对外提供一个委托的参数,把需要进行polly的代码段输入进来即可,对于http,数据库,网络通讯等非常必要,因为这些场景可能存在不稳定的因素!polly正好可以帮我们非常

友好的解决它,下面的代码主要实现了对所有异常的跟踪,然后每1秒重新执行一次,可以重试5次!

        /// <summary>
        /// polly重试机制
        /// </summary>
        private static HttpResponseMessage retryTwoTimesPolicy(Func<HttpResponseMessage> action)
        {
            var policy = Policy
                .Handle<Exception>()
                .WaitAndRetry(
                 5,
                 retryAttempt => TimeSpan.FromSeconds(Math.Pow(1, retryAttempt)),
                 (ex, timer, c, i) =>
                 {
                     logger.Logger_Info($"执行失败! 重试次数 {c}");
                     logger.Logger_Info($"异常来自 {ex.GetType().Name}");
                 });
            return policy.Execute(action);
        }

我们之前的httpHelper请求对象,也可以引入polly机制,全局进行控制!

        /// <summary>
        /// GET请求
        /// </summary>
        /// <param name="requestUri">服务地址</param>
        /// <param name="nv">参数键值</param>
        /// <returns></returns>
        public static HttpResponseMessage Get(
            string requestUri,
            NameValueCollection nv)
        {
            try
            {

                return retryTwoTimesPolicy(() =>
                {
                    var result = httpClient.GetAsync(GeneratorUri(requestUri, nv)).Result;
                    UnGZip(result);
                    return result;
                });
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

自己开两个api进程,一个是对外提供服务,别一个作为主服务器,被其它进行访问,当它挂了之后,其实进行可以通过polly进行重试!

感谢各位的阅读!

微服务来了,但需要我们关注的点多了!

奋斗吧!

回到目录

原文地址:https://www.cnblogs.com/lori/p/8387205.html

时间: 2024-11-10 17:12:59

LindDotNetCore~Polly组件对微服务场景的价值的相关文章

【微服务】之五:轻松搞定SpringCloud微服务-调用远程组件Feign

上一篇文章讲到了负载均衡在Spring Cloud体系中的体现,其实Spring Cloud是提供了多种客户端调用的组件,各个微服务都是以HTTP接口的形式暴露自身服务的,因此在调用远程服务时就必须使用HTTP客户端.我们可以使用JDK原生的URLConnection.Apache的Http Client.Netty的异步HTTP Client, Spring的RestTemplate.但是,用起来最方便.最优雅的还是要属Feign了.今天这一篇文章是系列教程中第五篇,也是对负载均衡的第二篇,主

用友iuap云运维平台支持基于K8s的微服务架构

什么是微服务架构? 微服务(MicroServices)架构是当前互联网业界的一个技术热点,业内各公司也都纷纷开展微服务化体系建设.微服务架构的本质,是用一些功能比较明确.业务比较精练的服务去解决更大.更实际的问题.该架构强调的一些准则:单一职责.协议轻量.进程隔离.数据分离.独立部署.按需伸缩. 什么是Kubernetes? Kubernetes是Google开源的容器集群管理系统,其提供应用部署.维护. 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,其主要功能:

在 Docker 上运行一个 RESTful 风格的微服务

tags: Microservice Restful Docker Author: Andy Ai Weibo:NinetyH GitHub: https://github.com/aiyanbo/docker-restful-demo 实现构思 1. 使用 Maven 进行项目构建 2. 使用 Jersey 实现一个 RESTful 风格的微服务 3. 在 Docker 里面执行 mvn package 对项目打包 4. 在 Docker 容器里运行这个微服务 实现一个微服务 场景 & 需求

微服务与Java EE

本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2016/01/microservices-and-java-ee 时至今日,基于微服务的架构已经随处可见了.我们见识到了Netflix与Amazon等创新者是如何通过微服务来取得业务上的成功.不过,对于那些使用Java EE服务器,编写传统系统的开发者来说应该何去何从呢?我们一直所做的都是错误的么?我们该如何让技术设计能够适应于未来? 单体架构 首先,我们来看一下这些传统系统,或者说

微服务运行指南——For Cattle

站在微服务的角度看容器的基础设施服务可以分为三层: 微服务基础层 微服务构建层 微服务访问层 Rancher的服务发现就是基于rancher-dns来实现,创建的stack&service都会生成相应的DNS记录,用户可以通过相应的规则进行访问,这样在微服务之间就可以无需知晓各自的IP地址,直接用服务名进行连接即可. 微服务基础层主要是为容器提供计算.存储.网络等基础资源.主机计算资源主要是对docker-machine封装来提供相关服务:容器存储通过Convoy组件来接入,目前对NFS协议的存

微服务架构与实践及云原生等相关概念

微服务架构与实践 笔记:<微服务架构与实践> 王磊 著 一 单块架构 1 定义:对于这种功能集中.代码和数据中心化.一个发布包.部署后运行在同一进程的应用程序,我们通常称之为单块架构应用,并非物理上的分层. 2 单层架构:数据 逻辑 页面 混合 3 三层架构: 1)表示层:数据显示和用户交互 2)业务逻辑层:业务逻辑处理 3)数据访问层:数据存储访问 4 优势: 比较适合小项目 易于开发:开发简单直接,集中式管理,基本不会重复开发,集成工具适合 易于测试:单进程 易于部署:单项目包,功能都在本

使用 Dubbo 对遗留单体系统进行微服务改造

摘要: 在 2016 年 11 月份的<技术雷达>中,ThoughtWorks 给予了微服务很高的评价.同时,也有越来越多的组织将实施微服务作为架构演进的一个必选方向.只不过在拥有众多遗留系统的组织内,将曾经的单体系统拆分为微服务并不是一件容易的事情. Credit: Justin Kenneth Rowley. You can find the original photo at flickr. The microservices style of architecture highligh

基于 Docker 的微服务架构实践

本文来自作者 未闻 在 GitChat 分享的{基于 Docker 的微服务架构实践} 前言 基于 Docker 的容器技术是在2015年的时候开始接触的,两年多的时间,作为一名 Docker 的 DevOps,也见证了 Docker 的技术体系的快速发展.本文主要是结合在公司搭建的微服务架构的实践过程,做一个简单的总结.希望给在创业初期探索如何布局服务架构体系的 DevOps,或者想初步了解企业级架构的同学们一些参考. Microservice 和 Docker 对于创业公司的技术布局,很多声

Devops微服务架构下具有代码级穿透能力的精准测试

微服务是Devops场景下热门的开发框架,在大型项目中被广泛采用.它把一个大型的单个应用程序和服务拆分为数十个的支持微服务,独立部署.互相隔离,通过扩展组件来处理功能瓶颈问题,比传统的应用程序更能有效利用计算资源.微服务之间无需关心对方的模型,它通过事先约定好的接口进行数据流转,使业务可以高效响应市场变化.但微服务一个明显的表象就是随着服务的增多,传统的测试模式受到很大制约,无法有效进行下去,威胁到整体系统质量.所有J2EE代码层白盒采集工具都无法区分覆盖和具体功能的对应关系,只能以后台模式"笼