Introduction
The respective benefits of microservices and monolithic services have been explained very clearly in the previous article. This article is not about which service architecture should be used. Rather, assuming that the project will eventually adopt a microservice architecture, there will be two situations. In the first case, at the beginning of the project, a single service is first used and then gradually converted to microservices during the development of the project. The other is One is to adopt the architecture of microservices from the beginning.
This article will discuss the reasons for using these two methods.
Monomer first, then microservice
Microservices are a useful architecture, but even their advocates say that using microservices is only useful for more complex systems.
Because using microservices itself has a management service cost, this cost will slow down the team's development speed. So for simpler applications, it is easier to use monolithic services. Therefore, the proponents of this approach believe that the new application should be built as a monolithic application at the beginning, even if it is likely to be converted into a microservice in the end.
The first reason is that in the early stage of the system, we don’t know how many users it will have, and in the first stage of the software, we usually consider the speed of software development, so everyone may be more inclined to use a single application. . If microservices are used, if the design of the microservices is poor, the subsequent system cannot be expanded and can only be redesigned.
The second reason is that they can only work well when a good and stable boundary is proposed between services. Any functional reconstruction between services is much more difficult than a single application. But even an experienced architect working in a familiar domain can hardly determine the boundaries at the beginning. By building a monolithic service first, you can figure out what the correct boundary is, and then transform microservices above the boundary.
One way to convert a monolithic service into a microservice is to design the monolithic service reasonably, such as paying attention to the modularity of the software, including API boundaries and data storage methods. If this can be done well, then the subsequent shift to microservices is a relatively simple matter.
Another method is to start with a single application and gradually peel off the edge microservices. This method can leave a huge monolith at the core of the microservice architecture, but most new developments use microservices, and monolithic applications are no longer extended.
Another is to completely replace the monomer application. This can completely abandon the architectural burden brought by the monomer and start over. The price is to spend more manpower and time.
So, if you can't build a well-structured monolithic application, what makes you think you can build a set of well-structured microservices?
Start directly with microservices
Of course, some people hold different opinions because they think:
If you can indeed build a well-structured monolithic application, then you may not need microservices in the first place.
That is to say, whether it is a single service or a microservice, a detailed requirement analysis is required before construction. After a thorough analysis, you can understand whether you need to use microservices with one click, and the boundaries of each service are also defined. So why not use microservices directly?
The main benefit of microservices is to establish a boundary between different services. In this way, it is difficult for us to make mistakes, such as connecting parts that should not be connected, and coupling parts that should not be coupled.
In theory, if your program follows specific rules and establishes a clear boundary in the overall application, then you don’t need microservices, but in actual work, this boundary will always be cross-domain.
You might assume that there are many well-separated microservices hidden in your single project, waiting to be extracted. But in reality, it is difficult to make such a division.
If you start with a whole, the parts will become very tightly coupled with each other. This is the definition of monolithic applications. These components will depend on the characteristics of the platform they all use. They will communicate based on a shared abstraction because they all use the same library. They will communicate in a way that is only available when they are hosted in the same process. Worse, these parts will share domain objects (almost) freely, relying on the same shared persistence model, assuming that database transactions are available at any time, so there is no need for compensation... which makes it very difficult to split transactions again. So it is very difficult to split the existing monomer into separate parts.
So when you start, you should consider the subsystems you are building and build them as independently as possible. Of course, you should only do this if you think your system is large enough to guarantee this. If only you and one of your colleagues have built something in a few weeks, then you don't need to use microservices at all.
to sum up
The world of software architecture is always interesting, and we will learn many different perspectives in the process of exploring.
This article has been included in http://www.flydean.com/10-microservices-monolith/
The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。