《微服务架构实战》读书笔记之SpringCloud其他框架二

《微服务架构实战》读书笔记之SpringCloud其他框架

Springcloud Security

Spring Cloud Security提供了一组原语，用于构建安全的应用程序和服务，而且操作简便。可以在外部（或集中）进行大量配置的声明性模型有助于实现大型协作的远程组件系统，通常具有***身份管理服务。它也非常易于在Cloud Foundry等服务平台中使用。在Spring Boot和Spring Security OAuth2的基础上，可以快速创建实现常见模式的系统，如单点登录，令牌中继和令牌交换。

功能：

从Zuul***中的前端到后端服务中继SSO令牌
资源服务器之间的中继令牌
使Feign客户端表现得像OAuth2RestTemplate（获取令牌等）的拦截器

在Zuul***中配置下游身份验证

Http Basic Authentication

在你访问一个需要HTTP Basic Authentication的URL的时候，如果你没有提供用户名和密码，服务器就会返回401，如果你直接在浏览器中打开，浏览器会提示你输入用户名和密码(google浏览器不会，bug？)。
要在发送请求的时候添加HTTP Basic Authentication认证信息到请求中，有两种方法：
一是在请求头中添加Authorization：Authorization: "Basic 用户名和密码的base64加密字符串"
二是在url中添加用户名和密码

JWT

JWT（JSON WEB TOKEN）：JSON网络令牌，JWT是一个轻便的安全跨平台传输格式，定义了一个紧凑的自包含的方式在不同实体之间安全传输信息（JSON格式）。它是在Web环境下两个实体之间传输数据的一项标准。实际上传输的就是一个字符串。广义上讲JWT是一个标准的名称；狭义上JWT指的就是用来传递的那个token字符串

JWT的数据结构以及签发的过程
JWT由三部分构成：header（头部）、payload（载荷）和signature（签名）。

Header 头部信息：指定类型和算法
Payload 荷载信息：存放Claims声明信息
Signature 签名：把前两者对应的Json结构进行base64url编码之后的字符串拼接起来和密钥放一起加密后的签名
组成方式为 header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiLlvKDlvLoiLCJuYW1lIjoiNzg5IiwiZXhwIjoxNTI4MzY0MjU5LCJpYXQiOjE1MjgzNjMwNTl9.574koY-c9SqMNNzfvAWQuKEnimWeZAcoFQ5XudNWF3o

Header的结构

type 声明类型
algorithm 声明加密算法
格式： {“typ”: “JWT”,“alg”: “HS256”}

payload的结构

声明信息
payload用来承载要传递的数据，它的json结构实际上是对JWT要传递的数据的声明，这些声明被JWT标准称为claims（声明），它的每个属性键值对其实就是一个claim，JWT常用的有两种声明，一种是Reserved claims（保留声明），也就是JWT规定的标准声明。
一种是Private claims（自定义声明），我们在这里定义要传递的信息
还有一种是public claims（公共声明），这个目前没用到。
```
    格式： {"name": "value","id": "value2"}
```
1
标准声明（JWT保留声明）
•iss(Issuser)：代表这个JWT的签发主体；
•sub(Subject)：代表这个JWT的主体，即它的所有人；
•aud(Audience)：代表这个JWT的接收对象；
•exp(Expiration time)：是一个时间戳，代表这个JWT的过期时间；
•nbf(Not Before)：是一个时间戳，代表这个JWT生效的开始时间，意味着在这个时间之前验证JWT是会失败的；
•iat(Issued at)：是一个时间戳，代表这个JWT的签发时间；
•jti(JWT ID)：是JWT的唯一标识。

signature

签名
把header和payload对应的json结构进行base64url编码之后得到的字符串用点号拼接起来，然后根据header里面alg指定的签名算法生成出来的，然后添加自己设定的key进行加密签名
添加：
.sign(Algorithm.HMAC256(Key))

OAuth2

