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

点击下方“ 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），程序员的终身学习网站已上线！

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

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

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

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

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

最近在准备面试，为大家准备一份2024最新最全Java学习路线一条龙