会员运营框架（PLUS会员合作商系统架构演变）

作者:平台研发李鹏程

来源: 京东零售技术

出处:https://mp.weixin.qq.com/s?__biz=MzUyMDAxMjQ3Ng==&mid=2247495567&idx=1&sn=ef30287f35b1708a992939acabf90c0d

一个好的系统架构是靠演变而来，刚开始系统上线，我们不可能全方位的考虑到架构的高性能、高扩展性、高安全等各方面的因素。随着业务需求越来越多、业务访问压力越来越大，架构不断的演变及进化，因此造就了一个成熟稳定的架构。如Facebook、淘宝网等大型网站的架构，无不从一个小型规模架构，不断进化及演变成为一个成熟稳定的网站架构。

PLUS会员合作商业务，随着对接的合作商越来越多，已经从开发测试全回归开始转型为定向开发测试。在系统中如何构建定向架构并提供稳定的服务，本文主要结合自身的最佳实践经验，向大家分享PLUS会员合作商系统架构演变的过程。

系统原始阶段

PLUS会员首次在2018年的3月与爱奇艺正式达成全面战略合作关系，随后分别在2018年5月和2019年6月接入了知乎和腾讯视频，这些合作商调用的接口是相同的，这样就会在接口的业务层公共逻辑部分去判断类型，面临着当新增合作商时就需要去改公共逻辑，如果修改了公共逻辑，那么在开发自测和测试同学进测时就会回归测试，既增大了研发工时也增加了测试的工作量。

系统演变过程

为了解决原系统的工程化效率和性能问题，为成为一个集成多种应用、多种数据、多种流程，能够显现敏捷开发的平台，PLUS异业合作组进行了大量的设计模式的调研和业务逻辑的梳理，找出对接各个合作商的共性和个性化差异，从顶层设计出发，适配底层各个逻辑路由，利用成熟的中间件解决性能问题。下面将介绍系统架构演变过程的主要几个方面：

将一个请求封装为一个对象，从而使不同的请求对客户进行参数化。这种模式调用者需要构建参数化，但是并不知道请求的接受者是谁，也不知道被请求的操作是什么，此时希望用一种松耦合的方式来设计程序，使得请求发送者和请求接收者能够消除彼此之间的耦合关系。而对于不同的合作商，入参的格式是一样的，但是入参的赋值具有个性化含义，需要不同的入参赋值包装对象。

在顶级接口Command里定义了execute()方法，该方法是调用接口的唯一入口；并且在BasicCommand子类里实现了execute()方法，定义了执行逻辑的主流程，包含了参数校验、包装参数、防频、鉴权、前置处理、后置处理等；在BasicForeignComand里对继承的方法默认实现。

策略模式包含三个角色，上下文角色（Context）：用来操作策略的上下文环境，屏蔽高层模块（客户端）对策略和算法的直接访问，封装可能存在的变化；策略角色（Strategy）：规定策略或算法的行为；具体策略角色（ConcreteStrategy）：具体的策略或算法实现。

这里的关键点是如何定义上下文环境及如何找到具体的策略算法。合作商系统采用spring架构，在spring的扩展功能中有ApplicationContextAware类，该类的主要功能可以获取到spring上下文，并且取得已实例化的bean,而这些实例化的bean就是我们注入到容器中的个性化的策略。对于这些策略是需要分类的，例如，当调用资格接口可以找到合作商对应的具体资格策略，我们定义了map结构保存数据，key就是合作商标识 方法名，value就是具体策略。采用这种方式，所有的策略都是被容器管理，Context根据入参就可以定位到具体策略执行逻辑。我们设计了顶层策略接口Strategy,并且逐层实现继承，考虑到合作商共性逻辑，定义了Base*类，例如,BaseSubscribeCooperatorStrategy实例就是共性实现，当有个性化处理时，继承Base来实现父类方法。

通过spring中AOP特性面向切面编程，业务处理流程中抽象出重复性行为，实现业务代码与非业务代码的分别维护。定义接口注解，在访问方法的环绕通知中，自动上报ump。我们定义了每个异常类型和异常码的一一对应关系，通过切面捕获的异常类型映射为返回码返回给调用者，这种方式把接口方法信息做了统一管理。

架构的原始阶段持久化层采用的是单数据库，每次到了活动大促的时候为了防止数据库的高并发导致宕机，应急措施都是降级，这种操作直接影响了用户体验及数据的不一致。为了解决这个问题采用了Sharding-JDBC关系型数据库中间件实现了分库分表功能，无中心化架构，适用于合作商系统采用Java开发的高性能的轻量级OLTP应用，我们组内自定义starter,封装定义了数据源（8主8从），结合业务逻辑配置分片策略，能够灵活的路由到具体库具体表中。针对中间件对服务器进行压测TPS达到10w/s,完全达到了各大促的高并发指标。

数据流转涉及到两个方向，一个是PLUS侧对接合作商，另一个是合作商侧对接PLUS,合作商接入的过程中并不一定都涉及到两个方向，这样拆分为两个集群，采用分而治之的方式各个集群达到轻量化、各司其职，并且监控日志更加清晰。在对内集群中利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。

系统架构演变总结

系统架构演变的过程也是我们不断地重构解耦实现平台化的过程，该系统平台化在设计上综合考虑了交互设计、用户体验、技术架构、业务流程、数据模型和功能设计等各个方面，已成为公司PLUS会员体系持续发展的亮点和竞争的制高点，现在系统有适配需求的场景化、顶层设计的抽象化、各个策略的高内聚、组件之间的松耦合、集群的职责分离等优势，该系统平台成为对内对接PLUS会员，对外对接各个合作商的稳固桥梁，整合了内外部资源。如今已经独立、自治、灵活地对接了多个合作商和渠道，工作量已经减少为原来的1/10。

未来该系统平台设计，遵循设计标准化原则至关重要，严格遵循流程标准化、数据规范化和技术标准化原则。为提供更加优秀的平台化系统服务，任重而道远，我们一直在架构演变的道路中。

作者:平台研发李鹏程

来源: 京东零售技术

出处:https://mp.weixin.qq.com/s?__biz=MzUyMDAxMjQ3Ng==&mid=2247495567&idx=1&sn=ef30287f35b1708a992939acabf90c0d