创业初期技能架构选型思考，那些年我们趟过的坑，云做事与三方做事利用心得；
O2O型互联网创业公司，重线下团队技能型公司，技能架构优化之路，分享我们大家车是如何做做事拆分、如何做做事化、如何做SOA、如何做DB慢SQL优化等；
大家车HTTP做事管理框架先容干系利用履历分享；
大家车业务平台技能架构方案；
大家车是由一帮百度兄弟们，于 2014年4月成立，作为二手车C2C模式创始者，以及范例的O2O二手车互联网电商企业， 创业两年多，目前业务范围已经覆盖全国数十个城市了，今年年底将覆盖到过百城市。
我们业务平台卖力全部核心业务系统研发事情，包括：CRM系统、发布系统、编辑系统、评估系统、发卖系统，金融支付等业务系统，承担大家车所有线下业务团队收车、卖车等核心环节技能支持！
好了，接下来，就进入到本日的第一个话题，分享下我们创业初期的技能架构和技能选型思考。
创业初期技能架构选型思考
为了快速开拓迭代，初期大家车业务平台所有做事全部基于LNMP进行搭建，从前到后一套系统，2台云主机机器，非常大略清晰，V 0.1版本架构如下图所示：
从上图可以看出创业初期我们的V0.1版本的技能架构非常大略，紧张基于一下几点考虑：
研发资源的限定，我们必须集中精力做最主要的事情，业务需求知足是第一位的；
产品快速迭代的须要，创业初期全体技能团队技能能力成熟度不高，因此我们更是方向大略、清晰、研发闇练度高的技能框架；
初期业务规模较小，技能架构需求较低，大略框架完备可以知足业务需求，适宜业务需求的架构便是好架构；
轻量级LNMP框架，选择足够大略灵巧的PHP CI框架， 云MySQL RDS做事，大略易上手，运维支配本钱非常低，大大节省了我们运维本钱，以及开拓职员的学习本钱；
为了能够快速搭建做事把创业项目搞上线，我们之前一贯坚持的几个原则也跟大家分享下：
大量利用云做事，包括：虚拟机、DB、MQ中间件、Redis等根本做事，大大降落了这些技能能力哀求高的根本主件、存储做事、中间件等做事的支配运维代价；实在便是：费钱大班事，费钱买韶光，费钱买研发能力；
大量利用第三方收费做事，以代价换韶光，例如：Teambition做事、BDP报表做事、ODPS数据管理、图片存储做事、语音通话做事等等；
权衡自研系统与三方采购系统代价，对付非核心业务系统，如果能通过采购知足需求，就快速采购做事，运用到一线业务中去，例如：HR系统、OA系统、培训系统、云报销系统、事情流引擎等等；
拥抱开源，GitHub是个金矿，值得每一位创业者去挖掘，去创造自己的需求，实在很多同行已经做了我们要做的根本研发事情；
O2O创业项目，线下业务系统是第一位的，所有资源”all in” 去提升线下团队事情效率，优化线下业务系统流程，提升线索转化漏斗，提高转化率；
低频冷门电商业务，口碑推广，营销推广，广告投放，SEM等都是须要风雅运营的，是流量运营最主要的几个关键点；
虽然我们坚持了上面提到的很多原则，不经意间我们还是踩了很多坑，例如：
云做事不靠谱，出问题造成雪崩，导致全体站点不可用。这块我的履历是不能把全体站点的死活寄托在别人手中，一定要多给自己留个B操持，容灾方案不管是公司发展到哪一步都须要的；云做事作为根本做事在做架构支配时，一定要多考虑几家互为容灾备份；
第三方做事在利用时，一定要与自己业务做事解耦，能大略封装一个proxy代理层那就最好了，避免直接嵌套第三方SDK到业务代码中，这样就相称于跟第三方捆绑在一条船上了，友情的小船说翻就翻啊；
核心系统容灾，核心系统在选择第三方做事时，一定要多挑选几个互助伙伴，系统架构上，最好能支持容灾切换，在一个第三方做事出问题时，能够快速进行切换，避免将核心系统死活权节制到第三方做事上去。例如我们大家车是一个重电销型公司，呼叫中央便是我们的核心，这套系统之前我们设计初期就仅仅只支持一家供应商，导致后面只要互助伙伴出问题，我们就随着挂了，非常非常的被动；真是不怕神一样的对手，就怕猪一样的队友啊！
重视DB设计，这个问题，可能在初期大家以为MySQL DB数据库表可以随便设计，表的字段个数，字段类型都影响不大，实在初期严格把关DB设计，后期就会少填很多坑，我们曾经有个大json_data字段，历史缘故原由设计不友好，导致我们花了2年韶光才把这个字段拆掉，真的是非常痛楚的经历；
大家车业务平台技能架构优化之路
随着我们业务不断发展，线下团队涌现了爆炸性的增长，发卖、评估师、客服职员等都增长不止一个量级，我们的车辆数、订单量、客服量等都是飞速增长，同时由于前期紧张关注产品需求，而对技能架构的优化事情相对滞后，导致这个阶段我们业务系统问题不断，这使得我们陷入了非常被动的局势。
这种背景下，我们意识到必须要缓一缓业务需求开拓了，不能再一贯堆代码了，我们须要进行重构须要梳理我们之前的系统架构，因此这才有了我们全面梳理大家车业务系统架构与系统重构这项事情，希望重点从技能架构合理性上去梳理现有系统！
转头大家可以反不雅观当时这个阶段我们的技能架构，我叫它为V0.2版本架构，如下图所示：
相对付1年前的V0.1版技能架构，此时全体业务端架构，做了部分系统拆分，但是这种拆分仅仅是代码层面的复制，重新创建出了很多业务模块，而真正的底层DB、数据库表、缓存等都还是未进行拆分的；
由于所有业务都利用一个业务DB库，因此DB成了全体业务的单点与雷区，随时可能被引爆，同时由于业务繁芜度的不断增大，DB慢查询也不断呈现，DB连接数、CPU、IOPS等核心资源都涌现了竞争与争抢，只要一个业务系统出问题，则所有做事都将受影响，涌现雪崩效应，正是由于这些问题使得我们业务进展越来越困难！
在启动做事架构优化项目之前，我们首先从如下两个方面进行梳理，全面诊断我们系统架构存在的问题：
1、流程规范与运维支配问题梳理：
全部做事支配在2台云主机，高度耦合，相互影响，资源竞争；
发布办法原始，svn check、scp覆盖；
回滚流程与工具缺失落，碰着问题回滚未便利、回滚不完备；
上线流程不规范，无通报干系机制、无回滚预案；
上线后回归验证方法不全面，不易确定功能是否完全；
2、做事耦合与做事拆分梳理：
所有项目copy自car_publish这个项目，大量冗余代码，框架利用不纯净；
通用库、工具、类未能复用，未提取支配到统一路径独立支配掩护；
API分层逻辑不严格，跨层、跃层调用征象明显，业务调用出口分歧一，不便于后续掩护；
项目耦合太紧密，未按功能进行做事化拆分，做事调用关系混乱，难以管理；
Cache层缺失落，短缺核心逻辑缓存加速，系统有时相应缓慢；
DB数据库耦合严重，未按业务独立拆分，部分字段设计不合理包含大JSON、长字段、慢查询；
日志打印不规范，关键路径日志缺失落，日志文件切分与清理机制短缺
接口级别监控短缺，超时、流量变革等业务级别监控短缺；
为理解决上面剖析的问题，我们从如下几个方面重点跟进，对大家车业务平台进行有史一来最大的一次优化重构，涉及到：做事拆分、运维支配流程优化、做事监控、DB拆分、慢SQL 优化、同步转异步等事变。
1、做事拆分
从上面剖析可以看出，现有系统最大问题，便是各模块之间耦合太高，模块之间依赖太重，因此我们首先启动的项目，便是做事拆分，从做事支配上物理拆分开，避免一个模块出问题造玉成部业务系统雪崩。
做事拆分的核心原则如下：
各模块Git代码层面独立管理与掩护
线上独立SLB、独立支配、独立运维
DB层面数据隔离，独立从库
通用功能抽取到API层
核心业务逻辑增加cache层
通过以上的拆分事情，我们的做事支配架构变成如下图所示，各个模块独立支配，通过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规范如下：
所有数据库的DDL操作全部收回，由OP统一管理；
每张表/视图要有注释（comment），格式为 模块|用场|卖力人|创建日期 ，例如：贷款|记录贷款用户身份证号码|张三|2016-03-25；
每个字段要有注释（comment），格式为 用场|卖力人|创建日期 ， 例如：记录用户性别@1:男@0:女@2:未知|李四|2016-03-25；
每张表三个必加字段，id （自动增长）， create_time ， update_time 用作存储主键，记录创建韶光，记录更新韶光 ， 这三个字段由OP掩护，RD无需处理；
有逻辑删除需求的表，可选增加delete_flag字段（int类型，默认值为0），用来标识字段是否被逻辑删除；
收回RD的delete权限，所有数据不能做物理删除（逻辑上删除的需求可以通过flag标签的办法来处理）；
字段来源须要解释，来自哪张表的那个字段，例如：记录车辆ID，#取自cp_used_car.car_id|李四|2016-03-25；
如果字段为列举类型，或普通数据类型当做列举利用，须要列举列举范围并解释每个列举值的含义，例如：记录用户性别，#系统根据用户身份证号码判断@1:男@0:女@2:未知|李四|2016-03-25 （ | 用来分割不同项目 ， # 用来标识数据来源 ，@ 用来分割多个列举 ，: 用来分割列举名称和值 ， 正常的描述中不要包含 | # @ :）
3、DB拆分：
由于前期业务相对大略，所有业务数据全部集中存放在一个DB里面，这样导致主要数据与普通日志数据都混在一个库中，各业务模块数据也全部落在一个库中，导致业务主库压力过大，随时可能由于一条SQL导致的DB问题，将全体大家车业务平台都给拖垮，因此DB拆分对付我们来说，也迫不及待。
我们实行DB拆分的核心原则如下：
各实体分库分表设计
DB主从拆分
数据加密杜绝明文存储
表与DB设计：必须遵照大家车DB设计规范与schema设计规范
索引设计：合理利用索引，杜绝滥用索引
为了能够更好的兼容之前的系统，做到平滑迁移，减少对业务系统的影响，在做DB拆分时，我们首先对业务系统进行实体拆分，再抽取API，对付业务方只须要将之前SQL查询办法迁移到API调用即可。
基于大家车业务实际场景，我们将之前的DB库拆分为如下实体：
Json_data 数据拆分 （办理DB 中json_data字段内容过大造成性能问题而拆分）
Car 实体抽取
User 实体抽取
Order 实体抽取
Clue 实体抽取
对付我们最核心的car车辆实体拆分，基本是将之前主库中一个核心表与json_data全部重新拆开设计的，由原来的一张表扩展到如下图所示的实体设计：
大家车做事化与SOA架构
一、做事化与SOA架构：
在我们做完做事支配架构拆分后，做事化与SOA架构方案实在已经排上了日程，我们做做事化与SOA架构紧张出于以下考虑：
1、业务平台视角
多样的需求直达 （业务端各种系统需求的知足）
同等的用户体验 （用户利用与行为习气的延续，减少培训本钱）
快速迭代 （各子系统、业务线只关注自有特性开拓、专人专事，避免“重复造轮子”）
资源的最有效利用 （便于人力资源、软硬件资源的高效共用与复用）
系统稳定性与做事质量的提升
问题避免与定位、办理速率的提升
2、公司全局视角
SOA与做事化架构的探索
公司级做事化框架的试点与运用
技能积累与沉淀的须要，研发职员技能提升的必由之路
打造高效O2O线上、线下平台的基石
提升研发效率、降落研发本钱的利剑
大家车做事化架构设计的核心指标如下表所示：
对付大家车来说，做事化架构是必行之路，前期的高度耦合的技能架构，已经在很大程度上制约全体公司业务的发展，对付产品需求，相应速率越来越慢，需求堆积越来越多，业务抱怨也越来越大！
因此我们对现有技能团队做了大略的组织架构调度，单独抽取精干力量，搭建专门卖力做事化的根本架构团队，开始启动人人车做事化架构之路，我们紧张从如下几个方面动手开展事情的：
现有系统功能划分与子系统梳理；
DB层拆分：各子系统DB独立，解耦降落依赖；
所有子系统、运用间的交互都要通过做事的办法来进行，不许可其他办法如：读库、同步脚步、搭建私服、跨层调用等；
所有子系统、运用，都以做事的办法将其数据与功能开放出来，通过API的形式供应访问；
做事的实现办法，初期以现有的HTTP协议为准，后续扩展到RPC、自定义协议等；
通过上面这一系列的优化重构，大家车业务平台技能架构终于站到了 V1.0版本，如下图所示：
从上图我们可以看到，我们的V1.0版本系统架构，基本达到如下效果：
做事已经完备拆分开，模块化与组件化也初步建立；
产出多个根本做事如：基于zookeeper的通用配置管理做事、通用反作弊做事、通用验证码做事等；
产出一批实行规范：通用缺点码规范、通用日志管理规范、MySQL规范、PHP编码规范等；
对付一些通用库与通用配置，也完成拆分，单独通过Git项目进行管理，创建comm libs， comm configs等多个通用配置与代码库。
可以说这一阶段，是我们大家车业务研发团队最困难的阶段，同样也是大家收成最大的阶段，从零开始，我们全程见证了自己的做事，从开始的混乱不堪，逐步变成规范与稳定，每一步拆分，每一个优化，实在都凝聚着所有业务平台研发同学的无限心血！
通过做事化干系项目的推进，我们在项目研发过程中，创造之前的研发流程与研发思路也须要进行调度与转变，紧张表现在如下几点：
转变须要办理的紧张问题
从大略“堆代码”实现业务需求，到模块化开拓“堆积木”知足需求；
从大略代码copy，到模块做事化与根本库沉淀，便于后续各种系统快速开拓；
转变的关键点
通用流程业务的抽象；
核心流程的拆分与解耦 （做事、子系统、模块级别拆分）；
做事的可定制 -> SAAS；
做事的可插拔 -> SOA；
二、大家车HTTP微做事管理框架：
在做做事化过程中，我们基于实体拆分，抽取了多个实体API做事，为了能够统一管理这些HTTP API，我们提取了统一的做事接入层，对我们所有http-api进行管理，通过统一的微做事管理框架，实现如下核心功能：
统一的API接入层：所有业务实体拆分后对应API全部接入到做事管理框架，实现对外接口统一，对内统一管理；
统一的权限管理与鉴权：可以实现多种API访问的权限管理，如：jwt、OAuth 2.0、IP白名单机制等等；
统一的API剖析与管理：通过WEB上实现做事注册，大略配置下，即可实现做事路由、API剖析、流量掌握、做事容灾、failover等通用功能；
统一的API监控与统计：统一实施qps统计、日志、监控、openfalcon打通上报数据等功能；
采取Nginx+lua的模式，功能模块采取lua可灵巧扩展，基于Nginx实现达到高性能与高可靠，在最上层实现功能需求，减少对业务的侵入与性能的损耗；
大家车微做事管理框架，架构图如下：
大家车业务平台微做事管理框架，基于开源OpenResty框架进行搭建，通过Lua脚本进行功能扩展，实现个性化需求，所有 HTTP要求调用全部通过微做事管理框架，由框架进行路由、鉴权等功能；
由于微做事管理的要求都是无状态的HTTP要求，因此在微做事框架层面可以灵巧的扩展，避免单点问题。对付一些核心业务，我们乃至可以灵巧的从物理层面独立支配微做事管理框架，从而隔离各个核心模块之间的相互影响。
三、大家车V2.0版本架构：
虽然大家车业务平台V1.0的架构，阶段性的知足了快速发展的业务需求，但是从技能架构角度看，还是存在诸多问题的，例如：
跨层调用大量存在；
API化不足彻底；
DB拆分仍不完全；
HTTP做事缺少统一管理，短缺统一的做事管理框架；
对付HTTP做事所有模块鉴权、安全、监控等都有大量重复事情。
因此，在2016年上半年我们花了大概小半年的韶光，通过进行上面提到的的SOA与做事化，HTTP api统一接入层的加入， 微做事管理框架的加入等一系列事情，终于将大家车业务平台技能架构再次往前推进一步到V2.0版架构，V2.0架构图如下所示：
大家车业务平台技能架构方案
对付下一步大家车业务平台技能架构的走向，总体方案如下图所示：
概括的讲，我们将重点关注做事稳定性、异地容灾、数据存储隔离、根本做事组件化、通用业务模块化、持续集成、运维与安全协同等方面，重点跟进如下几点：
根本支撑项目做事化与组件化：重点跟进呼叫平台化、派单做事化、CRM平台化、配置做事化、反作弊通用做事、验证码做事化等根本业务支撑项目；
根本运维与安全：协同OP一起构建更加方便灵巧的运维安全体系，对全体大家车业务平台所有做事进行安全护航；
持续集成支撑：协同QA团队一起打造从Git提交代码开始的自动化流程，包括：自动化测试，自动化发布，自动化回归验证等核心指标；
前端架构分离与做事化：协同FE团队一起打造做事化的前端架构，彻底做到前后端分离，真正实现前后端数据隔离，进一步打造大家车自己的前端开拓组件和框架；
数据存储隔离：协同DBA团队一起构建大家车业务系统数据访问层，对付底层DB真正做到业务隔离与上层透明，增强DB数据安全性；
异地容灾支撑系统：基于各家云做事供应商，构建大家车自有资源定位层，实施各云做事商之间灾备，同时通过自建proxy做事办法，实现自建做事与云做事之间的灾备功能；
做事质量评价体系建立：基于现有的业务系统，构建统一的做事质量评价体系，能够实现各做事毛病管理、稳定性度量、稳定性评价指标统一监控等功能；
作者先容
徐章健，南开大学打算机软件与理论硕士研究生毕业，2015年加入大家车，担当业务平台总架构师，总体卖力业务平台的架构及技能方案，目前重点推进大家车业务平台做事化、SOA、业务做事平台化、数据平台化等根本项目研发管理事情；徐章健同学拥有多年互联网研发管理事情，历任百度ksarch核心研发工程师，360搜索onebox组架构师，美团INF根本架构组架构师。多年来专注于根本架构方面的研究，对付大规模web架构、搜索架构算法、大规模集群根本举动步伐培植，都有一定的见地； 对付高并发、大流量分布式做事、RPC框架、做事管理、做事SOA化等都有丰富的实战履历，对项目管理、团队培植、人才培养等也都颇为善于！
