前端部署在外网内，也就是图中左边部分，后端集群部署在内网，当外网客户端通过发送请求后，首先会通过 Nginx 集群，Nginx 集群会对请求进行分流，发送给相应的 SpringCloud Gateway 网关，网关对用户的请求进行认证授权、负载均衡，通过之后则会发送给后端的业务集群，业务集群之间相互调用采用 Feign，有些业务需要通过认证之后才能进行，所以这里用到了 OAuth2.0 进行权限验证，

1.微服务

拒绝大型单体引用，基于业务边界进行服务微化拆分，各个服务独立部署运行，,每个服务之间相互调用

例如：订单服务 -》商品服务 -》仓库服务

2.集群

例如：京东就是一个分布式系统，众多业务运行在不同的机器上，所有业务构成了一个大型的业务集群。
集群是一个物理形态，分布式是一个工作方式
分布式的每一个结点，都可以做集群，而集群并不一定就是分布式的
结点：集群中一个服务器

redis是一个key-value型存储系统，支持的value类型比较丰富，支持String、List、集合set（没有顺序，元素唯一）、有序集合Zset，都支持push、pop、add、remove、交并集等操作，这些操作都是原子性的，调用redis的操作不用考虑多进程之间的并发问题。在此基础上，redis支持各种方式的排序，为了保证效率，数据都是缓存在内存中的，区别在于：redis会周期性的把更新的数据写到磁盘或者修改操作追加的记录文件中，前者就是默认的RDD模式，就是把数据写到临时文件中，持久化结束后，把临时文件替换为上次持久化的文件，达到数据恢复的目的，优点在于：使用单独子进程进行持久化，主进程不会进行任何IO操作，保证了redis的高效性能，缺点在于RDD是间隔一段时间进行持久化，如果持久化间隔期间，redis发生故障，那么这个持久化就不会更新到磁盘中，就会发生数据的丢失。

二维码其实就是一个比特的矩阵，这个比特矩阵存储的是一个url，当二维码扫描时就会自动打开其中存储的url给服务器，这个url可能会通过GET方式给服务器传递一个扫码者的信息，服务器接收到请求后，将GET信息获取到进行处理就会返回一些页面给扫码者

背景需求

在项目中，店铺授权二维码为扫码者申请扫码权限，需要首先获取到扫码者的个人信息，才能进行授权，为了获取扫码者的个人信息，这里我们使用微信测试号回传用户信息的url，如下所示

https://open.weixin.qq.com/connect/oauth2/authorize?appid=wx6d9e79f7e8844954&redirect_uri=http://81.70.249.115/o2o/shopadmin/addshopauthmap&role_type=1&response_type=code&scope=snsapi_userinfo&state=2#wechat_redirect

• appid字段：是申请微信测试号给予的appid开发者字段以及一个密匙secret（后面在获取用户信息会使用secret字段进行校验）
• redirect_uri字段：就是我们web应用接收微信回传个人信息的url
• state字段：可以自定义一些业务逻辑需要的一些信息，例如店铺授权需要知道往哪个店铺进行授权，需要知道店铺id，例如知晓二维码是否过期，封装createTime二维码的创建时间

扫码者打开微信扫描二维码时，就会访问这个url，微信就会将扫码者的信息传回给指定的redirect_uri，这个uri就可以通过code、accessToken、openId来获取用户的信息（这其中会涉及到多次二次验证），我们通过获取openId与数据库中的表tb_wechat_auth中查找该openId是否已经注册过，如果未注册就抓取其信息进行注册。