Micro-service Architecture pros and cons _microservice

Advantages and disadvantages of micro-service architecture

Previously reprinted an article on the Micro-service architecture written by Martin Fowler: "Micro-Service (microservices)". Today, I will reprint an article summarizing the advantages and disadvantages of this architecture.

Reprinted from: "Micro-service, make the development process simpler or more complex." , the debate on micro-service architecture: simpler or more complex. 》。

With the concept of devops, continuous delivery and so on, the micro-service architecture began to enter our horizons.

So micro-service is the industry's long-awaited solution. or the micro-service is simpler than the whole solution.

Let's define the Micro service first:

Micro-service is a set of small services to build an application, the services run independently in different processes, services through a lightweight communication mechanism (such as the RESTful interface) to interact, and services can be deployed independently through automated deployment. Because services are independent of each other in a micro-service architecture, different services can be developed using different languages, or different types of databases are used depending on the needs of the business.

James Lewis and Martin Fowler from ThoughtWorks shared their understanding and perceptions of the micro-service architecture. In this paper, the author introduces the characteristics of micro-service and the advantages of micro-service architecture compared with traditional architectures.

Some of the advantages of

Micro services are obvious: services are simple, only focus on a business function  
in the view of James, the traditional holistic architecture has great limitations in building deployment and scaling, and its server applications are like a piece of iron, unwieldy and not split, Changes to any program in the system require the entire application to be rebuilt and deployed to the new version. It is only possible to extend the entire system while extending horizontally, not to a single functional module.  
While the micro-service architecture decomposes the system into multiple services in a modular manner, the services are relatively independent and loosely coupled, and a single functional change requires only the rebuilding of the appropriate services. Each micro-service can be developed by different teams  
traditional development patterns tend to be technical units in the Division of labor, such as UI teams, service-side teams, and database teams, which can cause any functional changes to be communicated and coordinated across teams. While micro-service advocates the division of labor around services, different services can be implemented using different technologies, and a team should include all the skills needed for development, such as user experience, database, project management. Micro-service is loosely coupled  
Micro-service architecture abandons the complex business rules orchestration of an ESB, message routing functions, services in the micro-service architecture are high cohesion, each service will handle the corresponding business, all the business logic should be handled within the service as far as possible, and the communication between the services as lightweight as possible, such as the way to use restful. Can be developed with different programming languages and tools  
traditional software development often uses the same technology platform to solve all problems, and experience shows that using the right tools to do the right things can make development more effective. The micro-service architecture is inherently such that we can use Node.js to develop a simple report page that uses C + + to write a live chat component.

The introduction of the

Micro-service architecture provides the possibility for a variety of durable data storage, where the persistence layer can use traditional relational databases and NoSQL. Unlike traditional applications, in a micro-service architecture, we can choose a new database system for each service, such as MongoDB, PostgreSQL, which is suitable for business logic. The benefit is obvious, first of all, we can decide which type of database to use based on the type of business (read more or write more), and then reduce the load on a single database. &NBSP
James's article has aroused extensive discussion in the community, Contino's CTO Benjamin Wootton wrote that micro-services were not as good as they thought, and suggested that developers should be cautious when choosing this architecture. Benjamin that the micro-service architecture may face some of the following challenges: operational costs  
More services also means more operations, the product team needs to ensure that all the relevant services have a sound monitoring and other infrastructure, the traditional architecture developers only need to ensure that an application is working properly, Now it is a daunting task to ensure that dozens of or even hundreds of processes operate efficiently. DevOps requirements  
After using a micro-service architecture, the development team needs to ensure that a tomcat cluster is available to ensure a database is available, which means that the team needs high quality devops and automation technology. And now, such a full stack of talent is very few. Implicit interfaces  
Services and services are "contacted" through interfaces, and when a service changes the interface format, all services that may be involved in this interface need to be adjusted. Repetitive labor  
The same functionality may be used in many services. This function point is not large enough to provide a service level, this time may be different service teams will develop this function alone, duplicate business logic, which violates a good software engineering many principles. Complexity of distributed systems  
Micro Services connect different services through rest APIs or messages, which may have been a simple remote procedure call before. Distributed systems also mean that developers need to consider network latency, fault tolerance, message serialization, unreliable networks, asynchrony, versioning, load, and so on, and in the face of so many micro services need to be distributed, the entire product needs a complete set of mechanisms to ensure that each service can function properly. transactional, asynchronous, test-facing challenges  
transactions across processes, large amounts of asynchronous processing, and a whole range of tests across multiple micro-services require a complete set of solutions, and it now appears that these technologies are not mature.

All in all, the micro-service architecture has many attractions, but before embracing the micro-service, it needs to recognize the challenges it poses. Each architecture has its pros and cons, and we need to choose the right architecture based on the project's business and team situation.

Https://www.cnblogs.com/zgynhqf/p/5679028.html?utm_source=tuicool&utm_medium=referral