Build a more general business technology architecture

1. General Architecture Overview

At the beginning of our business, we often choose the simplest technology architecture, such as the lamp architecture, the SSH three layer architecture, in order to quickly iterate the product. These architectures can adapt to the rapid development of the initial business, but as the business becomes more complex, we will find that these architectures are becoming more and more difficult to support the development of the business, in a class to write thousands of lines of code, a method is everywhere if ELSE statements, if encountered in the middle of the main program ape separation, The procedure behind the ape can hardly understand the code, and in the end, the product becomes more and more difficult to iterate, only to overturn the redo. If we start at the beginning of a more adaptable architecture to write code, the latter will be a lot less detours. The following article is my own summed up a set of architecture, through practice, adaptability is good.

2. Universal Architecture Implementation

In general, my general architecture evolved on the basis of a three-tier architecture, in the classic three-tier architecture, the controller is the top, the service in the middle, and the DAO on the lower level. In my architecture, the top level is the gateway layer, controller is just one of the gateways, the middle is the business layer, service is only the portal of the business layer, the bottom layer is the foundation, DAO is only the data storage component in the base layer.

2.1. Gateway Layer

The gateway layer essentially handles requests for different network protocols, such as the HTTP protocol, the TCP protocol, and, of course, other protocols. See details:

2.1.1, HTTP request

Most requests from both PC and app are based on the HTTP protocol, and the industry is very mature in the scenario of handling HTTP requests. First, the Tomcat container itself has encapsulated the complexities of HTTP request processing, and secondly, spring MVC provides restful coding for request processing, greatly reducing the complexity of development. All we have to do is to divide the controller according to the business domain, for example, according to the order, the member to divide the big domain, inside the various methods is the operation in this domain. The controller here is the Unified Gateway processing layer, for each controller's method to do only three things, first, the request parameters resolved and assembled into internal parameters, the second call to the lower level service execution business logic, the third assembly returns the results, for the exception condition, The exception stack log needs to be logged and the error code is converted, and the stack information is not exposed to callers.

2.1.2, TCP Request

The industry is already ripe for scenarios that deal with TCP requests, such as Netty. However, TCP requests are too low-level, and we tend to develop our own protocols based on the TCP protocol. In addition, many distributed frameworks are based on TCP protocol, such as RPC Framework Dubbo, message framework ROCKETMQ and so on. From a stand-alone system to a distributed system, the gateway layer is more than the logic of processing TCP requests, in theory, the bottom of the business is no need to perceive whether it is out of a single-machine environment or distributed environment, the role of Gateway layer is to shield this different external call source details. In the Dubbo server, we need to implement the remote interface, and the remote service call internal forwarding, forwarding logic is also very simple, first of all to parse parameters and assemble internal parameters, and then call the business layer interface to execute the business logic, and finally assemble the return results, for exception handling also need to be done here, Prevent anomalies from being exposed to external applications.

2.1.3, summary

The gateway layer is essentially processing the protocol, while converging the business logic to the gateway layer, rather than exposing it to the outside, when the internal business logic is refactored, the external caller does not need to perceive these changes, and when the external call source increases, the internal business logic does not need to perceive this change. This decouples the external caller from the internal business logic.

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, where business processes and rules are hosted. The business layer consists of three layers from the outside: the first tier is the business service, the second tier is the business process, and the third tier is the business component. Specific example:

2.2.1, Business Services

Business Services is the business layer of external unified façade, it is composed of three aspects: business interface, entry, and the parameters.

A) Business interface

A business interface that represents a business service in a domain, such as 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. Interfaces can be divided into read and write interfaces according to the nature of execution, such as Orderreadservice and Orderwriteservice. The benefit of read and write separation is that the cluster can be read and written, thus managing traffic, and of course, the separation of read and write is not too large. Operations in the domain are represented in the form of a method in the business interface, such as placing a single createorder in the Order field, canceling the order Cancelorder, and so on. For these operations, as far as possible to design a business meaning of the method, rather than additions and deletions, of course, for some simple business, can only delete and change.

b) Enter the parameter

Next, is the design of the entry parameter. The entry method is relatively simple and not discussed. For the Write method, we design the parameter into a hierarchical data model. First of all, we need to design a public data model, such as order data model, merchant data model, commodity data model, and then combine these data models and some specific business personality data to form the request object, this request object according to different business operation different, The corresponding return result is response, which is also different from the parameters returned by the different business.

For example, taking a food order, first of all, we should identify some of these business processes in the comparative basis of the data model, such as food and beverage industry, table, and so on, these models are the basic model, because, no matter what food orders, dishes and tables must not escape, they can be reused! Therefore, we design these basic models for the relative do (Domian Object):D Ishdo (dish), boarddo (table), and so on, and then, We design a request object for the next catering order dishordercreaterequest where Dishordercreaterequest contains Dishdo and Boarddo, and also contains specific attributes, such as the number of people, discounts, etc. This makes it possible to be versatile and flexible, dishordercreaterequest represents a flexible business entry, while Dishdo and Boarddo represent an easy-to-change base model.

c) out of the reference

Finally, it is the design of the reference. For the writing method, the general parameter is relatively simple. For the reading method, the argument is often a complex object of structure and hierarchy. For example, to inquire about an order, this order has the basic information of orders, as well as commodity information, consignee address information. In the design of the parameters, the structure of the design as a combination of objects, but the real query, through the query selector, to query different combinations of objects. For example, the query selector set the product query to TRUE, the address query is false, then the query out of the order will contain only the goods, and not include the address.

