叩丁狼开发工程师：SSR服务架构特点分析

　　SSR服务架构是我们在搭建一些开放性平台的时候需要添加的一项功能应用，而今天成都软件开发工程师就通过案例分析来了解一下，关于SSR服务架构的特点都有哪些内容?

　　1、抵抗单页面大流量 要抵抗单页面的大流量，先我们自然而然会想到会使用缓存，与此同时我们也需要保证页面的及时响应，因此针对这个问题我们一般会使用CDN服务。由于CDN遵循就近原则，因此客户端请求对应的页面及其数据是会被自动分配到延迟低的CDN节点上，如果我们正确的设置对应的HTTP相关缓存，是会得到很好的低延迟加载效果。 那么当临近CDN节点缓存失效怎么办呢?

　　这个时候CDN根据对应配置也能很好的帮助我们尝试回源到目标服务器上，从而完成整个数据的加载。并且由于CDN到目标服务器上的网络一般采用更优化的网络链路，因此相对于客户端直接请求目标服务器来说，会有很大的低延迟优势(客户端到CDN的节点是邻近的，CDN到目标服务器是更优化的网络链路)。 但需要注意的是，对于资源的回源HTTP缓存头设置我们一般需要让其遵循源站方便业务端控制。同时也需要将其设置为一个比较合理的数值，否则非常容易造成缓存长时间不失效的问题。

　　2、秒级的发布与回滚 在此新架构之前，整个系统的发布和回滚是非常不可靠、缓慢且不灵活的，对于一次发布而言如果牵扯到非常多的子模块和子系统，那么耗时20多分钟是非常频繁的事情。由于新的架构是以平台化来进行设计，其希望能够接入更多的团队和项目产品，因此我们需要非常简便及可靠的发布逻辑作为支撑。

　　由于sis和sis-ssr所有组件相关信息都是以依赖表为基础，因此我们很容易在不涉及任何SSR服务下进行，其过程如下： 将对应目标产物同步至Combo服务，若失败则直接阻断 将对应目标产物同步至AWSS3中，若失败则直接阻断 修改Database的相关表中依赖表的路径信息，失败则直接阻断 刷新Redis的依赖表的路径信息，设置失效时间

　　3、系统安全与运行隔离 既然作为一个开放的平台化系统，那么关于整体的系统安全也是需要考虑的一个重要问题。由于组件的开发可以被下发给其他团队，因此其中的不可控性非常的高，况且整个组件的开发还会涉及到SSR的服务端逻辑，那么如果写出风险性的代码是非常存在可能性的。

　　试想，如果A团队编写的SSR端代码内部包含了了process.exit(0)，那么导致整个进程被重启，实际上会造成非常大的困扰。因此我们在运行过程中需要尽可能的做到运行隔离，限制SSR端代码可调用的基础库，保障整个系统的安全运行。