WebTIS的微服务架构

微服务架构是一门以小型独立的代码单元(称为微服务)构建软件解决方案的学科。 它实质上是面向服务的体系结构。 微服务被组织成一个独立的,独立的应用程序系统,每个应用程序都负有单一责任,并且所提供的业务目标不超过一个。 每个微服务都是一个具有自己数据源的独立进程,该数据源经过编程可通过网络与其他服务通信。

使用它的好处

这样的基础自然会在产品生命周期的许多领域中建立优势。 例如,在管理中,可以将产生微服务的开发人员团队有效地缩小到一个人,从而允许他们选择编程语言,利用最新技术,重用库和最佳实践。 在经验丰富的整体式结构中,这可能已经是一个问题,它希望进行固体重构。 此外,了解单个微服务所需的学习曲线适中,也许等于了解所讨论的业务目标。

当然,任何数量的可独立部署的应用程序都需要对持续集成和持续部署工具以及快速的基础架构供应进行一定的投资。 但是,它们的存在确实提供了更多的机会,可以从常规版本中获得好处,而冗长的自动化测试所需要的时间却很少,停机时间几乎为零,对整个系统的风险也最小。 更换一个有故障的微服务不会立即导致整个产品崩溃。 自动化的监视和警报也将对系统的良好运行状况和稳定性起关键作用。

扩展微服务非常有意义,因为它们可以按瓶颈分组,可以是CPU,内存,网络或文件系统,还可以部署到适当的服务器组,甚至是单独的实例,也许所有这些瓶颈都组合在一起了。 与单片结构相比,当借助微服务可以有效降低产品运行成本时,这可能成为决定性因素。

WebTIS的微服务

在铁路世界中,WebTIS是一种在线运行的票务发行系统。 这是一个复杂的系统,包含许多活动部件,行程计划器,预订系统,支付系统,帐户管理,财务报告以及与许多行业系统的集成。

那么,WebTIS作为一组微服务将是什么? 这正是过去12个月来我们在Assertis一直在问自己的问题。我们逐渐老化的单片应用程序正在逐步转换为微服务系统,方法是一个接一个地提取职责,创建微服务并与“老巨头”交谈。 ‘。

所有这些都会对系统的设计和运行产生影响。 微服务不是灵丹妙药,并且随着每个服务之间的通信的增加,现在有更多的故障场景需要考虑。 有人会说失败场景总是存在的,现在它们更加明确了。 无论哪种方式,结果都将是一个更强大的系统。

如果票证是由一个系统发行并由另一个系统履行的,那么如果这两个服务之间的通信中断,会发生什么? 您是否有看门狗来确保过程顺利进行?

有时,实施微服务时,您会感觉好像陷入了困境,因为发现了从未有过的问题。 但是,这是权衡的一部分。 该系统具有更高的可伸缩性和可维护性,可带来一些额外的开销。 这是一个小插图,可以帮助您了解主要组件。

未来发展

下一步是什么? 当世界上所有的遗留代码都已转移到微服务中并且它们都已进行了完美地扩展时,是否有可能进行更改? 当只需要自定义配置来运行业务时,代码会进行某种形式的全球化吗? 这些可能是在酒吧中进行激烈辩论的好问题,但是微服务架构似乎是迈向未来的坚实一步,我们应该为之做好准备,或者至少要意识到。

作者:Nikita Batalov