Definitions of distributed and microservice architectures

Distributed application scenarios cover a wide range of areas, and the parts I understand:

• Communication between different processes,
• Call between distributed objects on different hosts,
• Distributed file systems for big data storage,
• A naming service used to identify networks with each other,
• An acentric peer model for computing or storage in a cluster,
• Distributed transactions,
• Replication of data copies in a distributed environment,
• Cloud computing services,
• Vod and transmission of audio and video in network
• .

The purpose of microservice architecture is to decouple the original overly large and heavy cloud application services by reasonably disassembling business modules. The granularity of disassembling is usually controlled by architects to realize fine-grained services, which form a distributed state in the cloud.

Then microservices have some distributed application scenarios, such as: call between distributed objects of different hosts, EJB used to use RMI (remote method call), now microservices commonly used RPC (remote procedure call); Another example is the naming service for network recognition. EJB used to be the JNDI naming service, and Now SpringCloud’s Euraka is used for registration and discovery of microservices, as well as distributed naming services.

How to understand “distributed system” in a popular way, what problems it solves, and what are its advantages and disadvantages?

Understand what happened to “distributed systems.

Above is my other answer, which describes in some detail the historical comparison between EJB and Spring, as well as distributed versus individual applications. At that time, EJB stood for distributed services and Spring for singleton services.

The diagram above simply depicts the process of unbundling a single service into a microservice. Of course, the challenge facing microservices is not only so simple, this is only a relatively initial state of microservices.

What problems do distributed and microservices solve

Distributed is the form and state in which computing, service and storage communicate and collaborate with each other in the network

What does distribution solve?

The figure above shows a typical distributed computing scenario. A large file is divided into four parts, and MapReduce is divided into four tasks (processes). The data is then processed on different processes or hosts on the same host, and finally aggregated into a combined task over the network. At this time, the distributed task is parallel, which solves the efficiency problem of single task.

The figure above is a typical distributed state coordination management diagram, which is the HA architecture of Hadoop HDFS cluster. The primary and secondary Namonode nodes must be alive. When the primary fails, the secondary node must be put on top. The ZKFC process is used to monitor the heartbeat of Namoenode and issue switching commands.

The other three JournalNodes form a cluster where the namonode distributed state data is stored. When the primary Namonode dies, all states must be quickly restored to the secondary Namenode, so the Journalnode must constantly synchronize state. Fast recovery of HDFS cluster status

Then a very critical application scenario in distributed — cluster, the Hadoop HDFS cluster mentioned above, requires one or more roles (ZooKeeper, Journalnode) as the coordinator and manager of cluster state. Sometimes this state management is peer-to-peer (GlusterFS), and sometimes it is centralized (Hadoop is the case).

What problems do microservices solve?

If you’re talking about the distributed advantage of microservices, it’s not the end, it’s the means. Microservices simply leverage a distributed architecture to achieve their goals. So microservices are not an underlying technology architecture problem, but an architecture problem for the upper application.

The above example is a simple web application, medical service monomer visits at this time, medicine, order, instant messaging, are the most core business, Internet medical information push aims to Internet medical platform of Internet information service platform of all kinds of information push, post and communication, achieve the goal of self promotion.

Can just have a high degree of information push service updates, because need Internet service platform in complicated cases of external connections, will also have a new service platform into the module, then as a single application problems such a deployment, each update function, a new information push to the overall service to redeploy, This kind of influence has caused great trouble to the core service. At this time, the business influence of patients, doctors and hospitals is large-scale.

Look at micro service architecture, if will exist as a separate micro service information push service, other services will only need to push to the content of the Internet service platform of remote call, even in the same way that a message center, packaged into news, realize the news event driven, let foreign publishing service deployment will not interfere with other core services, Minimize the impact of deployment and release on the overall platform. Doesn’t this look a lot more comfortable, better for deployment, distribution, and even robustness of the overall system?

