Shulou(Shulou.com)06/02 Report--

It is believed that many inexperienced people are at a loss about what the 12 architectural specifications of Saas are. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

I. introduction

Today, software is usually delivered as a service, and they are called web applications, or software as a service (SaaS). 12-Factor provides a methodology for building the following SaaS applications:

Use a standardized process to automate configuration so that new developers can join the project at the lowest learning cost.

Draw a clear line between the operating system and the operating system as much as possible to provide maximum portability in each system.

Suitable for deployment on modern cloud computing platforms, thereby saving resources in server and system management.

Minimize the differences between the development environment and the production environment and implement agile development using continuous delivery.

Extensions can be implemented without significant changes in tools, architecture, and development processes.

This theory applies to applications developed in any language and back-end services (database, message queue, cache, etc.).

Second, twelve architectural specifications 1. Unified source code management system

One benchmark code (Codebase), multiple deployments (deploy)

In a centralized version control system like SVN, the benchmark code refers to this code base in the control system, while in a distributed version control system like Git, the benchmark code refers to the upstream code base.

There is always an one-to-one correspondence between the benchmark code and the application:

Once there are multiple benchmarks, it cannot be called an application, but a distributed system. Each component in the distributed system is an application, and each application can be developed using 12-Factor separately.

It is against the 12-Factor principle that multiple applications share a benchmark code. The solution is to split the shared code into separate class libraries and then use dependency management strategies to load them.

two。 Dependency management

Explicitly declare dependencies

Most programming languages provide a packaging system to provide packaging services for various class libraries, such as Perl's CPAN or Ruby's Rubygems. The class libraries installed by the packaged system can be system-level (called "site packages") or can be used only by an application and deployed in the appropriate directory (called "vendoring" or "bunding")

Applications under 12-Factor rules do not implicitly rely on system-level class libraries. It must declare all dependencies exactly through the dependency list. In addition, rely on the isolation tool to ensure that the program does not call dependencies that exist in the system but are not declared in the list. This approach will be applied uniformly to the production and development environments.

One of the advantages of explicitly declaring dependencies is that it simplifies the environment configuration process for new developers. New developers can check out the application's benchmark code, install the programming language environment and its corresponding dependency management tools, and simply install all the dependencies through a build command, such as Maven,Pip,Npm, etc.

12-Factor applications also do not implicitly rely on certain system tools, such as ImageMagick or curl. Even if these tools exist in almost all systems, there is no guarantee that all future systems will run smoothly or be compatible with applications. If the application must use certain system tools, then these tools should be included in the application.

3. Configuration management

Store configurations in the environment

In general, the configuration of an application varies greatly between different deployments (pre-release, production environment, development environment, and so on). These include:

Configuration of the 0 database, Memcached, and other back-end services

Certificates and credentials of third-party services, such as Amazon S3, Twitter, etc.

Each deployment-specific configuration, such as domain name, etc.

The application does not allow the configuration to be stored as a constant in the code, which requires strict separation of the configuration from the code. The configuration varies widely from deployment to deployment, while the code does not. In addition, this definition of "config" does not include internal application configuration, which does not vary from deployment to deployment, so it is best to save it in your code

Tip: the touchstone of whether the application has correctly allocated all the configurations in the code is whether the code base can become open source at any time without worrying about leaking any sensitive credentials.

The application should store the configuration in the environment variable (usually abbreviated to env vars or env). You can easily change Env variables between deployments without changing any code; unlike configuration files, they have little chance of being accidentally checked into the code repository; and unlike custom configuration files or other configuration mechanisms, such as Java system properties, they are language-and operating system-independent standards.

4. Back-end service

Use back-end services (backing services) as additional resources

The back-end service refers to all kinds of services called through the network for the program to run, such as database (MySQL,CouchDB), message / queue system (RabbitMQ,Beanstalkd), SMTP mail sending service (Postfix), and cache system (Memcached).

Back-end services similar to databases are usually managed by the system administrator who deploys the application. In addition to local services, it is possible that applications use services published and managed by third parties. Examples include SMTP (such as Postmark), data collection services (such as New Relic or Loggly), data storage services (such as Amazon S3), and services accessed using API (such as Twitter, Google Maps, Last.fm).

