自2019年起，俄罗斯出台了强制标签法。 该法律并不适用于所有商品组，并且各产品组强制标签的生效日期也不同。 烟草、鞋子和药品将首先受到强制标签的约束；随后将添加其他产品，例如香水、纺织品和牛奶。 这一立法创新促进了新的 IT 解决方案的开发，使跟踪产品从生产到最终消费者购买的整个生命链成为可能，直至该过程的所有参与者：包括国家本身和所有销售商品的组织。强制性标签。
在X5中，跟踪贴标签商品并与国家和供应商交换数据的系统称为“Marcus”。 让我们按顺序告诉您它是如何开发的、由谁开发的、它的技术堆栈是什么，以及为什么我们有一些值得自豪的东西。
真正的高负载
“Marcus”解决了很多问题，最主要的就是X5信息系统与贴标产品状态信息系统（GIS MP）集成交互，跟踪贴标产品的动向。 该平台还存储我们收到的所有标签代码以及这些代码在物体之间移动的整个历史记录，并有助于消除对标签产品的重新分级。 以第一组标签商品中包含的烟草产品为例，仅一卡车的香烟就包含约 600 包，每包都有自己独特的代码。 我们系统的任务是跟踪和验证每个此类包装在仓库和商店之间移动的合法性，并最终验证其向最终买家销售的可接受性。 我们每小时记录大约 000 笔现金交易，我们还需要记录每个这样的包裹是如何进入商店的。 因此，考虑到物体之间的所有运动，我们预计每年会有数百亿条记录。
M队
尽管 Marcus 被视为 X5 内的一个项目，但它是使用产品方法来实现的。 团队按照 Scrum 进行工作。 该项目于去年夏天启动，但直到十月份才取得第一个成果——我们自己的团队已完全组建完毕，系统架构已开发完毕，设备也已购买。 现在团队有16人，其中XNUMX人参与后端和前端开发，XNUMX人参与系统分析。 另外还有六人参与手动、负载、自动化测试和产品维护。 此外，我们还有一名 SRE 专家。
我们团队中不仅开发人员编写代码；几乎所有人员都知道如何编程和编写自动测试、加载脚本和自动化脚本。 我们特别关注这一点，因为即使是产品支持也需要高水平的自动化。 我们总是尽力为以前没有编程过的同事提供建议和帮助，并给他们一些小任务来完成。
由于冠状病毒大流行，我们将整个团队转移到远程工作；所有开发管理工具的可用性以及 Jira 和 GitLab 中构建的工作流程使我们可以轻松通过此阶段。 远程度过的几个月表明，团队的生产力并没有因此受到影响；对于许多人来说，工作的舒适度有所提高，唯一缺少的是实时沟通。
远程团队会议
远程工作期间的会议
解决方案的技术栈
X5 的标准存储库和 CI/CD 工具是 GitLab。 我们使用它来存储代码、持续测试以及部署到测试和生产服务器。 当至少 2 位同事需要批准开发人员对代码所做的更改时，我们还使用代码审查的做法。 静态代码分析器 SonarQube 和 JaCoCo 帮助我们保持代码整洁并确保所需的单元测试覆盖率水平。 对代码的所有更改都必须经过这些检查。 所有手动运行的测试脚本随后都会自动化。
为了成功实施“Marcus”的业务流程，我们必须按顺序解决许多技术问题。
任务1.系统水平可扩展性的需求
为了解决这个问题，我们选择了微服务架构方法。 同时，了解服务的职责范围也非常重要。 我们尝试将它们划分为业务运营，同时考虑流程的具体情况。 例如，仓库的收货不是很频繁，但是规模很大，需要从国家监管机构快速获取所收货物的单位信息，一次发货的数量达到600000万件。 ，检查是否可以接受该产品进入仓库，并返回仓库自动化系统的所有必要信息。 但仓库发货的强度要大得多，但同时数据量却很小。
我们在无状态的基础上实现所有服务，甚至尝试将内部操作划分为步骤，使用我们所说的 Kafka 自主题。 这是微服务向自身发送消息的情况，这使您可以平衡资源密集型操作的负载并简化产品维护，稍后会详细介绍。
我们决定将与外部系统交互的模块分成单独的服务。 这使得解决外部系统API频繁变化的问题成为可能，并且对具有业务功能的服务几乎没有影响。
所有微服务都部署在OpenShift集群中，这既解决了每个微服务的扩展问题，又允许我们不使用第三方服务发现工具。
任务2.需要在平台服务之间维持高负载和非常密集的数据交换： 仅在项目启动阶段，每秒执行约 600 次操作。 随着零售店连接到我们的平台，我们预计该值将增加到 5000 次操作/秒。
通过部署Kafka集群并几乎完全放弃平台微服务之间的同步交互来解决这个问题。 这需要对系统需求进行非常仔细的分析，因为并非所有操作都可以是异步的。 同时，我们不仅通过broker传输事件，还在消息中传输所有需要的业务信息。 因此，消息大小可以达到数百KB。 Kafka中的消息大小限制要求我们准确预测消息大小，必要时我们进行划分，但划分是逻辑性的，与业务操作相关。
例如，我们将汽车到达的货物分成箱子。 对于同步操作，分配单独的微服务并进行彻底的负载测试。 使用 Kafka 给我们带来了另一个挑战 - 测试我们服务的操作，同时考虑到 Kafka 集成使我们所有的单元测试都是异步的。 我们通过使用嵌入式 Kafka Broker 编写自己的实用方法解决了这个问题。 这并不能消除为单个方法编写单元测试的需要，但我们更喜欢使用 Kafka 测试复杂的情况。
我们非常关注跟踪日志，以便在服务运行过程中或使用 Kafka 批处理时发生异常时，其 TraceId 不会丢失。 如果第一个没有特殊问题，那么在第二种情况下，我们被迫记录该批次附带的所有 TraceId，并选择一个继续跟踪。 然后，当用户通过原始TraceId进行搜索时，就可以很容易地找到跟踪是从哪一个继续进行的。
任务3.需要存储大量数据： 每年仅烟草标签就有超过 1 亿个标签来到 X5。 他们需要持续且快速的访问。 总的来说，系统必须处理大约 10 亿条带有标签的商品的移动历史记录。
为了解决第三个问题，选择了NoSQL数据库MongoDB。 我们构建了一个包含 5 个节点的分片，每个节点都有一个包含 3 个服务器的副本集。 这允许您水平扩展系统，向集群添加新服务器，并确保其容错能力。 这里我们遇到了另一个问题——确保mongo集群中的事务性，同时考虑到使用水平可扩展的微服务。 例如，我们系统的任务之一是识别使用相同标签代码转售产品的尝试。 在这里，叠加出现了错误的扫描或收银员的错误操作。 我们发现此类重复项既可能发生在正在处理的一个 Kafka 批次内，也可能发生在并行处理的两个批次内。 因此，通过查询数据库检查重复项没有给出任何信息。 对于每个微服务，我们根据该服务的业务逻辑分别解决问题。 例如，对于检查，我们在批处理中添加了检查，并在插入时单独处理重复项的出现。
为了确保用户对操作历史的处理不会以任何方式影响最重要的事情 - 我们的业务流程的运行，我们将所有历史数据分离到具有单独数据库的单独服务中，该服务也通过 Kafka 接收信息。 这样，用户可以使用独立的服务，而不会影响处理正在进行的操作的数据的服务。
任务4：队列重新处理和监控：
在分布式系统中，数据库、队列和外部数据源的可用性不可避免地会出现问题和错误。 就 Marcus 而言，此类错误的根源在于与外部系统的集成。 有必要找到一种解决方案，允许在指定的超时时间内重复请求错误响应，但同时不停止在主队列中处理成功的请求。 为此，选择了所谓的“基于主题的重试”概念。 对于每个主要主题，创建一个或多个重试主题，将错误消息发送到这些重试主题，同时消除处理来自主要主题的消息的延迟。 互动方案-
为了实现这样的方案，我们需要：将这个解决方案与Spring集成并避免代码重复。 在网上冲浪时，我们遇到了一个基于 Spring BeanPostProccessor 的类似解决方案，但它对我们来说似乎不必要的麻烦。 我们的团队制定了一个更简单的解决方案，使我们能够集成到 Spring 周期中来创建消费者，并另外添加重试消费者。 我们向 Spring 团队提供了我们解决方案的原型，您可以看到它 。 重试消费者的数量和每个消费者的尝试次数是通过参数配置的，具体取决于业务流程的需求，要让一切正常工作，剩下的就是添加注解 org.springframework.kafka.annotation.KafkaListener ，这是所有 Spring 开发人员都熟悉的。
如果在所有重试尝试后仍无法处理消息，则会使用 Spring DeadLetterPublishingRecoverer 转到 DLT（死信主题）。 应支持请求，我们扩展了此功能并创建了一个单独的服务，允许您查看 DLT、stackTrace、traceId 中包含的消息以及有关它们的其他有用信息。 此外，所有 DLT 主题都添加了监控和警报，事实上，现在 DLT 主题中出现消息就是分析和修复缺陷的原因。 这非常方便——通过主题的名称，我们立即了解问题是在流程的哪一步出现的，这显着加快了查找其根本原因的速度。
最近，我们实现了一个接口，允许我们在消除消息原因（例如，恢复外部系统的功能）后使用我们的支持重新发送消息，当然，还可以建立相应的缺陷进行分析。 这就是我们的自我主题派上用场的地方：为了不重新启动长处理链，您可以从所需的步骤重新启动它。
平台运营
该平台已经投入生产运营，我们每天都进行送货和装运，连接新的配送中心和商店。 作为试点的一部分，该系统与“烟草”和“鞋子”产品组合作。
我们的整个团队参与试点，分析新出现的问题，并提出改进我们产品的建议，从改进日志到改变流程。
为了不重蹈覆辙，试点期间发现的所有案例都反映在自动化测试中。 大量自动测试和单元测试的存在使您可以在几个小时内进行回归测试并安装修补程序。
现在我们不断开发和完善我们的平台，不断面对新的挑战。 如果您有兴趣，我们将在接下来的文章中讨论我们的解决方案。
来源： habr.com