Cheng Learning micro-service architecture and basic article

See the recent "MicroServices Architecture" concept so fire, as a motivated program ape, Cheng can't help but want to learn. And the architect Lao Wang (not the next-door Lao Wang) has just been doing the company's basic services in the micro-service research and landing, this is deeply studied.

So Cheng immediately fart on the run to the old Wang ask: "Wang Go, I look at the micro-service architecture so fire, I also want to learn, you tell me what is the micro-service architecture Bai?" ”

Lao Wang smiled and said: "To know what is a microservices architecture, you need to know what system architecture is designed." ”

Cheng's ideal is to become an architect, usually accumulated a lot of knowledge, so the concept of "system architecture design" is still very familiar with, so he immediately gave the answer "1":

The system architecture design describes how to divide the application system into different parts according to various factors, such as business, technology, organization, flexibility, expansibility and maintainability, and make them work together and cooperate with each other in order to provide users with a certain value.

Lao Wang nodded with satisfaction, and continued to ask: "You see recently I was doing microservices research and landed, do you know why to do this thing?" ”

"Because the current three-tier architecture has a lot of drawbacks, not to meet the needs of business development chant." ”

"Right, I think you are very familiar with the current structure of the company, you have to carefully talk about the current three-tier architecture." ”

So Cheng took a piece of A4 paper, illustrated to Lao Wang about his understanding of the three-storey architecture :

Three-tier architecture means that in the course of business and technology development, the parts of different responsibilities in the system are defined at different levels, and each layer is responsible for more specific functions. A three-tier architecture typically consists of a presentation layer, a business logic layer, and a data access layer, where layers are interconnected and collaborated to form a whole, and the interior of the layer can be replaced with other parts that can work, but with little effect on the whole.

In the case of WEB applications, the early days were to put all of the presentation logic, business logic, and data access logic together, which is a layer of architecture.

Later, with the development of high-level languages such as Java,. NET, and more convenient data access mechanisms, such as Java's JDBC and. NET ADO. The data Access section is then separated to form a two-tier architecture.

Later, with the development of the concept of object-oriented design, enterprise architecture pattern and so on, the expression logic and business logic are separated, and the present three-tier architecture is formed.

The specific contents of the three-tier architecture are as follows:

• Presentation layer: The part that a user sees, hears, enters, or interacts when they use the application.
• Business Logic Layer: the part of logical calculation or business processing based on the information entered by the user.
• Data access layer: Focus on the part that effectively operates the raw data, such as storing data to storage media such as databases, file systems, and reading data from storage media.

Lao Wang is very satisfied with this explanation, made a further supplement: "You see, although the program is now divided into three layers, but only a logical layering, not a physical stratification." That is, for different layers of code, after compiling, packaging, and deploying, all the code eventually runs in the same process. And this is called a monolithic architecture. ”

Cheng scratched scratching his heads: "The original monolithic structure is this meaning AH ~ ~"

Well Based on your actual work experience, you can summarize the advantages and disadvantages of the single-block architecture. ”

The Cheng, which is usually diligent in summing up, soon lists the pros and cons of a single block architecture:

Advantages:

• Easy to develop: simple development, IDE support, easy to run and debug.
• Easy to test: All functions run in one process, and once the process is started, system tests can be performed.
• Easy to deploy: Just publish a packaged package to the server.
• Easy Horizontal Scaling: Simply create a server node, configure the runtime environment, and then publish the package to the new server node to run the program (and, of course, to take a distribution policy to ensure that the request is effectively distributed to the new node).

Disadvantages:

• High maintenance Costs: communication costs and management costs increase significantly as applications become more functional and teams grow larger. When a bug occurs, the number of reasons that could cause the bug is increasing, resulting in increased cost of analysis, positioning, and repair, and in the absence of a deep understanding of global functionality, it is easy to introduce new bugs when fixing bugs.
• Long delivery cycles: build and deploy times increase as functionality increases, and any minor modifications trigger a deployment pipeline.
• Long-term training cycle: New members understand the background, are familiar with the business and configure the environment more and more time.
• Technology selection cost is high: monolithic architecture tends to adopt a unified technology platform or solution to solve all problems, if you want to introduce a new technology or framework, the cost and risk are very large.
• Poor scalability: As the functionality increases, the cost of vertical scaling will increase, and for horizontal scaling, because all code is running in the same process, there is no way to do an independent extension of some of the functionality of the application.

