贝贝网：如何打造支持快速业务迭代的技术架构？

[lock522]

文 | 贝贝网 基础业务研发部总监 周亮
原文链接：http://t.cn/RyBazR1

贝贝现在叫“贝贝”。我们把“网”字去掉，这是因为我们平台上 90% 的交易量都来自移动 APP 。业务移动化，名字自然也要移动化 。

贝贝的业务从最开始单纯的特卖开始，逐渐发展出了海外购、限量购和圈儿等新业务。

技术架构中的后端支撑

首先，用户请求先到 CDN ，请求中大量的是商品图片请求，我们的图片托管于 UPYUN 。继续往下会到达 Vanish 缓存，然后到达 Nginx ， Nginx 再把请求转发给 PHP-FPM 进行处理。我们的系统每天早九点和晚九点开始抢购，因此要通过 HTTP 头来精确控制缓存。到了 PHP 应用层，我们使用了 memcached 和 Redis 作为缓存，使用 MySQL 存储数据，使用了消息队列来执行一些异步任务从而降低系统的处理时间。我们自己实现了一个简单的任务调度系统，即时跑定时或者循环任务，对这些任务会进行监控。

对电商而言，除了数据安全之前，数据的查询效率也非常重要，因为在我们的架构中，在 MySQL 之上，还有 CoreSeek 和 ElasticSearch 两个组件，主要是为了支撑复杂条件的搜索。

搜索分两种，一种是对外的搜索，主要支持网站或 APP 上的商品搜索功能；另一种是对内的搜索，电商核心是运营，这种搜索主要是为了支持运营需求，比如要开发一个活动页面，页面展示奶粉和纸尿裤这两个类别的商品并且按照销售额排序，我们就通过 CoreSeek 或 ElasticSearch 来支持这样的需求。

CoreSeek 和 ElasticSearch 都是搜索引擎， ElasticSearch 会更加优秀，支持集群、高可用以及更复杂的查询，但是学习成本和部署成本比较高，后续我们会逐渐迁移到 ElasticSearch 上。这些是构成贝贝的核心组件。

贝贝也用到了很多第三方提供的服务，比如前面提到的圈儿社交购物服务，用户可以随意地在圈儿中上传照片并发布商品，图片都会上传到 UPYUN 上。

数据库是核心的核心，非常重要而且永远是瓶颈，其他组件相对都比较容易扩展，但数据库到目前也比较难任意扩展扩展。到目前为止，我们只有一个主库，用的硬件相对比较好。主要是为了减少架构的难度，架构复杂之后，会极大的影响开发以及运维的难度。未来肯定会根据不同的业务来拆分系统以及数据库。

在前面通过 HAProxy 对流量进行切分，我们将业务分成核心业务和非核心业务。什么是核心业务？就是交易流程所涉及的业务，用户加入上到到购物车并结算，直到最后付款成功，这些是业务核心。

我们将这些请求转发到一个单独的集群上，数据库的中间件用的是 Amoeba ，这个中间件版本较老，会有一些性能上的一些器官问题让我们感觉很苦恼，我们也想做一些优化和替换。其他的请求我们会转发到另一个集群，这是我们的集群划分策略。这样划分主要是让我们在应对流量高峰的时候能更好的降级，在大促的时候，一瞬间的流量可以到平常的好几十倍，这时我们可以把周边业务的优先级降低，甚至不提供服务，但下单支付流程一定要保证是正常的。

在后端，搜索引擎需要很好的支持排序和筛选。我们最初使用的是 CoreSeek ，但是 CoreSeek 支持单机部署，扩展的性能并不是很好。后来我们逐渐转向了 ElasticSearch ，它能够很好的支持这样的集群和水平扩展，而且能通过 river 的插件来支持实时索引，同时提供了更多的强搜索方法，甚至是统计运算，当需要做排序的时候非常方便。

对社交来说，地理位置信息是很重要的因素，最新版本的 Redis 也能支持地理位置信息，但当时我们做基于地理位置的范围搜索时， Redis 还没有这样的功能，所以我们使用了 ElasticSearch 的支持地理位置信息搜索功能。不过，我们用 ElasticSearch 也遇到很多问题，如一些参数的设置。 ElasticSearch 除了刚才说 river 插件外，还有一些很好用的插件，如通过 bigdesk 插件可以看到集群里里面每个机器以及 JVM 的状况，对监控和运维很方便。

除了后端之外，对快速的业务研发而言，我们选择的是 PHP 这门比较简朴的语言。首先， PHP 语言学习成本比较低；其次，部署上线非常简单，我们通过用“ svn up ”这样的方式就可以将代码很快地上线。我们使用的是 CI 框架 2.0 版本， CI 框架已经发布了 3.0 的版，我们目前还没有迁移到 3.0 上。我们自己做了 CI 框架一些改动，引入了一些新的 Web 开发思想，如约定优于配置等，这些功能在 CI 2.0 版本里面并不支持。

