单体架构
很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬, 这就是单体架构. 业务的所有功能实现都打包在⼀个war包或者Jar包中,这种⽅式就称为单体架构
集群和分布式架构
当⽹站的⽤⼾量越来越⼤,需求也会越来越多,流量也会越来越⼤,服务可能就会⾯临以下问题: • 后端服务器的压⼒就会越来越⼤,负载越来越⾼,甚⾄出现⽆法访问的情况 • 业务场景逐渐复杂.为了满⾜⽤⼾的需求,单体应⽤也会越来越⼤.各个业务代码之间的耦合度也会 越来越⾼.任何⼀个问题, 都需要整个项⽬重新构建,发布. • ⼀个微⼩的问题,可能会导致整个应⽤挂掉
我们从两个⽅⾯进⾏优化:
• 横向:添加服务器,把单台机器变成多台机器的集群.
• 纵向:把⼀个应⽤,按照业务进⾏拆分,拆分为多个项⽬.此架构也称为垂直架构.
集群和分布式
• 集群(cluster)是将⼀个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个 服务器通过负载均衡调度完成任务.每个服务器称为集群的节点(node)
• 分布式是将⼀个系统拆分为多个⼦系统，多个⼦系统部署在多个服务器上，多个服务器上的⼦系统 协同合作完成⼀个特定任务• 分布式是将⼀个系统拆分为多个⼦系统，多个⼦系统部署在多个服务器上，多个服务器上的⼦系统 协同合作完成⼀个特定任务
微服务架构
在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,服务的调⽤关系也会越来越复杂. 我们可以把⼀些通⽤的,会被多个上层服务调⽤的共享业务,提取成独⽴的基础服务,组成⼀个个微⼩的 服务.这就是微服务.
微服务架构是分布式架构的⼀种拓展,这种架构模式下它拆分粒度更⼩,服务更独⽴.可
以理解为:微服务是⼀种经过良好架构设计的分布式架构⽅案
.微服务解决⽅案-SpringCloud
Spring Cloud 提供了⼀些可以让开发⼈员快速构建分布式服务的⼯具,⽐如配置管理,服务发现,熔断, 智能路由等.他们可以在任何分布式环境中很好的⼯作
Spring Cloud和SpringBoot的关系 Spring Cloud中的所有⼦项⽬都依赖SpringBoot,所以SpringBoot和SpringCloud的版本之间也存在 ⼀定的对应关系、
Spring Cloud实现⽅案 在SpringCloud的规范下,有很多实现,其中最为出名的是
• SpringCloudNetflix
• SpringCloudAlibaba
拆分微服务---般遵循如下原则:
-
单⼀职责原则
-
服务⾃治
-
单向依赖 微服务之间需要做到单向依赖,严禁循环依赖,双向依赖
RestTemplate
RestTemplate 是从Spring3.0开始⽀持的⼀个HTTP请求⼯具,它是⼀个同步的RESTAPI客⼾端,提 供了常⻅的REST请求⽅案的模版
:order-service服务向product-service服务发送⼀个http请求,把得到的返回结果,和订单结 果融合在⼀起,返回给调⽤⽅
实现⽅式: 采⽤Spring提供的RestTemplate
- 定义RestTemplate
- 修改order-service中的OrderService
什么是REST? REST(Representational State Transfer), 表现层资源状态转移. REST是由HTTP的主要设计者RoyFielding博⼠在2000年他的博⼠论⽂中提出来的⼀种软件架构⻛格.
REST是⼀种设计⻛格,指资源在⽹络中以某种表现形式进⾏状态转移. 简单来说:REST描述的是在⽹络中Client和Server的⼀种交互形式,REST本⾝不实⽤，实⽤的是如何设 计RESTfulAPI（REST⻛格的⽹络接⼝）
什么是RESTful? REST是⼀种设计⻛格,并没有⼀个明确的标准.满⾜这种设计⻛格的程序或接⼝我们称之为RESTful(从 单词字⾯来看就是⼀个形容词).所以RESTfulAPI就是满⾜REST架构⻛格的接⼝.
什么是注册中⼼
在最初的架构体系中, 集群的概念还不那么流⾏,且机器数量也⽐较少,此时直接使⽤DNS+Nginx就可 以满⾜⼏乎所有服务的发现.相关的注册信息直接配置在Nginx.但是随着微服务的流⾏与流量的激增, 机器规模逐渐变⼤,并且机器会有频繁的上下线⾏为,这种时候需要运维⼿动地去维护这个配置信息是 ⼀个很⿇烦的操作.所以开发者们开始希望有这么⼀个东西,它能维护⼀个服务列表,哪个机器上线了, 哪个机器宕机了,这些信息都会⾃动更新到服务列表上,客⼾端拿到这个列表,直接进⾏服务调⽤即可. 这个就是注册中⼼.
注册中⼼主要有三种⻆⾊：
• 服务提供者(Server)：⼀次业务中,被其它微服务调⽤的服务.也就是提供接⼝给其它微服务.
• 服务消费者(Client)：⼀次业务中,调⽤其它微服务的服务.也就是调⽤其它微服务提供的接⼝.
• 服务注册中⼼(Registry):⽤于保存Server的注册信息,当Server节点发⽣变更时,Registry会同步 变更.服务与注册中⼼使⽤⼀定机制通信,如果注册中⼼与某服务⻓时间⽆法通信,就会注销该实例.
服务注册：服务提供者在启动时,向Registry注册⾃⾝服务,并向Registry定期发送⼼跳汇报存活状 态.
服务发现：服务消费者从注册中⼼查询服务提供者的地址，并通过该地址调⽤服务提供者的接⼝.服务 发现的⼀个重要作⽤就是提供给服务消费者⼀个可⽤的服务列表.
CAP理论
谈到注册中⼼,就避不开CAP理论. CAP理论是分布式系统设计中最基础,也是最为关键的理论
• ⼀致性(Consistency) CAP理论中的⼀致性,指的是强⼀致性.所有节点在同⼀时间具有相同的数据 • 可⽤性(Availability)保证每个请求都有响应(响应结果可能不对)
• 分区容错性(PartitionTolerance)当出现⽹络分区后，系统仍然能够对外提供服务 ⼀个部⻔全国各地都有岗位,这时候,总部下发了⼀个通知,由于通知需要开会周知全员,当有客⼾咨 询时:
-
所有成员对客⼾的回应结果都是⼀致的(⼀致性)
-
客⼾咨询时,⼀定有回应(可⽤性)
-
当其中⼀个成员休假时,这个部⻔的其他成员也可以对客⼾提供咨询服务(分区容错性)
CAP理论告诉我们:⼀个分布式系统不可能同时满⾜数据⼀致性,服务可⽤性和分区容错性这三个基本 需求,最多只能同时满⾜其中的两个. 在分布式系统中,系统间的⽹络不能100%保证健康,服务⼜必须对外保证服务.因此Partition Tolerance不可避免.那就只能在C和A中选择⼀个.也就是CP或者AP架构
CP架构: 为了保证分布式系统对外的数据⼀致性,于是选择不返回任何数据
AP架构: 为了保证分布式系统的可⽤性,节点2返回V0版本的数据(即使这个数据不正确)
常⻅的注册中⼼
1. Zookeeper Zookeeper的官⽅并没有说它是⼀个注册中⼼,但是国内Java体系,⼤部分的集群环境都是依赖 Zookeeper来完成注册中⼼的功能.
2. Eureka Eureka是Netflix开发的基于REST的服务发现框架,主要⽤于服务注册,管理，负载均衡和服务故障 转移. 官⽅声明在Eureka2.0版本停⽌维护,不建议使⽤.但是Eureka是SpringCloud服务注册/发现的默认 实现,所以⽬前还是有很多公司在使⽤.
3. Nacos Nacos是SpringCloudAlibaba架构中重要的组件,除了服务注册,服务发现功能之外,Nacos还⽀持 配置管理,流量管理,DNS,动态DNS等多种特性.
Eureka 介绍
Eureka主要分为两个部分： • EurekaServer:作为注册中⼼Server端,向微服务应⽤程序提供服务注册,发现,健康检查等能⼒. • EurekaClient: 服务提供者,服务启动时,会向EurekaServer注册⾃⼰的信息(IP,端⼝,服务信息 等),Eureka Server 会存储这些信息
关于Eureka的学习,主要包含以下三个部分: 1. 搭建EurekaServer 2. 将order-service, product-service 都注册到Eureka 3. order-service远程调⽤时,从Eureka中获取product-service的服务列表,然后进⾏交互
搭建EurekaServer
Eureka-server 是⼀个独⽴的微服务.
创建Eureka-server⼦模块
引⼊eureka-server依赖
3.3 项⽬构建插件
完善启动类
给该项⽬编写⼀个启动类,并在启动类上添加@EnableEurekaServer 注解,开启eureka注册中⼼服务
编写配置⽂件
启动服务
启动服务,访问注册中⼼:http://127.0.0.1:10010/ 
服务注册
接下来我们把product-service注册到eureka-server中
1引⼊eureka-client依赖
2 完善配置⽂件
3启动服务
服务发现
接下来我们修改order-service,在远程调⽤时,从eureka-server拉取product-service的服务信息,实现 服务发现
1 引⼊依赖
服务注册和服务发现都封装在eureka-client依赖中,所以服务发现时,也是引⼊eureka-client依赖
2完善配置⽂件
服务发现也需要知道eureka地址,因此配置内容依然与服务注册⼀致，都是配置eureka信息
远程调⽤
远程调⽤时,我们需要从eureka-server中获取product-service的列表(可能存在多个服务),并选择其中 ⼀个进⾏调⽤
