How to Achieve A Scalable Large-scale Website Architecture?

Source: Internet
Author: User
Keywords scalable website architecture website architecture how to create a website architecture

The scalable architecture design of the website is the ability to sustainably expand and improve system functions with minimal impact on the existing system.

Here, the concepts of "scalability" and "scalability" that are easily confused are explained in detail:
Alibaba Cloud Simple Application Server:  Anti COVID-19 SME Enablement Program
$300 coupon package for all new SMEs and a $500 coupon for paying customers.

Scalability

Performance is: infrastructure does not need to be changed frequently, applications are less dependent or coupled, and can quickly respond to demand changes. It is open for extension and closed for modification. The architecture design will take into account the scalability of future functions, so when new functions are added to the system, there is no need to modify the structure and code of the existing system.

Scalability

It means that the system enhances (or reduces) the ability to process business by increasing (or reducing) its own resource scale. If this increase or decrease is proportional, it can be called linear scalability. Usually, the cluster is used to increase the number of  servers to improve the overall business throughput of the system.

1 Build a scalable website architecture
An important measure of the pros and cons of a development framework, design pattern, or programming language is whether it can make the software development process and software products less coupled.

Because a low-coupling system is easier to expand and easier to reuse, and it also makes the development process and maintenance easier. But how to decompose each module of the system, how to define the interface of each module, how to reuse and combine different modules to construct a complete system, this is the most challenging part of software design.

The greatest value of a software architect lies in the ability to decompose a large system into N low-coupling sub-modules. These sub-modules include horizontal business modules and vertical basic technology modules. This ability comes from professional technical ability and experience, understanding of business scenarios, grasp of human nature, and understanding of the world.

The core idea of building an extensible website architecture is modularity, and on this basis, it reduces the coupling between modules and improves the reusability of modules.

The software can be divided into several low-coupling, independent component modules by means of layering and segmentation, and then aggregated into a complete system by means of message passing or dependent calls among these component modules.

These modules can be deployed on independent  servers through distributed deployment. This physical separation of the coupling relationship between the modules can further reduce the coupling.

The aggregation methods after distributed deployment of modules are:

* Distributed message queue.

* Distributed services.

1 Use distributed message queues to reduce coupling
If there is no direct calling relationship between the modules, then adding or modifying modules will have the least impact on other parts, so the scalability is naturally better.

1.1 Event Driven Architecture

Event-driven architecture refers to the transmission of event messages between low-coupling modules, maintaining loose coupling between modules, and completing communication between modules through event messages. The most common implementation of event-driven architecture is to use distributed message queues.

The message queue works based on the publish-subscribe model, where the message sender publishes the message, and one or more message receivers subscribe to the message. After the message sender sends the message to the distributed message queue, the processing is completed, and then the message subscriber obtains the message from the message queue for processing. For new services, as long as you are interested in a certain message, you can subscribe to the message, and this has no effect on the original system and business, so as to realize the scalability design of the system.

The message receiver can also reconstruct the received message, define a new message type, and then send the message to the receiver who has subscribed to this new message type. So the event-driven architecture based on message objects can be a series of processes.

Because the message sender can return without waiting, the system has a better response time; and during peak visits, the message can be temporarily stored in the message queue, thereby reducing the storage load pressure of the database.

1.2 Distributed message queue

Queue is a first-in, first-out data structure, we can deploy the message queue to an independent  server. The application uses the message queue through the remote access interface to perform message access operations, thereby realizing distributed asynchronous calls:


The more popular distributed message queue is Apache ActiveMQ.

Because the data on the message queue server can be regarded as instant processing, in terms of scalability, after we add the new server to the distributed message queue cluster, we only need to notify the producer server to change the server list of the message queue. O( ∩_∩)O~

In terms of availability, if the memory queue is full, messages must be written to disk, so that when the message push module has processed the messages in the memory queue, it will load the messages in the disk into the queue to continue processing.

In order to avoid message loss caused by the downtime of the message queue server, the message will be stored on the message producer server, so that the message will not be deleted until it is actually processed by the message consumer server. If the message queue server goes down, the producer server will choose other servers in the distributed message queue server cluster to publish messages.

Distributed message queues can be very complex, such as supporting ESB (Enterprise Service Bus) and SOA (Service Oriented Architecture). It can also be very simple, such as using MySQL as a distributed message queue: the producer of the message writes the message as a record to the database, and the consumer queries the database (sorted by the timestamp of the record written to the database table), this is a distributed message queue La. Coupled with mature MySQL operation and maintenance methods, a higher availability and performance index can also be achieved O(∩_∩)O~

2 Use distributed services to build a reusable business platform
Distributed services can reduce the coupling of the system through interfaces, and different subsystems use the same interface description to call services.

With the increasing complexity of website functions, the system will gradually develop into a giant with a large number of applications and service components. Such a system will bring huge troubles to development, maintenance, and deployment:

* Difficult to compile and deploy.

* Difficulty in code branch management: The reused code modules are maintained and modified by multiple teams, so conflicts will always occur when the code is merged.

* Exhausted database connections: Assuming an application has 10 database connections, then an application with hundreds of server clusters will create thousands of connections on the database.

* Added business difficulties. Adding new business in such a constantly cutting and chaotic system? Just kidding O(∩_∩)O~

So we need to split and deploy the modules independently to reduce the coupling of the system:

* Vertical split-split a large application into multiple small applications. If the new business is relatively independent, design and deploy it directly as an independent Web application.

* Horizontal split-split the reused business and independently deploy it as a distributed service. The newly added business only needs to call these distributed services to quickly build an application system. Even if the business logic in the module changes, as long as the interface is consistent, it will not affect other modules.

Vertical splitting is relatively simple. By sorting out the business, the less-related business is separated to make it an independent Web application. Horizontal splitting not only requires identifying reusable businesses, designing service interfaces, and standardizing the dependencies between services, but also requires a complete distributed service management framework.

2.1 Web Service Distributed Service

Web Service used to be one of the most fashionable vocabulary in the field of enterprise application system development. It is used to integrate heterogeneous systems and build distributed systems:

The service provider uses WSDL (Web Services Description Language, Web Service Description Language) to describe the service interface content that it can provide to the registry (Service Broker), and then the registry uses UDDI (Universal Description, Discovery, and Integration, unified description, Discovery and Integration) Publish services provided by service providers. After the service requester retrieves the service from the registry, it communicates with the service provider through SOAP (Simple Object Access Protocol) to use the service.

Although Web Service has mature technical specifications and implementations, it has the following disadvantages:

1. Bulky registration and discovery mechanism.

2. Inefficient XML serialization methods.

3. The expensive HTTP remote communication.

4. Complex deployment and maintenance methods.

These problems make it difficult for Web Services to meet the requirements of large websites for high performance, high availability, easy deployment and easy maintenance.
Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.