系统架构的未来会有什么变化

重点将从部署系统，转移到重新配置现有资源以提高企业能力。

无论我们是否认识到，系统架构都在不断发展。在过去的几十年中，系统架构就是构建架构的过程：确定系统需要做什么，确定所需的主要子系统以及它们如何连接，并继续分解，直到有足够的细节供开发团队构建每个子系统，集成子系统并创建所需的系统。这种模式近年来一直在变化，但变化的速度正在增加。

网络的影响

随着网络系统在20世纪90年代变得越来越普遍，系统架构实践开始发生变化。客户端/服务器架构作为主导设计模式的出现，使得架构必须包括网络。系统不再是整体，它们被部署在一个地方，并从一组固定的终端使用，分布在一个可能很大的地理区域。

网络对系统架构演变的下一个主要影响是整合系统的愿望。没过多久就意识到将相同的数据输入不同的系统既费时又容易出错，所以开始尝试集成系统，以便共享数据。这导致了面向服务的体系结构（SOA）的发展。SOA的基本思想是，功能提供商可以将其产品作为可由网络上的任何应用程序调用的服务提供。“服务”只不过是一个定义良好的接口，可以满足某些所需的功能。SOA承诺了一个动态可组合应用程序的时代，这些应用程序可以适应新的业务需求，而无需重新编写应用程序代码。

服务的兴起

像许多广泛宣传的新技术一样，SOA从未完全实现其最初的承诺。但是，就像许多大肆宣传的技术一样，在大肆宣传十年后，我们看到了SOA理念的真正好处。许多功能可用作服务，并且更多企业正在使用它们。例如，Facebook，Google和其他公司都提供身份验证服务。如果运行网站，并希望在允许用户访问网站的所有功能之前对用户进行身份验证，则无需托管自己的身份验证子系统，可以使用其中一种作为服务提供。以类似的方式，评论线程，社交媒体集成，用户统计和许多其他功能也作为服务提供。整个云计算革命实际上只是将计算硬件转换为按需服务。

虽然它没有采用最初设想的形式，但SOA革命绝对发生了。如今，大多数企业集成工作都致力于使系统接口公开可用。这通常被称为“应用程序编程接口（API）的第一哲学”。API第一哲学最着名的例子可能是被称为“the Steve Yegge rant”的信件，他在那里谴责谷歌没有采用亚马逊的API优先设计理念。咆哮的基本原因是所有功能都应该通过API在网络上公开，以促进集成并最大限度地减少企业生产（和支付）的重复功能。

API如何推动系统架构

到目前为止，任何API优先任务的主要作用是使开发人员确保他们记录他们的API并公布它们。但亚马逊API首要任务的主要目标是降低在多个系统中开发重复功能所产生的成本。由于大多数企业不会每隔几年更新一次所有系统，因此任何API优先授权都需要时间来显示企业中的实际效果。但随着时间的推移，这些影响将会让人感觉到，特别是当API优先授权与重建前构建任务相结合时，需要系统开发人员在构建新的功能之前重用企业中可用的功能。

随着越来越多的系统通过API提供其功能，并且开发团队的任务是在构建之前重新使用，将通过将现有功能重新组合为新功能来替换构建新系统。目标差异很大的系统之间的重复数量令人惊讶。大多数系统都需要一种存储和检索数据的方法。大多数系统都需要一种方法来验证和授权用户。大多数系统都需要能够显示文本和渲染图形。可以从企业中的现有资源重用的功能列表一直在继续。在系统开发的早期阶段，开发人员需要创建这些功能，以便拥有最低功能的系统。由于大部分基本功能可用作服务，系统设计人员的任务正在从设计整个系统发展到在企业生态系统内设计边际功能改进。

迈向以能力为中心的架构

我们今天所面临的企业生态系统，是一个不断扩展的功能集作为服务提供的生态系统，特别是在云环境中。云提供商竞相提供越来越多的功能，并且已经可以通过将一些服务与一些组合软件或脚本语言拼接在一起，来开发基本系统。通过这样做，开发人员可以在几周而不是几个月内创建一个功能最少的系统。通过整合新服务或安装没有服务的现成模块，可以快速改进这一基本系统。在这样的环境中，一个长达数月的设计阶段，试图在构建开始之前计算出系统的细节是没有意义的。我们需要一种新的思考系统架构和设计的方式。

在已经拥有许多可用服务的企业中，构建新系统应首先明确定义预期系统需要执行的功能，并将其与已作为服务提供的功能列表进行比较。这将揭示企业中已有多少所需系统，以及需要构建多少。现有功能和所需功能之间的差异定义了企业当前功能与所需功能之间的能力差距。随着我们迈向未来，系统架构师的首要任务将从设计整个系统，发展到定义当前的能力增量并设计缩小差距的最佳方法。

我们还没有达到这种以能力为中心的架构很容易的程度。我们了解整个企业可用服务的能力受到严重限制。任何诚实的网络管理员都会承认他们并没有真正掌握其网络上可用的完整服务列表。他们可能知道哪些机器连接到网络，每台机器上运行的软件，以及每台机器上打开的端口和协议。但是这些信息只告诉我们这些事情的网络级方面，它没有透露有关这些东西如何被使用的任何信息。例如，网络上打开端口8443并接受HTTP连接的系统可能正在提供简单的网页，或者它可能通过该接口提供许多REST服务。

有办法克服这种缺乏理解，但大多数都是手工的。例如，维护列出企业中可用服务的Wiki需要开发人员添加他们已部署的服务并维护该列表。并且用于近实时地识别和编目服务接口的自动化装置将更有效。但那是另一个时间的主题。

也有例外

由于系统需要运行的环境，传统系统架构在某些领域仍然存在。任何涉及功能完整企业的操作环境都存在问题，需要以老式的方式进行全范围的系统设计。例如，飞机飞行控制系统实际上不能依赖于调用地面上的服务来执行与飞行安全相关的任何功能的能力。同样，卫星系统和其他类型的嵌入式软件需要在本地提供所有关键功能。

旧的系统架构方式不会完全消失，但是我们已经开始考虑如何提高系统架构实践的效率，以便更好地支持当今快速发展的商业环境。