OAuth2 角色设定
Oauth2定义了4种角色
resource owner 资源拥有者
指的是一个可以授权访问被保护资源的个体,例如一个个实体用户，他们的用户信息就是资源。

resource server 资源服务器
指的是用来托管受保护的资源,例如某个具体具体服务模块

client 客户端
指的是利用资源拥有者的授权信息去请求被保护的资源的各种第三方服务,例如第三方服务机构

authorization server 授权服务器
在资源拥有者授权后,向客户端授权(颁发 access,tokens)的服务器,例如支付宝验证登陆
资源服务器与授权服务器之间的交互是属于被访问者自己内部的事情，资源服务器与授权服务器可以是同一个。对于支付宝来说，一个授权服务器,可以向多个资源服务器颁发acess token服务

OAuth2 授权流程
step 1:客户端预先在授权服务器上注册,获得app_id
step 2:资源拥有者向客户端请求访问
step 3:客户端需要对该资源拥有者进行身份验证,遂重定向至授权服务器
step 4:在授权服务器上,资源拥有者同意给予客户端授权AuthorizationCode
step 5:资源服务器重定向至客户端并向客户端提供授权AuthorizationCode
step 6:客户端使用上一步获得的授权AuthorizationCode和自己的app_id,向授权服务器申请令牌access token
step 7:授权服务器对客户端进行认证后,同意发放令牌access token.
step 8:客户端使用令牌access token,向资源服务器申请资源.
step 9:资源服务器确认令牌,并向客户端开放资源.

以上是详细过程,其中step 1,6,7,8,9对于资源拥有者是不可见的,仅从资源拥有者角度分析:
(A)用户打开客户端
(B)被重定向至资源服务器，选择使用资源服务器提供的授权方式授权.
(C)重定向至客户端并携带AuthorizationCode操作

上面两步也是自动完成的,客户端和资源服务器会将需要重定向的url放置在Location中,资源拥有者可以抓包获取.

Spring Cloud Data Flow

1.Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL,批量运算和持续运算的统一编程模型和托管服务。
2.对于在现代运行环境中可组合的微服务程序来说,spring cloud data flow是一个原生云可编配的服务。使用spring cloud data flow,开发者可以为像数据抽取,实时分析,和数据导入/导出这种常见用例创建和编配数据通道 (data pipelines)。
3.Spring cloud data flow 是基于原生云对 spring XD的重新设计,该项目目标是简化大数据应用的开发。 Spring XD 的流处理和批处理模块的重构分别是基于 spring boot的stream 和 task/batch 的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等现代运行环境。
4.Spring cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。

SpringCloudStream

SpringCloudStream 就是使用了基于消息系统的微服务处理架构。对于消息系统而言一共分为两类：基于应用标准的 JMS、基于协议标准的 AMQP，在整个 SpringCloud 之中支持有 RabbitMQ、Kafka 组件的消息系统。利用 SpringCloudStream 可以实现更加方便的消息系统的整合处理，但是推荐还是基于 RabbitMQ 实现会更好一些。

为什么 SpringCloud 中要提供有一个类似于消息驱动的 SpringCloudStream 呢？

如果通过 Java 历史上的分布式的开发架构大家不难发现，对于消息系统，实际上最初的 SUN 公司是非常看中的，所以在 EJB 的时代里面专门提供有消息驱动 Bean（Message Driven Bean、MDB）利用消息驱动 Bean 可以进行消息的处理操作。利用消息驱动 bean 的模式可以简化用户的操作复杂度，直接传递一些各类的数据即可实现业务的处理操作。

于是在 SpringBoot 的之中为了方便开发者去整合消息组件，也提供有一系列的处理支持，但是如果按照这些方式来在 SpringCloud 之中进行消息处理，有些人会认为比较麻烦，所以在 SpringCloud 里面将消息整合的处理操作进行了进一步的抽象操作，实现了更加简化的消息处理。

总结：SpringCloudStream 就是实现了 MDB 功能，同时可以更加简化方便的整合消息组件。

#笔记##读书笔记#