mirror of
https://github.com/google/nomulus.git
synced 2025-07-24 03:30:46 +02:00
Use "Nomulus" name in documentation
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=135509458
This commit is contained in:
parent
86d8f35f79
commit
f9fe25f00a
9 changed files with 56 additions and 54 deletions
|
@ -1,11 +1,13 @@
|
|||
# App Engine architecture
|
||||
|
||||
This document contains information on the overall architecture of the Domain
|
||||
Registry project as it is implemented in App Engine.
|
||||
This document contains information on the overall architecture of Nomulus as
|
||||
pertains to App Engine.
|
||||
|
||||
[TOC]
|
||||
|
||||
## Services
|
||||
|
||||
The Domain Registry contains three
|
||||
Nomulus contains three
|
||||
[services](https://cloud.google.com/appengine/docs/python/an-overview-of-app-engine),
|
||||
which were previously called modules in earlier versions of App Engine. The
|
||||
services are: default (also called front-end), backend, and tools. Each service
|
||||
|
@ -88,10 +90,10 @@ tasks to push queues at regularly scheduled intervals, and the [MapReduce
|
|||
framework](https://cloud.google.com/appengine/docs/java/dataprocessing/) adds
|
||||
tasks for each phase of the MapReduce algorithm.
|
||||
|
||||
The Domain Registry project uses a particular pattern of paired push/pull queues
|
||||
that is worth explaining in detail. Push queues are essential because App
|
||||
Engine's architecture does not support long-running background processes, and so
|
||||
push queues are thus the fundamental building block that allows asynchronous and
|
||||
Nomulus uses a particular pattern of paired push/pull queues that is worth
|
||||
explaining in detail. Push queues are essential because App Engine's
|
||||
architecture does not support long-running background processes, and so push
|
||||
queues are thus the fundamental building block that allows asynchronous and
|
||||
background execution of code that is not in response to incoming web requests.
|
||||
However, they also have limitations in that they do not allow batch processing
|
||||
or grouping. That's where the pull queue comes in. Regularly scheduled tasks in
|
||||
|
@ -99,12 +101,12 @@ the push queue will, upon execution, poll the corresponding pull queue for a
|
|||
specified number of tasks and execute them in a batch. This allows the code to
|
||||
execute in the background while taking advantage of batch processing.
|
||||
|
||||
Particulars on the task queues in use by the Domain Registry project are
|
||||
specified in the `queue.xml` file. Note that many push queues have a direct
|
||||
one-to-one correspondence with entries in `cron.xml` because they need to be
|
||||
fanned-out on a per-TLD or other basis (see the Cron section below for more
|
||||
explanation). The exact queue that a given cron task will use is passed as the
|
||||
query string parameter "queue" in the url specification for the cron task.
|
||||
The task queues used by Nomulus are configured in the `queue.xml` file. Note
|
||||
that many push queues have a direct one-to-one correspondence with entries in
|
||||
`cron.xml` because they need to be fanned-out on a per-TLD or other basis (see
|
||||
the Cron section below for more explanation). The exact queue that a given cron
|
||||
task will use is passed as the query string parameter "queue" in the url
|
||||
specification for the cron task.
|
||||
|
||||
Here are the task queues in use by the system. All are push queues unless
|
||||
explicitly marked as otherwise.
|
||||
|
@ -159,9 +161,9 @@ explicitly marked as otherwise.
|
|||
* `load[0-9]` -- Queues used to load-test the system by `LoadTestAction`.
|
||||
These queues don't need to exist except when actively running load tests
|
||||
(which is not recommended on production environments). There are ten of
|
||||
these queues to provide simple sharding, because the Domain Registry system
|
||||
is capable of handling significantly more Queries Per Second than the
|
||||
highest throttle limit available on task queues (which is 500 qps).
|
||||
these queues to provide simple sharding, because Nomulus is capable of
|
||||
handling significantly more Queries Per Second than the highest throttle
|
||||
limit available on task queues (which is 500 qps).
|
||||
* `lordn-claims` and `lordn-sunrise` -- Pull queues for handling LORDN
|
||||
exports. Tasks are enqueued synchronously during EPP commands depending on
|
||||
whether the domain name in question has a claims notice ID.
|
||||
|
@ -184,10 +186,10 @@ explicitly marked as otherwise.
|
|||
|
||||
## Environments
|
||||
|
||||
The domain registry codebase comes pre-configured with support for a number of
|
||||
different environments, all of which are used in Google's registry system. Other
|
||||
registry operators may choose to user more or fewer environments, depending on
|
||||
their needs.
|
||||
Nomulus comes pre-configured with support for a number of different
|
||||
environments, all of which are used in Google's registry system. Other registry
|
||||
operators may choose to user more or fewer environments, depending on their
|
||||
needs.
|
||||
|
||||
The different environments are specified in `RegistryEnvironment`. Most
|
||||
correspond to a separate App Engine app except for `UNITTEST` and `LOCAL`, which
|
||||
|
@ -202,8 +204,8 @@ The full list of environments supported out-of-the-box, in descending order from
|
|||
real to not, is:
|
||||
|
||||
* `PRODUCTION` -- The real production environment that is actually running
|
||||
live TLDs. Since the Domain Registry is a shared registry platform, there
|
||||
need only ever be one of these.
|
||||
live TLDs. Since Nomulus is a shared registry platform, there need only ever
|
||||
be one of these.
|
||||
* `SANDBOX` -- A playground environment for external users to test commands in
|
||||
without the possibility of affecting production data. This is the
|
||||
environment new registrars go through
|
||||
|
@ -287,7 +289,7 @@ cron.xml is:
|
|||
|
||||
## Cloud Datastore
|
||||
|
||||
The Domain Registry platform uses [Cloud
|
||||
Nomulus uses [Cloud
|
||||
Datastore](https://cloud.google.com/appengine/docs/java/datastore/) as its
|
||||
primary database. Cloud Datastore is a NoSQL document database that provides
|
||||
automatic horizontal scaling, high performance, and high availability. All
|
||||
|
@ -388,15 +390,14 @@ registry codebase:
|
|||
|
||||
## Cloud Storage buckets
|
||||
|
||||
The Domain Registry platform uses [Cloud
|
||||
Storage](https://cloud.google.com/storage/) for bulk storage of large flat files
|
||||
that aren't suitable for Datastore. These files include backups, RDE exports,
|
||||
Datastore snapshots (for ingestion into BigQuery), and reports. Each bucket name
|
||||
must be unique across all of Google Cloud Storage, so we use the common
|
||||
recommended pattern of prefixing all buckets with the name of the App Engine app
|
||||
(which is itself globally unique). Most of the bucket names are configurable,
|
||||
but the defaults are as follows, with PROJECT standing in as a placeholder for
|
||||
the App Engine app name:
|
||||
Nomulus uses [Cloud Storage](https://cloud.google.com/storage/) for bulk storage
|
||||
of large flat files that aren't suitable for Datastore. These files include
|
||||
backups, RDE exports, Datastore snapshots (for ingestion into BigQuery), and
|
||||
reports. Each bucket name must be unique across all of Google Cloud Storage, so
|
||||
we use the common recommended pattern of prefixing all buckets with the name of
|
||||
the App Engine app (which is itself globally unique). Most of the bucket names
|
||||
are configurable, but the defaults are as follows, with PROJECT standing in as a
|
||||
placeholder for the App Engine app name:
|
||||
|
||||
* `PROJECT-billing` -- Monthly invoice files for each registrar.
|
||||
* `PROJECT-commits` -- Daily exports of commit logs that are needed for
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue