eureka  注册 尤里卡  优瑞卡   SpringCloud之服务注册与发现Eureka 

Eureka是Spring Cloud Netflix微服务套件中的一部分,可以与Springboot构建的微服务很容易的整合起来。
Eureka包含了服务器端和客户端组件。服务器端,也被称作是服务注册中心,用于提供服务的注册与发现。Eureka支持高可用的配置,当集群中有分片出现故障时,Eureka就会转入自动保护模式,它允许分片故障期间继续提供服务的发现和注册,当故障分片恢复正常时,集群中其他分片会把他们的状态再次同步回来。
客户端组件包含服务消费者与服务生产者。在应用程序运行时,Eureka客户端向注册中心注册自身提供的服务并周期性的发送心跳来更新它的服务租约。同时也可以从服务端查询当前注册的服务信息并把他们缓存到本地并周期性的刷新服务状态。

config 配置 看飞哥  Spring Cloud之——Config(配置中心)

目前SpringCloud Config的使用主要是通过Git/SVN方式做一个配置中心,然后每个服务从其中获取自身配置所需的参数。SpringCloud Config也支持本地参数配置的获取。如果使用本地存储的方式,在 application.properties 或 application.yml 文件添加 spring.profiles.active=native 配置即可,它会从项目的 resources路径下读取配置文件。如果是读取指定的配置文件,那么可以使用 spring.cloud.config.server.native.searchLocations = file:D:/properties/ 来读取。
 

auth    授权  啊四  SpringCloud(七):搭建OAuth2认证授权服务

为了保证服务对外的安全性,往往都会在服务接口采用权限校验机制,为了防止客户端在发起请求中途被篡改数据等安全方面的考虑,还会有一些签名校验的机制。
在分布式微服务架构的系统中,我们把原本复杂的系统业务拆分成了若干个独立的微服务应用,我们不得不在每个微服务中都实现这样一套校验逻辑,这样就会有很多的代码和功能冗余,随着服务的扩大和业务需求的复杂度不断变化,修改校验逻辑变得相当麻烦,一处改,处处改。所以我们需要把认证授权服务单独出来,做成一个服务进行调用。

 

gateway  网关  给特围  使用springcloud gateway搭建网关(分流,限流,熔断) &Spring Cloud Gateway 整合Eureka路由转发

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。

相关概念:

  1. Route(路由):这是网关的基本构建块。它由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配。
  2. Predicate(断言):这是一个 Java 8 的 Predicate。输入类型是一个 ServerWebExchange。我们可以使用它来匹配来自 HTTP 请求的任何内容,例如 headers 或参数。
  3. Filter(过滤器):这是org.springframework.cloud.gateway.filter.GatewayFilter的实例,我们可以使用它修改请求和响应。

admin 管理  springCloud--admin监控

Spring Boot提供的监控接口,例如:/health、/info等等,实际上除了之前提到的信息,还有其他信息业需要监控:当前处于活跃状态的会话数量、当前应用的并发数、延迟以及其他度量信息。下面我们来了解如何使用spring-boot-admin来监控我们的系统。

upms 系统管理 amd cmd fedR hjrG  公司有八个服务

这五个应用是大cloud的核心运营组件部分,外围可以再次运行很多应用

 

Docker部署Spring cloud微服务  && SpringCloud + Docker 自动构建微服务容器

目前最流行的java开发方式就是Spring Boot和Spring Cloud应该不为过。Spring Boot进一步加强了“约定大于配置”这一Spring的中心思想,使得我们开发人员能够更快捷,更便利的开发Spring项目,也使得开发java web变得不再那么费劲。而Spring Cloud的出现更是让我们项目的开发有了更多的选择,Spring Cloud集成并封装netfix中的ribbon,eureka,hystrix,feign和zull等十分出色的项目,为我们提供了服务注册与发现,客户端的负载均衡和路由分发等功能,为现在的大部分中小企业开发分布式架构提供了一整套的解决方案,大大提高了工作效率,个人认为Spring Cloud在未来一定会像Spring一样的出色。而Docker的出现让容器化技术得以普及,更快的部署和维护与Spring Cloud的结合,能让我们不再像以前一样为了某一个模块的增加而服务器上大动干戈,还需要考虑环境的问题,现在只需要一句docker start .....便可轻松实现服务的扩展。

 

