人人车业务平台从最初典型的LNMP单机单服务部署架构,发展到如今分布式服务化架构,五百多台虚拟机部署,一路走来,踩过不少坑,也遇到过不少挑战,特别是对于基于云服务进行业务开发的场景,以及从零开始服务化与SOA之路更是颇有心得,希望通过此次分享全面回顾人人车业务平台技术架构发展之路,重点分享如下内容:
人人车是由一帮百度兄弟们,于 2014年4月成立,作为二手车C2C模式首创者,以及典型的O2O二手车互联网电商企业, 创业两年多,目前业务范围已经覆盖全国数十个城市了,今年年底将覆盖到过百城市。
我们业务平台负责全部核心业务系统研发工作,包括:CRM系统、发布系统、编辑系统、评估系统、销售系统,金融支付等业务系统,承担人人车所有线下业务团队收车、卖车等核心环节技术支持!
好了,接下来,就进入到今天的第一个话题,分享下我们创业初期的技术架构和技术选型思考。
为了快速开发迭代,初期人人车业务平台所有服务全部基于LNMP进行搭建,从前到后一套系统,2台云主机机器,非常简单清晰,V 0.1版本架构如下图所示:
从上图可以看出创业初期我们的V0.1版本的技术架构非常简单,主要基于一下几点考虑:
为了能够快速搭建服务把创业项目搞上线,我们之前一直坚持的几个原则也跟大家分享下:
虽然我们坚持了上面提到的很多原则,不经意间我们还是踩了很多坑,例如:
随着我们业务不断发展,线下团队出现了爆炸性的增长,销售、评估师、客服人员等都增长不止一个量级,我们的车辆数、订单量、客服量等都是飞速增长,同时由于前期主要关注产品需求,而对技术架构的优化工作相对滞后,导致这个阶段我们业务系统问题不断,这使得我们陷入了非常被动的局面。
这种背景下,我们意识到必须要缓一缓业务需求开发了,不能再一直堆代码了,我们需要进行重构需要梳理我们之前的系统架构,因此这才有了我们全面梳理人人车业务系统架构与系统重构这项工作,希望重点从技术架构合理性上去梳理现有系统!
回头大家可以反观当时这个阶段我们的技术架构,我叫它为V0.2版本架构,如下图所示:
相对于1年前的V0.1版技术架构,此时整个业务端架构,做了部分系统拆分,但是这种拆分仅仅是代码层面的复制,重新创建出了很多业务模块,而真正的底层DB、数据库表、缓存等都还是未进行拆分的;
由于所有业务都使用一个业务DB库,因此DB成了整个业务的单点与雷区,随时可能被引爆,同时由于业务复杂度的不断增大,DB慢查询也不断涌现,DB连接数、CPU、IOPS等核心资源都出现了竞争与争抢,只要一个业务系统出问题,则所有服务都将受影响,出现雪崩效应,正是由于这些问题使得我们业务进展越来越艰难!
在启动服务架构优化项目之前,我们首先从如下两个方面进行梳理,全面诊断我们系统架构存在的问题:
1、流程规范与运维部署问题梳理:
2、服务耦合与服务拆分梳理:
为了解决上面分析的问题,我们从如下几个方面重点跟进,对人人车业务平台进行有史一来最大的一次优化重构,涉及到:服务拆分、运维部署流程优化、服务监控、DB拆分、慢SQL 优化、同步转异步等事项。
1、服务拆分
从上面分析可以看出,现有系统最大问题,就是各模块之间耦合太高,模块之间依赖太重,因此我们首先启动的项目,就是服务拆分,从服务部署上物理拆分开,避免一个模块出问题造成整个业务系统雪崩。
服务拆分的核心原则如下:
通过以上的拆分工作,我们的服务部署架构变成如下图所示,各个模块独立部署,通过SLB进行负载均衡,从物理部署上将服务拆分开来。
2、DB慢查询优化,我们从如下几个方面着手:
第一,每天通过SQL工具分析出top 5慢查询,要求研发同学必须完成优化,将慢查询优化作为例行事项,每天去review,到后期我们规范化慢SQL排查流程,从如下几个维度分析周级别慢SQL:执行耗时、扫描行数、返回行数等条件,综合分析出高优先级SQL提交给研发同学参考优化;
第二,DB读写分离,所有读请求切换到从库,同时各个服务按优先级使用不同从库,这样主库只剩下更新操作,基本可以杜绝大部分慢SQL,通过慢SQL每天分析报告可以清楚看到需要重点优化的问题SQL;
第三,对于DB轮询操作相关业务逻辑优化,调整轮询为通知机制,降低程序轮询给DB带来的压力,通过更新通知机制保证数据实时通知到业务方,再通过 API查询详细数据,减少各业务模块对主库的直接SQL查询;
第四,加强SQL审核,所有上线SQL,都必须通过SQL审核才可以到线上DB执行,之前由于业务迭代过快,线上DB运维与权限把控不够,导致研发同学直接线上操作DB, 各种慢SQL层出不穷;
第五,加强DB表设计review ,所有对线上数据库DDL相关操作,都必须通过线上DB schema审核才可执行;对于DB设计我们同样归纳出统一的 mysql DB设计规范,所有线上设计都必须满足规范才可执行!
人人车DB Schema规范如下:
3、DB拆分:
由于前期业务相对简单,所有业务数据全部集中存放在一个DB里面,这样导致重要数据与普通日志数据都混在一个库中,各业务模块数据也全部落在一个库中,导致业务主库压力过大,随时可能因为一条SQL导致的DB问题,将整个人人车业务平台都给拖垮,因此DB拆分对于我们来说,也迫在眉睫。
我们执行DB拆分的核心原则如下:
为了能够更好的兼容之前的系统,做到平滑迁移,减少对业务系统的影响,在做DB拆分时,我们首先对业务系统进行实体拆分,再抽取API,对于业务方只需要将之前SQL查询方式迁移到API调用即可。
基于人人车业务实际场景,我们将之前的DB库拆分为如下实体:
对于我们最核心的car车辆实体拆分,基本是将之前主库中一个核心表与json_data全部重新拆开设计的,由原来的一张表扩展到如下图所示的实体设计:
一、服务化与SOA架构:
在我们做完服务部署架构拆分后,服务化与SOA架构规划其实已经排上了日程,我们做服务化与SOA架构主要出于以下考虑:
1、业务平台视角
2、公司全局视角
人人车服务化架构设计的核心指标如下表所示:
对于人人车来说,服务化架构是必行之路,前期的高度耦合的技术架构,已经在很大程度上制约整个公司业务的发展,对于产品需求,响应速度越来越慢,需求堆积越来越多,业务抱怨也越来越大!
因此我们对现有技术团队做了简单的组织架构调整,单独抽取精干力量,搭建专门负责服务化的基础架构团队,开始启动人人车服务化架构之路,我们主要从如下几个方面着手开展工作的:
通过上面这一系列的优化重构,人人车业务平台技术架构终于站到了 V1.0版本,如下图所示:
从上图我们可以看到,我们的V1.0版本系统架构,基本达到如下效果:
可以说这一阶段,是我们人人车业务研发团队最艰难的阶段,同样也是大家收获最大的阶段,从零开始,我们全程见证了自己的服务,从开始的混乱不堪,逐步变成规范与稳定,每一步拆分,每一个优化,其实都凝聚着所有业务平台研发同学的无限心血!
通过服务化相关项目的推进,我们在项目研发过程中,发现之前的研发流程与研发思路也需要进行调整与转变,主要表现在如下几点:
转变需要解决的主要问题
转变的关键点
二、人人车HTTP微服务管理框架:
在做服务化过程中,我们基于实体拆分,抽取了多个实体API服务,为了能够统一管理这些HTTP API,我们提取了统一的服务接入层,对我们所有http-api进行管理,通过统一的微服务管理框架,实现如下核心功能:
人人车微服务管理框架,架构图如下:
人人车业务平台微服务管理框架,基于开源OpenResty框架进行搭建,通过Lua脚本进行功能扩展,实现个性化需求,所有 HTTP请求调用全部通过微服务管理框架,由框架进行路由、鉴权等功能;
由于微服务管理的请求都是无状态的HTTP请求,因此在微服务框架层面可以灵活的扩展,避免单点问题。对于一些核心业务,我们甚至可以灵活的从物理层面独立部署微服务管理框架,从而隔离各个核心模块之间的相互影响。
三、人人车V2.0版本架构:
虽然人人车业务平台V1.0的架构,阶段性的满足了快速发展的业务需求,但是从技术架构角度看,还是存在诸多问题的,例如:
因此,在2016年上半年我们花了大概小半年的时间,通过进行上面提到的的SOA与服务化,HTTP api统一接入层的加入, 微服务管理框架的加入等一系列工作,终于将人人车业务平台技术架构再次往前推进一步到V2.0版架构,V2.0架构图如下所示:
对于下一步人人车业务平台技术架构的走向,总体规划如下图所示:
概括的讲,我们将重点关注服务稳定性、异地容灾、数据存储隔离、基础服务组件化、通用业务模块化、持续集成、运维与安全协同等方面,重点跟进如下几点:
【作者简介:徐章健,南开大学计算机软件与理论硕士研究生毕业,2015年加入人人车,担任业务平台总架构师,总体负责业务平台的架构及技术规划,目前重点推进人人车业务平台服务化、SOA、业务服务平台化、数据平台化等基础项目研发管理工作;徐章健同学拥有多年互联网研发管理工作,历任百度ksarch核心研发工程师,360搜索onebox组架构师,美团INF基础架构组架构师。多年来专注于基础架构方面的研究,对于大规模web架构、搜索架构算法、大规模集群基础设施建设,都有一定的见解; 对于高并发、大流量分布式服务、RPC框架、服务治理、服务SOA化等都有丰富的实战经验,对项目管理、团队建设、人才培养等也都颇为擅长!】
原文来自:infoq
声明:所有来源为“聚合数据”的内容信息,未经本网许可,不得转载!如对内容有异议或投诉,请与我们联系。邮箱:marketing@think-land.com
通过企业关键词查询企业涉讼详情,如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能,它提供IP地址历史上绑定过的域名信息。
结合权威身份认证的精准人脸风险查询服务,提升人脸应用及身份认证生态的安全性。人脸风险情报库,覆盖范围广、准确性高,数据权威可靠。
全国城市和站点空气质量查询,污染物浓度及空气质量分指数、空气质量指数、首要污染物及空气质量级别、健康指引及建议采取的措施等。
输入手机号和拦截等级,查看是否是风险号码