为什么说金融科技公司应该迁移到微服务架构？

在这篇文章中，我将介绍我对于一些微服务相关问题的看法。第一个问题是为什么金融科技公司应当把遗留的传统架构应用迁移到现代的架构风格上；其次，如何在这一范式迁移过程中重用现有的应用资产；最后是这种迁移将以何种方式解决这一领域中包括代码质量和重用性在内的一系列令人望而生畏的问题。

一个典型的金融科技公司往往都处于尽早走向市场的压力中，这种压力来源于股东和其他利益相关者。因而类似的公司在早期并不会给予应用架构足够的重视。他们往往采用单体架构建立应用程序。这一架构易于实现，但在增加功能时会形成紧密的依赖关系。这一领域法规、税收结构、许可证和资本要求的频繁变动也加剧了这种混乱状况。为了满足新的相关要求，已经有大量的时间和努力消耗在了重新修改已有应用上。而这经常会引入新的错误并打断现有的功能。在这一应对挑战的过程中，这些公司最终会创建出乱麻一般的代码，并由此导致代码质量的恶化，以及维护噩梦。对于难以适应变化的单体架构而言这种问题会更加严重。

单体架构

单体应用的架构是单层结构，用户接口和数据访问代码都集成在一个平台中。

这种架构的简单性使得最初构建和部署至生产环境的时间消耗非常少。相较于现代的 web 应用架构，这种架构会提供更高的性能（响应时间），因为在数据库和应用接口之间的层次很少。但即使这样，单体架构仍然缺少一些关键的特性，例如：

• 敏捷性和可维护性 - 程序单元和代码行数会随着功能的增加而增长。一切都集中在一个程序中。这同样会为业务功能的实现带来巨大的挑战，因为每次修改都必须对应用进行完整的测试。

• 可用性 - 单体应用程序有更高的风险。因为即使应用程序的一部分发生中断，它也可能会影响整个应用程序并可能导致应用程序崩溃。

• 可重用性 - 可重用性仅局限于同一层内和同一程序单元中的方法和函数重用。尽管原则上可以在单体应用程序中创建独立模块，但鲜有实现。

• 可扩展性 - 大多数金融科技公司都从一个细分产品起步，而这只会影响金融业务流程中的一个小环节。即使用户起初并不能快速适应，然而他们一旦开始从这种细分产品中获益，用户数就会逐渐增加。人们非常期望应用程序具有高度的可扩展性以及能够支持高并发使用，同时又不需与最初的用户吞吐量相妥协。

• 可测试性 - 由于不同程序单元之间存在着复杂的相互依赖性，即使一个微小的功能变化测试，在这种单体应用中都会是一个挑战。

微服务架构

微服务是一种以业务功能为中心的架构风格，而非基于 UI，中间件和数据库等技术因素。一个微服务就是一个独立的单元，代表一个模块端到端的功能。一个应用程序包含一个或多个模块。因此，一组微服务就代表了一个应用程序。该体系结构推荐为每个服务设置独立的数据库（基于业务逻辑）。

这种架构的一些主要优点是：

统一团队

它带来了团队组织范式的转变。每一个模块都有一组中间件和数据库开发者以及质量保证（QA）测试员负责端到端的功能开发、测试和服务交付。又因为团队成员会利用不同的技术为同一个模块工作，这种组织方式增强了团队凝聚力、主人翁意识和责任感。

敏捷性

微服务架构能够为构建和管理银行业和金融业应用提供更强的敏捷性。这些应用在本质上具有复杂的设计，需要持续的进化和扩容，能与多种外部和内部系统相集成以及达到多种层次的高安全要求。

维护

相较于维护一个包含了所有功能的大型单一应用，维护独立的微服务要容易得多。每个微服务在源代码库中都是独立开发和维护的。这种分离的架构允许以更快，更高效的方式实现对应用程序的功能更改。这是因为开发一个全新的微服务并不需要很长时间。单元测试和代码审阅也变得非常简单。这种方法最终有助于提高应用程序的质量并减少缺陷。

可用性

