MasterofProject

Service Gateway Cloud Foundry and communication mechanism

1175 people reading comments(0) Collection Report
Classification:

The Service Gateway function and communication mechanism of this report from two aspects about Service Gateway:Service Gateway Cloud Foundry component in the.

 

1 Service Gateway function

The role of Service Gateway in CloudFoundry in the main are: to receive the Cloud Foundry controller Cloud Controller request, and according to the type of request, the management of the Service Node service instance.

In CloudFoundry, Cloud Controller will send 20 management requests to the ServiceGateway. The following is the description of the specific request:

 

1.1. Provision a service

Function: to create a new service instance for users.

Function: @provisioner.provision_service (req)

Parameter analysis:

Req:CloudController request sent by Service Gateway after the arrival of the decoded information, the data type in Ruby hash; in provision_service (req) function, which is mainly used in the properties of label, plan, version;

Label: the need to create instances of a service type, such as mysql-5.1, mysql-5.0 etc.;

Plan: we need to create a service instance of the program is mainly restricted to create the service instance size etc.;

Version: we need to create a service instance version, such as the MySQL version number 5.1.

 

1.2. Unprovision a service

Function: remove one has created the service instance for users.

Function: @provisioner.unprovision_service (params['service_id'])

Parameter analysis:

Params['service_id']:Cloud Controller sends a request, attribute to the value of'service_id'; due to the removal of a has created the service instance, only need to know the service instance of ID, so to unprovision_service () function parameters need only one instance of the ID service.

 

1.3. Bind a service

Function: for users of an application to bind a service instance

Function: @provisioner.bind_instance (req.service_id, req.binding_options)

Parameter analysis:

Req.service_id:CloudController need to service instance application bound ID;

Req.binding_options:CloudController need to bind Options Application binding service instance, in the Cloud Foundry operation, the parameter value is empty, in addition to the parameter values in the source program only functions to store and view, does not affect the program running, which could be considered as the note binding.

Note: because in CloudFoundry, bind to a service instance, just create a credential information for a specific service instance, then the information back to the Cloud Controller, by Cloud Controller this information will be repackaged into the application, so in the process, Service Gateway involves only the corresponding service_id, without the need for specific applications program ID.

 

 

1.4. Unbind a service

Function: for the application of a bound service instance users unbind.

Function: @provisioner.unbind_instance (req.service_id, req.handle_id, req.binding_options)

Parameter analysis:

Req.service_id: service instance need to unbind the ID;

Req.handle_id: the authentication information recording service instance need to unbind the ID;

Req.binding_options: service instance when binding the binding options, the parameters in the function of the reference parameter, but the specific implementation in the function but not to use.

 

1.5. Createa snapshot

Function: create a snapshot file for a service instance

Function: @provisioner.create_snapshot (service_id)

Parameter analysis:

Service_id: the need to create a snapshot of the service instance ID.

 

1.6. Get snapshot details

Function: the specific information to get a snapshot of the service instance

Function: @provisioner.get_snapshot (service_id, snapshot_id)

Parameter analysis:

Service_id: snapshot corresponding need to obtain detailed information of the service instance ID;

Snapshot_id: a snapshot of ID need to get specific information.

 

1.7. Update snapshot name

Function: update name for an already created snapshot

Function: @provisioner.update_snapshot_name (service_id, snapshot_id, req.name)

Parameter analysis:

Service_id: the need to update the name of the corresponding snapshot service instance ID;

Snapshot_id: ID need to update the name of the snapshot;

Req.name: the name is used to update the final snapshot.

 

1.8. Get all snapshots related to an instance

Function: list of all the snapshots of a service instance

Function call: snapshots = service_snapshots (service_id)

Parameter analysis:

Service_id: the need to enumerate all the snapshot service instance ID.

     

1.9. Roll back to a snapshot

Function: to a service instance rollback to a specified snapshot

Function: @provisioner.rollback_snapshot (service_id, snapshot_id)

Parameter analysis:

Service_id: need to rollback ID service instance;

Snapshot_id: this service instance will need to roll back to the version of the specified ID snapshot.

 

1.10. Delete a snapshot

Function: a snapshot deletes a service instance

Function: @provisioner.delete_snapshot (service_id, snapshot_id)

Parameter analysis:

Service_id: need to delete the snapshot service instance ID;

Snapshot_id: need to delete ID snapshot.

     

1.11. Create a serialized URL

Function: create a serial for a service instance URL

Function: @provisioner.create_serialized_url (service_id, snapshot_id)

Parameter analysis:

Service_id: you need to create serial URL service instance ID;

Snapshot_id: ID needs to create a snapshot of the URL serial.

     

1.12. Get a serialized URL

Function: serial URL access to the specified service instance of the specified snapshot

Function: @provisioner.get_serialized_url (service_id, snapshot_id)

Parameter analysis:

Service_id: the need to obtain serial URL service instance ID;

Snapshot_id ID: the snapshot service instances need to obtain serialization in URL.

 

1.13. Import serialized data fromURL

Function: for the specified service instance into serial URL

