企业架构设计的痛点分析.docx

企业架构设计的痛点分析本文给出了软件架构演化过程中出现的4种经典架构，就每种架构，分析了其主要特点并在几个度量维度给出结论。在文章的最后给出了4种架构的多维对比。1 分层架构分层架构是最常见的架构，也被称为n层架构。多年以来，许多企业和公司都在他们的项目中使用这种架构，它已经几乎成为事实标准，因此被大多数架构师、开发者和软件设计者所熟知。分层架构中的层次和组件是水平方向的分层，每层扮演应用程序中特定的角色。根据需求和软件复杂度，我们可以设计N层，但大多数应用程序使用3-4层。有太多层的设计会很糟糕，将导致复杂度的上升，因为我们必须维护每一层。在传统的分层架构中，分层包括表现层、业务或者服务层，以及数据访问层。 表现层负责应用程序的用户交互和用户体验（外观和视觉）。通常我们会使用数据传输对象（Data Transfer Object）将数据带到这一层，然后使用视图模型（View Model）渲染到客户端。业务层接收请求并执行业务规则。数据访问层负责操作各种类型的数据库，每个访问数据库的请求都要经过这一层。分层无需知道其他层如何去做，比如业务层无需知道数据访问层是如何查询数据库的，相反，业务层在调用数据层的特定方法时，只需关注需要部分数据还是全部数据。这就是我们所说的关注点分离。这是非常强大的功能，每层负责其所负的责任。分层架构中的核心概念是管理依赖。如果我们使用依赖倒置原则和测试驱动开发(Test Driven Development)，我们的架构会有更好的健壮性。因为，我们要保证所有可能的用例都有测试用例。我们需要这样的冗余，即使业务层没有处理业务规则，也要通过业务层来调用数据层，这叫分层隔离。对于某些功能，如果我们从表现层直接访问数据层，那么数据层后续的任何变动都将影响到业务层和表现层。分层架构中的一个重要的概念就是分层的开闭原则。如果某层是关闭的，那么每个请求都要经过着一层。相反，如果该层是开放的，那么请求可以绕过这一层，直接到下一层。分层隔离有利于降低整个应用程序的复杂度。某些功能并不需要经过每一层，这时我们需要根据开闭原则来简化实现。分层架构是SOLID原则的通用架构，当我们不确定哪种架构更合适的时候，分层架构将是一个很好的起点。我们需要注意防止架构陷入污水池反模式。这种反模式描述了请求经过分层，但没做任何事或者只处理了很少的事。如果我们的请求经过所有分层而没有做任何事，这就是污水池反模式的征兆。如果20%的请求只是经过各层，而80%的请求实际做事，这还好，如果这个比率不是这样的，那么我们已经患上反模式综合征。此外，分层架构可以演变为巨石应用（Monolith），导致代码库难以维护。分层架构分析：敏捷性：总体敏捷性是指对不断变化的环境作出反应的能力。由于其整体风格（Monolith）的性质，可能会变得难以应对通过所有层的变化，开发者需要注意依赖性和分层分离。易于部署：大型应用程序的部署会是个麻烦。一个小要求，可能需要部署整个应用程序。如果能做好持续交付，可能会有所帮助。可测试性：使用Mocking和Faking，每一层可以独立测试，因此测试上很容易。性能：虽然分层应用程序可能表现良好，但是因为请求需要经过多个分层，可能会存在性能问题。可伸缩性：因为耦合太紧以及整体风格（Monolith）的天生特质，很难对分层应用程序进行伸缩。然而，如果分层能够被构建为独立的部署，还是可以具备伸缩能力的。但是，这样做的代价可能很昂贵。易于开发：这种模式特别易于开发。许多企业采用这种模式。大多数开发者也都知道、了解，并且可以轻松学习如何使用它。2 事件驱动架构事件驱动架构（Event Driven Architecture）是一种流行的分布式异步架构模式，用于创建可伸缩的应用程序。这种模式是自适应的，可用于小规模或者大规模的应用程序。事件驱动架构可以与调停者拓扑（Mediator Topology）或者代理者拓扑（Broker Topology）一起使用。理解拓扑的差异，为应用程序选择正确的拓扑是必不可少的。调停者拓扑调停者拓扑需要编排多种事件。比如在交易系统中，每个请求流程必须经过特定的步骤，如验证、订单、配送，以及通知买家等。在这些步骤中，有些可以手动完成，有些可以并行完成。通常，架构主要包含4种组件，事件队列（Event Queue）、调停者（Mediator）、事件通道（Event Channel）和事件处理器（Event Processor）。客户端创建事件，并将其发送到事件队列，调停者接收事件并将其传递给事件通道。事件通道将事件传递给事件处理器，事件最终由事件处理器处理完成。事件调停者不会处理也不知道任何业务逻辑，它只编排事件。事件调停者知道每种事件类型的必要步骤。业务逻辑或者处理发生在事件处理器中，事件通道、消息队列或者消息