电子钱包概要设计

电子钱包概要设计＞总体架构设计1系统整体架构设计＞用户可以通过网页、公众号、小程序、APP访问系统，所有的访问都需要先经过系统网关，由网关进行分发。网页的由网关分发到对应的业务前端或管理前端。接口则分发到接口服务，再由接口服务分发到具体服务；＞系统整体服务分为基础平台、业务服务、服务治理、监控'告警三大块。基础平台就是系统的底层框架，提供一些基础的服务，如日志、权限、邮件等。业务服务则包含了所有业务相关的服务。服务治理主要关注的是系统的稳定及性能的优化。通过熔断、限流、降级来保证系统的可用性。通过负载均衡、注册中心、自动扩容来提升系统的性能。监控'告警通过事前预警，能提前对系统服务进行干预，保证系统的稳定。通过对系统的实时监控，掌控系统的运行情况，能根据系统的运行情况及时对系统进行有效干预。＞在服务与数据库间设置了中间层，中间层主要包含三块：缓存层、数据路由、分布式事务1）缓存层

常用数据可以放在缓存层，这样服务直接访问缓存，而不读取数据库，减轻了数据库的压力,提升了系统的性能。2）数据路由服务通过数据路由来访问数据库，服务本身并不关心他访问的是哪个库，哪张表。全部交由数据路由根据业务规则来处理，这样就可以动态的实现读写分离、分表分库。3）分布式事务分布式事务的处理不耦合在业务方法里，而是独立出来，根据具体业务做不同的处理。＞数据库做集群，做分库分表、主从热备。2系统功能架构设计T主用一T开电子账户卜用户业再■前端J"用了账户T充值提现卜败尸数据库日志一租分塌作T史尧系一优惠券操作T缢用户更忖接口用务和.分，优惠券加解密♦克值堤顼回调一一支付退款T阡电子账户一充值提现国际银行下裁订单数胡账单查询T北务季籍数据库—去4二T主用一T开电子账户卜用户业再■前端J"用了账户T充值提现卜败尸数据库日志一租分塌作T史尧系一优惠券操作T缢用户更忖接口用务和.分，优惠券加解密♦克值堤顼回调一一支付退款T阡电子账户一充值提现国际银行下裁订单数胡账单查询T北务季籍数据库—去4二退号T核心交易账单查询支付退款回i管理前端闽置物据库调度z\肥业公司注用入网

报表查洵。商户报表匏据库＞系统分为前台、中台和后台，前台提供前端（H5、APP、公众号）及接口服务给用户及外部系统调用。中台为各个业务服务，后台为国际银行；＞用户可以直接登录系统的前端进行注册、开设电子账户、充值提现等操作。外部业务系统可以通过接口进行相关业务操作。＞所有对外接口都会经过接口服务，接口服务日志记录及解密后再调用相应的服务进行业务处理，业务处理完后再经接口服务加密回调给外部系统。＞业务服务分为积分'优惠券、用户、商户、核心交易、账户、账务、配置、调度、报表。积分'优惠券服务主要处理积分和优惠券的业务。用户服务用来处理用户的业务，包括用户注册、信息变更、用户参数配置、数据查询等。商户服务主要处理相关商户的业务，包括商户入驻、信息变更、商户参数配置、数据查询等。核心交易服务的处理的是支付退款等核心交易。账户服务主要用来维护用户和商户的账户信息。账务服务主要是处理用户和商户的对账信息以及财务会计数据。配置服务主要是维护系统的相关配置。调度服务主要负责定时任务调度。报表服务负

责报表的展现。A从用户开户到支付到对账单生成，从商户入驻到平台签约到对账单生成都会跟国际银行进行对接，国际银行主要负责用户开设电子账户、商户进件、与第三方支付平台对接、商户分账、对账单生成。A接口服务单独一个数据库，主要存储日志记录。用户、商户、账户、配置一个数据库。积分优惠券服务一个数据库。核心交易和账务一个数据库。报表一个数据库。调度服务可以操作核心交易和报表的数据库。3系统技术架构设计盟和阿式/工由1集目0苒曲I呻用心口峭M英姿旃RiGMi阳ZijuIgatewayZuul纲1•标盟和阿式/工由1集目0苒曲I呻用心口峭M英姿旃RiGMi阳ZijuIgatewayZuul纲1•标y垄client＞系统主要采用的技术有：令SpringCloudSpringCloud是一套完整的微服务解决方案，它集成并封装netfix中的ribbon,eureka,hystrix,feign和zuul等十分出色的项目，为我们提供了服务注册与发现，客户端的负载均衡和路由分发等功能。为现在的大部分中小企业开发分布式架构提供了一整套的解决方案，大大提高了工作效率。令RedisRedis是一个开源的底层使用C语言编写的Key-Value存储数据库。可用于缓存、事件发布订阅、高速队列等场景。而且支持丰富的数据类型：string（字符串）、Hash（哈希）、List（列表）、Set（无序集合）、Zset（sortedset：有序集合）。它在项目中的主要实现场景，如图：

客户踹MySql客户踹缓存MySql数据库层直接与缓存进行交互，如果缓存中有数据直接返回客户端，如果没有才会从MySQL中去查询。从而减小了数据库的压力，提升了效率令EFKEFK是三个开源软件的缩写,分别表示：Elasticsearch,Filebeat,Kibana,它们都是开源软件。Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。作为Beats家族的一员，Filebeat是一个轻量级的日志传输工具，它的存在正弥补了Logstash的缺点：Filebeat作为一个轻量级的日志传输工具可以将日志推送到elasticsearch上去。Kibana也是一个开源和免费的工具，Kibana可以为Filebeat和日asticSearch提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。ELK结构图：令TX-LCNTX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。事务控制原理：TX-LCN由两大模块组成,TxClient、TxManager,TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制放。事务发起方或者参与反都由TxClient端来控制。原理图：

