空不是无,空是一种存在,你得用空这种存在填满自己。
维基上对其定义为:一种软件开发技术- 面向服务的体系结构(SOA)架构样式的一种变体,将应用程序构造为一组松散耦合的服务。在微服务体系结构中,服务是细粒度的,协议是轻量级的。
微服务(或微服务架构)是一种云原生架构方法,其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常
● 有自己的堆栈,包括数据库和数据模型;
● 通过REST API,事件流和消息代理的组合相互通信;
● 和它们是按业务能力组织的,分隔服务的线通常称为有界上下文。
尽管有关微服务的许多讨论都围绕体系结构定义和特征展开,但它们的价值可以通过相当简单的业务和组织收益更普遍地理解:
● 可以更轻松地更新代码。
● 团队可以为不同的组件使用不同的堆栈。
● 组件可以彼此独立地进行缩放,从而减少了因必须缩放整个应用程序而产生的浪费和成本,因为单个功能可能面临过多的负载。
1、微服务与微服务架构
微服务:
强调的是服务的大小,它关注的是某一点,是具体解决某一个问题/提供落地对应服务的一个服务应用,强调的是一个个的个体,每一个个体完成一个具体的任务或者功能。
微服务架构:
微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分为一组小的服务,每一个服务运行在其独立的自己的进程中,服务之间相互协调,相互配合,为用户提供最终价值。
2、微服务的优缺点
优点:
- 每一个服务足够内聚,足够小,代码容易理解;
- 开发简单,开发效率高,一个服务可能就专一的只干一件事;
- 微服务能被小团队单独开发;
- 微服务是松耦合的,是具有功能意义的服务,无论是在开发阶段或是部署阶段都是独立的;
- 易于第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jekins,Hudson,bamboo…;
- 微服务只是业务逻辑的代码,不会和HTML,CSS或其他界面组件混合;
- 每一个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库。
缺点:
- 开发人员要处理分布式系统的复杂性;
- 多服务运维难度,随着服务的增加,运维的压力也在增大;
- 系统部署依赖;
- 服务通信成本;
- 数据一致性;
- 系统集成测试;
- 性能监控。
3、技术栈
多种技术的集合体。
微服务条目 | 使用技术 |
---|---|
服务开发 | Springboot, Spring, SpringMVC… |
服务配置管理 | Archaius, Diamond… |
服务注册与发现 | EureKa, Consul, Zookeeper… |
服务调用 | Rest, RPC, gRPC… |
服务器熔断 | Hystrix, Envoy… |
负载均衡 | Ribbon, Nginx… |
服务接口调用 | Feign… |
消息队列 | Kafka, RabbitMQ, ActiveMQ… |
服务配置中心管理 | SpringCloud Config, Chef… |
服务路由(API网关) | Zuul… |
服务监控 | Zabbix, Nagios, Metrics, Spectator… |
全链路追踪 | Zipkin, Brave, Dapper… |
服务部署 | Docker, Openstack, Kubernetes… |
数据流操作开发包 | Springcloud stream |
事件消息总线 | Springcloud Bus |
… |
4、SpringCloud是什么?
SpringCloud是基于SpringBoot提供了一套微服务解决方案,包括服务注册与发现、配置中心、全链路监控、服务网关,负载均衡,熔断器等组件。利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发。
5、SpringCloud和SpringBoot的区别?
SpringBoot专注于快速方便的开发单个个体微服务;
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供,配置管理、服务发现、熔断器、路由、微代理、时间总线、全局锁、决策竞选、分布式会话等等服务。
SpringBoot可以离开SpringCloud独立使用开发项目,但是SpringCloud离不开SpringBoot。
6、SpringCloud和dubbo的区别?
社区活跃不同;
dubbo采用RPC通信,SpringCLoud基于HTTP的Rest方式;
SpringCloud全家桶,有自己的断路器、路由网关、分布式配置、服务跟踪、消息总线和数据流,而dubbo只有自己的不完善的断路器,其余都没有。
7、Eureka
基于AP原则;
Eureka是Netflix的一个子模块,也是核心模块之一。Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的,有了服务注册与发现只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了。
7.1、Eureka包含两个组件:Eureka Server和Eureka Client
Eureka Server提供服务注册服务
各个节点启动后,会在Eureka Server中进行注册,这样Eureka Server中的服务注册表中将会存储所有可用的服务节点的信息,服务节点的信息可以在界面上直观的看到。Eureka Client
Eureka Client 是一个Java客户端,用于简化Eureka Server的交互,客户端同时也具备一个内置的使用轮询(round-robin)负载算法的负载均衡器。在应用启动后,将会向Eureka Server发送心跳(默认周期为30s),如果Eureka Server在多个心跳周期没有接受到某个节点的心跳,Eureka Server就会从服务注册节点中移除(默认90s)。
7.2、Eureka三个角色
- Eureka Server提供服务注册与发现
- Eureka Provider服务提供方将自身服务注册进Eureka从而使服务消费者能够找到
- Service Consumer服务消费方从Eureka获取注册服务列表,从而能够消费服务
7.3、Eureka服务注册的建立(Eureka Server)
- Eureka模块的建立
- pom文件新增
1 | <dependency> |
- 添加application.yml配置
1 | #服务端口 |
- Eureka启动类,在启动类上添加对应的注解标签,@EnableEurekaServer
7.4、将已有服务注册进Eureka(Eureka Client)
- 修改要注册Eureka服务的模块pom文件
1 | <dependency> |
- 修改对应application.yml文件
1 | #服务端口 |
- 启动类上添加注解,@EnableEurekaClient
7.5、注册微服务信息完善
- 修改注册服务的名称
1 | instance: |
- 访问信息有IP提示
1 | prefer-ip-adress:true #访问IP路径可现实IP |
微服务info内容的详细信息
pom文件添加
1
2
3
4<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>总的父工程下添加build配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20<build>
<finalName>microservicecloud</finalName> #父工程的名字
<resources>
<resource>
<directory>src/main/resources</directory> #容许你访问所有工程下的src/main/resources
<filtering>true</filtering> #访问了过滤开启
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId> #解析解读
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<delimiters>
<delimit>$</delimit> #$符号结尾的,在resource指定的src/main/resources路径下配置文件信息都能读取
</delimiters>
</configuration>
</plugin>
</plugins>
</build>修改注册服务application.yml文件
1
2
3
4
5info:
app.name:
company.name:
build.artifactId: $project.artifactId$
build.version: $project.version$
7.6、Eureka的自我保护机制
某一时刻某一微服务不可用了,eureka不会立即清理,依旧会对该微服务的信息进行保存,当它收到的心跳数重新恢复到阈值以上时,该Eureka server节点就会自动退出保护机制。它的设计哲学就是宁可保留错误的服务注册信息,也不盲目注销任何可能是健康的服务实例。
自我保护模式是一种应对网络异常的安全保护措施。在SpringCloud中,可以使用eureka.server.enable-self-preservation=false禁用自我保护模式。
7.7、Eureka集群配置
- 参与服务注册的微服务各个yml对应hostname修改,对应defaultZone配置:访问地址除本省外的其余微服务地址
- 微服务服务端defaultZone:访问所有微服务注册地址
后记
Netflix在Eureka中遵守AP原则。
传统关系型数据库(MySQL,Orale,Sql Server) 遵守ACID原则。
关系型数据库(Redis,MongoDB) 遵守ACP原则。
CAP:一个分布式系统不可能同时很好的满足一致性(C)、可用性(A)和分区容忍性三个需求。因此,根据CAP原理将NoSQL数据库分成了满足CA原则、CP原则、AP原则三大类。
- CA:单点集群,满足一致性,可用性的系统,通常在扩展上不太强大
- CP:满足一致性,分区容忍性的系统,通用性能不是很高
- AP:满足可用性,分区容忍性,通常可能对一致性要去低一点
zoomkeepe和Eureka的区别?
前者是CP原则,后者是AP原则。
前者在master失联,选举新的leader时使用时间较长,容易引起服务崩溃
后者的各个服务无论是否异常都存在于注册信息中,只要还有一个服务注册运行都不会丢失
8、Ribbon
Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接一起。
- 本文作者: llc
- 本文链接: http://llc-dukes.top/2020/12/08/SpringCloud微服务/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!