Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the advantages and disadvantages of micro-service architecture". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn what are the advantages and disadvantages of micro-service architecture.

Micro-service practice (1): advantages and disadvantages of micro-service architecture

Author: Chris Richardson. Source: dockone.io release time: 2015-05-28 19:58 Reading: 23974 recommendations: 7 original links [favorites]

Abstract: this article, from the official blog of Nginx, is the first article in a series of microservices, which mainly discusses the shortcomings of traditional monolithic applications, as well as the advantages and challenges of microservices architecture. As the author said, the micro-service architecture is more suitable for building complex applications, although it has its own shortcomings.

Original English text: Introduction to Microservices

The author of this article is Chris Richardson, the founder of CloudFoundry.com, the early Java-based Amazonite EC2 PaaS platform. Now he provides consulting services for enterprises on how to develop and deploy applications. He also regularly publishes articles about microservices on http://microservices.io.

The microservice is getting more and more attention in blogs, social media discussion groups and conference presentations, and it ranks very high on Gartner's 2014 Hype Cycle. At the same time, there are many skeptics in the software community who believe that microservices are nothing new. Naysayers believes that this is the repackaging of the SOA architecture. However, despite the different arguments, the micro-service architecture model is providing great help for agile deployment and complex enterprise application implementation.

This blog is the first in a series of seven articles on how to design, develop, and deploy microservices. Readers will learn the method and compare it with the monolithic architecture model (Monolithic will be translated into monomer in this article). This series of articles will describe the different elements of the microservice architecture. You will learn about the advantages and disadvantages of the microservice architecture model in order to decide whether to better apply the microservices architecture to your project and how to apply it.

First of all, let's look at why we should consider using microservices.

Develop monolithic applications

Suppose you are preparing to develop a taxi scheduling software that competes with Uber and Hailo. After preliminary meetings and demand analysis, you may start this new project manually or using a generator based on Rails, Spring Boot, Play or Maven. Its hexagonal architecture is modular, as shown in the following diagram:

The core of the application is business logic, which is accomplished by modules that define services, domain objects, and events. Around the core are adapters that deal with the outside world. Adapters include database access components, message components that produce and process messages, and web modules that provide API or UI access support.

Although it is also modular logic, it will eventually be packaged and deployed as a single application. The specific format depends on the application language and framework. For example, many Java applications will be packaged in WAR format and deployed on Tomcat or Jetty, while other Java applications will be packaged into self-contained JAR format. Similarly, Rails and Node.js will be packaged into hierarchical directories.

This style of application development is common because IDE and other tools are good at developing a simple application that is easy to debug and can be tested end-to-end by simply running the application and linking UI with Selenium. Monolithic applications are also easy to deploy. You only need to copy the packaged applications to the server, and you can easily expand the applications by running multiple copies on the back end of the load balancer. In the early days, such applications worked well.

The deficiency of monolithic application

Unfortunately, this simple method has great limitations. A simple application will grow over time. In each sprint, the development team will face a new "story" and then develop a lot of new code. In a few years, this small and simple app will become a giant monster. Here's an example I recently discussed with a developer who is writing a tool to analyze the dependencies between JAR files in an application with millions of lines of code. I'm pretty sure this code is a monster that many developers have worked hard to develop over the years.

Once your app becomes a big and complex monster, it must be painful for the development team. Agile development and deployment is difficult, and the main problem is that the application is too complex for any single developer to understand. As a result, fixing bug and adding new features correctly becomes very difficult and time-consuming. In addition, team morale will also decline. If the code is difficult to understand, it cannot be modified correctly. It will eventually lead to a huge and incomprehensible quagmire.

Monolithic applications can also slow down development. The larger the application, the longer the startup time. For example, a recent survey shows that sometimes apps take more than 12 minutes to start. I've also heard that some apps take 40 minutes to start. If developers need to restart applications frequently, then most of the time will be spent waiting, and productivity will be greatly affected.

In addition, complex and huge monolithic applications are not conducive to sustainable development. Today, the norm for SaaS applications is to change many times a day, which is very difficult for monolithic applications. In addition, the impact of this change is not well understood, so a lot of manual tests have to be done. Then, continuous deployment will also be difficult.

When resource conflicts occur in different modules of monolithic applications, it will be very difficult to expand. For example, one module that completes a CPU-sensitive logic should be deployed in AWS EC2 Compute Optimized instances, while another in-memory database module is more suitable for EC2 Memory-optimized instances. However, because these modules are deployed together, we have to make a compromise on the hardware choice.

