基于SpringBoot微服务架构的城市一卡通手机充值支撑系统研究

作者/ 温晓丽 苏浩伟 陈欢 邹大毕 广州羊城通有限公司(广东 广州 510080)

摘要：基于微服务架构而构建的应用系统是将复杂的大系统分解成了一系列小的单独的子服务系统，这些子服务系统可以单独部署发布，也可以组合成一个应用发布。伴随着移动互联网应用的快速发展，相应的服务系统更新迭代频繁，采用微服务架构之后的系统可以很好地适应移动互联网这种需求不断迭代更新的应用场景。城市一卡通手机充值系统是城市一卡通公司在移动互联网领域的应用服务系统，同样地面临着业务不断快速迭代更新的需求，基于此，进行城市一卡通手机充值支撑系统的构建过程中采用了基于SpringBoot微服务架构的研究是必要和有参考意义的。

引言

随着时代的发展，在信息系统建设方面，传统IT架构面临着以下一些问题：

1)使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难。在系统更新时，往往牵一发而动全身，稍有不慎就可能带来大的损失。

2)随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线，而传统IT架构在系统快速迭代更新方面难度较大。

3)随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式，此时再生搬硬套传统IT架构往往会产生适得其反的效果。

4)移动互联网相关技术快速发展，云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟，主要为如下几方面：互联网/内联网/网络更加成熟，轻量级运行时技术的出现(node.js等)，新的方法与工具(Agile、DevOps、TDD、CI及XP)，新的轻量级协议(RESTful API接口和轻量级消息机制)，简化的基础设施，操作系统虚拟化(hypervisors)、容器化(Docker)、基础设施即服务(IaaS)、工作负载虚拟化(Kubernetes、Spark)等;服务平台化(PaaS)，云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务，新的可替代数据持久化模型：如NoSQL、MapReduce、BASE、CQRS等，标准化代码管理等。

这一切都催生了新的架构设计风格，即微服务架构的出现。

1 微服务架构概述

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。

微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其它服务(开源或闭源的)集成，只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。

1.1 与整体架构的比较

整体架构把所有功能都放到一个进程中，如图1所示，其中每个形状块代表一个功能;而微服务架构会将不同的功能放置到分离的多个服务进程中，如图2所示。

在系统服务能力需要扩展时，采用整体架构的系统只能复制整个系统到多个服务器上，如图3所示;而采用微服务架构的系统则仅根据不同服务的服务负载能力需求来决定复制到多少个服务器上，如图4所示。

1.2 微服务架构的优点

1)每个服务都比较简单，只关注于一个业务功能;

2)微服务架构方式是松耦合的，可以提供更高的灵活性;

3)微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题;

4)每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度;

5)微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

1.3 微服务架构的缺点

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性，主要约束性体现在如下几个方面：

1)运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。

2)代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

3)分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若