🏇 🔌 🚭 微服务还是模块化系统？客户如何选择产品IT体系结构的方法 💾 🙆🏻 👆🏿

微服务和模块化系统是IT解决方案体系结构的类型。

使用模块时，我们将最终确定现有IT产品的盒装版本。

盒装版本的意思是整体式的，现成的系统，其核心以相同的方式“按原样”交付给所有客户。

改进之处在于创建功能缺失的模块。

我们通过重用整体组件（核心或其他模块）来获得新模块。
业务逻辑写在整体中：对于一个程序（应用程序，站点，门户），有一个入口点和一个出口点。

使用微服务时，我们从头开始创建IT产品，由“砖块”（一种单独的小流程负责）的原子微服务组成（发送信件，接收订单数据，更改订单状态，创建客户等）。
一组这样的块通过业务逻辑组合到一个公共系统中（例如，使用BPMS）。尽管存在连接，但是每个块都是自治的，并且具有自己的入口和出口点。

我们为客户提供的大多数IT产品都是从模块化开发开始的。随着时间的推移，其中一些会演变为微服务。另一方面，不需要微服务。在本文中，我们将研究为什么如此，以及有哪些标准可以帮助确定是否有必要实施微服务，或者是否应该坚持使用模块。

模块化架构的好处

所有CMS系统（Bitrix，Magento，Drupal，Hybris等），CRM，ERP，WMS以及许多其他系统都有盒装版本。他们卖得很好，需求量很大。
让我们看一下那些客观原因，为什么客户最常选择使用模块化体系结构并愿意购买盒装解决方案。

实现速度快

安装，配置和填写此类软件的目录需要花费一些时间。对于中型公司而言，在启动后的三到四个月（有时甚至更早）开始使用盒子是很现实的。

对于小型企业，此期限可能只有几天。
. , enterprise- .
. . , , , .
,

. , .

还有其他一些主观因素可能会产生误导，并影响使用盒子和模块的决定。

1.制造商的竞争

软件销售商热烈地使客户相信，他们的开箱即用的解决方案是正确的：它经过了多年的测试，已经过了时尚，企业，流行和市场推广……任何供应商：Bitrix，Magento，SAP，Oracle，OpenCart， Django和其他所有人都在努力开发营销和销售技术。

2.对改进的复杂性的误解

客户常常充满乐观。他们选择盒装软件，并认为：“是的，需要改进。但这很容易：您不必发明新的东西。我们有一个受欢迎的版本，但数百万的用户无法犯错并购买不良产品。”
在他们看来，优化过程如下所示：有一个主要的（装箱的）功能。要“完成”其中的某些内容，开发人员将必须“只是”重新定义模块或快速编写自己的模块。在这种情况下，不必使用重复的方法，因为据说所有事情都是在整体中考虑的：规定了计算税款的通用方法，有明确的规则来编写交货和付款方式，有清晰的订单工作流程等。

在现实生活中，情况有所不同。从开始使用包装盒开始就产生了愉快的情绪之后，客户仍然面临着残酷的现实。这种情况通常发生在大中型公司中，这些公司的项目具有独特的业务逻辑，因此需要进行大规模改进。

如果您的公司规模不大，而软件不是您的主要资产，那么很可能会出现流行的盒装（或更好的是-云）解决方案。

让我们看看使用模块化体系结构时可能遇到的问题以及微服务如何帮助避免这种情况。

模块化系统的问题

主要问题在于，并非所有模块化系统都旨在认真地重新定义功能。它们有一个盒装的现成模块-最好使用它们。

项目的规模及其定制的复杂性越接近企业级别，模块完成的问题就越多。让我们谈谈主要的。

问题1。系统的核心成为减速点，而模块化成为不必要的复杂性。

假设您的项目与复杂的仓库逻辑相关联。如果选择模块化体系结构，则开发人员不仅需要创建管理这些仓库的功能，还需要重新定义或扩展多核模块，而后者又使用内核方法。

在这种情况下，有必要考虑到退货的复杂逻辑：依赖CRM系统中的事件，商品在目录之间的移动等。还值得考虑与资金返还，奖励积分等相关的隐藏逻辑。

当发生这么多次重新定义时，整料会发生明显变化。重要的是要记住，新功能的数量与模块数量之间的关系是非线性的：要添加一个功能，您必须对多个模块进行更改，每个模块都更改另一个模块的操作，或者在新模块中重新定义其他模块的大量方法，这不会改变本质。

完成所有更改后，系统变得如此复杂，以至于需要花费大量的时间来添加以下定制。

问题2。在模块化系统中不支持自我记录的原理。

模块化系统的文档很难更新。它很多，每次更改都会过时。一个模块的完善需要对其他几份文档（在用户，技术文档中）进行更改，并且所有这些都需要重写。

通常，没有人可以做这样的工作：在有价值的IT专家身上花时间在这上意味着简单地消耗预算。即使使用代码中的文档存储（PHPDoc）也不能保证其可靠性。最后，如果文档可能与实现不同，则必然会有所不同。

