Without further ado, let’s get straight to the point.
A single lightweight service is generally a separate microservice. Microservices focus on the implementation of a certain function. For example, the login system only focuses on user login. The realization of aspect functions emphasizes that has a single responsibility, can be used out of the box, and can run independently. The microservice architecture system is a distributed system that divides service unit modules according to business, solve the shortcomings of a single system, and meet increasingly complex business needs.
Martin Fowler: For now, there is no unified and standard definition for the microservices industry. But generally speaking, microservices architecture is an architectural pattern or architectural style that advocates dividing a single application into a set of small services. Each service runs in its own independent process. Services cooperate and coordinate with each other to provide users with ultimate value. Use lightweight communication between services. Each service is built around a specific business and can be independently deployed to production environments. In addition, a unified and centralized service management mechanism should be avoided as much as possible.
In layman’s terms:
Microservice is an independent service application with a single responsibility. In the intellij idea tool, there are independent modules developed using maven. Specifically, it is a small module developed using springboot to handle a single professional business logic. Each module only does one thing.
Microservices emphasize the size of the service, focusing on a certain point, specifically solving a certain problem/implementing a corresponding service application, which can be regarded as a module in idea.
For example, if you go to the hospital: your teeth feel uncomfortable, then you go to the dentist. If you have a headache, then you go to a brain department. Each department is a microservice, and each function is a service.
Synchronous communication: dobbo via RPC remote procedure call, springcloud via REST interface json call, etc. Asynchronous: message queue, such as: RabbitMq, ActiveM, Kafka, etc.
#First of all, they are all Distributed Management Framework.
dubbo is binary transmission, which will occupy less bandwidth. SpringCloud uses http transmission, and the bandwidth will be a little more. If you use the http protocol, you will generally use JSON messages, which will consume more.
Dubbo development is difficult, and the jar packages it relies on have many problemslarge projects cannot be solved. SpringCloud's inheritance of third parties can be generated with one click and is naturally integrated.
SpringCloud interface protocol agreement is relatively loose, strong administrative measures are needed to limit disorderly interface upgrade.
The biggest difference: Spring Cloud abandons Dubbo's RPC communication and adopts the REST method based on HTTP.
Strictly speaking, these two methods have their own advantages and disadvantages. Although to a certain extent, the latter sacrifices the performance of service calls, it also avoids the problems caused by native RPC mentioned above. Moreover, REST is more flexible than RPC. The service provider and the caller only rely on a paper contract, and there is no strong dependency at the code level. This is more appropriate in a microservice environment that emphasizes rapid evolution.
SpringBoot: Focus on quickly and conveniently developing a single individual microservice (focus on micro); SpringCloud: focus on global microservice coordination and governance A framework that combines and manages individual microservices developed by SpringBoot (focusing on the macro);
SpringBoot can be used independently from SpringCloud, but SpringCloud cannot leave SpringBoot and is a dependency.
The function of service fuse is similar to our household fuse. When a service becomes unavailable or the response times out, in order to prevent the entire system from avalanching, temporarily Stop calls to the service.
Service degradation is based on the load situation of the entire system and is considered. For some situations where the load will be relatively high, in order to prevent certain functions (business scenarios) from being overloaded In the case of overload or slow response, it temporarily abandons requests for some non-core interfaces and data internally, and directly returns a fallback error handling information prepared in advance. In this way, although a lossy service is provided, the stability and availability of the entire system are guaranteed.
Advantages: loose coupling, focusing on a single business function, independent of development language, reduced team size. During development, you don’t need to know much about the business, just focus on the current functions, which are convenient and centralized, and the functions are small and refined. If one function of a microservice is damaged, it will not have much impact on other functions, and the problem can be quickly located. Microservices only focus on the current business logic code and will not be mixed with html, css or other interfaces. It can be flexibly matched with technology, and it is more comfortable to be independent.
Disadvantages: As the number of services increases, management is complex, deployment is complex, server requirements increase, service communication and calling pressure increases, and operation and maintenance engineers increase pressure , increased human resources, enhanced system dependence, data consistency, and performance monitoring.
zookeeper is based on the CP principle, strong consistency and partition fault tolerance. eureka is the AP principle availability and partition tolerance. zookeeper When the master node fails, ZooKeeper will reselect the master node from the remaining nodes, which takes too long. Although it can eventually be restored, selecting the master node will cause the service to be unavailable, which is intolerable. All nodes in eureka are equal. If one node hangs up, other nodes will still ensure normal service.
Implementation technology | |
---|---|
SpringBoot, Spring, SpringMVC | |
Archaius from Netfix, Dlamond from Alibaba, etc. | |
Eurka, Consul, Zookeeper, etc. | |
Rest (service communication), RPC ( Dubbo), GRpc | |
Service circuit breaker | Hystrix, Envoy, etc. |
Load balancing | Nginx, Ribbon, etc. |
Service interface call (client simplified tool) | Fegin, etc. |
Message queue | Kafka, RabbitMQ, ActiveMQ, etc. |
Service Configuration Center Management | SpringCloudConfig, Chef, etc. |
Service Routing (API Gateway) | Zuul etc. |
Service Monitoring | Zabbix, Nagios, Metrics, Spectator, etc. |
Full link tracking | Zipkin, Brave, Dapper, etc. |
Service deployment | Docker, OpenStack, Kubernetes, etc. |
Data flow operation development package | SpringCloud Stream (encapsulated with Redis, Rabbit, kafka, etc. to send and receive messages) |
Event message Bus | Spring Cloud Bus |
If you understood what microservices are earlier, then you basically already understand the microservice architecture.
Microservice architecture is to manage, integrate and apply microservices. Microservice architecture relies on microservices and is based on microservices.
For example: What is a microservice has been listed above. In a hospital, each department is an independent microservice, so the hospital is a large-scale microservice architecture, just like the director can manage the following departments. Microservice architecture mainly has this function.
The above is the detailed content of How many of these 9 microservices interview questions can you answer?. For more information, please follow other related articles on the PHP Chinese website!