Misreading and misunderstanding of micro-services [GO]

MicroServices are really popular, but the misunderstanding of MicroServices is also true, and this article introduces these misconceptions hit:

One, micro-service is not enough "micro"?

Although the definition of microservices is clear, the developer community's interpretation of it is controversial, with some of the main issues being as follows:

1. Is it a representative of the monolithic architecture?
2. Is it a representative of a single service?
3. Is it a combination of logical functions?

Let's take a look at the banking application as an example: the three-tier architecture solves the tight coupling between technical components, allowing them to independently change and not depend on each other. For example, web-side changes do not affect back-end services. However, the three-tier architecture does not take into account the functionality and features that are based on component grouping, so I came up with the name of a "functional" architecture to indicate that the architecture needs to be divided by the characteristics of the product. This is essential for the performance and throughput of modern applications, and I'll explain the details further in the article.

Second, micro-service Scalability

MicroServices are an architectural style that allows you to attack on the scale of a magnificent system, how is this done? The traditional three-tier architecture service can be scaled and expanded, what is so special about microservices? For example: Online travel booking, purchase request and booking request ratio is 100:1

1. What does this mean, 101 requests, the purchase request can reach 100, and the reservation request only 1;
2. This is the alarm bell! The resources required for booking are much smaller than the resources consumed by the purchase, so why not scale the entire system to 100:1 as expected?

third, micro-services to help maintain and operate

"Rolling restart", "Hot Deploy", "polling deployment," Does that sound familiar? Maintaining application systems with minimal downtime is a typical state priority for modern application systems. Let's take an example where changing the application will run through the entire three-tier architecture, including changes to the database application. If the semantics of the data are modified, any of the above techniques are doomed (for example: ORM (object mapping relationship) Once you see the object changes, you need to restart all nodes). About MicroServices: Functional-layer architecture brings a new level of performance to high availability and maintenance. Even if the Bank report micro-service crashes, it will not affect the other functions of the banking system. You will be glad that 90% of consumers do not use the bank statement function.

Iv. micro-services need to be further explored

Well, any system of automatic scaling needs to be mined.

1. There are 10 nodes in the micro-service which are shopping, and two nodes are scheduled;
2. Due to the holiday season, the inflow flow is relatively high;
3. What do you expect to get from a manual split shopping example?
4. Assuming that more than one instance is spun out, how does the load balancer achieve a balanced balance?

A traditional load balancer can work well in a static environment, but it's bad when you dynamically add nodes or execute a new instance of a script. If the microservices can be scaled, the MicroServices project needs to be mined, registered, added to achieve load balancing, and most of the software problems are solved by referencing the indirect layer. Each micro-service needs to be self-registered when it is shut down or started. This requires a registered administrator-load balancer, which is sensitive to the loading of the microservices. How to check it,

Netflix solves this problem, and Netflix has load balancing on open source Eureka AWS.

v. Does microservices support multiple programming languages?

As the name implies, MicroServices are protocol-driven services that are based on http/rest (Xml/json data transfer). The clear definition boundary between microservices and lightweight protocols helps build a diverse programming team because their focus is on functionality rather than the choice of language.

Six, micro-services and containers are in heaven?

The cumbersome and modern nature of the virtual machines, which split and disassemble them into microservices, makes microservices ideal for containers. This is the real devops, and playing the package is not just a container for microservices but also an execution environment for the whole. The downside is that the application team will be the infrastructure team and need a good understanding of the container.

VII. Micro-services Add additional complexity?

1.Jenkins Simple channel to deploy two applications to 2 Tomcats, and so on, will be expanded out of countless micro services;
2. As the number of deployments increases, the time for deployment has risen significantly;
3. The need for a good container management, deployment and distribution of tools and technologies;
4. Each micro-service will have more log files, if there is no stash, splunk this appropriate tool, docking debugging transactions will become a nightmare;
5. If each tomcat has 10 connections, you will find hundreds of connections from different microservices databases because the database connection cannot be shared (microservices with no database attached);

Summary

Everything comes at a price, and microservices are the same, not all applications have the same architecture, and not all applications have the same requirements for high availability, scalability, maintainability.

Misreading and misunderstanding of micro-services [GO]