在这篇文章中,我将介绍我对于一些微服务相关问题的看法。第一个问题是为什么金融科技公司应当把遗留的传统架构应用迁移到现代的架构风格上;其次,如何在这一范式迁移过程中重用现有的应用资产;最后是这种迁移将以何种方式解决这一领域中包括代码质量和重用性在内的一系列令人望而生畏的问题。
一个典型的金融科技公司往往都处于尽早走向市场的压力中,这种压力来源于股东和其他利益相关者。因而类似的公司在早期并不会给予应用架构足够的重视。他们往往采用单体架构建立应用程序。这一架构易于实现,但在增加功能时会形成紧密的依赖关系。这一领域法规、税收结构、许可证和资本要求的频繁变动也加剧了这种混乱状况。为了满足新的相关要求,已经有大量的时间和努力消耗在了重新修改已有应用上。而这经常会引入新的错误并打断现有的功能。在这一应对挑战的过程中,这些公司最终会创建出乱麻一般的代码,并由此导致代码质量的恶化,以及维护噩梦。对于难以适应变化的单体架构而言这种问题会更加严重。
单体应用的架构是单层结构,用户接口和数据访问代码都集成在一个平台中。
这种架构的简单性使得最初构建和部署至生产环境的时间消耗非常少。相较于现代的web应用架构,这种架构会提供更高的性能(响应时间),因为在数据库和应用接口之间的层次很少。但即使这样,单体架构仍然缺少一些关键的特性,例如:
微服务是一种以业务功能为中心的架构风格,而非基于UI,中间件和数据库等技术因素。一个微服务就是一个独立的单元,代表一个模块端到端的功能。一个应用程序包含一个或多个模块。因此,一组微服务就代表了一个应用程序。该体系结构推荐为每个服务设置独立的数据库(基于业务逻辑)。
这种架构的一些主要优点是:
它带来了团队组织范式的转变。每一个模块都有一组中间件和数据库开发者以及质量保证(QA)测试员负责端到端的功能开发、测试和服务交付。又因为团队成员会利用不同的技术为同一个模块工作,这种组织方式增强了团队凝聚力、主人翁意识和责任感。
微服务架构能够为构建和管理银行业和金融业应用提供更强的敏捷性。这些应用在本质上具有复杂的设计,需要持续的进化和扩容,能与多种外部和内部系统相集成以及达到多种层次的高安全要求。
相较于维护一个包含了所有功能的大型单一应用,维护独立的微服务要容易得多。每个微服务在源代码库中都是独立开发和维护的。这种分离的架构允许以更快,更高效的方式实现对应用程序的功能更改。这是因为开发一个全新的微服务并不需要很长时间。单元测试和代码审阅也变得非常简单。这种方法最终有助于提高应用程序的质量并减少缺陷。
在大多数情况下,应用程序对于终端用户都是可用的。因为在单个微服务出现问题的情况下,可以卸载单独的服务,并且可以安装新版本,同时不会导致整个应用程序在维护时段内停机。
可重用性有两个方面:
与传统架构不同,微服务架构天然支持横向扩展,以满足并发用户和交易量的增加。现代微服务平台 - 例如基于Spring引导,Zuul和Eureka组合的平台 - 支持以简单高效的方式水平扩展服务。
可测试性会在更大程度上得到改善。行业标准指出,在有良好工程设计的应用程序中,测试占据了成本的40%。如果软件架构师可以降低这个成本,那么回报就会很大。要使应用程序得以适当地测试,必须能够控制每个服务的内部状态和输入,然后观察其输出。基于微服务的体系结构支持这种方法。每个微服务都可以独立于其他部分进行完整的测试。这大大减少了全功能单体应用程序达到可测试状态的等待时间。在上面的例子中,TradeProcessingService和PriceService服务都可以独立开发和测试。
基于以上所有观点,我们能否假设微服务架构是未来的方向?事实上,两种架构各有所长。在决定采用这条道路之前,有几个因素需要考虑。其中一些是:
事实上,迁移到微服务牵涉到风险,努力和成本。但是,如果我们能制定正确的策略,那么从长远来看,应用程序的整体质量将会增加。这是无可否认的。如果没有架构的范式转变,无论我们投入多少资金改进单体应用的质量,投资回报率和收益率将非常小。为了消除这种迁移风险,公司可以考虑先用微服务架构完成新需求的开发,并逐渐将传统模块转变为基于微服务的体系结构。
腾讯分布式微服务TSF围绕应用和微服务的PaaS平台,提供服务全生命周期管理能力和数据化运营支持,提供多维度应用、服务、机器的监控数据,助力服务性能优化;拥抱 Spring Cloud 开源社区技术更新和K8s容器化部署。