独立开发者最重要的事情就是做选择。相比于团队可以分摊任务,个人则必须决定把时间和精力主要放在哪里。我们可以精通客户端的开发,也可以专注于用户体验,但必然无法在每一个部分都亲力亲为。为了尽可能的提高效率,功能的复用性和通用性就变得尤为重要。

从单一的功能模块提取(支付系统,用户系统),到现在建立统一的中台架构。这个过程完全是自然推动的。

诞生的缘由

早先在接入支付时,我就在第三方的接口上做了个简单的集成和隔离,方便自己多个App使用的同时也提高了安全性(详见 个人支付系统的思考与实践)。

作为一个以安卓起家的开发者,对于后端的熟悉程度不足,所以开始时一直在使用 BaaS 类的服务,即通过第三方提供的SDK来实现后端功能。后来综合各种因素考虑,把重心转移到了 Serverless ,也就是以“云函数 + 云数据库”为基础,各个云服务的大厂都支持的开放架构上。

这么做的坏处是要写更多的代码,负责更多的设计。好处则是方便随时迁移,以及更为灵活自由的空间。它承担了服务托管、负载均衡以及灾备扩容这些支持环节,留给我们一个能够专注业务的环境。

在 Serverless 的基础上,后端功能的模块化设计就是顺势而为了(详见 基于腾讯云开发的简单用户系统)。

同样的功能模块,开发时copy过去改一改就行。但既然大部分功能都是必备且重复的,为啥不做个系统来统一调用呢?应用自身的业务就让它保持独立,其它诸如用户模块,支付模块等通用的功能,放在一起既方便维护也节省时间。就像中间层一样,中台就是各个应用和底层支持的中间层。从coding的角度来看,也是面向对象中的提取父类😜。

个人所需中台的考虑

我需要的中台,就是把相同的功能统一管理维护,使得应用能模块化的接入,节约重复开发的成本,提高效率和安全性。在形式上表现为一个单独的系统,拥有web和app控制台,独立的数据库和权限控制,以及对外提供各种接口的云函数。

对于目前的个人应用来说,主要的必备且相同的功能有:账号模块(简单的注册,登录以及重置密码,账户冻结,消息提示等),反馈与工单模块,更新与提示模块,应用远程开关,支付模块。可以划分为应用,用户和支付这三个大的方面。

每个应用要想接入,首先要在后台添加以获得id和key,然后在应用本身的后端中接入(自己的业务是独立的,因此依然有自己的后端)。放在后端调用可以有效的防止客户端被破解导致的数据安全问题,保证关键的调用都经过验证,而且中台系统本身也会制定严格的安全策略。除非业务逻辑设计出错,否则基本不存在 Serverless 后端被侵入的可能。

接口设计上,最主要的是应用和用户的鉴权,前者是所有模块正常使用的基础,后者是用户数据唯一且可溯源的保证。他们也是支付等模块必备的基础信息提供者。所谓用户鉴权,并不代替整个应用的登录过程,只是控制账户和密码加盐MD5的储存,反馈登录是否成功,具体的登录和授权依然由应用自身控制。

实现效果

目前还在做web控制台的前端,Vue 写起来还是挺舒服的,哈哈。

这是仪表盘页面的实现效果,数据是mock的。

效果图

8月8日周末更新

开始的时候是用了 ant design vue pro 这个框架,大而全,可惜就是有点重了,在这个项目上杀鸡用牛刀。
因为是个人使用,所以账户的权限控制几乎不需要,登录和状态方面都由 Severless 提供的 SDK 解决,连个包装个request都不需要🤣,实在是太方便了。

所以这个 Web 中台就是纯粹的前端,核心的操作逻辑都直接写在云函数里以供调用,有点微服务的意思。

用不到的东西一堆,改起来实在麻烦,最后就把框架换成 element 了,体验良好。如果是和后端配合开发的话,可以试试 element-admin-vue 这个框架,基本的功能和封装都有,而且比 ant 要轻一点。

附图一张,支付界面:

效果图

更多设想

具体细节还有些没说,时间所限,下次再补充。 😊

8月8日周末补充

确定了几件事:

  • 主要分为应用、用户、支付和工单四大模块,目前只做这些
  • 不碰业务数据,即使是用户和工单系统,也仅接入具体App的后端,不直接使用
  • 上线前添加登录二次验证功能

8月10日周末补充

在合适的限度(能接受的范围)内,勇于探索尝试并负责任,永远比躺着空想好一万倍。
得支棱起来,让自己的状态朝着目标的方向走啊!

以上是几句瞎感悟,今日确定的补充如下,三个基本原则(更新版):

  • 不租服务器,只使用云服务
  • 云服务商提供的解决方案,如果没有现行可代替的产品,就不使用
  • 中台只是服务的集成,不储存任何应用的业务数据