In the stage of formulating technical specifications, the development manager or architect should coordinate all developers, designate relevant technical specifications and maintain communication with developers, so that developers can understand the modules or subsystems they are responsible for, and ensure that developers can follow the architectural intent. realize various functions.
1 Basic coding conventions
Basically every company has such a document (if not, you can basically consider job-hopping), this document is generally not related to the project, such as naming conventions, annotation specifications, SQL specifications and so on. In addition, it is necessary to unify jdk, including local development environment and server environment; determine the project name, package name, database name, table name, and whether each table needs common fields (such as version optimistic lock version number) and so on.
Two places are emphasized here, project specification and package name directory specification.
Engineering specification : It is particularly important to clearly define the boundaries of each engineering module, especially in distributed systems. Developers should have a good understanding of the hierarchy of the framework, such as when to define DTO and when to define Domain . If this is not clarified, the size of the project will become larger and larger in the entire life cycle of the project. Once this problem is exposed, it will be a disaster.
Package name directory specification : The package directory specification should start from the top level as much as possible, and the developer's package directory permissions should be as low as possible. It is the unified standard. Another point is to avoid the same package path for two project modules, which is very likely to conflict when referencing.
2 Define the boundaries and responsibilities of components
After the system is decomposed, it is necessary to define the boundaries and responsibilities of components (subsystems or modules). This is the most concerned issue for developers at the beginning of the project. If this is not clearly defined, the subsequent system will face the danger of refactoring.
For example, basic data, not all basic data and configuration information are placed in basic data. Only basic data and configuration information across systems, services, and modules belong to the category of basic data management; in addition, the interface of basic data services needs to have certain Universality, minimize opening of special interfaces for a system, service, or module; and do not allow basic data services to depend on upper-layer services.
3 Project Version Definition
At the beginning of the project, except for some basic modules, such as public modules such as tools, which may be packaged into Release versions, others are generally SNAPSHOT versions. Provide a jar package reference, the role of version control will be highlighted. Here we recommend a batch of articles "Semantic Version 2.0.0" , which is about the semantic version specification, which was established by Tom Preston-Werner , founder of Gravatars and co-founder of GitHub .
4 svn code management and release specifications
According to the development model of the project, determine the relationship between the trunk, branches, and tags of the code, as well as the release process specification of the relevant environment.
5 Automatic build
In the development of distributed systems, it is impossible to imagine without automatic construction. Often a project has many sub-projects deployed on dozens or even hundreds of servers. If there is no automatic build, developers may spend a lot of time on the service package release. Once a test bug needs to be released immediately, it will take a long time, which will exhaust the entire team.
6 Code Log Specifications
The log of the project is prohibited from outputting the log to the Console in the production environment. In the project code, the Logger object needs to be used to output logs and exceptions. It is forbidden to use methods such as system.out.println to output, and it is forbidden to use e.printStackTrace to output exceptions. The log needs to be divided into two dimensions, date and size, to avoid log files that are too large and cannot be opened. The log level of the production environment does not allow DEBUG to be turned on. If it is really necessary for troubleshooting, it can be turned on for a specific class instead of setting the entire environment to DEBUG, which may cause the system to freeze due to file locks.
7 Unified exception handling
In a distributed business processing system, there are a large number of cross-service calls in the system, and different types of exceptions need to be processed at different levels. The processing methods need to adapt to different types of exception processing with the continuous expansion of the system. Service exceptions are uniformly defined and quickly locate the source and cause of cross-service exceptions. Generally, the purpose of identifying the system is achieved by defining the unified abnormal code of the whole system, and defining the cause of its occurrence.
8 Provide batch update method
Batch updates must use the provided unified batch update method, which greatly improves performance. If there are very special scenarios that cannot be used, they must be reviewed, otherwise this may become a performance bottleneck.
9 Provide basic services early
Such as SMS services, mail services, these basic services should be prioritized for development, because almost every module may be involved.
10 Standardized multi-threaded writing
If multiple threads are used in the system, do not open up threads at will, use a unified thread pool as much as possible, and encapsulate the public calling methods and return results.
11 Handling of Standardized Transactions
8.1 Avoid generating a transaction that locks multiple rows of data for a long time, and disassemble or change the transaction to be asynchronous as much as possible.
8.2 Distributed Transactions
In the project, data consistency is not achieved through distributed transactions at the database level as much as possible, but the final consistency of data is achieved through asynchronous, compensation, idempotent, etc. methods.
l Idempotency:
Any externally provided service entry method must implement idempotency, and the same result can always be obtained when the same method is called repeatedly with the same parameters, without causing repeated processing.
Query service: The query itself is idempotent, so no additional processing is required.
New service: control the uniqueness of data through unique constraints to avoid repeated data writing
Update service: control the idempotency of data through optimistic locking
Delete service: delete itself is also idempotent, so no additional processing is required
l Asynchronous message processing:
When performing transaction processing across systems, use asynchronous message processing as much as possible, first save the data as an intermediate state, and write the message into MQ, which is subscribed by the downstream system for processing. After the downstream system has finished processing, the result is fed back to the upstream to update the status. The data written in MQ should not use the complete data under normal circumstances, which will cause high IO pressure on MQ and the data may have expired, and the queue will become dedicated instead of general, which may not be subscribed by other services.
l Compensation
During MQ processing, there may be problems such as message loss and failure. Loss of data may cause the process to be interrupted. Therefore, compensation measures are needed to ensure that the process will not be interrupted for a long time. A timing compensation measure is provided by the most upstream system of a distributed transaction to detect the process of long-term outstanding transactions, and retrigger this process (rewrite MQ).
12 Determine the basic data caching scheme
Caching is often neglected. It is only when the performance bottleneck is encountered in the later stage of the project that it is found that it needs to be refactored. At that time, the cost is very high, so it is necessary to determine the caching plan as soon as possible, which is to use ehcache? guava? redis? This must be determined and Let the developers implement it.
13 Standardize the use of cache environment
For memcached/redis cache environment planning, it is necessary to define the data structure usage specifications. For example, everyone cannot use key/value to store, which will eventually lead to a messy cache environment.
14 Distributed file storage
Determined as soon as possible to do a shared disk physically? Or use a distributed file system?
15 Unit Tests
Writing unit tests should become a habit, and in addition, unit tests should have no side effects. A well-defined unit test that is run multiple times, if no other conditions change, should produce exactly the same result each time. For example, it is common to insert some fake data in the database, and then verify this data in the test, the test in this way is not reliable because the database may change. You can use an in-memory database during unit testing or the data for each unit test is automatically produced and automatically deleted at the end.
One of the main reasons why many colleagues are afraid of writing unit tests is that there are too many dependencies (remote service calls, redis, webservice, etc.). If a service hangs for various reasons, the test will fail. To solve this pain point, you can introduce mock objects to meet the needs of these conditions, and Mockito is such a framework. Mockito is used to simulate related behaviors without having to prepare various dependent environments. At this time, you only need to focus on business logic. Can.