我们最近写了有关IT架构师如何工作的文章，现在我们将告诉您有关我们其中一种情况的详细信息并显示系统方案。在这个项目中，我们帮助以微服务RBS取代了“盒式”银行应用程序，同时建立了每周平均一次的快速发布版本。
: , , -. NDA – , , , -.
«»
在中小型公司中，需要现成的IT解决方案，可以对其进行定制并使用自己的徽标发布。缺点-应用程序的功能“开箱即用”是有限的，并且更新通常必须长时间进行，并且只能通过供应商进行。
我们的一位客户使用了这种“盒式”远程银行服务（RBS）系统。网上银行是一个单一的应用程序，具有很少的功能集。
为了不逊色于竞争对手，该银行不得不不断引入改进和新功能。但是，即使只是简单地移动应用程序中的按钮，也必须与供应商联系。平均每个季度发布一次更新。
因此，由于许多限制，很难开发产品：
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
结果，该银行决定逐步放弃这种“盒子”，而是开发自己的具有微服务架构的远程银行系统，以加速功能的开发并为用户提供便利和安全。
我们从哪里开始
在线银行的创建始于顶层架构的设计，雇用开发人员并连接我们的专业团队。同时，必须依靠将来的扩展来安放该架构。
最初，我们的后端开发团队从事某些基本功能的实施：例如，汇款。但是，我们拥有与在线银行合作的丰富经验，此时我们的一个项目进入了Markswebb的行业评级，因此我们为银行提供了建筑设计方面的帮助-并获得了开绿灯。
建筑
我们决定与产品负责人一起使用Spring Cloud，它提供实现微服务架构所需的所有必要功能：这是服务发现-Eureka，Api Gateway-Zuul，Config服务器等等。之所以选择OpenShift作为Docker映像的容器系统，是因为该工具的银行基础设施得到了完善。
我们还分析了旧“盒子”的哪些功能会使用户的工作复杂化。主要缺点之一是系统通过数据总线同步工作，并且每个用户操作都导致对总线的访问。由于负载重，总线经常出现故障，整个应用程序停止工作。此外，与许多旧的银行产品一样，旧的资产已经积累起来，即以旧的沉重的CORE ABS形式出现的“遗留物”，这将很困难且昂贵。
我们提出了许多改进措施：
- 版本控制
以前，“盒子”仅支持一个版本，但是在新的在线银行中，我们提出了一种新的体系结构，该体系结构使我们可以同时支持多个不同版本，并在必要时替换它们。
版本控制方案如下：如果服务中的次要版本已更改，则将自动重建和部署服务，以替换过时的版本。如果我们放置主版本，则将部署具有新版本的服务的新副本。因此，通过更改服务API来开发新功能不会影响移动应用程序，同时会减少测试时间。如果用户没有机会进行更新，则这样的系统甚至可以为移动应用程序的过时版本提供支持。
- 异步性
我们已经实现了一个库，该库可用于需要异步工作的服务中。该库实现了异步任务的执行，适合在任意数量的服务副本上使用，并且它们不会相互干扰。不同副本之间的同步是使用Kafka消息队列完成的。
该解决方案有助于提高应用程序的稳定性。现在，移动应用程序独立于总线，我们在服务中复制用户所需的数据，并在可以访问银行总线时在后台更新它们。所有用户操作均已排队等待执行，一旦准备就绪，就会收到有关结果的PUSH通知。
- 快取
为了加快应用程序速度并减少内部银行资源的负载，已组织使用Redis进行数据缓存。缓存是KeyDB，它显示出良好的结果，并且与使用Redis的许多系统兼容。数据不是在用户请求之后而是在用户数据发生更改时进行缓存，从而可以独立于内部银行系统进行访问。
系统发生了什么变化
如上所述，在旧的在线银行中，后端是在整体架构中实现的，应用程序部署在单独的计算机上。随着负载的增加，必须部署新服务器。服务器崩溃时，某些用户无法使用移动应用程序。
新解决方案使用微服务体系结构，该体系结构使您可以部署特定功能所需的服务副本。我们添加了基于KeyDB的数据缓存，不仅可以提高信息检索的速度，还可以减少数据库的负载。
让我们看一个在新架构中获取用户帐户数据的示例。来自移动应用程序的用户请求通过平衡器到达网关，该网关了解将请求发送到哪些服务。接下来，我们进入帐户服务API。该服务首先检查缓存中是否有实际的用户数据。如果成功，它将返回数据，否则将请求发送到中间帐户服务。
在各种情况下都可能会更新服务中的数据。例如，根据用户的直接请求，服务将创建一个异步运行的数据更新任务，并更新从ESB接收的数据。该服务还从消息队列接收消息并对消息做出响应。例如，服务接收有关用户登录到应用程序的消息，并立即更新帐户数据，从其他服务接收有关帐户交易的数据，并更新其数据。因此，用户始终可以在其帐户上看到最新数据。
其中最重要的更改如下：
- 伸缩灵活性
为了提高系统的容错能力，服务分布在不同的服务器上。如果其中之一跌落，则可以使系统保持工作状态。为了及时应对非标准情况，我们实施了监控系统，必要时有助于扩大服务规模。我们连接了DevOps，以从头开始在客户端服务器上配置CI / CD，为将来在多台服务器上的应用程序建立了部署和支持流程。
- 由于版本控制而加速发布
以前，在更新移动版本时，一些用户已经应用了新版本，而其他用户则没有，但是后者的数量很少。在开发新的RBS时，我们实现了版本控制和发布版本的功能，而不会冒很大一部分客户无法使用该应用程序的风险。现在，当在新版本中实现单独的功能时，我们不会破坏旧版本，这意味着无需降级。这有助于将发布频率提高至少15倍-现在，发布平均每周发布一次。后端团队和移动团队可以同时独立地开发新功能。
加起来
在此示例中，我们讨论了为银行设计微服务体系结构，该体系结构替代了“盒装”整体解决方案。一个分布式团队负责该项目，其中包括内部开发人员和外包商。
在开发在线银行时，我们尝试在新应用程序中实现与盒装应用程序相同的功能范围，并逐步进行开发。
为了防止客户流失，必须建立应用程序的无故障运行，而不会出现故障和停机，并定期发布发行版和更新。这要归功于体系结构的改进。特别是，在减少数据库负载之后，我们获得了应用程序的恒定可用性，并且由于版本控制，我们减少了测试时间，确保了每周进行一次功能独立性和发行版本的可能性。
该应用程序的体系结构基于银行内部团队使用的产品和开发工具的进一步增长，因此产品所有者可以独立地对RBS进行任何改进。积极开发Alpha版本的期限约为一年，而又过了3个月，所有用户都发布了Beta版本。
我们希望所描述的工作方案在创建其他金融科技产品时会有所帮助。
感谢您的关注！