A microservice is an architectural style that structures an application as a collection of small, loosely coupled, independently deployable services. Each service typically focuses on a specific business capability and can be developed, deployed, and scaled independently. Microservices communicate with each other through well-defined APIs, often using lightweight protocols such as HTTP/REST, gRPC, or messaging queues.
- Structure: A single, unified codebase where all components are tightly integrated.
- Deployment: Deployed as a single unit. Any change or update requires redeploying the entire application.
- Development: Usually simpler to develop initially but can become complex and difficult to manage as the application grows.
- Scaling: Scaling requires scaling the entire application, even if only a small part of it requires more resources.
- Structure: Composed of multiple, independent services, each responsible for a specific business function.
- Deployment: Each service can be deployed independently, allowing for continuous deployment and updates.
- Development: Enables teams to work on different services simultaneously, often with different technologies and frameworks.
- Scaling: Allows for granular scaling, where individual services can be scaled independently based on their specific resource needs.
- Each service can be deployed, updated, and scaled independently, reducing the risk of deployment failures and allowing for faster release cycles.
- Teams can choose the best technology stack for each service based on its requirements, enabling the use of the latest and most suitable technologies.
- Failures in one service do not necessarily affect other services, enhancing the overall resilience and reliability of the application.
- Services can be scaled independently, allowing for more efficient use of resources and cost-effective scaling.
- Microservices align well with agile and DevOps practices, allowing teams to be more autonomous and responsible for specific services.
- Smaller codebases are easier to understand, maintain, and refactor, leading to better code quality and reduced technical debt.
- Managing multiple services, including their deployment, monitoring, and communication, introduces significant complexity compared to a monolithic application.
- Issues such as network latency, message serialization, and handling partial failures need to be addressed.
- Maintaining data consistency across services can be challenging and often requires implementing complex patterns like eventual consistency and distributed transactions.
- Running multiple services often requires more resources, such as CPU, memory, and storage, compared to a monolithic application.
- Requires robust DevOps practices, including continuous integration, continuous deployment, containerization, and orchestration tools like Kubernetes.
- Communication between services needs to be carefully managed to ensure efficient and reliable interactions, often requiring additional infrastructure like API gateways and service meshes.
- Individual services for user management, product catalog, inventory, payment processing, and order management.
- Separate services for account management, transaction processing, fraud detection, and reporting.
- Distinct services for user profiles, posts, comments, likes, notifications, and messaging.
- Independent services for patient records, appointment scheduling, billing, and prescription management.
Microservices offer significant benefits in terms of flexibility, scalability, and maintainability, making them suitable for large, complex applications with high demands for agility and reliability. However, they also introduce considerable complexity and require sophisticated DevOps practices and infrastructure. The choice between monolithic and microservice architecture depends on the specific requirements, scale, and maturity of the development and operations teams within an organization.
GO libraries to develop micro services.
When you zoom one micro service, the flow is as below
- Simplify common database operations, such as CRUD (Create, Read, Update, Delete) operations, batch processing and transactions (for SQL), by providing high-level abstractions and utilities.
- Generic CRUD Repository
- It is like CrudRepository of Spring, which promotes rapid development and consistency across applications.
- While it provides many advantages, such as reducing boilerplate code and ensuring transactional integrity, it also offers flexibility and control over complex queries.
- My batis for GOLANG, nodejs
- Support:
- SQL. The sample is at go-sql-generic-sample.
- Mongo. The sample is at go-mongo-generic-sample.
- Cassandra. The sample is at go-cassandra-sample.
- Firestore. The sample is at go-firestore-sample.
- Elastic Search. The sample is at go-elastic-search-generic-sample.
- Hive. The sample is at go-hive-sample.
- Dynamodb. The sample is at go-dynamodb-tutorial.
Visit core-go/io, you can see rich data processing:
- Import data from CSV or fix-length format files to SQL, Mongo, Cassandra, Firestore, Elastic Search, Hive
- Export data from SQL, Mongo, Cassandra, Firestore, Hive to CSV or fix-length format files
Please visit core-go/mq, Linked In article Standardize-7-Message-Queues.
- Because message queues are a crucial component in modern software architecture, we support most of message queues, such as Kafka, RabbitMQ, IBMMQ, Active MQ, NATS, Google Pub/Sub, Amazon SQS.
- Support 2 levels of 7 message queues:
- Standardize and simplify 7 message queues, for 9 libraries rabbitmq/amqp091-go, aws-sdk-go/service/sqs, go/pubsub, ibmmq, ActiveMQ, nats.go, segmentio/kafka-go, IBM/sarama and Confluent.
- Support standard level, which share the same interface with all message queues
- Abstract the consumer flow
- Support dead letter queue
- Support SDK or original library level, you can use all advance features of the SDK/libraries
Please visit core-go/health and Microservice Health Check. We support databases, message queues, redis, http client:
- http client
- Redis: go-redis/redis to support redis/go-redis, garyburd/redigo to support gomodule/redigo.
- Database: sql, mongo, dynamodb, firestore, elasticsearch, cassandra, hive
- Message queues: Kafka, RabbitMQ, IBMMQ, Active MQ, NATS, Google Pub/Sub, Amazon SQS.
Visit core-go/log and Middleware-Log-Tracing for more details.
Standardize API for logging, support 2 libraries:
- middleware: Log request and response at http middleware, allow to configure dynamic field names
- client: Log request and response at http client, allow to configure dynamic field names
- Support for CRUD, search (not required in every application). Sample is at go-backoffice.
Refer to MemoryCacheService for more details
- Time To Live: automatically clean up the expired objects in the memory cache
- Maximum size: When the memory exceeds the max size (which is configurable), it automatically remove the oldest object.
The library is here Redis. Support 2 libraries:
Check required, email, url, min, max, country code, phone number, regular expression...
Samples are go-admin, go-backoffice and go-location
- Generate the model by URL
- Paging
- Sort
- SQL
- Mongo
- Dynamodb
- Firestore
- Elasticsearch
- Build some standard interfaces, which can be shared by multiple providers: SMTP and Sendgrid
- The sample is go-authentication
- storage
- Samples are at go-storage
Please visit Authentication, we support:
- Support to log in by user name/password
- Login by LDAP (both server side and client slide)
- Login by Google, Facebook, Linkedin, Microsoft, Amazon, Dropbox
- Support any database design (SQL, Mongo, Firestore, Cassandra)
Please visit security: Sample is go-admin
- Identity and Access Management: Authorization at middleware, support http (mux, chi), gin, echo
- Support any database design (SQL, Mongo, Firestore, Cassandra)
- Crypto
- JWT
- sign up with password
- verify account (without password)
- sign up without password
- verify account (require to input password)
- authenticator
- ldap authenticator
- 2 factor authentication
- forgot password
- change password (also support change password 2 factors)
- reset password
- Libraries of core-go
- input: database, project settings
- output: metadata
- input: metadata, project templates
- output: project (working application)
- GUI, include "export" and "generate"
- https://github.com/lowcode-tech/windows
- https://github.com/lowcode-tech/mac
- https://github.com/lowcode-tech/linux
https://github.com/source-code-template
- https://github.com/source-code-template/go-sql-sample
- https://github.com/source-code-template/go-mongo-sample
- https://github.com/source-code-template/mongo-layer-architecture-sample
- https://github.com/source-code-template/sql-layer-architecture-sample