在大多数情况下，应用程序对于终端用户都是可用的。因为在单个微服务出现问题的情况下，可以卸载单独的服务，并且可以安装新版本，同时不会导致整个应用程序在维护时段内停机。

可重用性

可重用性有两个方面：

• 服务可重用性 -这是可能的，因为每个微服务设计目的是体现应用程序的一个功能。这为重用不同的功能模块提供了更高的灵活性。例如：证券的定价可以被开发为一个 Web 服务（模块 A，我们称之为 PriceService）。它将支持插入或更新证券最新价格的操作。价格可以 feed 的形式每日从诸如 Bloomberg 等市场信息来源获取。交易流程处理可以被开发为另一个 Web 服务（模块 B，我们称它为 TradeProcessingService）。为了处理已经投资于证券的基金的交易，它需要最新的价格数据。因此，TradeProcessingService 服务将在交易处理期间使用 PriceService。

• 代码可重用性 - 服务体系结构本质上消除了代码冗余。现有的遗留技术可以进行逻辑分割，并且每个逻辑单元都能转换为可重用的服务。这样，我们不仅可以提高代码质量，还可以重用我们现有的核心资产，并节省用现代语言重新编写它们所付出的巨大努力。因为基于同一种语言构建所有服务并非必要，所以微服务架构中的单个服务可以用适合他们的语言编写。这种架构的关键优势之一是互操作性，因为微服务是技术无关的。

可扩展性

与传统架构不同，微服务架构天然支持横向扩展，以满足并发用户和交易量的增加。现代微服务平台 - 例如基于 Spring 引导，Zuul 和 Eureka 组合的平台 - 支持以简单高效的方式水平扩展服务。

可测试性

可测试性会在更大程度上得到改善。行业标准指出，在有良好工程设计的应用程序中，测试占据了成本的 40％。如果软件架构师可以降低这个成本，那么回报就会很大。要使应用程序得以适当地测试，必须能够控制每个服务的内部状态和输入，然后观察其输出。基于微服务的体系结构支持这种方法。每个微服务都可以独立于其他部分进行完整的测试。这大大减少了全功能单体应用程序达到可测试状态的等待时间。在上面的例子中，TradeProcessingService 和 PriceService 服务都可以独立开发和测试。

构建微服务架构的成本

基于以上所有观点，我们能否假设微服务架构是未来的方向？事实上，两种架构各有所长。在决定采用这条道路之前，有几个因素需要考虑。其中一些是：

• 分析现有的复杂混乱的代码，从中分离出业务逻辑，并将他们构建成可重用的，有清晰、严格边界的微服务，完成这些任务的成本非常高昂。你需要一批对当前代码非常了解，并且具有不同技能专长的的开发者协助完成这一转换过程。

• 从某种意义上说，基于微服务的体系结构的维护比较简单，但它带来了额外的挑战，例如监视单个服务的正常运行时间，管理每个微服务的不同版本（包括运行时和源代码库）。

• 与基于微服务的体系结构相比，单体应用程序的故障排除相当容易，因为技术层的数量非常有限。现在，在新的架构体系中，服务集群遍布于不同的

• 因而我们需要构建一个集中的日志记录和审计平台来识别有问题的服务，然后对其进行故障排除。这为今天单体应用支持团队的工作方式带来了变化。

• 我们应该制定交付政策，定期提供不同版本的微服务。

• 我们需要应对个别服务故障导致整体微服务组所提供的功能失效的情况

• 与单体应用相比，微服务需要更多的硬件和计算资源。

未来之路

事实上，迁移到微服务牵涉到风险，努力和成本。但是，如果我们能制定正确的策略，那么从长远来看，应用程序的整体质量将会增加。这是无可否认的。如果没有架构的范式转变，无论我们投入多少资金改进单体应用的质量，投资回报率和收益率将非常小。为了消除这种迁移风险，公司可以考虑先用微服务架构完成新需求的开发，并逐渐将传统模块转变为基于微服务的体系结构。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/xWAaFjqf1wWgtucDoEssIQ