Directory Structure

[!TIP] This document is machine-translated by Google. If you find grammatical and semantic errors, and the document description is not clear, please PR

Directory splitting refers to the directory splitting in line with the best practices of go-zero, which is related to the splitting of microservices. In the best practice within the team, We split a system into multiple subsystems according to the horizontal division of the business, and each subsystem should have an independent persistent storage and cache system. For example, a shopping mall system needs to consist of a user system (user), a product management system (product), an order system (order), a shopping cart system (cart), a settlement center system (pay), an after-sale system (afterSale), etc.

System structure analysis

In the mall system mentioned above, while each system provides services to the outside (http), it also provides data to other subsystems for data access interfaces (rpc), so each subsystem can be split into a service , And provides two external ways to access the system, api and rpc, therefore, The above system is divided into the following structure according to the directory structure:

  1. .
  2. ├── afterSale
  3. │   ├── api
  4. │   └── rpc
  5. ├── cart
  6. │   ├── api
  7. │   └── rpc
  8. ├── order
  9. │   ├── api
  10. │   └── rpc
  11. ├── pay
  12. │   ├── api
  13. │   └── rpc
  14. ├── product
  15. │   ├── api
  16. │   └── rpc
  17. └── user
  18.     ├── api
  19.     └── rpc

rpc call chain suggestion

When designing the system, try to make the call between services one-way in the chain instead of cyclically. For example, the order service calls the user service, and the user service does not call the order service in turn. When one of the services fails to start, it will affect each other and enter an infinite loop. You order to think it is caused by the user service failure, and the user thinks it is caused by the order service. If there are a large number of services in a mutual call chain, You need to consider whether the service split is reasonable.

Directory structure of common service types

Among the above services, only api/rpc services are listed. In addition, there may be more service types under one service, such as rmq (message processing system), cron (timed task system), script (script), etc. , Therefore, a service may contain the following directory structure:

  1. user
  2.     ├── api //  http access service, business requirement realization
  3.     ├── cronjob // Timed task, timed data update service
  4.     ├── rmq // Message processing system: mq and dq, handle some high concurrency and delay message services
  5.     ├── rpc // rpc service to provide basic data access to other subsystems
  6.     └── script // Script, handle some temporary operation requirements, and repair temporary data

Example of complete project directory structure

  1. mall // 工程名称
  2. ├── common // 通用库
  3. │   ├── randx
  4. │   └── stringx
  5. ├── go.mod
  6. ├── go.sum
  7. └── service // 服务存放目录
  8.     ├── afterSale
  9.     │   ├── api
  10.     │   └── model
  11.     │   └── rpc
  12.     ├── cart
  13.     │   ├── api
  14.     │   └── model
  15.     │   └── rpc
  16.     ├── order
  17.     │   ├── api
  18.     │   └── model
  19.     │   └── rpc
  20.     ├── pay
  21.     │   ├── api
  22.     │   └── model
  23.     │   └── rpc
  24.     ├── product
  25.     │   ├── api
  26.     │   └── model
  27.     │   └── rpc
  28.     └── user
  29.         ├── api
  30.         ├── cronjob
  31.         ├── model
  32.         ├── rmq
  33.         ├── rpc
  34.         └── script

Guess you wants