SpringCloud ---day1
认识微服务
单体架构
微服务架构
方便进行打包上线,版本的更新上线,降低项目之间的耦合度,减少代码量巨大导致的编译/打包时间长的问题
SpringCloud简介
项目熟悉
业务流程
项目模块划分
服务拆分原则
什么时候拆:
对于一个初创的项目，首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发，快速产出生产可用的产品，投入市场做验证。为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。
如果这一阶段采用复杂的微服务架构，投入大量的人力和时间成本用于架构设计，最终发现产品不符合市场需求，等于全部做了无用功。
所以，对于大多数小型项目来说，一般是先采用单体架构，随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低，可以快速试错。但是，这么做的问题就在于后期做服务拆分时，可能会遇到很多代码耦合带来的问题，拆分比较困难（前易后难）。
而对于一些大型项目，在立项之初目的就很明确，为了长远考虑，在架构设计时就直接选择微服务架构。虽然前期投入较多，但后期就少了拆分服务的烦恼（前难后易）。
怎么拆:
之前我们说过，微服务拆分时粒度要小，这其实是拆分的目标。具体可以从两个角度来分析：
高内聚：每个微服务的职责要尽量单一，包含的业务相互关联度高、完整度高。
低耦合：每个微服务的功能要相对独立，尽量减少对其它微服务的依赖，或者依赖接口的稳定性要强。
高内聚首先是单一职责，但不能说一个微服务就一个接口，而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时，最好就只修改当前微服务，这样变更的成本更低。
一旦微服务做到了高内聚，那么服务之间的耦合度自然就降低了。
当然，微服务之间不可避免的会有或多或少的业务交互，比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库，否则就导致了数据耦合。而应该由商品服务对应暴露接口，并且一定要保证微服务对外接口的稳定性（即：尽量保证接口外观不变）。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。
明确了拆分目标，接下来就是拆分方式了。我们在做服务拆分时一般有两种方式：
纵向拆分
横向拆分
所谓纵向拆分，就是按照项目的功能模块来拆分。例如黑马商城中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。
而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。
服务注册和发现
服务拆分之后，不可避免的会出现跨微服务的业务，此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为RPC，即远程过程调用。RPC的实现方式有很多，比如：
•
基于Http协议
•
基于Dubbo协议
我们课堂中使用的是Http方式，这种方式不关心服务提供者的具体技术实现，只要对外暴露Http接口即可，更符合微服务的需要。
不过这种手动发送Http请求的方式存在一些问题。
试想一下，假如商品微服务被调用较多，为了应对更高的并发，我们进行了多实例部署
此时，每个item-service的实例其IP或端口不同，问题来了：
•
item-service这么多实例，cart-service如何知道每一个实例的地址？
•
http请求要写url地址，cart-service服务到底该调用哪个实例呢？
•
如果在运行过程中，某一个item-service实例宕机，cart-service依然在调用该怎么办？
•
如果并发太高，item-service临时多部署了N台实例，cart-service如何知道新实例的地址？
注册中心原理
在微服务远程调用的过程中，包括两个角色：
-
服务提供者：提供接口供其它微服务访问，比如
item-service -
服务消费者：调用其它微服务提供的接口，比如
cart-service
-
服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
-
调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
-
调用者自己对实例列表负载均衡，挑选一个实例
-
调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？
• 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
• 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
• 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
• 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表
Nacos注册中心
我们基于Docker来部署Nacos的注册中心，首先我们要准备MySQL数据库表，用来存储Nacos的数据。由于是Docker部署，所以大家需要将资料中的SQL文件导入到你Docker中的MySQL容器中
然后，将课前资料中的nacos目录上传至虚拟机的/root目录。
进入root目录，然后执行下面的docker命令：
docker run -d \ --name nacos \ --env-file ./nacos/custom.env \ -p 8848:8848 \ -p 9848:9848 \ -p 9849:9849 \ --restart=always \ nacos/nacos-server:v2.1.0-slim
以上是在将naco部署在docker中,接下来进入docker中的naco
服务注册
com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery
服务发现
服务的消费者要去nacos订阅服务，这个过程就是服务发现，步骤如下：
-
引入依赖
-
配置Nacos地址
-
发现并调用服务
服务发现除了要引入nacos依赖以外，由于还需要负载均衡，因此要引入SpringCloud提供的LoadBalancer依赖。
我们在cart-service中的pom.xml中添加下面的依赖：
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
可以发现，这里Nacos的依赖于服务注册时一致，这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人，也可以被别人调用，即可以是调用者，也可以是提供者。
因此，等一会儿cart-service启动，同样会注册到Nacos
接下来，服务调用者cart-service就可以去订阅item-service服务了。不过item-service有多个实例，而真正发起调用时只需要知道一个实例的地址。
因此，服务调用者必须利用负载均衡的算法，从多个实例中挑选一个去访问。常见的负载均衡算法有：
-
随机
-
轮询
-
IP的hash
-
最近最少访问
-
...
这里我们可以选择最简单的随机负载均衡;
另外，服务发现需要用到一个工具，DiscoveryClient，SpringCloud已经帮我们自动装配，我们可以直接注入使用
OpenFeign
我们利用Nacos实现了服务的治理，利用RestTemplate实现了服务的远程调用。但是远程调用的代码太复杂了
而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。
因此，我们必须想办法改变远程调用的开发模式，让远程调用像本地方法调用一样简单。而这就要用到OpenFeign组件了。
其实远程调用的关键点就在于四个：
-
请求方式
-
请求路径
-
请求参数
-
返回值类型
所以，OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写，非常方便
org.springframework.cloud
spring-cloud-starter-openfeign
org.springframework.cloud
spring-cloud-starter-loadbalancer
在cart-service中，定义一个新的接口，编写Feign客户端：
这里只需要声明接口，无需实现方法。接口中的几个关键信息：
-
@FeignClient("item-service")：声明服务名称 -
@GetMapping：声明请求方式 -
@GetMapping("/items")：声明请求路径 -
@RequestParam("ids") Collection：声明请求参数ids -
List：返回值类型
然后我们直接调用itemClient方法
feign替我们完成了服务拉取、负载均衡、发送http请求的所有工作, 看起来优雅多了。
而且，这里我们不再需要RestTemplate了,还省去了RestTemplate的注册。