今天给大家分享的是一个基于支付场景的微服务实战，会比较偏向于应用层的内容。分享主要围绕以下四点展开：SOA和微服务旧支付架构遇到的挑战基于微服务应该如何改造SOA和微服务在我看来，虽然微服务是从国外引进的技术，但它和我们中国的一些理论有关。那么在正式进入正题之前，先给大家简单介绍一下麦田理论。关于麦田说古周时期，百姓耕种土地，没有任何规划，没有地域限制。一般来说，田里种水稻，隔段种麦子，隔段种菜。然而，收获后发现，作物接受的阳光很少，营养很不均衡，后期维护成本很高。直到战国时代，一位农业专家将土地划分为多个区域，每个区域种植一种作物，田地分离，形成了最初的微服务概念。我们以前看到的很多文章，只讲SOA和微服务的比较。今天我在这个基础上加了个DDD。下面介绍DDD、SOA和微服务的演进过程。DDD、SOA和微服务SOA架构SOA是前时代的产物，出现在2010年之前，最早是作为传统行业计算的解决方案被提出来的。当时，甲骨文和IBM也提出了很多解决方案，其中就有很多流程引擎应运而生。它的思想是将紧耦合的系统划分为面向业务的粗粒度、松耦合和无状态的服务。之后，微服务的提出者在SOA的基础上做了改进，变成了单一职责、独立部署、小型的微服务，这是一个相反的概念。微服务与DDD今天说到微服务，就会想到DDD。很多朋友认为DDD是为微服务而生的。事实上，情况并非如此。当我接触到DDD时，它首先用于UML设计和领域建模。DDD关注充血模型，而J2EE模型将传统的分层架构与Spring架构捆绑在一起，形成基于贫血模型的架构模式。贫血模型的优点是容易上手，层次分明，而充血模型则需要设计者前期对业务有深入的了解，否则后期的项目会造成混乱。另外，DDD思想比较宽泛，导致形成了百家争鸣的态势，没有形成固定的方法论。开发者不容易理解，所以后来很少有人关注DDD，而微服务的提出巧妙地借用了DDD中的限界上下文、子域、领域事件等关键词，在微服务中得到了越来越多行业的认可在这种情况下，也给DDD带来了新的机会。旧支付架构遇到的挑战两个角度判断一个项目的好坏我们可以从两个方向来判断一个优秀项目的好坏：优秀的代码和高可用的架构。在设计高可用架构时，我们不能忽视代码的重要性。优秀的代码是指错误冗余、死锁操作、并发、死锁等，并不一定意味着代码写得有多漂亮。这就像建造一座建筑物。房子的基本框架搭建的很好，但是盖房子的工人不够专业，很多需要注意的地方都被忽略了，所以在里面填砖填瓦的时候就出现了问题。结果就是房子经常漏雨，墙壁出现裂缝等问题。虽然大楼不会倒塌，但大楼已经变成了危楼。从代码和设计的角度来看，有：代码不合理导致项目不可扩展数据库经常出现死锁数据库事务被误用，导致事务耗时过长代码容错性差，经常因程序考虑不足打印了大量无用的日志，造成性能问题。常用的配置信息还是从数据库中读取滥用线程池，导致栈和堆溢出从库中查询数据，每次都检测所有业务代码。研发不考虑幂等操作。缓存不合理，存在雷羊效应，缓存穿透等情况，代码上下游流程定义混乱。异常处理机制混乱。从整体架构来看：整体还是采用单集群架构，采用单机房服务器部署方式。Nginx+hessian面向服务的业务架构划分不完整，项目拆分不完整，边界模糊，监控系统（网络，系统）不合理，一个Tomcat共享多个应用无故障。、手动在线系统扩容和手动部署基于以上两点，我们可以清楚的看到老项目存在的问题，开始思考新的微服务架构应该怎么做。基于微服务的改造如上图所示。想要构建高可用的微服务架构，首先要确立以下五点：产品迭代速度。架构设计好之后，一定要对产品有利。设计没有完成后，会比以前更快。发展较慢。这也是微服务的核心。通过拆解业务，将不同的产品一个一个产品化，而不是投射。系统稳定性，一个系统在单一架构报错时，所有错误都报错，现在粒度更细，同时构建各种监控系统。研发效率。快速定位问题，就是每年给我们几十分钟的故障时间。系统耦合度，不要把所有的系统都放在一起，而是多拆解。使用DDD划分限界上下文。这是一个基于一些业务场景的业务架构图。中间绿色部分是产品服务层。用DDD的思想来分析，产品服务层也就是产品服务域，包含三个子域，一个是收银子域，一个是商户子域，一个是个人子域。每个域都包含有界上下文，两个用于收银员，四个用于商家，两个用于个人。有的同学可能不理解boundedcontext的概念，可以理解为一个系统，一个边界或者一个实体。例如，我们每天要从地铁上跌倒三次才能上班。这其中的关键事件是什么？刚上班，boundedcontext就是坐地铁，中间转了三次。限界上下文可以理解为一个微服务，也可以理解为一个系统或者一个模块。限界上下文的划分可以根据我们团队的规模来确定。如果团队规模还没有达到一定程度，边界线可以设置得粗一些。如果项目规模和团队规模继续扩大，大领域和有界上下文可以继续。分成多个较小的。微服务治理架构图这是我们一个微服务整体的大体流程图，采用的是SpringBoot+Dubbo架构。为什么提倡使用Dubbo而不是SpringCloud？有两个原因：这取决于当前的体系结构。如果是Dubbo，很多组件的一些设施肯定是围绕着它搭建的。如果这时候完全推翻，换成另一种架构，我们需要慎重考虑成本部分。SpringCloud技术虽然新，但不一定比Dubbo好。目前公司维护了一个DubboCloud，并开发了基于Dubbo的微服务系统。上图中间的探针也是我们自主研发的，可以收集整个业务链路的各种信息。比如断网的时间，报错，返回值，参数都收集了。采集完之后，用一个开源的组件对信息进行改造，所有的信息都推送给它，通过那个界面展示我们想要的东西。后一套，比如Hystrix断路器、DubboAdmin和MockServer，我们参考了Dubbo的智能拦截和服务降级的思路。下面的服务注册、服务发现、服务路由、失败重试、服务监控都是Dubbo自己提供的，也就是图中绿色部分是我们开发的新功能。未来我们会开源这个DubboCloud系统。通道告警切换系统的演化这是我们通道告警系统的框架演化。为什么叫“通道”呢？因为我们的支付需要和银行对接，但是银行本身比较传统，他们的渠道不是很稳定。经常会出现各种各样的问题，每家银行都有N个通道。我们无法知道在不久的将来哪个渠道是稳定的或不稳定的，它会来回变化。在这里，我们通过在其通道中收集一些使用数据来开发一个代理。比如这次我们连接成功，获取到数据，然后放到kafka中。之后就是统计分析的事情了。如果通道成功连接一次，它的统计数据将被添加一次，并且每隔一段时间将结果存储在Redis集群中。图中的路由系统用于通道选择。这是一个业务系统。路由系统每次选择通道时，首先从Redis集群中取出银行的通道，选择得分最好的通道。取出来之后，我们可以通过自己的一套路由选举来做一个清洗或者选择，最后得到一个专用通道，这个通道直接和银行通道相连，这样我们就可以知道哪些通道是高可用的。底层流程还是通过Kafka，进行各种统计分析，也非常好用。然后这里会有一个图表。如果目前有问题，你可以在界面上看到，同时可以给你发短信和邮件。为什么我们在这里做两套？第一期我们会做一个数据对比，因为如果采集的数据不准确，这个渠道就会出问题。所以我们一方面用上面的方法做评分策略，另一方面我们把数据收集起来放到一个库里，然后通过这个库再做一遍。最后，我们每次都进行比较，统计准确率。.当这个通道有问题的时候，比如某个银行通道有问题，我们的监控系统会直接把这个银行通道设置为不可用，然后通知研发部门让他们解决，然后让这个通道可用。如果这个过程中的数据不准确，会造成频繁的频道切换和很多不必要的问题，所以我们在第一阶段会做成半自动的。双活系统架构的演进双活机房的演进也需要两个阶段：第一个阶段是伪活-活两个机房同时提供服务，但主备机需要布置房间；备机房的应用只能通过专线访问主机房的数据库；备机房的Redis也需要通过专线访问主机房的Redis。当主机房宕机时，需要将备机房应用的数据库配置更改为备库，同时关闭备库，将备库改为主库.第二阶段是泳道主动-主动系统架构的演进。ZK在进行数据同步时，采用了两种方式：Curator的TreeCacheListener监听相应节点的变化来同步数据，另一种是修改ZK源码伪装成Observer接收交易Log数据来实现数据同步。ZK的同步方式依然没有进行同步和车道隔离。比如在使用Dubbo的时候，可以同步两个环境。如果用当当网的Elastic-Job，在做active-active的时候会比较麻烦。微服务架构全景这是我们整个微服务的整体架构。左半图是服务怎么划分，划分了哪些区域，然后有哪些服务可用，数据库内容怎么划分，网关层怎么做。从业务角度来看，这是一个部门。右边的部分展示了我们如何确保微服务的可靠性。第一层主要供项目运营商使用。第二层是我们为保证微服务所做的。有统一调度中心、双活管控架构、大数据平台和分布式缓存。各种组件用于保证微服务的顺利开发。下面是一些监控。这里我们使用APM分布式调链监控，包括我们自己搭建的一些监控平台。持续集成测试接下来说说我们的持续测试经历。如何保证代码的质量？这就涉及到集成测试的概念。我们把它分为四个象限：一个是单元测试，由开发者自己完成，一般覆盖率为60-80%；另一种是验收测试和探索性测试。这两个其实都是我们测试人员做的。一个是验证业务的可行性，一个是做一些不合规的条件或者一些破坏性的测试，最后就是压力测试。通过压力测试，我们可以看到系统能够承受的负载情况。这是我们整个测试过程：首先，我们参考了阿里等公司的一些编码标准，制定了自己的编码标准，与所有开发者达成共识。然后我们有自己的静态代码检查，这里也可以使用阿里的组件，就是前两步。第三步是单元测试。基本上，前三部分是为了保证代码的健壮性和正确性而开发的。第四是持续集成。我们按照自己的规则和模板再次扫码。扫描之后，我们组织一些架构师或者技术专家对一些关键的核心代码进行重构。五个步骤。我们计划在未来做的事情。上图中的点是我们未来打算做的一些事情，因为业务量越来越大，考虑到异地多住的情况，央行马上又要发一个文件了。我觉得是一个趋势，目前很多公司都在做。那我们还有一个DubboCloud，以后也会开源的。后者是大数据平台的持续建设。目前我们的大数据平台还不是特别完善。比如数据挖掘还没有做，现在一般的金融公司、支付公司都要做特别好的风控，才刚刚开始。程超，智能支付专家，12年Java开发经验，对互联网支付和电子商务业务有深入了解，擅长分布式、性能调优等技术领域，对高并发、大数据有浓厚兴趣数据。《深入分布式缓存》本书的合著者。
