Author: old _ source: www.cnblogs.com/imyalost/p/…
I. Introduction to microservice architecture
Microservice Architecture is an architectural concept that aims to decouple solutions by decomposing functionality into discrete services. You can think of it as being at the architectural level rather than getting services
A lot of SOLID principles apply to classes. Microservice architecture is an interesting concept. Its main role is to decompose functions into discrete services, thus reducing system coupling and providing more flexible service support.
Concept: Break up a large single application and service into several or even dozens of supporting microservices that extend individual components rather than the entire application stack to meet service level agreements (SLAs).
Definition: Create applications around business domain components that can be developed, managed, and iterated independently. Using cloud architecture and desktop deployment, management, and service capabilities in decentralized components makes product delivery easier.
Essence: To solve bigger, more practical problems with services that are more specific in function and business.
Emergence and development
The concept of Microservice appeared in 2012, as a way to speed up the development process of Web and mobile applications, began to attract 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 began to discuss and practice micro-services, which can be said to further promote the development and innovation of micro-services. Martin Fowler is responsible for the popularity of microservices.
The old man was a curious man, particularly adept at abstracting and inventing concepts. In particular, micro-services, a new term, have a characteristic: an explanation is easy to understand, ask, I do not know, a discussion will fight.
Martin Fowler is an internationally renowned OO expert, one of the founders of agile development methods and now chief scientist at ThoughtWorks, Inc. He is one of the world’s leading experts in object-oriented analysis and design, UML, patterns, software development methodology, XP, refactoring, and is currently chief Scientist at Thought Works. Thought Works is an enterprise application development and integration company. Fowler was an advocate of using object technology to build layered enterprise applications back in the 1980s, and is the author of several classic books: Enterprise Application Architecture Patterns, UML Essentials, and Refactoring. ———— Baidu Encyclopedia
Third, the difference between traditional development mode and microservices
Let’s take a look at traditional Web development and make it easier to understand what Microservice Architecture is by comparison. In contrast to microservices, this approach is often referred to as Monolithic development.
All functionality is packaged in a WAR package, with virtually no external dependencies (except for containers), deployed in a JEE container (Tomcat, JBoss, WebLogic) that contains all logic for DO/DAO, Service, UI, etc.
Advantages:
① Simple development and centralized management
② There will be no repeated development
③ Functions are local, no distributed management and call consumption
Disadvantages:
1. Low efficiency: the developers change the code in the same project, waiting for each other, and constantly conflict
2, maintenance is difficult: code functions are coupled together, new people do not know where to start
3. Inflexibility: The construction time is long, and any small modification will require the reconstruction of the whole project, which is time-consuming
4, poor stability: a small problem, can lead to the entire application hung
5. Insufficient expansibility: Unable to meet the business requirements 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 loss
3, cost reduction: reduce the cost of adding products, customers or business solutions
Design based on microservice architecture:
Objective: To effectively split applications and achieve agile development and deployment
A visual expression of micro services:
X-axis: Running instances after running multiple load balancers
Y-axis: Further decomposition of applications into microservices (sub-libraries)
Z-axis: When there is a large amount of data, partition the service (sub-table)
Iv. Specific features of micro-services
The official definition:
1. A series of independent services together constitute the system
2. Deploy alone and run your own process
3. Each service is developed as an independent business
4. Distributed management
5. Strong emphasis on isolation
General criteria:
1. System composed of distributed services
2. Organize by business, not technology
3. Make living products, not projects
Smart EndPoints and Dumb Pipes
5. Automated Operations (DevOps)
6, high fault tolerance
Fast evolution and iteration
The difference between SOA and microservices
SOA likes to reuse, microservices like to rewrite
The main purpose of SOA is to make it easier for enterprise systems to come together. When it comes to SOA, we have to say ESB(EnterpriseService Bus). What is an ESB? Think of the ESB as a scaffold that connects all enterprise-level services. Through service Broker, it can convert different data formats or models to canonical, convert XML input to CSV for Legacy services, convert SOAP 1.1 services to SOAP 1.2, and more. It can also route one service to another, centrally manage business logic, rules, validation, and so on. Another important feature is message queuing and event-driven messaging, such as converting JMS services to the SOAP protocol. There may be complex dependencies between services.
Microservices usually start by rewriting a module. Rewriting the entire megalithic application is risky and not necessarily necessary. When we move to microservices, we usually start with the least coupled modules or the most scalable modules, strip them off one by one and rewrite them nimbly, experimenting with the latest technologies and languages and frameworks, and then deploying them individually. It usually does not depend on other services. The API Gateway pattern commonly used in microservices is also not primarily aimed at reusing code, but rather at reducing the interaction between clients and services. The API Gateway pattern is not the same as the Facade pattern; we can use calls like the Future and even return incomplete data.
SOA likes horizontal services, microservices like vertical services
SOA designs like to layer services (such as the Service Layers pattern). We often see the design of an Entity service Layer, beautifully called the Data Access Layer. This design requires that all services fetch data through the Entity service layer. This design is very inflexible, for example, every change in the data layer can affect all business layer services. Each microservice usually has its own separate data store. We can do some denormalization when splitting the database so that it does not need to rely on data from other services.
Microservices are usually direct-to-user, and each microservice usually provides a function directly to the user. Similar features might be available for one service for mobile phones and another for set-top boxes. In an SOA design pattern, this is usually done using the multi-Channelendpoint model to return a large and comprehensive result that addresses all client needs.
SOA likes top-down, microservices like bottom-up
An SOA architecture begins with the definition of a service contract. It likes to centrally manage all services, including business logic, data, processes, schemas, and so on. It uses methods such as Enterprise Inventory and Service Composition to centrally manage services. SOA architectures typically define each module service interface up front. Communication between modular systems must comply with these interfaces, and services are directed to their callers.
SOA architectures apply to architectural methodologies such as TOGAF.
Microservices are much more agile. As long as the user is available, first dig out the service. Then targeted, quickly identify business requirements, rapid development iteration.
Vi. How to practice micro-services
To actually use microservices, there are four issues that need to be addressed:
1. How do clients access these services
2. How do each service communicate with each other
3, so many services, how to achieve?
4. The service is suspended. How to solve the problem? (Backup plan, emergency handling mechanism)
1. How do clients access these services
Monolithic development, where all services are native and the UI can be called directly, is now decoupled by function into separate services that run on separate Java processes that are generally run on separate virtual machines. How does the client UI access it?
There are N services in the background, and the front desk needs to remember to manage N services. If a service is offline/updated/upgraded, the front desk needs to be redeployed, which obviously does not serve our concept of separation. Especially when the front desk is a mobile application, the pace of business changes is usually faster.
In addition, the invocation of N small services is also a small network overhead. There are general micro services in the system, usually stateless, user login information and authority management is best to have a unified local maintenance management (OAuth).
Therefore, there is usually a proxy or API Gateway between the N services and the UI in the background. Its functions include:
① Provide unified service entrance, so that the micro service is transparent to the front desk
② Aggregate background services to save traffic and improve performance
Provide security, filtering, flow control and other API management functions
In fact, the API Gateway can be implemented in many broad ways, it can be a hardware and software box, it can be a simple MVC framework, or even a Node.js server. Their most important use is to provide aggregation of back-end services for foreground (usually mobile) applications, providing a unified service outlet and decoupling them, but API Gateways can also be single points of failure or performance bottlenecks.
If you have used the Taobao Open Platform, TAO is the API Gateway.
2. How do each service communicate with each other
All microservices are independent Java processes running on independent virtual machines, so the communication between services is inter Process Communication (IPC), and there are many mature solutions. There are two basic and most common ways:
Synchronous call:
①REST (JAX-RS, Spring Boot)
②RPC (Thrift, Dubbo)
Asynchronous message invocation (Kafka, Notify, MetaQ)
The difference between synchronous and asynchronous:
Generally, synchronous invocation is simple and consistent, but it is prone to invocation problems and poor performance experience, especially when there are many invocation layers. The comparison between RESTful and RPC is also an interesting topic.
General REST based on HTTP, easier to implement, easier to be accepted, the server side implementation technology is more flexible, each language can support, at the same time can cross the client, there is no special requirements for the client, as long as the PACKAGING OF THE HTTP SDK can be called, so the relative use of a wider number of. RPC also has its own advantages. The transmission protocol is more efficient and the security is more controllable. Especially in a company, if there is a unified development specification and a unified service framework, its development efficiency advantage is more obvious. See respective technical accumulation actual condition, his choice.
And asynchronous messaging way have special widely used in the distributed system, he can not only reduce the coupling between the call service, and can be invoked, the buffer between the backlog of messages will not be washed out by the caller, at the same time can guarantee the caller service experience, get on with their work, from the background slow performance. But the price to pay is the loss of consistency, the acceptance of final consistency of data; In addition, background services are generally idempotent because messages are sent repeatedly for performance reasons (ensuring that messages are received only once is a big performance test). Finally, it is necessary to introduce an independent broker. If there is no accumulation of technology within the company, the distributed management of brokers is also a great challenge.
3, so many services, how to achieve?
In microservices architecture, there are usually multiple copies of each service for load balancing. A service may go offline at any time, or new service nodes may be added in response to temporary access pressures. How do services feel about each other? How are services managed?
That’s the problem with service discovery. There are generally two kinds of approaches, each with its own advantages and disadvantages. Basically, the distributed management of service registration information is done through ZooKeeper and other similar technologies. When the service goes live, the service provider registers its service information with ZK (or similar framework) and maintains long links via heartbeat, updating the link information in real time. Service callers use ZK addressing to find a service based on customizable algorithms, and can cache service information locally to improve performance. ZK notifies the service client when the service goes offline.
Client side: advantages are simple architecture, flexible extension, only dependent on the service registry. The downside is that it is technically difficult for the client to maintain all the addresses that call the service, and large companies generally have mature internal frameworks such as Dubbo to support it.
Server-side do: advantages are simple, all services are transparent to the foreground callers, generally in small companies deployed in the cloud services of the application used more.
4. The service is suspended. How to solve the problem
As mentioned earlier, one of the great risks of Monolithic development is putting all your eggs in one basket. The biggest feature of distribution is that networks are unreliable. This risk can be mitigated by microservices unbundling, but without special safeguards, the outcome can be a nightmare. So when our system is made up of a chain of service invocations, we have to make sure that the failure of any one link does not affect the whole link. There are many corresponding means:
① Retry mechanism
(2) the current limit
③ Circuit breaker mechanism
④ Load Balancing
⑤ Degrade (local cache)
These methods are generally clear and generic, like Netflix’s Hystrix: github.com/Netflix/Hys…
7. Common design patterns and applications
There is a good diagram that summarizes the issues that microservices architecture needs to consider, including:
1, the API Gateway
2. Inter-service invocation
3. Service discovery
4. Service fault tolerance
5. Service deployment
6. Data invocation
There are six common microservices architecture design patterns:
1. Aggregator microservice design pattern
This is one of the most common and simplest design patterns:
The aggregator invokes multiple services to implement the functionality required by the application. It can be a simple Web page that processes and presents the retrieved data. It can also be a higher level composite microservice that adds business logic to the retrieved data and then further publishes it as a new microservice, in line with the DRY principle. 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. Aggregators can expand independently along the X and Z axes.
2. Agent micro-service design mode
This is a variation of the aggregation pattern, as shown below:
In this case, the client does not aggregate the data, but invokes different microservices based on different business requirements. An agent can simply delegate requests or perform data conversion work.
3. Chain microservice design mode
This pattern produces a combined response upon receipt of the request, as shown below:
In this case, service A communicates with service B upon receiving the request, and similarly, service B communicates with service C. All services use synchronous messaging. The client blocks until the entire chain call completes.
Therefore, the service invocation chain should not be too long to prevent the client from waiting for a long time.
4. Branch microservice design mode
This pattern is an extension of the aggregator pattern, allowing two microservice chains to be invoked simultaneously, as shown below:
5. Data sharing microservice design mode
Autonomy is one of the design principles of microservices, that is, microservices are full stack services. However, when refactoring an existing “monolithic Application”, SQL database de-normalization may result in data duplication and inconsistency.
Therefore, this design pattern can be used in the transition phase of singleton application to microservices 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 microservices-based applications.
6. Asynchronous messaging microservice design patterns
While the REST design pattern is very popular, it is synchronous and causes blocking. Therefore, some microservices-based architectures may choose to use message queues instead of REST requests/responses, as shown in the following figure:
Eight, advantages and disadvantages
1. Advantages of microservices:
Key points: controllable complexity, independent on-demand expansion, flexible technology selection, fault tolerance, high availability
① It solves complex problems. It breaks down a strange monolithic application into a set of services. While the total amount of functionality remains the same, the application is decomposed into manageable chunks or services. Each service defines a clear boundary in the form of RPC or message-driven apis; The Microservice architecture pattern achieves a level of modularity.
② This architecture enables each service to be developed independently by a dedicated team. 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 total anarchy and limit technology options. However, this freedom means that developers are no longer obligated to use technologies that may be outdated at the start of a new project. When writing a new service, they can choose to use the current technology. In addition, because the service is relatively small, it becomes feasible to rewrite the old service using the current technology.
③ The Microservice architecture mode enables each Microservice to be deployed independently. Developers do not need to coordinate the deployment of changes to local services. These changes can be deployed as soon as possible after testing. For example, the UI team can perform A | B test, and fast iterative UI changes. The Microservice architecture pattern enables continuous deployment.
④ The Microservice architecture mode enables each service to be adjusted independently. You can deploy only the number of instances per service that meet its capacity and availability limits. In addition, you can use the hardware that best fits the service resource requirements.
2. Disadvantages of microservices
Key points (challenges) : System deployment dependencies, inter-service communication costs, data consistency, system integration testing, rework, performance monitoring, etc
① One drawback is the name itself. The term microservice overemphasizes service size. But it is important to remember that this is a means, not the main end. The goal of microservices is to decompose applications sufficiently to facilitate agile application development and deployment.
② Another major disadvantage of microservers is the complexity of distributed systems. The developer needs to choose and implement an interprocess communication mechanism based on messaging or RPC. In addition, they have to write code to handle some failures because the destination of the request may be slow or unavailable.
③ Another challenge for microservers is the partitioned database architecture. It is quite common to update business transactions for multiple business entities. However, in a microserver-based application, you need to update multiple databases owned by different services. Using distributed transactions is generally not an option, and not just because of the CAP theorem. Many of today’s highly extensible NoSQL databases do not support them. You end up having to use the final consistency approach, which is more challenging for developers.
④ Testing microservices applications is also more complex. A test class similar to the service 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 so.
Another major challenge of the Microservice architecture pattern is implementing changes that span multiple services. For example, let’s say you are implementing A story that needs to change 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, then update service B, then repair A. Fortunately, most changes usually affect only one service, and there are relatively few multi-service changes that need to be coordinated.
⑥ Deploying microservices-based applications is also more complex. A single application is simply deployed on the same set of servers behind a traditional load balancer. Each application instance is configured with the location (host and port) of infrastructure services such as databases and message brokers. Microservice applications, by contrast, 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, extended, and monitored. In addition, you need to implement a service discovery mechanism that enables the service to discover the location (host and port) of any other services it needs to communicate with. Traditional trouble-sheet-based and manual methods cannot scale to this level of complexity. As a result, successful deployment of microservice applications requires greater developer control over deployment methods and a high level of automation.
Thinking: the transformation of consciousness
Micro services to our thinking, more is a change in thinking. For microservices architecture: technology is not a problem, awareness is more important than tools.
Some design considerations for microservices:
1. The core of the application is business logic, organizing resources according to business or customer needs (this is the hardest)
Do a living product, not a project
3, the first Wolf clan, full stack
Implement Single Responsibility Principle in backstage service
5, VM->Docker (to PE)
6. DevOps (to PE)
At the same time, for the development students, it is good to have so many middleware and strong PE support, we also need to deeply understand the principle behind these middleware, know why, how to implement microservices through open source technology with limited technical resources?
Finally, when it comes to microservices, DevOps and Docker are inseparable. It is understood that microservice architecture is the core, and DevOps and Docker are tools and means.
References:
- Kb.cnblogs.com/page/520922…
- www.infoq.com/cn/articles…
- www.csdn.net/article/201…
- Blog.csdn.net/mindfloatin…
- Blog.csdn.net/sunhuiliang…
- www.oschina.net/news/70121/…
Recent hot articles recommended:
1.1,000+ Java Interview Questions and Answers (2021)
2. I finally got the IntelliJ IDEA activation code thanks to the open source project. How sweet!
3. Ali Mock is officially open source, killing all Mock tools on the market!
4.Spring Cloud 2020.0.0 is officially released, a new and disruptive version!
5. “Java Development Manual (Songshan version)” the latest release, quick download!
Feel good, don’t forget to click on + forward oh!