其次是日志框架扩展。 PHP 的 log 输出在运营 PHP 机器上，我们需要把这些日志统一收集到一起然后对这些 log 进行处理和分析。

再次是 API 接口支持， CI 框架本身没有支持接口开发，所以我们加入了一些简单的扩展。

其他的增强包括提供系统降级的 API ，提供 slowquery 的日志等。由于我们程序员的水平不均，不能保证每个程序员的 SQL 语句都是完美的，如果一旦这个 SQL 在会存在全表扫描的情况，就会对这个业务会带来致命性的打击，甚至可能造成整个数据库宕机。鉴于之前的教训，我们对 SQL 的监控非常严格，会在 CI 里面收集 slowquery ，一旦查询时间超过了阈值，就需要进行优化。

另外，及时发现存在危险请求也非常重要，我们每天都会受到一些攻击，或者恶意访问。当我们在大促的时候，比如满 300 返现金券活动，有一些用户会来恶意套取现金券，我们组件了一个团队专门做安全方面的东西。因为 CI 并没有单元测试，所以我们也加入了一个支持单元测试的框架，这是一个开源的项目。总的来讲，随着业务的发展，框架需要进行演进，在使用成熟的框架上进行积累，然后将其公用的部门抽取出来，形成我们自己的开发框架。

技术架构使用的流程工具

贝贝在流程工具上也投入了不少，今年 4 月份之前每天上线两次代码。要支持这样的上线速度，必须通过一些自动化的方式完成，所以我们自己实现了一个流程工具，称之为“悟空”。

“悟空“支持基于 SVN 的分支与 Tag 的开发和发布，目前暂时没有支持 Git 。在贝贝，我们对 SVN 的使用非常多，一些运营和部署工具都是基于 SVN 。不过当数据量和机器数量变大了之后， SVN 也会出现一些王伦问题，所以我们在一些情况下也会使用 rsync 。我们在”悟空“中集成了 facebook 开源的 CodeReview 框架 phabricator 。 CodeReview 通过之后，程序员可以在”悟空“上直接将开发分支切换到预发布上进行验证，预发布连接是真实的线上环境，可以通过特定的方式将用户请求转发到预发布环境中。

对业务研发来讲，最让人头痛的就是变更的管理，比如数据库表结构的修改、配置参数的修改等。因为参数调整可能会导致整个系统不能用，所以我们一定要了解每个改变是基于什么原因产生的，而且每个变更一定要经过 Review 。所以，我们也开发了一个简单的工具，能够支持配置变更、紧急发布、数据库变更、变更统计报表等功能。如果程序员需要在某个数据表上增加一个字段，必须提出申请，也就是发起一个变更流程，虽然流程会更加繁琐一点，但对业务研发管控来讲，这件事情是必须做的，非常重要。

研发部门的系统监控

代码上线之后，我们从四个方面对系统进行监控：

第一是对业务数据监控。我们通过 log 方式记录数据点，然后进行统计。目前，我们除了 PHP 之外，还使用 Java 实现了一些 RMI 服务，这两者都需要对业务数据进行监控，不过两者打印日志的方法不同。我们定义了一种通用的格式，里面包含机器、进程、 Timing 和 Count 数据，然后分别实现了一个 PHP 和 Java 的日志输出模板，这里学习了亚马逊的经验。打印了 Log 后，通过 Scribe 收集到对应的中央服务上。

我们自己实现了一个组件将日志处理后将数据导入到 InfluxDB ，这是一个 Timeseries DB ，专门用于存放和统计时间序列，一淘之前开源了一个名为 OpenTSDB 的类似的系统。 InfluxDB 最近比较新，也比较轻量，直接装上就好了，不用配置 Hadoop 和 Hive 。不过 InfluxDB 还不支持集群，官方表示还在开发中，不过目前我们使用的量还比较少，经验还不够丰富。

上面的图就是用 Grafana 工具展现出来的图，这也是一个开源工具，和 InfluxDB 堪称无缝集成。在 InfluxDB 中通过一些查询语句做聚合计算，在 Grafana 就可以把图表显示出来，对业务监控来讲，很方便就知道了现在的业务是什么状况。我们也会将另一些 log 处理后放到 Hive 中存储下来，通过 HiveQL 来进行统计。

第二是对线上异常的监控。主要是通过 sentry 这个工具及时地将线上的问题通知我们，一旦有 PHP 异常抛出来 sentry 就会报警。我们经常发现一些对于空数组或者返回值没有检查造成的问题，有些是上线之前想不到的。但这个工具有一个不好的地方，如果有错误导致 PHP 进程退出了，这样的错误 sentry 就无法捕获了， PHP 只会在对应的机器上打印错误信息。