若与方后❷遇知中男组口二-5.«EiS3UlTS*a-工可近乎Sflf717帝孝根快A--——TE-sponiEeTxManager执行1Z若与方后❷遇知中男组口二-5.«EiS3UlTS*a-工可近乎Sflf717帝孝根快A--——TE-sponiEeTxManager执行1Z秀□[]相国*筠单元-一核心步骤创建事务组是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。加入事务组添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。通知事务组是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。解决方案：在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。例如存在服务模块A、B、C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。

若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。＞系统架构说明：令web服务器的选型，这个我选择的是nginx+keepalived，haproxy也是一个选择，但是haproxy在反向代理处理跨域访问的时候问题很多。所以我们nginx有些地方做了keep-alive模式处理，减少了三次握手的次数，提高了连接效率。keepalived做nginx的负载，虚拟一个vip对外，两个nginx做高可用，nginx本身反向代理zuul集群。令系统网关采用zuul，这里的zuul很多人诟病，说是速度慢推荐直接用nginx，这里我还是推荐使用zuul的，毕竟zuul含有拦截器和反向代理，在权限管理、单点登录、用户认证时候还是很有用的，而且zuul自带ribbon负载均衡，如果你直接用nginx，还需要单独做一个feign或者ribbon层，用来做业务集群的负载层，毕竟直接把接口暴露给web服务器太危险了。这里zuul带有ribbon负载均衡和hystrix断路器，直接反向代理serviceId就可以代理整个集群了。令业务集群，这一层我有些项目是分两层的，就是上面加了一个负载层，下面是从service开始的，底层只是单纯的接口，controller是单独一层由feign实现，然后内部不同业务服务接口互调，直接调用controller层，只能说效果一般，多了一次tcp连接。所以我推荐合并起来，因为做过springcloud项目的都知道，feign是含有ribbon的，而zuul也含有ribbon，这样的话zuul调用服务集群，和服务集群间接口的互调都是高可用的，保证了通讯的稳定性。Hystrix还是要有的，没有断路器很难实现服务降级，会出现大量请求发送到不可用的节点。当然service是可以改造的，如果改造成rpc方式，那服务之间互调又是另外一种情况了，那就要做成负载池和接口服务池的形式了，负载池调用接口池，接口池互相rpc调用，feignclient只是通过实现接口达到了仿rpc的形式，不过速度表现还是不错的。令redis缓存池，这个用来做session共享，分布式系统session共享是一个大问题。同时呢，redis做二级缓存对降低整个服务的响应时间，并且减少数据库的访问次数是很有帮助的。当然rediscluster还是redissentinel自己选择。令eurake注册中心这个高可用集群，这里有很多细节，比如多久刷新列表一次，多久监测心跳什么的，都很重要。令springadmin，这个是很推荐的，这个功能很强大，可以集成turbine断路器监控器，而且可以定义所有类的log等级，不用单独去配置，还可以查看本地log日志文件，监控不同服务的机器参数及性能，非常强大。它加上elk动态日志收集系统，对于项目运维非常方便。令config配置中心，这是很有必要的，因为服务太多配置文件太多，没有这个很难运维。这个一般利用消息队列建立一个springcloudbus，由git存储配置文件，利用bus总线动态更新配置文件信息。令zipkin，这个有两种方式，直接用它自己的功能界面查看方式，或者用stream流的方式，由elk动态日志系统收集。但是我必须要说，这个对系统的性能损害非常大，因为链路追踪的时候会造成响应等待，而且等待时间非常长接近1秒，这在生产环境是不能忍受的，所以生产环境最好关掉，有问题调试的时候再打开。令消息队列，这个必须的，分布式系统不可能所有场景都满足强一致性，这里只能由消息队列来作为缓冲，这里我用的是RabbitMQ。令分布式事务，我认为这是分布式最困难的，因为不同的业务集群都对应自己的数据库，互相数据库不是互通的，互相服务调用只能是相互接口，有些甚至是异地的，这样造成的结果就是网络延迟造成的请求等待，网络抖动造成的数据丢失，这些都是很可怕的问题，所以必须要处理分布式事务。我推荐的是使用TX-LCN开源的分布式事务框架。它支持LCN,TXC,TCC三种模式，项目可以根据业务实际情况灵活配置。令实时分布式日志系统，Filebeat收集本地的log文件流，传输给elasticsearch，elasticsearch再将流传给kibana，动态查看日志，甚至zipkin的流也可以直接传给elasticsearch。这个配合springadmin，一个查看动态日志，一个查看本地日志，同时还能远程管理不同类的日志级别，对集成和运维非常有利。、系功能设计1登录认证服务1.1登录认证时序图

①前端先校验access_token是否存在，不存在则直接跳转登录页面②有access_token则携带access_token访问需要的资源，资源服务到认证服务校验access_token是否有效，无效则跳转回登录页面。有效则根据access_token从Redis中获取登录用户信息，用户信息不存在同样跳转登录页面。③用户从登录页面登录。④认证服务校验登录信息，成功则生成access_token和refresh_token，并将登录用户信息保存在Redis里，并将access_token和refresh_token返回给前端1.1ER图22用户服务注册时序图电于钱包用户服务户注册贞'面电于钱包用户服务生八也用位，以二.---先向注册帝求〔岷守.雷帆）退回工团州是ER