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

小议动静分离架构方案

 

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

 

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

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

你可能感兴趣的:(架构师之路)