11月22日至23日，面向.NET爱好者的下一次DotNext 2018会议在莫斯科举行。 我的名字叫Maxim Smirnov，我是Alfa-Bank的.NET能力中心的负责人，想向您介绍在DotNext旁进行的一次采访的文本版本。
关于我们银行的生活和冒险，关于与Java共存和实现问题的建议-正在削减。
一般来说，.NET在Alpha中有多少，为什么我们需要它
最近，在使用.NET方面，我们已经有了显着的发展。 如果大约5年前Alpha的子公司不多（主要是公司申请，向公司业务贷款，投资等），那么大约有16至20人可以应付这样的负担。 现在，该银行正在积极发展中型公司业务部门，这已成为信贷体系发展的良好动力。
我们面临着一个选择-用Java重写所有这些，这在历史上一直是我们的强项，并且仍然在零售中占主导地位，或者继续在.NET上开发一切，为此，我们将不得不雇用一堆捐助者并走到最前面与Java中的微服务架构相同的技术。
当然，这样的举动立即受到威胁，因为[使用新技术的风险大约为 编]。 但是我们能够承担这些风险，我们向同事证明，.NET可以在Java很好的相同群集和基础结构解决方案上充分工作。 在这里，我指的是我们所谓的“统一战线”集群Apache Mesos-马拉松。 然后，我们开始做出前线决策，包括决策的中间部分。 前端与Java中的前端相同，中间部分位于Java中的某个地方，.NET中的某个地方。
我们走了-5年前，最多有20个人使用.NET，如今任务如此之多，以至于有75个勇敢的家伙。而且我们还在继续扩展-现在我们正在寻找一名
架构师和更多的
开发人员 。 尽管Java仍然是总数的一半，但仍然是一半到一半，因为它稳定地主导着零售和大众企业。 当然，在.NET方面，我们已经掌握了公司和区域平均水平的框架，此外还拥有电子渠道。
检查-证明-实施
为了使某事能够持续进行，有必要在银行的流程中实施此事。 要正常实施，您需要向所有负责人员证明，这不会破坏当前的事务状态，并且实施会带来很多好处。
最困难的是基础架构。 他们有一个严格的具体要求-所有这些都将在docker中展开并在Linux中正常工作。 需要指出的是，当时还没有.NET Core 2.0，只有第一个版本，在第二个版本中并没有发布所有的优点，总的来说，事实证明我们自己并不确切知道哪个水下版本我们可能会遇到冰山，但他们说我们会尽一切努力。 我们能够通过启动首批试点向企业证明这一点-Alfa-Credit，这是一种在线贷款，发行付款等应用程序。
然后，支持者必须证明该想法的可行性。 他们需要解释说，他们自己并不需要知道.NET来陪我们的容器（由于某些原因，他们肯定会相反）。 他们向他们证明了不会出现性能问题，我是第一个在集群上收集所有这些信息的人-我们部署了容器，从中删除了一堆指标，观察它装载了多少CPU，并将所有这些与Java进行了比较。 我们只是在容器中添加了Java代码，该容器向零售客户提供了帮助。 好吧，出于实验的纯正性，我们在.NET上提供了完全相同的服务，因此我们可以在性能，响应速度和内存负载方面进行诚实地比较。 结果，我为此编写了压力测试-一切对我们都有效，目前有6个团队以这种模式工作。
现在，我们逐渐摆脱了传统-我们将其包装在服务中，并在功能上将其重写为微服务。
.NET Core VS .NET Framework
我将再次注意我们实现了.NET Core。 因此，从某种意义上说，.NET框架中存在一些很酷的东西，但是在.NET Core中却没有，仍然没有。 例如，SOAP服务。
试想一下。 您是一家银行，您拥有一个消耗另一个系统的系统。 而且她习惯了SOAP来使用，而您却没有。 一般而言。 我们没有找到带有SOAP和类似内容的WCF服务的单个常规实现。 也许他们看上去很糟，一切皆有可能。 因此，我不得不放弃并在旧的.NET Framework上编写层。
第二组是REST API。 实施新服务的地方没有问题。 强迫旧服务使用REST API而不是SOAP是另一回事；我将不得不重写所有其他依赖系统。 再次，层，补丁，拐杖。
并与队列进行通信。 我们正在Alpha（一种用于消息队列的典型企业总线）中积极使用IBM MQ。 存在.NET Framework下的客户端，该客户端来自IBM。 但是他们没有.NET Core的客户端。 而且，据我们所知，这是没有计划的。 在开放的AMQP协议上只有一个实现，我们尝试在其帮助下与队列进行通信，但是也存在许多问题。 解决办法？ 是的，再说几遍。
总的来说，我们进行了一次迭代，以期使所有这些东西都能通过AMQP协议正常工作，而不是变得愚蠢。 但是，IBM的人退订了我们，他们说，对不起，伙计们，但是他为我们弃用了，他是如此。 并且出于某些原因，他们只会使用专有协议。 总的来说，我们现在坐下来思考如何重做所有这些。 很可能，我们将编写客户端而不是IBM客户端，这是开源的。
Front，.NET和NodeJS
在大多数情况下，我们将React JS用作前端；它通常与节点一起使用。 刚开始时，我们有许多旧的MVC项目。 在那儿，我必须向前转发，以便通过ReactJS.NET进行服务器端渲染是正常的。
现在我们避免了这种情况，我们决定将果蝇与炸肉排分开，最后结果是该节点有一个独立的前端，并且NodeJS在Web应用程序的rest api上使用了我们的服务。 而且，实际上，仅此而已。 在.NET上，我们已经在实现中间层。 而且，正如我在.NET和Angular中观察到的那样，我们之间并没有建立紧密的联系，因为我们努力开发人的专业化知识，因此我们根本无法将它们直接分开。
如果您知道纯净的前端，那么可以安全地与java-team一起为它编写前端。 这很方便，因此您可以在团队之间流动。 而且，如果您知道完整的堆栈，则可以制作端到端的应用程序。 以及.NET的后端，中间的前端。 在这里，我们有一个统一的技术标准。
手机整合
我们没有太多。 只要有，它就是在Web api上使用我们的服务。 我们自己没有在.NET上编写移动应用程序，甚至没有尝试。 本地的仍然更好。 如果您可以立即采用并编写本机语言，则最好立即采用并编写本机。 是的，有一些有用的功能，例如Microsoft的Xamarin，但是当您需要快速通用的入门时才有意义。 但是，如果对于每个平台的应用程序便利性和性能存在疑问，您仍然会继续，并且通常会编写本机代码。 我们最初有本地的。
关于对新的抵抗
当您拥有大型公司（甚至只有几个团队）时，您总是会对新工具的引入感到不满意。 通常，这总是正常的。 看到这些的艺术家，仅此而已。
当您从上方介绍不太受欢迎的内容或开发人员不喜欢的内容时，人们总是会找到一堆破坏流程的方法，甚至在流程中显示您是白痴开始的。 就像当我们引入StyleCop for .NET一样。 但是随着时间的流逝，每个人无论如何都接受它，现在正在积极使用它。 一个简单的论点有所帮助-StyleCop中的设置很常见。 结果是美观的，每个人的代码都差不多。 尽管我对此有所怀疑，但仍有一些开发人员在磨牙。 毕竟，每个人都有自己的标准，每个人都有自己对代码美的理解，他们自己的任何编辑器和技巧。
类似的事情在硅谷系列中被击败。 在那里，这些人就应使用的选项卡或空格进行了辩论。 就个人而言，我并不在乎，但是，正如实践所示，对于某些人来说，这可能是霍利瓦尔的开始。
当然，如果您将所有内容都以可视方式编写，则通常会消除此问题。
这里有人在Visual Studio中编写代码，而其他人则不在。 当我们切换到群集时，事实证明有许多技术在Windows下不起作用。 例如，Ansible。 Windows上有一个客户端部分，但是不能再引发服务器部分。 因此，要么在Linux上安装虚拟机，要么在Linux服务器上执行所有操作。
总的来说，我们这样生活。 如果您对银行中的.NET和原则上的.NET有任何疑问-编写，我将很乐意回答。