[智能架构系列]Buddy简单高效智能的后端架构[一]

引子

最近换了工作，时间也充裕了一些，利用休假时间和自己的空余时间对所思所学，进行归纳总结。对于自己3年来一直努力的Buddy，进行了深入的思考，其实一直以来，具体来说从04年开始就一直习惯的用PHP，到现在，这么多年的时间，很多时候自己把自己限制在了PHP所能实现的范围内，不过这个也是由时代决定的，04到现在从Web1.0到2.0，从做站开始，就一直围绕“站”这个概念来做东西，所以PHP还是足够用了，之后到了百度，还是做了PHP，作为一个开发工程师，一直在完成各个逻辑功能，功能做多了，就想自己能不能做一个框架，来让自己做事情做的更快一些呢？为此，将积累的代码进行整理，命名为buddy,它的完善随着 woshimaijia 的开源项目一并完善，一直到2011年都在做堆逻辑的事情，就想有所改变，是否应该在深入底层？后来换了部门之后发现，其实牛人真的很多，看了做PHP做到极致的 鸟哥（惠新宸，PHP开发组）及组内的其他的RD,QA同学们的能力之后，意识到自己的水平，真的是......小吐槽下，其实意识到自己的差距，那么应该做些什么来提高自己？看着各个技术达人基本都是在一些方面做到极致之后，其他的方面也跟上了，达到了高手的境界，在此特别提下2个人，@agentzh,@laruence，因为现在使用的技术都是他们开发的，一个是@agentzh的openresty项目，一个是@laruence的yaf框架。之所以是牛人，因为他们在往牛人的路上，都留下了产出，这些东西，造福了其他的人或者说其他的人可以从这里学到很多。不管是项目上的应用，还是看到他们源码之后自己的提升。说了这么多总结一句，就是有一些人有不同于他人的想法而又把这些想法实现了，这些才是值得大家记住和尊重的。

 

简单高效智能的架构是什么样的？

先上张图，通过图中来来详细的解说为什么它简单、高效、智能

 

技术选型

Nginx(OpenResty) + PHP + Mysql + Redis + Memcachd + Sphinx   + 外部的API

图中的部分，从上到下来看

第一层，Presentaion 表现层，和用户交互的部分，也可以说是请求的来源，系统的入口

第二层，API 接口层，提供对表现层的数据交互的支持，包含了主要的3部分，业务部分，公共部分和监控报警部分，右边的主要是用户的私有数据 和 公共的数据 以及一些静态的资源 