第三是应用性能监控。应用性能监控也就是 APM ，全称是 Application Performance Metrics ，我们最近接入了是听云，当然也有其他的服务，大家都可以尝试一下， APM 可以很好地反应出整个应用的概况以及对应的细节。比如上面图中有一个波峰，是存在问题的地方，下面的图这个波峰的具体分析。上面的图显示外部调用的时间太长，下面的图显示这些请求里面有多少外部调用，可以看到有一台机器上的 ElasticSearch 出现响应时间过长的问题，可以让我们清楚地了解到问题到底出在哪里。

第四是对机器状况的监控。我们使用的是比较流行的 zabbix ，能很好地收集到机器的状况，经过一些配置模板，可以把 Redis 的连接数和内存使用都监控起来。

技术之外的问题

对业务研发而言，技术之外的问题也很重要，贝贝在研发中总结出一套产品、需求、开发、测试、上线、复盘的流程，贝贝现在研发团队有 150 多人，必然会存在团队沟通和协作上的问题，所以我们做了一些管理方法上的总结。

首先，要对每个环节上的输出进行评估，质量如何，时间是否有延期，每个环节上都有对应的负责人。比如说开发的代码输出，一定要通过冒烟测试才能提交到测试人员，如果自己冒烟都通不过，提交到测试方再反馈回来就是浪费时间，也造成了整个项目进度的延后。

第二，我们实行短项目迭代。在贝贝这样的快速迭代环境里，一个比较大的项目也就一到两周，一个月的项目算是公司级的重要项目了，提到的圈儿社交业务，从开始到测试只有一个月时间，测试两周，一个半月时间就正式上线。每个阶段一定要明确负责人的权力和义务，还是以冒烟测试为例，什么时候提供用例，由谁检查，什么时候执行都需要明确。在我们的执行过程中，最重要的是复盘，项目上线后，对业务目标的达成和项目过程中的沟通和协作有什么问题。就我个人的经验而言，项目延期绝大多程度上不是技术的问题，而是相互之间的沟通和配合问题，所以每个环节上如何保持沟通顺畅就显得非常重要。

贝贝的未来之路

业务扩展之后带来的就是团队扩张，团队扩张带来的就是项目进度的把控和业务整合的把控。对技术管理而言，关键是如何保证流程是完全可控的。
针对这个问题，我们设想了一些计划：

一是服务化。对贝贝来讲，当前的系统是大一统的，所有业务都在一起，这样带来的问题是代码仓库在不断膨胀，而且速度很快，模块之间也有比较严重的耦合，不可能无限制的膨胀下去，一定要做子系统拆分和周边业务系统的拆分。

二是开发框架定制。当我们要拆分业务，将大系统拆分成独立成的系统的时候，就涉及到是不是继续沿用原来的框架，如果要用原来的框架，就要把原来的框架抽象出来，使其能支持开发新的系统，这就要进行开发框架抽象和定制。

三是关于系统发布。我们了解到阿里巴巴的发布是基于 RPM 包的，亚马逊发布时使用了一个容器性质的东西。我们也在考虑如何做打包发布，甚至自动回滚。一旦业务上线之后，集群 QPS 下降了，说明刚上线业务代码有问题，就需要做一次自动回滚。

四是调用链监控。前面提到我们可以通过现有的工具找到每个组件的调用时间，如数据库、 memcached 等组件。但是，在 PHP 中执行了多长时间，哪里存在问题，就要做 Profile 以及调用链的监控，函数的执行次数、循环次数要做一些监控。

五是业务数据监控。当前的业务数据和前几天的同时间段相比是不是正常，我们现在还没有办法实时监控，所以需要做这样的尝试。之前在亚马逊的时候会经常会提到一个词叫 order drop ，也就是订单量下降，如果订单量突然降下来，说明肯定那个环节出现了问题，这是一个非常重要的指标，所谓的业务数据，就是指这样的指标。

六是分布式数据库。主要目的是解决数据库水平扩展的问题，我们组件了一个架构团队在做这样的事情，这是一个长期才能受益的事情，但是作为一个有志于成为大公司的研发团队需要做一些类似的探索。

七是私有云。我们也会尝试研究一下，具体怎么做目前还不能确定，也许会尝试使用混合云这种方式。

八是 Hybrid APP 。前面提到了，我们的业务量 90% 来自于 APP ，也就是说主战场是 APP 上。我们会尝试 Hybrid 的方式，把 H5 打包到 APP 里面，更好的更新和迭代， APP 的版本发布，要经过长达十几天的审核时间，会影响业务的迭代。比如我们需要提前很长时间就开始规划双十一的产品迭代目标，目的就是在争取在合适的时间上线新版本，这样很受制于人。我们希望这方面可以做一些事情，能帮我们更好的实现快速业务迭代的目标。

---

本文为 UPYUN 品牌技术沙龙 “ UPYUN Open Talk ” 所产生的优质技术案例，此类内容均出自新锐、知名互联网企业的技术团队负责人&CTO 。

查看更多高质量技术专题&干货、在线申请免费流量空间请关注 UPYUN 微信公众号（又拍云）

转载请标明作者和来源，并保留原文链接：http://t.cn/RyBazR1