applications组件化如何影响性能和安全性

回顾过去的美好时光，企业可以依靠使用战略性部署的代理来提高应用的性能。 这是因为传统应用（整体式和三层架构）通常在客户端和服务器之间采用单一数据路径。

简单来说，所有内容都只有一种路径 - 无论是静态还是动态，基于文本还是图像。 这意味着应用交付控制器（代理）可以位于它们之间，并通过正确的方式优化性能。 顺便说一句，这过去是、现在仍然是通过调整各种 IP、TCP 甚至 HTTP 按钮和旋钮来实现的。 我们可以通过部署应用服务（如缓存、压缩和特定内容的加速技术）看到这些技术的使用。

但现代应用不再能够自力更生。 根据 Sonatype 的说法，它们现在主要由第三方（以及越来越多的开源）组件组成（80-90%）。 您可以从 Web应用中的脚本和其他可注入代码的数量中看到这一点。 有时该脚本会远程执行并返回图像、广告或其他内容（如网络字体和精灵）。 其他时候，脚本本身在运行时加载并在浏览器范围内执行，例如 jQuery。

这就是所谓的组件化，或者如果你愿意的话，原子化。 它将应用分解成许多更小的部分。 我们将它们称为客户端组件，因为它们通常在同一空间中执行。 在服务器端，我们越来越多地将它们称为微服务并将其部署在容器中。 在这两种情况下，影响都是类似的——我们最终会得到不可预测数量的数据路径，这些数据路径会直接影响性能。

基本上，您可以控制一条数据路径- 它可能占应用的20％。 这意味着您对用户体验的控制非常少，因为您对性能的控制非常少。

对于安全来说这也同样适用 - 感谢您的关注。 事实上，我们正在快速学习利用客户端代码技术来提高安全性。 这对于性能来说并不是很好，因为大多数应用程序都是移动的或网络的，而且都没有机会或能力来干扰网络堆栈。

解决这一问题的方法之一是重新获得控制权。 重新获得控制权的妙处在于您还可以从安全副作用中受益。

双赢： 降低风险并提高绩效

如果您的应用程序习惯于从外部站点动态加载组件，请停止这种做法。 马上停止。 这既是一个性能问题，也是一个安全问题。 您隐式地授予外部来源脚本在您的应用上下文中运行的权限。 相信我，如果发生安全漏洞，用户将无法区分您的组件和外部加载的组件。 正如我们从最近runc 容器漏洞的冲击中了解到的那样，向从第三方注册表或站点加载的资源中注入恶意代码会带来安全风险。

如果它是一个脚本，你最好从你自己的基础架构克隆并提供服务。 通过保持控制并能够调整旋钮和按钮来提高用户性能，您将受益于降低风险。 其中包括 DNS，它一直被证明对应用性能具有最大（通常是负面）影响。 当您从外部站点提取组件时，您依赖它们的 DNS 基础设施来实现预期的性能。 从您自己的站点提取组件可以显著减少影响，因为用户的本地 DNS 缓存对您有用。

从您自己的网站托管脚本还使您能够采用 TCP 优化或 SSL/TLS 卸载或通用应用程序加速技术来提高整体性能。 它还提供了对这些脚本执行安全扫描的机会，以确保没有深层隐藏的意外。

组件化对于开发非常有用，并且确实有助于加快价值实现时间。 但它可能会对性能和安全性产生负面影响。 了解安全和用户满意度风险以及如何应对这些风险。