-
架构演进过程
-
纯单机版架构
-
Maven依赖分层单机版架构
-
WebService服务调用分布式架构
- CXF框架/HttpClient
- RESTTemplate
- Dubbo+ZooKeeper
- 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
