Preface
In the project structure, do some pre-preparation in advance, which can make it more convenient for you to transform in the future.
-
Whether it is scalable and the nodes are balanced.
(WeChat accesstoken only allows single node to pull, so accesstoken and scalable nodes should not be put together) -
Is it possible to separate the server from the test server and the official server.
(Whether the redis key has a service identifier, and whether the redis db index distinguishes isolation or the like) -
Whether it is developed
by multiple people (Is the project's directory level reasonable, the probability of multi-person development and merge conflicts, the probability of sharing the same switch, and the probability of multi-editing global variables.) -
Is it possible to split sub-services from the main project.
(Updated at the same time as the main service, but does not affect each other, whether to share launch parameters, whether to distinguish configuration files, whether nginx routing conflicts) -
Whether it is convenient for middleware expansion.
(Postgres and redis respond to the number of people, changed to a cluster, the connection mode of redis/pg was changed from local passwordless to cross-intranet with password, read-write separation) -
Whether it is convenient to "duplicate the car".
(Whether the code structure is suitable for automatically generating model structure, http interface, gateway, document description) -
The service depends on whether there is an order of initiation.
(It's best to transform it into a harmless order.) -
Whether it is suitable for burying point statistics
-
Whether there is potential demand such as limited flow, fusing, and active and standby services.