银行实施Microservices的三大挑战
在当前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方法是否适合您，将取决于您要处理什么问题。