2.2.2, Business process

Business process is the interpretation of business rules, but this interpretation of the use of code to achieve, we have to do is to accurately translate these business rules, and maintain these business rules.

The business process can be broadly divided into three action nodes, 1, Assembly parameters Node 2, rule Judgment Node 3, Execution action node, each action node is a fragment of some business code. For example, under the food and beverage order, our first step is to assemble the parameters of the upper layer into a basic Dishorderdo (assembly parameter node) and then populate the Dishorderdo (rule judgment node) according to the specific rules. Then it is called DAO to create the Dishorderdo (Execute the Action node).

Business processes are the easiest to change, and the general idea is to break up large business processes into small business processes, extracting snippets of code that are common to each business process, and becoming maintainable business components.

2.2.2, Business components

A) Base components

The business component is actually encapsulating some of the reusable code fragments that are cohesive. and business processes in the three business nodes, business components are divided into three kinds: assembly parameters components, rule judgment components, action execution business components. The abstraction of business components is often done after a deep understanding of the business, and the abstraction of business components blindly tends to end in vain.

b) capacity

The ability to further abstract the business components can be obtained. Business capability is a combination of components with a certain reusability, such as texting ability = Assembling SMS parameter components + texting components. For the ability to send text messages can be reused by different business processes, such as the order to send text messages successfully, the successful payment of text messages, the logic is similar, only the content is different. Ability is a large size of the components, the larger the granularity, often reusability is smaller, the ability to extract, but also based on a specific business deep understanding, there is no once and for all silver bullets.

c) Higher latitude abstraction

After my practice, for the Internet such a rapid change in demand for the scene, higher latitude component abstraction is often low cost, not recommended to do.

2.3. Basic Layer

The base layer contains two parts, the first is the interface definition, and the second is the technical component.

2.3.1, interface definition

Interface definition is based on different technical framework, combined with business needs, design a reasonable interface, for business components, they will only perceive the technical interface, and not to perceive the technology implementation, we should not be the specific technical details upward exposure, which is called interface-oriented programming. Technology interface is often a bridge between business and technology, the interface itself is a business meaning, the most common is the DAO interface, we design DAO interface, will not be designed to insert, update, query such a business-independent interface, but designed to Insertuser, Updateuserbyid and so on and business-related interfaces, the same truth, design cache interface, also can not be designed to put, get such interface, but should be designed to cacheuser,deprecateuser such interface.

2.3.2, Technical components

The technical components of a stand-alone system are generally divided into two types, one of which is generic technology components such as data storage, caching, messaging and scheduling tasks, transactions, and locks. One is infrastructure, such as the spring container, the Tomcat container. Let's talk a little bit about generic technology components.

Data storage: Data storage includes relational databases, non-relational databases, and file storage systems. relational databases, such as MySQL, are ideal for storing most business data. Non-relational databases, such as HBase, can store historical logs or archive historical MySQL data. File storage systems, generally based on Linux file systems, compared to tablets, HTML files, and so on, also have HDFs-based, for big data analysis.

Cache: The cache can be divided into nanosecond cache, millisecond cache and hundred-millisecond cache by response time. Nanosecond Cache is a general local memory-based cache, such as Encache, millisecond cache is typically a centralized memory cache, such as Memcache, because of the remote invocation of access, so the response time will be extended to a few milliseconds, hundred milliseconds cache is generally a centralized and persistent cache, such as Redis, Because of the remote access and read persistence records caused by the cache breakdown, the response time is longer, to dozens of or even hundreds of milliseconds. A standalone system typically uses a local memory cache enough to access the database directly when the cache is penetrated.

Message and dispatch tasks: the essence of message and dispatch tasks is an asynchronous means, the difference is that the message cannot control the asynchronous time, and the dispatch task can. Generally, when a message is sent out, the system that listens to the message immediately receives the message, triggering the execution of the business logic immediately, while the dispatch task executes the business logic, one or more times, according to the scheduling rules. Single-machine system in the message and scheduling tasks to use less, in the log monitoring may use the message, in the data report statistics may use the scheduling task.

Transaction: Transaction essence is based on the database to achieve, single-machine system transaction is dependent on database transactions, we can use SPRING-TX transaction template for transaction operations, in business logic development, must grasp the size of the transaction, it is recommended that the business is relatively close to a lot of database operations in a transaction, Don't arbitrarily turn on transactions for each method.

Lock: Two kinds of locks are used in single system: optimistic lock and pessimistic lock. Optimistic locking relies on the database's Business table plus version fields to implement, each update will determine whether the version changes, if the change will need to retry, the size of the lock is smaller. Pessimistic lock is based on the lock interface of the JDK, the lock and release of a business process to lock the operation, the granularity of the locks is relatively coarse.

3. Summary

The above is my experience after a long period of time to find out the business technology architecture, self-considered to be general, but also to a certain extent to support the volatile business. Of course, this architecture is certainly not a silver bullet, it is impossible to solve all business scenarios, so ultimately it will need to focus on specific scenarios for reference.

About the author

Wu's heart is currently an architect in the Hangzhou Traveler's Planet, focusing on technical architecture and product architecture.

Build a more general business technology architecture