大厂出行业务架构演进踩坑记!-技术圈

点击下方“ JavaEdge ”，选择“ 设为星标 ”

第一时间关注技术干货！

1 业务架构演进

1.1 订单系统

快速发展期，对技术团队与系统的要求：稳定性，扩展性，合理性。但系统不能突变，如何搞定“快”与“稳定性，扩展性，合理性”的过渡演进？

早期多业务（2C、2B、直营城市、下沉城市等），每个业务更适合有自己独立的订单库，方便快速试错。而现在则需要统一订单中心，提升稳定性、保证扩展性，并维持较低水平的维护成本。

1.2 经纬度检索

司机的经纬度上报与检索，是打车的业务核心之一。早期我们直接使用数据库来存储与检索经纬度，快速实现、快速迭代。如果现在还用数据库，肯定性能扛不住，所以现在则抽离了单独的服务来实现。

1.3 消息中心

早期 GPS 上报，快速实现了一套消息通道；订单推送，快速实现了一套；用户与司机聊天，快速实现了一套。现在，我们则把共性的需求抽象除了消息中心，以满足不同场景，在扩充业务场景的适合，能够复用系统。

量级不同的阶段因为对系统的需求不同，所以对应的系统架构也不会相同。发展的这几个阶段中，在业务架构设计方面还是走了一些弯路，来看咋解决的。

2 踩坑

因为业务的不同阶段对架构的要求不同，在架构迭代或者重构的过程会比较痛苦：

要完成架构升级与转型
又不能影响业务需求的开发与迭代

通过一个“订单库从分开，到订单中心合并”的例子。

2.1 第一个业务

订单系统，如何快速实现？第一个业务（打车业务），闭环了自己的订单库：

2.2 第二个业务

为了快速迭代，也闭环了自己的订单库：

2.3 第三、第四个业务（货运业务、合伙人业务）

第三个业务，第四个业务，对点不对劲了，得统一。业务三有了统一意识，尝试统一订单库，业务四有了微服务意识，尝试建立订单中心，但并不彻底。

2.4 当有订单统一展现需求

要访问多个订单库了，开始抓狂，抱怨傻X领导，为啥早期为何不统一？

下决定要统一！统一是合理的，但咋统一？

3 统一大计

3.1 数据收口

尽量减少对原业务的影响。

服务写收口，服务读收口，1年才完成订单中心的统一

3.2 服务收口

尽量支持分业务平滑过渡

3.3 旧系统下线，完成统一

参考： 编程严选网（www.javaedge.cn）

写在最后

编程严选网（www.javaedge.cn），程序员的终身学习网站已上线！

点击阅读原文，即可访问网站！

欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。

添加好友备注【技术群交流】拉你进群，更多教程资源应有尽有

关注公众号后，在后台私信：

回复 【架构师】 ，获取架构师学习资源教程
回复【面试】，获取最新最全的互联网大厂面试资料
回复【简历】，获取各种样式精美、内容丰富的简历模板
回复 【路线图】 ，获取直升Java P7技术管理的全网最全学习路线图
回复 【大数据】 ，获取Java转型大数据研发的全网最全思维导图
微信【ssshflz】私信 【副业】 ，进副业交流群
点击 【阅读原文】 ，即可访问程序员一站式学习网站

大厂出行业务架构演进踩坑记!