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

This article mainly explains "distributed and service-oriented ERP system architecture design analysis," interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "distributed and service-oriented ERP system architecture design analysis"!

ERP pain

Once upon a time, I spent more than 4 years in the e-commerce and jewelry industries and developed two large business systems (ERP) for these two industries. As an ERP system, the main function modules of the system are order management, commodity management, production procurement, warehouse management, logistics management, financial management and so on. As a management system, the general development habit is to use. Net or Java technology to build a single-block (single-process) architecture application with only one SQL Server or MySql database. Then divide each module in the project file and organize the code writing and development in a three-tier structure. Final test, delivery on-line.

At first, because the amount of data is not large, the system performance is good, all kinds of list queries, report queries, Excel data export functions are used very smoothly. However, with the development of the company's business, the order volume accumulated day by day, and the demand for report query and data export of various business departments increased continuously in the later period, we gradually felt that the system was running slower and slower. So the first solution we might think of is to optimize the system bottleneck database. One possible approach is to place the database on a separate server, separate the database from the application, or index various database tables, optimize the program code, etc. After some research and optimization, some functions of the system may have greatly improved performance, but we still find that the data query export of some function lists is still very slow, or as the data volume continues to accumulate, the original faster list export function becomes slower and slower. We tried everything, but in the end we couldn't achieve the ideal system performance speed.

In order to improve system performance, we may take the initiative to learn the technical experience of some Internet companies, such as high concurrency, high performance, big data, read and write separation, and find that we have no way to start. We will feel that because the system business characteristics are different. ERP system concurrency is not high, mainly because the business is complex, the degree of coupling of various businesses is much higher than those of Internet applications, it is difficult to split, the data query logic is far more complex than the Internet system, and the data queried from a list page often needs to be associated with 4 or 5 tables to get results. Some reports have even more. In addition, various business operations have high transactional and data consistency requirements, which often leads to our inability to further optimize the system.

Once upon a time, I was also frustrated by one reason or another, thinking that ERP system is very special and incurable, but later...

I don't think so anymore. It seems that there is a new solution O($>_$>)O haha ~

A New Hope

Before describing the specific plan, first say your own ideas. First of all, I think we have to have today's Internet thinking before we do ERP systems. Let's not try to make a unified system anymore. We're going to split up a big system into smaller systems. These small systems then communicate with each other through system interfaces. In this way, a large system is formed, specifically,"distributed" and "service-oriented" Internet thinking. Let the system be architecturally designed to support a highly scalable system inherently.

How? Specifically, order management, commodity management, production procurement, warehouse management, logistics management, and financial management are divided into a subsystem. These subsystems can be designed and developed separately, exposing the data interfaces required by various other subsystems. Each subsystem has a separate database. Even these subsystems can be developed and maintained by different teams, using different technology systems, and using different databases. Instead of integrating them all into one big, comprehensive system, one big, comprehensive database, as before.

What are the advantages of the new architecture?

The first and most important thing is to solve the system performance problem. In the past, there was only one database instance, and it was impossible to expand multiple instances, so that Load Balancer could be achieved by adding database instances under the condition of limited performance. One might argue that a read-write separation scheme could be used, but because of the nature of ERP systems, this scheme is often unrealistic. For example, when manipulating inventory, you cannot read inventory from the read library and then write inventory to the write library. Because master-slave replication is time-sensitive, the inventory written cannot be written to the slave immediately. There are many such scenarios in ERP. Besides, the library can't be expanded, there can only be one. The new design is separate, with each subsystem having its own database.

Secondly, it is very convenient to update, and each subsystem exists in the form of microservices. A single web project in the foreground that invokes the service interfaces of these subsystems in the background. Such a design can be updated separately when a business subsystem needs to be updated. Instead of a single-process architecture like the old one, a small update requires an entire system restart, resulting in user sessions being lost and users needing new logins. The current design does not have this problem.

the whole design

System Physical Deployment View

detailed design

Split Application Layer

Splitting the application layer is the idea of practicing the "microservice" architecture. The original large and complete single-process architecture is split into independently deployable applications according to business modules, so as to achieve the purpose of smooth system update, upgrade and convenient load expansion. Specifically, technologies can use restfull-style interfaces, or they can use frameworks like dubbo in java to simplify development complexity. The ERP Web or other mobile side is also a separate application that acts as the presentation layer. Very thin, just simple to accept parameters, call the interface of various other microservice programs in the background to obtain the data to be displayed. Microservices act as business logic layers, and each microservice is an independently deployable online program that provides data access interfaces to the outside world.

Microservices can use popular RPC frameworks such as dubbo, which can support multiple invocation protocols such as Http, TCP, etc. These frameworks make coding easier and encapsulate the underlying data communication details, making it as easy for clients to execute remote methods as local methods.

dubbo microservice architecture, also supports service governance, Load Balancer and other functions. This not only improves the availability of the system, but also dynamically improves the performance of the system application layer. For example, the warehousing business in warehouse management is very busy and takes up a lot of CPU and memory resources. We can add another machine and deploy a separate warehouse management service. This allows the entire system to have two warehouse management services working simultaneously, balancing the load. All of this is done automatically in service registries such as Zookeeper.

Microservices architecture, inherently good for supporting system updates and upgrades. For example, if there is a new requirement for the finance module to go online, we only need to replace the service restart of the finance module. This has little impact on users who have logged in to the system, and there is no need to log in to the system again, and the use of other module services is not affected.

Split the data layer

