The evolutionary path of Java application architectures

The evolutionary path of Java application architectures

When we set up a system, we usually need to think about how to interact with other systems, so we first need to know how the various systems interact with each other and what technology is implemented.

1. Interactions between different languages of different systems

Now we commonly use webservice,http requests for interaction between different languages of different systems. WebService, or "Web service", abbreviated to WS. Literally, it is "WEB-based service." But the service is both sides, has the service demand side, has the service provider. The service provider publishes the service, and the service demand party invokes the service published by the service provider. If you're more professional, WS is actually a tool for communicating with heterogeneous systems on the HTTP protocol. That's right! WS is still based on the HTTP protocol, that is, the data is transmitted over HTTP. First we implemented WS with CXF development SOAP service, and later we implemented WS with REST service (this is the one that uses more and the most I use). Rest services can also be developed based on CXF, but we generally implement rest services directly using SPRINGMVC or other MVC frameworks.

But in many people's impressions, Web service generally refers to a variety of XML-based interactive technologies that were led by IBM 10 years ago, and it is now rare for some companies to use them in addition to others. Broadly speaking WebService is the Web service, all services.

2. Interactions between different systems in the same language

Common interactions between the same languages of different systems with RPC (remote procedure Call), or RMI (remote method call) implementations, without service to the outside, of course, the above can also be used in the same language between the interaction, but I often use RPC.

Architecture for different products

3. Architectural Evolution of individual products

Generally we are just a product of the case of the architectural evolution process, if you need to provide webservice, usually using the rest service implementation.

The following section is from

1. Evolution of distributed Architectures Evolution System architecture-initial stage architecture

The initial stage of the small system applications, databases, files, and all the resources are commonly called lamp on a single server

Features: All resources, such as applications, databases, files, and so on, are on a single server.

Description: Usually the server operating system uses Linux, the application uses PHP development, and then deployed on Apache, the database uses MySQL, a variety of free open source software and a cheap server can begin the development of the system.

2. System Architecture Evolution-separation of application services and data Services

Not long, found that with the increase in the number of system visits, webserver machine pressure in the peak will rise to a relatively high, this time began to consider adding a webserver

Features: Applications, databases, and files are deployed separately on separate resources.

Description: Data volume increased, single server performance and storage space is not enough, need to separate applications and data, concurrent processing power and data storage space has been greatly improved.

3. System architecture Evolution-using caching to improve performance

Features: A small subset of data accessed in a database is stored in a cache server, reducing the number of accesses to the database and reducing the access pressure on the database.

Description: System Access features follow the 28 law, which means that 80% of business access is concentrated on 20% of the data. The cache is divided into local cache and remote distributed cache, where local cache access is faster but the amount of cached data is limited, while there is contention for memory with the application.

4. System architecture Evolution-using the Application server cluster

After doing the work of the sub-Library, the pressure on the database has dropped to a relatively low, and began to watch the daily traffic surge of happy life, suddenly one day, found that the system's visit began to slow trend, this time first to view the database, pressure all normal, then view webserver, found that Apache blocked a lot of requests, and the application server for each request is also relatively fast, it appears that the number of requests is too high resulting in the need to queue waiting, slow response

Features: multiple servers provide services externally through load balancing, addressing the problem of single-server processing power and storage-space ceilings.

Description: Using clusters is a common means of solving high concurrency and massive data problems. By appending resources to the cluster, it can improve the concurrency of the system, so that the load pressure of the server is no longer a bottleneck of the whole system.

5. System Architecture Evolution-Database read/write separation

Enjoy a period of time the system visits the high-speed growth of happiness, the discovery system began to slow down, this is what the situation, after looking, found that the database write, update some of these operations of the database connection resource competition is very fierce, causing the system to become slow

Features: multiple servers provide services externally through load balancing, addressing the problem of single-server processing power and storage-space ceilings.

Description: Using clusters is a common means of solving high concurrency and massive data problems. By appending resources to the cluster, the load pressure on the server does not become the bottleneck of the whole system.

6. System Architecture Evolution-Reverse Proxy and CDN acceleration