Function: @provisioner.import_from_url (service_id, req.url)

Parameter analysis:

Service_id: the need to import the serial URL service instance ID;

Req.url: the need for specific serial URL service instance import.

 

1.14. Get job details

Function: access to the specified task information specified service instance

Function: @provisioner.job_details (service_id, job_id)

Parameter analysis:

Service_id: to get the task information service instance ID;

Job_id: the specific tasks of service instance ID.

 

1.15. Restore a service

Function: backup designated service instance

Function: @provisioner.restore_instance (req['instance_id'], req['backup_path'])

Parameter analysis:

Req['instance_id']: service instance backup ID;

Req['backup_path']: the backup path backup service instance.

 

1.16. Recovery an instance

Function: the restoration of a service instance, if a Service Node has been the collapse of words

Function: @provisioner.recover (instance_id, backup_path, resp.handles)

Call parameters:

Instance_id: the need to restore service instance ID;

Backup_path: the backup path for this service instance.

Note: in Cloud Foundry, create a snapshot and a storage service instance for service instances are not the same effect. The snapshot is the meaning of a time record of service instances, can the service instance will be rolled back some time, but the premise is to rollback the service instance still exist; when the service instance does not exist (such as Service Node, then crash) only from the backup service instance to find appropriate service instances, and do recovery.

   

1.17. Check orphans

Function: find the orphan

Function: check_orphan (resp.handles)

Parameter analysis:

Resp.handles: all set up service instance.

Note: orphan is an orphan, those in Service Node has created the Cloud in Foundry represents, and has recorded information in Service Gateway, Cloud Controller in the service instance but did not record information. These service instances are only a waste of ServiceNode resources, but in the actual process of Cloud Foundry operation, they are not used by users to (because the Cloud Controller does not exist in their records). As the "orphan" of these service instances are not reasonable, need to be cleared, and the first step is to see whether the removal of the existence of such "orphan".

   

1.18. Purge orphans

Function: excavation orphan

Function: @provisioner.purge_orphan (orphan_ins_hash, orphan_binding_hash)

Call parameters:

Orphan_ins_hash: the confirmation for all of orphan's service instance ID data type is hash type;

Orphan_binding_hash: confirmation for orphan, the Service Gateway appears to be binding, but the Cloud Controller does not know the service instance ID data type is hash type.

 

1.19. Migrate a service

Function: Service Node on the specific service instance migration

