最近为了准备开发私有云。研究了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的非常多測试功能，也没法进行了。
版权声明：本文为博主原创文章，未经博主同意不得转载。
举报
举报
- 本文已收录于下面专栏：
- Heroku学习
0条评论
objective-c
Delphi
Ruby
PHP
C#
C++
JavaScript
Visual Basic
Python
Java
CSS
SQL
其他