Microservices with Martin Fowler

来源https://martinfowler.com/articles/microservices.html

Summary

The article “Microservices” by Martin Fowler discusses an architectural style for software systems that has been gaining popularity due to its flexibility and scalability. Here’s a summary highlighting the key points:

Microservice Architectural Style: This approach involves developing a single application as a suite of small, independent services. Each service runs in its own process and communicates with other services using lightweight mechanisms, often HTTP resource APIs.
Characteristics: Microservices are built around business capabilities and can be independently deployed through automated deployment processes. They may be written in different programming languages and use different data storage technologies, with minimal centralized management.
Comparison to Monolithic Architecture: Traditional monolithic applications are built as a single unit, making changes and scaling more challenging. Microservices, in contrast, allow for more granular updates and scaling as each service can be updated and scaled independently.
Componentization via Services: Unlike libraries that are linked into a program, services are out-of-process components that communicate over a network. This allows for independent deployment and updates of individual services.
Organized Around Business Capabilities: Microservices are organized around business capabilities rather than technical layers, leading to cross-functional teams that can develop and manage their services end-to-end.
Products, Not Projects: The microservice approach favors a product mentality where teams own a product throughout its lifecycle, as opposed to the project model where development ends and maintenance begins after delivery.
Smart Endpoints and Dumb Pipes: Communication between microservices is kept simple, often using RESTful APIs or lightweight messaging, avoiding complex protocols and centralized orchestration.
Decentralized Governance: Microservices allow for the use of different technologies best suited for each service, as opposed to a single standardized technology platform in monolithic architectures.
Decentralized Data Management: Each microservice manages its own database, a concept known as Polyglot Persistence, which allows for flexibility but also introduces challenges in managing data consistency.
Infrastructure Automation: Automation is crucial for building, deploying, and operating microservices. Continuous Delivery practices are key to managing the complexity of multiple services.
Design for Failure: Microservices must be designed to handle failures gracefully, as network calls between services can fail. This requires sophisticated monitoring and possibly the use of patterns like circuit breakers.
Evolutionary Design: The microservice architecture supports evolutionary design, allowing for frequent, controlled changes to the software. Services are designed to be replaceable, and teams expect some services to be scrapped rather than evolved.
Future of Microservices: While the article acknowledges the positive experiences with microservices, it also expresses cautious optimism about their future. The long-term effects of microservices architecture are not yet fully understood, and challenges such as defining service boundaries, managing complexity, and ensuring team skill are highlighted.

In essence, microservices offer a way to build and manage complex applications more flexibly and scalably than traditional monolithic architectures. However, they also introduce new challenges that must be carefully managed to be successful.