Function: @provisioner.migrate_instance (params["node_id" params["," instance_id "," params[action ")

Parameter analysis:

Params["node_id"]: the need to migrate service instances where the Service Node ID;

Params["instance_id"]: the need to be transfer service instance ID;

Params["action"]: the specific operation type migration.

 

1.20. Get services on a node

Function: get a Service Node on all service instances

Function: @provisioner.get_instance_id_list (params["node_id"])

Parameter analysis:

Params["node_id"]: the need to obtain the service instance Service Node ID all.


 

The communication mechanism of 2.ServiceGateway

By the platform of CloudFoundry, for Service Gateway, requires only two communication platform components, which are Cloud Controller and Service Node. The Service Gateway and Cloud Controller communication is accomplished by mutual send HTTP request form. In addition, Service Gateway and Service Node communication is accomplished by the Foundry Cloud NATS message middleware. The following is the analysis of the two kinds of communication mode:

  

2.1. HTTP communication

In Service Gateway, it is always the way through the HTTP to establish communication with the Cloud Controller.

Such communication can be divided into two categories:

(1).Service Gateway to obtain the HTTP request from CloudController, and the corresponding treatment.

In the first part of the function about Service Gateway, the 20 functions involved, are sending Cloud Controller to manage the request, and they are all completed by the form of HTTP. The first Service Gateway to the HTTP routing request, then the request to the corresponding processing function of processing, and finally return to the corresponding results.

(2).Service Gateway CloudController to send a HTTP request, the function sends HTTP requests are send_heartbeat, send_deactivation_notice, fetch_handles, the following will be more in-depth analysis of the function of these methods and implementation.

 

2.1.1. send_heartbeat

Function: Service Gateway CloudController to send heartbeat messages, said the Service Gateway survival, can receive the management request.

The main method to realize:

Http =EM:: HttpRequest.new (@offering_url).Post (req)

   Methods: Service Gateway analysis by HTTP Cloud Controller to send a post request, the Cloud Controller URL @offering_url, the specific request information is packaged in a req object. The following content is req:

(req=create_http_request

Head: = @cc_req_hdrs,

Body: = @svc_json

)

Note: the transmission in heartbeat. The contents include: service type Service Gateway, URL (IP and port), description.

 

2.1.2.send_deactivation_notice

Function: Service Gateway Cloud Controller to stop sending information, said the Service Gateway has stopped working.

The main method to realize:

HTTP = EM:: HttpRequest.new (@offering_url).Post (req)

Methods: Service Gateway analysis by HTTP Cloud Controller to send a post request, the Cloud Controller URL @offering_url, the specific request information is packaged in a req object.The following contents: req=create_http_request (req

Head: = @cc_req_hdrs,

Body: = @svc_json

)

 

2.1.3.fetch_handles

Function: Service Gateway access to existing service instance information to Cloud Foundry requests (including the creation of information, binding information, etc.).

The main method to realize:

Http =EM:: HttpRequest.new (@offering_url).Get (req)

Methods: Service Gateway analysis by HTTP Cloud Controller to send a post request, the Cloud Controller URL @offering_url, the specific request information is packaged in a req object. The following contents: req req=create_http_request: head =>@cc_req_hdrs

 

2.1.4.update_service_handle

Function: Service Gateway update service instance information to Cloud Controller requests (including the creation of information, binding information, etc.).

The main method to realize:

Http =EM:: HttpRequest.new (@offering_url).Get (req)

Methods: Service Gateway analysis by HTTP Cloud Controller to send a get request, the Cloud Controller URL @offering_url, the specific request information is packaged in a req object. The following contents: req=create_http_request (req

Head: = @cc_req_hdrs,

Body: = handle_json

)

 

2.2. NATS communication

In Service Gateway, NATS communication mainly exists in the Gateway and Node in Service Service.

NATS is an event driven based on the lightweight, support subscriptions and message middleware system. As the nerve center of Cloud Foundry, NATS is responsible for the communication and interaction between the components of the work.

The use of NATS in ServiceGateway is mainly to create a connection, send subscription and news release. The following is a concrete realization.

 

2.2.1. create a NATS connection

Service Gateway the use of specific to NATS to subscribe and publish news program code in the provision.rb file, which is inherited from the Provisioner class Base class.

Service Gateway specific and NATS connection establishment process is Base in this class. For the specific implementation of the code:

@node_nats= (NATS.connect: URI: mbus] = > options[)

The options[: mbus] NATS server end host node URL. The NATS code is a program package is installed in the Service Gateway node through the gem package, is quoted in the program by way of require, quoted after they can use the method in the gem package. A @node_nats object is ServiceGateway and NATS server to create a connection, and some follow-up and implementation of publish subscribe is accomplished through this object.

 

2.2.2. send subscribe and publish news

Service Gateway to send subscribe and publish a message through NATS, because when creating the connection with the NATS, has produced a NATS and server side to communicate with the @node_nats object, so every time we need to subscribe and publish news, is a reference to the object corresponding to the operation.

The type of operation on the message are the following: publish, subscribe, unsubscribe.

Publish is a component of a release of a message, this message can be other components of a subscription.

Subscribe is mainly a subscription components a message, as soon as it was announced, NATs will will distribute such information to the subscriber.

Unsubscribe is a component of a no longer a message subscription.

In the first chapter relates to the ServiceGateway function, as long as these functions will need to establish a communication Service Gateway and Service Node, then the specific code, need to @node_nats the object to realize communication.

The following is the use of NATS to establish communication place in ServiceGateway:

 

Methods check_orphan:

@node_nats.publish ("#{service_name}.check_orphan", "SendMe Handles")

    The main achievement: Service GatewayIssued a message to NATS, the content of the message for the specified type of Service Node to Service Gateway to send the specific information service instance.

 

    Methods purge_orphanIn:

    @node_nats.publish (#{service_name}.purge_orphan.#{node_id}, req.encode)

    The main achievement: Service GatewayIssued a message to NATS, the content of the message for the specified type of Service Node to the specified ID service instance in addition to dig.

 

    Methods unprovision_serviceIn:

    Timer =EM.add_timer (@node_timeout) {

@node_nats.unsubscribe (subscription)

Blk.call (timeout_fail)

}

The main view: Service Gateway on Service Node sends a request to the NATS, Service Node is overtime.

@node_nats.request (#{service_name}.unprovision.#{node_id}, request.encode)

The main achievement: Service Gateway sends a NATS request information, the request information mainly NATS responsible for find the corresponding Service Node to delete a specific service instance.

 

Methods provision_service, bind_instance, unbind_uinstance respectively in @node_nats.request (#{service_name}.provision.#{best_node}, prov_req.encode),

@node_nats.request (#{service_name}.bind.#{node_id}, request.encode) and

@node_nats.request (#{service_name}.unbind.#{node_id}, request.encode).

The main unprovision_service implementation and the three implementation of the same principle, the specific function is slightly different.

 

Methods restore_instance:

@node_nats.request (#{service_name}.restore.#{node_id}, request.encode)

The main achievement: Service Gateway sends a NATS request information, the request information to NATS is responsible for finding the corresponding Service Node to create a backup for a service instance.

 

Methods migrate_instance:

@node_nats.request (channel, message)

The main achievement: Service Gateway sends a NATS request message, transfer the request NATS responsible for finding the corresponding Service to achieve Node service.

top
Zero
tread
Zero
Guess you're looking for
View comments
* the above user comments represent the personal views do not represent the views or position of the CSDN website
    personal data
    • Visit82083 times
    • Integral:One thousand three hundred and thirty-two
    • Grade
    • Ranking:18615th
    • Original47
    • Reprint:0
    • Translation:1
    • Comment:49
    Blog column
    Contact information
    The latest comments