设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 创业者 手机 数据
当前位置: 首页 > 服务器 > 安全 > 正文

指数级增长背后,滴滴出行业务系统的架构升级(2)

发布时间:2021-01-08 09:06 所属栏目:53 来源:网络整理
导读:相比端,API稍好一点的是,API至少在业务维度上是分开的,出租车与专车、快车是分开的两个系统,放在两个仓库里面.不过API也有一个很大的问题,业务代码没有做服务化拆分,没有model 封装,业务所有的API和后台MIS都在一个

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

该如何入手?

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

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

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

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

模块下沉与代码治理息息相关.如果只是要求把所有代码拆分,而没有合适的拆分方法,这件事情是无法推进下去的.对于程序员来说,他们内心总有一种冲动想做有意思的事情,比如封装一个很有意思的模块给更多程序员用.大家并非不想做封装,只是如果封装并共享出来的代价太大,就会影响大家的热情.

模块下沉是一种机制,一方面我们应该鼓励,另一方面还应该让大家发现这是一件不得不做的事情.如果仅仅对内公开模块列表让大家自由选择,达不到模块下沉的目的.因为人都很懒,不想思考太多,只想尽快把事情完成,大家往往倾向于复制粘贴,也不愿意额外花时间做下沉.

怎么办呢?我们会给所有业务提供一个统一的SDK,里面包含所有能用的组件,大家必须使用它进行开发.如果业务模块稳定了并且比较通用,我们有工具和相应的简单机制把业务模块下沉下来,变成SDK的一部分,长期下去SDK会越来越大,只要SDK里做好分类和规划,上层就会越来越轻,我们可以真正专注于业务逻辑开发.

除了上面这些,最核心的一点在于,一定要把所有业务都做到“无状态”和“异步化”.

“无状态”这个概念在服务端比较容易理解.一般我们倾向于把各种业务做到无状态,这样容易做水平扩展.在客户端也是一个道理,也要考虑横向扩展性.一个简单的框架往往提供一些最基础的控件,比如按纽、列表,这些都不会耦合任何业务逻辑,所以很容易使用.

但是当业务做起来,大家习惯将一些状态放到业务控件里面,这在一定程度上方便了,但是一旦需要将业务进行重构或者进行模块化下沉的时候,就造成了非常大的困难.例如,一个模块如果大量通过全局变量或单例跟上下游耦合,那么这个模块就很难复用和重构,这些全局变量或单例就是状态.

所以,我们在客户端也提出使用“无状态”的方式,把存储的信息都放到外面.后面我会提到到底应该怎么样去做.

“异步化”也是解耦的方式.服务端的RPC类似于函数调用,如果参数变了,实现和调用的双方都要做改变,这很不透明,也不能够渐进式上线.我们用订阅/发布的模式对 RPC进行解耦,要求所有接口都要异步返回.

在客户端也是这样,比如做数据的缓存,想优化网络,我们不能够期待这个函数是一个同步函数,一定用回调的方式接受所有参数.所以做设计的时候,只要是有可能发生网络请求或者访问磁盘,在客户端也尽量异步请求数据.

刚刚讲的都是相对比较抽象的内容,接下来会说一下滴滴的业务形态本身.

滴滴是一个出行的平台,涵盖的是整个出行领域所有的出行需求.大家出行到底想要什么?就是到达自己想去的地方.实际上,我们的模型可以做得非常抽象和简单.比如,我想要打快车去机场,我就是一个需求方,我的需求会发到很多服务者那里去,服务者会根据特征进行一些匹配.

最基本的特征是服务能力,如果服务者能够开快车并通过了能力验证,这个需求就有可能发给他.如果开出租车的也有能力开快车,但是他还没有在平台上验证这个能力,就只能开出租车.一个人可以验证很多服务,白天可以开快车,晚上可以做代驾,做不同的事.

服务和需求的匹配是通过计价模型和匹配策略来实现的.发送需求的时候需要选择计价模型和车的类型.快车和专车服务过程大同小异,但是价格差别很明显,专车价格会贵很多.通过匹配策略可以实现各种需求的匹配.

例如,选择了拼车,这个需求会尽量匹配已经有拼友和顺路的车.如果选择专车,可以要求这辆车在指定时间来接人,这时候匹配策略会优化倾向这种方式.

滴滴所有的业务基本上都是以这种模式运转的,所有功能都是核心主干或者旁路,只要把业务模型抽象出来,基本上就能够满足大部分的业务了.

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读