在当前API的趋势下,银行开始将Microservices作为API框架来开发实施,有些银行甚至将其视为许多问题的对策。
例如性能,复原能力,可伸缩性等,甚至有人声称核心银行的未来也将落在Microservices。
Microservices无疑具有解决许多问题的能力,但它有其局限性。这里,我们列出了在银行实施Microservices的三个主要挑战。
1. 交易管理
2. 服务绩效
3. 应用程序分区
交易管理:
分布式计算中的交易完整性始终是一个问题。
由于Microservices是分布式计算的技术,因此在不同的Microservices或不同的服务器中进行交易时,将很难管理这些交易的整体完整性。
举例,您可以从一个帐户中取款,但无法将资金存入另一个账户。
针对这个问题,有几种解决方案,例如分布式交易处理协调器,但它的性能很慢。
另一种解决方案是采用交易订阅体系结构,但它可能会有数据不一致的窗口。
我们的建议是避免分布式交易。因此,您可以将所有交易纳入一项服务的方式对Microservices进行分区。
服务性能:
尽管Microservices可以将负载分配到不同的服务器,但是它不能保证每个单独调用的性能。
这是因为每个单独的调用都可能触发许多Microservices,所有Microservices都通过网络进行传达,并且网络的效率性、延时性和可靠性永远无法保证。
应用程序分区:
传统应用程序的体系结构方法是Monolithic。软件架构师需要采用一种崭新的Microservices架构方法。
他们必须将单个应用程序分解为许多小型服务,每个服务都可以独立运行和管理。
应用程序分区是对每个应用程序逐个案例进行练习。
除了技术知识,设计人员还需要相关行业领域的知识。我们认为行业领域知识比技术知识更为重要。
举例,如果您要开发基于Microservices的订单管理系统(OMS),您需要了解证券交易的生命周期。这样您才可以更好地定义系统边界。
我们看到银行业正在大肆宣传使用Microservices。但这不是灵丹妙药,某些情况完全不适合使用Microservices。
我们曾经看到一个从以数据库为中心的应用程序迁移到Microservices体系结构的案例 (存储过程中有超过10万行代码)。毋庸置疑,该项目以失败告终。
简而言之,Monolithic方法具有许多优点。而Microservices方法是否适合您,将取决于您要处理什么问题。
感谢您阅读这篇文章。想了解更多关于Microservices在银行中的运用,请联系我们。