本周阅读了老师推荐阅读的公众号：架构师中的推文《蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践》，感想如下：
上一周阅读笔记《阅读心得14：《新浪微博用户兴趣建模系统架构》》介绍完独立的1.0。
按照架构发展的道路，我们到了分叉路口，一边是流行的LAMP架构，另一边是符合广告、搜索的CELL架构。LAMP架构数据策略分离，脚本语言作为业务开发主要语言，项目快速开发和迭代的首选。CELL结构强调本地流程处理，数据与业务耦合性强，自研的服务以及数据库较多出现，适用于高性能效果型产品。最终我们选择兼容两者，倾向于业务的架构体系。为何如此呢？让我们再来看看当时的环境。
微博推荐2.0的时间段是2013年3月份到2014年年底，这段时间内部环境因素是：
1) 当前团队成员合作已经很长时间，彼此相互熟悉，同时对于技术选型有了一定的共识。
2) 团队产品进行了聚焦，针对内容／用户／垂直类三类推荐进行了整理，同时对于场景分别进行了重点划分：feed流内、正文页以及PC首页右侧。这种聚焦有利于进行架构统一，同时也为技术争取了时间。
而外部因素是：
1) 公司对于推荐有了比较明确的定位，提高关系达成以及内容传播效率，同时为推荐型广告打好技术探索、场景介入以及用户体验的基础。
2) 推荐领域里，各个公司都纷纷有了对于架构的产出，对于微博推荐有了很好的指导意义。
2.2 架构组成与特点
团队在执行核心业务实现的时候，不断演进工具以及框架，构建2.0的目标呼之欲出。
1) 技术目标
与1.0不同，仅仅实现业务需求已经不是2.0的技术目标了，针对完整的推荐流程，我们需要解决：
首先要实现完整的推荐流程，架构覆盖候选、排序、策略、展示、反馈和评估。
以数据为先，提炼出数据架构。实现数据对比，效果以数据为准；实现数据通道，体现反馈；实现数据落地，承接业务需求。
提供算法方便介入的方式。
既能保证业务的快速迭代和开发，又能支持高效运算。
2) 架构组成
微博推荐2.0的架构如图5所示，它不再是一个个独立的系统，也不是会让开发人员使用不同的技术解决相似的问题。这个架构图主要包括几个部分的内容：
应用层：主要承担推荐策略以及展现方面的工作，其特点在于充分发挥脚本语言的特点响应迭代需求。大部分的推荐内容经过排序之后已经可以展示了，但是由于前端产品策略的设定需要融合、删选以及重排操作，需要这一层来完成，在技术层面属于IO密集型的。在技术选型上，早期在原有apache＋mod_python基础上进行了框架开发产生了common_recom_frame。该框架面向的是二次开发者，基于此框架可以很好的实现推荐业务流程。该框架的核心思想是提炼出project、work以及data的三层interface，project针对每一个推荐项目，work针对每个推荐项目中不同推荐方法，而data则是管理下游数据的访问方法。同时，设定了两个规范：一个是统一了推荐接口，无论是用户、内容还是垂直业务；另一个是屏蔽了不同协议数据库访问方法，极大提高了开发效率。common_recom_frame框架的诞生基本上解决了产品的各种推荐策略需求，走在了产品的前面。
通过本周的阅读，使我进一步了解了新浪微博推荐系统的演变，对架构有了更深的理解。
革命尚未成功，同志仍需努力！
文章地址：
https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=209199498&idx=1&sn=12556bfc94311a0a33d67d361f6237af&scene=21#wechat_redirect