近期为了准备开发私有云，研究了heroku第三方服务的接入。这里总结下heroku在这一方面的亮点。
一、强大的接入工具
要把自己的服务集成到heroku上，你要和heroku定协议，按照协议开发，然后验证，最后还要发布到heroku。这个过程会很耗时，而heroku提供了一个叫kensa的命令行工具，能减轻不少工作量，特别是其中的测试功能，能够逐步验证接入的相关约定，相当方便，回想自己之前的项目，需要做机器接入，很多都是人工验证，相当原始落后。不过，如果能提供图形界面，我觉得会更加上流。
二、详细的接入文档
这个自不必多说，没有这些文档，我也写不出这几篇文章。
三、强制约定，而非厂商自定义
在接口协议上，第三方厂商基本只能自定义服务地址，其他大部分都得按照heroku的约定。heroku首先设定，第三方厂商需要提供一个heroku的专用接口-your-add-ons/heroku/resources,接口名一定是用heroku/resources结尾的，然后这个接口的参数，请求方式，返回都得按heroku的要求来。这样做可以减少heroku双方联调（事实上就不用联调）的成本。对于heroku来说，第三方服务成百上千，一定得用强制约定的方式。之前我的项目接入其他服务时，会允许其他服务自己定义，主要是因为我的项目接入服务不多，有人力可以做适配。但如果往大了走，希望支持更多服务，还是得和heroku一样，采用约定的方式。
四、分级发布制度
定义了测试版、灰度版、正式版等概念，第三方服务要逐级完成这些版本的要求，才能正式发布。这样做提升了服务的整体质量，减少了劣质插件的用户的伤害
五、协议以本地文件的方式存在
第三方厂商和heroku的协议，模版是由heroku定义的，第三方厂商需要填写服务地址、资源变量等信息。这些信息，heroku也可以让厂商去网站上填写，但heroku没这样做，而是以一个配置文件的方式，存放在第三方厂商自己的代码中（当然，最后发布时，还是要把这个文件push给heroku），我在考虑，heroku这样做的好处。这样做最大的好处，还是测试方便。没有这个配置文件，kensa的很多测试功能，也没法进行了。
