软件开发应用体系结构(软件工程师应该知道的7种架构)

　　软件架构定义了应用程序的基本结构，深刻地影响了可伸缩性、可维护性和开发速度等因素。正确的选择对于项目的成功至关重要。下面是7种常见的架构：

　　Monolithic Architecture：传统方法。在这里，整个应用程序被构建为一个独立的单元。整体式设计简单、易于部署且具有成本效益—适合小型项目或快速原型设计。面向服务的体系结构（Service—Oriented Architecture，SOA）：服务是一个独立的功能单元，可以远程访问，并独立地对其进行操作和更新。SOA是一种软件体系结构风格，它侧重于使用离散的、可重用的服务来构建应用程序，这些服务通过网络上定义良好的协议相互通信。这强调了松耦合和互操作性，允许使用各种技术构建的不同系统轻松地协同工作。微服务架构：微服务通过将应用拆分为松散耦合的服务来实现可扩展性、故障隔离和独立部署。这使得它们非常适合需要灵活性和持续发展的大型复杂系统。然而，如果做得不正确，它们可能会非常昂贵，这就是为什么要投入更多精力的原因。事件驱动架构（EDA）：一种反应式方法，其中组件通过事件进行通信。EDA支持解耦系统、可扩展性和实时处理，使其适用于基于事件的应用程序和复杂的业务工作流。分层体系结构：一种将组件划分为逻辑层（如表示层、业务逻辑层和数据访问层）的体系结构风格。分层架构促进了关注点的分离、可维护性和代码可重用性。领域驱动设计（DDD）：一种侧重于对应用程序领域及其概念进行建模的方法。DDD强调领域专家和开发人员之间的协作，确保软件与问题领域紧密结合。这种方法可能会变得非常复杂和昂贵，这就是为什么人们建议只在有明确需要的时候才使用这种方法（我们将在本文后面谈到这一点）。无服务器架构：一种云原生方法，开发人员专注于编写代码，而无需管理底层基础设施。无服务器架构提供了可扩展性、成本优化和快速开发，但可能会导致强烈的平台依赖性。尽管如此，无服务器的广泛采用是一个明显的趋势，任何现代软件工程师都应该很好地理解它。1.单片架构本质：把应用程序想象成一个单独的大块。在单体中，所有组件—用户界面（UI），业务逻辑和数据库访问—都紧密交织在一起。在它们的简单性使得monoliths成为一个很好的默认设置，可以在需求不同时开始你的设计并切换到其他东西。

　　优点:

　　简单性：Monoliths在最初的开发、部署和测试都很简单。小型项目的成本效益：对于小型团队或范围有限的应用程序，整体式可以是一种快速有效的入门方式。

　　缺点：

　　可扩展性限制：随着应用程序的增长，扩展单体变得很麻烦。改变一个部分可能会影响整个系统。紧密耦合：组件是如此相互依赖，它阻碍了个人的更新或技术升级。这就像试图在一堵巨大的坚固的墙上修补一块有缺陷的砖。新开发人员的障碍：庞大的规模和相互联系使新团队成员更难跟上速度。任何建筑的复杂性都可能是巨石的10倍，因为所有东西都联系在一起。2.面向服务的体系结构（SOA）本质：旧的分布式体系结构的演变，重点是通过标准协议（如SOAP或Web服务）进行通信的可重用服务。

　　优点

　　松耦合：服务没有紧密地交织在一起，减少了依赖性问题。可重用性：服务被设计为“黑盒”，由组织内的不同应用程序使用。技术无关：SOA可以集成使用不同语言或平台构建的系统。引用Arcitura教育公司首席执行官托马斯埃尔的话，“SOA帮助我们摆脱了十年前的技术供应商锁定模型，推动了向互操作性级别标准的过渡。”

　　缺点：

