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

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

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

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

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

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

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

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

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

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

        线上服务挑战会一直存在，什么样心态面对，会带来截然不同的结果。

微信搜索：debugme123