undertow 安得特 使用这个小红帽的组件,就可以替代tomcat,新的应用服务器

springSecurity安全框架

一个能够为基于Spring的企业应用系统提供声明式的安全訪问控制解决方式的安全框架(简单说是对访问权限进行控制嘛),应用的安全性包括用户认证(Authentication)和用户授权(Authorization)两个部分。用户认证指的是验证某个用户是否为系统中的合法主体,也就是说用户能否访问该系统。用户认证一般要求用户提供用户名和密码。系统通过校验用户名和密码来完成认证过程。用户授权指的是验证某个用户是否有权限执行某个操作。在一个系统中,不同用户所具有的权限是不同的。比如对一个文件来说,有的用户只能进行读取,而有的用户可以进行修改。一般来说,系统会为不同的用户分配不同的角色,而每个角色则对应一系列的权限。   spring security的主要核心功能为 认证和授权,所有的架构也是基于这两个核心功能去实现的。

众所周知 想要对对Web资源进行保护,最好的办法莫过于Filter,要想对方法调用进行保护,最好的办法莫过于AOP。所以springSecurity在我们进行用户认证以及授予权限的时候,通过各种各样的拦截器来控制权限的访问,从而实现安全。

 

微服务下session保存一致性

spring cloud:模块_Cloud

 

简单说一下session和session一致性。服务为访问他的用户构造了一组信息,称之为会话(session),当该用户在限定时间内每次发起http访问时,服务端能自动感知到是该用户在发起访问,称之为会话保持(session一致性)

2.1、IP哈希

使用反向代理(nginx),对用户的IP进行hash操作,确保唯一IP地址每次都访问一个相同的服务。

2.2、Session复制

把每个用户的session都同步复制到集群中的每一个服务节点,这样无论用户访问哪个服务节点,都能获取到自己的session信息。

2.3、Session客户端存储

把session信息保存到客户端的cookie中。

2.4、Session分布式存储

把session信息保存到后端的其它存储中,例如mysql,redis,memcached等。

 

微服务下事件保存一致性: 可靠事件,补偿模式, TCC

http://www.360doc.com/content/17/1116/22/16915_704486258.shtml

 

消息队列:消息中间件 ActiveMQ,RabbitMQ   http://developer.51cto.com/art/201904/595020.htm

系统可用性降低:你想啊,本来其他系统只要运行好好的,那你的系统就是正常的。现在你非要加个消息队列进去,那消息队列挂了,你的系统不是呵呵了。因此,系统可用性降低

系统复杂性增加:要多考虑很多方面的问题,比如一致性问题、如何保证消息不被重复消费,如何保证保证消息可靠传输。因此,需要考虑的东西更多,系统复杂性增大。

RabbitMQ:基于erlang开发,所以并发能力很强,性能极其好,延时很低;管理界面较丰富。中小型软件公司,建议选RabbitMQ.一方面,erlang语言天生具备高并发的特性,而且他的管理界面用起来十分方便

  1.  把数据放到消息队列叫做生产者
  2.  从消息队列里边取数据叫做消费者
  3. 生产者把消息放入队列,消费者获得消息

队列是一种先进先出的数据结构。

系统A将userId写到消息队列中,系统C和系统D从消息队列中拿数据。这样有什么好处?

  1.  系统A只负责把数据写到队列中,谁想要或不想要这个数据(消息),系统A一点都不关心。
  2.  即便现在系统D不想要userId这个数据了,系统B又突然想要userId这个数据了,都跟系统A无关,系统A一点代码都不用改。
  3.  系统D拿userId不再经过系统A,而是从消息队列里边拿。系统D即便挂了或者请求超时,都跟系统A无关,只跟消息队列有关。

这样一来,系统A与系统B、C、D都解耦了