Logistics system design based on zhongtai idea (5) : Design extensible product service platform

In the previous four articles, we built up the basic capability layer of the logistics center, and then we can build our products and services on top of these basic capabilities to support each line of business.

The basic capability layer is mainly concerned with the stable availability of atomic interfaces, so the design focuses on a number of highly concurrent and highly available technologies. The product service layer is mainly designed to support the continuous innovation of the business, so it needs to pay attention to the scalability of the business process in the design. We will first design a set of abstract models as a whole, and then go into the various modules of the model.

Those of you who have written business code must know that our system is usually composed of a Service layer, a Manager layer and a remote service layer. Among these three layers, the Service layer defines the external interface, and the Manager layer processes various business logic, mainly data verification, data assembly, call other applications (Dubbo service, remote service layer is the packaging of Dubbo service, relatively simple. As our business grows, we may encounter the following:

1. There are more and more interfaces in the Service layer, and similar services define multiple sets of interfaces

2. The Manager code is becoming more and more bloated, with various if and else nested, and every time it changes a bit, it needs to test and regression the whole block of business

3. Remote services, especially query services, are repeatedly invoked in multiple places within a business process, resulting in a decline in overall response time

For the first question, we need to analyze the business carefully and abstract out a common interface, such as creating logistics orders. In business, we can create express orders or warehouse orders. We need to define a common order interface, rather than designing two sets of order interfaces respectively for express and warehouse orders. Then, we can make extensible design on the input and output parameters, such as inheritance and composition, which can support different businesses while keeping the input model basically unchanged. In this way, when new business comes in, there is no need to change the interface, only need to extend the input object.

For the second problem, we abstracted the business logic of the Manager into three steps: validation, data transformation, and execution. Delivery has delivery validation, data conversion, and execution; warehousing has warehouse validation, data conversion, and execution; Service calls manager are routed through policy mode. In this way, each business is a different code flow, no modification will affect the whole world, the test only needs to focus on the modified process, the new line of business only need to add a business process and configure the routing, and will not affect the old business.

For the third problem, we can specify that all data queries are placed in the data transformation step of the Manager, and then the data is passed through the process context so that the query service is not spread throughout the process.

To summarize the solutions to the above three problems, we can abstract the following business process model:

The interface service of the product service layer follows the request-Response style. The input parameter of each method is a Request and the output parameter is response. Request and Response are extended by inheritance and composition.

Request can often be extended for different services through inheritance. In terms of logistics delivery, delivery is divided into express delivery and storage delivery, the two kinds of delivery is not the same, at this time we can pull out the public parameters, and then different parameters sink. We will define a LogisticsServiceDTO object, express delivery and warehousing respectively inherited it, get ExpressLogisticsServiceDTO and WarehouseLogisticsServiceDTO, then define the parameters, We end up with a request object like the one shown below:

In the future, if there are other new shipping methods, we just need to define the new LogisticsServiceDTO, and the basic structure of the interface will hardly need to change.

Response can often be combined to expand different businesses. For example, the user logistics order detail page needs to display logistics order information, user information and address information. We can define an OrderDetailResponse, This object combines the LogisticsOrderDTO, UserDTO, AddressDTO, and other objects. Extensions by composition are common and will not be covered here.

According to our experience, methods should be defined according to the life cycle of the business. Take LogisticsService as an example. We can define createLogistics, consignLogistics and logisticsCallback.

A), createLogistics

CreateLogistics is a method for creating logistics orders by defining extensible request objects that support the creation of logistics orders such as express, warehouse, and delivery

B), consignLogistics

ConsignLogistics is a shipping method that enables delivery of logistics orders such as express, warehouse, delivery, and more by defining extensible request objects

C), logisticsCallback

LogisticsCallback is a logistics return method. By defining extensible request objects, logisticsCallback supports logistics return processes such as warehouse order receiving, warehouse sorting, warehouse removal, delivery collection, delivery delivery, and delivery receipt

Three methods basically covers most of the business scenario, if the emergence of a new business scenario, you first need to assess whether existing methods to support business process, if not support, and new methods, such as some of the logistics situation exists many period of delivery (as a typical rural taobao), then a consignLogistics affirmation is not enough, This is where you need to extend the method. At the start of extension method, can open special interface for a particular business, such as the business more and more, the special interface unified arrangement into a generic interface at a time, this process is a process of precipitation business model, is designed through early design, must after the business of precipitation to get out.

Having said the design of the interface layer, we are going to talk about how to design the implementation layer of the interface. According to the overall design idea, we cut the business into one flow, and then cut each flow into three nodes: verification, data conversion and execution, and then decide which flow to go through the input parameter. Therefore, the implementation layer of an interface is actually a process of process decision + process node execution.

A process decision is simply a list of nodes that need to be executed in a mapping table, either by ordinary hash mapping or by a sophisticated rules engine. Once you have the node list (typically the node class name), you can retrieve the node object through the Spring container. All process nodes inherit from the same abstract node object and implement the same method: execute method, so once you get the node object from the Spring container, you can execute the node through reflection. Nodes usually need to transfer data to each other. Therefore, the execute method on nodes needs to pass in A context object. Node A passes data into the context object after execution, and node B obtains data from this context object during execution.

Taking the above abstract model into the concrete business, we can get the following architecture:

Logistics to create a single, for example, all the business code in accordance with the business dispersed in different process node, the entrance through policy routing process, the same process specifies three nodes, three transfer data between nodes through the process context, three nodes work together to complete different business logistics single creation process.

From a broader perspective, the combination of the product service layer and the basic capability layer is the following architecture:

The product service layer provides services externally, and each service defines a highly aggregated business method. Each business method isolates the business code through strategic routing and process choreography. Each node in the business process calls the atomic interface of the basic capability layer for a series of business operations.

The general idea of a product service platform is a very old principle: open for extension, closed for modification. We improved extensibility by making interface entry and exit parameters extensible through inheritance and composition, and by isolating old and new business code through combination of policy patterns and process nodes. Of course, every advantage has its disadvantages. The product service platform improves scalability while increasing the amount of code to write, and at the same time, there is no good way for distributed transactions.