四年前，每个商店分别维护了一个客户群，并在该站点上建立了另一个客户群。
在上一个系列：三年前，我们决定需要在俄罗斯进行发展。 两年前，他们开始编写自己的代码，而不是修改母公司的fork代码。 今天的故事将是关于我们如何从一个大型Legacy整体组件转变为通过一种总线（协调器）连接的一堆小型微服务的。
最简单的用户案例：通过该网站进行订购，然后在俄罗斯的Leroy Merlin真实商店中取货。 以前，通常根据另一个方案在另一个应用程序中处理在线商店订单。 现在我们需要一个全渠道展示柜，以便将任何订单分解为一个界面：商店中的收银员，移动应用程序，商店中的终端，网站-等等。 如果将Linux放在微波炉上，请放微波炉。 最主要的是，某些接口可以敲击API的背面，并说您需要在此处下达这样的命令。 他们对此有明确的答案。 第二个故事是关于他卡中商品的可用性和属性的要求。
在前端（我们将很快对此进行介绍），我们有一个庞然大物-AEM，在其后面的是两个大型应用程序：OPUS和MoVe。 第一个是每个产品的属性数据库（从尺寸到描述），第二个是用于结帐的功能，即收银台。 如果大大简化。
Opus怎么了？
OPUS是一个庞大的分布式基础。 更准确地说，它是提供访问数据库的接口的软件，也就是说，它访问数据库，例如，搜索或简单地公开API，以使客户端不直接进入数据库。 该软件可以运行并且在法国受支持。
正如我们已经说过的 ，第二个特点是它的改进线很长，与法国的业务部门相比，我们并不是最优先考虑的事情。
困难重重，我们无法理解开发人员如何在没有来自法国的团队的情况下进行更改；批准时间很长。 功能发布六个月。 实际上，起初我们想进行自己的开发和审查，然后才进行自己的开发，基础架构，测试以及总体上自己的开发。 同时扔掉了几乎三分之一的旧版代码。
但是回到OPUS。 由于系统存储了有关可用性，特征，交易等信息的相关信息，因此我们出于任何原因将其关闭。 专门针对该站点，这意味着如果用户在购物篮中有三个产品，则需要检查每个页面上的数据库，因为已检查了相关性。 即使您敲一次缓存，然后对其进行了巧妙的更新，仍然具有一些功能。 通常，当您打开目录页面时，所有产品规格均来自OPUS。
顺理成章的下一步是，我们开始减少OPUS的使用频率并建立基础（更确切地说，是具有基础的微服务）。 整个系统称为俄罗斯PUB。
然后，他们创建了一个乐团，该乐团已经可以存储集合，也就是说，实际上是用于收集建筑页面的数据。 从某种意义上说，当用户将页面视图从卡片切换到列表时，它仍然是相同的集合，只有正面有所不同。
也就是说，我们离开了原来的OPUS（仍在法国），但是我们几乎完整的镜子“吸”了它，将底座切成碎片，准备在管弦乐队中组装。 然后，协调器收集并存储聚合（或快速接收它们并开始存储它们），这是其他系统所需的。 结果，这部分工作正常。 在法国OPUS的原始功能中，剩下约5％。 很快我们将完全取代它。
MoVe怎么了？
没什么特别的，除了我们决定扔掉所有代码，因为它：
- 在古老的栈上是古老的。
- 他考虑了IF链中每个区域“ Leroy Merlin”的特征。
- 很难阅读和维护，以至于最好的重构方法是“再次写入并立即正常记录文档”。
我们做到了。 只有我们改写了它，而不是将其作为整体，而是开始为周围的每个单独功能提供微服务。 然后，MoVe切换到微服务的部分功能被顺利删除。 如此一一，直到MoVe的功能完全结束。 也就是说，它仍然有效，但是处于真空中并且没有数据流。
由于我们是从零开始构建平台的，因此该项目被命名为Lego。
乐高完全改变了这种中间状态。 是的，让我们澄清一下：真正的后端是传统总线，文件系统，数据库以及其他几乎基础架构级别。 围绕此的大型应用程序和逻辑微服务处于中间位置。 演示已经很重要。
为什么需要重写所有这些内容？
因为我们在俄罗斯开业15年以来就分别与不同的客户群生活在一起，所以这并不适合任何人。 也没有同步。 在其他国家，他们仍然像那样生活。
法国的母公司负责一般物流，我们重复使用了Pixis系统-这是一家收据单店，即客户订单：一家店看到另一家店的订单。 但这并不能完全解决全渠道订单问题。 因此，有必要巩固基础并进行一般处理。 这是主要的。
第二个原因是联邦票房法：由于我们针对所有国家/地区开发通用系统（和测试）的开发时间表会被罚款。
在巴西也采用了类似的选择：他们在那里没有母公司的任何软件就在那里建立了Leroy Merlin，他们成功了。 那是在分裂决定之前。 顺便说一下，他们对内部人员投入很多，他们发展非常快。
实际上，Pixis只允许从收银机下订单。 我们分三个阶段更改了情况：
- 首先，我们为员工制作了一个移动应用程序，极大地简化了他的生活。 在此基础上，他们开始构建接口与逻辑分离的生态系统。
- 一切准备就绪后，互联网订单被手动推入收银台。
- 他们依次使用微服务，并在中间将其全部替换。
为什么需要从商店应用程序开始？ 因为与法国相比，我们再次拥有独特的流程。 例如，一个人决定在商店购买六米长，十厘米的链条。 卖方切断了他的身分，并提供了一份文件，证明该文件要花多长时间以及要花多少钱。 您拿着这张纸去收银台，在那里付款。 从逻辑的角度看，销售不应该在票房，而卖方应该在票房，但实际上最有趣的事情是在票房开始的：您需要同时拥有商品和纸张。
最终，我们将成为一个下订单的平台：例如，现在，在我们的主系统上，增加了购买主人服务的服务（我买了厨房-我从一个外部主人那里订购安装，但我们找到了并给了我们自己保证），
市场 （直接从更广泛的供应商那里购买），不久之后就必须有一个子公司，以便我们的积木可以放置在任何地方。 像在博客中嵌入Amazon商店之类的东西，只会更加灵活。
如何做出更换决定？
我踩。 完善业务模型。我们进行了检查，确实如此：与俄罗斯一样，该模型-每天低价-是成功的。 勒罗伊·梅林（Leroy Merlin）在欧洲要贵得多，但在俄罗斯，这就是我们的利基市场：一家建筑店，您可以在其中找到最优惠的价格。
第二步。 创建一个客户端脚本。也就是说，从客户的角度出发，构建我们希望它们与我们互动的流程。 也就是说，对于未来几年我们想要成为什么样的人以及从建筑的角度看它的外观有一个单一的愿景。
第三步。 建立架构。将此愿景分解为更详细的特定传统知识和体系结构。 结果是有110个项目，我们在五年中将其分为五个类别。
然后他们组成了专业团队。 大多数情况下，这些人是他们的员工加上承包商。 最初，他们为此遭受了极大的折磨：当他们进入产品时，他们并不真正了解如何消化如此大量的变化。 然后，他们开始为任务制定通用方法，并逐渐增加其开发份额。
在那些错误非常严重的地方，他们根据NASA计划工作，而这些错误是不可接受的，根本不是一种选择。 这都是关于金钱交易的。
在可能跌落的地方，主要的事情是快速起床，我们使用的方法接近Google的SRE。 反复使用门框，但可以尽快实施项目。 现在我们正在做很多事情，而且开发非常酷。
第三种方法是创新。 我们开发了一个想法沙箱，以利用我们的内部资源快速完成第一个MVP，从而使我们能够快速而廉价地进行测试。 这就是真正的“快速尝试，快速失败”。 这使您能够为那些想出一个很棒的项目的人获得预算和授权。
第二个重点是地理开发。 然后一年开设20家商店（现在稍微慢一些）。 六千名员工。 许多地区。 必须重写整个供应链，以快速开发流程以提高商店的基础设施。
2017年，我们决定成为建筑订单的平台：这是未来几年的一个有前途的策略。
对于地理环境，我们需要一个大型的IT后台办公室来促进公司的成长和供应链的成长。 对于全渠道（一般顺序）-用于内部系统，实时，微服务和数百个子系统之间的同步的不同级别的SLA。 这通常是IT成熟度的不同水平。 对于平台而言，变更的速度也很重要。
刚开始时，每个人都认为敏捷将拯救世界。 对于承包商而言，敏捷可能没有那么有效。 因此，希望在IT部门
招聘 200名员工。
我们看到了在不损失品牌的前提下，我们能够以多快的速度实施一切。 可以很快写一些东西，但是没有时间准备服务。 例如，如果没有库存信息，那么无法保证保留商品，就无法在线付款。 我们将相互依存关系链分解为几个。 现在我们已经知道我们需要缩短周期，因为团队的能力仍然很重要。 现在，我们看到的特征很小，我们正在收集连接，现在只有当年在计划中。 长期战略（但根据功能）最多为一年，并且有许多独立的产品团队。