Another problem with monolithic applications is reliability. Because all modules are running in a single process, a bug in any module, such as a memory leak, may bring down the entire process. In addition, because all application instances are unique, this bug will affect the reliability of the entire application.

Finally, monolithic applications make it very difficult to adopt new architectures and languages. For example, imagine that you have 2 million lines of code written in the XYZ framework. If you want to change to the ABC framework, both the time and the cost are very expensive, even if the ABC framework is better. Therefore, this is an insurmountable gap. You have to bow in front of the original choice.

To sum up: you start with a very successful key business application, and then you become a huge, incomprehensible monster. The use of outdated and inefficient technologies makes it difficult to hire potential developers. The application cannot be extended, the reliability is very low, and in the end, agile development and deployment cannot be completed.

So how to deal with it?

Microprocessor architecture-- dealing with complex things

Many companies, such as Amazon, eBay and NetFlix, have solved these problems by adopting a microprocessor architecture model. The idea is not to develop a huge monolithic application, but to decompose the application into small, interconnected micro-services.

A microservice generally performs a specific function, such as order management, customer management, and so on. Each microservice is a miniature hexagonal application with its own business logic and adapter. Some micro-services will also release API to other micro-services and application clients. Other microservices complete a Web UI, and at run time, each instance may be a cloud VM or a Docker container.

For example, a possible decomposition of a previously described system is as follows:

Each application functional area is done using microservices, and in addition, Web applications are split into a series of simple Web applications (such as one for passengers and one for taxi drivers). Such a split is easier to deploy for different users, devices, and special application scenarios.

Each backend service opens a REST API, and many services themselves use the API provided by other services. For example, driver management uses a notification service that informs the driver of a potential demand. The UI service activates other services to update the Web page. All services use asynchronous, message-based communication. The internal mechanism of microservices will be discussed in a subsequent series.

Some REST API are also open to mobile apps used by passengers and drivers. These applications do not directly access the background service, but deliver intermediate messages through API Gateway. API Gateway is responsible for load balancing, caching, access control, API billing monitoring and other tasks, which can be easily implemented through NGINX. Later articles will introduce API Gateway.

The microservice architecture pattern in the above figure corresponds to the Y axis representing the extensible Scale Cube, which is a three-dimensional extended model described in the book "The Art of Scalability". The other two extensible axes, the X axis consists of multiple application copies running at the back end of the load balancer, and the Z axis routes requirements to related services.

Applications can basically be represented by the above three dimensions, and the Y axis represents the decomposition of applications into micro-services. At run time, the X axis represents the running of multiple instances hidden behind the load balancer, providing throughput. Some applications may still partition services with the Z axis. The following figure shows how the itinerary management service is deployed on Docker running on AWS EC2.

At run time, the itinerary management service consists of multiple service instances. Each service instance is a Docker container. To ensure high availability, these containers generally run on multiple cloud VM. In front of the service instance is a layer of load balancers such as NGINX, which are responsible for distributing requests between instances. The load balancer also handles other requests, such as caching, permission control, API statistics, and monitoring.

This micro-service architecture model has a profound impact on the relationship between the application and the database. Unlike the traditional multiple services sharing a database, each service in the micro-service architecture has its own database. In addition, this line of thinking also affects the enterprise data schema. At the same time, this pattern means multiple pieces of data, but a unique database for each service is necessary if you want to reap the benefits of microservices, because this architecture requires this kind of loose coupling. The following figure shows an example of applying a database schema.

Each service has its own database, and in addition, each service can use its own database type, also known as a multilingual consistency architecture. For example, driver management (finding which driver is closer to passengers) must use a database that supports geographic information queries.

On the face of it, the micro-service architecture pattern is a bit like SOA, which is made up of multiple services. However, from another perspective, the microservice architecture pattern is a SOA that does not contain Web services (WS-) and ESB services. Micro-service applications prefer to use simple lightweight protocols such as REST rather than WS-, to avoid using ESB and similar functions like ESB within micro-services. The microservice architecture model also rejects the use of SOA concepts such as canonical schema.

Benefits of microservice architecture

The microservice architecture model has many benefits. First of all, the complexity problem is solved by decomposing huge monolithic applications for multiple service methods. With the same function, the application is decomposed into multiple manageable branches or services. Each service has a clearly defined boundary using either RPC- or message-driven API. The micro-service architecture pattern provides a modular solution for functions that are difficult to achieve with single coding, so that a single service is easy to develop, understand and maintain.

