随着前端发展逐渐成熟，前端 CD 也随着时间的迁移而变化。本文通过时间线的方式，简述前端 CD 的过去、现在和将来。
part1: 纯静态页面时代
前后端分离后，前端页面变成了静态资源页面。只需要将页面文件部署在服务器，再通过 nginx 反向代理，页面就能被顺利的访问到。
1. nginx 反向代理访问资源纯静态页面的发布，只需要将新的页面资源把旧的资源替换掉，就完成了升级。
2. 静态资源替换进行更新为了屏蔽机器的操作细节，也为了更方便扩容，虚拟系统逐渐显现。
3. 使用虚拟系统屏蔽系统差异因为系统里面跑系统，占用了更多的cpu、磁盘，这项技术一直没被广泛传播。
4. 系统上面跑虚拟系统，消耗更多资源此时 Docker + k8s(Kubernetes) 出现了，因为先前使用虚拟操作系统并没有比较好的收益，这项技术在前端并没有被广泛使用。
5. docker 初现part2: SSR 的现在
此时因为受到静态资源加载后再发起请求，导致网页初始化很慢，大家逐渐想起来前后端分离前的快乐。
6. CSR 方式: 先请求资源，再请求数据，页面有闪动前端开始逐渐往服务端渲染靠，开始逐渐做后台的工作
7. SSR 方式: 一次请求，页面打开速度提升和静态资源不同，服务端渲染会有一定程度上的资源消耗，就需要更多的机器了。
8. SSR 方式: 消耗更多服务端资源需要操作机器更多，运维成本极限升高，开始寻求更低的运维成本。到底是serverless 还是 docker + k8s?
9. 是serverless 还是 docker + k8s?中大型网站需要灰度能力，因此docker + k8s 在中大型前端中逐渐胜出。
10. docker + k8s 能力强大，逐渐获胜part3: 发布原子化的未来
随着发布节奏紧锣密鼓的进行，前端也受够了线上反馈的问题，希望发布系统能自动灰度；有问题可随时会滚。
11. 前端发布速度快、多，如何减少发布风险？通过 docker + k8s, 根据用户id、IP进行自动灰度，能保证同一个用户命中相同资源。每次发布都会变成一次记录，发布和回滚只需要将域名流量切换，再也不需要提醒吊胆的发布了。
12. 发布原子化，修改配置实现灰度、升级、回滚结束语
资源替换、裸机 ssr 适合中小型的项目开发，发布频率不大；中大型前端追求发布平稳，灰度简单；每种形式各有优劣。本文以时间线的方式讲述了前端 CD 发展的痛点和动机。
当然，前端 CD 还在逐渐发展中，还有很多技术需要不断尝试和更迭，仅是对现有的技术和最新的 CD 流程做简述。
或许有一天开发者感知不到发布。只需要定好发布策略并随时提代码呢？希望这天提早到来～
感谢您看到这里～ 💗
原文链接：https://blog.gdccwxx.com/docker/why-web-need-docker/
