系统平台对接方案本项目采用统一接入方案。本项目云平台设计升级改造时，不会直接影响到第三方服务。过往的逻辑链路，是云平台绑定了N个第三方服务，而有了插件平台，这个链路变成：云平台->插件平台->N个第三方服务。过往的情况是，云平台的一些变动，N个第三方服务可能要跟着修改。而现在，只需要由插件平台统一做变更，而插件平台到N个第三方服务这条链路，可以保持之前约定的规则不变。另外，云平台的一些部署、变更，也能尽量少地影响到插件服务。插件平台更专注于插件这个事情，可以把插件接入、维护这件事情做得更加极致。一个插件平台，可以对接多个云平台。作为一个中间站，插件平台可以按照它和每个云平台的约定进行对接，然后再按照插件平台自己的标准流程，和多个第三方服务进行对接。这样，每个云平台上，等于都能接入插件平台提供的第三方服务。能与开源社区结合，打造闭环“广大开发人员开源组件->孵化成熟->成为云平台第三方服务”，从而提供更多丰富的插件。这是我们的实践结果。插件平台不仅为云平台提供第三方服务，同时，我们还开发了这么一个网站，每个开发人员，可以到这个网站开源自己写的组件，如果觉得合适，还可以将这个组件转成云平台适用的第三方服务。其次，解答统一接入方案的重要性和必要性：说到底是为了两个字,"效率"。没有统一接入方案时，每来一个新的第三方服务，云平台开发人员就需要和第三方服务开发人员讨论确定接口，然后一方（第三方服务）写接口，一方（平台）写调用逻辑，最后进行联调，非常麻烦。有没办法改善呢？当然是有，就是提供一个统一的接入方案，不管是什么第三方服务，都按照这套规范。平台的逻辑是通用的，要接入新的第三方服务时，无需开发。第三方服务要按照规范开发几个接口，再通过页面配置信息，然后就能接入了。从之前的两方联调模式，变成单边适配。对接流程开发者按照约定，开发服务的增删改查接口。在云服务平台填写服务信息，使用测试工具测试ok后，提交管理员审核。管理员审核并上线。这是很常见的一个接入流程。下面我们具体看看，我们是如何更简洁解决上面提到的问题。鉴权第三方服务在收到请求时，当然需要判定请求来源是否合法，是否来自插件平台。我们提供了两种鉴权方式，供第三方服务开发者选择：Keystone插件平台、公司的私有云平台，鉴权都基于openstack自身的keystone模块，该模块为服务间交互的鉴权，提供了一种统一方案。因此，和平台交互的第三方服务，也可以采用该方式。这样有两个好处：从云平台、插件平台、第三方服务，自上而下，鉴权都是统一、标准、可信任不用自己造轮子Password平台和服务之间约定一个密码，平台发起请求时，会在Header中带上该密码，服务在收到请求时，判断该密码是否和约定一致这两个方式，前者略重，但安全可靠，后者略轻，却快速简单。keystone是openstack的标准方式，它的好处自不必说，而password这个方式，是考虑到我们是个私有云，可以减低安全要求，同时更要尽量快速简单地接入第三方服务。约定响应格式和下面要展开的“请求参数格式"一样，这里的关键，是如何抽离区分，平台的统一参数及不同服务之间的差异参数。什么意思呢？哪些是统一的参数，哪些是差异参数。例如，不管是何种第三方服务，创建一个资源后，都需要返回操作的明确结果，资源的id。而其他的返回参数，则存在差异，例如一个mysql服务，还需要告知，资源的url，端口号，用户名，密码等，而图片服务，则可能提供一个存储路径url即可。我们是这样做的：请求、响应设计，遵循RESTful设计。RESTful的特点：通过HTTP状态码能知道操作结果，通过HTTP方法能知道操作类型（增删改查），通过Url能知道操作的资源对象。这些特点，刚好和服务接入的标准不谋而合。因此，我们约定：请求响应码，操作成功返回200，否则返回4xx，5xx。平台只通过状态码来判断操作成功与否。标准的返回内容（示例）如下：{"id":"68788943-d109-416b-983d-e3df70a9463b","config_vars":{"port":"3306","host":"d9888.mysql.oa.com","slave_host":"fd9888.slave.mysql.oa.com","default_db":"db_name","user":"a742e2f...
