|NO.Z.00403|——————————|CloudNative|——|KuberNetes&CI/CD.V41|——|Jenkins.v07|SpringCloud_Eureka.v01|

一、SpringCloud架构解析

### --- 传统架构说明

~~~     在未使用SpringCloud架构之前，传统架构是
~~~     假设有3个微服务A服务、B服务、C服务：后端服务：java应用或者其它应用
~~~     3个微服务有一个前端用于展示Frontend：nginx、Apache或者其它web

~~~     # a服务调用b服务调用方式：
~~~     一般很少使用IP地址+端口号，一般是在nginx上配置一个路由

~~~     # 路由：
~~~     XXX.com/serviceB；a服务或者b服务调用b服务都是使用xxx.com/serviceB来调用

~~~     这个前端有可能是前端的角色，或者有可能是单独的反代
~~~     浏览器访问前端请求根路径，肯定是先到前端；
~~~     浏览器访问有可能是调用前端，也有可能调用后端
~~~     可能是通过某个路由调用到后端的服务比如serviceb
~~~     若是调用serviceA；通过前端xxx.com/serviceA来调用

~~~     # 若是service有多个实例：

~~~     需要在nginx上再加入一个serial，把这个实例加入进去，serviceB也是同理
~~~     这样nginx前端不可能不是有一个，应该是多个，若是一个有可能会出现单点故障

~~~     # 问题一：
~~~     若是多个nginx，就需要用到文件共享，比如NFS去实现。
~~~     NFS就会是一个单点，若是NFS挂掉，文件就不可用了

~~~     # 问题二：
~~~     若是使用自动化工具Ansible，去写配置一次性的同步到其他服务器上。
~~~     但是这样就会出现，若是配置文件改错了，文件都同步过去，这样就可能会造成服务不可用
~~~     在没有SpringCloud架构之前，都是使用这种方案来部署的。

二、简单的服务发现console

### --- 简单的服务发现console

~~~     以文件的形式或者console的形式来实现服务发现
~~~     serviceA连接到console上，把自己的信息IP地址端口等告诉console；
~~~     console记录下来。serviceB/C同理之后serviceB若是想要访问serviceA，它就会调用console，
~~~     获取service的地址返回给serviceB，

~~~     serviceB就会从console提供的serviceA的列表中随机的选一条去连接serviceA
~~~     这样就是console返回给serviceB serviceA的多个实例的信息，
~~~     serviceB应该连接serviceA那个实例的地址，需要serviceB在自己的代码中去实现的。
~~~     而且serviceB不知道这2个serviceA是否是正常的。
~~~     若是某一个serviceA挂掉，需要serviceB中代码选择方案来连接轮询等。

三、SpringCloud架构

### --- SpringCloud架构

~~~     # Pivoral公司开发的SpringCloud架构：
~~~     Redis RabbitMQ都是Pivoral公司的。

~~~     # Eureka：服务注册发现
~~~     在服务器或者容器部署一个eureka应用，这个eureka保存着其他应用的地址。是服务发现注册的中心
~~~     serviceA、serviceB注册到eureka中，将自己的信息注册到eureka

~~~     # Eureka拉取形式：
~~~     serviceB需要连接到serviceB，serviceA就会向eureka获取serviceB的连接信息；
~~~     Eureka中插件帮我们实现了负载均衡、容灾机制都帮我们实现，不需要我们使用很多的代码去实现这个逻辑。

~~~     # Eureka推送机制：

~~~     若是添加了serviceA，不会很快同步到其他服务上，当serviceA将信息同步到eureka中，
~~~     eureka就会推送注册表信息到其它服务中。

~~~     # 东西流量：
~~~     服务间的访问被称为东西流量
~~~     # 南北流量：
~~~     前端到后端的访问被称之为南北流量
~~~     # 传统配置：
~~~     Nginx作为入口：访问根路径就到前端，若是调用其他服务serviceA/B/C，
~~~     nginx就会维护一张注册表。来完成信息调用。

### --- 在SpringCloud的解决方案：引入了一个组件：

~~~     # zuul：
~~~     在SpringCloud充当了网关角色；注册到eureka，去获取到其它服务的IP地址+端口，
~~~     内部维护了一张路由表/api/serviceA/B/C；

~~~     # 若是流量访问进来：
~~~     流量入口：访问根：还是到Frontend，做前端页面的展示。zuul提供一个api接口，
~~~     无论访问什么样的服务，直接请求这个/api即可，zuul来自动调度，不用在前端来配置。

~~~     # zuul：
~~~     提供动态路由，监控后端应用是否是正常的，及时上线或者下线。实现灰度发布、蓝度发布，
~~~     相当于一个网站所有后端的前门。

~~~     # ConfigServer：

~~~     SpringCloud配置管理；用来统一管理配置
~~~     serviceA/B启动时需要一个数据库的；统一管理服务配置文件：
~~~     若是serviceA/B/C服务配置文件是一样的，就写一份配置文件即可。
~~~     SpringCloud只针对于java应用的。

Walter Savage Landor:strove with none,for none was worth my strife.Nature I loved and, next to Nature, Art:I warm'd both hands before the fire of life.It sinks, and I am ready to depart

——W.S.Landor