指数级增长背后，滴滴出行业务系统的架构升级

发布时间：2021-01-09 05:27:54 所属栏目：安全来源：网络整理

导读：《指数级增长背后，滴滴出行业务系统的架构升级》要点：本文介绍了指数级增长背后，滴滴出行业务系统的架构升级，希望对您有用。如果有疑问，可以联系我们。成立四年,估值已超260亿美元,公司指数级发展、业务爆炸式增长,在此背景下,滴滴出行业务系统的架构

相比端,API稍好一点的是,API至少在业务维度上是分开的,出租车与专车、快车是分开的两个系统,放在两个仓库里面.不过API也有一个很大的问题,业务代码没有做服务化拆分,没有model 封装,业务所有的API和后台MIS都在一个仓库里,这对系统来说是非常大的一个隐患.

该如何入手?

现状看上去很糟糕,要仔细思考才能入手.最基本的思路是把所有事情分类,就像整理自己家里一样,无论多乱,我们要做的事情就是将东西分门别类放好.因此,最关键的是要了解到底哪些东西应该放在一起,我们用颜色来比喻模块或者代码的归属,核心问题就变成这些模块到底是什么颜色.我们的思路是,先从前面,也就是从用户入口进行拆分,要先保证所有的模块是足够内聚的,由统一的团队负责.比如,出租车业务线可以完全控制自己的代码,能够写自己的客户端,也能够写自己的Web App,最终只是通过一些工程构建手段将多个业务整合起来变成一个完整的端.

做到这一点之后,所有的业务迭代问题就迎刃而解了,因为业务间已经没有依赖和耦合了.这一步完成之后做的就是重新梳理业务,让业务根据自己模型特点进行一些重构.

最开始的时候,我们考虑的是怎么做代码治理和模块下沉.代码治理本质上就是把各种模块进行染色、再把它们归类的过程.代码治理最难的事情在于消除错综复杂的依赖.到底怎么做才对呢?

首先,一定要把不同模块的代码放在不同仓库里面,使得模块能够物理上隔离.特别是Java、Obj-C这些静态编译的语言,一旦把代码仓库隔离就完全没有办法直接对其他模块产生依赖,至少绝对不会再出现循环依赖.
再者,就看如何把循环依赖通过一些间接层隔离开,比如通过抽象接口隔离开,一点一点把代码拆到不同仓库.
最后,有了这样一个简单的拆分之后,就需要考虑怎么让模块能独立的开发、测试、上线.独立的流程一旦独立起来,就意味着拆分基本上成功了.

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

2/7

首页

尾页