12-Factor applications do not discriminate between local or third-party services. For applications, both are additional resources that obtain data through a url or other service location / service certificate stored in the configuration. Any deployment of a 12-Factor application should be able to replace the local MySQL database with a third-party service (such as Amazon RDS) without any code changes. Similarly, local SMTP services should also be interchangeable with third-party SMTP services such as Postmark. In the above two examples, only the resource address in the configuration needs to be modified.

12-Factor applications treat these as additional resources that are loosely coupled with their attached deployments.

5. Build, publish, run

Strictly separate build and run

Transforming the benchmark code into a deployment (non-development environment) requires the following three phases:

The build phase refers to the process of transforming a code repository into an executable package. The specified version of the code is used during the build, the dependencies are acquired and packaged, and compiled into binaries and resource files.

The release phase combines the results of the build with the configuration required for the current deployment and can be immediately put into use in the running environment.

The runtime (or "runtime") refers to starting a series of application processes in the execution environment for the selected release.

12-factor applications strictly distinguish between the three steps of building, releasing, and running. For example, it is not advisable to modify running code directly because it is difficult to synchronize these changes back to the build steps.

Each release must correspond to a unique release ID, for example, you can use a timestamp at the time of release (2011-04-06-20:32:17), or a growing number (v100). A released version is like an account book that can only be appended, once released, it cannot be modified, and any changes should result in a new release. It also makes it easy to fall back to any historical version without having to risk rebuilding.

The new code requires the developer to trigger the build operation before it can be deployed. However, the run phase does not necessarily need to be triggered artificially, but can be done automatically. For example, the server restarts or the process manager restarts a crashed process. Therefore, the runtime should keep as few modules as possible, so assuming that a system failure occurs in the middle of the night and the developer is stretched, it will not cause too much problem. The build phase can be relatively complex because error messages can be immediately displayed in front of developers and properly handled.

6. Process

Run the application as one or more stateless processes

In a running environment, applications typically run as one or more processes.

The processes of 12-Factor applications must be stateless and unshared. Any data that needs to be persisted is stored in a back-end service, such as a database.

The memory area or disk space can be used as a cache for a process to do some transactional operation, such as the process of downloading a large file, operating on it, and writing the results to the database. 12-Factor applications do not have to consider whether the contents of these caches can be reserved for later requests, because the application starts many types of processes, and future requests are mostly served by other processes. Even if there is only one process, previously saved data (in memory or file system) is lost due to restart, such as code deployment, configuration changes, or running environment to schedule the process to another physical area for execution.

Some systems rely on "sticky session", which means caching data from a user's session into the memory of a process and routing subsequent requests from the same user to the same process. Sticky session is strongly opposed by 12-Factor. Data in Session should be kept in a cache with expiration time, such as Memcached or Redis.

7. Port binding

Provide services through port binding (Port binding)

Applications sometimes run in the server's container. For example, PHP often runs as a module of Apache HTTPD, just as Java runs on Tomcat.

12-Factor applications can completely load themselves without relying on any network server to create a network-oriented service. Internet applications provide services through port binding and listen for requests sent to that port.

It is also pointed out that port binding also means that one application can become a back-end service for another application, and the caller stores the corresponding URL provided by the server as a resource in the configuration for future invocation.

8. Concurrence

Extend through the process model

In 12-factor applications, processes are first-class citizens. The process of 12-Factor application mainly draws lessons from the unix daemon model. Developers can use this model to design application architectures and assign different tasks to different process types. For example, HTTP requests can be handed over to the web process, while resident background work can be left to the worker process.

The above process model will shine when the system is in urgent need of expansion. The process of 12-Factor applications has no sharing, and the feature of horizontal partitioning means that it is easy and safe to add concurrency. The types of these processes and the number of processes in each type are called process composition.

9. Easy to handle

Fast start and graceful termination maximize robustness

