什么是系统架构（Architecture）设计不仅仅指外观和手感，还包括操作方式。——乔布斯系统架构（SystemArchitecture）、软件架构（SoftArchitecture）是IT领域的常用名词，架构设计是软件系统构建过程中极为关键的一环。为什么系统架构很重要？常见的架构模式有哪些？关注【CodeGeByte】了解不同架构设计所采用的不同设计哲学。让我们看一下常见的架构模式：Client-Server、PeertoPeer、MVC、Layered、Distribute-Cluster、Micro-Service、Even-Source、Hexagonal，并一一分解。Architecture，架构的本意，其实软件架构的概念就是从架构派生出来的。建筑是与建筑物的设计和建造相关的艺术和技术的综合。建筑学是一门跨越工程技术和人文学科的学科。它研究建筑的可利用空间、可欣赏的形象，以及围绕空间的一系列问题以及形象如何建立、调整和美化。而其研究的对象不仅仅是建筑本身，更重要的是研究人们对建筑的要求以及如何满足这些要求，并从无到有地研究相应的建筑实体的规划、设计和实施。建筑学研究建筑物的规划、设计和实施。软件架构研究软件的规划、设计和实现。在架构设计中，根据业务、技术、组织、灵活性、可扩展性和可维护性等因素，将应用系统划分为不同的部分，使这些部分能够分工协作，满足特定的需求。.架构贯穿于系统实现的全过程，是软件系统实现的主要参考依据，是软件系统实现的蓝图。软件系统的规划、设计和实施是根据体系结构的设计来组织和实施的。为什么系统架构很重要？我们知道摩尔定律——计算机硬件性能大约每两年翻一番的速度。但是，软件开发过程并没有这样一个提速过程，开发成本并没有降低。系统架构的设计方法论和设计模式在不断变化，这一重要过程还没有一个完全可靠、一劳永逸的解决方案。为什么？软件开发过程的特殊挑战是什么？有以下几点：复杂性（Complexity）软件可以说是人类创造的最复杂的系统类型。软件的各个模块之间存在着各种显式或隐式的依赖关系。随着系统的增长和模块的增多，这些关系的数量往往呈几何级数增长。而了解如何使用这些复杂性的人并没有太大变化。2.隐形（Invisibility）软件工程师可以直接看到源代码，但源代码并不是软件本身。而且静态源代码不同于运行系统，软件运行环境的复杂性也增加了软件系统的不可预测性。软件系统不能用简单的方式描述。设计文档、描述、流程图、架构图只是为了让复杂的软件系统更容易理解和交流，但仍然不能完整地描述系统的全貌。3.可变性修改软件似乎很容易。修改软件比修改硬件容易得多，修改软件系统比修改高楼容易得多。所以人们很自然地期望软件系统能够适应未来的变化。但是变化是复杂的，环境也是复杂的。这些复杂的情况往往会使一个容易修改的东西变得越来越难。4.一致性一个软件系统不能独立存在。它始终在硬件上运行，必须服从系统中其他组件的要求，以及用户和行业的要求。软件系统的上述特点使得系统架构的设计显得尤为重要。系统架构设计通过以下方式解决上述软件挑战：抽象抽象是系统架构设计中的一个重要步骤。抽象是对复杂概念的简化。在最高层，软件系统被抽象为对象和过程两个高层概念。对象可以是系统、组件、接口、类、方法等不同层次的概念，进程是系统运行的方式和流程。抽象将具体事物概念化，从而定义边界，使其易于理解和交流。分解分解与组合相互作用。分解是将高层抽象概念分解成低层抽象概念，即将实体分解成小的部分或组件。在处理复杂性的众多方法中，“分而治之”是一种基本策略。把它分解成小问题，直到每个小问题都能解决。语言语言的边界就是世界的边界。领域语言和设计语言决定了系统的内容、方式和原因。语言使系统在文档、设计图纸等易于理解的层面上变得可见，也使系统的可变性被调节在可预测和可控的范围内。几种架构模式Client-Server有了Internet，就有一种客户端-服务器模式。客户端-服务器模式以请求-响应模式工作。客户端发送请求信息，服务器端接受请求，进行相应的处理，然后返回响应信息。我们访问的所有Internet站点都是以这种方式构建的。在那个桌面程序流行的年代，互联网并没有今天这么发达。Client-Server只代表DesktopClient-Server模式，使用浏览器的方式称为B-S模式，即Browser-Server模式。今天Browser、DesktopApplication、MobileApplication、MobileWeb等统称为Client。因此，我们目前访问的大部分网站，如新闻咨询网站、博客网站等，都属于这种模式。PeertoPeer端到端服务模式（PeertoPeer，简称P2P），又称“点对点模式”，是指通过互联网将个人与个人连接起来，绕过中央平台的模式并直接提供服务和完成交易。P2P的早期含义是计算机通信领域的一种“点对点网络协议”。参与者直接共享自己拥有的部分硬件资源（包括处理能力、存储能力、网络连接能力、打印机等），这些共享资源可以通过互联网直接被其他对等节点（Peer）访问，无需经过网络统一的中间体。网络中的参与者既是资源（服务或内容）提供者（Server），又是资源获取者（Client）。P2P模式在文件共享和下载、计算和存储、即时通信和协作共享等领域很流行。MVCModel-View-Controller，MVC架构是面向对象编程的一大进步。服务将逻辑分为三个不同的组件：模型——模型或数据通常存储在数据库中，并在内存中进行逻辑操作。视图——用于用户交互和数据显示的用户可见组件，例如WebGUI。Controller——逻辑操作，连接Model和View的组件，操作Model逻辑和View交互显示逻辑。MVC模式在客户端和H5前端都比较流行。它一直是Web后端的流行架构模式。JavaWeb领域催生了Struts、SpringMVC等Web后台框架，让曾经复杂的Web开发变得极其简单。随着前后端的逐渐分离，之前的后台MVC已经将View完全交给了前端，前后端通过相关协议进行通信，完成View数据的传输。Layered分层架构是使用最广泛的架构模式。几乎每一个软件系统都需要通过层级（Layer）来隔离不同的关注点（ConcernPoints），以应对不同需求的变化，让这样的变化可以独立进行。单一职责原则是系统设计和开发中的一个重要原则。分层架构始终遵循单一职责原则。不同层相互隔离，职责不同。说到分层架构，最广为人知的就是经典的三层架构。经典的三层架构自上而下由用户界面层（UserInterfaceLayer）、业务逻辑层（BusinessLogicLayer）和数据访问层（DataAccessLayer）组成。三层架构是简单的Client-Server架构的升级。三层架构的经典和流行，以及大量的Web后台框架与三层架构的贴近，使得Web后台的开发如此简单，一个刚入门的开发者就可以进行Web发展。也正是因为如此，大部分Web开发者的思维都受此局限，从而成为人人嘲讽的CRUD-Boy。随着MIS系统时代的远去，三层架构在某些领域已经开始不能成为“灵丹妙药”。去掉经典的三层架构。在领域驱动设计中，EricEvans设计了一个经典的四层架构，在用户界面层和业务逻辑层之间引入了一个新的层，即应用层（ApplicationLayer）。其余层也相应调整。上面提到的Distribute-Cluster架构都是单体架构下的。从服务的部署方式和运行方式来考虑单体架构和多服务架构。单体架构有以下优点：易于开发：借助开发框架，单体应用的开发极其简单，开发者很少需要考虑系统、部署、网络层面的问题。易于测试：单体应用单进程部署，环境简单。只要服务启动，就可以测试所有功能。易于部署：通常只需要将应用程序打包成一个简单的包。易于水平扩展：只需将包部署到多个服务。单体应用的缺点：维护成本增加：随着需求的增加，单体系统会越来越臃肿，维护的复杂度也会增加。持续交互周期长：一方面难以维护，另一方面单体应用的并行开发和测试会非常困难，单体应用非常不适合快速迭代敏捷发展。可扩展性差：由于系统臃肿，系统的可扩展性会变得困难。系统升级也需要非常谨慎。对新人不友好。分布式系统拆分：随着互联网的飞速发展，一方面互联网应用的访问量和数据量大幅增加。另一方面，应用的迭代速度也越来越快。单一的应用模式已经不适合互联网的快速发展。这样，后台分布式集群架构越来越流行。Micro-Service微服务并没有严格的定义。以下是MartinFowler对微服务的描述：微服务架构是一种架构模式，提倡将单个应用程序划分为一组相互协调、相互配合，为用户提供最终价值的小服务。每个服务都运行在自己的进程中，服务之间使用轻量级的通信机制（通常基于HTTPRESTfulAPI）进行通信。每个服务都是围绕特定业务构建的，可以独立部署到生产环境中。微服务通常具有以下特点：职责单一：业务独立、团队自治。单一职责的服务应该有核心领域，高内聚，低耦合，与其他系统和领域的边界清晰。轻量级通信：通信应该是简单和轻量级的。语言无关，平台无关。独立性：独立开发、独立测试、独立部署。所有的选择都是一个权衡的过程。微服务解决了单体应用的很多问题，自然也带来了相应的问题。分布式集群环境复杂，基于它的微服务架构也会有相应的复杂性。随着微服务的普及，微服务的很多问题已经被越来越多的框架和服务解决了。下面以SpringCloud技术栈为例：SpringBoot：单一服务，快速创建项目，快速集成各种框架，易于测试，易于部署。Feign：微服务独立部署，通过相关协议进行通信。Feign是一个简单的基于HTTPrestful的声明式通信框架。Eureka：独立服务越来越多，服务实例越来越多。服务治理是必须的，Eureka提供了高可用的服务注册和服务发现功能。Ribbon：Feign只负责通信，Ribbon提供客户端负载均衡，属于系统优化的一部分。Hystrix：微服务会带来服务之间复杂的依赖关系，分布式和集群的复杂性也会带来很多不可预知的问题。为了防止在复杂的网络和复杂的系统中出现问题导致整个系统雪崩状态，Hystrix是SpringCloud系统中的一个优秀的断路器，可以在系统出现问题时进行服务降级以及防止整个系统崩溃。Zuul：统一网关。统一网关采用Facade模式对外提供友好的接口。微服务之后，服务会越来越复杂。为了降低外部系统调用的复杂度，统一网关是一种常见的解决方案。Config：服务划分越多，配置越多。Springcloudconfig提供了统一的配置管理。Sleuth：服务监控和治理。监控是复杂系统的必要基础设施。系统感知、问题发现、性能定位都需要监控的支持。Even-Source事件溯源是最新流行的应用程序架构模式。事件溯源将应用程序所做的状态更改建模为不可变序列或事件“日志”。事件源不是当场修改应用程序的状态，而是将触发状态更改的事件存储在不可变的日志中，并将状态更改建模为对日志中事件的响应。CQRS模式通常基于事件溯源模式。在传统架构中，使用相同的数据模型查询和更新数据库。这非常简单，非常适合基本的CRUD操作。但是，在更复杂的应用程序中，这种方法会变得很麻烦。例如，在读取端，应用程序可能会执行大量不同的查询，返回具有不同形状的数据传输对象(DTO)。对象映射可能会变得复杂。在编写方面，模型可能会实现复杂的验证和业务逻辑。结果，该模型执行了太多操作并且过于复杂。CQRS（CommandQueryResponsibilitySegregation）将读写操作分离成不同的模型，使用命令更新数据，使用查询读取数据。Hexagonal六边形架构，也称为“端口和适配器模式”，是AlistairCockburn提出的一种具有对称特征的架构风格。在该架构中，系统通过适配器与外部进行交互，将应用服务和领域服务封装在系统内部。六边形架构由以下三个部分组成：端口：可分为输入和输出，是系统与其他系统交互的接口。适配器：与其他系统的适配层，一方面防止核心系统和域受外界影响，即防腐；另一方面，它促进了API的使用。领域：应用程序和模型是程序的核心。六边形架构的核心思想是应用程序通过“端口”与外界进行交互。在传统的分层架构中，很容易跨越层与层之间的边界，将业务逻辑渗透到其他层中。六方结构重要的是“界”和“场”。六边形架构的初衷是为了解决技术与业务系统的解耦问题，以及技术与技术之间的解耦问题。标准化的端口协议和适配器的实现，服务本身的独立性和完备性。
