What are microservices
Microservices are small, autonomous services that work together. It has the following two features:
1. Small and focused on doing one thing well
In the era of monolithic applications, we wrote all the business modules in one system, and as new features were added, the system’s code base grew so large that it was difficult to know where to make changes. Although the system is divided into modules, the reality is that the boundaries of these modules can be difficult to maintain, and similar code can be found everywhere, making bug fixes or implementations more difficult.
Cohesion refers to bringing together things that change for the same reason and separating things that change for different reasons. Microservices apply this concept to standalone services, defining service boundaries according to business boundaries, making it easy to determine which service a particular function should be placed in. According to the business module split can be very good to avoid the system code base is too large and derived from the related problems.
Considerations regarding the granularity of service separation: The smaller the service, the more obvious are the advantages and disadvantages of a microservice architecture. The smaller the service, the greater the benefits of independence, but the greater the complexity of managing a large number of services.
2. The autonomy
Microservices are independent entities that can be deployed independently and communicate with each other through network calls. For a service, we need to think about what should be exposed and what should be hidden. If too much is exposed, the consumer of the service can be coupled to the internal implementation of the service, reducing the autonomy of the service.
Second, the benefits of micro services
1. Technical heterogeneity
We can choose among different services the appropriate technology implementation for that service.
2. The elastic
In a single system, if the server where the system is deployed is faulty or the CPU/ memory usage of a module is too high, the entire application becomes unavailable. Microservices don’t have this problem, and a problem with one service doesn’t affect the normal operation of other services.
3. The extension
Individual systems can only be extended as a whole. Even if only a small part of the system has performance problems, the entire service needs to be extended. If we use microservices, then we only need to scale for the services that need to be scaled, for example, we can deploy more nodes for the services with high access rates.
4. Simplify deployment
Even if only one line of code is modified in a single system, the entire system needs to be redeployed, which has a large impact and higher possibility of problems. Only corresponding services need to be deployed in microservices, and other services are not affected.
5. Fit the organizational structure
Each service is developed and maintained by a small team, avoiding a large code base and achieving the desired team size and productivity.
6. Optimization of substitutability
In a large monolithic system, there is a higher probability of problems if we have to modify/delete some code in it, whereas microservices have a smaller amount of code and are less risky if they need to be rewritten and replaced.
Third, challenges brought by micro-services
1. Deployment, operation and maintenance of microservices
How to deploy services more efficiently and ensure high availability of services.
2. Distributed complexity
Distributed transactions or CAP-related issues need to be handled.
3. Monitoring of micro-services
Including service availability monitoring, service invocation link monitoring.
The above content is arranged according to “Micro service Design”.
When is it not appropriate to use microservices architecture
Based on my own experience, THE following situations may not be suitable for microservices architecture.
1. Want to launch products quickly
If a company wants to launch a product quickly to validate the market, then it’s not necessarily the right time to adopt a microservices architecture. Because of the complexity of the service architecture itself brings, we should not only develop business needs, will also have to solve the problem of micro service architecture technology in all its aspects, and it is hard to solve some technology problems, such as a distributed transaction, thus inevitably stretched project cycle, lead to products cannot be delivered on time. However, if the development of a single architecture is adopted at this time, it is only necessary to focus on business requirements. When the product is successful and gradually developed, it is not too late to transition to a microservice architecture.
2. Weak technical foundation of team micro-service
If technical team members do not have a good foundation in microservices theory or practice, it is important for developers to: One of the problems that that can cause is that when they write code, they still think in terms of monolithic applications. For example, in the scenario of cross-service cross-library invocation, they don’t take distributed transactions into account at all, which can easily cause inconsistencies in business service data and lead to failures. For operations personnel, it can be a pain to deploy N services without the ability to automate deployment. Therefore, before adopting microservices architecture, make sure that team members already have a theoretical or practical foundation in microservices architecture.
3. The system scale is small
If the system scale is small, there may be no more than five business modules, which is also not suitable for the microservice architecture. Because complexity is an important consideration for microservices architectures, it may be more difficult to address the complexity of microservices architectures than to develop system requirements, which may seem like a loss than a gain.
4. You just want to experience microservices
Microservices are so hot right now that some technical teams might want to try them out and incorporate them into their projects. However, before this, we should first think clearly whether we can hold it, otherwise we will only go further and further on the road of pit mining. In fact, for the company, it does not care about the realization of specific technology, and the company leaders only care about the realization of business requirements. For our development, the main goal should also be to achieve business.
In general, due to the complexity of development, operation and maintenance brought by microservice architecture, it is recommended not to adopt microservice architecture if there are some problems mentioned above.
Five, the practice of micro services
The selection of microservice architecture technology includes Spring Cloud and Dubbo. The difference and comparison between the two are available on the Internet and will not be described here. Overall, Spring Cloud is a complete solution for microservices architecture.
Spring Cloud provides a number of components to support microservices, some of the basic components recommended include:
- Service registration discovery: Eureka
- Service Gateway: Zuul
- Service invocation: Feign
- Soft load Balancing: Ribbon
- Current limiting fuse: Hystrix
- Configuration Center: Apollo (Standby: Ctrip open source, recommended use)
- Log monitoring: ELK
- Service invocation link monitoring: The options are CAT, Zipkin, and SkyWalking
Although Spring Cloud provides a complete set of components, there are still some holes to tread in the actual practice.
Six, summarized
While we enjoy the benefits of micro-services, we also have to accept the challenges it brings. Whether we can implement micro-services should also be combined with the actual situation and proceed from reality.
Another important point is that it’s not easy but it’s important to develop specifications, improve the quality of the code, and not leave too much technical debt.
Give the article a “like” if it’s helpful to you. If there are any inaccuracies, please point them out. Article first public number: dancing robot, welcome to scan code attention.