应用服务的 Per-App 方法为何如此重要

我不会读心术（我的孩子们可能并不赞同，但这并不重要），但我可以看懂我们的应用交付状态调查的结果。当我从应用开发人员的角度来解读这些结果时，我有了有趣的发现。

开发人员关注的是速度、安全性和规模。重要性的排列不一定按这个顺序，但他们确实关注这三点。并且还意识到应用服务的价值，可以帮助他们达成目标。

也就是说，开发人员不仅需要笼统的“加速”应用服务，还需要提供 TCP 优化和缓存的具体服务。他们希望有一个 Web 应用防火墙，以及一些负载均衡来进行引导。

问题是，这些应用服务大多是以共享基础设施模式提供。每个应用都有自己的“虚拟代表”，但它实际位于一个共享的软件或硬件之中。

这可能会导致真正的问题，这也是 IT 和应用开发之间仍然存在摩擦的部分原因。正是系统的共享性质，让我们不得不面对更改时间限制、审查委员会和加班完成部署工作（这时可以用美味披萨来犒劳自己）。这些流程拖慢了开发速度，并让参与部署的同事感到力不从心。

我们不再部署庞大的应用。即使没有了海量的微服务，没有将应用分解成数百个小服务，我们仍然有更多的应用列于更频繁的部署计划中。应用开发变成了以一周为时限的冲刺赛跑，再也不是以年为单位的开发项目，并且还需要更快更频繁地推送更新。

从根本来看，这多半归功于（公有）云得到了成功实施。因为我可以全权负责应用和基础设施，我不必在推送更新之前等待其他同事的审批。因为我可以全权掌控，但相对的，如果出了问题，我也需要全权负责。

同样的方法在本地也可以实施（我认为是可取的）。条件是，构成应用交付链的所有部分和部件都要支持云计算所需要的按应用方法。

基本上，按应用交付所需的网络和应用服务的方法类似于为应用指定子网；也可以说是应用交付 VLAN。就是为了一个应用，提供专门服务。

这种隔离不仅对部署计划有好处，而且对其他人也有好处。在故障发生时，要做的便是尽可能减少所带来的影响。按应用架构意味着可以严格限制故障所带来的影响，这可以让所有那些“以防万一”待命的人员安下心来，因为并不会发生这种危机情况。我可以每周发布和部署，而不会与那些每月发布和部署一次的应用相冲突。一个人可以全权掌控应用、服务和部署计划。

Per-App 应用架构也使得在生产中出现的问题很容易得到解决，而这种问题时有发生。事实上，在 2017 年 Atlassian 调查中，50% 的开发人员在代码发布后报告了生产中的问题。开发人员做的些许改变很难影响到整个应用，因此可以直接去寻找所涉及的系统，而不是花费宝贵的时间去弄清楚问题可能涉及哪些系统。

Per-App 架构的性质同样适合云（不管是公有云还是私有云），因为该模型的假设便是来源于此。每个应用都有一套专门的应用服务来扩展、加速和保障它的安全。

现实情况是，Per-App 架构势在必行。这已经算是老生常谈。应用的重要性绝不容忽视，而且为了保证应用的安全，需要越来越多特定于应用的安全措施，这意味着或早或晚均要采纳按应用方法。

这是件好事，因为开发人员所需要的应用服务往往是针对特定应用的。对一个应用有效的技术手段不一定会对另一个应用有效，而且事实上，甚至可能带来负面影响。通过采用 Per-App 架构方法来进行应用交付，您可以确保开发人员不仅可以获得他们想要和需要的技术来扩展、保护和加速应用，还可以更好地支持他们期望的自助服务模式，无论是在本地还是非本地云，均可以实现这一点。