什么是应用架构？

应用架构描述了设计和构建应用的模式与技术。该架构可以为您提供构建应用时应遵循的路线图和最佳实践，帮助您构建一个结构合理的应用。

软件设计模式可以帮助您更方便地构建应用。模式是一种可重复利用的解决方案。

不同的模式可以连在一起，从而创建更多通用的应用架构。使用现有的设计模式，您就不用完全自行创建架构，而且可以确保一切会按预期运行。

应用架构包含前端和后端服务。前端开发事关应用的用户体验，而后端开发则侧重于提供对数据、服务及其他现有系统的访问，以确保应用正常工作。

架构是构建应用的起点或路线图，但对于架构中未涉及的实现方案，则需要您自行做出选择。例如，通常第一步是选择编写应用的编程语言。

软件开发有许多种编程语言。某些类型的应用需要特定的语言，例如用于移动应用的 Swift 或用于前端开发的 JavaScript。 

与 HTML 和 CSS 一起使用的 JavaScript 目前是 Web 应用开发中最广泛使用的编程语言之一。 

其他常见的编程语言还包括：Ruby、Python、Swift、TypeScript、Java、PHP 和 SQL 等。构建应用时所用的语言将取决于应用的类型、可用的开发资源和要求。 

以往，我们是将应用编写为单个代码单元，其中的组件均共享相同的资源和内存空间。这种架构叫做单体式架构。

现代应用架构则通常使用微服务和应用编程接口（API）来实现松散耦合，以连接相关服务，这为云原生应用奠定了基础。 

云原生开发可以加快构建新应用、优化现有应用，并在私有云、公共云与混合云之间提供一致的开发和自动化管理体验。

在决定新应用的应用架构或评估当前的架构时，首先要确定战略目标。

然后再设计支持该目标的架构，而不是先选择架构再尝试让应用来适应该架构。 

您还应考虑通常多久发布一次更新以满足客户或运维需求，以及业务目标或开发需求需要什么样的功能。 

快速向客户提供新服务和新功能是每间公司的关键竞争优势之一。加快开发速度可以让企业更频繁地发布新功能，并在发现漏洞后立即推出更新。

目前应用架构有很多，但根据服务间的关系，当今最重要的应用架构是：单体式和 N 层架构（紧密耦合）、微服务（非耦合），以及事件驱动架构和面向服务的架构（松散耦合）。

分层或 N 层架构是一种传统架构，通常用于构建内部和企业应用，而且常常与传统应用相关联。

在分层架构中，应用由多个层（通常为 3 层，但也可以有更多层）构成，且每一层都有自己的职责。 

分层有助于管理依赖关系并执行逻辑功能。在分层架构中，层与层之间是水平排列的，因此它们只能调用自己下面的一层。 

每层既可以调用紧挨在它下面的层，也可以调用它下面的任何一层。 

单体式应用（另一种与传统系统关联的架构类型）就是一个应用中包含所有功能的应用堆栈。无论是服务之间的交互还是开发与交付方式，都采用紧密耦合的形式。 

更新或扩展单体式应用的某一方面会对整个应用及其底层的基础架构产生影响。 

对应用代码的任何更改都需要重新发布整个应用。因此，更新和新版本发布通常每年只能进行一次或两次，并且可能只包括常规维护，而不会添加新功能。 

相比而言，更为现代化的架构则尝试按功能或业务能力来拆分服务，以提供更高的敏捷性。

微服务既是一种架构，也是构建软件的方法。在微服务中，应用被拆分成最小的组件，彼此独立。其中的每一个组件或流程都是一个微服务。

微服务采用分布式、松散耦合结构，因此它们之间不会相互影响。这对于动态可扩展性和容错能力都有一定的好处：可以在不占用大量基础架构的情况下按需扩展单个服务，或者可以在不影响其他服务的情况下进行故障转移。

使用微服务架构的目的是更快地交付高质量的软件。您可以并行开发多个微服务。由于服务是独立部署的，因此在发生更改时无须重建或重新部署整个应用。 

这样就可以让更多的开发人员同时处理各自的服务，而不是更新整个应用，由此可以减少开发时间，并能增加新功能的发布频率。

与 API 和 DevOps 团队一样，容器化微服务也是云原生应用的重要基础。

对于事件驱动系统而言，事件的捕获、通信、处理和持久保留是解决方案的核心结构。这和传统的请求驱动模型有很大不同。

事件是指系统硬件或软件的状态出现任何重大改变。而事件的来源可能是内部也可能是外部原因。

事件驱动架构可以最大程度减少耦合度，因此是现代化分布式应用架构的理想之选。

事件驱动架构由事件发起者和事件使用者组成。事件的发起者会检测或感知事件，并以消息的形式来表示事件。它并不知道事件的使用者或事件引起的结果。

检测到事件后，系统会通过事件通道从事件发起者传输给事件使用者，而事件处理平台则会在该通道中以异步方式处理事件。

事件驱动架构可以基于发布/订阅模型或事件流模型。

发布/订阅模型是以事件流订阅为基础的。对于该模型而言，在事件发生或公布之后，系统会将相应的消息发送给需要通知的订阅用户。

这与事件流模型不同。在事件流模型中，事件使用者不会订阅事件流。相反，它们可以从流的任何部分读取并随时加入流。

事件在其事件源（如物联网（IoT）设备、应用和网络）发生时即被捕获，因此事件发起者和事件使用者可实时共享状态和响应信息。

面向服务的架构（SOA）是一种非常成熟的软件设计模式，它有点类似于微服务架构模式。 

SOA 将应用构建为可重复使用的离散型服务，这些服务会通过企业服务总线（ESB）进行通信。 

采用这种架构时，各项服务会分别围绕特定的业务流程进行组织，遵循相应的通信协议（如 SOAP、ActiveMQ 或 Apache Thrift），并通过 ESB 平台来提供服务。总而言之，前端应用会利用这套通过 ESB 集成的服务为企业或客户提供价值。

红帽解决方案可以帮助您将单体式应用分解为微服务、对其进行管理、编排并处理它们所创建的数据，让您团队可以更快地向客户提供高质量的解决方案，从而提升您的业务敏捷性。  

创建新的业务应用时，您能够考虑未来需求，构建敏捷且可轻松扩展的云原生应用，并从一开始就将这些应用与您的其他业务相集成。

观看本网络研讨会系列，获取有关如何通过红帽® OpenShift® 上的企业级数据平台来构建、运行、部署和现代化应用的专家视角。

无需彻底改造现有系统，即可获益良多。红帽拥有卓越的开源技术、开放标准和多年经验，可以帮助您找到适合自己企业的微服务解决方案。

凭借我们的开源产品组合（包括红帽® 企业 Linux®、红帽 OpenShift 和红帽应用服务），红帽拥有得天独厚的优势，致力于携手希望转型的公司，帮助他们在日新月异的软件驱动型市场中保持竞争力。