2分彩怎么做代理_Hystrix针对不可用服务的保护机制以及引入缓存

  • 时间:
  • 浏览:1

   从前我写过一篇博文,通过案例了解Hystrix的各种基本使用妙招,在这篇文章里,大伙儿儿是通过Hystrix调用正常工作的服务,也什么都有说,Hytrix的保护机制并那么 起作用,这里大伙儿儿将在HystrixProtectDemo.java里演示调用不可用的服务时,hystrix启动保护机制的流程。什儿 类是基于NormalHystrixDemo.java改写的,什么都有在其中增加了getFallback妙招,代码如下。     

1	//省略必要的package和import代码
2	public class HystrixProtectDemo extends HystrixCommand<String> {
3		RestClient client = null;
4		HttpRequest request = null;
5	    //构造函数很这类
6		public HystrixDemoProtectDemo() {
7		super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
8		}
9	   //initRestClient妙招没变
10		private void initRestClient(){
11	        //和NormalHystrixDemo.java一样,具体请参考代码
12		}
13		//run妙招也没变
14		protected String run() {
15			//和NormalHystrixDemo.java一样,具体请参考代码
16		}
17	    //这次多个了getFallback妙招,一旦出错,会调用其中的代码
18		protected String getFallback() {
19			//省略跳转到错误提示页面的动作
20			return "Call Unavailable Service.";
21		}
22		//main函数
23		public static void main(String[] args) {
24			HystrixDemoProtectDemo normalDemo = new HystrixDemoProtectDemo();
25			normalDemo.initRestClient();
26			try {
27				Thread.sleep(30000);
28			} catch (InterruptedException e) {
29				e.printStackTrace();
300			}           
31			String result = normalDemo.execute();
32			System.out.println("Call available function, result is:" + result);
33		}
34	}

    什儿 类里的构造函数和NormalHystrixDemo.java很这类,而initRestClient和run妙招根本没变,什么都有就不再完正给出了。

    在第18行里,大伙儿儿重写了HystrixCommand类的getFallback妙招,在其中定义了一旦访问出错的动作,这里仅仅是输出一段话,在实际的项目里,都能够跳转到相应的错误提示页面。

    而main函数里的代码和NormalHystrixDemo.java里的完正一样,什么都有,在运行这段代码前不需要运行HystrixServerDemo项目的启动类,从前服务一定是调用能够的。运行本段代码后,大伙儿儿能看一遍如下的结果。  

             In run

             Call available function, result is:Call Unavailable Service.

    从第2行的输出上,大伙儿儿能确认,一旦调用服务出错,Hystrix出理 类能自动地调用getFallback妙招。

    不可能 这里那么 定义getFallback妙招,那么 一旦服务不可用,那么 用户不可能 在连接超时从前,在浏览器里看一遍一串毫无意义的内容,从前用户体验就很差,不可能 整个系统的其它容错妙招也没到位,甚至就有 不可能 原因分析 当前和下游模块瘫痪。

    相反,在这里不可能 大伙儿儿在hystirx提供的getFallback妙招里做了充分的准备,那么 一旦老是出现错误,这段错误出理 的代码能被立即触发,其效果就离米 熔断后继的出理 流程。

    由getFallback出面,友好地告知用户出什么的什么的问题 了,以及后继该何如出理 ,从前一方面能及时熔断请求从而保护整个系统,自己面不需要造成因体验过差而用户大规模流失的状态。

    不可能 每次请求就有 走后台应用守护进程乃至再到数据库检索一下数据,这对服务器的压力不要 ,有从前什儿 因素甚至会成为影响网站服务性能的瓶颈。什么都有,大多数网站会把什儿 不需要实时更新的数据倒入缓存,前端请求是到缓存里拿数据。    

    Hystrix在提供保护性便利的一块儿,能够支持缓存的功能,在下面的HystrixCacheDemo.java里,大伙儿儿将演示Hystrix从缓存中读取数据的步骤,代码如下。     