Second, this architecture allows each service to be developed by a dedicated development team. Developers are free to choose development technologies and provide API services. Of course, many companies try to avoid confusion and offer only certain technological options. Then, this freedom means that developers do not have to be forced to use the outdated technology that was used at the beginning of a project, they can choose the current technology. Even, because the services are relatively simple, it is not very difficult to rewrite previous code with current technology.

Third, the micro-service architecture model is the independent deployment of each micro-service. Developers no longer need to coordinate the impact of other service deployments on this service. This change can speed up deployment. UI teams can use AB testing to deploy changes quickly. The micro-service architecture pattern makes continuous deployment possible.

Finally, the micro-service architecture pattern allows each service to expand independently. You can deploy the scale that meets the needs according to the size of each service. Even, you can use hardware that is more suitable for service resource requirements. For example, you can deploy CPU-sensitive services on EC2 Compute Optimized instances and in-memory databases on EC2 memory-optimized instances.

The deficiency of micro-service architecture

Fred Brooks wrote 30 years ago that "there are no silver bullets", like any other technology, has shortcomings in its micro-service architecture. One of them is similar to his name. "Micro Services" emphasizes the size of the service. In fact, some developers advocate building a slightly larger, 10-100 LOC service group. Although small services are more likely to be adopted, don't forget that this is only the choice of the terminal, not the ultimate goal. The purpose of microservices is to effectively split applications and achieve agile development and deployment.

Another major deficiency is that micro-service applications are distributed systems, which will bring inherent complexity. Developers need to choose between RPC or messaging and complete the interprocess communication mechanism. What's more, they have to write code to deal with local failures such as slow or unavailable message delivery. Of course, this is not difficult, but compared with monolithic applications through language-level methods or process calls, this technology is more complex.

Another challenge for microservices comes from the partitioned database architecture. It is common to update messages to multiple business sub-subjects at the same time in business transactions. This kind of transaction is easy for monolithic applications because there is only one database. In micro-service architecture applications, different databases used by different services need to be updated. Using distributed transactions is not necessarily a good choice, not only because of CAP theory, but also because today's highly scalable NoSQL databases and messaging middleware do not support this requirement. In the end, you have to use an ultimate consistent approach, which puts forward higher requirements and challenges for developers.

Testing an application based on a micro-service architecture is also a complex task. For example, using the popular Spring Boot architecture, it is easy to test the REST API of a monolithic web application. In turn, the same service test needs to start all the services associated with it (at least the stubs of those services). Once again, the complexity of adopting a micro-service architecture cannot be underestimated.

Another challenge is that changes in the application of the microservice architecture model will affect multiple services. For example, suppose you are completing a case where you need to modify services A, B, and C, and A relies on BMagne B and C. In monolithic applications, you just need to change the relevant modules, integrate the changes, and deploy them. In contrast, the micro-service architecture model needs to consider the impact of related changes on different services. For example, you need to update service C, then B, and finally A, fortunately, many changes generally affect only one service, and there are few changes that require coordination of multiple services.

Deploying a micro-service application is also complex, and a distributed application simply needs to deploy its own servers behind a complex equalizer. Each application instance needs to configure basic services such as database and message middleware. By contrast, a micro-service application generally consists of a large number of services. For example, based on the fact that Adrian Cockcroft,Hailo consists of 160 different services, NetFlix has about 600 services. Each service has multiple instances. This results in a lot of parts that need to be configured, deployed, extended, and monitored. In addition, you need to complete a service discovery mechanism (published in subsequent articles). To discover the address (including server address and port) of the service that communicates with it. The traditional problem-solving method can not be used to solve such a complex problem. In turn, the successful deployment of a micro-service application requires developers to have adequate control over deployment methods and a high degree of automation.

One way to automate is to use PaaS services, such as Cloud Foundry. PaaS provides developers with an easy way to deploy and manage microservices, all of which are packaged and solved built-in. At the same time, system and network experts who configure PaaS can adopt best practices and strategies to simplify these issues. Another way to automate the deployment of microservice applications is to develop the most basic PaaS system for you. A typical starting point is to use a clustering scheme, such as Mesos or Kubernetes with Docker. In the following series, we will look at how to provide caching, permission control, API statistics and monitoring at the micro-service level based on software deployment methods such as NGINX.

Thank you for your reading. the above is the content of "what are the advantages and disadvantages of the micro-service architecture". After the study of this article, I believe you have a deeper understanding of the advantages and disadvantages of the micro-service architecture. the specific use situation still needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.