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

This article introduces the knowledge of "how to apply Java architecture to different products". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

When we build a system, we usually need to consider how to interact with other systems, so we first need to know how various systems interact and what technologies are used to implement them.

1. Interaction between different systems and different languages

Now we often use WebService,Http requests for interactions between different systems and different languages. WebService, or "Web service", is abbreviated to WS. Literally, it is actually a "Web-based service". On the other hand, the service is bilateral, and if there is a service demand side, there is a service provider. The service provider publishes the service, and the service demander invokes the service published by the service provider. To put it more professionally, WS is actually a tool to realize the communication of heterogeneous systems based on the HTTP protocol. That's right! To put it bluntly, WS is still based on the HTTP protocol, that is, the 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 the most widely used, but also the one I use the most). REST services can also be developed based on CXF, but we generally implement REST services directly using springMVC or other MVC frameworks.

But in the impression of many people, Web service generally refers to the various XML-based interaction technologies dominated by IBM more than a decade ago, but now very few people use them except for some companies. In a broad sense, Webservice is a Web service, everything is a service.

two。 Interaction between different systems and the same language

The common interaction between different systems and the same language is realized by RPC (remote procedure call) or RMI (remote method call). There is no need to provide services to the outside. Of course, the above interaction can also be used in the same language, but I often use RPC.

Architecture of different products

3. Architectural evolution of a single product

Generally speaking, we are just the evolution of the architecture in the case of a product. If we need to provide webService, we usually use REST services to implement it.

The following paragraph comes from Zhihu.

1) the evolution of distributed architecture system architecture evolution process-initial phase architecture

In the initial stage, small system applications, databases, files, and other resources are popularly known as LAMP on one server.

Features: all resources such as applications, databases, files, etc., 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, a variety of free and open source software and a cheap server can start the development of the system.

2) the evolution of system architecture-the separation of application services and data services

The good times did not last long. It was found that with the re-increase of system visits, the pressure on the webserver machine would rise to a relatively high level during the peak period. At this time, we began to consider adding a webserver.

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

Description: the increase in the amount of data, the lack of performance and storage space of a single server, the need to separate applications from data, concurrent processing capacity and data storage space have been greatly improved.

3) the evolution of system architecture-using caching to improve performance

Features: a small part of the data in the database is stored in the cache server, which reduces the access times of the database and reduces the access pressure of the database.

Description: system access characteristics follow the 28 law, that is, 80% of business visits are concentrated on 20% of the data. Cache is divided into local cache and remote distributed cache. The access speed of local cache is faster, but the amount of cache data is limited. At the same time, there is a situation of contention with applications for memory.

4) the evolution of system architecture-using application server cluster

After finishing the work of dividing the database and tables, the pressure on the database has been reduced to a relatively low level, and we began to live a happy life of watching the traffic soar every day. Suddenly, one day, we found that the access to the system began to slow down again. At this time, we first checked the database, the pressure was normal, and then we checked webserver. We found that apache blocked a lot of requests, and the application server was relatively fast for each request. It seems that the number of requests is too high, which leads to the need to wait in line and slow down the response speed.

Features: multiple servers provide services to the outside world at the same time through load balancing to solve the problem of processing capacity and upper limit of storage space of a single server.

Description: the use of clusters is a common means for the system to solve the problems of high concurrency and massive data. By adding resources to the cluster to improve the concurrent processing capacity of the system, the load pressure of the server is no longer the bottleneck of the whole system.

5) the evolution of system architecture-separation of database read and write

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

Features: multiple servers provide services to the outside world at the same time through load balancing to solve the problem of processing capacity and upper limit of storage space of a single server.

Description: the use of clusters is a common means for the system to solve the problems of high concurrency and massive data. By adding resources to the cluster, the load pressure on the server is no longer the bottleneck of the whole system.

6) the evolution of system architecture-reverse proxy and CDN acceleration

Features: using CDN and reverse proxy to speed up the access speed of the system.

Description: in order to cope with the complex network environment and the access of users in different regions, the speed of user access is accelerated through CDN and reverse proxy, while reducing the load on the back-end server. The basic principle of CDN and reverse proxy is caching.

7) the evolution of system architecture-distributed file system and distributed database

With the continuous operation of the system, the amount of data began to increase by a large margin. At this time, it was found that the query would still be a little slow after sub-database, so we began to do the work of sub-table according to the idea of sub-database.

Features: the database adopts distributed database, and the file system adopts distributed file system.

Description: no powerful single server can meet the growing business needs of large-scale systems, and database read-write separation will eventually be unable to meet the needs with the development of business, which needs to be supported by distributed database and distributed file system. Distributed database is a method of splitting system database, which is used only when the scale of single-table data is very large. The more commonly used method of database split is business sub-database, which deploys different business databases on different physical servers.

8) system architecture evolution-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 all kinds of data through the unified data access module, which reduces the trouble of the application program managing many data sources.

9) the evolution of system architecture-business split

Features: the system is split and reformed according to the business, and the application server is deployed separately according to the business differentiation.

Description: in order to deal with increasingly complex business scenarios, the whole system business is usually divided into different product lines by divide-and-conquer means. The relationship between applications is established through hyperlinks, and data can also be distributed through message queues. Of course, it is more likely to form an associated and complete system by accessing the same data storage system. Vertical split: split a large application into multiple small applications. If the new business is relatively independent, it is relatively simple to design and deploy it as an independent Web application system. By combing the business, you can divest less related business. Horizontal split: split the reused services and deploy them as distributed services independently. New services only need to call these distributed services to identify reusable services, design service interfaces, and standardize service dependencies.

10) the evolution of system architecture-distributed services

Q: what problems will distributed service applications face?

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

(2) when further development, the dependency relationship between services becomes complex, and even can not tell which application should be launched before which application, the architect can not fully describe the architectural relationship of the application.

(3) then, as the amount of service transfer becomes larger and larger, the problem of service capacity will be exposed. how many machines do this service need to support? When should I add the machine?

(4) when there are more services, the cost of communication begins to rise. Who should I turn to for the failure of a certain service? What are the conventions for the parameters of the service?

(5) if a service has multiple business consumers, how to ensure the quality of service?

(6) with the continuous upgrading of the service, there are always some unexpected things happen, such as memory overflow caused by cache mistakes, failure is inevitable, each core service is hung up, affecting a large area, people panic, how to control the impact of the failure? Can the service be degraded? Or resource deterioration?

This seems to be the beginning of the core principles and case studies of the technical architecture of large websites, but the author summed it up well, so I'll reprint it.

4. Architecture of the product line

There is also a business split mentioned above. Now we need to make a product line, we only need a data layer, a general business logic layer, and there are various application and interface layers ahead, and there is no need to provide services to external systems (external company's systems). In the past, we would generally choose to use EJB to build distributed applications. But now we can use RPC frameworks such as dobbo, thrift, avro, hessian to build distributed applications to interact with different applications and data sources. Under this structure model, we need to provide services to other companies, and we can write an application to provide rest services to external systems. In general, most Internet services access a dozen or even hundreds of internal services, and the communication between them is usually RPC: just like accessing a remote method, enter parameters and wait for the result to be returned. This is the easiest way to understand building complex systems.

The model, file system and cache of the following figure are not drawn, as long as you understand them.

This is the end of the content of "how the Java architecture is applied to different products". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.