Database bottleneck is the permanent damage of ERP system. A large number of complex data query table connection logic flooding the entire system. The key to the success of database vertical splitting is how to redesign the coupling of each module of the system data layer. If this problem could be solved, the permanent injury could be solved.

Let's start with a typical data-layer module coupling problem. Demand is display item inventory, list fields: item number, item name, category, warehouse, quantity

Bill of Materials:

Inventory table:

Category and warehouse tables omitted...

Obviously, in a traditional database, we only need a simple join operation to associate these two tables, plus the associated category and warehouse table to query the data we want. But now in our architecture, the material table and the commodity table are not in the same database instance, we can not use the join operation, then how do we implement the requirements?

The new architecture only allows us to obtain data through the service interface of the other party, and cannot directly associate with the private database of the other party's service. At least from the perspective of architecture and service, you can't directly access the database of the other service. In this case, assuming that the web module subsystem calls the repository subsystem to fetch data, we need to create a service method in the repository module to assemble the data. And then back to the web subsystem. As shown in the figure below, the warehouse management method first obtains the material code of the local inventory table and the warehouse name field information of the warehouse table, and after paging is completed, before finally preparing to return 20 pieces of data to the Web module, the material ID in the 20 pieces of data is used as a parameter to request the commodity module subsystem, and the commodity subsystem returns the commodity information related to the 20 material IDs to the warehouse management module, and then the warehouse management module reassembles the two field data of the material name and category required by the list. Implement the data that is ultimately returned to the Web subsystem.

Perhaps you will say, this is too troublesome, the performance of this method is definitely not as high as that of direct join, and it cannot solve the performance problem. At first glance, this seems to be the case, but when you think about it carefully, in an environment where the system concurrency is low, the data volume is small, and the business is not busy, the performance is indeed not as fast as the traditional join method in a data. But let's think about the future! Our current architecture design is to split a database into multiple databases, each database can run on a separate server, so that the pressure of the database can be loaded later. Overall, this will not make the database a performance bottleneck during busy business times in the future. It's exciting to think about it, isn't it?

At this time, some people will ask, then the system data volume, business is larger, even if you split into several databases is not enough to do? My approach is that it can be based on split databases, and each library can be read and write separately, using caching, etc. It can even be broken down further, splitting subsystems into multiple grandchild systems again. Depending on how busy the business module is.

report system

Some people will ask, some list query logic is very complex, associated with more than ten tables, if the data split according to the above method, it is simply a disaster ah! Yes, you're right. In this case, my solution is to display the data query requirements of this more complex report level, and it can be a separate report system. The report database is designed in the way of data warehouse. For higher read performance, we can design database tables in a way that has many redundant fields, i.e., reverse normal form design, and build a lot of composite indexes.

The key to the success of this system is the synchronization of data and the main ERP system business library. Generally, you can write a timed synchronization program to directly generate the final or intermediate data required by the report view from the data of the ERP main business system through selection and transformation, simplifying the association query. Reporting systems can also be designed using microservices architecture. As shown below:

If the data required for the report requires real-time, we can let the ERP system trigger a request for synchronization of data during business operations and synchronize it to the report library in real time.

distributed transaction

Perhaps someone asked again, ERP system many operations require transactional, you split the system after how to achieve transactional, ensure data consistency?

That's a good question and the last one I thought about before deciding to write this article. In microservices architecture, implementing high-service transactions is not easy, at least not as convenient, performance-efficient, and data-consistent as native applications using native database transactions.

You may have heard of the concept of distributed transactions. There are two scenarios, one is the use of multiple databases in an application, in order to ensure data consistency, you need to use distributed transactions. There is another situation that is specific to our architecture. Distributed transactions in a microservices environment, for example. Purchase Receipt This operation is designed in the Warehouse Management Service. After receipt, the receipt quantity in the purchase order in the purchase subsystem needs to be updated. This process requires data consistency, that is, the quantity written into the inventory table after the purchase order is successfully received, and the receipt quantity in the purchase order table needs to be updated at the same time. We can't access the database of purchasing service directly in warehouse service, but only through the service interface provided by purchasing service. If so, how can we guarantee data consistency? Because it is very likely that the inventory table is written successfully, but the procurement service is called to write the purchase order data fails. It may be caused by network problems, so the data is inconsistent.

In distributed transaction technology, there is a saying to achieve final consistency, which means that as long as I can guarantee that the data on both sides will eventually achieve consistency, I don't have to use transactions. So there's a plan. For example, when the warehouse subsystem processes purchase receipt, it needs to add receipt document data and update multiple tables such as inventory data. These multiple tables are in the warehouse subsystem, and we can use a local transaction to ensure consistency of the table data in the warehouse subsystem. Then call the purchase subsystem to update the receipt quantity in the purchase order. To prevent this process from breaking abruptly and causing calls to fail, consider adding a message queuing middleware such as ActiveMQ. If the interface fails, we write the request to MQ, and when the purchasing subsystem returns to normal, MQ notifies the purchasing subsystem to process the update. Because there will be no notification after the message is consumed, an exception occurs during the processing of the purchase subsystem, resulting in an update failure. It is necessary to write the problem to the local log base so as to notify the administrator for subsequent compensation processing. In this way, various methods can be used to achieve final consistency of data. It sounds like a trap, but that's the solution. There is nothing better. Or call the warehouse subsystem to roll back the receipt document and inventory data after the update fails to achieve final consistency! As shown in the figure:

At this point, I believe everyone has a deeper understanding of "distributed and service-oriented ERP system architecture design analysis," so let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

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.