进学阁

简介：

在oauth2中授权服务器颁发过令牌后，用户就可以对资源进行访问，这时会有一个问题就是需要验证令牌，而前边文章中令牌使用的jwt格式，所以需要一个统一的资源管理器来验证令牌解析令牌

前言：

先看下认证授权的过程，认证客户端的认证是最先被认证的，只有先认证客户端可会进行token的认证，而我们不应该把客户端的信息暴漏在外面所以客户端的信息只能通过网关转发的时候注入到请求中

简介

在官方的说明中我们可以看到OAuth 2.1 废弃了 OAuth 2.0 中的密码模式，只提供了三种授权类型：授权码、刷新令牌、客户端凭证。

回顾

在集成Oauth2.1认证中心，采用默认的数据结构实现了认证，但是大部分时候默认的用户结构并不能满足生产的需要，所以接下来以RBAC权限设计来实现用户

概念

新版本中的springcloud已经将springcloudoauth2包取消掉，oauth2新增了一个spring-authorization-server的项目，在spring-authorization-server下现在已经有3个可用版本，其中0.3.0对应的是jdk11版本， 0.4.0对应的是jdk8版本，1.0版本对应的是jdk17。以下的实例是以jdk11为例

Pod是Kubernetes的基本部署单元。它由一个或多个共享IP地址和存储卷的容器组成。服务实例的pod通常由单个容器组成，例如运行 JVM 的容器。但在某些情况下，Pod包含一个或多个实现支持功能的 边车（sidecar)容器。 例如，Nginx 服务器可以有一个边车容器，定期执行 git pull 以下载最新版本的网站；微服务中可以通过注入一个filebeat的边车容器负责收集日志。

Pod大家可以简单将其理解成传统基础设施里“虚拟机”的角色；而容器，则是这个虚拟机里运行的用户程序。Pod里的不同容器可以共享存储、网络和命名空间。

什么是service

在使用虚拟机或者裸容器部署应用时，程序之间的互相访问一般是通过宿主机的IP+端口号的形式进行访问，因为宿主机的IP地址一般不会轻易改变，所以用IP+端口的方式并没什么大问题。 但使用Kubernetes部署Pod应用时，Pod会被调度器随机调度至最佳节点，并且会经常删除重建，所以Pod的IP地址并不是一成不变的。 这时候再使用之前的IP+端口的方式就行不通了，所以Service就应运而生。

为什么要使用外置Jenkins

云上部署的项目少或者使用云环境的开发团队少，用原生的方式基本没问题。但随着你上云的项目越来越多和上云的团队越来越多，再使用这种方式一定会碰到这样一个问题： Jenkins的调度时间越来越长，流水线执行越来越慢。 我们甚至出现过执行一个流水线需要等上10分钟才开始调度的情况，极大影响了开发效率。而我们使用云平台还有一个原则，就是要让云平台尽可能的轻量化。基于上述2个原因我们最终选择了将流水线中的CI部分外置，通过外置的Jenkins来实现编译、构建、推送镜像功能，在流水线中只保留持续部署CD的功能。

Kt Connect

Kt Connect是阿里巴巴开源的一款云原生协同开发测试解决方案，目前包含以下几个核心功能，参加官方文档。 https://alibaba.github.io/kt-connect

改造Java程序

在应用中引入监控所需要的jar包，包含prometheus和actuator

1
2
3
4
5
6
7
8
9

<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-starter-actuator</artifactId>  
</dependency>  
  
<dependency>  
    <groupId>io.micrometer</groupId>  
    <artifactId>micrometer-registry-prometheus</artifactId>  
</dependency>

引入这2个包以后就通过prometheus抓取到应用的监控信息