Feature: Use CDN and reverse proxy to speed up system access.

Description: To cope with complex network environments and access by users in different regions, speed up user access through CDN and reverse proxies while reducing load pressure on back-end servers. The rationale for both CDN and reverse proxies is caching.

7. System Architecture Evolution-Distributed File system and distributed database

With the continuous operation of the system, the volume of data began to grow substantially, this time to find the library after the query will still be a little slow, so according to the idea of the library began to do the work of the sub-table

Characteristics: The database adopts distributed database, and the file system adopts distributed File system.

Description: Any powerful single server can not meet the continuous growth of the business needs of large-scale systems, database read and write separation with the development of the business will eventually not meet the requirements, need to use distributed database and distributed file system to support. Distributed database is the last method of system database splitting, only used when the scale of single table data is very large, the more commonly used database splitting means is the business sub-Library, and the different business databases are deployed on different physical servers.

8. System Architecture Evolution Process-usingNoSQL and search engines

Features: The system introduces NoSQL databases and search engines.

Description: As the business becomes more complex, the need for data storage and retrieval is becoming more complex, and the system needs to adopt some non-relational databases such as NoSQL and sub-database query technologies such as search engines. The application server accesses various data through a unified data access module, alleviating the hassle of application management of many data sources.

9. Evolution of system architecture-business split

Feature: The system is split by business, and the application server is deployed separately according to the business distinction.

Description: In order to deal with the increasingly complex business scenarios, it is common to divide and conquer the entire system business into different product lines, to establish relationships between applications through hyperlinks, to distribute data through message queues, and, of course, to form an associated complete system by accessing the same data storage system. Split vertically: Split a large application into smaller applications, and if the new business is more independent, it is relatively simple to deploy its design directly as a standalone Web application system, and by combing the business, it will be less relevant to the business stripping. Horizontal split: Splitting the reused business and deploying it separately as a distributed service, the new business only needs to call these distributed services. Horizontal split needs to identify reusable businesses, design service interfaces, and standardize service dependencies.

10. System Architecture Evolution-distributed services

Features: Public application modules are extracted and deployed on distributed servers for provisioning with server calls. Description: As the business becomes smaller, the overall complexity of the application system increases exponentially, because all applications are connected to all database systems, resulting in insufficient database connection resources and denial of service.

Q: What are the issues with distributed service applications?

• (1) As the service becomes more and more difficult, the service URL configuration management becomes very hard, and the single point of pressure of the F5 hardware load balancer is getting larger.

• (2) When further development, inter-service dependencies become more complex, even confusing which application to start before, the architect can not fully describe the architectural relationship of the application.

• (3) Next, the number of calls to the service is increasing, and the capacity problem of the service is exposed, how much machine support does the service require? When should I add a machine?

• (4) More services, communication costs began to rise, to call a service failed to find who? What are the conventions for the parameters of the service?

• (5) A service with multiple business consumers, how to ensure the quality of service?

• (6) With the service upgrade, there are always some unexpected things happen, such as the cache is wrong to cause memory overflow, failure inevitable, each time the core services a hanging, affecting a large, people flustered, how to control the impact of the fault surface? is the service capable of degrading functionality? or resource deterioration?

This seems to be a large web site technology architecture Core Principles and case analysis of the beginning of the content, but the author summed up well, I will reprint it.

4. Structure of the product line

There is also a business split that is mentioned above. Now we need to make a product line, we only need a data layer, a common business logic layer, front of a variety of applications and interface layer, do not need external system (external company's system) to provide services, we generally choose to use EJB and so on to build distributed applications, but now we can use Dobbo, RPC frameworks such as thrift, Avro, and Hessian are used to build distributed applications that enable interaction between different applications and data sources. In this structured mode we need to provide services to other companies and can write an application that provides rest services to external systems. In general, most Internet services have access to more than 10 or even hundreds of internal services, and the communication between them is generally RPC: like accessing a remote method, the input parameter waits for the result to be returned. This is the easiest way to understand how to build complex systems.

such as the model, file system, cache those not drawn out, everyone understands on the line.

The evolutionary path of Java application architectures