1. Introduction to Microservice Architecture
Microservice Architecture is an architectural concept aimed at decoupling a solution by decomposing functionality into discrete services. You can think of it as being at the architectural level rather than acquiring services
Apply many SOLID principles to classes. Microservice architecture is a very interesting concept. Its main function is to decompose functions 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 scale individual components rather than the entire application stack to meet service level agreements.
Definition: Create applications around business domain components that can be developed, managed, and iterated independently. Use cloud architecture and platform-style deployment, management, and service capabilities in disparate components to make product delivery easier.
Essence: Use some services with more clear functions and more refined business to solve larger and more practical problems.
2. Emergence and Development
The concept of microservice (Microservice) appeared in 2012. As a method to speed up the development process of web and mobile applications, it began to receive attention from all parties in 2014, 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 further promote the development and innovation of microservices. And the popularity of microservices is due to Martin Fowler.
This old man is a strange man, especially good at abstraction and concept creation. In particular, the new term microservices has a characteristic: you understand it when you explain it, don't know it when you ask it, and fight when you discuss it.
Martin Fowler is an internationally renowned OO expert, one of the founders of agile development methods, and is now the head of ThoughtWorks.
Scientist. In object-oriented analysis and design, UML, patterns, software development methodology, XP, refactoring, etc., are the world's top
Expert, now Chief Scientist at Thought Works. Thought Works is a company engaged in enterprise application development and--
established company. As early as the 1980s, Fowler was an advocate of building multi-tier enterprise applications using object technology, and he is the author of several
This classic book: "Enterprise Application Architecture Patterns", "UML Essence" and "Refactoring", etc.
---- Baidu Encyclopedia
3. The difference between traditional development mode and microservices
Let's first take a look at the traditional web development methods, and it is easier to understand what Microservice Architecture is through comparison. Corresponding to Microservice, this method is generally called Monolithic (single development).
All functions are packaged in a WAR package with basically no external dependencies (except the container), deployed in a JEE container (Tomcat, JBoss, WebLogic), including DO/DAO, Service, UI and other logic.
advantage:
① Simple development and centralized management
② Basically, there will be no repeated development
③ The functions are all local, there is no distributed management and call consumption
shortcoming:
1. Low efficiency: all developers are changing the code in the same project, waiting for each other, and conflicts continue
2. Difficult to maintain: Code functions and functions are coupled together, and newcomers do not know where to start
3. Inflexible: The construction time is long, and any small modification must refactor the entire project, which is time-consuming
4. Poor stability: a small problem may cause the entire application to hang up
5. Insufficient scalability: unable to meet business requirements under high concurrency
Common system architectures follow three standards and business drivers:
1. Improve agility: Respond to business needs in a timely manner and promote enterprise development
2. Improve user experience: Improve user experience and reduce user churn
3. Cost Reduction: Reduce the cost of adding products, customers or business programs
Design based on microservice architecture:
Purpose: Effectively split applications to achieve agile development and deployment
An image expression about microservices:
X-axis: running instances after running multiple load balancers
Y-axis: further decompose the application into microservices (sub-libraries)
Z-axis: When the amount of data is large, the service is partitioned (sub-table)
Fourth, the specific characteristics of microservices
Official definition:
1. A series of independent services form a system together
2. Deploy separately and run in its own process
3. Each service is developed for an independent business
4. Distributed management
5. Strong emphasis on isolation
Approximate standard:
1. A system composed of distributed services
2. Divide the organization by business, not technology
3. Make living products, not projects
4. Strong service individuals and weak communication (Smart endpoints and dumb pipes)
5. Automated operation and maintenance (DevOps)
6. Highly fault-tolerant
7. Rapid evolution and iteration
Five, the difference between SOA and microservices
1. SOA likes to reuse, microservice likes to rewrite
The main purpose of SOA is to make it easier to integrate the various systems of the enterprise. When it comes to SOA, we have to say ESB (EnterpriseService Bus). What is an ESB? Think of an ESB as a scaffolding that connects all enterprise-level services.
Through the service broker, it can convert different data formats or models into canonical formats, convert XML input into CSV and send them 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 and validation, etc. It also has an important function of message queuing and event-driven messaging, such as converting JMS services into the SOAP protocol. Each service may have
complex dependencies.
Microservices usually start by rewriting a module. Rewriting an entire monolithic application is risky and not necessarily necessary. When we migrate to microservices, we usually start with the modules with the least coupling or the modules with the highest scalability requirements.
Strip them out one by one and rewrite them in agile, you can try the latest technologies and languages and frameworks, and then deploy them individually. It usually does not depend on other services. The main purpose of the API Gateway pattern commonly used in microservices is not to reuse code.
Rather, it reduces the exchanges between the client and the service. API gateway mode is not equivalent to Facade mode, we can use calls such as future, and even return incomplete data.
2. SOA likes horizontal services, microservices like vertical services
SOA design likes to layer services (such as the Service Layers pattern). We often see the design of an Entity service layer, euphemistically 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 may affect the services of all business layers. And each microservice usually has its own independent data store. We can do something appropriately when splitting the database
Denormalization so that it does not need to rely on data from other services.
Microservices usually face users directly, and each microservice usually provides a certain function directly to users. Similar functionality might have one service for cell phones and another for set-top boxes. In SOA design patterns this situation is often used
The Multi-ChannelEndpoint mode returns a large and comprehensive result taking into account the needs of all clients.
3. SOA likes top-down, microservices like bottom-up
SOA architecture at the beginning of the design will first define the service contract (service contract). It likes to centrally manage all services, including centrally managing business logic, data, processes, schemas, etc. it uses Enterprise
Methods such as Inventory and Service Composition to centrally manage services. SOA architecture usually pre-defined each module service interface. Communication between module systems must adhere to these interfaces, and services are directed to their callers.
SOA architecture works with architecture methodologies like TOGAF.
Microservices are much more agile. As long as the user can use it, the service will be dug out first. Then, in a targeted manner, quickly identify business requirements and develop iteratively.
6. How to practice microservices concretely
To actually apply microservices, four problems need to be solved:
1. How clients access these services
2. How to communicate between each service
3. How to realize so many services?
4. The service is down, how to solve it? (backup plan, emergency handling mechanism)
1. How clients access these services
In the original Monolithic development, all services are local, and the UI can be called directly. Now, it is divided into independent services according to functions, and runs in independent Java processes that are generally on independent virtual machines. How does the client UI access his?
There are N services in the background, and the front desk needs to remember to manage N services. If a service goes offline/update/upgrade, the front desk needs to be redeployed. This obviously does not serve our concept of splitting, especially when the front desk is a mobile application. Often the pace of business change is faster.
In addition, the invocation of N small services is also a considerable network overhead. There are also general microservices inside the system, which are usually stateless. It is best to have a unified place for user login information and permission management (OAuth).
Therefore, there is generally a proxy or API Gateway between the N services in the background and the UI. Its functions include:
① Provide a unified service entrance to make microservices transparent to the front desk
② Aggregate background services to save traffic and improve performance
③ Provide API management functions such as security, filtering, and flow control
In fact, this API Gateway can have many broad implementation methods. It can be a box that integrates software and hardware, or a simple MVC framework, or even a Node.js server. Their most important role is for the front desk (usually
Mobile application) provides aggregation of background services, provides a unified service exit, and decouples them, but API Gateway may also become a single point of failure or a performance bottleneck.
Those who have used Taobao Open Platform (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 independent virtual machines, so the communication between services is IPC (inter process communication), and there are many mature solutions. There are basically two most common methods:
Synchronous call:
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
Asynchronous message calls (Kafka, Notify, MetaQ)
The difference between synchronous and asynchronous:
Generally, synchronous calls are relatively simple and have strong consistency, but they are prone to call problems, and the performance experience will be poor, especially when there are many call levels. The comparison of RESTful and RPC is also an interesting topic.
Generally, REST is based on HTTP, which is easier to implement and more acceptable. The server-side implementation technology is also more flexible. All languages can be supported. At the same time, it can be cross-client. There is no special requirement for the client.
The SDK can be called, so it is relatively widely used. RPC also has its own advantages, the transmission protocol is more efficient, the security is more 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 of their own technology accumulation and their own choices.
The asynchronous message method is widely used in distributed systems. It can not only reduce the coupling between calling services, but also serve as a buffer between calls to ensure that the message backlog will not overwhelm the callee, while ensuring that calls square
Service experience, continue to do what you need to do, and not be slowed down by background performance. However, the price to be paid is the weakening of consistency and the need to accept the eventual consistency of data; and the background service generally needs to achieve idempotency, because the message
Sending is generally repeated for performance reasons (ensure that the message is received and only received once is a great test for performance); finally, an independent broker must be introduced. If there is no technical accumulation within the company,
Distributed management of brokers is also a big challenge.
3. How to realize so many services?
In a microservice architecture, generally each service has multiple copies for load balancing. A service may go offline at any time, and new service nodes may be added in response to temporary access pressure. How do services perceive each other? How are services managed?
This is the problem with service discovery. There are generally two types of approaches, each with their own advantages and disadvantages. Basically, the distributed management of service registration information is done through zookeeper and other similar technologies. When the service goes online, the service provider sends its own service information
Register to ZK (or similar framework) and maintain long links through heartbeats, updating link information in real time. The service caller can find a service through ZK addressing, according to a customizable algorithm, and can also cache the service information locally to improve performance.
When the service goes offline, ZK will send a notification to the service client.
The client does it: 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 needs to maintain the addresses of all calling services, which is technically difficult. Generally, large companies have mature internal framework support, such as Dubbo.
Server-side: The advantage is that it is simple, and all services are transparent to the front-end caller. Generally, small companies deploy more applications on cloud services.
4. The service is down, how to solve it
As mentioned earlier, a big risk of Monolithic development is to put all the eggs in one basket, and one will prosper and one will lose. The biggest characteristic of distributed is that the network is unreliable. This risk can be reduced by splitting microservices,
But if there is no special guarantee, the ending will definitely be a nightmare. Therefore, when our system is composed of a series of service call chains, we must ensure that problems in any link will not affect the overall link. There are many corresponding means:
①Retry mechanism
②Current limiting
③Fusing mechanism
④ Load balancing
⑤ Downgrade (local cache)
These methods are basically clear and generic, such as Netflix's Hystrix: https://github.com/Netflix/Hystrix
Seven, common design patterns and applications
There is a diagram that nicely summarizes the issues to consider in a microservices architecture, including:
1、API Gateway
2. Call between services
3. Service discovery
4. Service fault tolerance
5. Service deployment
6. Data call
Six common microservice architecture design patterns:
1. Aggregator microservice design pattern
This is one of the most common and simplest design patterns:
Aggregators call 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 composite microservice that adds business logic to the retrieved data and further
Published as a new microservice, which complies with the DRY principle. Also, each service has its own cache and database. If the aggregator is a composite service, then it also has its own cache and database. Aggregators can scale 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 image:
In this case, the client does not aggregate data, but calls different microservices based on differences in business needs. The proxy can just delegate the request, or it can do the data transformation work.
3. Chained Microservice Design Pattern
This mode produces a merged response after a request is received, as shown in the following figure:
In this case, service A will communicate with service B after receiving the request, and similarly, service B will communicate with service C. All services use synchronous messaging. The client will block until the entire chain of calls is complete.
Therefore, the service call chain should not be too long to prevent the client from waiting for a long time.
4. Branch Microservice Design Pattern
This pattern is an extension of the aggregator pattern and allows two microservice chains to be invoked at the same time, as shown in the following diagram:
5. Data sharing microservice design pattern
Autonomy is one of the design principles of microservices, which means that 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 in the transition phase of monolithic application to microservice architecture, as shown in the following figure:
In this case, some microservices may 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 microservice-based applications.
6. Asynchronous Messaging Microservice Design Pattern
Although the REST design pattern is very popular, it is synchronous and can cause blocking. Therefore, some microservice-based architectures may choose to use message queues instead of REST requests/responses, as shown in the following figure:
8. Advantages and disadvantages
1. The advantages of microservices:
Key points: controllable complexity, independent on-demand expansion, flexible technology selection, fault tolerance, and high availability
①It solves the problem of complexity. It decomposes a weird monolithic application into a set of services. While the total amount of functionality remains the same, the application has been broken down into manageable chunks or services. Each service is supported by RPC or message-driven API
Form defines a clear boundary; the Microservice architectural pattern implements a level of modularity.
② This architecture enables each service to be independently developed by a team dedicated to that service. Developers are free to choose any useful technology as long as the service conforms to 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 exist at the start of a new project. When writing new services, they can choose to use current technology. Furthermore, due to the relatively small size of the service,
So it becomes feasible to rewrite old services using current technology.
③ 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, UI teams can perform A|B testing and iterate quickly
UI changes. The Microservice architectural pattern enables continuous deployment.
④The Microservice architecture pattern enables each service to be adjusted independently. You can deploy only the number of instances of each service that meet its capacity and availability constraints. Additionally, you can use the hardware that best matches your service resource requirements.
2. Disadvantages of Microservices
Key points (challenges): Difficulty in multi-service operation and maintenance, system deployment dependencies, inter-service communication costs, data consistency, system integration testing, duplication of work, performance monitoring, etc.
① One disadvantage is the name itself. The term microservice overemphasizes service scale. But it's important to remember that this is a means, not a primary goal. The goal of microservices is to decompose an application sufficiently to facilitate agile application development and deployment.
② Another major disadvantage of microservers is the complexity that arises from distributed systems. Developers need to choose and implement an inter-process communication mechanism based on message passing or RPC. Also, they have to write code to handle partial failures,
Because the requested destination may be slow or unavailable.
③ Another challenge of microservers is the partitioned database architecture. Business transactions that update multiple business entities are fairly common. 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 an eventual consistency approach, which is more challenging for developers.
④ Testing microservice applications is also more complex. A service-like test class would 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 this.
⑤ Another major challenge of the Microservice architectural pattern is to implement changes across multiple services. For example, let's say you are 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 appropriate modules, integrate the changes, and deploy them all in one go. In contrast, in the Microservice architectural pattern, you need to carefully plan and coordinate changes to each service. For example, you need to update service C, then update service B,
Then repair A. Fortunately, most changes usually only affect one service, and there are relatively few multi-service changes that need to be coordinated.
⑥ Deploying microservice-based applications is also more complex. A single application is simply deployed on a set of identical servers behind a traditional load balancer. Each application instance is configured with infrastructure services (such as databases and message brokers)
location (host and port). In contrast, microservice applications are usually composed 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. Also, you need to implement the service
A discovery mechanism that enables a service to discover the location (host and port) of any other service it needs to communicate with. Traditional ticket- and manual-action based approaches cannot scale to this level of complexity. Therefore, successfully deploying a microservice application requires
Developers have more control over deployment methods and achieve a high level of automation.
9. Thinking: A Shift in Consciousness
What microservices think about us is more of a change in thinking. For microservice architecture: technology is not a problem, awareness is more important than tools.
A few design starting points for microservices:
1. The core of the application is business logic, organizing resources according to business or customer needs (this is the hardest)
2. Make living products, not projects
3. Alpha Wolf, full stack
4. The background service implements the Single Responsibility Principle (single responsibility principle)
5、VM->Docker （to PE）
6 、 DevOps (to PE)
At the same time, for developers, it is a good thing to have so many middleware and strong PE support. We also need to deeply understand the principles behind these middlewares, know why they are, and how to use open source technology with limited technical resources. Implementing microservices?
Finally, it is generally mentioned that microservices are inseparable from DevOps and Docker. Understanding the microservice architecture is the core, and devops and docker are tools and means.
If you think you have something to gain, you can pay attention to the collection and forward it! You can also add java advanced architecture group: 725633148 will share some videos recorded by senior architects: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principles, JVM performance optimization, Distributed architecture, etc., have become a necessary knowledge system for architects. You can also receive free learning resources, which are currently benefiting a lot!