How Java architecture is applied to different products

When we set up a system, we usually need to consider how to interact with other systems, so we first need to know how various systems interact with each other and what technology is used to implement it.

1. Interaction between different systems and different languages

Now our common interactions between different systems and different languages ​​use WebService and Http requests. WebService, that is, "Web service", abbreviated as WS. Literally understood, it is actually a "Web-based service". But services are for both parties. If there is a service demander, there will be a service provider. The service provider publishes services to the outside world, and the service demander calls the services published by the service provider. To put it more professionally, WS is actually a tool built on the HTTP protocol to achieve heterogeneous system communication. That's right! To put it bluntly, WS is based on the HTTP protocol, that is to say, data is transmitted through HTTP. At first we used CXF to develop SOAP services to implement WS, and later we used REST services to implement WS (this is currently used more often, and it is also the one I use the most). REST services can also be developed based on CXF, but we generally use springMVC or other MVC frameworks directly to implement REST services.

But in many people’s minds, Web services generally refer to various XML-based interactive technologies that IBM led more than ten years ago. Nowadays, except for some companies, few people use them. In a broad sense, Webservice is a Web service, and everything is a service.

2. Interaction between different systems with the same language

Common interactions between different systems with the same language use RPC (Remote Procedure Call), or RMI (Remote Method call) is implemented without providing external services. Of course, the above mentioned can also be used for interaction between the same languages, but I usually use RPC.

Architecture of different products

3. Architecture evolution of a single product

Generally, we only have one product, if necessary. To provide webService to the outside world, it is usually implemented using REST service.

The following content comes from Zhihu

1) Evolution of distributed architecture System architecture evolution process-initial stage architecture

In the initial stage, all resources of small system applications, databases, files, etc. are on one server, commonly known as LAMP

Features: applications, databases, files Wait until all resources are on one server.

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

2) Evolution of system architecture - separation of application services and data services

The good times did not last long, and it was found that with the increase in the number of system visits increases again, the pressure on the webserver machine will rise to a relatively high level during peak periods. At this time, consider adding a webserver

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

Description: The amount of data increases, the performance and storage space of a single server are insufficient, and applications and data need to be separated. The concurrent processing capability and data storage space have been greatly improved.

3) Evolution of system architecture - using cache to improve performance

Features: A small portion of the data in the database is accessed more intensively Stored in the cache server, reducing the number of database accesses and reducing database access pressure.

Description: System access characteristics follow the 80/20 rule, that is, 80% of business access is concentrated on 20% of data. The cache is divided into local cache and remote distributed cache. The local cache has faster access speed but the amount of cached data is limited. At the same time, it may compete with the application for memory.

4) Evolution of system architecture - using application server cluster

After completing the work of sub-database and sub-table, the database The pressure on the system has dropped to a relatively low level, and I have begun to live a happy life of watching the number of visits increase every day. Suddenly one day, I found that the access to the system has begun to slow down again. At this time, I first checked the database. The pressure Everything was normal. After checking the webserver, I found that apache blocked a lot of requests, and the application server was relatively fast for each request. It seemed that the number of requests was too high, which caused the need to wait in line and the response speed became slower.

Features : Multiple servers provide services to the outside at the same time through load balancing, solving the problem of the processing power and storage space limit of a single server.

Description: Using clusters is a common method for systems to solve high concurrency and massive data problems. By adding resources to the cluster, the concurrent processing capabilities of the system are improved, so that the load pressure of the server no longer becomes the bottleneck of the entire system.

5) Evolution of system architecture - database read and write separation

#After enjoying the happiness of rapid growth in system visits for a period of time, I discovered that The system started to slow down again. What is the situation this time? After searching, it was found that the resource competition of some database connections for database writing and updating operations was very fierce, causing the system to slow down.

Features: Multiple servers provide services to the outside at the same time through load balancing, solving the problem of the processing power and storage space limit of a single server.

Description: Using clusters is a common method for systems to solve high concurrency and massive data problems. By adding resources to the cluster, the load pressure on the server no longer becomes the bottleneck of the entire system.

