mysql service broker 是mysql接入CF的代理服务实现，它是一个ROR（Ruby On Rails）工程。
目录结构
app - web应用的前端代码
\- asserts - 静态资源
\- controllers - MVC中的C，控制器代码
\- models - MVC中的M，业务数据集
\- queries - 查询
\- views - MVC中的V，视图，即html的模板文件（erb）
bin - 安装，启动服务，任务管理等脚本
config - 配置文件
db - 数据库schema脚本，rails的方式
lib - 业务代码
log - 日志目录
spec - 测试
tmp - 运行时的临时目录
核心代码解读
URL映射
在config/routes.rb中定义了系统的URL路径映射
这里resource定义了响应URL请求的Controller，
namespace，映射app/controllers下的目录，如：namespace :v2映射到了app/controllers/v2
only指定了支持的URL，update，destroy定义了支持的方法
get则是直接定义了URL映射到哪个controller的哪个方法
resource :preview, only: [:show] # 映射到app/controllers/preview_controller.rb的PreviewController，只支持GET方法
namespace :v2 do # 映射到app/controllers/v2目录
resource :catalog, only: [:show] # 映射到CatalogController，但只是暴露show方法，即只支持GET方法
resources :service_instances, only: [:update, :destroy] do # 映射到URL：/serviceinstance，支持PUT和DELETE方法，分别对应update和destroy
resources :service_bindings, only: [:update, :destroy] #映射到了下级URL：/serviceinstance/service_bindings/支持PUT和DELETE方法，分别对应update和destroy
end
end
namespace :manage do
get 'auth/cloudfoundry/callback' => 'auth#create' # 直接映射
get 'auth/failure' => 'auth#failure'
resources :instances, only: [:show]
end
由上面的代码可知，系统提供了以下几个REST API：
GET /preivew，由PreviewController#show处理
GET /v2/catalog，由CatalogsController#show处理
PUT /v2/service_instances，由ServiceInstancesController#update处理
DELETE /v2/service_instances，由ServiceInstancesController#destroy处理
PUT /v2/serviceinstance/service_bindings/，由ServiceBindingsController#update处理
DELETE /v2/serviceinstance/service_bindings/，由ServiceBindingsController#destroy处理
GET /manage/auth/cloudfoundry/callback，由AuthController#create处理
GET /manage/auth/failure，由AuthController#failure处理
GET /manage/instances，由InstancesController#show处理
其中/v2/目录的API（即红色的API）是service broker 必须提供的接口，也是我们重点关注的接口
/manage/目录中的接口是对实例管理（目前只有查看）的接口，并提供了OAuth认证的支持。
接口实现
获取服务目录信息
GET /v2/catalog
从CatalogsController#show方法可以知道，仅仅是将config/settings里的配置好的service以JSON的方式输出，因此服务目录信息在这里是静态的。
创建服务实例
PUT /v2/service_instances/:id
该接口是需要参数的，具体参考Service Broker API
对应ServiceInstancesController#update方法，改方法里，先检查了参数，之后调用业务类ServiceInstanceManager的create方法，去创建了服务实例
再追溯到ServiceInstanceManager，最核心的是调用了Database#create创建了数据库，接下来ServiceInstance#create创建了记录关联改数据库和实例id，并记录了规格plan
注意：ServiceInstance是ActiveRecord::Base的子类，即继承了操作数据的方法，类似DAO层
时序如下：
从代码解读可以知道：创建mysql服务实例的实质是为用户创建一个数据库
删除服务实例
和创建相反的流程，这里不赘述
绑定服务实例
PUT /v2/serviceinstance/:inst_id/service_bindings/:id
该接口是需要参数的，具体参考Service Broker API
对应ServiceBindingsController#update方法：先从参数id获取服务实例，并创建一个ServiceBinding实例，调用ServiceBinding#save方法，该方法为之前创建的服务实例（数据库）创建了一个用户，并授予所有权限。
从代码解读可以知道：为之前创建的服务实例（数据库），创建用户，并授权
解绑服务实例
和绑定相反的流程，这里不赘述
认证授权
MySQL service broker 提供的服务提供了简单的认证机制，可以保证基本的安全要求。
所有接口的API都继承自BaseController，这里定义了每个API调用都会经过认证授权
before_filter :authenticate
protected
def authenticate
authenticate_or_request_with_http_basic do |username, password|
username == Settings.auth_username &&
password == Settings.auth_password
end
数据视图
这里只需要一个表保存：服务实例和数据库的映射关系，及规格信息
schema_migrations是用来升级数据库的。
一些说明
接入CF管理
service broker 可以通过向nats注册，让CF知道自身的生命周期状态。
config/initializers/register_route.rb就是注册mysql service broker 到CF。