软件开发可以被描述为一个复杂的系统过程，需要各个技术领域以及相关业务方面的专业知识。就像总体规划的蓝图一样，通过定义软件的体系结构，可以促进软件开发过程的这个组成部分。为什么我们需要软件架构>TheBigBallofMud被早期的开发人员用来设计无架构的软件，起初看起来像是没有规划开销和更快的原型制作的好处。然而，随着他们对流程的深入，该软件变得像泥球一样不灵活且难以管理。随着每次更改的成本越来越高，这种方法被称为“大泥球”。随着时间的推移，这种项目变得难以管理，因此每次新的迭代都会大大增加维护成本。这限制了软件的开发超出了项目开始时最初定义的范围。在多年的软件设计中，开发人员提出了稳健的体系结构方法来避免无体系结构的软件设计问题（也称为“泥球”）。以下是一些最著名的分层架构多层架构面向服务的架构(SOA)微服务??架构分层架构这种方法基于关注点分离原则。软件设计分为重叠层。每一层都有专门的职责。该体系结构将软件分为以下几层：表示层业务逻辑层数据链路层表示层具有与外界交互的用户界面。这也负责提供用户体验，因为这是唯一暴露给最终用户交互的层。顾名思义，业务逻辑层包含软件应用程序的业务逻辑。该层将UI/UX与业务相关的计算分开，从而提供了根据不断变化的业务需求修改逻辑的灵活性，而不会影响其他层。数据链路层负责与持久性存储交互，例如数据库和与领域无关（即与业务无关）的杂项数据处理。数据和控制从设计的每一层流向另一层。这些层还增加了设计中的抽象级别。由于稳定性在一定程度上与抽象成正比，因此也在一定程度上增加了软件的稳定性。>架构的分层表示优点：与其他方法相比更易于实施由于层之间的关注点分离，在抽象层之间提供隔离在其他层之间提供隔离，以免修改一层由于低耦合，软件更改更易于管理缺点：可扩展性不强以这种方式构建的软件将倾向于具有整体结构，缺乏修改的便利性，即使不需要从某些层传递数据，数据也必须从一层到另一层流出。这个问题被称为“污水池问题”多层架构这种架构方法根据客户端-服务器通信原则将软件套件分成几层。架构在n层系统中可以有一层或两层，分离数据提供者和消费者之间的责任。它利用请求-响应模式在定义的层之间进行通信。与分层架构不同，它提供的可扩展性可以是水平的（通过高性能节点扩展网络）或垂直的（通过提高个体性能来扩展每个节点）。既可充当客户端又可充当服务器，无需系统间通信(ISC)即可简化部署。因此，提供了良好的通信速度。这样的系统只适合小规模的单用户应用，不适合复杂的多用户应用。2-tiersystem>2-TieredArchitecture这样的系统由两台物理机组成，一台服务器和一台客户端。它提供数据管理操作与数据处理和表示操作之间的隔离。客户端拥有表示层、业务逻辑层和数据链路层。服务器像数据库一样存储数据3层/n层系统>3层架构像这样的架构在水平和垂直方向上都具有高度可扩展性。通常，实施n层架构的成本更高，但可以提供高性能。因此，它在大型复杂的软件解决方案中是首选。它可以与高级面向服务的架构风格相结合，以生成高度复杂的模型。当软件很复杂并且需要性能和可扩展性时，建议使用此体系结构，因为就资源和时间而言，这可能是一种更昂贵的方法。面向服务的体系结构SOA是一种基于服务的体系结构模型，其中组件和应用程序使用定义明确的服务进行通信。它由5个元素组成，即：ServiceServiceBusServiceLibraryServiceDirectorySOASecuritySOAGovernance客户端使用标准协议和数据格式通过网络发送请求。这个由ESB处理的请求可以被认为是SOA的核心。ESB负责编排和路由。ESB使用服务存储库将请求定向到专用服务。此专用服务可以与其他服务或数据库交互以组成响应负载（响应数据）。完整的请求-响应调用符合SOA治理和安全规则，以完成确保安全性和正确性的事务。>https://www.udemy.com/course/software-architecture-and-design-essentials/服务一般分为两种：原子服务：提供不能进一步分解的功能组合服务：多个大气服务的集合,提供复杂的复合功能服务类型：服务可以有以下几种类型，即：实体服务领域服务实用程序服务集成服务应用程序服务安全服务服务架构。简而言之，微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行并通过轻量级机制（通常是HTTP资源API）进行通信。沟通。这些服务围绕业务功能构建，可以通过完全自动化的部署机制独立部署。这些服务几乎没有集中管理，可以用不同的编程语言编写，使用不同的数据存储技术。它基于服务组件化的原则。该体系结构将软件分解为可定义为服务的各种组件。每个服务都有单一的职责，并且每个服务本质上是隔离的。一项服务的更改不应影响其他服务。>https://divante.com/blog/monolithic-architecture-vs-microservices/微服务由能够独立扩展的隔离、简洁和细粒度微服务的架构组合组成。该架构由5个部分组成，如下所示：服务服务总线外部配置API网关容器微服务特性微服务架构应包括以下特性：通过服务进行组件化围绕业务能力进行组织产品不是项目智能端点和哑管道去中心化治理去中心化数据管理基础设施自动化失败设计进化设计建议与不同的团队分别开发不同的微服务，并允许每个微服务随着时间的推移同时进化，就像空气中的各种气泡。由于数据通信是根据标准协议和数据格式进行的，因此一项服务的结构不会影响通用服务的功能。>不同架构的比较好处：隔离度高，耦合度低增强模块化一个服务的故障不会影响整个系统，因为它们是隔离的提供高灵活性提供高可扩展性易于修改可以加速进化迭代，可以更好地处理错误避免分层架构和数据仅通过相关服务流动的问题缺点：不同服务之间通信时失败的可能性更高。难以管理大量服务。需要解决的问题如网络延迟和负载平衡以及分布式架构等其他问题在分布式环境中复杂的测试实施需要更多时间结论每种软件架构方法的设计动机都是为了解决先前架构中突出的问题。正确了解不同的方法可以帮助您为项目设计高效的软件架构。“虽然没有完美的软件架构，但任何架构方式只要能满足项目的功能和非功能需求，都可以认为是比较完美的。”原文链接：https://medium.com/swlh/everything-aboutsoftware-architecture-dfd2b9351ef4
