系统架构（System Architecture）、软件架构（Soft Architecture）是IT领域常见的名词，架构设计是软件系统构建过程中极其关键的一部分。

  系统架构为什么重要？常见的架构模式都有哪些？本文将带你了解不同的架构设计所运用的不同设计哲学。

  Architecture，原意建筑学，其实软件架构的概念就是源于建筑学。建筑学是建筑物设计和建造相关的艺术和技术的综合。建筑学是一门横跨工程技术和人文艺术的学科。它研究的是建筑物可资使用的空间、可供欣赏的形象，以及围绕空间、形象怎么样产生确立、调整美化等的一系列问题。并且其所研究的对象不仅是建筑物本身，更主要的是研究人们对建筑物的要求及其如何得以满足，研究建筑物实体从无到有的产生过程中相应的策划、设计、实施等。

  在架构设计中，依据业务、技术、组织、灵活性、可扩展性以及可维护性等因素，将应用系统区别划分成不同的部分，使这些部分之间相互分工、相互协作，从而完成特定的需求。架构贯穿系统实现的整一个完整的过程，是软件系统实现的主要参考，是软件系统实现的蓝图。软件系统的规划、设计和实施依架构的设计而组织实施。

  我们知道摩尔定律——计算机硬件的能力大致每两年提高一倍的速度发展。然而软件开发的流程却没有这样的提速过程，开发成本也没下降，系统架构的设计方法论和设计模式一直在变化，而这个重要的流程依旧没有一个完全可靠和一劳永逸的解决方案。为什么？软件开发过程有什么特别的难题？有下面几点：

  软件可以说是人类创造的最复杂的系统类型。软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。而理解运用这些复杂性的人并没有太多的变化。

  软件工程师能直接看见源代码，但是源代码不是软件本身。并且静态的源代码和运行的系统也不一样，软件运行环境的复杂性也增加了软件系统的不可预测性。软件系统不能以简单的方式描述出来，设计文档、描述说明、流程图、架构图这些也不过是让复杂的软件系统以更易于理解和易于交流的方式展示，却依旧不能完全描述系统的全貌。

  修改软件看似很容易，修改软件比修改硬件看似容易多了，修改软件系统也比修改一座巍立建筑物看似容易得多。所以人们自然地期待软件系统能适应未来的变化。但变化却是复杂的，环境也是复杂的，这些复杂的情况往往让一个易于修改的事情却变成一件越来越困难的事情。

  软件系统不能独立存在，它总是运行在硬件上面，也总是要服从系统中其他组成部分的要求，也要服从用户的要求、行业的要求。

  软件系统的以上特性使得系统架构的设计显得尤其重要。系统架构设计通过以下方式来解决上面的软件难题：

  抽象是系统架构设计的重要一步。抽象是将复杂的概念简单化。在最高层次上，将软件系统抽象为对象和过程两个高层次概念。对象可以是系统、组件、接口、类、方法等等不一样的层次的概念，过程是系统运行的方式和流程。抽象使具象的事物概念化，从而确定边界，易于理解，易于交流。

  分解与组合相互作用。分解就是将高层次的抽象概念分解成低层次的抽象概念，就是将实体分成小的部件或组成部分，在应对复杂度的诸多方式中，”分而治之“是一项基本策略，它把大问题持续分解成小问题，直到每一个小问题都能够解决为止。

  语言的边界就是世界的边界。领域语言、设计语言确定系统的what、how和why。语言使系统显见于文档、设计图等等易于理解的层次，也使得系统的易变性被规范在可预见和可控制的范围之中。

  因此我们当前访问的大部分网站，如新闻咨询网站、博客网站等等都属于这种模式。

  端对端服务模式（Peer to Peer，简称P2P），亦称为“点对点模式”，是指利用互联网将个人与个人连接起来，绕开中心平台而直接提供服务、完成交易的模式。P2P的早期含意是计算机通信领域中的“对等网络协议”，它打破了传统的Client/Server（C/S）模式，使得成千上万台彼此连接的计算机都处于对等地位，网络的参与者直接共享他们所拥有的一部分硬件资源（包括解决能力、存储能力、网络连接能力、打印机等），这些共享资源利用互联网，能被其它对等节点（Peer）直接访问而无需经过统一的中间体。在该网络中的参与者既是资源（服务或内容）提供者（Server），又是资源获取者（Client）。

  Model-View-Controller，MVC架构是面向对象编程的一大进步。服务将逻辑划分为三个不同的组件：Model——模型，即数据，通常存储在数据库中，在内存中进行逻辑操作。View——用户可见的组件，用于用户交互和数据展示，如Web GUI。Controller——逻辑操作，连接Model和View的组件，操作Model逻辑和View交互展示逻辑。

  MVC模式在客户端和H5前端都比较流行。也一直是Web后端流行的架构模式，在Java Web领域催生的Struts、Spring MVC等Web后台框架，让曾经复杂的Web开发变成一种异常简单的开发。

  随着前后端渐渐分离，之前的后台MVC已经将View完全交于前端，前后端通过相关协议通信，完成View数据的传输。

  分层架构是运用最为广泛的架构模式，几乎每个软件系统都需要通过层（Layer）来隔离不同的关注点（Concern Point），以此应对不一样的需求的变化，使得这种变化可以独立进行。

  单一职责原则，是系统设计开发重要的原则。分层架构就时时遵循单一职责原则。不同的层次相互隔离，承担不同的职责。

  说起分层架构，最让人熟知的就是经典的三层架构。经典三层架构自顶向下由用户界面层（User Interface Layer）、业务逻辑层（Business Logic Layer）与数据访问层（Data Access Layer）组成。三层架构是简单Client-Server架构的升级。

  三层架构的经典和流行，以及大量Web后台框架对三层架构的靠近，使得Web后台开发简单到一个刚刚入门的研发人员就能够直接进行web开发。也正因为此，使得大部分web研发人员的思维受限于此，从而成为人人调侃的CRUD-Boy。随着MIS系统时代的渐远，三层架构也开始在一些领域无法成为“银弹”。

  除去经典的三层架构。在领域驱动设计中，Eric Evans设计了一种经典的四层架构，其在用户界面层与业务逻辑层之间引入了新的一层，即应用层（Application Layer）。其余几层也相应地有所调整。

  以上所提的架构都是在单体架构之下。单体架构和多服务架构是从服务的部署模式、运行模式来考虑。

  易于开发：借助于开发框架，单体应用的开发极其简单，研发人员也很少需要仔细考虑系统、部署、网络等层次的问题。

  易于测试：单体应用部署在一个进程中，环境简单。只要服务启动就可以测试所有的功能。

  维护成本增加：随着需求的增多，单体系统将越来越臃肿，维护的复杂性也将越来越大。

  持续交互周期长：一方面维护困难，另一方面单体应用在并行开发，并行测试上将十分困难，单体应用十分不适合快速迭代的敏捷开发。

  扩展性差：由于臃肿的系统，将导致系统扩展性变难。系统的升级也需要十分谨慎。

  随着互联网的加快速度进行发展，一方面互联网应用访问量级大增，数据量大增。另一方面，应用的迭代速度也不断变快。单体应用的模式已经不适合互联网的快速发展。这样，后台分布式集群架构越来越流行。

  微服务并没有一个严格的定义。以下是Martin Fowler描述的微服务：

  微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户更好的提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，还可以被独立地部署到生产环境。

  单一职责：业务独立，团队自主。职责单一的服务应该具有核心的领域，高内聚、低耦合，与其他系统和领域确定明确的边界。

  一切选择都是权衡的过程。微服务解决了单体应用的许多问题，自然也会带来相应的问题。分布式和集群的环境是复杂的，基于此的微服务架构也将拥有相对应的复杂度。

  随着微服务的流行，微服务的很多问题也被慢慢的变多的框架和服务解决掉了。我们以Spring Cloud技术栈为例：

  SpringBoot：单体服务，快速创建项目，快速集成各种框架，易于测试，易于部署。

  Feign：微服务独立部署，通过相关协议通信。Feign就是一个简单的申明式通信框架，基于HTTP restful。

  Eureka：独立服务慢慢的变多，服务实例也慢慢变得多。服务治理便是必须的，Eureka提供高可用的服务注册和服务发现功能。

  Ribbon：Feign只负责通信，Ribbon提供客户端负载均衡，是系统优化的部分。

  Hystrix：微服务将带来服务间复杂的依赖关系，分布式和集群的复杂度也将带来许多难以预料的问题。为防止复杂网络和复杂系统某一点的问题导致整个系统的雪崩状态，便有了Hystrix，Hystrix是Spring Cloud体系中优秀的断路器，可以在系统发生问题时进行服务降级，防止整体系统崩溃。

  Zuul：统一网关，统一网关是以Facade模式，对外提供友好的接口，微服务化之后，服务将慢慢的变多，越来越复杂，为降低外部系统调用的复杂度，统一网关就是常用解决方案。

  Sleuth：服务监控和治理。监控是复杂系统必需的基础设施。系统感知、问题发现、性能定位都需要监控的加持。

  事件溯源是最新流行一种应用程序体系结构模式。事件源将应用程序进行的状态更改建模为事件的不可变序列或“日志”。事件源不是在现场修改应用程序的状态，而是将触发状态更改的事件存储在不可变的日志中，并将状态更改建模为对日志中事件的响应。

  CQRS模式通常基于事件溯源模式。在传统的体系结构中，使用同一数据模型查询和更新数据库。这十分简单，非常适用于基本的CRUD操作。但是，在更复杂的应用程序中，此方法会变得难以操作。例如，在读取方面，应用程序可能执行大量不同的查询，返回具有不一样形状的数据传输对象(DTO)。对象映射可能会变得复杂。在写入方面，模型可能实施复杂验证和业务逻辑。结果，模型执行太多操作，过度复杂。

  CQRS（命令查询的责任分离Command Query Responsibility Segregation）将读取和写入操作分成不同的模型，使用命令更新数据，并使用查询来读取数据。