1 业务架构演进
1.1 订单系统
快速发展期，对技术团队与系统的要求：稳定性，扩展性，合理性。但系统不能突变，如何搞定“快”与“稳定性，扩展性，合理性”的过渡演进？
早期多业务（2C、2B、直营城市、下沉城市等），每个业务更适合有自己独立的订单库，方便快速试错。而现在则需要统一订单中心，提升稳定性、保证扩展性，并维持较低水平的维护成本。
1.2 经纬度检索
司机的经纬度上报与检索，是打车的业务核心之一。早期我们直接使用数据库来存储与检索经纬度，快速实现、快速迭代。如果现在还用数据库，肯定性能扛不住，所以现在则抽离了单独的服务来实现。
1.3 消息中心
早期 GPS 上报，快速实现了一套消息通道；订单推送，快速实现了一套；用户与司机聊天，快速实现了一套。现在，我们则把共性的需求抽象除了消息中心，以满足不同场景，在扩充业务场景的适合，能够复用系统。
量级不同的阶段因为对系统的需求不同，所以对应的系统架构也不会相同。发展的这几个阶段中，在业务架构设计方面还是走了一些弯路，来看咋解决的。
2 踩坑
因为业务的不同阶段对架构的要求不同，在架构迭代或者重构的过程会比较痛苦：
- 要完成架构升级与转型
- 又不能影响业务需求的开发与迭代
通过一个“订单库从分开，到订单中心合并”的例子。
2.1 第一个业务
订单系统，如何快速实现？第一个业务（打车业务），闭环了自己的订单库：
2.2 第二个业务
为了快速迭代，也闭环了自己的订单库：
2.3 第三、第四个业务（货运业务、合伙人业务）
第三个业务，第四个业务，对点不对劲了，得统一。业务三有了统一意识，尝试统一订单库，业务四有了微服务意识，尝试建立订单中心，但并不彻底。
2.4 当有订单统一展现需求
要访问多个订单库了，开始抓狂，抱怨傻领导，为啥早期为何不统一？
下决定要统一！统一是合理的，但咋统一？
3 统一大计
3.1 数据收口
尽量减少对原业务的影响。
服务写收口，服务读收口，1年才完成订单中心的统一
3.2 服务收口
尽量支持分业务平滑过渡
3.3 旧系统下线，完成统一
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都国企技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
参考：
- 编程严选网
