*time.geekbang.org/course/deta… 课程笔记
课程和背景介绍
课程重点是：微服务和云原生架构，运用Spring boot 和 kubernetes。_________________________________________________________________________________________________
基于JWT的无状态认证机制。登录认证职责由WWW认证服务承担，如果用户名密码校验通过，WWW服务会生成一个JWT并传给浏览器，浏览器会储存JWT至cookie中，同时WWW会发送一个301跳转请求，会根据角色的不同跳转至不同的home页面。
只有用户的每一个请求，都会带着cookie➕JWT，Faraday网关会截获请求并解析JWT，如果通过了JWT校验，Faraday网关会把请求转发到相关的微服务。JWT的失效的原因是JWT自动过期，或者用户自动登出（清除浏览器中的cookie）.
服务间调用鉴权
在用feign调用另一个服务的时候，需要再传一个request header，带着auth的信息，在服务方姐收到请求之后，需要根据@Authorise注解中定义的所需权限，查看传过来的header中是否含有相应的权限。
网络安全认证架构演进
V1版本：用户在浏览器发起login请求，带有账户名密码，服务器做auth认证，如果通过，会把当前的sessionId和user绑定，并分配一个过期时间，之后把sessionId放到cookie中传给浏览器，之后浏览器对这个站点的访问都会带有这个cookie
V1.1版本：微服务系统中，每个服务器会有多个实例，但是只有绑定了sessionId的服务器会有储存这个sessionId，所以，负载均衡会记录存有浏览器sessionId的那台实例，并在每次请求转发时导向它。就是sticky session
V1.5版本：sessionId的信息持久化在redis中，所以每台服务器实例都能知道sessionId的信息
V3.0版本：所有消费方先去Auth Service 申请一个token，之后所有的请求都带着这个token，服务方收到请求后，会向Auth Service 做token的校验，并获得用户信息
V3.5版本：由网关接收所有消费方发来的请求，并访问Auth Service做校验，获得用户信息后，将信息用户信息附加到原本的请求上，一同发送给服务方
V3.6版本：消费方在login(向Auth Service发送登陆请求)时，直接申请到JWT，是携带了用户信息的，然后直接把JWT通过网关，传给服务方
参考权限模型
关键信息就是User可以注册多个APP，每个APP绑定了多种Role，当用户绑定了某个App后，他就可以拥有多个此app的role。之后，当每个用户登陆的时候，再经过Auth Service之后，再去RBAC Service (Role-based access control)去获取这个用户的Role，之后把role的信息一起放到JWT中返回。
微服务测试的分类
可以分为：单元测试，集成测试，和组件测试。
单元测试：后端的用mockmvc测试controller层，用h2测试repo层都属于单元测试
集成测试：测与三方依赖的点，比如数据库，调用的其他服务等。
组件测试：把整个服务当作一个组件来测，可以mock掉对其他服务的依赖，这里的mock可以用wiremock
其他类型的测试：
契约测试：微服务之间对接口的定义，消费方和提供方会有一个接口的契约，如果规模较大的微服务可以采用契约测试
端到端(End to End test)：将整个系统当作一个黑盒，会包含所有的微服务模块，测试端到端的稳定性。测试工具如selemnium。最佳实践：80/20原则，聚焦核心业务。
测试金字塔：
从金字塔的底端到顶端，测试的数量变少，粒度变粗，覆盖面增加，稳定性降低，测试变慢。
_________________________________________________________________________________________________
cover了课程第五章和第六章的内容