6) Evolution of system architecture - reverse proxy and CDN acceleration

Features: Using CDN and reverse proxy to accelerate the system access speed.

Description: In order to cope with the complex network environment and access from users in different regions, CDN and reverse proxy are used to speed up user access while reducing the load pressure on the back-end server. The basic principles of CDN and reverse proxy are caching.

7) Evolution of system architecture - distributed file system and distributed database

As the system continues to run, data The volume began to increase significantly. At this time, I found that the query would still be a bit slow after the database was divided, so I started to work on table partitioning according to the idea of ​​​​sub-database

Features: The database uses a distributed database, and the file system uses Distributed file system.

Description: No powerful single server can meet the growing business needs of large-scale systems. The separation of database read and write will eventually be unable to meet the needs as the business develops. Distributed databases and distributed databases need to be used. file system to support. Distributed database is the only method for system database splitting. It is only used when the scale of single table data is very large. The more commonly used method of database splitting is business sub-database, which deploys different business databases on different physical servers. superior.

8) Evolution of system architecture - using NoSQL and search engines

Features: The system introduces NoSQL database and search engine.

Description: As the business becomes more and more complex, the requirements for data storage and retrieval become more and more complex. The system needs to use 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, reducing the trouble of applications managing many data sources.

9) Evolution of system architecture - business split

Features: The system is split and transformed according to business, application server Deploy separately according to business differentiation.

Description: In order to cope with increasingly complex business scenarios, divide and conquer methods are usually used to divide the entire system business into different product lines. Relationships are established between applications through hyperlinks, and data can also be distributed through message queues. Of course What's more, it's more about accessing the same data storage system to form an associated complete system. Vertical split: Split a large application into multiple small applications. If the new business is relatively independent, then directly design and deploy it as an independent Web application system. Vertical split is relatively simple. By sorting out the business, the smaller applications will be divided into smaller applications. The relevant businesses can be divested. Horizontal splitting: Split reusable businesses and deploy them independently as distributed services. New businesses only need to call these distributed services. Horizontal splitting requires identifying reusable businesses, designing service interfaces, and standardizing service dependencies.

10) System Architecture Evolution - Distributed Service

Q: What problems will distributed service applications face? ?

(1) When there are more and more services, service URL configuration management becomes very difficult, and the single-point pressure on the F5 hardware load balancer is also increasing.

(2) As it develops further, the dependencies between services become so complicated that it is even unclear which application should be started before which application, and the architect cannot fully describe the architectural relationship of the application.

(3) Then, as the number of calls to the service increases, the capacity problem of the service is exposed. How many machines does this service need to support? When should I add a machine?

(4) With more services, communication costs have also begun to rise. Who should I call if the adjustment of a certain service fails? What are the conventions for service parameters?

(5) If a service has multiple business consumers, how to ensure service quality?

(6) With the continuous upgrade of services, some unexpected things always happen. For example, the cache is written incorrectly, causing memory overflow. Failure is inevitable. Every time a core service fails, it affects a large area and makes people panic. How to control the impact of failures? Can services be functionally downgraded? Or resource degradation?

This seems to be the beginning of the core principles and case analysis of large-scale website technical architecture, but the author summarized it well, so I will reprint it.

4. Product line structure

There is also the business split mentioned above. Now we need to build a product line. We only need a data layer, a general business logic layer, and various application and interface layers in front. We do not need to provide services to external systems (systems of external companies). In the past, we usually We choose to use EJB to build distributed applications, but now we can use RPC frameworks such as dobbo, thrift, avro, and hessian to build distributed applications to achieve interaction between different applications and data sources. Under this structural model, if we need to provide services to other companies, we can write a dedicated application to provide rest services to external systems. Generally, most Internet services have to access a dozen or even hundreds of internal services, and the communication method between them is generally RPC: just like accessing a remote method, input parameters and wait for the result to be returned. This is the easiest to understand way to build complex systems.

As shown below, the model, file system, and cache are not shown, so everyone can understand them.

The above is the detailed content of How Java architecture is applied to different products. For more information, please follow other related articles on the PHP Chinese website!