第三层，LOGIC 逻辑实现层 + Sharding，可以支持海量的数据存储，逻辑层涉及到各种的模块，外部的API接口等等，以及后端的异步模块等，模块方面主要有MatchMaker(分类器，建立对象和对象之间的关系），Searchd搜索模块（提供搜索支持），Recommender推荐器（对外提供推荐服务）还有一些统计模块和用户找回模块等...

第四层，Store 存储层，主存储使用了 Mysql,Redis

 

如何简单？

简单，我理解的简单，从技术选型来讲，就是用自己熟悉的，经过生产环境检验的可靠的技术产品.

比如：

Redis,从最近的Twitter的Timeline以及Instagram中介绍，还有之前微博也使用,充分的让大家认识到Redis的强大。

Nginx,牛逼了很多年了，但是通过OpenResty项目，让人深刻的感受到，Nginx，它真的不只是Web服务器软件。

从开源的角度来讲，主要是开源产品的技术认可度以及作者(个人/团队）是否在积极的维护。从当前用的OpenResty和Yaf来看，作者都是很积极的，更不用说Nginx和Redis的作者的了。

Yaf：最近每个一周基本有一个版本，鸟哥很给力，我昨晚报告了一个Bug，今天就修复了，发布了2.1.14版本了

OpenResty:4.29号刚刚发布的新版本，章亦春老师也很给力。

Nginx:刚刚不久前发布了1.2.0版本

Redis:看作者的Blog最近2.6RC在一直进行中，估计也不久的了

Mysql:5.5系列的版本也在不断的开发中

由于这些作者的活跃和开发，只要项目中遇到问题或者是发现Bug都可以及时的联系到他们并能得到作者的反馈，这个是亲自体验过，备受感动.

大部分底层的事情，都让牛人做了，那我们能做什么呢？关注与自己的业务逻辑，是否就是简单了？也许，这个时候，你会说，这个怎么简单了？还是需要写很多的代码，还是要考虑Sharding的问题，还是要考虑到各个模块之间的数据互通，还是需要考虑到数据结构的设计等等，这个时候Buddy就可以登场了，Buddy就是将这些技术产品及我们需要的模块都能够完全的融合进来，并将项目中的共性的部分，通过接口抽象出来，实现大部分的功能，这样您只要开发自己项目中的特殊的部分，大大的减少开发时间，那么，用Buddy，在靠谱的软件集合下面做自己的项目，省事也省心。接下来的博文中，会对架构图中每个模块部分进行详细的阐述并附上具体的代码。这里只是笔者的一种实现方式，聪明的你也许做的比笔者更好，那就开始行动吧！

 

如何高效？

高效应该如何定义？由于很多的项目都存在sharding，所以单纯的从性能来说，一个请求发送和接收需要的时间还有数据量的不同，10ms? 200ms ? 300 ms? 如何才能算高效呢？

还是可以从单机的性能测试来算，看cpu的idle及内存占用等来算？其实笔者认为，在执行的过程中，尽量用高效的语言做尽可能少的事情，这样才是高效。这里主要来show下OpenResty的评测的结果。以及章老师PPT中的一些结论。

 

具体的可以点击图片看章老师的微博中的具体的评论以及 openresty.org中的文章。

看了评测之后，看了由 Lua 粘合的Nginx生态环境 中章老师对生成环境下的介绍的，确实是感觉一个提升，可以节省很多的服务器及带宽的成本

这些是章老师的评测及相关的介绍，本次笔者所在的公司的项目中也会实践这个架构，接下来也会出一些性能的评测出来，别人说的高效，要在自己的项目中能实现，才是真的高效。

高效是对自己而言的，高效是意味着更小的投入有更高的负载能力和更好的用户体验。

 

如何智能？

智能，最近出现在很多的地方都提及，印象较深的是豆瓣的豆瓣猜首页，其中主要的是看了豆瓣的阿稳写的《智能WEB算法》里面对于智能WEB的表述，其实笔者认为智能的范围相对而言比较广，而且在于用户的体验，用户如何体会到智能？ 看到一些的站点的页面上渐渐的出现了，你可能喜欢，你可能认识，你可能想买，你关注的人也关注了某某。随着智能的普及，我们是否在初期设计的时候就从架构的角度来解决这些问题呢？从架构图中可以看到，笔者标了3个模块MatchMaker,Recommender,Searchd,Count这4个模块，主要是为了从常见的部分尝试实现智能。一下具体阐述如何通过这些模块来实现智能。

MatchMaker模块，输入2个对象，判断2个对象之间是否存在关系，并确定是否要建立关系或者解除关系。并将最终的数据放到Private/Public 存储中，具体设计是放到Redis的数据类型为List/Set的存储中，实现前端可之间读取的关系集合。也许你会说，这个之前我们是如何做的？比如说淘宝上的发布商品，你会经过4层，还有输入过程中输入勾选各种的属性，最终发布了宝贝，然后建立了宝贝和各种属性，品牌，分类等之间的关联，那我们需要做到这样细化的粒度的关联么？我们可以通过使用聚类或者分类等各种智能WEB算法来实现自动的分类么？其实笔者也在尝试中。接下来完善模块后会详细的细化模块，现在只有一些最简单的通过对象的title来进行分词并通过分词后的结果建立tag之间的关联关系的实现。其他的具体的场景根据项目中具体用到的在逐渐完善。

Recommender模块，推荐器模块，通过使用协同过滤及复合的算法来实现对具体场景的推荐，这块网上的资料也很多，还是得根据自己项目的场景来具体的选用不同的算法来实现，笔者的项目中用到的一些，主要有判断2个是否相似，用到了距离计算的一些算法，编辑距离/dice距离等。还有在开发中的，参考了Yooreeka项目中的，基于物品和基于用户的推荐等。用户的访问日志及行为日志分析也作为反馈到推荐器中，建立推荐器所有的数据。

Searchd模块，搜索模块，搜索当前项目中使用了Sphinx，之前在Solr和Sphinx中选择了Sphinx，主要的原因有：

一，Sphinx的配置和资料比较多些，国内有Coreseek项目在中文方面支持的比较多。

二，配置相对比较简单，相比于Solr而言，对于配置有张宴大侠写的文章，都比较详细。

三，当前来说够用，对于数据量在千万到上亿级别还够用。郁闷的是看源码比较吃力。主文件24k行，实在头大。

四，自动提示及统计搜索热词，以及词库的配置等，还用了一些分词模块，主要有scws,xplite

搜索结果的体验很重要，对于结果现在都是使用评分模式，现在笔者的项目中用到的还是只有一些属性的加权平均算出来的。

Count模块，统计模块，对于之前的提及基本都是通过在数据库中进行SQL，还有LOG统计得来，Buddy中的提及主要是设计了触发点，根据事件来驱动，将数据存储在redis中，之后进行计算，实现了大部分的及时的数据提及功能，主要使用了OpenResty中之间通过HTTP写redis及Log的读取后抽取并提交到接口接口进行输入的方式来统计。统计模块详细的设计在后续的文章中将有详细的描述。

 

结语

很多时候，都在使用大家认为稳妥的技术方案，好多的时候，一个Team里面其实还是有想吃螃蟹的人的，可惜最后都被和谐了，在和谐的社会里面，技术也和谐，还有什么激情？

听过很多的抱怨，也有过多个项目亲身经历，很多时候对于技术方案最终的选型都无法最终决定，为此当你有能力决定技术选型和架构的时候，是不是可以尝试下？

是否可以从全局及未来来考虑，让我们使用简单高效智能的技术解决方案，来更快，更好的将项目推进，并能够通过技术节约公司的成本。

也许这样，就多能撑过一个冬天，也许这样，你会自豪的说，其实我也是个爱吃螃蟹的人！