个性化推荐系统（四）--- 推荐系统服务端

 推荐系统怎样稳定高效提供服务，持续不断知足业务需求，持续不断面对技术挑战，是每个服务端开发同窗应该持续思考，和持续不断优化线上服务。

        之前咱们开发的程序更多的是网站，而且以单体服务形式构建，好处是整个程序一次构建，维护方便，但当公司发展后，组织机构变大，程序由多我的维护，单体程序维护成本高，难于修改，难于持续升级问题就暴漏了出来。影响了线上业务持续发展，产品需求及时上线。

        为了应对大型机构，特别是大型电子商务系统，须要持续不断优化，将单体程序进行横向纵向拆分，每一个组织只维护本身的服务，每一个模块可进行不断持续的升级优化，微服务将系统拆分，整个系统复杂度下降，而且每一个系统部分，根据本身流量状况动态调整资源，能够既保证资源最大化利用，又能够很好的应对618，双11等流量大促状况。

        对于大部分程序微服务已经可以很好的解决问题。当下个性化推荐系统面临问题和通常程序有必定差别性，一方面个性化意味着“千人千面”，每一个用户用到数据都不同，常规缓存策略失效，这就要求对程序不断优化已保证性能。 

        当下个性化推荐正由策略主导，转型到由机器学习算法，深度学习算法，这一过程对于服务端要求要支持更多数据拉取，个性化推荐服务比较核心指标召回率，准确率。所谓召回率是根据用户偏好，兴趣，热门等各类条件拉取文章或sku商品数量大小。准确率比较好理解是召回数据里面多少是用户愿意去点击的，带来多少点击量。       

        当前今日头条，淘宝等个性化推荐服务均是构建在微服务架构之上，整个流程是根据用户信息拉取分类召回集，过滤已经曝光过，已经购买过等分类召回集，根据分类召回集拉取素材，过滤相应曝光，已购买等素材信息，对数据进行品牌，品类分隔优化用户体验，这是原来常规逻辑。线上服务接入GBDT，深度学习DNN等模型后，须要根据素材信息，拉取用户，分类素材，用户素材交互特征，场景特征等多个维度几十个特征，这样特征须要每一个用户实时拉取成千上万组，对于线上服务性能稳定性是极大挑战，换个角度看对于提高服务端技术水平也是很好机会。

        线上每分钟10万次访问系统实时拉取大量数据而且进行实时模型计算，是个颇有挑战问题，面对问题咱们怎么处理呢？首先咱们处理这个核心思路是，职责拆分，将模型CTR计算拆为单独服务，召回集由60扩大到200。

       把线上素材特征召回集一会儿由200扩大到1000，性能一降低到400ms，性能不可接受，经定位分析发现耗时为计算服务，怎么样才能优化GBDT模型计算性能呢？单个线程解决不了，那就多个线程，这时召回集扩大到一千单整个服务性能由原来400毫秒缩到到60毫秒，扩大召回集成功，线上点击率转换率获得提高，你们努力没有白费，仍是颇有成就感的。

       再一次扩大召回集，须要将服务拆成分布式，微服务节点只拉取分类召回集，素材找回集特征数据由模型计算节点处理。并分主从节点并由主节点，协调进行分布式计算，减小IO避免特征无用传输，仅返回有意义的数据素材排序，同时每一个多线程利用多核计算，将召回集扩大到几千，上万彻底知足线上需求。

        线上服务挑战会一直存在，什么样心态面对，会带来大相径庭的结果。

微信搜索：debugme123

      扫描二维码关注：