Recently, with the popularity of microservices (Microservice), microservice architecture has also been more and more mentioned, today for everyone to combine the collected information, the right as a comprehensive summary of a microservice architecture combing ~
The table of contents is as follows:
First, the introduction of microservice architecture
Second, emergence and development
Third, the difference between traditional development models and microservices
Fourth, the specific characteristics of microservices
Fifth, the difference between SOA and microservices
Sixth, how to practice microservices
7. Common microservice design patterns and applications
Eighth, the advantages and disadvantages of microservices
Thinking: The Transformation of Consciousness
First, the introduction of microservice architecture
Microservice architecture is an architectural concept designed to decouple a solution by decomposing functionality into discrete services. You can think of it as getting services at the architectural level rather than acquiring services
Many SOLID principles apply to the class. Microservices architecture is an interesting concept whose main role is to decompose functionality into discrete services, thereby reducing the coupling of the system and providing more flexible service support.
Concept: Splitting a large single application and service into several or even dozens of supporting microservices that extend a single component rather than the entire application stack to meet service-level agreements.
Definition: Create apps around business domain components that can be developed, managed, and iterated on their own. Use cloud architecture and platform-based deployment, management, and service capabilities in distributed components to make product delivery easier.
Essence: use some services with more clear functions and more concise business to solve larger and more practical problems.
Second, emergence and development
The concept of microservice emerged in 2012 as a way to speed up the development process of web and mobile applications, and 2014 began to attract attention from all sides, and 2015 can be said to be the first year of microservices;
More and more forums, communities, blogs and Internet industry giants have begun to discuss and practice microservices, which can be said to be a step closer to promoting the development and innovation of microservices. And the popularity of microservices, Martin Fowler is indispensable.
This old man is a strange man, especially good at abstract induction and manufacturing concepts. In particular, the nascent term of microservices has a characteristic: one explanation is understood, one question is not known, and one discussion is fought.
Third, the difference between traditional development models and microservices
Let’s take a look at the traditional way of web development, and it is easier to understand what Microservice Architecture is through comparison. Corresponding to Microservice, this approach is generally referred to as Monolithic (monolithic development).
All the functions are packaged in a WAR package, basically without external dependencies (except containers), deployed in a JEE container (Tomcat, JBoss, WebLogic), containing DO/DAO, Service, UI and all other logic.
Merit:
(1) Simple development and centralized management
(2) Basically no duplicate development
(3) The functions are local, and there is no distributed management and call consumption
Shortcoming:
1, low efficiency: development is in the same project to change the code, waiting for each other, conflicts constantly
2, maintenance is difficult: code work function coupled together, newcomers do not know where to start
3, inflexible: long build time, any small modification to reconstruct the entire project, time-consuming
4, poor stability: a small problem, can lead to the entire application hanging
5. Insufficient scalability: It cannot meet the business needs under high concurrency
Common system architectures follow three standards and business drivers:
1. Improve agility: timely respond to business needs and promote enterprise development
2. Improve user experience: improve user experience and reduce user churn
3, reduce costs: reduce the cost of increasing products, customers or business solutions
Design based on microservices architecture:
Purpose: Effectively split applications for agile development and deployment
An image of microservices:
X-axis: A running instance after running multiple load balancers
Y-axis: Further decompose the application into microservices (triage)
Z-axis: When the volume is large, the service is partitioned (table)
Fourth, the specific characteristics of microservices
Official definition:
1. A number of independent services together constitute a system
2. Deploy separately and run in your own process
3. Each service is developed for independent business
4. Distributed management
5. Great emphasis on isolation
Approximate criteria:
1. A system composed of distributed services
2. Divide the organization according to business, not technology
3, do living products rather than projects
4. Smart endpoints and dumb pipes
5. Automated O&M ( DevOps )
6. High fault tolerance
7. Rapid evolution and iteration
Fifth, the difference between SOA and microservices
1, SOA likes to reuse, microservices like to rewrite
The main purpose of SOA is to make it easier for enterprise systems to be integrated together. Speaking of SOA I have to say ESB (EnterpriseService Bus). What is an ESB? Think of an ESB as a scaffolding that connects all enterprise-class services.
Through the service broker, it can convert different data formats or models to canonical format, convert XML input to CSV to legacy services, convert SOAP 1.1 services to SOAP 1.2, and so on. It can also put a service
Routing to another service can also centrally manage business logic, rules, validation, and more. Another important feature is message queuing and event-driven messaging, such as converting JMS services into the SOAP protocol. Each service room may be available
Complex dependencies.
Microservices typically start by rewriting a module. There is a great risk and not necessarily a need to rewrite the application of the entire megalithic type. When we migrate to microservices, we usually start with the modules with the least coupling or the modules with the most scalability requirements.
Strip them off one by one and rewrite them with agility, you can try the latest technologies and languages and frameworks, and then deploy them separately. It usually does not rely on other services. The main purpose of the API Gateway pattern commonly used in microservices is also not to reuse code.
Instead, it reduces the traffic between clients and services. The API gateway pattern is not the same as the Facade pattern, and we can use calls like future and even return incomplete data.
2, SOA likes horizontal service, microservices like vertical service
SOA design prefers to tie services (such as the Service Layers pattern). We often see the design of an Entity service layer, called the Data Access Layer. This design requires all services to pass through this Entity service layer
to get the data. This design is very inflexible, for example, every change in the data layer can affect the services of all business layers. And each microservice usually has its own separate data store. We can do something appropriate when splitting the database
Denormalization, so that it does not need to rely on data from other services.
Microservices are typically directly user-to-user, and each microservice typically provides a feature directly to the user. A similar feature may have one service for mobile phones and another for set-top boxes. This is often the case in SOA design patterns
The Multi-ChannelEndpoint pattern returns a large and complete result that takes into account the needs of all clients.
3) SOA likes to be top-down, and microservices like bottom-up
The SOA architecture begins with a service contract defined at the beginning of the design. It prefers to centrally manage all services, including centralized management of business logic, data, processes, schemas, and so on. It uses Enterprise
Methods such as Inventory and Service Composition centrally manage services. SOA architectures typically predefine each module’s service interface. Communication between module systems must adhere to these interfaces, and each service is directed at its caller.
SOA architectures apply to architectural methodologies such as TOGAF.
Microservices are much more agile. As long as the user can use it, dig out the service first. Then targeted, quickly identify business requirements, and quickly develop iterations.
Sixth, how to practice microservices
To actually apply microservices, you need to solve the following four problems:
1. How the client accesses these services
2. How to communicate between each service
3, so many services, how to achieve?
4. The service is hanged, how to solve it? (Backup plan, emergency handling mechanism)
1. How the client accesses these services
The original Monolithic way of development, all services are local, UI can be directly called, now by function split into independent services, running in a separate Java process that is generally on a separate virtual machine. How does the client UI access him?
There are N services in the background, the front desk needs to remember to manage N services, a service offline / update / upgrade, the front desk will be redeployed, which obviously does not serve our concept of splitting, especially when the front desk is a mobile application, usually the pace of business changes is faster.
In addition, the invocation of N small services is also a considerable network overhead. There are general microservices inside the system, usually stateless, user login information and rights management is best to have a unified place maintenance management (OAuth).
Therefore, in general, there will be a proxy or API Gateway between the N services and the UI in the background, and his role includes:
(1) Provide a unified service entrance to make microservices transparent to the front desk
(2) Aggregate background services to save traffic and improve performance
(3) Provide API management functions such as security, filtering, and flow control
In fact, this API Gateway can have many generalized implementations, it can be a soft and hard box, it can be a simple MVC framework, or even a Node.js server. Their most important function is for the foreground (usually
Mobile apps) provide aggregation of back-office services, providing a unified service outlet, uncoupling them, but API Gateway can also be a single point of failure or performance bottleneck.
Those who have used Taobao Open Platform can easily understand that TAO is this API Gateway.
2. How to communicate between each service
All microservices are independent Java processes running on separate virtual machines, so interprocess communication is IPC (inter process communication), and there are many mature solutions. There are now two basic and most common ways:
Synchronous calls:
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
Asynchronous message call (Kafka, Notify, MetaQ)
The difference between synchronous and asynchronous:
Generally, synchronous calls are relatively simple and consistent, but they are prone to call problems, and the performance experience will be worse, especially when there are many levels of calls. The comparison of RESTful and RPC is also an interesting topic.
General REST is based on HTTP, easier to implement, easier to accept, server-side implementation technology is more flexible, each language can be supported, while cross-client, there is no special requirements for the client, as long as the HTTP is encapsulated
The SDK can be called, so it is relatively widely used. RPC also has its own advantages, the transport protocol is more efficient, more secure and controllable, especially within a company, if there is a unified development specification and a unified service framework,
His development efficiency advantage is more obvious. It depends on the actual conditions for the accumulation of their respective technologies and their own choices.
The asynchronous message method has a particularly wide range of applications in distributed systems, which can not only reduce the coupling between calling services, but also become a buffer between calls, ensuring that the message backlog will not collapse the callee, and at the same time ensuring the caller’s
Service experience, continue to do their own work, will not be slowed down by background performance. However, the price to be paid is the weakening of consistency, the need to accept the eventual consistency of the data; There is also the fact that background services generally want to achieve idempotency because of messages
Sending is generally repeated for performance reasons (ensuring that messages are received and received only once is a great test of performance); Finally, it is necessary to introduce an independent broker, if there is no accumulation of technology within the company,
It is also a big challenge for broker distributed management.
3, so many services, how to achieve?
In a microservices architecture, each service generally has multiple copies to do load balancing. A service may go offline at any time, and may also add new service nodes in response to temporary access pressure. How do services perceive each other? How are services managed?
That’s the problem the service found. There are generally two types of practices, each with its own advantages and disadvantages. Basically, distributed management of service registration information is done through zookeeper and other similar technologies. When a service goes live, the service provider will bring its own service information
Register to ZK (or similar framework) and maintain long links with a heartbeat, updating link information in real time. Service callers find a service based on customizable algorithms through ZK addressing, and can also cache service information locally to improve performance.
When the service goes offline, ZK will notify the service client.
Client does: The advantage is that the architecture is simple, the extension is flexible, and it only depends on the service registrar. The disadvantage is that the client has to maintain the address of all the calling services, which is technically difficult, and generally large companies have mature internal framework support, such as Dubbo.
The advantage of the server is simple, all services are transparent to the foreground caller, and generally the applications deployed on the cloud service by small companies are more.
4, the service is hanged, how to solve
As mentioned earlier, one of the big risks of Monolithic approach development is to put all your eggs in one basket and lose both. The biggest feature of distributed is that the network is unreliable. Splitting up microservices can reduce this risk.
But without special guarantees, the outcome is a nightmare. So when our system is made up of a chain of service calls, we have to make sure that any problem at any one link does not affect the overall link. There are many corresponding means:
(1) Retry mechanism
(2) Flow restriction
(3) Fusing mechanism
(4) Server load balancing
(5) Downgrade (local cache)
These methods are basically clear and universal, such as Netflix’s Hystrix:https://github.com/Netflix/Hystrix
7. Common design patterns and applications
There is a diagram that summarizes the issues that microservices architecture needs to consider very well, including:
1、API Gateway
2. Invocation between services
3. Service discovery
4. Service fault tolerance
5. Service deployment
6. Data call
Six common microservices architecture design patterns:
1. Aggregator microservice design pattern
This is one of the most common and simple design patterns:
The aggregator calls multiple services to implement the functionality required by the application. It can be a simple web page that processes and displays the retrieved data. It can also be a higher-level combined microservice that adds business logic further to the retrieved data
Released as a new microservice, which is in line with DRY principles. In addition, each service has its own cache and database. If the aggregator is a composite service, it also has its own cache and database. The aggregator can expand independently along the X and Z axes.
2. Proxy microservice design pattern
This is a variant of the aggregation pattern, as shown in the following figure:
In this case, the client does not aggregate the data, but calls different microservices based on different business needs. The agent can delegate only the request or perform data transformation work.
3. Chain microservice design mode
This pattern results in a merged response after receiving the request, as shown in the following figure:
In this case, Service A will communicate with Service B after receiving the request, similarly, Service B will communicate with Service C. All services use synchronous messaging. The client blocks until the entire chain call completes.
Therefore, the service call chain should not be too long to avoid long waits for the client.
4. Branch microservice design mode
This pattern is an extension of the aggregator pattern that allows two microservice chains to be invoked at the same time, as shown in the following figure:
5. Data sharing microservice design mode
Autonomy is one of the design principles of microservices, that is, microservices are full-stack services. But when refactoring an existing “monolithic application,” SQL database denormalization can lead to data duplication and inconsistency.
Therefore, this design pattern can be used during the transition phase of a monolithic application to a microservices architecture, as shown in the following figure:
In this case, some microservices might share cache and database storage. However, this is only possible if there is a strong coupling between the two services. This is an anti-pattern for new, microservices-based applications.
6. Asynchronous messaging microservice design pattern
While the REST design pattern is very popular, it is synchronous and can cause congestion. Therefore, some microservices-based architectures may choose to use message queues instead of REST requests/responses, as shown in the following figure:
Advantages and disadvantages
1. Advantages of microservices:
Key points: controllable complexity, independent on-demand expansion, flexible technology selection, fault tolerance, high availability
(1) It solves the problem of complexity. It breaks down a weird overall application into a set of services. Although the total number of features remains the same, the application is broken down into manageable blocks or services. Each service is based on RPC or message-driven APIs
Form defines a clear boundary; The Microservice architecture pattern achieves a level of modularity.
(2) This architecture enables each service to be independently developed by a team focused on that service. Developers are free to choose any useful technology, as long as the service complies with the API contract. Of course, most organizations want to avoid complete anarchy and
Limit technology choices. However, this freedom means that developers are no longer obligated to use potentially obsolete technologies that existed at the start of a new project. When writing new services, they can choose to use the current technology. In addition, since the service is relatively small,
It is therefore feasible to overwrite the old service using current technology.
(3) The Microservice architecture pattern enables each microservice to be deployed independently. Developers do not need to coordinate changes to deploy local services. These changes can be deployed as soon as possible after testing. For example, a UI team can perform A | B test and iterate quickly
UI changes. The Microservice architecture pattern enables continuous deployment.
(4) The Microservice architecture model enables each service to be adjusted independently. You can deploy only the number of instances of each service that meet its capacity and availability limits. In addition, you can use the hardware that best meets the requirements of the service resources.
2. Disadvantages of microservices
Key points (challenges): multi-service O&M difficulty, system deployment dependency, inter-service communication costs, data consistency, system integration testing, repetitive work, performance monitoring, etc
(1) One disadvantage is the name itself. The term microservice overemphasizes service size. But it’s important to remember that this is a means, not a primary goal. The goal of microservices is to fully decompose applications for agile application development and deployment.
(2) Another major drawback of microservers is the complexity created by distributed systems. Developers need to select and implement interprocess communication mechanisms based on messaging or RPC. In addition, they must write code to handle some failures,
Because the destination of the request may be slow or unavailable.
(3) Another challenge with microservers is the partitioned database architecture. It is fairly common to update business transactions across multiple business entities. However, in a microserver-based application, you need to update multiple databases owned by different services. Use distributed transactions
Usually not an option, and not just because of the CAP theorem. Many of today’s highly scalable NoSQL databases do not support them. You end up having to use the ultimate consistency approach, which is more challenging for developers.
(4) Testing microservices applications is also more complex. A service-like test class will need to start the service and any services it depends on (or at least configure stubs for those services). Again, it’s important not to underestimate the complexity of doing so.
(5) Another major challenge with the Microservice architecture pattern is implementing changes that span multiple services. For example, let’s say you’re implementing a story that requires changes to services A, B, and C, where A depends on B and B depends on C. In a monolithic application,
You can simply change the corresponding modules, consolidate the changes, and deploy them all at once. In contrast, in the Microservice architecture pattern, you need to carefully plan and coordinate changes to each service. For example, you need to update Service C, and then update Service B,
Fortunately, most changes usually affect only one service, and there are relatively few multi-service changes that need to be coordinated.
(6) Deploying microservices-based applications is also more complex. A single application is simply deployed on the same set of servers behind a classic load balancer. Each application instance is configured with infrastructure services such as databases and message brokers
Location (host and port). In contrast, microservices applications typically consist of a large number of services. For example, each service will have multiple runtime instances. More moving parts need to be configured, deployed, scaled and monitored. In addition, you need to implement the service
A discovery mechanism that enables a service to discover the location (host and port) of any other services it needs to communicate with. Traditional ticket-based and manual approach cannot scale to this level of complexity. Therefore, successful deployment of microservices applications is required
Developers have more control over deployment methods and achieve a high level of automation.
Thinking: The Transformation of Consciousness
Microservices think more about our thinking. For microservices architectures: technically not a problem, awareness is more important than tools.
A few design starting points for microservices:
1, the core of the application is the business logic, according to the business or customer needs of the organization of resources (this is the most difficult)
2, do living products, not projects
3. Head Wolf Team, full stack
4. Background service implements Single Responsibility Principle
5、VM->Docker （to PE）
6、DevOps (to PE)
At the same time, for development students, it is good to have so much middleware and strong PE support, we also need to deeply understand the principles behind these middleware, know why they are so, how to implement microservices through open source technology in limited technical resources?
Finally, it is generally mentioned that microservices are inseparable from DevOps and Docker, understanding that microservices architecture is the core, and devops and docker are tools and means.
I hope today’s explanation is helpful to everyone, thank you!
Thanks for reading!
Pay attention to the public account and receive learning materials for free
If you think it’s not bad, welcome to follow and forward ~