软件体系 思维导图
U425254192
2023-02-06
单点
多点
低代码
树图思维导图提供《软件体系 》在线思维导图免费制作，点击“编辑”按钮，可对《软件体系 》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：2435c4c03dfa11ac06e8f7c86b879f76
思维导图大纲
相关思维导图模版
软件体系 思维导图模板大纲
单点
登入鉴权
JWT
JWT ， 全写JSON Web Token, 是开放的行业标准RFC7591，用来实现端到端安全验证.
简单来说， 就是通过一些算法对加密字符串和JSON对象之间进行加解密。
优点
无状态登录（token认证）
服务器当中不记录用户的登录信息，而是将登录成功后的合法用户信息以token方式保存到客户端当中，用户在每次请求都携带token信息。
优点：
减轻服务端存储session的压力；
支持分布式，支持单点登录并对移动端友好；
支持跨域；
无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御
结构
JWT由3部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串
JWTString = Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)
安全加固
在实际开发中需要用下列手段来增加JWT的安全性：
因为JWT是在请求头中传递的，所以为了避免网络劫持，推荐使用HTTPS来传输，更加安全
JWT的哈希签名的密钥是存放在服务端的，所以只要服务器不被攻破，理论上JWT是安全的。因此要保证服务器的安全
JWT可以使用暴力穷举来破解，所以为了应对这种破解方式，可以定期更换服务端的哈希签名密钥(相当于盐值)。这样可以保证等破解结果出来了，你的密钥也已经换了
Demo
1.Maven依赖
2.生成Token，解析Token
3.配置TTL，SecreKey
4.JWT登出
黑名单
redis记录黑名单
白名单
每次登陆记录Token，登出删除
Session/Cookie
Cookie
原理
Key/Value 单个cookie保存的数据不能超过4K，一般会设置不会超过20个
因为Http协议是无状态的,在Session出现以前，一直是由Cookie来保证服务会话，它是由服务器颁发给浏览器的通行证
同源策略/跨域问题
同源策略保证浏览器数据安全问题 网站B拿到银行网站A的Cookie 获取敏感数据 是很危险的，随着互联网的发展，“同源政策”越来越严格。目前，如果非同源，共有三种行为受到限制
1、Cookie、LocalStorage 和 IndexedDB 无法读取
2、DOM 无法获得
3、AJAX 请求无效（可以发送，但浏览器会拒绝接受响应）
Cookie生命周期
Cookie的maxAge决定着Cookie的有效期
如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效
如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该Cookie即失效。
maxAge为负数的Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中
如果maxAge为0，则表示删除该Cookie。失效的Cookie会被浏览器从Cookie文件或者内存中删除
Cookie cookie = new Cookie("username","helloweenvsfei"); // 新建Cookie
cookie.setMaxAge(0); // 设置生命周期为0，不能为负数
response.addCookie(cookie);
修改/删除 Cookie只有response.addCookie(Cookie cookie)做覆蓋，没有删除 设置MaxAge =0 为删除
禁用Cookie
如何禁用
浏览器禁用Cookie
WAP 移动端大多数网址不支持Cookie
修改Tomcat全局的conf/context.xml
<!-- The contents of this file will be loaded for eachweb application -->
<Context cookies="false">
<!-- ... 中间代码略 -->
</Context>
/META-INF/context.xml
打开项目sessionWeb的WebRoot目录下的META-INF文件夹（跟WEB-INF文件夹同级，如果没有则创建），打开context.xml（如果没有则创建），编辑内容如下： <?xml version='1.0' encoding='UTF-8'?>
<Context path="/sessionWeb"cookies="false">
</Context>
由于Cookie和Seesion是成对使用，如果没有禁用Cookie或者没有Cookie怎么办？
重写URL
URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写
<a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>">
Homepage</a>
<ahref="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=
1&wd=Java">Homepage</a>
重定向response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));
编码
Unicode编码：保存中文
中文属于Unicode字符，在内存中占4个字节，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码
BASE64编码：保存二进制图片
Cookie不仅可以使用ASCII字符与Unicode字符，还可以使用二进制数据。例如在Cookie中使用数字证书，提供安全度。使用二进制数据时也需要进行编码。
Unicode和 ASCII 属于字符集，UTF-8是编码 UTF-8是变长编码，编码英文的时候使用ASCII 中文使用Unicode
Cookie属性
属 性 名
描 述
String name
该Cookie的名称。Cookie一旦创建，名称便不可更改
Object value
该Cookie的值。如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码
int maxAge
该Cookie失效的时间，单位秒。如果为正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1
boolean secure
该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false
String path
该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”
String domain
可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”
String comment
该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明
int version
该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范
Session
原理
除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。
Session生命周期
Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。
Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。
Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。
Session失效
由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。
Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。
FQA
Cookie和Seesion的最大区别
cookie数据存放在客户的浏览器上，session数据放在服务器上.
Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗考虑到安全应当使用Session。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。
安全认证
SpringSecurity
Auth2
定义角色
资源所有者
资源服务器
客户端
授权服务器
受保护资源
4大模式
授权码模式
授权码模式被广泛应用于第三方互联网开放平台，通过第三方登录是其最常见应用场景之一，比如使用微信、QQ和淘宝账号进行登录。
https://xxx.com/authorize?
response_type=code& #请求返回授权码
client_id=CLIENT_ID&
redirect_uri=xxx& #重定向地址
scope=write #申请读权限 客户端拿到授权码之后再去获取token
隐藏模式
针对授权码模式 少了获取授权码的过程，直接获取token
https://xxx.com/oauth/authoriize?
response_type=token&
client_id=xxx&
redirect_uri=http://xx&
scope=read
用户授信模式/密码式
密码模式比较好理解，用户在客户端输入自己的用户名和密码，客户端拿着信息直接去授权服务申请令牌，请求响应返回token。grant_type 为 password 表示密码式授权。
https://xxx.com/token?
grant_type=password&
username=xxx&
password=xxx&
client_id=client_Id
注意：这种模式非常危险，除非高度信任
应用授信模式/凭证式
凭证式和密码式很相似，主要适用于那些没有前端的命令行应用，可以用最简单的方式获取应用的令牌。
grant_type 为 client_credentials 表示凭证式授权，client_id 和 client_secret 用来识别身份
https://xxx.com/token?
grant_type=client_credentials&
client_id=XXX&
client_secret=xxx
如何选择模式
上面几种授权方式例子中，涉及到client_id及client_secret，一般也不会放在url里，都是header头中，Authorization设置为Basic + Base64(client_id:client_secret)。
拓展
令牌：包括访问令牌及刷新令牌
权限范围：根据实际需要划分成不同的scope。
授权流程：获取令牌的流程。后面讲的四种授权方式就是属于这块。
安全的问题
客户端漏洞
受保护资源漏洞
授权服务器漏洞
令牌漏洞
客户端安全
https://zhuanlan.zhihu.com/p/507011790
子主题 3
子主题 4
动态注册客户端
身份认证协议（OpenId)
协议扩展(UMA, HEART, iGov)
令牌扩展：PoP
自定义模式
待补充
Spring
MVC
Controller
Service
Repository
贫血模型
三层架构，表现层，逻辑层，数据访问层，适用于简单业务，不适合复杂业务
充血模型
DDD领域驱动
如何设计DDD
四层架构-充血模型
用户界面层：controller
应用层：组装领域以及领域用到的基础层的Component对象
领域层：业务逻辑层，非spring bean对象
基础设施层：包含数据访问层
六边形架构/整洁架构/洋葱圈架构
用户界面层：controller
应用层：组装领域以及领域用到的基础层的Component对象
基础基础层：包含数据访问层
领域层：业务逻辑层，非spring bean对象
六边形架构+CQRS
command：六边形架构
query：三层架构，query-查询操作，查询后更新某个表字段的操作也算是查询操作使用三层架构
SpringBoot
IOC
控制反转，把管理对象依赖的任务交给框架，ioc是一种思想，DI是实现
https://baijiahao.baidu.com/s?id=1712887849553755889&wfr=spider&for=pc
反射+工厂
Bean的生命周期
拓展点
在Bean整个生命周期中，都可以围绕Bean做处理
AOP
概念
Join point（连接点）
Advice（通知）
Pointcut（切点）
Aspect（切面）
Target object（目标对象）
AOP proxy（AOP 代理）
Weaving（织入）
Advisor
JDK动态代理
代理类实现了接口
实现 InvocationHandler
与CGLIB的区别
CGLIB 是对目标对象本身进行代理，所以无论目标对象是否有接口，都可以对目标对象进行代理，其原理是使用字节码生成工具在内存生成一个继承目标对象的代理类，然后创建代理对象实例。由于代理类的父类是目标对象，所以代理类是可以赋值给目标对象的，自然如果目标对象有接口，代理对象也是可以赋值给接口的。
CGLIB 动态代理中生成的代理类的字节码相比 JDK 来说更加复杂。
JDK 使用反射机制调用目标类的方法，CGLIB 则使用类似索引的方式直接调用目标类方法，所以 JDK 动态代理生成代理类的速度相比 CGLIB 要快一些，但是运行速度比 CGLIB 低一些，并且 JDK 代理只能对有接口的目标对象进行代理。
CGLIB
asm
原理：SpringAop的原理是通过Schema或者注解实现的
自动装配
SPI
自定义Stater
原理
启动加载原理
原理
启动拓展点
程序结束拓展点
MyBatis
ORM
多级缓存
MyBatis Plus
工具包
Guava
hutool
子主题 3
项目管理
版本管理GIT
JAR包管理Maven
多点
分布式
背景
CAP
BASE
分布式锁
服务治理
网关
Api Gateway
Zuul
配置中心
Nacos
Spirng Cloud config
项目配置放到GIT或者本地 需要项目重启才能生效
Apollo
注册中心
原理：
ZeeKeeper
Nacos
Eruka
服务监控和链路
Arthas
Prometheus
SkyWalking
SpringCloud Admin
zabbix
SpringBoot Actuato
消息总线
Spring Cloud Bus
消费者/生产者模式
广播
目前 Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka，
SOA 面向服务
Web Service
微服务
dobbo
SpringCloud
SpringCloud Alibba
Service Mesh
istio
Devops
DevOps
Docker
docker镜像
dockerfile
demo
镜像仓库
常用命令
Chats
Charts文件描述项目如何部署
K8S
管理Docker集群的工具
Rancher
日志收集平台ELK
ElasticSearch
Kibana
LogStash
思考：
为什么单体项目要升级成分布式项目
分布式项目带来的挑战是什么
微服务切分粒度是如何
如何理解中台？
网络
OSI 七层网络模型
物理层
链路层
网络层
ip
传输层
tcp
三次握手，四次挥手
ssh
会话层
表示层
应用层
常用协议
http
http1.0
http2.0
https=HTTP+SSL
ftp
短链接和长链接
职责
通常网络OSI模型为七层，但由于太过于理想，实际上可以简化为五层 物理层，链路层，网络层，传输层，应用层
网络安全
CSRF
跨站域请求伪造 而 CSRF 则通过伪装成来自受信任用户的请求来利用受信任的网站，例如用户登入某银行系统A，A网页的Cookie还存在，用户再登入非法网站B B欺骗用户向A发起请求
如何防御
Referer
判断该请求是否来自本网站
url携带Token
URL请求的签名校验-因为容易被第三方网址截取获取token
请求头添加认证
签名放在请求头里
随机函数校验
动态生成签名，算法和盐取值定期变
防御该攻击的主要目的就是判别是不是自己站点的请求
CSRFTester
XSS
跨站脚本攻击，恶意攻击者在Web页面中插入恶意javascript代码（也可能包含html代码），当用户浏览网页之时，嵌入其中Web里面的javascript代码会被执行，从而达到恶意攻击用户的目的。
如何防御XSS攻击
对输入内容的特定字符进行编码，例如表示 html标记的 < > 等符号。
对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie，此 HTTP头由服务端设置。
将不可信的值输出 URL参数之前，进行 URLEncode操作，而对于从 URL参数中获取值一定要进行格式检测（比如你需要的时URL，就判读是否满足URL格式）。
. 不要使用 Eval来解析并运行不确定的数据或代码，对于 JSON解析请使用 JSON.parse() 方法
后端接口也应该要做到关键字符过滤的问题。
DDos攻击：分布式服务攻击；
SQL注入攻击，POST表单攻击
IO
网络IO
磁盘IO
其他IO
高级语言
Java
JDK
JVM
子主题 2
语言特性
封装
继承
多态
异步
多线程
线程池
新建线程
携程
生产者/消费者模式
同步
锁
无锁模式CPU密集
synchronized
luck
反射
容器
IO
BIO
NIO
AIO
缓冲
通道
文件操作
函数编程
Lambda表达式
版本历史
Python
Go
HTML
JavaScript
JQuery
设计内功
软件常用性能优化技巧
时间”与“空间”互换取舍
索引术，空间换时间，通过数据结构和算法维护好索引数据，新华字典的目录一样快速寻找目标数据
压缩术，时间换空间再换时间 一劳永逸，对于大文件来说，每次上传下载都是巨大的损耗，先利用算法将目标数据压缩，后面只用对目标数据解压
缓存术，空间换时间，例如 将预热数据缓存到缓存空间内
如果内存和磁盘数据一样快，缓存还有意义吗
对如今的缓存和磁盘来说，数据有很大的差差异，但是缓存的真正目的是将数据预热，方便拿，就好像我每次要做一件事情前，先把需要的东西放在身边，如果忽视这种物理距离，那么还有结构是优化空间的，有序总比无序找得快
预取术，时间换空间再换时间， 预期和缓存有些类似，区别是，预取得目的是将原本需要从数据库拿出来的数据提前拿出来，在很多项目中，组织用户都会在项目启动时查出来放进缓存里
削峰填谷术，时间换空间再换时间，在很多项目中，尤其是高并发，抢单等需求里，单位时间内的并发量会很高，如果说服务器的负载过高会严重影响速度，通过将订单放进MQ内削峰，后面再去处理，直接响应用户
批量处理术，在很多批量需求中，一次一次的发送的效率 不仅有IO效率 还有连接建立销毁的损耗，批量是可以减少 损耗的，在生活中一次端10个盘子也比一次次拿过去效率高
并行能力
八门遁甲，榨干计算资源典型的BIO和AIO区别，IO时间内是不会消耗计算资源的，通过异步能力达到计算资源的利用最大化源
影分身术，水平扩容 请10个服务员的效率肯定比1个高
分片术，分片的意义针对数据而言在于更大化的提高并行能力，把同一份资源分散到不同的节点，鸡蛋不能放在一个篮子里，不然死一窝
无锁术，在很多同步需求中，锁
算法
通过算法能够合理的减少时间复杂度或者空间复杂度，程序=算法+数据结构，平时业务需求的业务逻辑也等于算法，合理的使用容器，保证逻辑精简也是优化算法
提高可用性方法
影分身
10个服务员 生病了一个 还有9个 怕个啥
分片术
同一份数据分散到10个人那，一个人失踪了，还保留90%数据 怕个啥
灰度
也是鸡蛋不放一个篮子的道理，新的功能吧服务搞挂了还玩个毛
监控，追踪
搞个上帝视角，提前发现问题，解决
测试，扫雷兵先行
功能精美心得
在用户使用感受上来看，速度越快，功能越好理解，快捷的操作方式，优美的前端画面是定理，哪如何保证以上几点呢？
文案无二义性，直白专责
画面简洁，图案少
无Bug，响应速度快，无卡顿
报错提示清楚，可追溯
功能明确，不多此一举
工程控制心得
磨刀不误砍柴功，好工具事半功倍
低代码
LCDP低代码平台
表单
组件
子主题 3
流程平台
Activity
Camunda
taskList
module
子主题 3
Flowable
计算机原理
编码
Unicode
ASCII
GBK
UTF-8
算法
一致性哈希算法
前世
取模
今生
操作系统
存储
数据库
DBMS
MySQL
ORACLE
SQL
NoSQL
Redis
MongoDB
Minio
Alibaba OSS
ElasticSearch
中间件
RocketMQ
Kafka
RobbitMQ
内存
高速内存
子主题 2
磁盘
查看更多
相似思维导图模版
首页
我的文件
我的团队
个人中心