Introduction to microservices single architecture
Disadvantages: 1. High complexity
Take a single application of millions of lines as an example, the whole project contains a lot of modules, with fuzzy boundaries, unclear dependencies, uneven code quality and chaotic stacking together… The whole project is very complicated. Every time you make a change to the code, even adding a simple feature or fixing a BUG can lead to hidden bugs.
2. Technical debt
Over time, requirements change, and people change, an application’s technical debt builds up and builds up. This idea of “Not broken,don’t fix” is common in software development, and even more so in individual applications. The used system design or code is difficult to modify because other modules of the application may use it in unexpected ways.
3. The deployment frequency is low
As the code increases, so does the build and deployment time. In a single application, every functional change or bug fix causes the entire application to be redeployed. Full deployment takes a long time, has a large impact, and has high risks. As a result, single application projects are seldom deployed online. The low frequency of deployment leads to a large number of feature changes and bug fixes between releases, with a high probability of errors.
4. Limited ability to expand
Individual applications can only be expanded as a whole, but cannot be scaled based on the characteristics of service modules. For example, some modules in your application are computationally intensive and require a powerful CPU; Some modules are IO intensive and require more memory. Because these modules were deployed together, we had to compromise on our hardware choices.
5. Block technology creation
Individual applications often use a common technology platform or solution to solve all problems. Everyone on the team must use the same development language and framework, and it can be very difficult to introduce a new framework or technology platform. For example, a single application with 1 million lines of code built using Struts2, if you want to switch to Spring MVC, the switching cost is very high.
Architecture evolution single architecture
SOA (Distributed, Service-oriented Architecture)
Micro service
Micro service architecture www.martinfowler.com/articles/mi… In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
In short, the microservices architecture style is an approach to developing a single application system by developing a set of small services. Each of these small services runs in its own process and often uses lightweight mechanisms such as HTTP resource apis to communicate with each other. These services are built around business functions and can be deployed independently through a fully automated deployment mechanism. These microservices can be written in different languages and can use different data storage technologies. We have minimal centralized management of these microservices.
Microservice features: 1. Each microservice can run in its own process independently.
2. A series of independent microservices jointly construct the whole system;
3. Each service is independent business development, and a micro-service only focuses on a specific function, such as order management, user management, etc.;
4. Microservices communicate with each other through some lightweight communication mechanisms, such as calling through REST APIS;
5. Different languages and data storage technologies can be used;
6. Automatic deployment mechanism.
A microservice focuses on a specific business function, so it has clear business and less code. Developing and maintaining individual microservices is relatively simple. The entire application is built from several microservices, so the entire application is kept in a controlled state.
2. A single microservice starts quickly
A single microservice has less code, so it’s faster to get started.
3. Partial modification is easy to deploy
Microservices solve the problem of redeploying the entire application whenever a single application is modified. Typically, to make changes to a microservice, you simply need to redeploy the service.
4. Technology stack is not limited
In microservices, we can combine the characteristics of the project business and the team to choose a reasonable technology stack. For example, some services can use the relational database MySQL; We can use Neo4J for some microservices that require graphical computation. Some microservices can even be developed using JAVA and some using NodeJS, depending on your needs.
5. Scale on demand
Fine-grained expansion can be achieved according to requirements. For example, if a microservice in the system encounters a bottleneck, we can add memory, upgrade CPU, or add nodes based on the service characteristics of the microservice.
6.DevOps
Challenges of microservice architecture: 1. High o&M requirements
More services means more operations. In a single architecture, only one application needs to run properly. However, in microservices, it is necessary to ensure the normal operation and cooperation of dozens or even hundreds of services, so the operation and maintenance of this project brings great challenges.
2. Inherent complexity of distribution
You build distributed systems with microservices. For a distributed system, system fault tolerance, network latency, distributed transactions and so on all bring us great challenges
3. Interface challenge costs are high
Microservices communicate through interfaces. If you change the API of a microservice, you may need to change all microservices that use that interface.
4. Rework
Many services may use the same functionality, but this functionality is not decomposed into a microservice, at which point the services may develop this functionality, resulting in code duplication.
Microservice design principle single responsibility
Ref:en.wikipedia.org/wiki/SOLID_…
The service of autonomy
Each microservice should have independent business capabilities and be dependent on the operating environment
Lightweight communication
Interface clear
The external interface of each service should be clearly defined and kept as constant as possible.
Micro service development framework introduction to Spring Cloud: projects. Spring. IO/Spring – clou…
Dubbo: Dubbo. IO
Dropwizard: www.dropwizard.io
Consl, etcd & etc.
Spring Cloud synopsis introduction projects. Spring. IO/Spring – clou…
A tool set for quickly building distributed systems
Versioning services register and discover microservices that create call relationships
Use Eureka for service registration and discovery
Github.com/netflix/eur…
Coding client load balancing Ribbon
Github.com/netflix/rib…
Declarative Http Client Feign If the constructed URL is: www.baidu.com/s?ie=utf-8&… How to do?
Github.com/OpenFeign/f…
Microservices fault tolerance avalanche effect
Just think about it, if there is no circuit breaker in the home, the current is overloaded (such as too much power, short circuit, etc.), the circuit is constantly open, the circuit will heat up, or even burn the circuit, fire. With a circuit breaker, when the current is overloaded, it will automatically cut the circuit (trip), thus protecting the entire circuit and the home. When the current overload problem is solved, just turn off the breaker and the circuit can work again. Similarly, when a dependent service has a lot of timeouts, it doesn’t make much sense for new requests to access it, and it just consumes existing resources unnecessarily. For example, we set a timeout of one second, and if there are a large number of requests in a short time (say 50) that are not responded to within one second, it is usually an exception. There is no need for more requests to access the dependency, and we should use circuit breakers to avoid wasting resources. Circuit breaker can realize rapid failure, if it is in a period of time to detect many similar errors (such as timeout), will force the multiple calls later fail fast, no longer request depends on service, so as to prevent the application when trying to implement operations may fail, so the application can continue and don’t have to wait for correct mistakes, Or waste CPU time waiting for long timeouts. A circuit breaker also enables an application to diagnose whether the error has been fixed, and if so, the application will try to invoke the operation again. Circuit breaker mode acts as a proxy for error-prone operations. This proxy can record the number of times an error occurred in the most recent call, and then decide to use either allow the operation to continue or return an error immediately. The logic of switching between circuit breakers is shown as follows:
Blog. Daocloud. IO/microservic…
Zuul API Gateway github.com/netflix/zuu…
Yml /{label}/{Application}-{profile}.yml /{application}-{profile}.properties /{label}/{application}-{profile}.properties
Refresh /refresh /bus/refresh ===> AMQP
The final architecture
Spring Cloud features convention over Configuration Out-of-the-box, quick start suitable for a variety of environments PC Server Cloud Environment Container (Docker) lightweight component services found Euraka component support is rich, JAVA Scala/Groovy build tool Maven Gradle(How to convert a Maven project into a Gradle project?) Maven-gradle gradle init — type POM) Spring Boot Concept of service provider and Service consumer Service provider: the called party of a service (that is, a service that provides services for other services)
Service caller: The caller of a service (that is, a service that depends on other services)
User – purchase ticket – > Movie micro service – Query user information – > User micro service
Write a service provider
Service discovery
Service registration service registration is well understood, is when the service is started, the network address of the service is registered in the service registry;
The Health Check Service discovery component periodically detects registered services through some mechanism and removes a service from the service registry if it is found to be inaccessible (perhaps after a few heartbeat cycles).
Service discovery mode Client discovery Eureka ZK server discovery Consul+nginx Service registry, service discovery, registry, in many scenarios can be understood as a service discovery component.
Wechat scan code to get a full set of Java information oh ~