问题3。增强代码的一致性-回归之路：“他们在这里更改了代码，但最终失败了”

模块化系统的经典问题在于与回归的斗争。

由于不同方法的一致性，TDD开发很难用于整体式（您可以轻松地在5行代码上加上30个测试代码，再加上固定装置，花费30行测试）。
因此，在与回归的斗争中，有必要用集成测试覆盖功能。
但是鉴于已经很慢的开发（毕竟，您需要仔细地开发它以提供许多替代），所以客户不想为复杂的集成测试付费。

功能测试变得无意义。它们运行了几个小时，甚至是并行运行。

是的，可以对PWA等现代技术进行API功能测试。但是测试通常依赖于从外部电路接收数据-因此，例如，如果测试SAP落后食品杂货店N个月，而测试“ 1C”发送的数据不正确，则测试将开始失败。

当您必须为某个模块上传少量编辑内容时，开发人员应从两个弊端中进行选择：启动完整的CI运行并花大量时间进行部署或在不运行测试的情况下布置修补程序，否则有可能破坏某些内容。当这样的编辑在黑色星期五从市场营销部门收到时，非常具有戏剧性。当然，迟早会发生回归和人为错误。熟悉吗？

最终，为了实现业务目标，团队进入紧急操作模式，熟练地处理测试并仔细查看日志中的仪表板-Kibana，Grafana，Zabbix ...最终我们会得到什么？燃尽。

您必须承认，这种回归的情况并不像“稳定的企业”那样，而是应该在客户的梦想和梦想中实现的。

问题4：代码连接性和平台更新

代码连接性的另一个问题是平台更新困难。

例如，Magento包含两百万行代码。无论我们在哪里看，到处都有很多代码（Akeneo，Pimcore，Bitrix）。在向内核添加功能时，最好考虑自定义模块中的更改。

这是Magento的实时示例。
在2018年底，发布了新版本的Magento 2.3平台。 Multistores和Elasticsearch已添加到开源版本中。此外，内核中修复了数千个错误，并在OMS中添加了一些功能。

已经在Magento 2.2中编写了多商店的电子商务项目面临什么？他们需要重写一系列逻辑来处理订单，结帐和产品卡，才能使用盒装功能。确实，“很好”-为什么要在模块中复制盒装版本的功能？减少大型项目中的自定义代码量总是有用的-毕竟，所有box方法都考虑了这些多仓库，并且在没有这种重构的情况下更新box可能毫无意义（请注意安全性问题，以简化起见，尤其是因为无需进行更新即可将其汇总）。

现在想像：这样的更新将花费多少时间，并且如果没有集成测试（很难编写）如何进行测试？

毫不奇怪，对于许多人而言，平台升级是在不进行重构的情况下进行的，而是增加了重复性，或者（如果团队希望通过风水来完成所有工作）在重构和恢复顺序上“离开”了很长时间。

问题5。业务流程的不透明度

项目管理中最重要的问题之一是客户看不到项目的所有逻辑和所有业务流程。它们只能从代码或文档中恢复（正如我们前面所说，它们的相关性在模块化系统中难以维护）。

是的，Bitrix具有BPM部分，而Pimcore具有工作流程可视化。但是这种通过业务流程管理模块的尝试总是与内核的存在相冲突。此外，事件，复杂的计时器，事务性操作-所有这些都不会在BPM整体中发生。我再说一遍：这适用于大中型公司。对于小型公司而言，模块化系统的功能已足够。但是，如果我们谈论的是企业领域，那么该解决方案仍然缺少一个控制中心，您可以在其中查看任何过程的图，任何状态，确切发生的情况，异常，计时器，事件和控制项。。没有足够的机会更改业务流程，但没有更改模块的机会。项目的流程管理淹没于变更的速度和逻辑的一致性。

问题6：系统扩展的复杂性

如果您部署一个整体，它将与每个应用程序服务器上的所有模块一起整体部署。那些。您不能与代码的其余部分分别增加一个季节中处理订单和奖金的服务。

需要更多的内存和处理器，这大大增加了群集的成本。

微服务如何将客户从模块化开发的典型缺陷中拯救出来。Camunda和jBPM中的微服务编排

剧透：使用BPMS和协调微服务系统可以解决上一段中列出的问题。

BPMS（英文业务流程管理系统）是用于管理公司业务流程的软件。与我们合作的流行BPMS是Camunda和jBPM。

编排描述了服务应如何使用消息传递（包括业务逻辑和一系列操作）相互交互。使用BPMS，我们不仅可以绘制抽象方案-我们的业务流程将根据绘制的图执行。我们保证在图中看到的内容都与流程的工作方式，使用的微服务，使用的参数，根据哪些决策表，选择的特定逻辑相关。

例如，我们采用一个经常遇到的过程-发送要交付的订单。

通过任何消息或直接致电，我们将从选择交货方式的过程开始进行订单处理。选择逻辑已设置。

结果，流程，服务和开发：

变得快速可读；
自我记录（它们的工作与绘制的完全相同，并且文件与代码的实际工作之间没有任何同步）；
刚刚调试（很容易看到此过程或该过程如何进行，并了解错误是什么）。

