静态化使用于什么场景呢？ 也就是 在什么业务需求下会使用 静态化？

小议动静分离架构方案

 

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.总结：

 

“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术。

总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态化”优化。