“应用架构”应用程序架构的当前趋势

本文有些不是最最新的，但是方法和思路也有借鉴意义，稍后会介绍Gantner的最新应用架构趋势。

应用架构概述

随着各种力量（云、移动、社交和大数据）的相互联系不断涌现，不利用这些力量的组织在未来将面临严重的业务劣势。

架构师应该考虑适应这些新趋势

使用面向服务架构（service-oriented architecture，SOA），包含微服务(MSA)，构建应用程序，并集成内部商用现货（COTS）和遗留应用程序，以及业务合作伙伴应用程序和云服务。

利用SOA在具有不同预算、计划、需求和所有者优先级的应用程序和服务之间提供松耦合连接的能力。

使用SOA的关注点分离和封装，将移动、社交和云数据源与可变的结构化和非结构化数据模型集成。

利用松散耦合最为关键的事件驱动架构（EDA）。

确保开发工作更加敏捷和渐进。

考虑通过开源产品、开放标准和开放数据利用开放计算。

遵循大型网站的最佳实践和先例；寻找使用内存计算以及基于最终一致性模型的事务处理的机会

下面是显示应用程序架构议程的图表

图1

摆脱三层架构

应用程序体系结构的分层方法的问题在于它只在一个维度中定义应用程序（图2）。所有不同的数据源都在底层。所有用户界面（UI）逻辑都在顶层。而且，应用程序的其余部分介于两者之间。自上而下。自下而上。直线。一维的

图2

今天的客户端应用程序必须支持在一系列不同的“客户端”设备上运行的各种UI，包括PC、上网本、平板电脑、智能手机、信息亭、汽车仪表盘、GPS设备和媒体播放器。名单很长，而且还在继续增长。这些应用程序经常被调用来支持来自其他系统的访问，如社交计算站点、业务合作伙伴应用程序、媒体公司站点和业务部门IT提供的mashup（图3）。在这种情况下，单个客户端程序将清楚地调用应用程序的业务逻辑的概念是很奇怪的。

图3

我们现在在应用程序的访问端和数据管理端都有多个维度。许多新应用程序中的业务逻辑由一个或多个组合服务组成，这些组合服务依赖于多个子服务来执行业务逻辑。在某些情况下，这些多个服务在内部运行，但有时应用程序必须访问合作伙伴或供应商提供的服务，或者这些服务可以托管在云中。

图4

鉴于这些关于现实世界应用程序复杂性的观察，我们可以通过注意充分描述的应用程序架构来总结，应该假设许多客户端程序和设备访问许多业务逻辑服务，而这些服务反过来又访问其他业务逻辑服务，以及多个数据访问/数据管理服务。

图5

放弃过时的应用程序架构假设

应用程序设计人员一直在基于长期以来的假设来设计他们的应用程序。其中一些假设与移动、社交、云计算和新信息管理的交叉带来的新范式相冲突。有必要抛弃这些假设，以便能够容纳各种力量（云、社交、移动和信息）的联系。

放弃应用程序可能依赖于环境同质性的假设。设计系统，假设它们运行在高度动态基础设施上的混合云环境中。

放弃应用程序将存在于单个位置的假设。构建这样的应用程序：流程和数据可以分布在多个位置，而辖区分割是设计的一部分。

放弃使用数据库强制流程完整性的假设。相反，创建具有完整性意识的应用程序并管理业务成果。

放弃关于应用程序使用结构化数据的假设。相反，应用程序必须容纳不同的媒体类型和用于类似目的的多个数据类型。

放弃“记录器”模式假设。相反，应该围绕人际和社会沟通来设计应用程序。

接受应用程序范例和模型

术语“应用程序架构”是指应用程序的结构和组织，包括其组件以及它们之间的交互/相互依赖模型。应用程序架构师应用架构范例，并使用常见的模式和模型来设计应用程序并定义其架构。

最直接受体系结构影响的应用程序特性包括

1] 可维护性

2] 稳健性

3] 多才多艺

4] 可用性

5] 寿命

为了更好地理解如何使用应用程序体系结构来交付具有这些特性的应用程序，考虑体系结构的三个组件是很有帮助的：

范式

模型

结构和组织

范例：

架构范例（有时称为架构样式）是一个总体概念框架，它影响您设计应用程序的方式。一个范例有助于确保应用程序展示最能满足应用程序所有者目标的特性。

模型

模型是对现实世界某些方面的抽象描述和符号规范。模型通过将复杂性抽象为系统最可见方面的高级表示，帮助人们理解复杂的系统。然后，设计人员、开发人员和系统涉众在逐步深入到系统的细粒度方面时创建更详细的模型，以便更好地理解系统组件的功能性和非功能性功能及其相互依赖性。

解决方案架构师为系统的四个相关方面建模：

业务能力模型指定了组织需要能够做的事情

业务流程模型指定组织如何完成任务

信息模型指定组织使用、处理或创建的信息

服务模型指定执行工作的软件组件

结构和组织

应用程序的架构反映在其实现的结构和组织中。这些架构特性影响应用程序的性能、可伸缩性、健壮性、灵活性、可维护性和总体拥有成本。

要确定应用程序的体系结构质量，请考虑其结构和组织的以下方面：

其服务和组合的分解和粒度

用于定义和描述解决方案的拓扑

解决方案组件的相互依赖性

接口说明和合同

定义或利用的框架

实施

谢谢大家关注，转发，点赞和点在看。