背景图

用户中心再思考

在之前写的一篇文章中,我们提到了用户中心的设计,但是我们没有提及如何定位用户中心,以及如何使用用户中心,接下来我们就简要讨论一下这个用户中心的事情。

用户中心定位

用户中心应该是独立于系统而存在的,是基础服务的抽象,也就是说用户中心中不应该出现业务的影子,更不应该出现特制的一些东西。用户中心应该是一种服务,这种服务不对外,只针对系统,所以它的服务对象是后端的各个系统,不会直接面向用户。

当然如果你做成面向用户的一些接口的话也是可以实现的,但是这样做就打破了系统的边界和统一的API服务,因为我们觉得,一个系统不能跨系统请求,除非是基础的服务。一个系统需要其他的数据,也应该由本系统提供,本系统调用基础的服务,而不是基础服务直接对外。当然关于这个问题,还是有很多值得思考的地方,以后我们在实践的过程中应该还会去考虑这些问题。因为我们还要不停地去确定我们的系统边界的问题。

用户中心颗粒度

用户中心是一个组系统还是一个系统,我们在具体实施的过程中遇到了这样的问题。其实这个命题不是很准确,我觉得用户中心怎么实现都是可以的,关键你是采用什么样的思想去实现,还有可能就是非技术因素的限制。

比如我们觉得用户中心包含多个方面,一是SSO,二是Oauth等等,当然最后一定用户信息模块的维护(这个狭义的用户中心)等。因为我们觉得这个更符合微服务话的思想。这个是一个比较理想的实现方式,而实际的实现可能并不是这样的。

真实的情况我们可能将上面所有的系统融合到一个系统里面去,形成了一个广义的用户中心,或者说是SSO式的用户中心。上面的狭义用户中心的设计会遇到下面这些问题:

  • 实现比较复杂(开发难度有点高)
  • 需要处理服务调用间的异常情况
  • 需要运维支持,可能带来很多沟通成本
  • 分散的系统也许不是那么安全可靠

这些缺点的反面就是广义用户中心的优点。只要单台机器,部署简单,省去不少与运维的沟通成本。

所以用户中心的颗粒度问题要视具体的实现情况来看。可以根据自己的需要进一步拆分系统。

用户中心设计注意事项

我与团队在进行上述问题的讨论过程中,又发现了用户中心设计的一些注意事项,或者说我们不得不面对和考量的一些问题。

  • 用户中心应该保存哪些用户资料信息
  • 每个系统要求用户中心修改资料,用户中心如何防止有冲突的修改情况。(当然我们每个系统都有user表,如果想特制化,可以利用自己本地的user表,用户中心只是一些基础默认信息,但是有些系统直接使用的,这样还是会存在用户中心资料的修改冲突。)
  • 信息修改需不需要对外(我们一致认为基础服务不能对外,因为一旦对外,这些基础服务可能就变成了一个业务系统。)

总结

总之在用户中心的设计过程中,我们会面对很多的问题,在系统成熟之前,我们可能还要面临更多的设计问题,还要做出更多的思考和总结。

一个关于系统拆分的问题,原来我们一直在拆分系统,变成了几大块,但是我们发现后来好像有点迷失了,因为我们不知道,系统在哪里?因为我们拆出来的系统好像都是基础模块,而忘记了我们其实是在做一个系统,没有系统来耦合调用这些模块,那我们做的这些基础系统有什么存在的价值。

而且基础服务的设计也是基于当前的业务,所以很多的时候,我们也许很难真正实现独立的基础服务,有些基础服务就是会和业务耦合,那么我们该如何进行处理呢?耦合可以分为:代码耦合,逻辑耦合和数据耦合(比如数据库的表设计)。如何进行高度解耦也是基础服务设计必不可少的一个考虑因素。

一个用户中心系统的设计问题,为我们带来了更多的思考,以后我们会单独写一篇文章来专门讨论如何进行系统拆分的问题。

0%