![](https://csdnimg.cn/release/download_crawler_static/9960143/bg11.jpg)
changes. A microservice architecture makes continuous deployment feasible.
Third, each service can be scaled independently of other services using X-axis cloning
and Z-axis partitioning. Moreover, each service can be deployed on hardware that is
best suited to its resource requirements. This is quite different than when using a
monolithic architecture where components with wildly different resource requirements
– e.g. CPU intensive vs. memory intensive – must be deployed together.
The microservice architecture makes it easier to scale development. You can organize
the development effort around multiple, small (e.g. two pizza) autonomous, teams.
Each team is solely responsible for the development and deployment of one or more
related services. Each team can develop, deploy and scale their services independently
of all of the other teams.
The microservice architecture also improves fault isolation. For example, a memory
leak in one service only affects that service. Other services will continue to handle
requests normally. In comparison, one misbehaving component of a monolithic
architecture will bring down the entire system.
Last but not least, the microservice architecture eliminates any long-term commitment
to a technology stack. In principle, when developing a new service the developers are
free to pick whatever language and frameworks are best suited for that service. Of
course, in many organizations it makes sense to restrict the choices but the key point is
that you aren’t constrained by past decisions.
Moreover, because the services are small, it becomes practical to rewrite them using
better languages and technologies. It also means that if the trial of a new technology
fails you can throw away that work without risking the entire project. This is quite
different than when using a monolithic architecture, where your initial technology
choices severely constrain your ability to use different languages and frameworks in
the future.
1.5 Drawbacks of microservices
Of course, no technology is a silver bullet, and the microservice architecture has a
number of significant drawbacks and issues. Indeed most of this book is about how to
address the drawbacks and issues of the microservice architecture. As you read about
the challenges don’t worry - later on, I’ll describe ways to address them.
One challenge with using the microservice architecture is that there isn’t a concrete,
well-defined algorithm for decomposing a system into services. Like much of software
development, it is some what of an art. To make matter’s worse, if you decompose a
system incorrectly you will build a distributed monolith, a system consisting of
coupled services that must be deployed together. It has the drawbacks of both the
monolithic architecture and the microservice architecture.
Another challenge with using the microservice architecture is that developers must deal
with the additional complexity of creating a distributed system. Developers must use
an inter-process communication mechanism. Implementing use cases that span
©Manning Publications Co. We welcome reader comments about anything in the manuscript - other than typos and
other simple mistakes. These will be cleaned up during production of the book by copyeditors and proofreaders.
https://forums.manning.com/forums/microservice-patterns
Licensed to rong fengliang <1141591465@qq.com>