[note] this article is excerpted from:Microservices Guide (martinfowler.com)
In short, it is a micro application development styleA set of small servicesMethod for each small serviceAll run in their own processesAnd communicate with lightweight mechanisms (usually HTTP resource APIs). These servicesBuild around business functionsAnd can be deployed automaticallyIndependent deployment。 These services can be written in different programming languages and use different data storage technologies, as long as centralized management is minimized.
— James Lewis and Martin Fowler (2014)
At the end of 2013, after hearing all the discussions about microservices in my circle, I began to worry about the unclear definition of microservices (such fate)It brings many problems to SOA）。 So I got together with my colleague James Lewis, who is one of the senior practitioners of this style. Let’s write together
we wrote this article to provide a clear definition of the microservice style. We achieved this by listing the common features of the microservice architecture we saw in this field.
- Componentization through services
- Organize around business capabilities
- Product is not a project
- Smart endpoints and dumb pipes
- Decentralized governance
- Decentralized data management
- Infrastructure automation
- Fault design
- Evolutionary design
we also studied some common questions, such as “how large is the scale of microservices” and “what is the difference between microservices and service-oriented architecture”. This article has aroused people’s interest in microservices.
“We use it, we don’t use it?
… what the hell is this? “
in my brief introductory speech (about 25 minutes), I selected the most important defining features, compared microservices with overall components, and outlined the important work to be done before putting the first microservice system into production.
When should we use microservices?
Any architectural style needs to be weighed: we must evaluate its advantages and disadvantages according to the context it uses. This must be the case with microservices. Although it is a useful architecture, in fact, in most cases, it is better to use overall components.
Microservices offer advantages
- Strong module boundaries: microservices strengthen the modular structure, which is particularly important for large teams.
- Independent deployment: simple services are easier to deploy, and because they are autonomous, they are less likely to cause system failure when errors occur.
- Technological diversity: with microservices, you can mix multiple languages, development frameworks and data storage technologies.
… but at a price
- Distributed: distributed systems are difficult to program because remote calls are slow and always at risk of failure.
- Final consistency: for distributed systems, maintaining strong consistency is very difficult, which means that everyone must manage final consistency.
- Operational complexity: you need a mature operational team to manage a large number of services that are redeployed regularly.
In the past year, microservice architecture style has been a hot topic. At the recent O’Reilly software architecture conference, it seems that every conference is talking about microservices. Enough to make everyone’s “over hype detector” start and flash. One of the consequences is that we have seen that the team is too eager to accept microservices without realizing that microservices will bring complexity to itself. This adds extra cost to the cost and risk of the project – which usually puts the project into serious trouble.
Martin Fowler May 13, 2015
when I heard the story of the team using microservice architecture, I noticed a common pattern.
- Almost all successful microservice stories begin with a huge whole and are broken down
- I’ve heard of itA system built from scratch as a microservice systemAre in serious trouble.
Don’t start with the whole
Over the past few months, I’ve heard many times that the only way to achieve a successful microservice architecture is to start from the whole. In the words of Simon Brown: if you can’t build a well structured whole, why do you think you can build a set of well structured microservices? The most recent (often very persuasive) argument comes from Martin fouqin on the site. When I had the opportunity to comment on the earlier draft, I had some time to consider this. I do this, especially because I usually find myself in agreement with him, and some other ideas I usually share seem to agree with him. I firmly believe that it is usually wrong to start from the whole.
Stefan tilkov June 9, 2015
When I talk to people about using the microservice architecture style, I hear a lot of optimism. Developers prefer to use smaller units and expect better modularity than overall components. However, as with any architectural decision, trade-offs are required. Especially for microservices, this has serious consequences for operations. Operators must now deal with the ecosystem of small services, rather than a well-defined single whole. Therefore, if you don’t have some basic abilities, you shouldn’t consider using the microservice style.
Martin Fowler August 28, 2014
The first law of microservices and distributed objects
In EAA’s P, I say “don’t distribute your objects”. Does this suggestion contradict my interest in microservices?
Martin Fowler August 13, 2014
Interview with Sam Newman on micro services
The goto conference asked me to interview Sam Newman’s book “monoliths to microservices”. This becomes a general discussion about microservices and when to use them. Sam believes that their three main reasons are independent deployability, data isolation and reflecting organizational structure. I’m more skeptical about the first one, but I think data and people are complex parts of software development.
Martin Fowler September 4, 2020
the microservice architecture is quite new, but I’m lucky that we’ve been working with them at ThoughtWorks since it first appeared. The best description of how to best work with them is Sam Newman’s Book Building microservices, which he wrote based on our experience and other published experience.
Testing strategy in microservice architecture
In the past few years, service-based architecture has shifted to smaller and more centralized “micro” services. This approach has many advantages, such as the ability to deploy, extend and maintain each component independently, and parallelize development among multiple teams. However, once these additional network partitions are introduced, the testing strategy applied to monolithic process applications needs to be reconsidered. Here, we plan to discuss ways to manage the additional testing complexity of multiple independently deployable components and how to keep testing and application correct when multiple teams act as guardians of different services.
Toby Clemson November 18, 2014
How to decompose a single application into micro services
As the overall system becomes too large to handle, many enterprises tend to decompose it into micro service architecture style. It’s a worthwhile journey, but it’s not easy. We have learned that to do this, we need to start with simple services, and then provide services based on vertical functions that are important to the business and change frequently. These services should be large at first, and it is best not to rely on the rest as a whole. We should ensure that every step of the migration represents an atomic improvement of the entire architecture.
Zhamak dehghani April 24, 2018
Micro front end
The front-end development is very difficult. It becomes more difficult to expand front-end development so that many teams can deal with large and complex products at the same time. In this article, we will describe a recent trend to split the front-end into many smaller and easier to manage parts, and how this architecture can improve the efficiency of the front-end code team. In addition to discussing various benefits and costs, we will also introduce some available implementation options and delve into a complete example application that demonstrates the technology.
Cam Jackson June 19, 2019
How to extract data rich services from the whole
When splitting a monolithic server into smaller services, the most difficult part is actually splitting the data that exists in the monolithic database. To extract data rich services, it is useful to follow a series of steps to always keep a single write copy of the data. These steps are first logically separated in the existing whole: the service behavior is divided into separate modules, and then the data is divided into separate tables. These elements can be moved to the new autonomous service respectively.
Prafur todkar August 30, 2018
Infrastructure is code
Infrastructure, that is, code, is a method of defining computing and network infrastructure through source code, which can then be treated as any software system. Such code can be kept in source control to allow auditable and replicable builds, services from test practices, and complete specifications for continuous delivery. Over the past decade, this approach has been used to deal with the growing cloud computing platform and will become the next major method to deal with computing infrastructure.
Martin Fowler March 1, 2016
Agile software development breaks some isolated islands between requirements analysis, testing and development. Deployment, operation and maintenance are other activities that are similarly separated from the rest of the software development process. The Devops campaign aims to eliminate these islands and encourage collaboration between development and operations.
Rouan wilsenach July 9, 2015
For the software system, it is usually to call the software running in different processes remotely, which may be on different computers in the network. One of the biggest differences between in memory calls and remote calls is that remote calls may fail or hang without a response until a timeout limit is reached. To make matters worse, if you have many callers on unresponsive vendors, you may run out of critical resources, resulting in cascading failures between multiple systems. Michael nygard popularized the circuit breaker mode in his excellent book release it to prevent this disastrous chain reaction. The basic principle of fuse is very simple. Wrap the protected function call in a fuse object that monitors for faults. Once the fault reaches a certain threshold, the fuse will trip and all further fuse calls will return an error without making a protected call at all. Usually, if the fuse trips, you also need some kind of monitor alarm.
Martin Fowler March 2014