此次分享全面回顾人人车业务平台技术架构发展之路，重点分享如下内容：

创业初期技术架构选型思考，那些年我们趟过的坑，云服务与三方服务使用心得；

O2O型互联网创业公司，重线下团队技术型公司，技术架构优化之路，分享我们人人车是如何做服务拆分、如何做服务化、如何做SOA、如何做DB慢SQL优化等；

人人车HTTP服务管理框架介绍相关使用经验分享；

人人车业务平台技术架构规划；

徐章健，南开大学计算机软件与理论硕士研究生毕业，年加入人人车，担任业务平台总架构师，总体负责业务平台的架构及技术规划，目前重点推进人人车业务平台服务化、SOA、业务服务平台化、数据平台化等基础项目研发管理工作。拥有多年互联网研发管理工作，历任百度ksarch核心研发工程师，搜索onebox组架构师，美团INF基础架构组架构师。

创业初期技术架构选型思考

为了快速开发迭代，初期人人车业务平台所有服务全部基于LNMP进行搭建，从前到后一套系统，2台云主机机器，非常简单清晰，V0.1版本架构如下图所示：

从上图可以看出创业初期我们的V0.1版本的技术架构非常简单，主要基于一下几点考虑：

研发资源的限制，我们必须集中精力做最重要的事情，业务需求满足是第一位的；

产品快速迭代的需要，创业初期整个技术团队技术能力成熟度不高，因此我们更是倾向简单、清晰、研发熟练度高的技术框架；

初期业务规模较小，技术架构需求较低，简单框架完全可以满足业务需求，适合业务需求的架构就是好架构；

轻量级LNMP框架，选择足够简单灵活的PHPCI框架，云MySQLRDS服务，简单易上手，运维部署成本非常低，大大节省了我们运维成本，以及开发人员的学习成本；

为了能够快速搭建服务把创业项目搞上线，我们之前一直坚持的几个原则也跟大家分享下：

大量使用云服务，包括：虚拟机、DB、MQ中间件、Redis等基础服务，大大降低了这些技术能力要求高的基础主件、存储服务、消息中间件等服务的部署运维代价；其实就是：花钱买服务，花钱买时间，花钱买研发能力；

大量使用第三方收费服务，以代价换时间，例如：Teambition服务、BDP报表服务、ODPS数据管理、图片存储服务、语音通话服务等等；

权衡自研系统与三方采购系统代价，对于非核心业务系统，如果能通过采购满足需求，就快速采购服务，应用到一线业务中去，例如：HR系统、OA系统、培训系统、云报销系统、工作流引擎等等；

拥抱开源，GitHub是个金矿，值得每一位创业者去挖掘，去发现自己的需求，其实很多同行已经做了我们要做的基础研发事情；

O2O创业项目，线下业务系统是第一位的，所有资源”allin”去提升线下团队工作效率，优化线下业务系统流程，提升线索转化漏斗，提高转化率；

低频冷门电商业务，口碑推广，营销推广，广告投放，SEM等都是需要精细运营的，是流量运营最重要的几个关键点；

虽然我们坚持了上面提到的很多原则，不经意间我们还是踩了很多坑，例如：

云服务不靠谱，出问题造成雪崩，导致整个站点不可用。这块我的经验是不能把整个站点的生死寄托在别人手中，一定要多给自己留个B计划，容灾方案不管是公司发展到哪一步都需要的；云服务作为基础服务在做架构部署时，一定要多考虑几家互为容灾备份；

第三方服务在使用时，一定要与自己业务服务解耦，能简单封装一个proxy代理层那就最好了，避免直接嵌套第三方SDK到业务代码中，这样就相当于跟第三方捆绑在一条船上了，友谊的小船说翻就翻啊；

核心系统容灾，核心系统在选择第三方服务时，一定要多挑选几个合作伙伴，系统架构上，最好能支持容灾切换，在一个第三方服务出问题时，能够快速进行切换，避免将核心系统生死权掌握到第三方服务上去。例如我们人人车是一个重电销型公司，呼叫中心就是我们的核心，这套系统之前我们设计初期就仅仅只支持一家供应商，导致后面只要合作伙伴出问题，我们就跟着挂了，非常非常的被动；真是不怕神一样的对手，就怕猪一样的队友啊！

重视DB设计，这个问题，可能在初期大家觉得MySQLDB数据库表可以随便设计，表的字段个数，字段类型都影响不大，其实初期严格把关DB设计，后期就会少填很多坑，我们曾经有个大json_data字段，历史原因设计不友好，导致我们花了2年时间才把这个字段拆掉，真的是非常痛苦的经历；

业务平台技术架构优化之路

随着我们业务不断发展，线下团队出现了爆炸性的增长，销售、评估师、客服人员等都增长不止一个量级，我们的车辆数、订单量、客服量等都是飞速增长，同时由于前期主要







































北京中科医院是假的吗
青少年白癜风爱心救助

转载请注明原文网址：http://www.coolofsoul.com/phptx/17402.html