4月25日，我们在Mail.ru Group召开了一次有关云和围绕
mailto的会议
：CLOUD 。 一些要点：
- 俄罗斯主要的提供商聚集在一个阶段-Mail.ru云解决方案，＃CloudMTS，SberCloud，Selectel，Rostelecom数据中心和Yandex。Cloud谈到了我们的云市场及其服务的具体细节；
- 来自Bitrix24的同事讲述了他们是如何陷入多重竞争的;
- Leroy Merlin，Otkrytie，Burger King和Schneider Electric 就云用户而言提供了一个有趣的观点 -他们的业务为IT设定哪些任务以及他们认为最有前途的技术（包括云技术）。
您可以在此处查看mailto：CLOUD会议的所有视频，但在这里您可以阅读有关微服务的讨论。 MegaFon业务系统研发中心负责人Alexander Deulin和M. Video-Eldorado集团信息技术总监Sergey Sergeyev分享了成功摆脱单块的案例。 他们还讨论了IT战略，流程甚至HR的相关问题。
小组成员
- M.Video-Eldorado集团信息技术总监Sergey Sergeev ；
- MegaFon业务系统研发中心负责人Alexander Deulin ；
- 主持人-PaaS方向Mail.ru云解决方案负责人Dmitry Lazarenko 。
在Alexander Deulin发表演讲
“ MegaFon如何通过微服务平台扩展业务”之后，来自M.Video-Eldorado的Sergey Sergeev参加了讨论，并主持了Mail.ru Cloud Solutions的讨论Dmitry Lazarenko。
下面我们为您准备了讨论记录，但您也可以观看视频：
转向微服务-对市场需求的回应
德米特里：您有转换到微服务的成功经验吗？ 通常，您会从微服务的使用或从整体式服务向微服务的过渡中看到最大的业务收益？
谢尔盖：我们已经在某种程度上过渡到微服务，并且已经使用这种方法三年多了。 证明需要微服务的第一个需求是不同的前线产品与后台的无休止的集成。 而且每次我们都必须进行其他集成，开发，实施我们的服务操作规则时。
在某个时候，我们意识到我们需要加快系统和输出功能的速度。 那时，市场上已经存在诸如微服务，微服务方法之类的概念，我们决定尝试一下。 它始于2016年。 然后，由一个单独的团队铺设平台并实施前10个服务。
价格计算服务是最早的，负载最重的服务之一。 每当您进入任何一个频道，进入M.Video-Eldorado公司集团，无论是网站还是零售店，都在那儿接货，在网站上或“购物篮”中查看价格时，一项服务会自动计算价格。 为何需要这样做：在此之前，每个系统都有其与促销配合使用的原则-折扣等。 后台进行定价，折扣功能在另一个系统中实现。 有必要以业务流程的形式集中并创建这种独特的，可分离的服务，以使我们能够执行此服务。 我们就是这样开始的。
第一个结果的价值非常大。 首先，我们能够创建可分离的实体，使我们能够单独工作，聚合在一起。 其次，在与大量系统集成方面，我们降低了拥有成本。
在过去的三年中，我们增加了三个前线系统。 很难以公司能够负担的相同数量的资源来维护它们。 因此，出现了寻找新的出口，在速度，内部成本和效率方面响应市场的任务。
如何评估向微服务过渡的成功
德米特里：如何确定切换到微服务的成功？ 每个公司的“之前”是什么？ 您使用什么指标来确定过渡的成功，实际上是谁确定的？
谢尔盖：首先，它作为推动者在IT内部诞生-“解锁”新功能。 我们需要以相对相同的资金更快地完成所有工作，以应对市场挑战。 现在，成功由不同系统重用的服务数量，流程之间的统一表示。 事实如此，到那时，这是一个创建平台并确认我们可以做到这一假设的机会，这将给业务案例带来效果和计算。
亚历山大：成功是一种内在的感觉。 商业总是想要更多，而我们积压的深度是成功的证明。 我也这么认为
谢尔盖：是的，我同意。 三年来，我们已经有超过200种服务和未完成订单。 团队内部对资源的需求仅以每年30％的速度增长。 这是因为人们感到：与其他技术相比，它更快，所有东西都在发展。
微服务将到来，但核心仍将保留
德米特里：这就像一个无休止的过程，您需要在开发上进行投资。 企业本身向微服务的过渡是否已经结束？
谢尔盖：很容易回答。 您如何看：更换手机是一个漫长的过程？ 我们自己每年都购买电话。 这就是：尽管需要速度，但为了适应市场，将需要进行一些更改。 这并不意味着我们拒绝标准的东西。
但是我们不能立即拥抱并重做一切。 我们之前有传统的标准集成服务：企业总线等。 但是有很多积压，也有需要。 移动应用程序及其功能的数量正在增长。 同时，没有人说他们会给您更多30％的钱。 也就是说，一方面总有需求，另一方面寻求效率。
德米特里：生活状况良好。
（笑）亚历山大：一般来说，是的。 我们没有从景观中移除核心部分的革命性方法。 正在进行系统工作以分解系统，以便它们与微服务体系结构更加一致，以减少系统之间的相互影响。
但是我们计划保留核心部分，因为在运营商的视野中，总会有一些我们要购买的平台。 同样，您需要一个健康的平衡点：我们不应该急于进入“切割”核心。 我们将系统并排放置，现在，事实证明已经覆盖了许多核心部分。 此外，在开发功能时，我们为与我们的通信服务一起使用的所有渠道做出了必要的表示。
如何向企业出售微服务
德米特里：我仍然很感兴趣-对于那些尚未转换但要去的人：将这个想法推销给企业有多容易，这是一次赌博，一项投资项目吗？ 或这是一个精心设计的策略：现在我们开始使用微服务，仅此而已，没有什么能阻止我们。 你最近怎么样
谢尔盖：我们没有出售这种方法，但从中获得了业务收益。 业务中存在问题，我们试图将其消除。 当时，有人表示，在不同的渠道中使用了不同的定价原则-分别用于促销，库存等。 这很难维护，出现了错误，我们听了客户的抱怨。 也就是说，我们卖掉了消除问题的方法，但事实是我们需要金钱来创建一个平台。 他们以第一阶段投资为例展示了一个商业案例：我们将如何继续为之付款，以及它将允许我们做什么。
德米特里：您是否已经确定了第一阶段的时间？
谢尔盖：当然可以 我们花了6个月的时间来创建核心平台和先导测试。 在这段时间里，我们试图创建一个供飞行员滑冰的平台。 他们进一步证实了这一假设，并且既然可行，那么我们可以继续。 他们开始复制并加强团队-他们将其带到一个单独的部门，该部门仅参与其中。
接下来是系统的工作，从业务需求，机会，资源可用性以及现在正在进行的所有工作着手。
德米特里：好吧 亚历山大，你怎么说？
亚历山大：我们的微服务源于“海泡沫”，这是由于节省资源，服务器容量和团队内部力量再分配之间的某种平衡。 最初，我们没有将此项目出售给企业。 我们在这个项目中进行了相应的研究和开发。 我们从2018年初开始，并热情地发展了这个方向。 销售才刚刚开始，我们正在进行中。
德米特里：但是，碰巧的是，一家公司允许您按照Google的原则进行此类操作-一周一次免费吗？ 你有这个方向吗？
亚历山大：在进行研究的同时，我们从事业务任务，因为我们所有的微服务都是业务问题的解决方案。 仅在开始时，我们就构建了覆盖一小部分订户基础的微服务，而现在，我们几乎使用了所有旗舰产品。
物质影响已经很明显了-如果我们采用旧的方法，我们已经可以计数，可以估算产品输出的速度和收入损失。 这是我们构建案例的地方。
微服务：炒作还是需要？
德米特里：数字就是数字。 节省的收入或金钱非常重要。 如果你看看另一边？ 似乎微服务是一种趋势，大肆宣传，许多公司滥用它？ 您如何清楚地区分微服务和不翻译的内容？ 如果现在是遗产，那么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机器在其下运行所有这些程序，即聚合。 但是这些产品仍然缺乏成熟度，它们必须经历这一过程。 这个话题真的很新，它将继续发展。
德米特里：是的，非常有趣。 这适用于人力资源。 在这三年中，您的人力资源流程和人力资源品牌可能已经发生了一些变化。 您开始招募具有不同能力的其他人。 而且可能有优缺点。 以前，区块链和数据科学是高科技，而其中的专家价值仅数百万。 现在价格下降，市场已经饱和，微服务也有类似趋势。
谢尔盖：是的，绝对。
亚历山大：人力资源部问一个问题：“后端和前端之间的粉红色独角兽在哪里？” 人力资源部不了解什么是微服务。 我们向他们透露了一个秘密，并说这个后端做了所有事情，而且没有独角兽。 但是，人力资源部门正在发生变化，正在迅速学习并招募拥有基本IT知识的人员。
微服务的演变
德米特里：如果您查看目标体系结构，那么微服务看起来就像是一个庞然大物。 您的旅程花了几年时间。 其他人有一年，其他人有三年。 您预见了所有问题，目标体系结构是否有所变化？ 例如，在微服务的情况下，网关，服务网格现在再次出现。 您是在一开始使用它们还是更改了体系结构本身？ 您有这样的挑战吗？
谢尔盖：我们已经重写了几种交互协议。 最初，一种协议现已转换为另一种。 我们提高了安全性和可靠性。 我们从企业技术开始-Oracle，Web Logic。 现在，我们正在远离微服务中的技术企业产品，而转向开源或完全开放的技术。 我们放弃了数据库，继续研究在此模型中对我们更有效的方法。 我们不再需要Oracle技术。
, , , , , , . . , , -, - , . , — - , — , . , API.
. , , , , . , . , , CI/CD.
— , : , . , , . : , , .
- , - — backlog' . . 20% , 80% — -. , , , , . .
:. «»?
:— . , «» — . , . .
: « ?». : « ?». service mesh. Istio, . . — , , - . , .
:! . GDPR chief data protection officers, . .
. — . , , .
, !
(1):, IT- ? , , — . IT- , ?
:, . , . , . . , CI/CD.
, , -, — . . -, — -. : « ?».
, , , : , -. , , , , .
(2):, . , - . ? .
:, .
, , 5-7 . , -. : BSS, .
. QA-. , 5-7 , 2-3 . , , , Mail.ru Group R&D «». , . QA- , .
. , , . , API-. - , front . , - , — , API- v2. , .
:. — . , , . : . , unit-. , . push , unit-.
, . , , .
end-to-end , , . , , . — , , . .
:, unit- . , unit- . , , . — . , . .
(3):, . ?
: . , . , , , .
, , . ?
:« » — . -, . , «», . , . — , — .
:, . , . : . - , , . -.
, , , , . , , . , . , . , .
, , , unit- — , . , .
:, , ? Backlog ? ?
:: . backlog, , — . backlog, , backlog . . IT-, . .
backlog' — backlog' — . , — IT. , — . , backlog' , .
, : « , — ». : «, ». : « : ?». , , . ? : « legacy-, , , ». : «: backlog — . ». , capacity, .
,
mailto：CLOUD会议由Mail.ru Cloud Solutions主持。我们还进行其他活动-例如@Kubernetes Meetup，在这里我们总是寻找出色的演讲者：