1. General architecture overview
At the beginning of our business, we often choose the simplest technical architecture, such as LAMP architecture and SSH three-tier architecture, in order to quickly iterate products. These architectures can adapt to the rapid development of the initial business. However, as the business becomes more and more complex, we will find that these architectures are more and more difficult to support the development of the business. It appears that thousands of lines of code are written in one class, and one method There are if else statements everywhere. If the main programmer resigns in the middle, the programmers who intervene later can hardly understand the code. In the end, the product becomes more and more difficult to iterate and can only be overturned and redone. If we write code with a more adaptable architecture at the beginning of our business, we will avoid many detours later. The following article is a set of architecture that I have summed up by myself. After practice, the adaptability is not bad.
2. Implementation of general architecture
In general, my general architecture is still evolving based on a three-tier architecture. In the classic three-tier architecture, the top layer is the controller, the middle layer is the service, and the lower layer is the dao. In my architecture, the top layer is the gateway layer, the controller is just a kind of gateway, the middle is the business layer, the service is just the entrance of the business layer, the bottom layer is the base layer, and the dao is just the data storage component in the base layer.
2.1. Gateway layer
The gateway layer essentially processes requests from different network protocols, such as HTTP protocol, TCP protocol, and of course, other protocols can also be processed. See the figure below for details:
2.1.1, HTTP request
Generally, requests from the PC side and the APP side are based on the HTTP protocol. The solution for processing HTTP requests is very mature in the industry. First, the tomcat container itself has encapsulated the complexity of HTTP request processing. Second, spring mvc provides a RESTful coding method for request processing, which greatly reduces the complexity of development. What we need to do is to divide the controller according to business fields, such as dividing large fields according to orders and members, and the various methods in it are the operations in this field. The controller here is the unified gateway processing layer. For each controller method, it only does three things. First, it parses the request parameters and assembles them into internal parameters. Second, it calls the lower-level service to execute business logic. For exceptions, it is necessary to record the exception stack log and convert the error code, and the stack information should not be exposed to the caller.
2.1.2, TCP request
For the solution of handling TCP requests, the industry is already very mature, such as Netty. However, TCP requests are too low-level after all, and we often develop our own protocols based on the TCP protocol. In addition, many distributed frameworks are based on the TCP protocol, such as the RPC framework Dubbo, the message framework RocketMQ and so on. From a stand-alone system to a distributed system, the gateway layer has more logic for processing TCP requests. In theory, the underlying business does not need to know whether it is in a stand-alone environment or a distributed environment. The role of the gateway layer is to shield this difference. Details of the external call source. In the Dubbo server, we need to implement the remote interface and forward the remote service calls internally. The forwarding logic is also very simple. First, parse the parameters and assemble the internal parameters, then call the interface of the business layer to execute the business logic, and finally assemble The result is returned, and exception handling also needs to be done here to prevent exceptions from being exposed to external applications.
2.1.3. Summary
The essence of the gateway layer is to process the protocol, while converging the business logic to the gateway layer instead of exposing it to the outside. When the internal business logic is reconstructed, the external caller does not need to perceive these changes. When the external call source increases , the internal business logic does not need to perceive this change, thereby decoupling the external caller from the internal business logic. I have recorded the underlying principles of the technical points of Spring mvc, Dubbo, and tomcat used in this article as a video network disk and shared it in the group: 619881427. It can be obtained for free, and interested programmers can join in to learn.
2.2, business layer
The business layer is a system, whether it is a stand-alone system or a business system in a distributed system group, the business layer is where business processes and rules are carried. The business layer consists of three layers from the outside to the inside: the first layer is business services, the second layer is business processes, and the third layer is business components. The details are as follows:
2.2.1. Business Services
The business service is the unified external appearance of the business layer. It consists of three aspects: business interface, input parameters, and output parameters.
a) business interface
A business interface represents the business service of a domain. For example, the business service of the order domain is represented by the interface OrderService, and the business service of the member domain is represented by the interface MemberService. The interface can be divided into read interface and write interface according to the nature of execution, such as OrderReadService and OrderWriteService. The advantage of read-write separation is that you can group reads and writes on the cluster to manage traffic. Of course, the read-write separation of a stand-alone system does not make much sense. The operations in the field are reflected in the form of methods in the business interface. For example, in the order field, there are operations such as placing an order createOrder, canceling an order, cancelOrder, and so on. For these operations, try to design methods with business meaning instead of adding, deleting, modifying and checking. Of course, for some simple businesses, you can only add, delete, modify and check.
b) Input parameters
Next, is the design of the entry. The entry method is relatively simple for the reading method, and will not be discussed. For writing methods, we design the input parameters into a hierarchical data model. First, you need to design public data models, such as order data models, merchant data models, commodity data models, etc., and then combine these data models with some personal data under specific services to form a Request object, which is different according to different business operations. However, the corresponding return result is the response, which is also different with the parameters returned by different services.
For example, when taking a catering order, first of all, we should identify some basic data models in these business processes, such as dishes and table seats in the catering field. The reason why these models are called basic models is because, No matter what catering order is placed, the dishes and table seats cannot be escaped, they can be reused! Therefore, we design the corresponding DO (Domian Object) for these basic models: DishDO (dish), BoardDO (table), etc. Next, we design a request object DishOrderCreateRequest for placing catering orders, which DishOrderCreateRequest contains DishDO And BoardDO, it will also contain some specific attributes, such as the number of people, discounts, etc., so that it can be universal and flexible. DishOrderCreateRequest represents a personalized and flexible business input, while DishDO and BoardDO, etc. Represents a base model that is not susceptible to change.
c) outgoing
Finally, it is the design of the reference. For the writing method, it is generally relatively simple to output parameters. For the read method, the output parameter is often a composite object with a complex structure and hierarchy. For example, to query an order, this order has basic order information, as well as product information, consignee address information, etc. When designing the parameters, the structure should be designed as a composite object, but when the query is actually performed, the query selector is used to query different composite objects. For example, if the query selector sets the product query to true and the address query to false, the order queried this time only contains the product, but not the address.
2.2.2, business process
The business process is actually the interpretation of the business rules, but this interpretation is implemented using code. What we need to do is to accurately translate these business rules and maintain these business rules.
The business process can be roughly divided into three types of action nodes, 1. Assembly parameter node 2, Rule judgment node 3, Execution action node, where each action node is a fragment of some business code. For example, to place a catering order, our first step is to assemble a basic DishOrderDO (assembly parameter node) from the parameters passed in from the upper layer, and then fill the DishOrderDO (rule judgment node) according to specific rules, and then call DAO Go to create DishOrderDO (Execute Action Node).
The business process is the easiest place to change. It is not easy to maintain the business process. The general idea is to split the large business process into small business processes, extract the common code fragments in each business process, and make them changeable. Maintained business components.
2.2.2, business components
a) Basic components
Business components actually encapsulate some cohesive and reusable code fragments. Corresponding to the three business nodes in the business process, business components are also divided into three types: assembly parameter components, rule judgment components, and action execution business components. The abstraction of business components is often carried out after a deep understanding of the business. Blindly abstracting business components is often a waste of time.
b) Ability
By further abstracting business components, capabilities can be obtained. The business capability is a combination of components with certain reusability, for example, the ability to send text messages = the assembly of short message parameter components + the text message component. For the ability to send text messages, it can be reused by different business processes. For example, an order is successfully sent a text message, and a payment is successfully sent a text message. The logic is similar, only the content is different. Capability is a component with relatively large granularity. The larger the granularity, the smaller the reusability. The extraction of capabilities is also based on a deep understanding of a specific business, and there is no silver bullet once and for all.
c) higher latitude abstraction
After my own practice, for scenarios such as the Internet where the demand changes rapidly, higher-dimensional component abstraction is often very cost-effective, and it is not recommended for everyone to do it.
2.3, the base layer
The base layer consists of two parts, the first is the interface definition, and the second is the technical component.
2.3.1. Interface definition
The interface definition is to design a reasonable interface according to different technical frameworks and at the same time combine business needs. For business components, they only perceive the technical interface, but not the technical implementation, and we should not put the specific technical details. Expose upwards, which is called interface-oriented programming. The technical interface is often a bridge between business and technology. The interface itself contains business meaning. The most common one is the DAO interface. When we design the DAO interface, we will not design it as insert, update, query and other business-independent interfaces. It is designed as insertUser, updateUserById and other business-related interfaces. For the same reason, when designing a cache interface, it should not be designed as an interface such as put and get, but should be designed as an interface such as cacheUser and deprecateUser.
2.3.2. Technical components
The technical components of a stand-alone system are generally divided into two types. One is general technical components, such as data storage, cache, message and scheduling tasks, transactions, and locks. One is infrastructure, such as spring container, tomcat container. Let's talk a little bit about the common technical components.
Data storage: Data storage includes relational databases, non-relational databases, and file storage systems. Relational databases, such as MySQL, are suitable for storing most business data. Non-relational databases, such as hbase, can store historical logs and archive historical MySQL data. File storage systems are generally based on Linux file systems, such as pictures, html files, etc., and also based on HDFS for big data analysis.
Cache: Cache can be divided into nanosecond cache, millisecond cache and hundred millisecond cache according to the response time. Nanosecond cache is a general cache based on local memory, such as encache, millisecond cache is generally a centralized memory cache, such as memcache, due to remote calls during access, the response time will be extended to a few milliseconds, and a hundred millisecond cache is generally It is a centralized persistent cache, such as redis. Due to the existence of remote access and cache breakdown caused by reading persistent records, its response time will be longer, to tens or even hundreds of milliseconds. A single-machine system generally uses a local memory cache. When the cache is broken down, it directly accesses the database.
Messages and scheduling tasks: Messages and scheduling tasks are essentially a means of asynchrony. The difference is that messages cannot control the asynchronous time, while scheduling tasks can. Generally, after the message is sent, the system monitoring the message will receive the message immediately, thereby triggering the execution of business logic immediately, and the scheduling task will execute the business logic one or more times according to the scheduling rules. Messages and scheduling tasks are rarely used in stand-alone systems. Messages may be used in log monitoring, and scheduling tasks may be used in data report statistics.
Transaction: The essence of transaction is based on the database. The transaction of a stand-alone system is a transaction that depends on the database. We can use the transaction template of spring-tx to perform transaction operations. In the development of business logic, we must grasp the size of the transaction. A bunch of database operations with a relatively close business are placed in a transaction. Do not open a transaction for each method at will.
Locks: There are two main types of locks used in stand-alone systems: optimistic locks and pessimistic locks. Optimistic locking is implemented by adding a version field to the business table of the database. Each update will determine whether the version has changed. If it changes, it needs to be retried. The granularity of this lock is relatively small. Pessimistic lock is based on JDK's Lock interface. It locks and releases locks for a business process. The granularity of locks is relatively coarse.
3. Summary
The above is the business technology architecture that I have explored after a long period of practice. I think it is fairly general and can support volatile business to a certain extent. And I recorded the underlying principles of the technical points of Spring mvc, Dubbo, and tomcat used in the article as a video network disk and shared it in the group: 619881427. It can be obtained for free, and interested programmers can join in to learn.