我们将熟悉业务流程管理系统的工作原理。

BPMS原则1。发展成为可视化的过程

BPMS允许您创建一个业务流程，在该业务流程中，项目团队（开发人员或业务用户）将确定微服务的启动顺序以及其运行的条件和分支。在这种情况下，一个业务流程（动作序列）可以包含在另一业务流程中。

所有这些都在BPMS中清楚地呈现：您可以实时查看这些方案，对其进行编辑，以高效的方式进行处理。在此，最大程度地实现了自我记录环境的原理-该过程完全按照可视化方式工作。

所有微服务都成为可以从快照添加到业务用户的流程多维数据集。业务由流程管理，开发人员负责特定微服务的可用性和正确操作。此外，各方都了解该过程的一般逻辑和目的。

BPMS原则2。每个服务都有明确的输入和输出。

该原理听起来很简单，对于没有经验的开发人员或业务用户来说，BPMS似乎并没有以任何方式改善编写微服务的策略。就像普通的微服务一样，无需BPMS即可编写。

是的，有可能，但很难。当开发人员在没有BPMS的情况下编写微服务时，他不可避免地希望节省抽象性。坦率地说，微服务变得很大，有时它们甚至开始重用其他服务。希望保存结果从一种微服务到另一种微服务的透明性。

BPMS鼓励您写得更抽象。精确地进行开发，并定义输入和输出。

BPMS原则3：队列处理的并发性

想象一下处理订单的过程：我们需要去某个市场，拿起所有好的订单并开始处理它们。

查看该图（图的一部分）。在这里，我们确定每10分钟检查一次市场上的所有订单，然后并行处理（如流程订单中垂直的“汉堡”所示）每个订单的处理。如果成功，则将所有数据传输到ERP并完成处理。

如果我们突然需要在Camunda，JBoss或任何其他BPMS中提高处理特定订单的日志，我们将能够完全还原所有数据，并查看它在哪个队列中以及带有什么输入/输出参数。

BPMS原则4。错误和升级

想象一下，在交付过程中发生了错误。例如（顺便说一句，这是一个真实的案例），运输公司接了订单，然后仓库被烧毁了。另一个真实的故事：除夕高峰，该产品首先被推迟，然后可能丢失了。

在这种情况下，事件是由BPMS中的鼠标触发的，例如，在传递时间过去的情况下通知客户端。如果您从内部的运输公司收到错误，则可以在自己的分支机构中开始该流程并中断所有操作：通知，对下一个订单给予折扣，并退还款项。

所有此类异常不仅难以在BPMS之外（例如，计时器中的计时器）进行编程，而且难以在整个过程的上下文中理解。

BPMS原则5。事件和进程间选项之一的动作选择

提交相同的订单。

总共，我们有三种方案：

货物按预期交货；
货物未按预期交付；
项目已丢失。

直接在BPMS中，我们可以确定将货物运送到运输公司的过程，并可以通过订单预期发生以下事件之一：

成功交付（产品交付过程中已交付所有产品的消息）；
或一些时间的开始。

如果时间还没有过去，则需要启动另一项服务：与操作员解析此特定订单（您需要在OMS / CRM系统中为其设置任务以找出订单的位置），并进一步通知客户。

但是，如果在调查过程中仍然交付了订单，则有必要中断调查并完成订单的处理。

在BPMS中，所有中断和异常都在BPMS端。您不会使用此逻辑使代码过载（并且代码中这种逻辑的存在会使微服务变大，并且在其他进程中很难重用）。

BPMS原则6。在您的Camunda中，您将看到所有日志

使用事件和进程间选项，您：

您可以在一个窗口中看到整个事件序列（顺序发生了什么，它经历了异常的哪个分支，等等-很容易看到）；
您可以仅基于BPMS日志来收集BI的所有分析（而无需使微服务因日志事件而过载）。

结果，您将能够专门收集有关处理，过渡率和公司所有流程问题的统计信息。日志信息是统一的-很容易将交付中的事件与操作员的行为或任何其他信息系统的事件联系起来。

注意模块化系统的区别：通用日志也可以在此处完成，但是在与其他系统交互时，您也需要统一登录才能做一些事情，而这并非总是可行的。

结论：微服务和模块化架构的比较

每种类型的体系结构都有其优点和缺点。没有通用的解决方案。

我们不主张大规模转向微服务。相反，对于小型企业或使用少量自定义项时，模块化方法将更适合。

另外，我们也不反对任何IT解决方案（Bitrix，Magento，Symfony或Django等框架等），因为我们每个月在这些框架上仅开发六千多个小时的代码，并且使用相同数量的front'a和微服务。因此，我们深信，寻找合适的技术解决方案而不是促进特定平台的使用非常重要（可惜的是，IT的大部分销售都在下滑）。

在本文的前面各节中，您了解了模块化体系结构的缺点和优点。我们希望这已经有助于评估盒装版本的完善或从头开始创建微服务是否更合适。如果无法决定，让我们看看不同类型的体系结构如何根据项目寿命而变化。

在项目开始时：