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) With more and more services, service URL configuration management becomes very difficult, and the F5 hardware load Balancer's single point of pressure is getting bigger.
• (2) When further development, inter-service dependencies become a complex, even unclear which application to start before which application, the architect can not fully describe the application's architectural relationship.
• (3) Then, the service is more and more calls, the capacity of the service problem is exposed, how much machine support this service needs? When should I add a machine?
• (4) More services, communication costs also began to rise, the transfer of a service failed to find who? What are the conventions for the parameters of the service?
• (5) How to ensure the service quality of a service with multiple business consumers?
• (6) With the service upgrade, there are always some unexpected things happen, such as the cache is wrong to lead to memory overflow, failure is unavoidable, each time the core services a hanging, affecting a large, people flustered panic, 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.

Conclusion:

• Regardless of the architecture we need to be modular (as far as possible module multiplexing).
• Do not architect for architecture and cause over-design.
• No matter what the architecture is to better meet the business needs, the architecture should follow the development of business.
• The current architecture, if it can meet the current business development, you can consider the next expansion, do not have to consider 3 steps 4 steps or more.

The evolutionary path of Java application architectures