推荐系统核心任务是排序，从线上服务角度看，就是将数据从给定集合中数据选择出来，选出后根据一定规则策略方法进行排序。
线上服务要根据一定规则进行架构设计，架构设计是什么？每一次权衡取舍都是设计，设计需要理解需求、深入理解需求基础上做权衡取舍。复杂系统架构需要需求方与研发人员反复沟通探讨。这需要技术领导者能理解并鼓励这种行为，才能有所谓技术驱动，否则光喊口号不会产生什么所谓的技术驱动。
品类召回配置化，通过对每一个key进行配置管理，配置项包含偏好取得数量以及卡分配置、排序优先级等多个配置项。每一个配置生成一个配置对象，配置绑定到一个ABTest算法上。配置管理界面、配置管理服务构成配置管理平台。
素材、特征召回配置化，根据分类召回素材，根据用户、分类、素材、设备、季节等多个条件拉取素材。素材与特征全部通过配置化进行实现，由人管理配置文件由xml构成、
素材、特征召回这两项特点是召回量大，要注意有大量此类偏好数量，这种数据获取最好用线程池，设置超时如超时则这次请求有部分数据未请求到，并进行记录。
特征上报，为了方便模型组进行模型训练，因为一些数据是比较散的，就是说这种情况下需要对数据进行进行响应处理，在进行上报，每一种数据处理方式是不同的，需要对特征进行分类处理。
并且为了避免增加新特征或者修改特征就进行上线，这是与模型组探讨，根据需求设计可配置，或者说基于配置文件的特征计算。要建立一套与特征归一化相应多种计算规则，以支持多种类型特征配置归一化。
分类召回级平台，素材、特征召回级平台，均存在一个配置更新后怎样获取问题。配置更新是一个通用问题，大概存在几种方式：一种是配置管理界面更新时更新服务配置信息，一种是定时更新方式，一种是通过通知方式，当有变更时发起更新。
最简单方式就是，在管理平台修改后进行更新，但现在线上服务多为微服务集群，通过更新管理平台，同时更新多个微服务节点不是一种可行方式，在过去单体web系统中是可行的。
定时更新方式实现简单，并且能保证比较好一致性，并且就算这次更新集群存在个别节点更新失败，下一次更新也会更新成功。但这种方式要注意不要用线上服务定时拉取数据库，因为会导致数据库压力过大，可以采取将数据库节点数据同步到redis方式，通过redis来支持定时更新，因redis能支持极大读qps。
通知方式最优雅，即观察者模式。观察者订阅事件，事件发生时，各个订阅节点根据事件进行响应操作，当配置更新发生时，线上服务节点更新配置到最新，通过Zookeeper可以很容易实现此种配置方式，其实也需要比较懂zookeeper原理与编程。
过滤建立职责链进行实现，扩展性强，可读性强。分类过滤，最近购买过分类，分类过滤白名单。过滤包括但不限于用户已购买、以曝光。在问答业务上，像我提问我已经回答，构建职责链逻辑清晰易理解。
配置化，通过配置文件实现整个逻辑通用化，是小伙伴最初的梦想和模型组构建出来配置化召回素材以及特征架构，很给力。通过配置实现对于品类素材特征召回，并且支持分层ABtest,并且配置中包含对特征计算，特征计算主要是上报特征用于模型计算，但是有些数据需要进行归一化处理，以方便模型训练使用。并且给人编辑配置文件为xml，通过程序转换成json，并且通过json来支持程序使用，能够方便程序进行解析，xml对人友好，json对程序解析友好。
特征归一化是特征上报很重要一环，他的特点是情况多，要根据数据分布情况做相应处理，就需要提前归纳总结多种情况，因为反射性能差线上服务是接受不了的，就需要提前对数据处理分成几类，提前想好处理逻辑，根据配置项选择相应逻辑进行处理。
上报特征服务、日志白名单服务，上报特征服务将两部分特征进行上报，一部分是简单特征由服务本身进行配置上报，另一部分是复杂特征由其他服务计算后调用上报特征服务，两部分合并进行特征上报。
日志白名单平台，服务可以配置相应用户信息，并且提供服务支持其他服务上报用户在白名单中进行相应记录，并且提供平台界面支持检索。这样可以方便定位线上服务问题，快速解决问题。
推荐系统是个复杂系统，由多个模块构成，构建推荐引擎，我们在一步步探索。
推荐系统架构，推荐系统由品类平台，素材、特征召回平台、模型计算打分服务，排序服务构成。
将请求封装成QueryInfo对象，通过对象来向下完成一步步数据召回。首先是通过QueryInfo对象召回品类、分类信息。
前边有人问到是怎样实现通用化？好问题，当时答得不太好，现在梳理总结一下，分类平台通过配置品类、分类信息，配置选取个数、配置过滤品类信息，通过每一种配置情况构建分类信息，分类信息完全由配置文件构成。
召回品类扩展QueryInfo对象构成QueryInfoExtern对象，为下一步进行素材、特征召回做准备，因为品类、分类数据量少，传输时不会因为数据量消耗太多时间，而素材、特征召回量极大，可通过分布式形式将素材进行召回，此时召回量最大可满足线上服务要求，召回之后，每组分别进行打分计算，打分之后进行取前边数据进行返回。
再由品类召回节点合并将高分素材进行返回，熟悉ElasticSearch同学，会发现和ElasticSearch集群架构很像，其实推荐本身和搜索就有很多相似之处，研究搜索引擎对于推荐引擎构建也会大有益处。
数据返回之前由排序服务对数据按展示效果进行商品按照品类、分类进行分隔，文章内容按标签、主题进行分隔。分隔目的是为了好的展示效果，提升用户体验，通过上面这一系列过程构建成推荐系统大致过程。
除了上边架构逻辑，还存在存储以及数据流转体系。分类、素材、特征存储在redis、HBase*服务读取使用。
对于实时反馈，用户点击、浏览会通过存储在redis中用于过滤，以及调整后续推荐分类、素材权重，已作为一种最实时反馈手段。
上报特征本身通过JDQ消息队列进行上报，上报异步进行，通过先写日志文件再上报日志文件内容，来达到异步上报，以避免同步上报导致线上服务性能受影响。JDQ本身基于开源kafka打造。
JDQ本身为了资源情况限制上报速度为5M/s,为了更好利用上报机器资源，会构建内存队列，充分利用内存资源来控制发送速度，而不是一味通过扩容来解决问题。
一个挺不错的Java架构交流学习群：688583154里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多：
关注公众号：Java架构师学习
日志白名单本身按照服务、属性、关键字进行存储，在ElasticSearch中可方便按属性、关键词检索使用，通过图形化界面展示，方便快速定位线上问题。
监控本身除了Ump对系统功能、性能、可用性进行监控，引擎本身就要配备全面监控避免程序某个分支存在问题，导致线上服务正确性、可用性存在问题，再有因为程序很多由配置文件动态构成，性能也要进行全面监控。
对于线上效果，线上模型与分支进行绑定，当分支A效果实时效果好于B效果，要将线上模型进行更新调整，监控时间以几个小时效果为准。线上效果也要进行相应监控，如效果不好要对效果进行报警，以便算法人员对情况进行处理。