玩事业务中台构建之路

共计 1296 个字符，预计需要花费 4 分钟才能阅读完成。

本文章通过玩事创新应用的发展之路，来介绍如何随着业务的不断发展抽象出的业务中台。玩事，不一样的做事方式。这是一个 17 年 3 月初开始创新孵化 17 年 4 月 1 日上线的创新产品。经过 1 年多的发展，从最简单的发荣耀功能，发展至今包含荣耀、荣誉、祝福、权益中心、金豆雨、学一下、猜一下、权益雨等多种创新互动的场景，并形成以基础数据、金豆、标签、权益为核心的中台微服务。下面谈谈玩事是如何基于 iuap 的 PaaS 平台快速构建业务，逐步抽象出核心的中台微服务。互联网界一直都在呼喊“大中台，小前台”的理念，但到底什么是中台呢？下面是 iuap 对中台的一个理解：中台更多是一种理念，大家以中台的方式思考和行动，业务发展是核心目标，中台能力沉淀是持续保障！中台不是简单的产品或者平台，她代表着全新的：业务服务模式 + 架构模式 + 组织协作模式图 1 – 玩事中台架构图图 2 – 玩事技术架构图玩事创建新应用是基于 iuap 的 gPaaS、bPaas、dPaaS 平台快速创建的。gPaaS 平台提供了开发运维一体化及基础的技术支撑，bPaaS 提供了用户、员工、项目、企业账号、团队、消息等基础服务的支撑，dPaaS 提供了数据收集、数据报表的基础支撑。在这些强大的 PaaS 平台技术的支持下，才有玩事的专注于业务创新。上线之初，玩事就初步具备了金豆、荣耀和权益三个应用，只是初期的功能非常简单。随着业务的不断发展，增加了很多的新业务：荣誉、祝福、拍砖、学一下、猜一下、投一下、权益券等。如果不对应用进一步的抽象出中台业务的话，业务中可能会存在大量的重复逻辑，非常不利于维护和未来的持续发展。以标签核心微服务的抽取过程来阐述下如何抽象业务中台微服务。下面是最初的发荣耀业务流程图：![clipboard.png](/img/bVbmXjp 图 3 – 荣耀发放流程图随着业务的不断发展，新增了发拍砖、发祝福、发荣誉以及扣减库存发荣耀等需求，他们的大致业务流程相同，却存在一些细微的差别。如果进行抽象，那么荣耀、拍砖、祝福、荣誉存在将会存在大量的重复业务逻辑和代码，浪费开发资源也不利于长远的发展。图 4 – 荣耀、拍砖、祝福、荣誉发放流程图仔细观察我们会发现，荣耀、拍砖、祝福、荣誉存在一些共同的特性，他们实际上本身都是一个标签信息，区别在于荣耀、祝福、荣誉是转账金豆，拍砖是扣减金豆，荣耀支持用库存发放，祝福支持发权益券。为此我们抽象出一个标签的中台微服务。图 5 – 标签抽象图当然标签微服务的能力和扩展点除了标签的业务操作外，还有校验、报错、IM 消息等都可能存在细微的差别，都可以通过扩展的这种方式来完成对主题业务的抽象统一，细微差别的个性化操作。这样的好处在于，如果后续发荣耀的业务也要支持送权益券仅需要改个配置参数就可以了，不需要重复开发。抽象出业务中台服务后，可以将这些服务重新反补到 bPaaS 平台，提供给更多的应用使用这些能力，并逐步发展和壮大这些核心微服务。在实际的中台核心微服务抽取过程远比这复杂，但是要抓住业务核心，针对 DDD 领域建模，抽象出领域服务的核心能力，差别的操作通过扩展的方式来实现。只要抓住这些核心方法，相信一定可以抽象出合理的中台服务。