正文
一直在打“遭遇战”
2017 年运满满和货车帮合并后成立满帮集团，整个集团不论是业务体系还是技术体系都在飞速发展。为了更好的为司机和货主服务，集团各个业务、团队开始融合。融合的过程中，业务上既要满足不停歇的新业务需求，还要不断地升级系统以确保稳定性。合并之后和货车帮的技术团队很好的配合一起来完成这件事是一个挑战。结果只用了 3 个月就实现了系统融合并上线，双方团队的匠心精神充分展现。
最开始运满满的系统架构设计比较简单：单体应用，一个 war 包包含了所有服务端接口，没有做服务化拆分，各模块严重耦合。随着业务量快速增长，在高峰时段系统访问量快速攀升，系统不断出现问题甚至宕机，很难诊断出问题在哪里。后来启动了服务化拆分、中心化建设。同时技术架构上开始大量使用缓存，以及数据库读写分离。App 重构项目、安全攻坚项目、运维自动化项目、Docker 化项目、稳定性体系项目也紧随其后。
系统架构迭代
第一次迭代是“服务化拆分”。运满满初期是一个单体应用，随着业务的发展开始隐隐暴露出研发效率与稳定性难以权衡的痛点，为避免业务进入高速发展时期对技术团队带来的冲击，研发团队启动了服务化拆分项目。对于系统的更新，我们从研发效率与稳定性两个基本要求出发，分析关键路径，隔离业务变化与资源体量，整体规划面向分布式系统的全链路监控。从系统复杂度、服务分级，以及业务领域对团队配合度的要求这几个方面，对团队进行盘点、重组和扩充。这个过程虽然花了很多时间与精力去分析系统，洞察团队，但事实证明这为后续的工作奠定了坚实的基础。
第二次迭代是“稳定性保障体系与业务服务中台”。在运满满系统全量服务化后，研发效率、性能、稳定性得到了巨大的提升，业务也在这个阶段进入了高速爆发期。然而，随着服务化大幅增加了系统复杂度，线上故障的定位难度与恢复时长也随之提高。研发团队围绕着故障预演、发现、止损、定位与恢复规划并落地了统一流控熔断降级、流量调度、动态分组、自动化破坏性测试、全链路 Trace、线上变更事件流等能力，大幅降低了故障数量与恢复时长。
同样，系统复杂度的提升给研发效率也造成了不小的冲击，大量业务服务中存在相似或相同的逻辑，随着对业务领域的逐渐深入，
我们规划并逐步沉淀业务服务中台，以数据模型抽象化配置化，业务逻辑引擎化的思路，
使大量前端业务系统的共性与差异化转变为中台调用的选项参数，以及配置能力的使用。比如用户平台、货源平台、推荐排序平台。
