日常分享前端话题
单点登录
简介
单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，
所有的应用系统都不能再直接访问保护资源，
单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。
单点登录在大型网站里使用得非常频繁，例如，阿里旗下有淘宝、天猫、支付宝等网站，还有背后的成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。
所以，单点登录要解决的就是，用户只需要登录一次就可以访问所有相互信任的应用系统。
像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术
实现
客户端:
- 拦截子系统未登录用户请求，跳转至sso认证中心
- 接收并存储sso认证中心发送的令牌
- 与服务器端通信，校验令牌的有效性
- 建立局部会话
- 拦截用户注销请求，向sso认证中心发送注销请求
- 接收sso认证中心发出的注销请求，销毁局部会话
服务器端：
- 验证用户的登录信息
- 创建全局会话
- 创建授权令牌
- 与客户端通信发送令牌
- 校验客户端令牌有效性
- 系统注册
- 接收客户端注销请求，注销所有会话
服务端渲染 SSR
简介
SSR是Server Side Render的简写，意为服务端渲染，指页面或组件渲染在服务端进行，不占用客户端计算，能够快速显示页面及做SEO优化；
服务端渲染是数据与模板组成的HTML，即html=数据+模板。将组件或页面通过服务器生成HTML字符串，再发送到浏览器，最后将静态标记混合为客户端上完全交互的应用程序。页面没使用服务渲染，当请求页面时，返回的Body里为空，之后执行JavaScript将HTML结构注入到Body内，结合Css显示出来。
SSR 渲染优势
- SEO优化更好
- 所有模板、图片等资源存储在服务端
- HTML会返回所有的数据
- 减少HTTP请求
- 响应快、用户体验好、受屏渲染快
SSR 劣势
- 服务端压力较大
本来是通过客户端完成渲染，现在统一到服务端
node服务去做。尤其是高并发访问的情况，会大量占用服务端CPU资源；
- 开发环境受限
服务端渲染中，只会执行到
componentDidMount之前的生命周期钩子，因此醒目引用的第三方的库也不可用其他生命周期钩子，这对引用库的选择产生了很大的限制
- 学习成本相对较高
除了对
webpack、MVVM框架要熟悉，还需要掌握node、Koa2等相关技术。相当于客户端渲染，项目构建、部署过程更加复杂
- 并且构建相对纯客户端CSR渲染较为复杂
微服务
微服务
微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。
这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
什么是单体架构
在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，
业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。
单体架构存在的不足
在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。
用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。
这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。
如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构。
redux 的设计思想
分析
在JQuery时代的时候，我们是面向过程开发，随着react的普及，他们提出状态驱动UI的开发模式。我们认为：Web应用就是状态与UI一一对应的关系。但是随着我们的web应用日趋的复杂化，一个应用所对应的背后的state也变得越来越难以管理。而redux就是web应用的一个状态管理方案。Redux是Flux思想的一种实现，同时又在其基础上做了改进。其主要体现在：
-
单向数据流
-
Store是唯一的数据源
Redux 三大原则
-
单一数据源
-
State只读 -
使用纯函数来修改
例子
- 1、 Store（快递公司）
Store 可以看成是一个容器，整个应用只能有一个 Store ，就好比整个应用只能指定京东快递公司来运货。
import {createStore, combineReducers, applyMiddleware} from 'redux';
const store = createStore(reducer);
- 2、 State （快递物件）
State：一状态下的数据，一时间点下的数据。Store对象包含所有数据，想要得到某个时间点的数据，就要
对Store生成快照，得到一个数据集合，就叫做state。 store.getState()可以得到state。
Redux规定一个State对应一个View，反之亦然。 就好比一个快递物件只能给对应的主人，不能给其他人。
import {createStore, combineReducers, applyMiddleware} from 'redux';
const store = createStore(reducer);
store.getState()
- 3、Action （快递单）
买家要买东西怎么办，当然要先下单啦。用户只能操作
View（比如对view进行点击），用户是接触不到State的，
那State的变化对应View的变化，这就需要View通过一个Action对象来通知State的变化。就好比通过一个
快递下单（发送一个Action），才有接下去的物流等一系列操作不是吗。
Action是一个自定义对象，其中type属性是必现的
cost action = {
type:'btnClick',
msg:'信息字符串，不是必现'
}
- 4、store.dispatch() (给快递公司货单)
store.dispatch()是view发出Action的唯一方法，store.dispatch()接受一个Action对象，将他发出去。
现在还没发货，只是把订单信息给京东快递而已，京东是自营企业，有自己的物流仓库和物流中心，搜到订单信息
再根据订单来发货。
store.dispatch(action);
5、Reducer （包装货物）
Store收到一个Action后，必须给出一个新的State，这样view才会发生变化，而新的State的计算过程就是
Reducer来完成的。
就想收到一个订单（Action）后，需要根据订单来选取货物，进行包装。
Reducer是一个自定义函数，它接受Action和当前的State作为参赛，返回一个新的State
const reducer = (state = defaultState, action) => {
switch (action.type) {
case 'btnClick' :
return state + action.msg +'更新';
case '其他type':
return state + ‘其他action.msg’;
/*
可添加更多的 case type 来匹配不同的Action
*/
default:
return state;
}
}
接下来 我们把这套处理订单的规则（Reducer）给快递公司（Store），以后有订单只需要根据这套规则来发货就行了
import { createStore } from 'redux';
// store.dispatch 方法会触发 Reducer 的自动执行
const store = createStore(reducer);
也许你会疑问那需要发送不同的 Action怎么办 ，没错就是增加订单规则就可以了，往 Reducer 里面增加 case ’type’的规则
- 6、store.subscribe() （接受快递）
当
State一旦发生变化，那么store.subscribe()就会监听到自动执行。 好比收到了快递（秒送，哈哈）
那收到快递能干嘛呢，每错，就是在这里重新渲染View更新View咯。
let unsubscribe = store.subscribe(() =>
console.log(store.getState())
render（）{
更新view ！！！
}
);
// 也可以取消订阅（监听）
unsubscribe();
♥关注小佑带你带你了解不一样的前端😄~
评论区