• 分布式：一个业务分拆多个子业务，部署在不同的服务器上
  • 集群：同一个业务，部署在多个服务器上
  • 微服务：是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

1：分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。
分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
通过实现WebMvcConfigurer，并重写addInterceptors方法，来实现（实现HandlerInterceptor的）自定义拦截器
image.pngimage.png
具体实现：业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样每个子业务如果出了问题，整个系统完全不会受影响
一、在加入购物车、结账等操作之前，需要登录，得加入登录功能，这个登录功能不能只是去会员服务里面，按照会员的账号密码去查会员信息就算登录了，后面还会加入复杂的社交登录以及单点登录功能。特别是在分布式系统以及微服务模式开发中，如下的架构图中，有个认证中心，就是来处理登录注册功能，特别是登录功能，以后凡是要请求需要登录的都应该由认证中心来统一进行认证 ，如果登录成功认证通过了，才可以访问其他微服务，来执行相应的功能
image.png
发送一个请求直接跳转到一个页面，SpringMVC viewController:将请求和页面映射过去

MD5%MD5盐值加密：

通过爆破，得到我们的账户和密码，存明文肯定有问题，存密文，存什么样的？（1）可逆加密；（2）不可逆加密-通过密文推断不出密码。所以密码字段需要通过不可逆加密，防止被爆破。
推荐使用MD5加密，其实不算一个加密算法，而是如下信息摘要算法
image.png
MD5使用场景：
百度网盘有个秒传功能：百度网盘在上传文件之前，对文件进行MD5加密处理，算出值，如果这个文件以前上传过或者别人上传过，而且MD5的强抗碰撞，只要这个文件的内容不变，这个MD5值永远都不变，几乎不会有两个相同的MD5值，所以秒传就利用了这个特点，上传了这个文件，去百度的数据库进行匹配，看是否有文件与之匹配，匹配成功了，就不用传了，达到了秒传的效果。
MD5可能出现的问题：暴力破解
image.png
针对MD5的抗修改性，生成彩虹表，比如123456对应MD5值，只要你的MD5值与之相匹配，就可以得到你的密码是123456.所以MD5不能直接用来作为密码的加密存储。
所以有了盐值加密：比较贴合实际的例子：有一头牛，送给了屠宰场，屠宰场把牛杀了，把牛肉交给我们，但是与此同时，也杀了无数头牛，但是你能指出一盘牛肉说是哪一头牛的呢；所以MD5是消息摘要，会损失元数据，所以不能通过最终的MD5值推断出原数据。所以不能用MD5存储，会被暴力破解。
盐值加密：传密文+盐值，所有人吃的饭都是一样的，随机的加一把盐，就都不一样了
所以，123456+盐值（可以是随机值，也可以是时间戳）进行MD5加密，就不容易被破解了。在数据库中增加时间戳字段，这样就可以验证了。
image.png

社交登录之OAuth2.0

image.pngimage.png
第三方应用想用微信、微博信息进行登录，所以第三方应用是客户端，想要微信、微博服务器要微信、微博的账号信息登录进去第三方应用的网站。
1、向用户申请请求认证， csdn等第三方应用向用户请求认证，用户需要授权（输入密码或者扫描），账号密码登录的肯定是QQ服务器，验证后，继续到认证服务器（QQ服务器）认证,QQ服务器给第三方应用返回一个访问令牌（唯一的）
image.png
CSDN服务器就可以拿着这个code令牌（令牌关联了登录的QQ账号）,去QQ服务器查当前用户QQ信息（头像、昵称等受保护信息），
image.pngimage.png通过code令牌，获取access_token
image.png
再通过access_token获取用户可获得的信息。
使用Code换取access_token（有有效期），code只能使用一次。下次重新授权以后再使用使用Code换取access_token。image.pngimage.png
获取用户可获得的信息后，如果当前用户是第一次登陆进来，自动注册进来

得到社交用户信息以后，想在www.gulimail.com页面也能获得这些社交用户信息，该如何？

单体应用时代，最常用的方式，跨页面共享数据，可以用Httpsession
（原生api），在整个回话期间，从打开这个页面开始到结束，session里面放的数据在任何页面都可以共享

image.png

分布式情况下，session共享问题

不同域名(服务)不能共享session

同一个服务部署在不同的服务器上session也不相同

1、session就是服务器里面的一个内存数据，当成一个Map,每一个访问这个服务器的人都被生成一个Map被sessionManager（session管理器）管理着；
2、命令浏览器保存一个cookic，类似于去银行办银行卡，第一次去办，需要办张银行卡，以后就带着银行卡就可以操作了。浏览器收到这个session保存的cookic，以后浏览器访问这个网站都会带上这个cookic（类似于特定银行的银行卡）————————————————-session不能跨不同域名共享，即cookic不能被auth.gulimail.com和gulimail.com所共享的
image.png
上面的会员服务不可能部署到一台服务器上面，而是多台服务器都有这个会员服务，以前的session默认是服务器的一片内存空间（类似于一个Map）,浏览器第一次登陆落在了1号服务器上面，登陆成功了，1号服务器保存了用户信息，由于是分布式集群环境，下一次进来的时候可能落在2号服务器上，带了1号发的卡（cookic），不能用了。

出现问题：服务处于集群状态

负载均衡机制下，第一次和第二次访问的可能是同服务的不同地址的服务，session保存在第一个服务里面，而第二个服务没有session

（1）解决方案：session复制

image.png

（2）解决方案：客户端存储

image.png

（3）解决方案：hash一致性（比较推荐）

image.png

（3）解决方案：统一存储（比较推荐）

之前所有问题出现的原因就是浏览器在访问某些服务时，由于负载均衡机制跳到不同的服务器，而session是各自存储在各自的服务器的本地内存中，导致跳到下一个服务器的时候session的数据就用不到了。推荐的方案就是让session统一存储，无论是哪个服务器，哪个tomcat，session不存储在内存中，全部存储在数据库中或者redis（或者其他更快的中间件）中。列如：第一个请求来到第一个服务器，这个服务器想给session存数据，给session卡号为123的，存了456值，把这对数据存储在redis中，第二次负载均衡到第二个服务器时，把卡号123带来了，想要取数据，以前是各自取各自的，取不到了，现在都去redis中存取，所以也能取的出来。这就解决了session共享的问题，下图有优缺点.
image.png

image.png

出现问题：服务处于不同域名状态下

image.png解决方案：springsession

浏览器在会员服务里面登录成功，会员服务会将登录成功的存储在session中，存session的时候，不让存储在自己的内存中，可以让他存储在redis中，接下来给浏览器发卡，session对应的 jsessionid 这个卡，对应的作用域不能只是会员服务，而是放大作用域，作用于gulimail.com,下一次访问任何服务都带上这个cookic的jsessionid,前端一个session的jsessonid去其他服务都通用，解决了session跨域问题

SpringSession整合-session共享问题、子域session共享问题

image.pngimage.pngimage.pngimage.png
自定义SpringSession完成子域共享问题
使用cookic的序列化器，暴露cookic的序列化器（@bean注解）来设置cookic的名称、路径、以及作用域
image.png
image.png

springSession原理
image.png

多系统-单点登录

image.png