服务化反面案例

一、背景说明
最近一公司在做权限服务,其中的设计可以作为反面案例好好学习下。
大概背景是这样的,公司有大几十部分,员工大概有1W人,因为每个部门都要用到权限,因此准备做一个权限的服务,封装权限的相关功能。

相关数据库设计如下(不是所有字段):
用户权限表
userId, roleId

资源表
resourceId, resourceUrl, resourceName

角色表
roldId, roleName

角色权限表
roldId, resourceId

这是一个标准的权限模型,用户和角色绑定,角色和权限绑定。

前面说了这个服务是给整个公司所有人员用的,为了解决性能问题,设计的同学憋了个大招,每个业务系统把上述表自己同步回去,然后通过MQ发送数据的修改情况。
看完这个设计,瞬间晕倒。

二、什么是服务,如何做服务化
先抛开上述设计的分析,我们看什么是一个服务,在我看来一个服务应该包含几点:
1、有自己的数据,对整个数据的生命周期进行管理,像订单中心,要对订单的创建、支付、发货,甚至包括逆向的售后都需要参与管理;
2、和其它系统交互主要通过接口交互,当然也有一些异步交互,像发送MQ,但主要还是通过接口交互,因为你要控制业务的逻辑,才能做到高内聚;
3、独立的部署;
4、做的比大的服务还有自己的后台,可以对业务进行配置,查看业务相关的数据,及进行业务流程的周转;

做服务的目的是提高系统/业务的可重用性,快速响应业务。所以一个好的服务应该是高内聚的,如果做的不好,一个表象就是如果要加点功能,各业务系统都要修改,系统响应慢,交互效率 低。

如何做服务化呢,没有严格的标准,在我看来有些可以参考:
1、分清哪些是服务该做的,哪些是不该做的
这个要结合业务讨论,理清业务边界,即要对系统的职责进行准确的定位;

2、对外一定是以接口提供服务为主
因为你是一个服务,需要做业务的控制,要管控业务流程,让调用方都不关心业务的具体设计,只关心结果就行了;
像上面的权限服务,应该提供判断用户是否有权限的接口,入参为userId和resourceId,只有这样,你才是高内聚的,因为中间的复杂逻辑都收拢在服务内。

3、业务闭环
服务所管理的业务的整个生命周期的应该是在服务内闭环的;
就像权限服务,核心应该是管理权限,那么权限的添加、修改、判断用户是否有权限都应该是在权限服务里完成的。

三、案例分析
再回到案例里,这么设计本身是为了解决性能问题,其实解决性能问题有很好方案,如缓存,即将权限数据保存到分布式缓存或本地JVM缓存,则TPS上到6,7K应该问题不大。

像上面这样设计为带来很多问题:
1、复杂的数据同步机制
消息的顺序性如何保证,实际情况可能是先将一个用户的权限添加,后来发现加错了需要删除,可能要发送2条消息,如果消息中间件无法保证顺序性,这个将会加大工程量。

2、逻辑的分散
因为权限服务没有对业务逻辑收拢,导致逻辑由每个业务系统自己实现,后续如果要做些调整,需要和每个业务系统调整逻辑并且上线,即因为权限服务的变化导致调用方的修改,估计每一次上线都是恶梦。

3、数据的安全性
因为权限数据到处复制,所以所有人的权限都可以看到,这个包括一些BOSS级别,如果数据库相关流程设计不好,每个业务系统都可以看到所有人的权限,很有可能泄漏敏感数据。

FastDFS不同步怎么破
redis-port支持前缀迁移
Nginx配置不当险酿S0
RabbitMQ跨机房迁移数据零丢失
扩展Redis:增加Redis命令

image

你可能感兴趣的:(服务化,权限)