- 架构演进过程
- 纯单机版架构
- 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环境下开发是帮开发者简化配置文件,简化第三方的技术文件。
代码语言:javascript复制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服务注册中心
代码语言:javascript复制 <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