对现有架构的理解

未分类

现在的处理流程：

（1）API网关管理：注册API、管理角色对应的权限
（2）API网关管理：管理角色对应的权限
（3）直接请求：无法防止url篡改和重放攻击
（3.1）权限校验，用户对应的角色是否有访问资源的权限
（3.2）路由选择，根据请求的url选择合适的restful资源
（4.1）角色权限检验，根据角色检验权限
（4.2）资源归属检验，为了安全有必要添加业务数据归属
（4.3）真正的业务处理

Restful资源应该是状态无关的，足够精简的。现在的我们的设计虽然号称没有session管理，没有状态。但是处处都是传递了一个当前用户，后台又根据用户管理了一堆的缓存。跟session的唯一区别，一个是中间件平台提供的，一个是自己手工通过redis管理。

以一个客户360视图为例，一个请求过来，我只要返回360视图的数据，而不用管是他的客户经理请求过来的，还是部门领导或者总行领导请求过来的（因为以后还会添加其他的角色），不能因为业务逻辑的需求变更改变我Restful的资源，一个Restful资源应该是相对比较固定的，不能频繁变动的。试想我一个Restful资源有太多的业务逻辑处理，这个资源又被很多地方引用，如果业务需求变更，如果仅仅是权限的变更，就要改后台的Restful资源，影响到前端一堆的引用不能使用。这种设计肯定是有问题的。业务逻辑的处理越是下沉到Restful后端，对系统影响性也越大。

本来是想细粒化Restful资源的，现在Restful资源里有太多的逻辑处理，就会很重。以后你的网关可能会有请求聚合的处理，每个Restful资源很重，有很强的业务逻辑相关的在里面，聚合处理就是个很棘手的问题。

Restful层作为API资源的提供者，API网关的上层应用（网站、手机、其他系统）作为API资源的消费者，怎么组合使用API资源应该是各个系统自己的问题。

同样的一个资源的同一个操作应该只有一个api，比如一本书的保存对应的应该是book_save操作。至于保存那些内容、什么人、什么组织保存的，应该只会作为记录的内容保存在数据库或者日志里，而不是作为条件判断或者逻辑处理的依据。这样一个API才足够清晰，而不会在使用的时候考虑他的内部逻辑处理方式和相关依赖。如果不同的逻辑暴露出不同的API，会造成API数量的暴增。这个量是很难估计的。

权限的处理只是业务逻辑的一部分，如果把系统除权限管理以外的强业务逻辑提升到API网关层显然是不合适的。现在的API网关已经整合了很多跟API网关无关的处理逻辑。

现在的设计是：Restful资源需要对业务系统用户级的访问权限负责，网关也整合了一部分业务系统用户级访问权限的控制，有一定的重复操作在里面。以后加入的系统或者平台要么往现有的平台上靠，要么只能暴露其他的api给它们。如果以后对接的一个系统没有用户的概念，它只是想要我的一部分数据，它就要模拟一个用户出来，放到我的请求里。

完善后的设计

1. 工作台sever作为一个API的使用者，对自己平台上的用户负责，通过组合调用API满足业务逻辑处理。
2. API网关作为API的集中管理者，对接入的系统负责，给各个系统分配秘钥，进行鉴权，保证各个系统只能访问开放给他的API
3. Restful对自己的提供的服务负责，保证提供的api服务明确没有歧义，没有依赖，尽量简单
4. 工作台sever使用现在的poin平台基本就能满足要求，不需要做太多的改动
5. API网关经过精简化以后，只要关注中间件的开发，不用再关心业务系统用户态的东西。
6. Restful资源使用POIN平台开发，不用再关心用户态的东西，基本也就只剩增删改查的操作了。API的数量会大幅减少，也更清晰。
7. 项目完成以后，我们得到一个比较成熟的API网关，一个平台级的工作台，其他的业务系统可以通过模块的方式在上面发布应用，也可以通过申请API网关服务，以系统APP的方式组合调用API服务