麻袋理财基于Docker的容器实践:互联网金融征信项目的微服务化之旅

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本文转载自中生代技术群的分享,本期是FinTech第一期,本文将分享麻袋理财基于Docker的容器实践,带领大家走进互联网金融征信项目的微服务化之旅。

FinTech第一期

征信是互联网金融的核心系统之一,在单体应用到服务化改造中,定义了API Gateway,Scheduler Service,Data Processing Service,Cache Service和Worker Service等服务,并实现了对基于Docker的微服务化。


本次分享的主题是《麻袋理财基于Docker的容器实践》——

             47dd52995b328b66410b4e4e6af9db4db3502771
征信要做的事情就是从内部外部获取数据,以此对用户的还款意愿进行甄别。
现在市场上也有很多第三方的征信公司,每家征信公司的数据来源各不相同,比如有些来自通信运营商,所以我们需要对接很多第三方的公司,而且各家公司的IT技术能力层次不齐,提供的接口也各不相同。

痛点:

  1. 对接N家公司;
  2. 使用不同接口;
  3. 各个接口的并发限制,超时时间各不相同

             2629a4fa123c3c190550e3d52d78dbc6b6c0dbb6

改造之前是一个典型的单体应用。
             75232d668bff24f240d165c03a924a41200c0061
改造过程中,我们希望把和第三方交互的模块抽取出来以便于单独扩展,提供API Gateway,对外提供统一的接口。
在方法与流程上,我们希望用自动的CI和CD,提高部署效率。从运维的角度来看,希望能够有更好的监控,及时发现问题,解决问题。
             93923c08ca25421f4553cf2beac8f53b5c73374f
我们遵循12 Factor App的原则,服务拆分的时候,使用单一职责。代码和配置进行分离,这样Dev/Test/Prod环境可以用同一套代码加不同配置。
这是改造结果,后面我会一一叙述。
             8116b8d67a94a73406f32376bce57cfae6ba7aa0

后面讲一下Docker的一些细节:

             36658572b6c769737eeeba37b5620d1bbd2b1565

目前Docker版本已经到1.12了,我们也已经升级到了1.11版本,原则就是保持在上一个稳定版本。
             f81cab86a5eaa881033c136fffb052cce402ff85
我们有使用一些基础镜像,包含一些基础的组件。

             a7681554cd353a4fdbed11fd748c57bc801de3af

             34fca486c39c3f0bd02166b3340eb2552939c326

我们的系统大部分使用Java开发,因此有Maven的基础构建镜像,JDK镜像等。
             61d6dac62fc681d58eea2dd3a45e37779804bab6
镜像仓库用的是VMware中国团队开发的Harbor,也是一个开源项目。
             16a03b76ccef1313aa62973baa6759d7cc80c79e
存储是一个高级话题,也包括如何优化Docker file,减少layer。

             401f66f518c163adbf3ab5617365e2130b4f52e6

             266b773ea77ff6d46b6b45c88ffd0f84de6e5e0a

这是几种存储驱动的比较。
             496a38b2efc096775f43175d6a3d8c3adfc0abc7
代码仓库我们目前用gitlab,遵循git-flow。目前每个项目有三个分支:dev,uat和master。每次代码提交都会触发Maven build和test,跑一些自动化测试脚本,结果会反馈到gitlab上。CI跑完之后,通过merge request的方式合并到uat分支,然后由测试和业务同事进行验证。测试完成后再通过merge request合并到master分支,然后进行产线部署,一般走灰度发布的流程。所有发布的流程都是用Jenkins实现
             936b0552cfca5332c9b55ebfa4003bae1f53bc72
我们会使用Docker compose来部署一组相关服务,参数通过不同文件来指定。
             2dbb457b961cedda4f1767e9a1d90666a35cdcf5
集群管理使用Swarm+Shipyard。
             3581e23ad35348e47f303219df4e6c4eb39eae11
日志监控用ELK,还有就是用filebeat把日志同步到某个目录,方便开发排错。
             cf07a8a0021bd28ffabfbbc3604dce34297d1f67
