本文主要是介绍静态化使用于什么场景呢？ 也就是 在什么业务需求下会使用 静态化？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
小议动静分离架构方案
1.缘起：
互联网项目应用大多是高并发，要求在高并发下 请求访问能够快速响应。除了在 scale up 和
scale out 方案外 还可以使用 动静分离的方式实现；
首先说下 动静分离为什么会快？
静态的资源特点： 访问路径短，不需要动态拼装即可返回用户请求结果；
动态的资源特点： 访问路径长，微服务实现中可能一个请求会跨几个微服务节点，寄过需要拼装
后才可以返回给前端；
动静分离： 故名思意，就是将能够静态化的单独部署在 nginx 或者CDN或者squid/varnish 等服
务器上，而需要动态拼装的则放在另外的服务器上部署，从而动与静态属性的两种
资源分离开来部署；
2.静态资源
如： html js css jpg png 等等 不会变动的资源；
主要的 前端页面缓存技术有：
CDN （可以用 nginx + memcache ）；
NIGNX；
squid： 特点： 可持久化到 磁盘，支持大文件存储；
varnish： 特点： 效率高，不支持持久化--磁盘存储，小文件存储性能好；
3.动态资源：
通常是指，需要动态的组装，例如 法义APP按照条件找律师的搜索结果叶需要多个维度的筛选后结果集组装，访问的链路可能会 跨越多个微服务节点，链路很长。而且不同用户的不同条件搜索结果是不一样的；
那么此时就不能再用动静分离，只能是使用 scale out 方式，前文有总结过 scale out 方式的扩展方案； 或分布式 多节点集群 + 负载均衡策略；或添加 服务器应用层级的缓存；
总结如下：
- 分层架构
- 服务化架构
- 数据库，缓存架构
4. 互联网的动静分离架构：
动静分离的方案是，指将动态页面与静态页面 分开不同系统访问的架构方案；
一般来说：
- 静态页面访问路径短，访问速度快，几毫秒
- 动态页面访问路径长，访问速度相对较慢(数据库的访问，网络传输，业务逻辑计算)，几十毫秒甚至几百毫秒，对架构扩展性的要求更高
- 静态页面与动态页面以不同域名区分
静态页面除了上述中指出的 html css js jpg png 等文件，比如还可以 根据具体的业务场景将
业务中产生的 一些结果集事先做成静态页放在静态资源服务器中 实现静态化；
比如：
法义APP 中 资讯 页面就可以这么搞， 访问 的是 ID 为 123456 的 资讯文章， 那么我们可以
将ID为 123456 的文章ID 去数据库查询出来 然后将 文章内容 用html css 等进行渲染成静态
的 123456.html 文件 放入静态资源服务器中。那么用户在访问的时候就可以 如下方式方
位：
http://fystatic.com/zx/123456.html 此时访问的就是静态资源服务器 ， 前面有说过 静态资源
服务器 的特点 访问链路短，响应迅速；
5.静态化的适用场景：
哈哈哈。。。 老调常谈。。。 一切脱离业务的架构都是耍流氓。。。
静态化使用于什么场景呢？ 也就是 在什么业务需求下会使用 静态化？
总结下：
1. 高并发 但要求响应速度快 快到什么程度？？？？ --- 用户请求响应在三秒内。
2. 静态化的文件 数量不宜过大，数量不多，静态化总文件数不庞大；
3. 适合用在 规则性较强的逻辑处理较复杂的业务场景：比如： 按照某三四个条件维度
来检索出来的律师服务页，产生的结果是一致的。那么此时就可以生成静态页放入静态
缓存服务器中供调用；
4. 反之，当数据量庞大，生成静态页比较多的时候就不适合应用此静态化方案。
6.总结：
“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术。
总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态化”优化。
这篇关于静态化使用于什么场景呢？ 也就是 在什么业务需求下会使用 静态化？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
