Hi, I am entropy reduction, see the words as the face.
Microservices is a software architectural style designed to enhance the scalability, maintainability, and testability of applications by breaking them down into small, independent services.
While microservices can provide many benefits to software development, they are not always the best choice for all situations.
In other words, the microservice architecture is not a silver bullet for software engineering.
Therefore, when the technical team considers whether to use the microservice architecture, the following 10 points need to be carefully considered.
added complexity
There is nothing free in this world. Realizing the microservice architecture requires a large amount of supporting infrastructure, such as service discovery, load balancing, and inter-service communication. These mechanisms and systems will increase the complexity of the system and make maintenance costs higher.
Microservices can solve many problems, such as application scalability and maintainability, but it is not a single solution. It needs to be used in conjunction with other technologies and best practices, such as DevOps, CI/CD, and containerization.
test more difficult
When using the microservice architecture, the system testing work will become more complicated. In addition to the necessary individual tests for each service, it also needs to be tested together with other services it depends on to finally guarantee the quality of the system.
More expensive to deploy
Microservices require more development, deployment, and testing effort, and require more server resources.
For small to medium-sized applications and simple systems, a microservices architecture might be too complex and expensive to be worth adopting.
O&M costs are higher
That is, each service is very simple, and it is always easier to manage and support one service than to manage 100 services.
When using the microservice architecture, you have to manage and monitor multiple services, which may increase the overhead of a lot of operation and maintenance resources.
Under the microservice architecture, developers still need to put in a lot of work, such as designing and implementing services, as well as monitoring and troubleshooting.
Debugging is more difficult
One of the biggest challenges of the microservice architecture is that in a distributed system, it is extremely difficult to locate and debug system problems.
In a huge distributed microservice system, it is self-evident that it is difficult to locate and identify the root cause of the problem. For example, it is necessary to obtain information in multiple systems, coupled with complex call relationships, it is necessary to clarify before integrating and concatenating information.
System latency will be higher
Microservices communicate with each other over the network, which can introduce additional latency to your system.
所以，对于时延要求较高的场景，就需要慎重考虑微服务的调用层级关系和具体的代码实现方式，以满足场景所需。
难以理解的系统
当系统内多个服务独立开发和运行时，我们就很难以掌握系统整体的运行状况了。
系统之间是如何组合的，调用请求是如何流转的，数据是如何传递的等。
都会让理解成本增加不少，系统变得难以掌控，可观测性降低，分险也就增加了。
需要专职团队
微服务并不是无代价的。
微服务架构的有效落地，需要一个具备分布式系统、网络和DevOps专业技能的团队。
采用微服务架构需要大量的投资，例如培训、开发、测试、部署和维护。
企业需要考虑这些成本，并权衡微服务架构的优点和缺点。
安全的问题
微服务并不是无风险的，保护微服务架构比保护单体应用更具挑战性。
采用微服务架构可能会引入新的风险，例如服务之间的通信问题、服务部署和版本控制问题、以及依赖关系的复杂性。这些风险需要被认真评估，并且需要采取适当的措施来减轻这些风险。
并不总是必要的
微服务并不是适用于所有团队的。
采用微服务架构需要更高的技术能力和开发经验。
对于一些中小型团队或初创公司来说，可能没有足够的资源和技能来开发和维护微服务架构。
因此，需要根据团队的技能和经验，以及项目的规模和复杂度来评估，是否适合采用微服务架构。
微服务不是一个必选项，只是一个可选项而已。
最后
尽管微服务架构在很多情况下可以提供一些优势，但也需要根据具体情况进行评估和决策。
技术团队，需要考虑技术和业务需求，以及组织的能力和资源等多个方面，并综合权衡微服务架构的优缺点，才能做出正确的决策。
阅读，思考，练习，分享，日日不断之功。
嗯，写完了。
新的一天，加油哦 (ง •̀_•́)ง