前言
博主是一名97年的程序员，在职场上摸爬滚打了一年。从毕业至今，生活可以说是五味杂陈。这篇文章是我的第一篇文章，后面会持续更新，希望看完这篇文章的读者能有自己的感悟和收获。本篇文章主要带大家熟悉微服务以及学会应用springcloud的注册中心和负载均衡。
目录
1.了解微服务
1.1什么是微服务？
微服务从字面上解释就是微小的服务，在业界其实并没有给出微服务标准的定义，不过我们可以从俩个维度去理解微服务：
1.从架构风格上去理解：微服务架构的提出者Martin Fowler是这样阐述微服务架构的：简单来说，微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
对于这段话我是这样理解的：他说的意思就是把之前所做的单体系统分为很多个模块去开发，每个模块都是一个独立的服务，每个服务都是独立的进程，那么我们知道，在单体系统中，模块之间的调用是通过方法的，但是在微服务里，每个模块都是独立的服务，那么服务之间是怎么调用的呢？Martin Fowler指出服务之间的通信是通过http协议来进行的。那每个服务只要提供相应的接口，只要遵循http协议，那么不同的服务是可以使用不同的编程语言去开发，服务的数据可以保存在不同的数据库里，甚至每个服务可以在不同的操作系统上，只需保证服务之间能调用，能正常访问。
2.从微服务的设计理念去理解：微服务是一种架构，而一种架构的诞生目的是为了解决一些特定的问题，而微服务是为 解决哪些问题呢？这里就要说到微服务的架构演变了。
（1）传统单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。这样做的优点就是部署成本低、架构简单，因为就一台服务器。缺点是耦合度高，耦合度高所造成的问题是拓展性差，BUG蔓延（可靠性差），阻碍技术创新，复杂性高，部署频率低等等。虽然单体架构存在诸多缺点，但在某些场景中还是很适合使用的，比如一些业务很简单的项目：OA办公系统、学生管理系统等等。
（2）如果在大型高并发项目中使用单体系统，那它的缺陷会完全暴露出来，比如：京东、淘宝等等。为了解决这一问题，于是产生了分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。优点：降低服务耦合，有利于业务拓展和维护。但是分布式在服务治理上存在了很多的问题：服务拆分粒度如何？ 服务集群地址如何维护？ 服务之间如何实现远程调用？ 服务健康状态如何感知？
（3）为了解决分布式架构中的一些问题，于是出了一套解决方案，这套方案就是微服务架构。微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征： 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发； 面向服务：微服务对外暴露业务接口； 自治：团队独立、技术独立、数据独立、部署独立 ；隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题。缺点是架构非常复杂，运维、监控、部署难度大。
1.2一个微服务工程可能包含的技术体系
微服务技术主要包括：服务治理、异步通信技术、缓存技术、DevOps、搜索技术，每一个技术下都有一系列的技术分支，如下图。后面我会带大家一起学习这些技术。
2.Springcloud
通过上面的阅读，我们已经清晰的认识了微服务，那么微服务既然是一种解决方案，是一个架构，那么必然需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。注意：SpringCloud主要是落地微服务架构中的服务治理。
2.1为什么要选择SpringCloud
下图是微服务的一些落地技术框架的对比
SpringCloud中提供了配置中心和服务网关的相关组件，并且SpringCloud中包含了SpringCloudＡ－libada，除此之外，SpringCloud是在SpringBoot的基础上开发的，SpringBoot大家应该也了解过，它就是自动装备的，简化了很多配置，只需要注解就能实现相关功能，用起来很方便。
2.2服务拆分
服务拆分把每个模块甚至每个功能都作为一个服务。
服务拆分的注意事项：
1.单一职责：不同微服务，不要重复开发相同的业务
2.面向服务：暴露自己的服务为接口，供其他微服务调用
3.数据独立：不要访问其他微服务的数据库
2.3服务调用
在单体架构中只有一个服务，服务中有不同的业务，业务之间通过方法来调用。那么在微服务中，每个服务都是独立的功能，不同的服务所使用的开发环境可能不一样，那么服务之间是怎么调用的呢？
这里介绍服务之间调用的其中一个方法：使用RestTemplate,使用方法如下，比如这里是订单服务order-service去调用用户服务user-service中的一个功能：
1.在订单服务的SpringBoot的启动类中把RestTemplate对象注入到Spring容器中
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}2.在A服务的service中向B服务发起Http请求
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) { // 1.查询订单
Order order = orderMapper.findById(orderId); // TODO 2.查询用户
String url = "http://localhost:8081/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class); // 3.封装user信息
order.setUser(user); // 4.返回
return order;
}2.4 Eureka注册中心
2.4.1上面服务调用存在的问题：
1.服务消费者该如何获取服务提供者的地址信息？难道写死吗--“IP地址：端口号/接口地址+参数”
2.如果有多个服务提供者，消费者该如何选择？比如说提供者是一个集群
3.消费者如何得知服务提供者的健康状态？
2.4.2Eureka的作用
1.消费者该如何获取服务提供者具体信息？
服务提供者启动时向eureka注册自己的信息 eureka保存这些信息 消费者根据服务名称向eureka拉取提供者信息
2.如果有多个服务提供者，消费者该如何选择？
服务消费者利用负载均衡算法，从服务列表中挑选一个
3.消费者如何感知服务提供者健康状态？
服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态 eureka会更新记录服务列表信息，心跳不正常会被剔除 消费者就可以拉取到最新的信息
2.4.3 eureka的使用
1.搭建eureka服务，eureka本身也是一个服务
（1）创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
（2）编写启动类，添加@EnableEurekaServer注解
（3）添加application.yml文件，编写下面的配置：
server:
port: 10086
spring:
application:
name: eurekaserver
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka/2.提供者注入eureka
（1）在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
（2）在application.yml文件，编写下面的配置：
spring:
application:
name: userserviceeureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka/
3.消费者拉取服务：服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
（1）注册服务到eureka
(2)修改service中调用服务的方法
String url = "http://userservice/user/" + order.getUserId();
（3）在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解@LoadBalanced
2.4.4 eureka总结
在Eureka架构中，微服务角色有两类：
| EurekaClient：客户端 | Provider：服务提供者，例如案例中的 user-service 注册自己的信息到EurekaServer 每隔30秒向EurekaServer发送心跳 |
| consumer：服务消费者，例如案例中的 order-service 根据服务名称从EurekaServer拉取服务列表 基于服务列表做负载均衡，选中一个微服务后发起远程调用 | |
| EurekaServer：服务端（注册中心） | 记录服务信息 ，心跳监控 |
2.5 Ribbon负载均衡
负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。举个通俗的例子：假如教室里只有1个门，教室里有100个人，放学了这100人都走那一个门就很拥挤、需要20分钟才能走完，那现在我在给这教室开2个门，这100个人平分到这3个门中走，是不是7分钟就走完了。这就是负载均衡的原理。
2.5.1 负载均衡的流程
2.5.2 负载均衡的策略
2.5.3 修改负责均衡策略
通过定义IRule实现可以修改负载均衡规则，有两种方式：
1.代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：
@Bean
public IRule randomRule(){
return new RandomRule();
}
2.配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule# 负载均衡规则2.5.4 Ribbon的加载形式
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。 而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: userservice # 指定饥饿加载的服务名称
3.总结
本次分享就到此结束了，下次准备分享Nacos的相关内容。其实博主写这个的初衷是为了巩固自己所学的内容用的，本来打算做笔记到本地，后来觉得把自己所学的东西分享给大家既能帮助初学微服务的读者，也能督促自己把学习持续下去。所以，大家一起加油呦！欢迎来评论，也非常希望大家能指出我一些错误的技术论点。谢谢大家！
1107
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
