再谈能力开放平台(9.10)

今天是教师节，祝天下所有的老师节日快乐，感恩惜福。对于能力开放平台我在前面已经有很多文章都谈到过，今天再做下说明。

首先对于能力开放平台我在前面的思考里面做了一件重要的事情，就是将能力引擎和能力运营两者分开，能力引擎即我们常说的能力聚合网关，ESB服务总线，API网关等。可以看到能力开放平台构建你可以选择任何一个能力引擎都没有关系，只要能力引擎能够满足标准的能力注册接入，能力基础管控（安全，日志，流控）即可。

在能力引擎剥离后，最重要的就是能力运营平台。

在我们没有谈能力开放平台的时候，我们会在能力引擎上方增加一个能力管控平台。而能力管控平台主要做两个方面的事情，一个是实现API接口服务的全生命周期管理，一个是实现接口运行后期的运行监控治理。因此对于能力引擎上方，我们可以考虑拆分为三方面内容

1. 能力开发中心： 面向开发者，帮助开发者快速的进行能力接入和消费

2. 能力运营中心： 将能力服务作为商品去卖，因此设计到服务订购签约，计量计费，流控关键功能

3. 能力运维中心： 实际上包括运维中心和运行监控中心两个方面的内容。

而在这之上即是我们常说的门户层，实际的门户也应该包括了运营门户，开发者门户，合作伙伴门户。这里要注意的是门户层更多的是集成和聚合了底层各个业务模块的功能，只是区分业务场景和角色进行聚合。

在该构图后遗留的待思考问题主要体现在如下几个方面

1. 能力运营中心是否进一步拆分

能力运营中心是否进一步拆分为能力运营中心和能力管控中心，注意如果不拆分，那么我们原来说的SOA管控平台的内容将部分体现在能力引擎中，部分体现在能力运营中心中。能力运营中心直接对接到能力引擎。如果拆分则是能力引擎上是能力管控平台，能力管控平台上是能力运营平台。经过思考，为了减少层次和集成，最好方式还是不要再进行拆分，在能力运营中心中包括能力全生命周期管理模块即可。

2. 在总体构图上的安全模块问题

看了一些网上的能力开放平台构图，可以看到基本都会将安全管理再单独体现一个模块，而实际上安全管理本身核心实现应该再能力引擎里面，同时能力运营平台也有安全和权限控制方面的内容。而各自安全管理和内容的实现上本身也有差异，如果将安全管理单独拿出来，后续并不好区分清楚具体安全管控实现的边界。

当然还有一些参数配置，系统管理等功能模块，实际上再大的框架结构图上没必要体现。