系统架构设计的原则和模式

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）。客户端建立事件，并将其发送到事件队列，调停者接收事件并将其传递给事件通道。事件通道将事件传递给事件处理器，事件最终由事件处理器处理完成。

 

事件调停者不会处理也不知道任何业务逻辑，它只编排事件。事件调停者知道每种事件类型的必要步骤。业务逻辑或者处理发生在事件处理器中，事件通道、消息队列或者消息主题用于传递事件给事件处理器。事件处理器是自包含和独立的，解耦于架构。理想状况下，每种事件处理器应只负责处理一种事件类型。

一般，企业服务总线、队列或者集线器能够用做事件调停者。正确选择技术和实现可以下降风险。

代理者拓扑

不像调停者拓扑， 代理者拓扑 不使用任何集中的编排，而是在事件处理器之间使用简单的队列或者集线器，事件处理器知道处理事件的下一个事件处理器。

 

因其分布式和异步的性质， 事件驱动架构 的实现相对复杂。咱们须要面对不少问题，好比网络分区、调停者失败、从新链接逻辑等。因为这是一个分布式且异步的模式，若是你须要事务，那就麻烦了，你得须要一个 事务协调器 。 分布式系统 中的事务很是难以管理，很难找到标准的工做单位模式。

另外一个充满挑战的概念是契约。架构师声称服务的契约应该预先定义，而应变是很是昂贵的。

事件驱动架构分析：

• 敏捷性 ：因为事件和事件处理器之间解耦，而且可独立维护，所以这种模式的敏捷性很高。变化能够快速、轻松地完成，而不会影响整个系统。

• 易于部署 ：因为架构是解耦的，所以很容易部署。组件能够独立部署，而且能够在调停者上注册。部署在代理者拓扑上也至关简单。

• 可测试性 ：虽然独立测试组件很容易，但测试整个应用程序颇有挑战。所以端到端的测试是很难的。

• 性能 ：事件驱动架构性能很是好，由于它是异步的。此外，事件通道和事件处理器能够并行工做，由于它们是解耦的。

• 可伸缩性 ：事件驱动架构的伸缩性很是好，由于组件之间解耦，组件能够独立扩展。

• 易于开发 ：这种架构的开发不是很容易。须要明肯定义契约，错误处理和重试机制得处理得当。

3 微内核架构

微内核架构（Microkernel architecture）模式也被称为 插件架构（plugin architecture） 模式。这是产品型应用程序的理想模式，由两部分组成： 核心系统 和插件模块 。核心系统一般包含最小的业务逻辑，并确保可以加载、卸载和运行应用所需的插件。许多操做系统使用这种模式，所以得名微内核。

插件彼此独立，所以解偶。核心系统持有注册器，插件将本身注册其上，所以核心系统知道哪里能够找到它们以及如何运行它们。

 

这种模式很是适合桌面应用程序，可是也能够在Web应用程序中使用。事实上，许多不一样的架构模式能够做为整个系统的一个插件。对于产品型应用程序来讲，若是咱们想将新特性和功能及时加入系统，微内核架构是一种不错的选择。

微内核架构分析：

• 敏捷性 ：因为插件能够独立开发并注册到核心系统，微内核架构具备很高的敏捷性。

• 易于部署 ：依赖于核心系统的实现，能作到不须要从新启动整个系统来完成部署。

• 可测试性 ：若是插件开发是独立的，测试就能够独立且隔离地进行。还能够Mock核心系统来测试插件。

• 性能 ：这取决于咱们有多少插件在运行，但性能能够调优。

• 可伸缩性 ：若是整个系统被部署为单个单元，这个系统将难以扩展。

• 易于开发 ：这种架构不容易开发。实现核心系统和注册会很困难，并且插件契约和数据交换模型增长了难度。

4 微服务架构

尽管微服务的概念还至关新，但它确实已经快速地吸引了大量的眼球，以替代总体应用和面向服务架构（SOA）。其中的一个核心概念是具有高可伸缩性、易于部署和交付的独立部署单元（Separately Deployable Units）。最重要的概念是包含业务逻辑和处理流程的服务组件（Service Component）。拿捏粒度设计服务组件是必要而具备挑战性的工做。服务组件是解耦的、分布式的、彼此独立的，而且可使用已知协议来访问。

微服务的发展是由于总体应用和面向服务应用程序的缺陷。总体应用程序一般包含紧耦合的层，难以部署和交付。好比，若是应用程序总在每次应对变化时垮掉，这是一个因耦合而产生的大问题。微服务将应用程序分解为多个部署单元，所以很容易提高开发和部署能力，以及可测性。虽然面向服务架构很是强大，具备异构链接和松耦合的特性，可是性价比不高。它很复杂、昂贵，难于理解和实现，一般对于大多数应用程序来讲矫枉过正。微服务简化了这种复杂性。

 

跨服务组件的代码冗余是彻底正常的。开发微服务时，为了受益于独立的部署单元，以及更加容易的部署，咱们能够违反DRY原则。其中的挑战来自服务组件之间的契约，以及服务组件的可用性。

微服务架构分析：

• 敏捷性 ：因为服务组件能够各自独立开发，彼此没有耦合，所以微服务架构具备很高的敏捷性。独立部署单元可以对变化做出迅速的反应。

• 易于部署 ：相比其余的架构模式，微服务的优点是服务组件便是单独部署单元。

• 可测试性 ：服务组件的测试能够独自完成。微服务的可测试性很高。

• 性能 ：依赖于服务组件和这种特定模式的分布式性质。

• 可伸缩性 ：独立部署单元自然具有很好的伸缩性。

• 易于开发 ：每一个服务组件能够各自独立实现。

https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247484493&idx=1&sn=1f4433d08a42e8ea53a1c99545a57489&chksm=fbb28db3ccc504a5cb1d68f320865c62c0159574d65004e32912e80c61d2319d25d78fb07564&mpshare=1&scene=1&srcid=0224Maz4s6stgNgFihBAgFAW&key=819d0d70e718cb3683600c532ab633542d457009ef5350bbada96c2ec3fa5c28ff5707291f23d503a6dd69137ae867bea6d40099dc093b292bed02292a3106e64056ea4c6bdd2c9fcb2a5b18128cd272&ascene=0&uin=OTIwNjc0MTU%3D&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.12.4+build(16E195)&version=12010110&nettype=WIFI&lang=zh_CN&fontScale=100&pass_ticket=tr9ThSjWvhTKVvoxS06JQ7ltNk%2BtCz60yYV5xG08%2F%2Bk%3D