目前 Docker监控以cAdvisor为主。
             0cd9bff324edf4779a7f790db6a68d6962fc64d4
这是最后的部署架构图。
             e5d00cbe86087b741cd3cd14ac0838bbc2d5865a
总结
  1. 每个worker和一个第三方渠道打交道;
  2. 每个可以独立跑的项目用Docker进行封装;
  3. 用gitlab+Jenkins+Docker实现自动化CI/CD
Q&A
Q1: 王老师,请问你们如何解决合并分支时代码冲突的问题呢?尤其在涉及到多个feature分支以及个人分支的情况下。另外经常也会有已合并到dev分支上的feature需要撤销,这个怎么处理会比较好呢?
A1:代码冲突只能人工解决,另外一个微服务化的优势是,不同功能会放在不同项目中。

Q2: 目前麻袋整合了多少外部征信数据,后期的征信数据再加工和标准化做到什么程度了?
A2:我们正在梳理自己的征信领域模型。

Q3: 征信信息是实时查询吗?
A3:大部分是,但是有部分数据第三方提供的是异步接口;另外一个问题是第三方的IT水平也一般,不能保证7*24小时可用,再加上网络的问题,也会经常超时,所以要做好保护。

Q4: 调用外部征信渠道是一个微服务?还是按渠道分成不同的微服务?
A4:按渠道拆分为不同的服务,可以根据第三方的能力动态部署多个instance。

Q5: Docker打通了三层网络?
A5:我们现在没有用overlay network,因为不需要做隔离。

Q6: 单体到容器微服务化,相同研发人员产能究竟提升了多少,有无度量数据?
A6:首先是模块化能够带来很多好处,当然系统的复杂性也会增加,所以要先根据业务场景进行分析。数据没有度量。

Q7: 不同征信渠道作为一个worker单独部署,渠道多的时候,起很多Docker也是很占资源,做成一个微服务,并发去掉用呢?
A7:Docker占用资源还好了,主要是访问第三方需要不同线程池,不让对方响应比较慢,会把线程都占用掉。

Q8: 对这种大额低频的应用上Docker的意义在哪?主要是部署和运维层面?
A8:征信是一个高频应用(因为审批需要调用),也会不断接入新的第三方渠道,所以这样拆分之后,就可以做到不停机加渠道及升级不同渠道。

Q9: 关于问题四,接着请教[抱拳]理财和分期不同于秒杀场景,需要先注册,然后提订单,通常在同一时间并发应该没那么高,按渠道做那么多Docker实例必要性?

A9:这里拆分的原因还是因为要对接不同第三方渠道,第三方渠道提供不同接口,我们希望能够用一个模型来进行屏蔽这种差异性。


作者简介
王天青,麻袋理财首席架构师,曾就职于EMC中国研究院,对OpenStack,Cloud Foundry及Docker有较深研究。2015年加入麻袋理财,负责整个基础架构的演进。

