软件开发基础架构软件开发系统架构

转载

karen 2024-08-01 22:04:50

文章标签 软件开发基础架构数据库 python java 设计模式 文章分类 架构后端开发

软件架构开发架构

好的，因此您将开始开发新的基于Web的一流软件应用程序。您拥有适当的敏捷方法，开发团队可以开始布局软件体系结构。

这将是开发过程中要克服的第一个障碍。使软件设计过于严格会与敏捷软件开发方法冲突，并会导致过多的Big Design Up Front 。使设计过于宽松或无法完全实现设计的边界会使开发人员感到困惑。在此博客文章中，我们将更深入地研究四种软件体系结构，并讨论其优缺点，最佳用例。

有时，可以将多个体系结构和模式组合到一个系统中，并且将完美的设计融入您的解决方案中通常感觉就像是一门艺术。查看我们关于构建模块化整体的文章，以深入了解这种混合系统。

分层架构

这可能是最常用的体系结构，因为它以数据源为中心。许多业务应用程序无非就是一种处理表中存储的数据的方法，而表之间则包含一些业务逻辑。

安排代码，以便数据或输入进入顶层，并在每一层向下进行直到到达底层。每个层都有自己的任务和责任，程序员可以同时在不同的层上工作。

软件开发基础架构软件开发系统架构_设计模式

模型视图控制器（MVC）结构是分层软件体系结构的清晰示例。

这种架构的优点是：

易学且非常一致，

明确分离关注点。每层负责一个明确的任务，

由于关注点的分离，易于测试：每个层都是可测试的，可维护的并且易于更新。

这种体系结构的缺点是：

如果没有组织，源代码可能会变得quite肿，
需要跳过某些层并造成逻辑混乱时，需要“快速修复”时产生紧密耦合的风险，
大多数用于单片应用程序，因此即使很小的更改也需要完全重新部署。

当需要在短时间内构建应用程序，很少有复杂的业务场景或与初级开发团队合作时，应考虑使用此体系结构。

微服务架构

当软件程序增长并在顶部添加新功能时，就有可能成为僵化的，庞大的巨人。微服务体系结构旨在帮助开发人员解决此问题。创建几个不同的较小的程序，而不是构建一个程序，每个程序都有自己的目标。每当请求新功能时，都会创建一个新程序。

每个微服务都是一项独立的应用程序服务，提供一项自包含的功能，并通过REST，HTTP等轻量级消息传递协议相互通信。

微服务只有在不违反其API合同的情况下才能独立于其他微服务发展。如果您更改合同，它将影响所有其他连接的微服务或API网关。需要以新旧版本的微服务合同同时运行的方式增量部署微服务的新版本。因此，为服务版本制定一个好的策略很重要。

软件开发基础架构软件开发系统架构_软件开发基础架构_02

Netflix是微服务架构的最早采用者之一。当您打开Netflix主页时，将从其他服务中检索所有信息。为了说明这一点，您的收藏夹列表是从与您的帐户信息不同的服务中检索到的。

这种架构的优点是：

没有供应商或技术锁定：每个微服务都可以拥有自己的技术堆栈，或者可以作为测试新技术的场所，
微服务很小，因此更易于测试，部署，维护和扩展。例如，如果您要在网站上启动促销活动，则可以仅扩大订购服务的规模，
围绕多个团队组织开发。每个小型团队负责一个或多个微服务。每个团队可以独立于其他团队的服务来部署和扩展其服务。

该体系结构的缺点是：

分布式系统的开发可能很复杂：一切都是独立的服务，您应该非常仔细地处理从服务到服务的请求。应包括额外的验证和错误处理，以避免中断和超时，
使用多个数据库带来的事务管理的复杂性。当一项服务中的请求成功但另一项服务中的请求失败时，您应该回滚数据库更改吗？
尽管分别测试服务很容易，但是对所有应用程序进行集成测试可能很困难，因为所有服务都应运行并需要自己的测试数据集。

当应用程序或应用程序的一部分应易于扩展或缩小时，建议将这种体系结构用于具有许多小的单独组件的应用程序。当与分布在不同位置或时区的几个开发团队合作时，微服务架构也可以成为福音。

面向服务的架构

面向服务的体系结构，通常简称为SOA，是一种基于业务服务的体系结构。服务是定义明确且自包含的。服务是松散耦合的，并且彼此通信以执行活动。基本上，它由服务使用者和服务提供者组成：服务使用者请求服务，而提供者执行服务并返回请求的结果。提供者和消费者都同意预定义的消息传递协议。

企业服务总线（ESB）实现了不同软件应用程序之间的通信系统。 ESB将消息转换为正确的消息类型，然后将消息发送到正确的消费者服务。

软件开发基础架构软件开发系统架构_数据库_03

乍一看，似乎微服务架构和面向服务的架构非常相似，但是如果仔细研究，它们在服务特性方面会有很大差异。

服务粒度，微服务体系结构中的组件集中于一个目的，并且确实做到了这一点。在面向服务的体系结构中，组件的大小范围可以从小型应用程序到整个企业应用程序。
中间件与API：微服务使用API层和简单的消息传递协议进行通信，而SOA具有具有额外功能的消息传递中间件组件。
SOA体系结构依赖于多个组件来处理业务请求，而微服务体系结构则试图将其最小化。微服务是应满足唯一目的的独立应用程序，SOA依靠多种服务来按设计完成请求。

SOA的优点是：

服务可重用性：通过组合松散耦合的功能来构建应用程序。服务可以在多个应用程序中重复使用，而与其他服务的交互无关，
可用性和可扩展性：可以产生服务的多个实例，
没有技术约束，生产效率更高：开发人员可以重用现有的旧版应用程序，并且可以独立于平台和技术而与来自不同供应商的产品进行连接。

该体系结构的缺点是：

大量的开销：每次服务与另一个服务进行交互时，都会在ESB上完成请求和参数的完整转换和验证，
该体系结构不适用于不需要消息中间件的小型应用程序。

当您具有大型复杂的企业范围的系统需要与需要消息中间件的异构应用程序和服务集成时，我建议使用面向服务的体系结构。该体系结构的另一个重要优点是合同解耦功能。服务和消费者可以分别发展，但仍然保持合同关系； SOA使数据保持一致。如果您在架构中需要这种抽象级别，则应该考虑使用SOA解决方案，而不是微服务架构。