spring cloud学习笔记

2018-01-29  本文已影响0人  蒋胖子胖

对应项目地址为:https://github.com/jiangcaijun/spring_cloud_example

该项目的 README 已同步到简书:https://www.jianshu.com/p/def752208f6c

最新项目结构

├── spring_cloud_example
│   ├── zeus_eureka_server          //注册中心 eureka 的 client 端         
│   ├── zeus_eureka_client          //注册中心 eureka 的 client 端
│   ├── zeus_service_ribbon         //服务消费 ribbon            
│   ├── zeus_service_feign          //服务消费 feign
│   ├── zeus_hystric                //断路器 hystric 的 熔断机制
│   ├── zeus_zuul                   //路由网关 zuul 的 请求分发
│   ├── zeus_config_server          //配置中心 config 的 server 端
│   ├── zeus_config_client          //配置中心 config 的 client 端
│   ├── zeus_config_eureka_server   //配置中心 config 的 server 端的微服务化(利用eureka)
│   └── README.md

1. 参考链接

2. 疑问与解决

1. 疑问1

参考链接:

2. 疑问2

解答:

参考链接:

3.知识点

1.eureka

参考链接:

4.框架搭建进度

1. eureka 服务的注册与发现(2017年11月18号)

eureka server(port:8761) 和 eureka client(port:8762) 启动后,实现服务的注册与发现,如下图:


1.1.png 1.2.png

2. 服务消费者(rest+ribbon)(2017年11月19号)

接上节,利用rest+ribbon,实现负载均衡,访问了不同的端口的服务实例。


2.1.png 2.2.png

此时的架构,如下:

2.3.png

3. 服务消费者(Feign)(2017年11月19号)

接上节,利用feign,实现负载均衡,访问了不同的端口的服务实例。

3.1.png 3.2.png

4. 断路器(Hystric)(2017年11月28号)

4.1 在ribbon使用断路器

hystric(8764)的service层代码如下:

/**
 * 通过之前注入ioc容器的restTemplate来消费service-hi服务的“/hi”接口,
 * 在这里我们直接用的程序名替代了具体的url地址,在ribbon中它会根据服务名来选择具体的服务实例,根据服务实例在请求的时候会用具体的url替换掉服务名
 * @param name
 * @return
 */
@Override
@HystrixCommand(fallbackMethod = "hiError") //该注解对该方法创建了熔断器的功能,并指定了fallbackMethod熔断方法
public String hiService(String name) {
    return restTemplate.getForObject("http://SERVICE-HI/hi?name="+name,String.class);
}

@Override
public String hiError(String name) {
    return "hi,"+name+",sorry,error!";
}

依次启动eureka_server(8761)、eureka_client(8762)、hystric(8764),访问:http://localhost:8764/hi?name=dd,如下图:

4.1.png

将eureka_client(8762)项目停掉,再次访问该页面:

4.2.png

证明:eureka_client(8762) 工程不可用的时候,hystric(8764)调用eureka_client(8762)的API接口时,会执行快速失败,直接返回一组字符串,而不是等待响应超时,这很好的控制了容器的线程阻塞。

5. zuul (2017年12月27号)

zuul 主要功能 路由转发和过滤器

5.1.png

现象(路由转发):

5.2.png 5.3.png

6. 配置中心(config from git)(2018年01月20号)

6.1.png

ZeusConfigServerApplication: config 的 server 端
ZeusConfigClientApplication: config 的 client 端
注意:关于config client 端,使用bootstrap.properties 是因为:bootstrap.properties的加载是先于application.properties

注意:

Spring Boot中application.yml与bootstrap.yml的区别(转)
说明:其实yml和properties文件是一样的原理,主要是说明application和bootstrap的加载顺序。且一个项目上要么yml或者properties,二选一的存在。
Bootstrap.yml(bootstrap.properties)在application.yml(application.properties)之前加载,就像application.yml一样,但是用于应用程序上下文的引导阶段。它通常用于“使用Spring Cloud Config Server时,应在bootstrap.yml中指定spring.application.name和spring.cloud.config.server.git.uri”以及一些加密/解密信息。技术上,bootstrap.yml由父Spring ApplicationContext加载。父ApplicationContext被加载到使用application.yml的之前。
例如,当使用Spring Cloud时,通常从服务器加载“real”配置数据。为了获取URL(和其他连接配置,如密码等),您需要一个较早的或“bootstrap”配置。因此,您将配置服务器属性放在bootstrap.yml中,该属性用于加载实际配置数据(通常覆盖application.yml [如果存在]中的内容)。

访问配置信息的URL与配置文件的映射关系如下:

启动 server 端后,访问:http://localhost:8888/config-client/dev ,如下图所示:

6.2.png 6.3.png

再启动 client 端 ,访问: http://localhost:8881/hi ,如下图所示:

6.4.png

证明: config-client从config-server获取了foo的属性,而config-server是从git仓库读取的,

当前架构,如图:

6.5.png

7. 高可用配置中心(config 与 eureka)(2018年01月25号)

7.1.png 7.2.png

访问: http://localhost:8881/hi ,如下图所示:

7.3.png

当前架构,如图:

7.4.png
上一篇下一篇

猜你喜欢

热点阅读