1    //省略必要的package和import代码
2    public class HystrixCacheDemo extends HystrixCommand<String> {
3        //用户id
4        Integer id;
5         //用有有有4个HashMap来模拟数据库里的数据
6        private HashMap<Integer,String> userList = new HashMap<Integer,String>();
7        //构造函数
8        public HystrixCacheDemo(Integer id) {
9        super(HystrixCommandGroupKey.Factory.asKey("RequestCacheCommand"));        
10            this.id = id;
11            userList.put(1, "Tom");
12        }

    在第3行里,大伙儿儿定义了有有有4个用户id,并在第6行定义了有有有4个存放用户信息的HashMap。

    在第8行的构造函数里,大伙儿儿在第10行里用参数id来初始化了本对象的id属性,并在第11行里,通过put妙招模拟地构建了有有有4个用户,在项目里,用户的信息确实是处于数据库里的。    

13        protected String run() {
14            System.out.println("In run");
15            return userList.get(id);
16        }

    不可能 不走缓存一段话,第13行定义run函数不可能 被execute妙招触发,在其中的第15行里,大伙儿儿通过get妙招从userList什儿 HashMap里获得一条用户数据,这里大伙儿儿用get妙招来模拟根据id从数据库里获取数据的诸多动作。    

17		protected String getCacheKey() {
18			return String.valueOf(id);
19		}

  第17行定义的getCacheKey妙招是Hystrix实现缓存的关键,在其中大伙儿儿都能够定义“缓存对象的标准”,具体而言,大伙儿儿在这里是返回String.valueOf(id),也什么都有说,不可能 第4个HystrixCacheDemo对象和第有有有4个对象具有相同的String.valueOf(id)的值,那么 第4个对象在调用execute妙招时,就都能够走缓存。

public static void main(String[] args) {        
21         //初始化上下文,什么都算是法用缓存机制
22            HystrixRequestContext context = HystrixRequestContext.initializeContext();
23            //定义有有有4个具有相同id的对象
24            HystrixCacheDemo cacheDemo1 = new HystrixCacheDemo(1);
25            HystrixCacheDemo cacheDemo2 = new HystrixCacheDemo(1);
26            //第有有有4个对象调用的是run妙招,那么

走缓存    
27            System.out.println("the result for cacheDemo1 is:" + cacheDemo1.execute());
28            System.out.println("whether get from cache:" + cacheDemo1.isResponseFromCache);
29            //第4个对象,不可能

和第有有有4个对象具有相同的id,什么都有走缓存    
300            System.out.println("the result for cacheDemo2 is:" + cacheDemo2.execute());
31            System.out.println("whether get from cache:" + cacheDemo2.isResponseFromCache);
32            //销魂上下文,以清空缓存
33            context.shutdown();
34            //再次初始化上下文,但不可能

缓存已清,什么都有cacheDemo3没走缓存
35            context = HystrixRequestContext.initializeContext();
36            HystrixCacheDemo cacheDemo3 = new HystrixCacheDemo(1);
37            System.out.println("the result for 3 is:" + cacheDemo3.execute());
38            System.out.println("whether get from cache:" + cacheDemo3.isResponseFromCache);
39            context.shutdown();

    在第20行的main妙招里,大伙儿儿定义了如下的主要逻辑。

    第一,在第22行,通过initializeContext妙招,初始化了上下文,从前能够启动缓存机制。,在第24和25行里,大伙儿儿创建了有有有4个不同名的,但相同id的HystrixCacheDemo对象。

    第二,在第27行里,大伙儿儿通过cacheDemo1对象的execute妙招,根据id查找用户,确实大伙儿儿在这里是通过run妙招里第15行的get妙招从HashMap里取数据,但大伙儿儿都能够把这想象成从数据表里取数据。

    第三,在第300行里,大伙儿儿调用了cacheDemo2对象的execute妙招,不可能 它和cacheDemo1对象具有相同的id,什么都有这里并那么 走execute妙招,什么都有直接从保存cacheDemo1.execute的缓存里拿数据,这就都能够出理 因多次访问数据库而造成了系统损耗。

    第四,大伙儿儿在第33行销毁了上下文,并在第35行里重新初始化了上下文,从前,确实在第36行定义的cacheDemo3对象的id依然是1,但不可能 上下文对象被重置过,其中的缓存也被清空,什么都有在第37里执行的execute妙招并那么 走缓存。

    运行上述代码,大伙儿儿能看一遍如下的输出,有有哪些打印结果能很好地验证上述对主要流程的说明。    

1    In run
2    the result for cacheDemo1 is:Tom
3    whether get from cache:false
4    the result for cacheDemo2 is:Tom
5    whether get from cache:true
6    In run
7    the result for 3 is:Tom

    这里请大伙儿儿注意,在缓存相关的getCacheKey妙招里,大伙儿儿就有 定义“保存缓存值”的逻辑,什么都有定义“缓存对象的标准”,初学者老是会混淆这点。具体而言,在这里的getCacheKey妙招里,大伙儿儿并那么 保存id是1的User对象的值(这里是Tom),什么都有定义了如下的标准:而且我有有有4个(或多个)HystrixCacheDemo对象具有相同的String.valueOf(id)的值,什么都有缓存中什么都有可能 存有id的1的结果值,那么 后继对象则都能够直接从缓存里读数据。

    在上文里,大伙儿儿演示了通过Hystrix调用可用以及不可用服务的运行结果,并在调用过程中引入了缓存机制,这里,大伙儿儿将在上述案例的基础上归纳Hystrix的一般工作流程。

    第一,大伙儿儿都能够通过extends HystrixCommand<T>的妙招,让有有有4个类具备Hystrix保护机制的形态,其中T是泛型,在上述案例中大伙儿儿用到的是String。

    第二,一旦继承了HystrixCommand从前,大伙儿儿就都能够通过重写run妙招和getFallback妙招来定义调用“可用”和“不可用”服务的业务功能代码,其中,这有有有4个妙招的返回值须要和第一步里定义的泛型T一致。而在项目里,大伙儿儿一般在getFallback妙招里,定义“服务不可用”时的保护妙招(也什么都有后文里将要提到的降级妙招)。

    第三,大伙儿儿还都能够通过缓存机制来降低并发状态下对服务器的压力,在Hystrix里,大伙儿儿都能够在getCacheKey里定义“判断都能够走缓存对象的标准”。

    在使用缓存是,请注意两点,第一须要开启上下文,第二,Hystrix会根据定义在类里的属性判断多次调用的对象算是同有有有4个,不可能 是,什么都有从前被调用过,则都能够走缓存。

    本文谢绝转载。