介绍 在现代经济中，软件的创造是一个完整的行业。一方面，它帮助企业实现所有流程的自动化和数字化，另一方面，它赚取利润并创造虚拟资产。目前，研发越来越复杂，程序员的数量不断增长，IT任务也越来越复杂。 这些原因导致了新的软件开发方法和架构类型的出现。 现代 Web 应用程序是多功能的，数字化转型增加了对软件的要求。应用程序应该是：易于扩展、灵活和跨平台，并且可以针对用户任务进行更改。任务管理器在开发此类软件的阶段设定这些要求。 首先，要为现代企业创建软件，您必须认真研究软件开发过程并选择正确的架构。 软件开发中架构的选择 通常，以前所有应用程序都是基于单体架构开发的。让我们看看什么是单体应用程序。 单体应用程序是作为一个整体开发的。处理请求的逻辑放置在单个进程中。 Monolith Web 应用程序可以以模块和块的形式构建。根据所使用的编程语言，使用单独的类、函数等。但是模块之间的连接非常牢固。 这导致以下结论：更改任何模块都会极大地影响整个应用程序的工作。 例如，我们可以考虑一个用于 LMS（学习管理系统）的典型 Web 应用程序。 该软件具有三层架构，其中包括： 用户界面; 用于软件业务逻辑和数据访问的服务器端组件； 数据库。 这种应用程序的业务功能非常不同。包括以下板块：“课程与培训”、“课程目录”、“公司组织架构”、“活动日历”、“报告”、“留言”、“新闻”等。 但是，它们都组合成一个整体块，并位于一台服务器上。扩展和更改这样的应用程序非常困难。 让我们强调一下单体架构的缺点： 即使是 Web 应用程序中的一个小改动，也会导致整个软件的新版本的组装和部署。 您只能扩展整个应用程序。不可能扩展一个单独的块。 如果任何一个应用程序模块出现故障，则可能导致整个应用程序的运行中断。 开发工具始终仅限于选定的技术堆栈。 管理大量合格开发人员的不便。每个开发人员都应该了解应用程序的所有功能，而不仅仅是他的模块。 任何更新都会影响软件的全部功能。它会导致更新后应用程序失败的风险。因此，只发布很少的更新版本。 数据库中的任何更改都会影响整个应用程序的工作，并且需要更改代码。 如果这是一个免费的小程序，用于向普通用户教授一些个人技能，甚至很少更新，那么单体架构非常适合这种开发。 如果说的是企业软件（比如LMS），甚至经常更新，那么选择微服务架构是很有必要的。 是软件开发的最佳方法。在微服务架构中，Web 应用程序被划分为具有特定接口的小型自治组件（微服务）。这种架构已经在云计算领域得到应用。 微服务架构 微服务和单体架构有什么区别？在微服务架构中，Web 应用程序被开发为一组小型且互连不良的组件，称为微服务。微服务的开发、部署和维护几乎彼此独立。 例如，LMS 的 Web 应用程序。每个微服务旨在仅解决其特定的业务任务，拥有自己的数据库，并通过 API 与其他微服务联系。因此，有必要为 LMS Web 应用程序开发以下微服务：“课程和培训”、“课程目录”、“公司的组织结构”、“活动日历”、“报告”、“消息”、 《新闻》等 但必须注意，还有另一种架构类型——面向服务的架构（SOA）。有时它与微服务混淆。看来微服务架构和SOA的区别不是那么明显。但是微服务和 SOA 是有区别的。这涉及企业服务总线 (ESB) 的角色。 SOA 是一种公司范围的架构。其目标是标准化公司 Web 服务的交互和集成。微服务架构的目的是开发特定的应用程序。以下模板与 SOA 相关：CORBA、Web 服务、消息队列、ESB 等。 下面我们将详细讲述微服务在开发 Web 应用程序方面的优势。 微服务架构的主要优势 我们将评估微服务与单体架构相比的优势。 应用程序部署的简单性和独立性。在微服务的情况下，您只能部署一个应用程序模块。例如，在我们的 LMS 案例中，您只能部署一个模块（“事件日历”），而其余应用程序组件保持不变。如果你需要在“报告”模块中重写代码，那么不需要获得很多权限。该组件（“报告”）是一个独立的微服务。 可扩展性：准确性和效率。首先，它需要确定哪些微服务需要频繁的可扩展性，哪些不需要。不需要经常扩展的模块可以放置在较弱的服务器上，通常可扩展的模块可以与所有其他软件分开扩展。 提高应用程序的弹性。合理的应用程序设计和构建模块之间的独立连接具有以下优势：其中一个模块的故障不会导致整个软件的故障。例如，如果“消息”模块出现故障，用户将收到有关此块暂时不可用的通知。所有其他应用程序块都将起作用。 技术堆栈选择。通过开发每个微服务，您可以选择最合适的技术堆栈。 管理团队的灵活性。例如，1 号团队开发服务“课程目录”，2 号团队开发“事件日历”服务，3 号团队开发“新闻”服务。这就是为什么新专家更容易更快地投入工作。不需要长时间研究整个应用程序的功能，学习特定微服务的技术栈就足够了。 重用功能的能力（用于不同的目的和以不同的方式）。 更换或删除不必要的服务可以快速轻松地解决。例如，如果特定客户不会使用 LMS 中的“新闻”块，则可以简单地删除此模块，而无需对所有软件进行全局更改。 每个微服务都使用其数据库。这一事实导致数据模型的独立性。例如，如果程序员更改了某个特定服务中的数据模型，则不会影响其他服务的工作。 我们可以看到，微服务架构具有显着的优势，越来越吸引开发者。但是，在选择软件开发架构之前，应该先看看微服务的缺点。我们将在下面列出。 微服务的缺点 微服务系统是分布式的。一方面，这是软件工作中的一个优势。另一方面，如果微服务过多，每个微服务都向其他服务发出请求，那么由此产生的响应时间会增加，并且会出现“故障点”。 有两种方法可以解决这个问题： 更改通话详细信息，这可能导致其数量减少； 异步的引入，调用是并行执行的，因此，这导致最终响应时间是所有时间中最慢的时间，而不是所有延迟的总时间。 开发过程的不断复杂化，导致对程序员资格的要求越来越高。在微服务架构中，集成流程和持续交付流程的作用很大。 这就是为什么如果没有自动化测试和部署服务就很难处理大量流程。这些因素都需要在公司实施 DevOps 以及开发人员与系统工程师、测试人员、技术支持等密切合作。 微服务架构中的去中心化会给微服务的一致性带来问题。例如，在单体应用程序中，可以在一个事务中进行许多更改，但如果发生故障也可以回滚，同时保持数据一致性。 在使用微服务时，可能会出现以下情况：如果其中一个服务发生故障，另一个微服务停止响应。在这种情况下，这是开发人员的优先级问题：您可以优先考虑组件的可用性（如果一个服务发生故障，其他服务将继续运行）。一般来说，开发人员必须在服务的一致性和可用性之间找到一个平衡点，并且必须非常小心地做到这一点。 结论 在选择用于开发 Web 应用程序的微服务架构之前，开发人员应评估其优缺点。毕竟，架构的错误选择可能会影响未来软件的性能和功能。 如果微服务架构使用不当，开发人员可能会遇到大问题，从而否定微服务的所有优势。 在本文的下一部分中，我们将考虑在软件开发中使用微服务架构的开发人员应该掌握的技术工具。
