架构：第一章：项目架构的演变历史

1. 架构演进过程
   1. 纯单机版架构
   2. Maven依赖分层单机版架构
   3. WebService服务调用分布式架构
      1. CXF框架/HttpClient
      2. RESTTemplate
      3. Dubbo+ZooKeeper
      4. Spring Boot+Spring Cloud

远古时代：单一架构：整个项目只有一个工程。在Servlet容器上运行的时候，只有一个war包。

黑铁时代：基于WebService实现方法的远程调研，进而实现分布式架构

WebService本质就是实现所有“方法远程调用”技术的总和。

方法调用形式：

一：本地调用：在同一个工程里面直接调用某个对象的某个对象的某个方法。userService.doLogin(user);

二：远程调用：调用方法时要经过网络，调用另一个工程的方法。

模块A要调用模块B，原来单一架构，工程之间通过工程jar调用，相互之间依赖，聚合，继承，属于本地调用；而我们通过网络，可以在java代码中发起一个请求，调用对象方法；原来web阶段我们发现客户端可以访问浏览器了，而现在通过远程调用发现客户端项目之间也可以访问

方法的远程调用内外两方面意义

对内：帮我们实现分布式架构

对外：让我们能够调用第三方接口

发短信

查物流

看天气

支付

……

 

SOA：Service Oriented Architecture面向服务的架构，在项目的内部基于方法的远程调用实现分布式架构，被调用的方法工程称为服务端，调用用的方法工程称为客户端。

模块A：客户端，模块B：服务端

模块B提供了服务。模块B提供服务是通过在一个接口中定义可以被调用的方法提供服务。

好处：隐藏实现细节，保证数据安全，资金安全，商业秘密安全；面向接口编程，只有我们接口不变，不管实现类如何变化，调用方都感觉不到，能够实现解耦合，符合项目开发过程中的“高内聚，低耦合”原则。

你写过接口吗？

青铜时代：Dubbo+Zookeeper，实现项目总体的分布式架构

Dubbo:基于RPC(Remote Procedure Call远程过程调用)的分布式架构环境下服务治理框架。

Zookeeper:项目中服务的注册中心。项目中的各个provider模块将自己开发的服务的相关信息注册到Zookeeper，各个consumer（消费）模块根据Zookeeper中注册的信息调用provider（提供）.

白银时代：SpringBoot+SpringCloud

SpringBoot：在进行Spring环境下开发是帮开发者简化配置文件，简化第三方的技术文件。

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/eureka

引入Eureka服务注册中心

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

SpringCloud:实现微服务架构。提供了一整套一站式解决方案。

负载均衡，注册中心，网关，熔断机制，服务监控。。。。

SpringCloud:要求每个模块，每个组件都是使用SpringBoot开发的微服务工程，而使用SpringBoot时，不一定使用SpirngCloud.

Service Mesh服务网格：服务间通信的基础设施层。将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。

分布式架构的好处：

有利于分工：直接把一个模块分配给某个小组或某个程序员

有利于实现非常庞大的项目模块结构：当我们的各个模块太多时使用package划分组件无法接受。所有分散到不同工程里。

模块化程度高，结构更清晰：有利于开发维护。

有利于提升性能：每个模块可以独占一个服务器的硬件资源。

针对某个访问压力大的模块可以进行集群化部署。

集群：多台服务器上运行相同模块

集群：多台服务器上运行相同模块

分布式：多台服务器上运行不同模块

中间件：

知识体系：

分布式事务

概念

保证分布式架构系统中，修改数据时，让各个模块和各个中间件中存储的数据保持一致。

※注意：没办法做到绝对。

情景举例

 

在修改商品数据时，各个组件都需要修改，但是其中某一个操作可能失败。此时需要回滚机制——但是，这样的机制并不是天然存在的。

可以在修改操作的那写个逆操作，但这样有个问题，逆操作也有可能失败。

补偿性解决方案

简单来说：失败的操作再试一次。需要借助消息队列实现效果。

如果第二次尝试操作又失败了，那么写入日志的同时触发报警系统，立即给运维人员或开发人员发短信，尽快解决。同时如果有必要借助客服部门人工进行必要协调。

 

CAP定理

C：强一致性——在很高强度下保持数据一致

A：高可用性——在并发量很高情况下依然可用

P：分区容错性——整个系统中某个组件故障时整个系统仍然可用而不是崩溃

P必须保证。C和A之间二选一。因为要做到强一致性，需要在必要的地方加数据锁，必然会影响性能。

CP

AP