本文转载自微信公众号 中生代技术 freshmanTechnology
目录
相关文章
|
5天前
|
NoSQL 关系型数据库 Redis
mall在linux环境下的部署(基于Docker容器),Docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongo
mall在linux环境下的部署(基于Docker容器),docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongodb、minio详细教程,拉取镜像、运行容器
mall在linux环境下的部署(基于Docker容器),Docker安装mysql、redis、nginx、rabbitmq、elasticsearch、logstash、kibana、mongo
|
5天前
|
应用服务中间件 nginx Docker
Docker同一台宿主机容器通信-通过容器名称互联
本文详细介绍了如何通过容器名称实现同一宿主机上容器间的互联,并提供了实战案例。首先,文章解释了容器间通过自定义名称访问的原理,随后演示了创建并连接Tomcat与Nginx容器的具体步骤。此外,还讨论了配置中可能出现的问题及解决方案,包括避免硬编码IP地址和使用自定义容器别名来增强系统的灵活性与可维护性。通过这些实践,展示了如何高效地配置容器间通信,确保服务稳定可靠。
14 1
Docker同一台宿主机容器通信-通过容器名称互联
|
2天前
|
设计模式 API 持续交付
深入浅出:微服务架构的设计与实践
在软件开发的世界中,微服务架构如同一场革命,它改变了我们构建、部署和管理应用的方式。本文将带你一探微服务的奥秘,从基础概念到实际案例分析,再到设计模式和常见问题解答,我们一步步深入理解微服务架构的设计哲学和实践要点。无论你是初学者还是有经验的开发者,这篇文章都将为你打开一扇了解和应用微服务的大门。
|
2天前
|
监控 Cloud Native 持续交付
云原生时代的微服务架构实践
【9月更文挑战第5天】随着云计算技术的飞速发展,云原生已成为现代软件开发的重要趋势。本文将深入探讨在云原生环境下,如何有效实施微服务架构,包括服务拆分、容器化部署、持续集成与交付等关键环节。通过具体案例,我们将展示如何在云平台上构建弹性、可扩展的微服务应用,并讨论在此过程中可能遇到的挑战及解决策略。
|
1天前
|
监控 Cloud Native 安全
云原生时代的微服务架构实践
【9月更文挑战第6天】在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性成为企业架构升级的首选。本文将通过浅显易懂的语言和生动的比喻,带你一探微服务架构的世界,从理论到实践,逐步揭示如何利用云原生技术构建高效、可靠的微服务系统,同时穿插代码示例,为有志于云原生领域发展的技术人员提供一份实操指南。
15 2
|
3天前
|
Cloud Native 持续交付 Docker
云原生技术实践:Docker容器化部署教程
【9月更文挑战第4天】本文将引导你了解如何利用Docker这一云原生技术的核心工具,实现应用的容器化部署。文章不仅提供了详细的步骤和代码示例,还深入探讨了云原生技术背后的哲学,帮助你理解为何容器化在现代软件开发中变得如此重要,并指导你如何在实际操作中运用这些知识。
|
3天前
|
消息中间件 监控 API
深入浅出微服务架构:从理论到实践
在软件开发领域,“微服务”这一概念已如日中天,它改变了我们构建、部署和扩展应用的方式。本文将带你走进微服务的世界,不仅探讨其核心理念,还将通过实际案例,展示如何将一个传统单体应用拆分为微服务架构。我们将一步步分析微服务的优势与挑战,并讨论如何在现实世界中实现和维护微服务架构,让你对微服务有一个全面而深入的理解。
|
2天前
|
运维 Cloud Native 持续交付
云原生时代下的微服务架构实践
在数字化转型的浪潮中,云原生技术以其高效、灵活的特性成为企业IT架构升级的首选。本文将通过深入浅出的方式,探讨云原生环境下微服务架构的设计原则、关键技术及实施策略,旨在为读者提供一条清晰的技术路线图,帮助理解和掌握在云平台上构建和管理微服务的实用方法。
|
3天前
|
Kubernetes Cloud Native Docker
云原生技术:容器化与微服务架构的融合之道
【9月更文挑战第4天】在数字化时代的浪潮下,企业追求敏捷、高效、可扩展的IT架构成为共识。云原生技术作为现代软件部署的黄金标准,其核心理念在于推动应用的快速迭代与无缝迁移。本文将深入探讨云原生技术的精髓——容器化与微服务架构如何相互促进,共同构建起适应云计算环境的应用生态系统。我们将通过实际案例,揭示如何在云平台上利用这些技术实现服务的解耦、弹性伸缩及自动化管理,进而提升企业的竞争力。
|
2天前
|
Java 数据库 微服务
深入浅出:微服务架构的设计与实践
在数字化时代的浪潮中,传统的单体应用逐渐显得笨重不堪。微服务架构以其灵活性、可扩展性成为现代软件开发的新宠。本文从基础概念出发,逐步深入探讨如何设计并实现一个高效的微服务系统,同时分享实战经验,帮助读者规避常见陷阱。