Lao Wang patted into a small fat shoulder, the eyes narrowed into a seam: "The lad summed up very good!" Now that you have a good understanding of the pros and cons of the current monolithic architecture, we can begin to learn about microservices architectures. ”

Old Mr. Wang search the "microservices architecture" keyword from the web and come out with this passage:

A microservices architecture is an architectural pattern that advocates dividing a single application into a small set of services that are coordinated and co-ordinated to provide the ultimate value to the user. Each service runs in its own separate process and serves to communicate with each other in a lightweight communication mechanism (typically HTTP-based RESTful APIs) between services. Each service is built around a specific business and can be independently deployed to a production environment, a class production environment, and so on. In addition, we should try to avoid a unified, centralized service management mechanism, for a specific service, should be based on the business context, choose the appropriate language, tools to build it.

Cheng read this passage, said: "Look at a bit dizzy, foggy feeling ..."

Lao Wang hehe Smile: "Mo Panic, now give you detailed talk about the characteristics of micro-service architecture. "

1. Single Responsibility

Each service in the MicroServices architecture is a unit of business logic that conforms to the high cohesion, the low-coupling principle, and the single-responsibility principle, and different services are flexibly combined in a "pipeline" way to build a large system.

2. Lightweight communication

Services are interconnected through a lightweight communication mechanism, and the so-called lightweight, usually refers to language-independent, platform-independent interaction.

For the format of lightweight communication, we are familiar with XML and JSON, which are language-independent, platform-independent, and for the Protocol of communication, usually based on HTTP, can make the communication between the services become standardized, non-stateful. The well-known REST (representational state Transfer) is one of the lightweight communication mechanisms that enable interoperability among services. Using a lightweight communication mechanism, you can let your team choose a language, tool, or platform that is more appropriate to develop the service itself.

3. Independence

Each service is developed, tested, and deployed independently in the application delivery process.

In a monolithic architecture all functions are in the same code base, the development of function is not independent; When different teams complete multiple functions, integration and regression testing are required, and the testing process is not independent; When the test is complete, the application is built into a package, and if a bug exists, the entire deployment will fail or roll back.

In a microservices architecture, each service is a separate business unit that is highly decoupled from other services and can be independently developed, tested, and deployed by simply changing the current service itself.

4. Process isolation

In a single-block architecture, the entire system runs in the same process, and when the application is deployed, it must stop the currently running application, and then restart the process after the deployment is complete and cannot be deployed independently.

Sometimes we will extract the duplicated code into components, in a monolithic architecture, the common form of the component is called a shared library (such as a jar package or DLL), but when the program runs, all the components will eventually be loaded into the same process to run.

In a microservices architecture, applications consist of multiple services, each of which is a highly autonomous, independent business entity that can be run in a separate process, and different services can be deployed to different hosts very easily.

Theoretically, all services can be deployed on the same server node, but this is not recommended because the main thrust of the microservices architecture is high autonomy and high isolation.

"Brother Wang you are so powerful, you say that my thinking clearly a lot!" "The Cheng excited almost to be called up."

"I've known SOA before, like the idea of a microservices architecture, can you help me differentiate?" "Cheng to.

Lao Wang Hehe smiled, picked up the Cheng hand on the A4 paper, turned to the other side drew a table:

SOA implementation	Micro-Service Architecture implementation
Enterprise-class, top-down implementation	Team-level, bottom-up implementation
Services are made up of multiple subsystems and are of large granularity	A system is split into multiple services, with granular granularity
Enterprise Service bus, centralized service architecture	No centralized bus, loose service architecture
Integrated approach complex (ESB/WS/SOAP)	Simple Integration Method (Http/rest/json)
Single-block architecture system, interdependent, complex deployment	Services can be deployed independently

Then the old King drew another picture:

Cheng looked and said: "You are such a painting I probably understand, but the concept of DevOps in the picture I do not understand ah ..."

"This DevOps is a long story, you have time to check the information yourself first." ”

"good." Now that I have an understanding of the concept of microservices architecture, can you dig deeper into its nature? "

"Well, you can listen carefully, ha!" ”

1. Services as components

MicroServices can also be thought of as a component, but the difference with traditional components is that it can be deployed independently, so it has a significant advantage. Another advantage is that it defines a clear, language-independent, platform-independent canonical interface between components and components, with low coupling and very high flexibility. However, its disadvantage is that the distributed call relies heavily on the reliability and stability of the network.

