Rebuilding a Go Microservice Skeleton from Scratch: The EasyMS Journey

Why Rebuild EasyMS?

The previous version built on Go‑Kit introduced excessive abstraction layers, unintuitive code, and tight framework coupling, making customization difficult. The decision was to discard Go‑Kit entirely and create a lightweight, framework‑free microservice skeleton.

Overall Design Philosophy

EasyMS is positioned as an engineering practice template rather than a new framework. The core goals are:

Clear startup flow

Decoupled infrastructure

Service governance placed upfront

All capabilities are replaceable and evolvable

Project Structure (simplified)

easyms.golang
├── cmd/                # Service entry point
├── configs/            # Local configuration files
├── pkg/
│   ├── config          # Config loading & hot‑update
│   ├── registry        # Service registration & discovery
│   ├── log             # Unified logging wrapper
│   └── server          # HTTP server wrapper
├── middleware/         # Rate‑limit / circuit‑breaker / logging middleware
└── deploy/docker       # Docker & Compose

Service Startup Flow (main.go)

The lifecycle is fully expanded in cmd/main.go without hidden logic. The sequence is:

Config loading → Log initialization → Service registration → Middleware injection → HTTP server start

This explicit flow aids newcomers in understanding, debugging, and customizing the service.

Configuration System – First Line of Defense

Configuration errors are a common failure source in microservices. Design goals:

Support local configuration files

Support Consul as a configuration center

Enable hot‑update of configurations

Zero intrusion to business code

Dual‑Source Mode

Local development – local configuration file

Testing / Production – Consul configuration center

Benefit: the same service binary runs in different environments without code changes.

Service Registration & Discovery

All registration logic resides in pkg/registry, invisible to business code. Responsibilities include:

Service instance registration

Health‑check reporting

Removal of unhealthy instances

Service deregistration

Principle: the registry is infrastructure and should not pollute business logic.

Why Consul?

Mature and stable

Clear API

Simple deployment

Low debugging cost

Consul provides sufficient capabilities for small‑to‑medium microservice systems.

Framework‑Free Governance via Middleware

Common concern: without Go‑Kit, how to handle rate limiting, circuit breaking, and logging? Middleware design principles are:

Single responsibility

Pluggable

Composable

Non‑intrusive to business logic

Implemented or planned middleware includes:

Request logging

Dynamic rate limiting

Circuit breaking

Trace / metrics extension points

Key Takeaways

Microservice complexity stems from engineering, not the language.

Frameworks raise the entry floor but hide hidden costs.

Sustainable systems must be understandable.

EasyMS now offers a clear startup path, well‑defined module boundaries, and a solid foundation for continuous evolution.

Future Plans

Multi‑level cache optimization for higher stability

Gateway enhancements (logging, policy routing, dynamic intelligent rate limiting, circuit breaking, recovery)

Database access layer improvements (slow‑query analysis, smart index optimization, one‑click read/write splitting)

Deployment environment upgrades (CI/CD, testing, gray releases)

Project Source Code

GitHub: https://github.com/louis-xie-programmer/easyms.golang

Gitee (faster in China): https://gitee.com/louis_xie/easyms.golang