将应用服务插入不断变化的应用架构中

自计算诞生以来，应用架构已经历了多次演变。 对于一些寿命较长的企业来说，他们已经处于第五种不同的应用架构。 如今，许多人都在操作和维护每个应用。 也就是说，我们即将发布的2020 年应用服务状况调查结果表明，大多数组织运营的现实情况如下：

每个应用程序架构都会对“上游”的一切（网络架构、技术、安全性和应用（交付）服务）产生巨大影响。 最新架构转变的核心——微服务——是我们可以称为“原子化”或“组件化”的概念。 两者本质上都是指将应用分解为更小、更易于管理的组件的过程，目的是缩短上市时间、提高代码质量和灵活性。

在前几代应用程序架构中，网络仍然是插入某些类型的应用服务的最有效点。 直到最近，代理一直是将这些服务插入从应用程序到客户端的数据路径的主要手段。

但该数据路径正在随着现代应用架构而分解。 它现在涵盖互联网、云属性和数据中心。 它越来越多地将客户端作为应用功能的关键组件。 

因此，仅仅依靠单一已知的数据路径来插入应用服务不再是最佳选择。 此外，由于许多新兴的数据路径不适合基于代理的平台，我们必须寻找其他潜在的插入点来扩展和保护现代应用。

application服务插入点

将应用服务“插入”到数据路径的概念为我们提供了一种简单方法来描述部署应用服务的现代视图：插入点。

在这个模型中，我们区分了传统的插入点（代理）和其他位置，例如应用程序/Web 服务器和客户端设备。 每个位置都有多个适合应用服务插入的表单。

代理人

在网络的传统网络插入点中，您会发现基于代理的应用服务以及它们的现代等效物——构成某些服务网格解决方案基础的边车代理。 两者都部署在“网络中”，因此无论形式因素（容器、软件、硬件）如何都需要访问该位置。

代理仍然是插入应用服务的有效手段。 当今现代应用程序架构对代理的最大影响是其焦点。 代理传统上为许多应用托管应用服务，而当今的架构要求采用更针对每个应用程序的方法。 因此，代理被设计到应用及其基础设施中，并且往往比以前的代理解决方案具有更加细粒度的关注。

无代理

由于并非所有应用和环境都提供该访问权限（例如 SaaS），我们寻找可以部署应用服务的替代插入点。 我们大致称这些替代点为“无代理”，因为它们不需要或依赖代理来部署和执行。 这些服务可能采用传统代理的形式（作为服务器或应用的一部分部署的软件），或者可能采用更适合开发人员的基于代码的选项形式。 注入的代码（例如 JavaScript 库或 Web 服务器和浏览器插件）是这些替代位置中的插入点的很好示例。

服务

许多应用服务可以“作为服务”提供，即作为基于云的产品托管。 插入仍然需要访问才能调用这些服务；因此，如果没有通过代码或配置工件进行某种形式的插入，此类服务很少会被包含在应用中。 

鉴于现代应用架构所塑造的这种新格局，应用服务适用位置的答案越来越多地出现在应用程序（或应用程序的一部分）可能驻留的任何地方。 随着应用程序架构的分解，用于扩展、保护和加速应用组件交付的应用服务也将随之分解。 

插入点的扩展只是支持未来遥测和智能自动化需求所必需的进化步骤之一。  随着企业继续沿着数字化转型的道路前进，应用服务也将继续扩展和发展。