用于大型应用程序的系统架构和堆栈

Question

我有两个关于银行应用和类似“高风险”应用中使用的最佳实践和技术的问题。

假设我们正在尝试构建一个银行应用程序，客户可以在该应用程序上使用他或她的凭据注册一个帐户并进行转账和收款。就像每个普通银行应用程序一样构建，具有身份验证机制、PUSH TAN 和其他转账前的验证方法、会话登录（在给定的不活动时间段后到期，导致自动注销和指纹身份验证等）...

问题：

使用哪些系统级架构模式（高级设计）作为此类应用程序的基础？

哪些（堆栈）编程语言、数据库查询语言和 API 通常用于此类高风险应用程序，例如银行应用程序（可能是 Python 和 Django、MySQL、Cassandra 等语言和固件）？< /p>

我非常感谢每一个答案，所以不要犹豫，把你知道的都扔进去。

Answer 1

以下是我对此的看法：

• 一般而言，高风险系统（银行应用、交易所）应在安全性、可用性、可靠性和正确性方面遵循严格的要求。如果不仔细考虑其中一项功能，可能会发生不好的事情（人们会赔钱）。与其他类型的应用相比，这通常会导致更高的成本。
• 在架构方面，如果你想顺应当前的趋势，你可以使用微服务。例如 Monzo 使用基于微服务的方法来运行他们的后端（this 不错的演示文稿详细介绍了）。这绝对是构建低延迟可扩展后端系统（即使对于高风险应用程序）的新方法。我认为这种方法的一个缺点（我可能是错的）是缺乏成熟度（与经典的客户端-服务器模型相比）以及您始终需要了解所涉及的开源技术的最新情况，因为它们在不断变化。大公司都有专门的团队来贡献并及时了解开源技术。
• 您始终可以采用客户端-服务器架构，其中后端只是一组处理请求并与数据库通信的节点。这可能更容易开始，但可能更难发展。选择架构完全取决于您为系统规划的开发策略。任何方法都有利有弊。
• 在技术栈方面，我会选择成熟的语言/框架，比如 Angular、Java、C#、Spring Boot。这样您就可以更轻松地找到帮助您的开发者，同时还可以找到行业多年来建立的生态系统。
• 在数据库方面，您可以使用关系解决方案（MySQL、SQL Server）并使用事务来提供原子更新（例如，帐户余额）。就延迟/吞吐量而言，这可能会在某些时候影响整体性能。 No-SQL 方法可能会提高速度，但也可能带来数据重复以及在选择正确数据模型方面的一些挑战。

如您所见，处处都有权衡。这仅取决于您设置的初始策略，因此您可以避免未来发生重大变化。