Of course, there are still many problems solved by microservices, such as fine-grained division of labor, improvement of iteration speed, ease of small-scale refactoring, and facilitation of sustainable integration (DevOPS), etc., which will not be described in detail, but only the parts with characteristics of microservices will be taken to understand.

Third, the advantages and disadvantages brought by these structures

Distributed corresponding is single, its advantage on section describes some, do not go into, disadvantages also large deployment is not simple, operational not simple network bottlenecks and fault will have important influence, if the node failure, need to be perceived and hot replacement mechanism, the consistency problem, such as distributed transaction has been a worldwide problem, should not only consider the balanced load, The effect of load balancing should be considered. Data is stored in distributed mode, and data skew is also considered in some peer-to-peer modes. Except for distributed storage shortcoming 6, the first 5 disadvantages of microservices are basically perfect inheritance.

4. Technical debt caused by improper use

Talk about the troubling problem of poorly designed microservices

(1) Decoupling of microservices will change some business programs from database query to remote object call. I mentioned this process in the original answer, which is anti-human. Both the complexity of the formation and the interface that requires convention introduce more work than SQL queries. And in a more dehumanizing way, the database is also divided by microservices, which data needs to be redundant and which data can keep the database paradigm, basically annoying the elevation people to death.

(2) Inexperienced microservice architects tend to cut microservices too finely. If a single unit is cut into a thousand microservices, and remote object serialization and deserialization are used between microservices, then this becomes a dead end! Because once the entity object of a microservice is adjusted, how many associated microservices are contaminated, and the work of constantly locating and republishing the dependencies of other microservices exceeds the work of solving the business problem.

Therefore, attention must be paid to the division of microservices, and object transfer between RPCS should be done with a simple and loose structure as far as possible. The granularity of microservice division varies according to different businesses. There is an agreement that a large reconstruction of a microservice takes one week as the granularity standard of microservice.

V. Is the project directly using microservice architecture based on future considerations?

The consideration of microservice architecture should not be about the future, but an architecture reconstruction after the problems of single application in the past. The reconstruction process can be seen from the figure in section 1. In the case of Internet medical treatment, the reconstruction of microservice further tends to be message-driven and event-driven.

In the implementation of micro service experience and lessons from the past, I summed up the experience and if it is the architect, the new project can be applied to choose the monomer, and then a little bit of iterative reconstruction according to the business development to the service, even if in the process of micro service architecture not so pure, and even individual applications and services coexist for a long time, It is also prudent to design microservices directly from new projects.

Because no one is a fortune teller, who can estimate the day, layer and scope of his business system will need microservices decoupling. Only when the system is up and running near that stage will it be easier for the architect to make sound microservitization decisions. Of course, some people may have doubts. If the system is designed as a single unit, who has the heart to continue to reconstruct microservices? It is much easier to make the microservice architecture directly.

Vi. What are the differences and connections between K8s and Spring Cloud?

Spring Cloud is a concrete implementation framework for implementing the microservices architecture, including SpringBoot as a stand-alone container for microservices, Euraka as a registration and discovery container for microservices, and Zuul as a service gateway. The rest are not very useful, so I’ll leave the gateway out, but I prefer Openresty.

K8s is just a kind of container layout framework, manager of a large number of Docker containers, but now K8S does not integrate docker, dizzy very!

As a container of microservices, Docker provides a separate network, file system, process management and other infrastructure for each microservice, so that the status and running log of each microservice can be better monitored and managed. In addition, containers simplify the deployment process and facilitate the popular devOPS development, release, and deployment management model. The containerization of microservices is a perfect match.

At the end,

When we understand clearly what the various scenarios under the distributed is a form of existence, when we understand what micro-service is a distributed scenario, we will be more clear to do a good job of micro-service design decisions.

I’m a “Read Bytes” creator who delves into big data technology and interprets distributed architectures

Head over to Byte Read Zhihu — learn more about big data

Public id Read-byte “Read bytes” Distributed, big data, depth of software architecture, professional interpretation