1. General architecture overview
In the beginning, we tend to choose the simplest technology architecture, such as LAMP architecture and SSH three-tier architecture, in order to quickly iterate on the product. The architecture can adapt to the rapid growth of our business in the early, but, as business becomes more and more complex, the architecture is getting harder and harder to support our business development, appear in a class to write thousands of lines of code, a method if everywhere else, if encounter among the main program apes, intervention program later apes almost impossible to understand the code, At the end of the day, the product becomes more and more difficult to iterate and can only be overturned and redone. If we had started coding in a more adaptable architecture, we would have made fewer mistakes later. The following article is my own summary of a set of architecture, after practice, adaptability is not bad.
2. Implementation of general architecture
In general, my general architecture evolves on the basis of three-tier architecture. In the classic three-tier architecture, controller is at the top, Service is in the middle, and DAO is at the bottom. In my architecture, the uppermost layer is the gateway layer, controller is just one kind of gateway, the middle layer is the business layer, Service is just the entrance of the business layer, the bottom layer is the basic layer, DAO is just the data storage component in the basic layer.
2.1. Gateway Layer
The gateway layer essentially handles requests for different network protocols, such as HTTP, TCP, and, of course, other protocols. See the following figure for details:
2.1.1 HTTP requests
Generally, requests from PC and APP terminals are based on HTTP protocol, and the industry has been very mature for processing HTTP requests. First, the Tomcat container itself encapsulates the complexity of HTTP request processing, and second, Spring MVC provides RESTful coding for request processing, greatly reducing the complexity of development. What we need to do is to divide the controller according to the business field, for example, to divide the large field according to the order and membership, and the various methods in the controller are the operation in this field. The controller here is the unified gateway processing layer. For each controller method, only three things are done: first, the request parameters are parsed out and assembled into internal parameters; second, the lower-level service is invoked to execute the business logic; third, the result is returned. For exceptions, the exception stack log needs to be recorded and error codes converted. Stack information is not exposed to the caller.
2.1.2 TCP request
Solutions for handling TCP requests, such as Netty, are well established in the industry. However, TCP requests are so low-level that we tend to develop our own protocols based on TCP. In addition, many distributed frameworks are based on TCP, such as RPC framework Dubbo, messaging framework RocketMQ, etc. From single-machine system to distributed system, nothing more than the gateway layer processing TCP request logic, in theory, the underlying business is not aware of whether it is based on single-machine environment or distributed environment, the role of the gateway layer is to shield the details of different external call sources. In Dubbo server, we need to implement remote interface, and the remote service invocation are internal forward, forward logic is very simple, first is assembling analytical parameters and internal parameters, and then call the business layer interface to execute business logic, final assembly returned as a result, the exception handling also need to do here, to prevent abnormal exposed to external applications.
2.1.3, subtotal
Gateway layer is the essence of protocol processing, at the same time, convergence to the gateway to the business logic layer, not exposed to the outside, when the internal business logic reconstruction, external caller don’t need to perceive these changes, when the external call source increases, the internal business logic does not need to feel this kind of change, the caller to external and internal business logic for decoupling.
2.2. Business Layer
The business layer is a system, whether it is a single system or a business system in a distributed system group, the business layer is the place to carry business processes and rules. The business layer consists of three layers from the outside in: the first is business services, the second is business processes, and the third is business components. The details are as follows:
2.2.1. Business Services
Business service is the unified external facade of the business layer, which consists of three aspects: business interface, input parameter, and output parameter.
A) Business interface
A business interface represents a business service of a domain. For example, the business service of an order domain is represented by the interface OrderService, and the business service of a member domain is represented by the interface MemberService. Interfaces can be divided into read and write interfaces according to the execution nature, such as OrderReadService and OrderWriteService. Read/write separation enables read/write groups to be added to clusters to manage traffic. However, read/write separation is not significant in a single-node system. Operations in the domain are represented by methods in the business interface, such as order createOrder, cancelOrder, and so on in the order domain. For these operations, try to design a business meaning of the method, rather than add, delete, change and check, of course, for some simple business, can only add, delete, change and check.
B) into the refs
Next, the design of the input parameter. Input parameters for reading methods, relatively simple, not discussed. For the write method, we design the input as a hierarchical data model. First of all, it is necessary to design common data models, such as order data model, business data model, commodity data model, etc., and then combine these data models with individual data of some specific businesses to form Request objects. This Request object varies according to different business operations, and the corresponding return result is response. It also returns different parameters for different businesses.
, for example, take food and beverage orders, first of all, we should identify some of these business processes are fundamental data model, such as a restaurant in the field of food, such as a table, the model is a basic model, because, no matter what the food and beverage orders, dishes and table must be not escape, they can be reuse! Therefore, we designed the DO (Domian Object) relative to these basic models respectively :DishDO (dishes), BoardDO (tables), etc. Next, We design a request object DishOrderCreateRequest for placing food and drink orders. The DishOrderCreateRequest contains DishDO and BoardDO, and also contains some specific attributes, such as number of people, discount and so on. In this way, both universality and flexibility can be achieved. DishOrderCreateRequest represents personalized and flexible business input, while DishDO and BoardDO represent unchangeable basic model.
C) the refs
Finally, it is the design of the parameter. For writing methods, the general parameter is relatively simple. For the read method, the output parameter is usually a composite object with complex structure and hierarchy. For example, to query an order, this order has the basic information of the order, as well as commodity information, consignee address information, etc. In the design of the parameter, the structure should be designed as a composite object, but the actual query, through the query selector, to query different composite objects. For example, if the query selector sets the item query to true and the address query to false, the order will contain only the item and not the address.
2.2.2. Business process
Business process is actually the interpretation of business rules, but this interpretation using code to achieve, we have to do is actually accurate translation of these business rules, and maintain these business rules.
Business processes can be roughly divided into three types of action nodes: 1. Assembly parameter node; 2. Rule judgment node; 3. For example, to place a catering order, our first step is to assemble a basic DishOrderDO (assemble parameter node) from the parameters passed in from the upper layer, and then to fill the DishOrderDO (rule judgment node) according to specific rules. Then, we call the DAO to create a DishOrderDO (execute action node).
Business process is the most easily changed place, it is not easy to maintain a good business process, the general idea is to break the large business process into small business process, extract the common code fragments of each business process, into maintainable business components.
2.2.2. Business Components
A) Basic components
Business components encapsulate cohesive, reusable pieces of code. Corresponding to the three types of business nodes in business processes, 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 done after a deep understanding of the business, and blindly abstracting business components often ends up in vain.
B) the ability to
By further abstracting business components, capabilities can be obtained. A service capability is a combination of components that have certain reusability. For example, SMS capability = SMS parameter assembly component + SMS component. The SMS capability can be reused by different business processes, such as sending SMS messages after placing orders and sending SMS messages after payment. The logic is similar but the content is different. Capability is a component with large granularity. The larger the granularity is, the smaller the reusability is. The extraction of capability is also based on a deep understanding of a specific business, and there is no silver bullet that can be used once and for all.
C) Higher latitude abstractions
After my own practice, for the scene of rapid demand change such as the Internet, the component abstraction of higher latitude is often cost-effective, so it is not recommended to do it.
2.3 basic 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
Interface definition is to design reasonable interfaces according to different technical frameworks and combined with business needs. For business components, they only perceive technical interfaces, but not technical implementation. We should not expose the specific technical details upwards, which is called interface oriented programming. Technical interface is often a bridge between business and technology. The interface itself contains business meaning. DAO interface is the most common one. In the same way that business-specific interfaces such as updateUserById are designed, caching interfaces should not be put or get, but cacheUser or deprecateUser.
2.3.2 Technical components
The technical components of a stand-alone system are generally divided into two kinds. One is a general technical component, such as data storage, cache, message and scheduling task, transaction, and lock. One is infrastructure, such as the Spring container, tomcat container. Let’s talk a little bit about 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 images and HTML files, and some are 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 caches are typically local memory based caches, such as Encache, and millisecond caches are typically centralized memory caches, such as memcache, which are called remotely when accessed, so the response time is several milliseconds, and hundred-millisecond caches are typically centralized and persistent caches, such as Redis, Response times can be longer, to tens or even hundreds of milliseconds, due to remote access and read persistent records due to cache breakdowns. Stand-alone systems generally use the local memory cache, when the cache is broken, directly access the database.
Messages and scheduling tasks: Both messages and scheduling tasks are asynchronous in nature. The difference is that messages cannot control the timing of asynchrony, while scheduling tasks can. Generally, after a message is sent, the system listening to the message receives the message immediately and triggers the execution of the service logic. The scheduling task executes the service logic one or more times according to the scheduling rules. In a single-node system, messages and scheduling tasks are rarely used. Messages may be used in log monitoring and scheduling tasks may be used in data report statistics.
Transactions: We can use the transaction template of Spring-Tx to conduct transaction operations. In the development of business logic, we must grasp the size of the transaction. It is recommended to put a bunch of database operations that are relatively close to the business in one transaction. Do not randomly open transactions for every method.
Lock: There are two types of lock used in single-machine system: optimistic lock and pessimistic lock. Optimistic locking is implemented by adding version fields to the business table of the database. Each update will determine whether the version changes. If the version changes, it needs to retry. Pessimistic locking is based on the Lock interface of JDK. It locks and releases locks for a business process with coarse granularity.
3, summarize
The above is the business technology architecture that I have worked out after a long period of practice. I think it is still general and can support the changeable business to a certain extent. In addition, I recorded the basic principles of Spring MVC, Dubbo and Tomcat, which were used in the paper, and shared them in group 697579751. It’s free for interested programmers to join.