基于支付场景下的微服务改造与性能优化近年来微服务架构已经成为大规模分布式架构的主流技术，越来越多的公

文件名称: 基于支付场景下的微服务改造与性能优化

所属分类: 微服务

开发工具:

文件大小: 1mb

下载次数: 0

上传时间: 2019-06-30

提供者: longlo*******

下载 (1mb)

不能下载？报告错误

详细说明：近年来微服务架构已经成为大规模分布式架构的主流技术，越来越多的公司已经或开始转型为微服务架构。本系列不以某一种微服务框架的使用为主题，而是对整个微服务生态进行系统性的讲解，并结合工作中的大量实战案例，让读者读完即可实际上手应用。(1)对接业务层:主要是一些业务系统对接支付系统,包括电商业务、互金业务和一键支付三个限界上下文 (2)统一接入网关层:主要功能是对请求入口进行加解密、分流、限流和准入控制等。上下文电商业务互金业务一键支付运营服务统一接入层支撑服务加签、验签、分流、限流、准入控制等商户后台产品服务层短信服务收银台商户个人业务运营后台通知服务 PC收银台分账鉴权充值订单查询报表手机收银台担保代扣提现监控报醫数据后台业务服务层数据采焦交易服务支付服服务退款服务计费服务风控服务其础服务层网关资金处理平台支付网关鉴权对账清结算支付路由备付金会计图11-1 (3)产品服务层。收银台:包括两个限界上下文,分别是PC收银台和手机于银台。商户:包括四个限界上下文,分别是分账、鉴权、扣保和代扣。个人:包括两个限界上下文,分别是充值和提现 (4)业务服务层:包括五个限界上下文,分别是交易服务、支付服务、退款服务、计费服务和风控服务 (5)基础服务层。网关:包括三个限界上下文,分别是支付网关、鉴权和支付路由。资金处理半台:包括四个限界上下文一对账、清结算、备付金和会计。三、支付场景下微服务架构的详解与分析使用微服务的核心是业务,没有业务进行支撑的微服务是虚的”,但只有业务与微服务相结合的思想而没有微服务的架构体系也是无法将微服务落地的,所以本章重点介绍要做好微服务还需要完善哪些技术架构。下面我们将以一个实际工作中的案例为出发点,分析在中小公司中如何落地微服务。如图11-2 所示,左半部分是微服务的业务架构,右半部分是微服务的基础技术架构。网关层基础平台加验验分流/限流权限 Saas 数据分析服务两尸运营服务运维管控服务报备进件服务服务层 Paas 交易中心 Spring boot RabbitS消息限务配管管理中心分布式文件系统收单交易服务付款交易服务钱包交易服务分布式缓存分库分表中间件统一调度中心双活管控架构支付中心支付服努路由系统银行果道大散撼平台 Mock测试系统银行通道监控与切换通知中心资金清到中心数据迁移平台短信通知服务统一流水号计费服务账户服务结算服务支撑监控风控中心容量压测分布式调用链自研探针+ Zipkin 监控平台部署编译风控策略风控引擎风控处理 docker仓库灰厦发布系织小流量平台 ELK日志平台数据层 docker docker kubernetes DB 图11-2 3.1业务架构分析根据前面介绍的如何根据业务来划分领域可以看到,整个业务架构部分已经完成了领域的划分, 我们重点来看服务层。服务层是一个核心域里面包含了多个子域,每个子域都是按功能进行划分的,比如支付中心子域里面包括支付服务、路由系统和银行渠道等限界上下文,这些限界上下文是一个服务,还是一个系统呢?这就要结合康威定律来综合考量团队的规模,小公司创业初期研发人员少,可以将支付中心子域定义为限界上下文,里面包括三个独立模块,分别是支付服务模块、路由模块和银行渠道模块,待人员逐步増加到一定规模后,多个项∏组同时修改一个支付中心限界上下文会导致互相影响的时候,就需要将支付中心上升为一个业务领域,而将之前的三个独立模块拆分为独立系统,由不同的项目组分别接管,各自维护各自部署,如图11-3所示交易服务交易服务调用调用支付系统支付中心域支付模块路由模块道模块支付服务系统路由系统锓行渠道系统图11-3 可以看出左边是未拆分前的结构,交易服务想要调用支付模块就必须统一调用支付系统,然后才能调用攴付模块,而石边是经过拆分后的结构,这时交易服务可以直接调用攴付服务系统、路由系统和银行渠道系统中的任意一个,当然从业务流来讲肯定要先调用支付服务系统。而数据层是根据业务进行数据库的拆分,拆分原则与应用拆分相同,如图11-4所示。支付应用接口/URL调用路由应用支付数据库路由数据库图114 可以看到业务、应用和数据库三者一体,物理上与其他业务隔离,不同应用服务的数据库是不能直接访问的,只能通过服务调用进行访问。 3.2技术平台详解当我们将整个支付业务根据微服务理念做了合理划分之后,业务架构的各层次就逐步清晰起来, 而微服务架构的成功建设除了业务上面的划分,技术平台和运维体系的攴撑也是非常重要的,图 11-2的右半部分共分为三个层次,分别是统一平台业务层、微服务基础中间件层和自动化运维层 1)统一业务平台层这一层主要是通用的平台业务系统,包括数据分析服务、商户运营服务、运维管控服务和进件报备服务,它们无法根据业务被归类到某一业务系统中,只能作为支撑域存在,所以放到统一业务平台层供所有业务线共同使用 2)微服务基础中间件层微服务本身是一个生态,为了支撑微服务这个庞大的体系,必须有很多基础中间件进行辅助才能使微服务平稳地运行。卜面将根据笔者积累的实饯经验对图中一些重要的组件进行技术选型方面的介绍,另外图中有很多组件在本书其他章节进行了详绌介绍,这里就不再做说明。微服务框架 ∏前市面上非常流行 Spring boot- Spring cloud的微服务框架,这套框架确实是微服务的集大成者,涵盖的范围广,可以支持动态扩展和多种插件。但是作为公司的管埋者来说,并不能因为出了新的技术就立刻将公司核心业务用新的技术进行更替,这样在生产上所带来的风险将会非常大。比较合理的做法是,如果公司或部门是新成立的,还没有做技术框架的选型,又想在公司內部推广微服务的时候,尝试使用 Spring boot和 Spring cloud框架,可以节省出公司或部门的很多时间来攻关前端业务,而不需要将更多精力放在如何进行微服务的建设上来。目前很多互联网公司在生产过程中使用的微服务框架并不是 Spring boot和 Spring cloud,会使用如Dubo、gRPC、 Thrift等RPC框架进行服务治理,而公司内部自己研发出很多微服务的外围组件,比如APM监控系统、分库分表组件、统一配置中心、统一定时任务等。在这种情况下公司内部已经自建了比较完善的基础架构平台就没必要整体更换为 Spring boot和 Spring Cloud,否则代价极大,甚至会对公司的业务造成严重的后果。公司发展的策略一般都是以客户 (用户)稳定优先,但公司技术也需要更新,可以先尝试在公司边缘业务中使用,达到认可后逐步推广,循环渐进笔者在进行微服务改造的过程中实际上是基于原有的 Dubbo做的改进,将 Dubao和 Spring Boot相结合形成服务治理框架。消息服务我们在谈技术选型的时候,不能脱离业务空谈选型,每种消息中间件必定有其优点和不足,我们可以根据自身的场景择优选择,下面笔者结合自己使用的两种类型的MQ简单说一下选型与使用场景。 RabbitMQ是使用 Erlang编写的一个开源的消息队列,本身支持很多协议:AMQP、XMPP、SMTP STOMP,也正是如此,使它变得非常重量级,更适合企业级的开发。 RabbitMQ是AMQP协议领先的一个实现,它实现了代理( Broker)架构,意味着消息在发送到客户端之前可以在中央节点上排队。对路由( Routing)、负载均衡( Load balance)或数据持久化都有很好的支持。但是在集群中使用的时候,分区配置不当偶尔会有脑裂现象出现,总的来说,在支付行业用 RabbitMQ 还是非常多的 Kafka是 LinkedIn于2010年12月开发并开源的一个分布式MQ系统,现在是 Apache的个孵化项∏,是一个高性能跨语言分布式 Publish/ Subscribe消息队列系统,其性能和效率在行业中是领先的,但是原先的版本经过大量测试,因为其主备 Partition同步信息的机制问题, 偶尔会造成数据丢失等问题,所以更多的应用场景还是在大数据、监控等领域。目前市面上有很多支付公司都在使用 RabbitMQ作为消息中间件,虽然很重“但是却具有支付行业的不丢消息、MQ相对稳定等特点。缺点则是不像 ActiveMQ那样可以使用Java实现定制化, 比如想知道消息队列中有多少剩余消息没有消费,哪些通道获取过消息,共有多少条,是否可以手动或自动触发重试等,还有监控和统计信息,目前做得还不是太完善,只能满足基本功能的要求接下来我们再来说说消息队列在技术领域的使用场景 (1)可以做延迟设计。比如一些数据需要过五分钟后再使用,这时就需要使用延迟队列设计,比如在 RabbitMQ中利用死信队列实现。 (2)异步处理。主要应用在多任务执行的场景。 (3)应用解耦。在大型微服务架构中,有一些无状态的服务经常考虑使用MQ做消息通知和转换。 (4)分布式事务最终一致性。可以使用基于消息中间件的队列做分布式事务的消息补偿,实现最终一致性。 (5)流量削峰。般在秒杀或团抢活动中使用广泛,可以通过队列控制秒杀的人数和商品,还可以缓解短时间压垮应用系统的问题 (6)日志处理我们在做监控或日志采集的时候经常用队列来做消息的传输和暂存。统一配置中心目前市面有很多种开源的统一配置中心组件可供使用,如携程开源的 Apollo、阿里的 Diamond、白度的 Discont,每种组件都各有特点,我们在使用的过程中还需要根据实际情况来综合考量。笔者公司目前采用的微服务架构是 Spring boot+Dubo的方式,Apoo的架构使用了 Spring Boot SpringCloud的方式,在架构方式上正好可以无缝对接,同时 apollo可以解决同城双活方面的问题,所以从这些角度来看比较适合目前的场景。银行通道监控与切换由于每家银行提供的业务及产品不同,例如B2C、B2B、大额攴付、银企直连、代收代付、快捷支付等,这些产品及服务并无统一的接口,要使用这些产品服务,支付机构只能一家家银行进行接入,当对接的银行通道过多时,每条通道的稳定性就是支付工作中的重中之重,这是涉及用户支付是否成功的关键,也是支付机构支付成功率的重要指标,基于此,要有针对性地进行银行通道稳定性的监控与故障切换系统的建设,如图11-5所示, 数据报警切换系统 Dubbo Redis集群获取通道评分才路由系统通道选择银行渠道通道汇总结果获取通道配置 Collector 持久化 Kafka Redis 处理结束发生故隐后修改通道状态采集银行通道数据将通道设置为不可用 Proxy 数据监控报警通知研发部门 Http InfiuxDB IntluxDB

(系统自动生成,下载前可以参看下载内容)