The processes of 12-Factor applications are disposable, meaning that they can be started or stopped instantly. This is conducive to fast, flexible scalable applications, rapid deployment of changed code or configuration, and robust deployment of applications.

The process should pursue a minimum startup time. Ideally, the process should take only a short time from typing a command to actually starting and waiting for a request. Less startup time provides a more agile release and extension process, as well as increased robustness because the process manager can easily move the process to a new physical machine under authorization.

In addition, once the process receives the termination signal (SIGTERM), it terminates gracefully. In the case of a network process, graceful termination refers to stopping the port of the listening service, that is, rejecting all new requests, continuing to execute the currently received requests, and then exiting. The implicit requirement for this type of process is that most HTTP requests are short (no more than a few seconds), while in long polling, the client should try to reconnect immediately after losing the connection; for worker processes, graceful termination means returning the current task to the queue.

10. The development environment is consistent with the online environment.

Keep the development, pre-release and online environment the same as possible

There are many differences between the development environment (that is, the local deployment of developers) and the online environment (the real deployment accessed by external users). These differences are shown in the following three aspects:

Time difference: the code that developers are writing may take days, weeks, or even months to come online.

Personnel differences: developers write code, operators deploy code.

Tool differences: developers may use Nginx,SQLite,OS X, while online environments use Apache,MySQL and Linux.

If 12-Factor applications are to be deployed continuously, they must narrow the gap between local and online. Looking back at the three differences described above:

Narrow the time gap: developers can deploy code in hours or even minutes.

Narrow the staff gap: developers should not only write code, but also be closely involved in the deployment process and the performance of the code online.

Narrow the tool gap: try to ensure the consistency of the development environment and the online environment.

Turn the above summary into a table as follows:

Traditional application

12-Factor application

Each deployment interval

A few weeks

Few hours

Developer vs operation and maintenance staff

Different people

The same person

Development environment vs online environment

Different

Get as close as possible

Developers of 12-Factor applications should object to using different back-end services between different environments, even though adapters can almost eliminate differences in usage. This is because different back-end services mean sudden incompatibility, resulting in online problems with code with normal testing and pre-release. These errors can create resistance to continued deployment. From the point of view of the life cycle of the application, it is costly to remove this resistance.

11. Journal

Treat the log as an event stream

Logging makes the actions that the application runs transparent. In a server-based environment, the log is usually written to a file on the hard disk, but this is only an output format.

12-factor applications themselves never consider storing their own output streams. You should not attempt to write or manage log files. Instead, each running process has a direct stream of standard output (stdout) events. In the development environment, developers can see the activity of the application on the terminal in real time through these data streams.

In pre-release or online deployment, the output stream of each process is intercepted by the running environment, other output streams are grouped together, and then sent to one or more final handlers for viewing or long-term archiving. These archive paths are not visible or configurable for the application, but are entirely managed by the running environment of the program. Open source tools like Logplex and Fluentd can do this.

These event streams can be output to a file or watched in real time at the terminal. Most importantly, the output stream can be sent to a log indexing and analysis system such as Splunk, or to a general data storage system such as Hadoop/Hive. These systems provide powerful and flexible features for viewing the historical activities of applications, including:

Find out the special events of the past.

Graphically a large-scale trend, such as requests per minute.

Triggers an alarm in real time according to user-defined conditions, such as an error per minute that exceeds a warning line.

twelve。 Management process

Background management tasks run as an one-time process

Process composition (process formation) is a set of processes used to handle the general business of an application, such as processing web requests. In contrast, developers often want to perform one-time tasks of managing or maintaining applications, such as:

Run the data migration (manage.py migrate in Django, rake db:migrate in Rails).

Run a console (also known as REPL shell) to execute some code or do some checks on the online database. Most languages provide a REPL tool (python or perl) through the interpreter, or other commands (Ruby uses irb, Rails uses rails console).

Run some one-time scripts that are submitted to the code repository.

An one-time management process should use the same environment as a normal resident process. These administrative processes use the same code and configuration as any other process and run based on a release. Background management code should be released with other application code to avoid synchronization problems.

After reading the above, have you mastered the method of applying the 12 architectural specifications of Saas? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.