　　复杂性：标准化协议的开销带来了设计和管理的复杂性。性能开销：与紧密耦合的系统相比，SOA的通信速度通常较慢。3.微服务架构本质：将你的整体分解成小的、独立的服务。每个微服务都专注于特定的业务功能，并拥有自己的数据库（如果需要）。服务通过定义良好的API（想想REST或消息传递协议）进行通信。

　　优点:

　　独立可扩展性：仅在重负载下扩展服务，而不是整个系统。弹性：如果一个微服务失败，它不会关闭整个应用程序。技术自由：每个微服务都可以使用最适合其任务的技术（语言，数据库）构建。

　　缺点：

　　增加的复杂性：分布式系统在设计、故障排除和监控方面固有地更加复杂。运营开销：部署和管理大量微服务会增加团队的工作量。网络依赖性：对网络通信的依赖性增加会带来延迟和潜在的故障点。4.事件驱动架构（EDA）本质：组件通过发布和订阅事件间接通信。事件代理协调这种通信。EDA可以很容易地与其他方法融合。你经常使用的大多数应用程序都有很强的事件驱动组件（点击社交媒体，输入消息，游戏等）。

　　优点:

　　极端解耦：组件不需要知道彼此，只需要知道它们关心的事件。可伸缩性：添加新的组件来监听现有的事件是很容易的。实时能力：非常适合需要对数据更改或用户交互做出即时反应的系统。

　　缺点：

　　思维转变：要求开发人员从事件的角度思考，而不是直接的函数调用。挑战：在复杂的EDA系统中跟踪事件流可能很棘手。最终一致性：并非系统的所有部分都可以在事件发生后立即更新，这取决于它是如何设置的。5.分层架构本质：另一种经典的方法，将应用程序组织成表示层、业务逻辑层和数据访问层。每个层只与下面的层交互，强制执行清晰的边界。这是之前提到的基本模式之一。

　　优点:

　　关注点分离：改进代码组织，使每一层更容易理解和修改。可维护性：包含在层中的更改通常不会影响系统的其余部分。可测试性：层可以独立测试。

　　缺点：

　　性能影响：通过多个层传递数据会增加开销。灵活性问题：严格的分层有时会阻碍需要跨层通信的横切问题。6.领域驱动设计（DDD）本质：DDD与其说是一种技术架构，不如说是一种设计哲学。它强调将软件系统建模为真实世界业务领域及其复杂性的直接反映。DDD的哲学是所有技术人员都应该牢记在心的东西，B/C太多的技术产品希望“颠覆”行业，但对该领域的理解不够。

　　优点:

　　使软件与业务保持一致：开发人员和领域专家使用共享的语言更深入的理解：开发过程导致对业务领域本身更深入的理解。不断发展的代码库：软件可以更有机地与业务一起发展。

　　缺点：

　　高前期投资：DDD需要专门的努力来理解领域并构建共享词汇表。专业知识通常是昂贵的，特别是对于金融，法律和医学等专业案件。复杂性：DDD引入了像Bounded Contexts、Aggregates和Ubiquitous Language这样的模式，增加了开发团队的复杂性。不是一刀切：DDD对于具有复杂业务逻辑的应用程序最为有利。对于更简单的系统来说，这可能是矫枉过正。7.无服务器架构本质：基于云的模型，您不直接管理服务器。代码在由事件（如HTTP请求、文件上传）触发的临时函数中运行，提供程序（AWS Lambda、Azure Functions）处理其余部分。

　　优点：

　　终极可扩展性：功能可根据需求自动扩展和缩小。这利用了规模经济-AWS购买堆和计算并给予一小部分批发比您自己购买和维护云功能更便宜。按次付费用途：您只为功能执行付费，不为空闲的服务器付费。更快的开发：专注于代码，而不是基础设施管理。

　　缺点：

　　供应商锁定：在无服务器提供商之间迁移可能具有挑战性。冷启动：一段时间不活动的功能在第一次触发时可能会有延迟。可扩展性和可观察性：对执行环境的有限控制带来了一些监控挑战。