正文
重视DB设计
，这个问题，可能在初期大家觉得MySQL DB数据库表可以随便设计，表的字段个数，字段类型都影响不大，其实初期严格把关DB设计，后期就会少填很多坑，我们曾经有个大json_data字段，历史原因设计不友好，导致我们花了2年时间才把这个字段拆掉，真的是非常痛苦的经历；
业务平台技术架构优化之路
随着我们业务不断发展，线下团队出现了爆炸性的增长，销售、评估师、客服人员等都增长不止一个量级，我们的车辆数、订单量、客服量等都是飞速增长，同时由于前期主要关注产品需求，而对技术架构的优化工作相对滞后，导致这个阶段我们业务系统问题不断，这使得我们陷入了非常被动的局面。
这种背景下，我们意识到必须要缓一缓业务需求开发了，不能再一直堆代码了，我们需要进行重构需要梳理我们之前的系统架构，因此这才有了我们全面梳理人人车业务系统架构与系统重构这项工作，希望重点从技术架构合理性上去梳理现有系统！
回头大家可以反观当时这个阶段我们的技术架构，我叫它为V0.2版本架构，如下图所示：
![]()
相对于1年前的V0.1版技术架构，此时整个业务端架构，做了部分系统拆分，但是这种拆分仅仅是代码层面的复制，重新创建出了很多业务模块，而真正的底层DB、数据库表、缓存等都还是未进行拆分的；
由于所有业务都使用一个业务DB库，因此DB成了整个业务的单点与雷区，随时可能被引爆，同时由于业务复杂度的不断增大，DB慢查询也不断涌现，DB连接数、CPU、IOPS等核心资源都出现了竞争与争抢，只要一个业务系统出问题，则所有服务都将受影响，出现雪崩效应，正是由于这些问题使得我们业务进展越来越艰难！
在启动服务架构优化项目之前，我们首先从如下两个方面进行梳理，全面诊断我们系统架构存在的问题：
1、流程规范与运维部署问题梳理：
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；
