1. Architecture Evolution

    1. Pure standalone architecture

    2. Maven relies on a layered standalone architecture

    3. WebService service calls distributed architecture

      1. The CXF framework/HttpClient
      2. RESTTemplate
      3. Dubbo+ZooKeeper
      4. Spring Boot+Spring Cloud

Ancient times: Single architecture: There is only one project for the entire project. When running on the Servlet container, there is only one WAR package.

Black Iron age: Remote survey based on WebService implementation method, and then realize distributed architecture

WebService is essentially the sum total of all the techniques that implement “method remote invocation”.

Method call form:

Local call: call a method of an object directly in the same project. userService.doLogin(user);

Two: remote call: call method through the network, call another project method.

Module A will call module B, originally A single architecture, between projects through the project JAR call, mutual dependence, aggregation, inheritance, belong to the local call; Over the network, we can make a request in Java code that calls object methods; In the Web phase we found that the client can access the browser, and now we find that the client can access it between projects through remote calls

Remote invocation of a method has both internal and external implications

Internally: help us implement distributed architecture

External: allows us to call third-party interfaces

texting

Check logistics

Look at the weather

pay

…

 

 

A distributed Architecture is implemented by remote method-based invocations within a project. The invoked method project is called the server, and the invoked method project is called the client.

Module A: client; module B: server

Module B provides services. Module B provides services by defining methods that can be invoked in an interface.

Benefits: Hide implementation details, ensure data security, capital security, business secret security; Interface oriented programming, only our interface is unchanged, no matter how the implementation class changes, the caller will not feel, can achieve decoupling, in line with the principle of “high cohesion, low coupling” in the process of project development.

Have you ever written interfaces?

Bronze Age: Dubbo+Zookeeper, which implements the overall distributed architecture of the project

Dubbo: Service governance framework based on Remote Procedure Call (RPC) in distributed architecture environment.

Zookeeper: A registry of services in the project. Each Provider module in the project registers the relevant information of its service to Zookeeper, and each consumer module invokes the Provider (provide) according to the information registered in Zookeeper.

Silver Age: SpringBoot+SpringCloud

SpringBoot: Development in the Spring environment is to help developers simplify configuration files, simplify third-party technical files.

server:
  port: 10002
spring:
  application:
    name: ManagerProvider
  datasource:
    name: druid-source
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: org.gjt.mm.mysql.Driver
    url: jdbc:mysql: / / 127.0.0.1:3306 /atcrowdfunding180725?rewriteBatchedStatements=true&useUnicode=true&characterEncoding=utf8
    username: root
    password: root
    dbcp2:
      min-idle: 5
      initial-size: 5
      max-total: 5
      max-wait-millis: 200
mybatis:
  mapper-locations:
  - classpath:mappers/*Mapper.xml eureka: client: service-url: defaultZone: http://localhost:10000/eurekaCopy the code

Introduce the Eureka service registry

                <dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
		@EnableEurekaClient
Copy the code

SpringCloud: Implementing microservices architecture. Provides a complete set of one-stop solutions.

Load balancing, registries, gateways, circuit breakers, service monitoring…

SpringCloud: Each module, each component is required to be a microservice project developed using SpringBoot, and not necessarily using SpirngCloud when using SpringBoot.

Service Mesh: Infrastructure layer for communication between services. Think of it as TCP/IP between applications or microservices, responsible for network calls, traffic limiting, fuses, and monitoring between services.

Distributed architecture benefits:

Good for division of labor: assigning a module directly to a team or programmer

Conducive to a very large project module structure: it is unacceptable to use the Package to divide components when we have too many modules. All dispersed into different projects.

High degree of modularization, clearer structure: conducive to development and maintenance.

Performance benefits: Each module can monopolize the hardware resources of a server.

Cluster deployment can be implemented for a module that is under heavy access pressure.

Cluster: Multiple servers running the same module

Cluster: Multiple servers running the same module

Distributed: Running different modules on multiple servers

Middleware:

Knowledge system:

 

 

Distributed transaction

concept

Ensure that the data stored in each module and middleware are consistent when modifying data in distributed architecture systems.

※ Note: There is no absolute way.

Scenario, for example,

 

When modifying commodity data, each component needs to be modified, but one of the operations may fail. A rollback mechanism is needed — however, such a mechanism is not natural.

You can write an inverse operation on the modify operation, but there’s a problem with that, the inverse operation can also fail.

Compensatory solutions

Simply put: Try again for a failed operation. Message queues are needed for the effect.

If the second attempt fails, the alarm system will be triggered while the log is written, and an SMS message will be sent to the OPERATION and maintenance personnel or developers to solve the problem as soon as possible. At the same time, if necessary, use the customer service department to carry out necessary coordination.

 

The CAP theorem

C: Strong consistency — keeping data consistent at a high intensity

A: High availability — available even with high concurrency

P: Partition fault tolerance – the whole system is still available when one of its components fails instead of crashing

P must be guaranteed. It’s A choice between C and A. Because to achieve strong consistency, data locks need to be added where necessary, which inevitably affects performance.

CP

AP