数据平台服务化建设(1) -- 谋定而动

    技术2022-07-12  98


    这是《数据平台服务化建设》系列的第 1 篇,预计会写 10 篇左右。通过这个系列,我希望和大家分享下数据平台怎么去做服务化建设。扫描文末二维码,关注公众号,不再错过精彩。也欢迎转发朋友圈分享给更多人。


    上一篇文章,我大致说了下服务化建设的重要性。对包括数据平台在内的基础设施型技术团队,都是非常重要的出路。

    现在就进入正题,分享下到底要怎么做数据平台的服务化。这里面的一些思考和规划,哪怕你不是做数据平台的,也是值得了解甚至借鉴的。

    这篇文章,会讲一些整体上的考虑,后面的几篇再具体讲每个模块该做什么和怎么做。

    首先,需要有一个主页。

    服务化建设的成果,主要是一些提供给业务部门使用的 Web 系统和 API。随着服务化建设的推进,这样的服务会越来越多。

    业务部门需要记住的东西也越来越多,就可能会分不清这些服务各自是干嘛的,甚至都不知道去哪里找。

    所以,需要一个像以前流行的导航网站一样的东西,来收纳数据平台提供的所有服务。

    可以用 home.dp.company.com 作为域名,浏览器打开后,就能看到所有服务的入口。

    类似上图这样(安全考虑打了码),数据平台的服务化成果就有了统一的入口,业务部门要记住的就只有这一个总的域名。

    除了作为服务化成果的入口导航外,这个主页上还可以做很多事。比如挑选合适的技术调研和分享放上去,作为数据平台的技术能力展示;再比如一些帮助文档和规章制度等,也可以放上去。

    不要小看这个主页,虽然没什么技术含量,就是个静态网页,但它的作用不是用技术衡量的,而是更多体现在体验上。如果把数据平台整体作为一个产品看待,那就是这个产品的首页,毫无疑问是非常重要的。

    其次,需要有统一的登录认证。

    主页只是导航,具体每个服务都一定有自己的权限系统。而每个服务的认证和鉴权方式大概率是不一样的。

    这没关系,后台鉴权不统一很难改也不一定要改。但作为前台的服务化系统,我们有绝对的控制权,就可以统一认证了。

    并且,为了用户友好性,必须统一认证。

    试想,如果你自己去用这么多服务,每个都要求登录,可能还是不一样的账号密码,甚至有的都不是用账号密码,你一定会抓狂。

    所以,我们需要统一并且唯一的认证系统。

    比较简单的做法,是直接利用公司现成的 LDAP 系统,或者已有的 OAuth2 鉴权系统。然后为每个服务化系统都分配一个 xx.dp.company.com 的次级域名,这样就能让它们共享同一个身份。登录其中任意一个(包括主页),就不需要再重复登录其他系统了。

    不得不提的是安全问题,统一的账号密码固然方便,但相对 Kerberos 等方式肯定是不够安全的。

    但是,没有绝对的安全,只有不同成本下的相对安全。

    在数据平台这个前提下,考虑到很多公司都还搭配了 VPN,账号密码对大多数应用场景来说,都是可以接受的。其他特殊的场景,比如 HDFS 管理员账号等,可以特殊处理,比如加一个动态密码做两步认证,或者辛苦运维同学登录服务器去操作。

    再次,需要有合适的推进节奏。

    早期的服务化建设,一定是烟囱式的开发。

    发现一个公共需求,就做一个系统出来,发现另一个,就再做一个。

    当然,我们做事情必须有规划(我之前提过的平台意识),不能想到啥做啥。但也不能等所有东西都整理清楚、设计完美了再去做。更何况有些需求是后面才显露出来的。

    所以,我们不怕有节制的烟囱式开发。

    但是,度过早期阶段后,服务化建设就需要开始更规范地推进了。

    怎么样才叫规范、专业,才叫好,我总结了几个小点:

    做减法,之前为两个小模块各自做了系统,但其实属于同一个大模块,现在可以考虑合并,重新抽象和整合,也能减少对外入口,减轻业务部门心智负担,

    做串连,各个服务之间经常都是有关联的,首页固然可以导航,但只是静态展示,各系统间也可以通过跳转来体现关系,甚至是复用功能。

    后面讲各个模块怎么做服务化建设,我也会提到我们在过程中,是怎么去做减法和串连的。而不是扔一个最终效果就完了。过程往往比结果更重要。

    最后,需要掌握一些推广技巧。

    服务化成果做出来,只是开始。用起来,才上路了。

    但是,想用起来往往没那么顺利,有几个点需要注意:

    一方面,要摆正初衷,不是为了锻炼自己技术,也不是没事找事,一定要有对公司和业务部门有明确的帮助。具体参照上一篇,这里不赘述,

    另一方面,就算你做的东西真的是有用的,也要注意推广的方式,市面上无数商业公司真金白银的教训已经证明过了,好产品不一定就能火。

    因为业务部门可以有非常多的理由不用你做的这些东西:

    有些比较客观,会公开拿出来说,比如有更紧急的事,比如质疑用这个东西有多大好处,

    还有些纯主观,不好放明面上讲,比如「你都封装好了,我岂不是无脑用,那我一点进步都没有了」。

    类似问题,如果你是纯技术思维,那八成完蛋了。很多时候需要软硬兼施:

    可以开个服务介绍会,或者高调点弄个产品发布会,仔细介绍做这个服务的初衷,能给公司和业务带来什么好处,

    多用案例、数据和图表说话,比如通过引入 SQL,上百行的 MR 只用几行就能搞定;通过引入 bucketing,某个大任务执行时间缩短到原来的 1/5,

    找些外部背书,社区主流方向就是这样,哪几个大厂也是这么做的,

    找些内部背书,公司或哪个高管特别重视安全问题,某个业务部门特别希望上线这个系统,来提升开发效率,

    张开手、弯下腰,找一两个业务做突破口,像服务客户那样,耐心教他们,帮助他们解决遇到的问题。

    只有推广开来,你辛辛苦苦做的这些东西,才是真正有意义的,不要一做完就开始感动自己了。


    在这个号正在连载的另一个系列《漫谈核心能力》里,我提到过一种能力,叫做有条理地做事情的能力。其中一个重要体现,就是做事有规划。

    服务化建设就是我们在有规划地做数据平台建设。

    而上面列的这四点,就是我们怎么有规划地做服务化建设。

    刀磨好了,下一篇开始,我们就上山砍柴。

    关联阅读

    数据平台服务化建设(0) -- 寻找出路

    漫谈核心能力(4) -- 有条理,更清晰

    原创不易

    关注/分享/赞赏

    给我坚持的动力

    Processed: 0.014, SQL: 9