25 月 XNUMX 日，我们 Mail.ru Group 举办了一场关于云和周围的会议 - 。 几个亮点：
- 主要的 — Mail.ru Cloud Solutions、#CloudMTS、SberCloud、Selectel、Rostelecom Data Center 和 Yandex.Cloud 谈到了我们云市场及其服务的具体情况；
- Bitrix24 的同事讲述了他们是如何 ;
- Leroy Merlin、Otkritie、汉堡王和施耐德电气提供了有趣的内容 — 他们的企业为 IT 设定了哪些任务以及他们认为最有前途的技术（包括云技术）。
您可以观看 mailto:CLOUD 会议中的所有视频 ，在这里您可以阅读有关微服务的讨论如何进行。 MegaFon业务系统研发中心负责人Alexander Deulin和M.Video-Eldorado集团信息技术总监Sergey Sergeev分享了他们摆脱庞然大物的成功案例。 我们还讨论了IT战略、流程甚至HR的相关问题。
小组成员
- 谢尔盖·谢尔盖夫（Sergey Sergeev）, 集团首席信息官 《M.Video-埃尔多拉多》;
- 亚历山大·杜林业务系统研发中心主任 兆丰;
- 主持人—— 德米特里·拉扎连科, PaaS方向负责人 Mail.ru 云解决方案.
亚历山大·杜林 (Alexander Deulin) 演讲后 M.Video-Eldorado 的 Sergey Sergeev 和 Mail.ru Cloud Solutions 的讨论主持人 Dmitry Lazarenko 也参与了讨论。
下面我们为您准备了讨论记录，但您也可以观看视频：
向微服务的过渡是对市场需求的响应
德米特里：
您有迁移到微服务的成功经验吗？ 一般来说：您认为使用微服务或从整体迁移到微服务的最大商业利益在哪里？
谢尔盖：
我们在向微服务的过渡方面已经取得了一些进展，并且已经使用这种方法三年多了。 证明微服务合理性的第一个需求是各种前端产品与后台的无休止的集成。 每次我们都被迫进行额外的集成和开发，实施我们自己的规则来操作这个或那个服务。
在某些时候，我们意识到我们需要加快系统的运行和功能的输出。 当时，市场上已经存在微服务和微服务方法等概念，我们决定尝试一下。 这要从 2016 年开始。 然后平台铺设完毕，前10项服务由单独的团队实施。
价格计算服务是最早、负载最重的服务之一。 每次您来到任何渠道、M.Video-Eldorado 集团公司，无论是网站还是零售店，在那里选择产品，查看网站上或“购物篮”中的价格，费用就会自动计算由一项服务计算。 为什么这是必要的：在此之前，每个系统都有自己的促销原则 - 折扣等。 我们的后台处理定价；折扣功能在另一个系统中实现。 这需要集中化，并以业务流程的形式创建一个独特的、可分离的服务，使我们能够实现这一点。 我们就是这样开始的。
第一个结果的价值非常大。 首先，我们能够创建可分离的实体，使我们能够单独并以聚合的方式工作。 其次，我们在与更多系统集成方面降低了拥有成本。
三年来，我们新增了三个一线系统。 用公司所能负担的同等资源来维持它们是很困难的。 因此，我们面临的任务是寻找新的出路，以速度、内部成本和效率来响应市场。
如何衡量迁移到微服务是否成功
德米特里：
如何确定迁移到微服务是否成功？ 每家公司的“以前”是什么？ 您使用什么指标来确定过渡是否成功？由谁实际决定？
谢尔盖：
首先，它诞生于 IT 领域，作为推动者——“解锁”新功能。 我们需要以相对相同的资金更快地完成所有工作，以应对市场挑战。 现在，成功体现在不同系统重用的服务数量以及流程之间的统一。 现在是这样，但在那一刻，这是一个创建平台并确认我们可以做到这一点的假设的机会，它将产生效果并计算业务案例。
亚历山大：
成功更多的是一种内在的感觉。 企业总是想要更多，我们积压的深度就是成功的证明。 对我来说似乎是这样。
谢尔盖：
是的我同意。 三年来，我们已经有两百多个服务和积压。 团队内部对资源的需求仅以每年 30% 的速度增长。 发生这种情况是因为人们感到：它更快，它不同，有不同的技术，所有这些都在发展。
微服务将会到来，但核心仍将存在
德米特里：
这就像一个永无止境的过程，你需要投资于开发。 业务向微服务的过渡是否已经结束？
谢尔盖：
这很容易回答。 您认为更换手机是一个永无止境的过程？ 我们自己每年都会购买手机。 这就是：只要需要速度，为了适应市场，就需要一些改变。 这并不意味着我们放弃标准的东西。
但我们不能一次性覆盖并重做所有事情。 我们拥有以前存在的遗留标准集成服务：企业总线等。 但有积压，也有需求。 移动应用程序的数量及其功能正在不断增长。 同时，没有人说会给你多30%的钱。 也就是说，总是一方面有需求，另一方面又追求效率。
德米特里：
生活状况良好。 （笑）
亚历山大：
一般来说，是的。 我们没有革命性的方法来从景观中移除核心部分。 正在进行系统性的工作，对系统进行分解，使之更加符合微服务架构，减少系统之间的影响。
但我们计划保留核心部分，因为在运营商的视野中总会有一些我们购买的平台。 同样，我们需要一个健康的平衡：我们不应该急于削减核心。 我们将系统并排放置，现在事实证明我们已经掌握了许多核心部分。 此外，在开发功能时，我们为与我们的通信服务配合使用的所有渠道创建了必要的表示。
如何向企业销售微服务
德米特里：
我也对那些尚未转行但计划转行的人感兴趣：将这个想法出售给企业有多容易？这是一次冒险还是一个投资项目？ 或者这是一个有意识的策略：现在我们要转向微服务，就这样，没有什么可以阻止我们。 你感觉怎么样？
谢尔盖：
我们出售的不是一种方法，而是一种商业利益。 业务上出现了问题，我们试图解决它。 当时的表现是，不同的渠道使用不同的计算价格的原则——分别用于促销、促销等。 维护起来很困难，经常出现错误，我们还听取了客户的投诉。 也就是说，我们正在出售问题的解决方案，但我们面临的事实是我们需要资金来创建一个平台。 他们使用第一阶段投资的例子展示了一个商业案例：我们将如何继续收回投资以及这将允许我们做什么。
德米特里：
你有记录第一阶段的时间吗？
谢尔盖：
是的，当然。 我们分配了 6 个月的时间来创建核心平台并进行试点测试。 在此期间，我们尝试创建一个平台供飞行员滑行。 那么假设就得到了证实，既然可行，那就说明我们可以继续下去了。 他们开始复制并加强团队——他们将其转移到一个单独的部门来完成这个任务。
接下来是基于业务需求、机会、资源可用性和当前正在进行的一切的系统工作。
德米特里：
好的。 亚历山大，你说什么？
亚历山大：
我们的微服务诞生于“大海的泡沫”——由于节省资源、由于服务器容量形式的一些剩余以及团队内力量的重新分配。 最初，我们没有将这个项目出售给企业。 这是我们共同研究和开发的一个项目。 我们从2018年初开始，只是满怀热情地发展这个方向。 销售刚刚开始，我们正在进行中。
德米特里：
是否有企业允许您每周有一天免费做 Google 之类的事情？ 你有这样的方向吗？
亚历山大：
研究的同时，我们也处理业务问题，所以我们所有的微服务都是业务问题的解决方案。 一开始我们构建的微服务只覆盖了一小部分用户群，现在我们几乎出现在所有旗舰产品中。
实质性影响已经很明显——如果我们走老路，我们已经可以计算出来，产品发布的速度和收入损失也可以估计。 这就是我们构建案例的基础。
微服务：炒作还是必要性？
德米特里：
数字就是数字。 收入或节省的金钱非常重要。 如果你看另一面呢？ 似乎微服务是一种趋势，一种炒作，许多公司都在滥用它？ 您如何清楚地区分您所做的和不转化为微服务的事情？ 如果现在有遗产，5年后你还会有遗产吗？ 5 年后，M.Video-Eldorado 和 MegaFon 的信息系统的年龄将是多少？ 是否会有十年、十五年历史的信息系统，还是新一代的信息系统？ 您对此有何看法？
谢尔盖：
在我看来，很难想得很远。 回顾过去，谁能想到科技市场会发展成这样，包括机器学习、人脸识别？ 但如果你看看未来几年，在我看来，公司的核心系统、企业 ERP 级系统 - 它们已经工作了相当长的时间。
我们的公司总共已有 25 年历史，经典 ERP 已深入系统领域。 很明显，我们正在从中取出一些部分并尝试将它们聚合到微服务中，但核心仍将保留。 我现在很难想象我们会更换那里的所有核心系统，并迅速转移到新系统的另一个光明的一面。
我支持这样一个事实：一切离客户和消费者更近的地方都是最大的商业利益和价值，其中适应性和对速度、变化、“尝试、取消、重用、做不同的事情”的关注是最重要的。需要“——这就是景观将发生变化的地方。 而且盒装产品不太适合放在那里。 至少我们没有看到它。 那里需要最简单、最简单的解决方案。
我们看到这样的发展：
- 核心信息系统（主要是后台）；
- 中间层以微服务的形式连接核心、聚合、创建缓存等；
- 一线系统针对的是消费者；
- 通常集成到市场、其他系统和生态系统中的集成层。 该层尽可能轻量、简单，并且包含最少的业务逻辑。
但与此同时，如果使用得当，我支持继续使用旧原则。
假设您有一个经典的企业系统。 它位于一个供应商的环境中，由两个相互协作的模块组成。 还有一个标准的集成接口。 为什么要重做并在那里引入微服务？
但当后台有5个模块，将其中的信息收集到业务流程中，然后供8-10个一线系统使用时，好处立即显而易见。 您从五个后台系统中获取并创建一个服务，一个独立的服务，专注于业务流程。 使服务在技术上先进 - 以便它可以缓存信息并具有容错能力，并且还可以与文档或业务实体一起使用。 您可以根据单一原则将其与所有一线产品集成。 他们取消了一线产品——他们只是关闭了集成。 明天您需要编写一个移动应用程序或制作一个小型网站，并且只将一部分放入功能中 - 一切都很简单：您像构造函数一样组装它。 我看到这个方向有更多的发展——至少在我们国家。
亚历山大：
谢尔盖完整地描述了我们的方法，谢谢。 我只想说我们绝对不会去的地方——核心部分，在线计费的主题。 也就是说，评级和收费实际上仍然是一个“大”脱粒机，可以可靠地冲销资金。 并且这个系统将继续得到我们监管机构的认证。 当然，其他一切面向客户的都是微服务。
德米特里：
这里的认证只是一个故事。 应该会得到更多的支持吧。 如果你在支持上花费很少或者系统不需要支持和修改，最好不要碰它。 合理的妥协。
如何开发可靠的微服务
德米特里：
美好的。 但我仍然感兴趣。 现在你正在讲述一个成功的故事：一切都很好，我们转向微服务，向业务部门捍卫这个想法，然后一切都顺利了。 但我还听过其他故事。
几年前，一家瑞士公司投资了两年为银行开发新的微服务平台，最终关闭了该项目。 彻底崩溃了。 花费了数百万瑞士法郎，最终团队被解散——这没有成功。
你有过类似的故事吗？ 有没有或者现在有什么困难？ 例如，维护微服务和监控也是公司运营活动中令人头疼的问题。 毕竟元件数量增加了数十倍。 您怎么看，这里有投资不成功的例子吗？ 您可以向人们提出什么建议，以免他们遇到此类问题？
亚历山大：
不成功的例子包括企业改变优先级和取消项目。 当处于良好的准备阶段时（事实上，MVP 已经准备好了），企业表示：“我们有新的优先事项，我们正在转向另一个项目，我们正在关闭这个项目。”
我们的微服务没有发生任何全局故障。 我们睡得很安稳，我们有 24/7 轮班，为整个 BSS [业务支持系统] 提供服务。
还有一件事 - 我们根据适用于盒装产品的规则出租微服务。 成功的关键是，首先，您需要组建一个团队，为生产做好充分的微服务准备。 开发本身是有条件的40%。 剩下的就是分析、DevSecOps 方法、正确的集成和正确的架构。 我们特别关注构建安全应用程序的原则。 信息安全代表在架构规划阶段和实施过程中参与每个项目。 他们还管理用于分析代码漏洞的系统。
假设我们部署了无状态服务 - 我们将它们放在 Kubernetes 中。 由于服务的自动扩展和自动提升，每个人都可以安然入睡，并且值班会发生事件。
在我们微服务的整个存在过程中，只有一两个事件到达了我们的生产线。 现在操作已经没有问题了。 当然，我们拥有的微服务不是 200 个，而是大约 50 个，但它们都用在旗舰产品中。 如果他们失败了，我们将是第一个知道的人。
微服务和人力资源
谢尔盖：
我同意我同事关于转移到支持部门的观点——工作需要正确组织。 但我会告诉你当然存在的问题。
首先，技术是新的。 这是一种很好的炒作，找到一位能够理解并能够创造这一点的专家是一个巨大的挑战。 资源的竞争是疯狂的，所以专家是有价值的。
其次，随着某些景观的打造和服务的不断增多，重复利用的问题必须不断解决。 正如开发人员喜欢做的那样：“现在让我们在这里写很多有趣的东西......”因此，系统会不断增长，并在金钱、拥有成本等方面失去有效性。 也就是说，有必要将重用纳入系统架构中，将其纳入引入服务和将遗留系统转移到新架构的路线图中。
另一个问题是内部竞争，尽管这本身是件好事。 “哦，这里出现了新的时尚人士，他们说一种新的语言。” 当然，人是不同的。 有些人习惯用 Java 编写，有些人编写并使用 Docker 和 Kubernetes。 他们是完全不同的人，他们说话方式不同，使用不同的术语，有时彼此无法理解。 能否分享实践、分享知识，从这个意义上来说也是一个问题。
好吧，扩展资源。 “太好了，我们走吧！ 现在我们想要更快、更多。 什么，你不能？ 一年交付量不是可以翻倍吗？ 为什么？” 这种成长的烦恼可能是很多事情、很多方法的标准，你可以感觉到它们。
关于监控。 在我看来，服务或工业监控工具已经在学习或能够以不同的非标准模式与 Docker 和 Kubernetes 一起工作。 因此，举例来说，您最终不会拥有 500 台 Java 机器来运行所有这些，即聚合。 但这些产品还不够成熟，必须经历这个过程。 这个话题确实很新，它会继续发展。
德米特里：
是的，非常有趣。 这也适用于人力资源。 也许您的人力资源流程和人力资源品牌在这三年中发生了一些变化。 你开始招募具有不同能力的其他人。 可能有利也有弊。 此前，区块链和数据科学被炒作，这些领域的专家身价数百万美元。 现在成本在下降，市场正在趋于饱和，微服务也有类似的趋势。
谢尔盖：
是的，绝对。
亚历山大：
HR 提出问题：“你的粉色独角兽在后端和前端之间在哪里？” HR 不明白什么是微服务。 我们告诉他们这个秘密，并告诉他们后端做了一切，并且没有独角兽。 但人力资源部门正在发生变化，快速学习并招聘具有基本 IT 知识的人员。
微服务的演变
德米特里：
如果你看看目标架构，微服务看起来就像一个怪物。 你的旅程花了几年时间。 有的人一年，有的人三年。 您是否预见到了所有问题、目标架构，有什么变化吗？ 例如，就微服务而言，网关和服务网格现在再次出现。 您是一开始就使用它们还是更改了架构本身？ 你有这样的挑战吗？
谢尔盖：
我们已经重写了几个通信协议。 起初有一个协议，现在我们改用另一个协议。 我们提高安全性和可靠性。 我们从企业技术开始 - Oracle、Web Logic。 现在，我们正在从微服务中的技术企业产品转向开源或完全开放的技术。 我们放弃数据库，转向在这个模型中对我们更有效的方法。 我们不再需要 Oracle 技术。
我们一开始只是简单地作为一个服务，没有考虑我们需要多少缓存，当没有与微服务连接但需要数据时我们会做什么等等。现在我们正在开发一个平台，以便可以描述架构不是用服务语言，而是用业务语言，当我们开始用语言交谈时，将业务逻辑提升到一个新的水平。 现在我们已经学会了用字母说话，下一个层次是服务将被收集到某种聚合中，此时这已经是一个单词 - 例如，整个产品卡。 它是由微服务组装而成，但它是建立在其之上的 API。
安全非常重要。 一旦你开始变得容易访问，并且你拥有一项服务，通过它你可以很快地、在一瞬间获得很多有趣的东西，那么就会渴望以一种不是最安全的方式获得它。 为了避免这种情况，我们必须改变测试和监控的方法。 我们必须改变团队、交付管理结构、CI/CD。
这是一种演变——就像电话一样，只是速度更快：首先出现了按钮式电话，然后出现了智能手机。 由于市场有不同的需求，他们重写并重新设计了产品。 这就是我们的发展方式：一年级，十年级，工作。
迭代地，每年从技术的角度布局一些东西，从积压和需求的角度布局一些东西。 我们将一件事与另一件事联系起来。 团队花费 20% 用于团队的技术债务和技术支持，80% 用于业务实体。 我们在行动时了解我们为什么要这样做，为什么我们要进行这些技术改进，以及它们会带来什么。 像那样。
德米特里：
凉爽的。 MegaFon 中有什么？
亚历山大：
当我们接触微服务时，主要的挑战是不要陷入混乱。 MegaFon的架构办公室立即加入了我们，甚至成为了发起者和推动者——现在我们有了一个非常强大的架构。 他的任务是了解我们要采用什么目标模型以及需要试点哪些技术。 对于建筑，我们自己进行了这些试点。
下一个问题是：“那么如何利用这一切呢？” 还有一题：“如何确保微服务之间的透明交互？” 服务网格帮助我们回答了最后一个问题。 我们试用了 Istio 并且喜欢结果。 现在我们正处于向生产区推广的阶段。 我们对所有挑战都抱有积极的态度——事实上，我们需要不断改变堆栈，学习新的东西。 我们感兴趣的是开发而不是利用旧的解决方案。
德米特里：
金字！ 这些挑战让团队和业务保持警惕并创造未来。 GDPR 设立了首席数据保护官，而当前的挑战则设立了首席微服务和架构官。 这很令人高兴。
我们讨论了很多。 最重要的是，良好的微服务设计和架构本身可以让你避免很多错误。 当然，这个过程是迭代和进化的，但这就是未来。
感谢所有参与者，感谢谢尔盖和亚历山大！
观众提问
观众提问（1）：
Sergey，您公司的 IT 管理发生了怎样的变化？ 我知道，当有多个系统组成的大堆栈时，如何管理它是一个相当清晰且合乎逻辑的过程。 在这么短的时间内集成了大量的微服务之后，你们是如何重建IT组件的管理的？
谢尔盖：
我同意我同事的观点，即架构作为变革的驱动力非常重要。 我们首先成立了一个建筑部门。 建筑师同时也是功能分配和功能在景观中如何出现的要求的所有者。 因此他们也充当这些变革的协调者。 因此，当我们创建 CI/CD 平台时，对特定的交付流程进行了特定的更改。
但标准、开发基本原则、业务分析、测试和开发并没有取消。 我们只是增加了速度。 以前，周期花费了很多时间，在测试环境中安装也花费了更多时间。 现在，企业看到了好处，并说：“为什么我们不能在其他地方做同样的事情呢？”
从好的方面来说，这就像以疫苗的形式进行注射，表明：你可以用这种方式做到这一点，但你也可以用另一种方式做到这一点。 当然，人员上有问题，能力上有问题，知识上有问题，抵抗力上有问题。
观众提问（2）：
微服务架构的批评者表示测试和开发很困难。 当事情变得复杂时，这是合乎逻辑的。 您的团队面临哪些挑战以及您是如何克服这些挑战的？ 向大家提问。
亚历山大：
从微服务迁移到平台时会遇到一些困难，但这些困难是可以解决的。
例如，我们正在制作一个由 5-7 个微服务组成的产品。 我们需要在整个微服务堆栈中提供集成测试，以便为迁移到主分支开绿灯。 这项任务对我们来说并不新鲜：我们在 BSS 已经这样做了很长时间，当时供应商为我们提供了已经发货的解决方案。
而我们的问题只出在小团队上。 一款有条件的产品需要一名 QA 工程师。 因此，我们推出了包含 5-7 个微服务的产品，其中 2-3 个可以由第三方开发。 例如，我们的计费系统供应商 Mail.ru Group 和 MegaFon R&D 参与了一款产品的开发。 在将其投入生产之前，我们需要对其进行测试。 QA 工程师已经在这个产品上工作了一个半月，而团队的其他成员却失去了他的支持。
这种复杂性只是由缩放引起的。 我们知道微服务不可能存在于真空中；绝对的隔离是不存在的。 当更改一项服务时，我们总是尝试保留 API 契约。 如果引擎盖下发生了变化，前台服务仍然保留。 如果变化是致命的，就会发生某种架构转换，我们会转向完全不同的数据元模型，这是完全不兼容的——只有那时我们才谈论 v2 服务 API 规范的出现。 我们同时支持第一个和第二个版本，当所有消费者切换到第二个版本后，我们只需关闭第一个版本即可。
谢尔盖：
我想补充一下。 我完全同意并发症的说法——它们确实会发生。 情况变得越来越复杂，管理成本也在增加，尤其是测试成本。 如何处理这个问题：切换到自动化测试。 是的，您必须额外投资编写自动测试和单元测试。 这样开发人员就无法在未通过测试的情况下提交，也无法更改代码。 因此，如果没有自动测试、单元测试，即使按钮也无法工作。
维护以前的功能很重要，这是额外的开销。 如果您将一项技术重写为另一种协议，那么您将重写它，直到完全关闭所有内容。
我们有时不会故意进行端到端测试，因为我们不想停止开发，尽管我们也有一件又一件的事情。 景观非常大、复杂，有很多系统。 有时这只是存根 - 是的，你降低了安全裕度，就会出现更多风险。 但同时你释放了供应。
亚历山大：
是的，自动测试和单元测试允许您创建高质量的服务。 我们支持没有单元和集成测试就无法通过的管道。 我们经常要把模拟器和商业系统拖到测试区和开发环境中，因为并不是所有的系统都可以放在测试区。 此外，它们不仅仅会被弄湿，我们还会从系统中生成完整的响应。 这是微服务工作的重要组成部分，我们也在对此进行投资。 如果没有这个，就会出现混乱。
观众提问（3）：
据我了解，微服务最初是由一个单独的团队发展而来，现在存在于这个模型中。 它的优点和缺点是什么？
我们有一个类似的故事：一种微服务工厂的出现。 现在，我们在概念上已经达到了这样的程度：我们正在将这种方法扩展到通过流和系统进行生产。 换句话说，我们正在远离微服务、微服务模型的中心化开发，而越来越接近系统。
相应地，我们的操作也走向了系统，就是说我们正在去中心化这个话题。 你的方法是什么？你的目标故事是什么？
亚历山大：
你直接从嘴里说出了“微服务工厂”这个名字——我们也想扩大规模。 首先，我们现在确实拥有了一支球队。 我们希望为 MegaFon 的所有开发团队提供在共同生态系统中工作的机会。 我们不想完全接管我们现在拥有的所有开发功能。 局部任务是扩展，全局任务是领导微服务层所有团队的开发。
谢尔盖：
我会告诉你我们走过的路。 我们真正开始作为一个团队工作，但现在我们并不孤单。 我是以下观点的支持者：流程必须有一个所有者。 需要有人理解、管理、控制和构建微服务开发流程。 他必须拥有资源并参与资源管理。
这些了解技术、细节并了解如何构建微服务的资源可以位于产品团队中。 我们有一个组合，来自微服务平台的人员加入了制作移动应用程序的产品团队。 他们在那里，但是他们按照微服务平台管理部门的流程和他们的开发经理一起工作。 该部门内有一个单独的团队负责技术处理。 也就是说，我们将我们之间的公共资源混合起来，然后将它们划分给团队。
与此同时，该过程仍然是通用的、受控的，它根据通用技术原理进行，并进行单元测试等等——一切都建立在之上。 可能会有专栏的形式收集来自不同部门的产品方法的资源。
亚历山大：
Sergey，您实际上是该流程的所有者，对吗？ 任务积压是否共享？ 谁负责其分配？
谢尔盖：
看：这又是混音。 由于技术改进而形成了积压的订单——这是一个故事。 有一个积压订单，它是由项目制定的，还有一个积压订单来自产品。 但是引入每个服务产品或创建该服务的顺序是由产品专家制定的。 他不在 IT 部门；他是被特意调离的。 但我的员工肯定是按照同样的流程工作的。
不同方向的积压工作（变更积压工作）的所有者将是不同的人。 技术服务的连接及其组织原则 - 所有这些都将在 IT 中实现。 我也拥有这个平台和资源。 最上面的是积压和功能变更以及这个意义上的架构。
假设一家企业说：“我们想要这个功能，我们想要创建一个新产品——重新发放贷款。” 我们回答：“是的，我们会重做。” 架构师说：“让我们想一想：我们将在贷款的哪个位置编写微服务以及如何实现？” 然后我们将其分解为项目、产品或技术堆栈，将其放入团队并实施。 您是否在内部创建了一个产品并决定在该产品中使用微服务？ 我们说：“现在我们拥有的遗留系统或一线系统必须切换到这些微服务。” 架构师说：“所以：在一线产品内部的技术积压中——向微服务的过渡。 去”。 产品专家或企业主了解分配了多少容量、何时完成以及原因。
讨论结束，但还没有结束
mailto:CLOUD 会议召开 .
我们还举办其他活动 - 例如 @Kubernetes 聚会，我们一直在寻找优秀的演讲者：
- 在我们的 Telegram 频道中关注 @Kubernetes 和其他 @Meetup 新闻
- 有兴趣在 @Meetups 之一上发表演讲吗？ 留下请求
来源： habr.com