sponge 中文

sponge is a microservice framework, a tool for quickly creating microservice code. sponge has a rich generating code commands, a total of 12 different functional code, these functional code can be combined into a complete service (similar to artificially broken sponge cells can be automatically reorganized into a new sponge ). Microservice code features include logging, service registration and discovery, registry, rate limit, circuit breaker, trace, metrics monitoring, pprof performance analysis, statistics, caching, CICD. The code uses a decoupled layered structure and it's easy to add or replace functional code. As an efficiency-enhancing tool, commonly repeated code is basically generated automatically and only business logic code needs to be populated based on the generated template code examples.

sponge command framework

The generated code is based on three approaches Yaml, SQL DDL and Protocol buffers, each possessing different functional code generation, and the framework diagram of the generated code is shown in Figure 1-1.

Figure 1-1 spong generation code framework diagram

• Yaml generates configuration files corresponding to go struct code.
• SQL DDL generated code includes http, handler, dao, model, proto, rpc, service, divided into two types of web and rpc, web and rpc types have their own sub-modules, each module code can be generated separately, between the modules like an onion layer of independent decoupling. The code includes standardized CRUD (add, delete, change, check) business logic, which can be directly compiled and used.
• web type code: Generate http service code including handler, dao, model three sub-module code, as shown in the diagram inward contain, the same principle, generate handler module code contains dao, model two sub-module code.
• rpc type code: generate rpc service code including service, dao, model, protocol buffers four sub-modules, as shown in the diagram inwards contain, generate service module code including dao, model, protocol buffers three sub-module code.
• The code generated by Protocol buffers includes http-pb, rpc-pb, rpc-gw-pb, also divided into web and rpc types, where http-pb, rpc-pb are usually used in combination with dao, model code generated by SQL DDL.
• http-pb: http service code includes two sub-modules, router and handler template, excluding the operation database sub-module, and subsequent business logic code is filled to the handler template file.
• rpc-pb: rpc service code includes service template a sub-module, not including the operation database module, subsequent business logic code filled to the service template file.
• rpc-gw-pb: rpc gateway is actually an http service, including two submodules, router and service template, where the service template code is the business logic code related to calling the rpc service.

In the same folder, if the latest generated code is found to conflict with the original code, sponge will cancel the generation process and will not make any changes to the original code, so you don't have to worry about writing business logic code that is overwritten.

Microservices framework

The microservice code framework created by sponge is shown in Figure 1-2, which is a typical microservice hierarchy containing common service governance functions.

Figure 1-2 Microservices framework diagram

Microservices main functions:

• Web framework gin
• RPC framework grpc
• Configuration file parsing viper
• Configuration Center nacos
• Logging zap
• Database component gorm
• Caching component go-redis ristretto
• Documentation swagger
• Authorization jwt
• Validator validator
• Rate limiter ratelimit
• Circuit Breaker circuitbreaker
• Tracing opentelemetry
• Monitoring prometheus, grafana
• Service registry and discovery etcd, consul, nacos
• Performance analysis go profile
• Code inspection golangci-lint
• Continuous Integration CI jenkins
• Continuous Deployment CD docker, kubernetes

The code directory structure follows project-layout, and the code directory structure is shown below.

.
├── api               # proto files and the generated *pb.go directory
├── assets            # Directory of other assets used with the repository (images, logos, etc.)
├── build             # Package and continuous integration directory
├── cmd               # Program entry directory
├── configs           # Directory for configuration files
├── deployments       # Configuration and template directories for IaaS, PaaS, system and container orchestrated deployments
├─ docs               # Design documentation and interface documentation directory
├── internal          # The code directory for private applications and libraries
│ ├── cache           # business wrapper based cache directory
│ ├── config          # The configuration file directory for the Go structure
│ ├── dao             # Data access directory
│ ├── ecode           # Custom business error code directory
│ ├── handler         # http's business function implementation directory
│ ├── model           # Database model directory
│ ├── routers         # http routing directory
│ ├── rpcclient       # The client directory to connect to the rpc service
│ ├── server          # Service entry, including http, rpc, etc.
│ ├── service         # rpc's business function implementation directory
│ └── types           # Directory of request and response types for http
├── pkg               # The directory of libraries that external applications can use
├── scripts           # A directory of scripts for performing various build, installation, analysis, etc. operations
├── test              # Additional external test procedures and test data
└── third_party       # External helpers, forked code, and other third-party tools

The web service and rpc service directory structures are basically the same, with some directories unique to the web service (routers, handlers, types in the internal directory) and some directories unique to the rpc service (services in the internal directory).

Documentation

• Installation
• Quickly create web projects
• Quickly create microservices projects
• Service governance introduction
• Continuous Integration And Continuous Deployment

If it's useful to you, give it a star ⭐.

License

See the LICENSE file for licensing information.