2. Around the business organization team

In a single-block architecture, companies typically divide teams according to their skills, and in such an organization, even simple requirements changes may require cross-team collaboration and high communication costs. In the microservices architecture, it advocates business as the core, organizes the team according to the business ability, and the members of the team have a variety of skills.

3. Focus on the product, not the project

In a monolithic architecture, the application is basically built on a "project pattern" where the project starts with a team of resources drawn from different skill pools, releasing all resources at the end of the project. In this case, team members lack ownership and a sense of product accomplishment.

In the microservices architecture, the "product model" is advocated to build, that is more inclined to let the team responsible for the entire service life cycle, in order to provide better service.

4. Technology diversity

The MicroServices architecture advocates the choice of appropriate technical solutions for different business features, targeted solutions to specific business problems, rather than the use of a unified platform or technology in a single-block architecture to solve all problems.

5. Independent Business Data

MicroServices architectures provide the ability to manage their related business data autonomously, so that data interface integration can be provided as the business grows, rather than being integrated with other services in a database. In addition, with the development of the business, it is convenient to choose more tools to manage or migrate business data.

6. Infrastructure Automation

In the practice of the microservices architecture, the requirements for continuous delivery and deployment lines are high, which will facilitate the enterprise to continuously find more efficient ways to complete the automation of infrastructure and the improvement of DEVOPS capabilities.

After listening to Cheng can't help expressing admiration: "The old driver is the old driver, oh, wrong ..." Architect is the architect, summed up so concise and profound! ”

"Cough, low-key ..."

"Listening to you explain so much, I think the microservices architecture solves many of the pain points of the current three-tier architecture. But I don't think any technology or architecture is perfect. ”

"very correct. There are many challenges to the landing of a microservices architecture. "

1. Complexity of distributed systems

MicroServices architectures are distributed based systems, and building distributed systems inevitably entails additional overhead.

• Performance: Distributed systems are cross-process, cross-network calls that are affected by network latency and bandwidth.
• Reliability: Because of the high dependency on network conditions, any remote calls can fail at any one time, and more potential points of failure will occur as the service grows. Therefore, how to improve the reliability of the system and reduce the failure rate caused by the network is a great challenge to the system construction.
• Asynchronous: Asynchronous communication greatly increases the complexity of the implementation of the function, and is accompanied by the difficulty of locating and debugging.
• Data consistency: To ensure that the data consistency of the distributed system, the cost is very high, need to C (consistency) A (availability) P (partition fault tolerance) to make a trade-off between the three.

2. Operation and maintenance cost

Operations include configuration, deployment, monitoring and alarm and log collection four major aspects. In a microservices architecture, each service needs to configure, deploy, monitor, and collect logs independently, with an exponential increase in cost.

3. Automated Deployment

In a microservices architecture, each service is deployed independently, with short delivery cycles and high frequency, and manual deployment is no longer adaptable to rapid changes in the business. Therefore, how to effectively build an automated deployment system is another challenge facing microservices.

4. DevOps and Organizational structure

In the implementation of the MicroServices architecture, the roles of developers and operations have changed, and developers will assume responsibility for the lifecycle of the entire service, including deployment and monitoring, while OPS prefers a consultative role to consider how services are deployed at an early stage. Therefore, it is also a challenge to adjust the organizational structure and build a full-featured team on demand.

5. Inter-Service dependency testing

In a monolithic architecture, integration testing is typically used to verify that dependencies are normal. In the micro-service architecture, the number of services, each service is a separate business unit, the service is mainly through the interface to interact, how to ensure the normal dependence, testing is the main challenge.

6. Inter-Service dependency management

MicroServices architecture, the number of services, how to clearly and effectively show the dependencies between services is also a challenge.

"The landing of MicroServices needs to be thoroughly explored and perfected, not every scenario is suited to the use of a microservices architecture, and not every enterprise has the ability or energy to face these challenges." The last earnestness of Lao Wang said.

"Well, there are two sides to everything, and the best is the one!" By the Wang Go, you have given me a theoretical lesson, when to take me to practice? ”

"You have to digest what you said today, next time ..."

"Well, look forward to our next exchange ..."

"1" picture source and content mainly refer to "micro-service architecture and practice".

Cheng Learning micro-service architecture and basic article