5.0 KiB
Google Service Management manages a set of services. Service Management allows service producers to publish their services on Google Cloud Platform so that they can be discovered and used by service consumers. It also handles the tasks of tracking service lifecycle and programming various backend systems -- such as Stackdriver Logging, Stackdriver Monitoring -- to support the managed services.
If you are a service producer, you can use the Google Service Management API and Google Cloud SDK (gcloud) to publish and manage your services. Each managed service has a service configuration which declares various aspects of the service such as its API surface, along with parameters to configure the supporting backend systems, such as logging and monitoring. If you build your service using Google Cloud Endpoints, the service configuration will be handled automatically.
If you are a service consumer and want to use a managed service, you can use the Google Service Management API or Google Cloud Console to activate the service for your Google developer project, then start using its APIs and functions.
Managed services
REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}
REST schema is defined here.
A managed service refers to a network service managed by
Service Management. Each managed service has a unique name, such as
example.googleapis.com, which must be a valid fully-qualified DNS name, as per
RFC 1035.
A managed service typically provides some REST APIs and/or other functions to their service consumers, such as mobile apps or cloud services.
Service producers can use methods, such as services.create, services.delete, services.undelete, to manipulate their managed services.
Service producers
A service producer is the Google developer project responsible for publishing and maintaining a managed service. Each managed service is owned by exactly one service producer.
Service consumers
A service consumer is a Google developer project that has enabled and can invoke APIs on a managed service. A managed service can have many service consumers.
Service configuration
REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}/configs/{config_id}
REST schema is defined here.
Each managed service is described by a service configuration which covers a wide range of features, including its name, title, RPC API definitions, REST API definitions, documentation, authentication, and more.
To change the configuration of a managed service, the service producer needs to publish an updated service configuration to Service Management. Service Management keeps a history of published service configurations, making it possible to easily retrace how a service's configuration evolved over time. Service configurations can be published using the services.configs.create or services.configs.submit methods.
Alternatively, services.configs.submit allows publishing an
OpenAPI specification, formerly
known as the Swagger Specification, which is automatically converted to a
corresponding service configuration.
Service rollout
REST URL: https://servicemanagement.googleapis.com/v1/services/{service-name}/rollouts/{rollout-id}
REST schema is defined here.
A Rollout defines how Google Service Management should deploy service
configurations to backend systems and how the configurations take effect at
runtime. It lets service producers specify multiple service configuration
versions to be deployed together, and a strategy that indicates how they
should be used.
Updating a managed service's configuration can be dangerous, as a configuration error can lead to a service outage. To mitigate risks, Service Management supports gradual rollout of service configuration changes. This feature gives service producers time to identity potential issues and rollback service configuration changes in case of errors, thus minimizing the customer impact of bad configurations. For example, you could specify that 5% of traffic uses configuration 1, while the remaining 95% uses configuration 2.
Service Management keeps a history of rollouts so that service
producers can undo to previous configuration versions. You can rollback a configuration
by initiating a new Rollout that clones a previously submitted
rollout record.