而不是介绍
自第一个微服务推出以来已经过去了几个月。在我们看来，现在是时候讲述所获得的经验。
值得立即对本文中将要保留的内容和保留的内容不作保留。本文不会以这些决策的原理来描述体系结构解决方案和说明。我们将不专注于创建微服务的技术堆栈。
本文的主要重点将放在我们的团队在整个项目中面临的全局问题上。
本文将是众多文章中的第一篇。首先，它的目标是在向微服务架构过渡的过程中介绍我们的问题，并顺利引出以下主题，这些主题详细揭示了过渡的某些方面。
一切如何开始
大约一年半前，决定切换到微服务架构。我们面临的挑战是为公司的快速发展做准备。我们必须在技术解决方案方面变得更加灵活，提高更改速度，当然还要提高系统的弹性。
在决定切换到微服务架构之后，由经验丰富且积极主动的团队创建了一个独立的部门。决定向新部门转移的候选人的决定因素是在一个或多个现有信息系统中的高度专业知识。
由于当时对工作方面尚无明确的了解，因此该团队是自发成立的。但是，与此同时，那时已经确立了自给自足的原则-团队中的开发人员，分析师和测试人员应该拥有自己的原则。
一次选择了两条路径作为切换到微服务的策略：
- 我们将微服务带入微服务（正如我们所认为的）；
- 我们将微服务转移到微服务中，这可以解决业务和IT方面的大多数问题。
第一种方法是好的，因为在此过程中，团队将获得必要的专业知识并全力以赴，从而提高其后续工作的效率。第二种方法是为团队提供一种快速的胜利，表明为公司切换到微服务所选择的决策的正确性，并激励团队寻求新的壮举。
团队是旅程的开始。那是一段快乐的时光：前途一片光明，万里无云，在我们看来，我们有一个计划。
最初的困难
而且，当然，由于我们在谈论微服务，所以我们不得不谈论整体。这些是我们的主要信息系统。
这张照片最好地用Stefan Tilkov的文章“不要从整体开始”中得到最好的说明。正如我们所看到的，整体中的功能块彼此之间有着极为紧密的联系。这是将单独的功能转移到微服务的过程的严重障碍。
作为参考，我们的独石大约有13年的历史，平均独石的代码库约为120万行。
换句话说，团队一遍又一遍地面临以下问题：
- 分析现有功能的过程非常耗时；
- 通常缺乏对我们到底要为微服务带来什么的理解；
- 将整体与新的微服务集成的复杂性。
考虑到，除了解决这些问题外，团队还需要在新的堆栈和新的设计方法方面增加专业知识，进展并不很快。
然而，几个月后，该团队开始展示出最初的结果-第一个微服务友好地向所有人提供了他们的API。团队相信自己，并确定自己所做的一切正确。好吧，我们生活中的许多事情都是虚幻的。
最初的成功和新的困难
尽管遇到了最初的困难，该团队获得了新的经验和最初的成果。但是，出现了一些无法解释的风险，阻止了微服务的启动。
- 事实证明，这些单片尚未准备好与新堆栈一起使用，并且集成被延迟了。
- - .
- , , , , .
前两个问题非常简单地解决了-通过编写单独的客户端来集成Monolith和微服务，并相应地调整Monolith功能。但是，第三个问题至今尚未完全解决。
通过协同资源调度可以部分解决资源不一致的问题。似乎团队考虑了他们所有的错误，对正确的方法和正确的方法有所了解，到2020年初，大约有十几种微服务被编写出来（其中有些根本不是微服务），等待集成并发布到生产环境中。大多数关键业务流程，例如计算成本和交货时间，将新地区和办事处带到销售地点，搜索和选择商品等。
我们已经有了扎实的经验，并且遇到了很多坎s，我们充满信心地向前迈进了一步。似乎我们面临着所有陷阱，现在仍然有意逐步逐步执行我们的计划。
好…
隔离，劳动剥削和最终成功
今年年初对我们的计划进行了重大调整，这是由于当时传播的新冠状病毒的后果。显然，不需要解释什么是危险的：每个人都已经对该主题了如指掌。
大流行的爆发和随之而来的经济危机迫使我们公司重新考虑其发展重点。结果，IT优先级发生了变化-设置了新任务，旨在在最短的时间内将业务流程重塑为新的现实。
这些变化也影响了微服务计划。由于资源的重新分配，将微服务与整体集成在一起，并因此再次推迟了微服务本身的发布。
最后，在这里有必要更详细地介绍团队中发生的事情以及团队的感受。
首先是动力。由于长期缺乏可靠的结果，并且将近一年没有完整的现成的和集成的微服务投入生产，因此该团队在道德上非常疲惫（尽管如此，但仍然如此）。效率大大降低了。并非没有罕见但生动的情感崩溃。
其次，隔离并完全过渡到远程控制。当然，我们在远程工作方面拥有丰富的经验：几乎有1/3的开发人员是远程工作者。但是从事微服务的每个人都在同一办公室一起工作，向远程工作的过渡并没有以最佳方式影响团队的效率。一方面，这需要时间进行重组和过渡到新的工作形式。另一方面，正是在减少团队动力的时期，团队内需要更多的个人沟通和相互支持。
第三，团队需要证明结果。确实，尽管存在内部和外部问题，整个团队仍然清楚地理解：整个企业的进一步命运取决于我们能否以多快的速度将目标推向坚实的成果。我们公司中的许多人已经准备好承认及时，不成功地切换到微服务的实验并解散了部门。
在将近两个月的时间里，团队工作了12-15个小时，通常一周工作7天。她能够实现期望的目标-完全投入工作并与单片系统完全集成的四种微服务立即投入了全面生产。
重要的是要注意，我们没有使用任何棘手的技巧来激励团队，没有专门知识可以共享。就在一天又一天，团队做了以下工作：
- Skype通话频繁，可更新工作的当前状态并迅速解决新出现的问题；
- 通过不断检查每个团队的资源状态，在团队中保持积极的态度。
结果是
除了结论以外，我想谈谈我们为自己做出的结论...
- 跨团队。为了成功实施这些雄心勃勃的项目，必须有一个完全敬业的，自治的团队，并具有足够的资源来解决任何问题。在我们的案例中，这意味着在新堆栈上创建微服务的团队应该有来自整体开发团队的人员。如果我们较早地了解了这一点，并且能够将这一想法推到最后，那么这将使我们避免因业务流程专业知识不足以及微服务和整体集成的资源不一致而导致的错误。
- . , , . . , , , , . .
- . , . .
现在，在完成错误工作之后，我们可以放心地说：这项将近一年半开始的实验可以认为是成功的。现在，从一个实验的类别来看，向微服务架构过渡的项目正成为我们公司的关键IT战略之一。
将来，我们将返回该主题，并详细讨论技术堆栈，单个解决方案等等。我们已经积累了足够的材料和经验。