基于Go构建滴滴核心业务平台的实践

本文介绍了滴滴如何基于Go语言构建其核心业务平台,包括Go在滴滴的应用规模、中台业务的挑战以及选择Go的原因。文章详细阐述了滴滴在服务治理方面的经验,如异常定位、日志规范化、线上压测和全链路追踪,并分享了Go在实践中遇到的问题,如net.Conn的double close和GC问题。最后,作者推荐了两个开源工具:gendry和Jsoniter。
摘要由CSDN通过智能技术生成

作者简介:

石松然,滴滴资深开发工程师,负责中台业务的维护和开发工作。本文主要内容是基于Go构建滴滴核心业务平台的实践经验。


内容大纲:

1、Golang 在滴滴业务的应用发展及规模

2、滴滴使用Go治理模块的经验

3、分享两个具体的Go在应用上的问题

4、推荐两个开源工具


正文

1.Go 在滴滴内部的应用和发展的情况

   在滴滴的代码仓库里面有超过 1500 多个模块是含有 Golang 的代码片断的,有1800多位 Gopher 在滴滴提交过 Golang 编写的代码,仅仅是我们的中台服务,就有2000多台机器在跑 Go 的服务。

1.1 我们用Go做了什么

DUSE 是滴滴的分单引擎,负责滴滴司机和乘客的撮合,每秒钟负责万级的撮合需求。

DOS 是滴滴订单系统,负责实时订单状态的流转,同时也负责滴滴历史订单的检索,是一个百亿级别数据的检索服务。

DISE 是我们自主开发的 schemaless 数据存储服务,使用了类似 Bigtable 的实现。

DESE 服务是一个serverless 分布式框架,只需完成业务函数即可完成分布式业务的搭建,类似亚马逊的 Lambda 业务。

1.2 中台业务

640?wx_fmt=png&wxfrom=5&wx_lazy=1

大家使用滴滴的时候,会碰到一些业务线。快车、专车、顺风车,在滴滴这些业务线叫做前台服务,他们有一些共同的特性,都有司机信息,订单的状态,收银,账号等等这些业务逻辑,我们会把专门的业务逻辑集合起来,形成专职的服务,这些就是中台服务。中台服务作为前台服务的支撑,重要性是不言而喻的。

1.3 挑战

  开发中台服务的时候遇到一些挑战,主要来自三个方面:

  1、高可用:中台服务支撑了所有的前台服务,出现问题就会导致前台服务集体挂掉,高可用是非常重要的。

  2、高并发:中台服务是所有流量的承载体,需要非常高的承载能力和很快的响应速度。

  3、业务复杂:中台服务也是一个业务服务,所以业务的复杂程度直接决定了中台系统有多复杂。

1.4 Why Golang

  第一是执行效率非常高

  第二是优秀的开发效率,Golang的语法比较简洁清楚,可以屏蔽很多技术细节,让业务开发更加顺畅。

  第三是Golang活跃的社区和丰富的库,帮我们解决很多问题。

  第四是学习成本低,我们刚开始使用Go的时候,发现工程师非常难招,其他语言的工程师通过很快的学习就可以了解Go,熟悉Go,开发Go的程序。


2.滴滴在治理Go模块的经验

2.1 庞大的业务系统

   滴滴业务比较特殊,每一个请求都涉及到司机、乘客、订单的三者的状态信息,我们有很多微服务保证服务的状态。我做过简单的统计,如果把一个快车订单拿出来看,涉及的子服务有50多个,Rpc请求达到了300个,日志行数是1000多条,这样人工进行分析非常困难。

2.2 服务治理的难题

   微服务过多带来很多的问题,比如异常定位比较困难;系统链路不清楚哪一块好,哪一块差;做服务优化和服务迁移的也会比较困难。针对这三点,我介绍一下滴滴是怎么做的。

异常定位

  随着初期滴滴业务的野蛮增长,很多服务没有遵循开发规范,导致我们滴滴日志混乱,异常定位也非常困难,缺少上下游基本定位的信息。 大量工程师的人力都浪费在异常定位、异常分析上面了,随着我们的业务发展,后期人力投入会越来越大。我们就想能不能做异常的分布式追踪,还有日志规范化的工作。

日志规范化

640?wx_fmt=png

  • 10
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值