今天完成的事情：
解决 oAuth2授权码模式403报错
任务9深度思考
明天计划的事情：
任务7，8，9总结
准备复盘评审
遇到的问题：
做认证的服务端，我怎么知道code对应的是哪个用户啊？是哪一步做的关联啊？
需要在认证服务端保存这个 code 和 用户的对应关系，然后在JWT中也可以设置增加JWT,添加扩展属性，这当中可以加上用户 id 或用户名等信息，比如微信登录就会返回 openId 和 unionId。
类似下面这种
{
"access_token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"token_type": "bearer",
"refresh_token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"expires_in": 3599,
"scope": "all",
"jwt-ext": "JWT 扩展信息",
"jti": "69dfcc8c-bffb-4b42-a6af-a7b3ee2f25e3"
}
收获：
先定位问题，我是访问的认证服务器，所以和授权码服务器无关，我之前是在授权码下添加了，但是根本就不是这个问题，而是需要在认证服务器修改
WebSecurityConfig的配置
如下，之前把login登录页面注释了，因为之前是采用postman的方式传递参数，并不需要登录，所以把登录页面直接关了：
@Override
protected void configure(HttpSecurity http) throws Exception {
//登录接口
http.formLogin()
.and()
.authorizeRequests()
.antMatchers("/**").permitAll();
// http.authorizeRequests()
// .antMatchers("/**").permitAll();
}
1.重新打开之后，输入用户名和密码
2.跳转页面 localhost:6001/oauth/authorize?client_id=code-client&response_type=code&redirect_uri=http://localhost:6102/client-authcode/login
3.点击授权，注意code,这个 code 参数是为了向认证服务器 /oauth/token 接口请求 access_token ，继续用 REST Client 发送请求
4.解析这个access_token,可以发现和之前的值并无差别
================
================
1.Dubbo提供了哪几种注册中心的方式？Redis和Zookeeper应该用哪一种？
Dubbo的注册中心有Mulicast、Zookeeper、Nacos、Redis、Simple注册中心，官方推荐使用zookeeper
我是没想到redis也能做注册中心的。。。
redis做注册中心，可以看作是一个简单的扩展实现。其核心是基于Redis的过期机制和publish/subscribe能力。
但和zk比起来，redis功能实现会相对困难些，甚至看起来有些蹩脚（如其redis集群策略需要自行从外部保证同步，这恐怕不会是件容易的事，现有的主从，集群方案都完全无法cover其场景。既要保证任意写，又要保证全同步（数据一致性），呵呵）。它需要单独去维护一些心跳、过期类的事务。过多的服务会导致这类工作更加繁重。
选择zookeeper，方便易用，不用自己去维护心跳、过期类的事务。
2.微服务里，什么是注册中心，注册中心最常见的有Zookeeper，Eureka，还有我们自己的Scallop，他们之间的区别是什么？
这里简单介绍一下注册中心的作用：
1.因为微服务众多，所以需要一个服务注册中心来管理众多的微服务。可以理解成大学宿舍管理员下的每把钥匙对应每个房间。
2.主要的作用是，服务的注册和发现，加上一个服务注册后，会定时向注册中心发送一个请求，表明自己可用。
这里找到了一个主流的注册中心对比的图片：
这里简单了解了一下CAP理论：
一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
可以看到Eurekac遵循的是可用性+分隔容忍，然后访问协议是http
而zookeeper遵循的是一致性+可用性，然后访问协议是TCP
以上两点是我觉得它们区别最大的两点
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪
3.Dubbo和Spring Cloud的区别是什么？如果让你来做架构选型，你会选择哪一个微服务体系，原因是什么？
dubbo其实就是一个很好的RPC框架，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而spring cloud是微服务的一整套解决方案，不仅仅有服务的调用，而是一个生态了。
看那个适合目前的业务用那个，springcloud可以快速搭建一个架构，出现的问题比较少。反之，dubbo还需与整合其他的工具来一起使用，服务治理能力非常强，比springcloud更加灵活。
4.什么是微服务，微服务有哪几种实现方案，包含哪几个模块，Spring Cloud分别是怎么实现的？
微服务有以下特点：
1.按照业务来划分成一个服务单元
2.服务之前通过HTTP或者TCP来进行通信
3.自动化部署
4.可以使用不同语言，不同存储技术，服务集中化管理
5.微服务是一个分布式系统
目前我所知道的，spring cloud, Dubbo , spring cloud Alibaba.
包含 服务注册和发现，熔断，负载均衡，网关，分布式追踪，容错，通信，安全等等
5.什么是SOA，什么是SCA，什么是微服务？
SOA（Service-Oriented Architecture）是面向服务的架构，这早在20年前就被提出来了，只不过当时和企业服务总线（ESB）整合在一起，非常的沉重，没有多少人使用。
SOA理解：把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立
SCA（Service Component Architecture）服务组件架构
SCA是基于SOA开发的一个模型规范，它最重要的两点就是组件和传输协议的分离，接口和实现语言的分离
即：1.服务组件能自由绑定各种传输协议，集成其他的组建与服务 2.服务组件实现与语言无关，即不绑定语言Tuscanys是SOA的具体实现。
微服务介绍如之前一个问题所说，微服务是SOA的进一步实现。比ESB实现的SOA更简单，轻快。
spring cloud是微服务的具体实现
6.Spring RMI，Spring Cloud，Tuscany，Dubbo分别是什么，互相之间有哪些不同？
spring RMI: 是对 java RMI的封装，让RMI实现起来更简单
spring cloud: 是微服务的一整套解决方案。
Tuscany: 对SCA的实现，使服务不在关心传输协议和语言
Dubbo: 实现RPC的一个框架，在服务治理能力非常强
7.怎么实现WEB调用Service的负载均衡，怎么实现可以动态添加服务？
在spring cloud中使用 Ribbon可以实现对service的均衡负载。使用Eureka 自动的动态添加服务和注销服务，通过“心跳来实现”
8.公司内部项目里使用的Scallop是什么，和资源中心是怎么结合在一起使用实现动态增加服务的？
没使用过，资料也很少
返回列表
评论