springcloud学习前提:需要具备一定的java、springboo等相关知识,加油,为自己鼓掌大气....
参考链接:https://www.cnblogs.com/kashowres/p/9011665.html
参考链接:https://blog.csdn.net/q15102780705/article/details/100045375
1.1什么是微服务
微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外应尽量避免统一的,集中的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数所存储。
怎么学习使用?在接下来的学习中,我们将主要围绕以下红色重点知识再学习.
服务的注册与发现(Eureka)
服务消费者(rest+Ribbon)
服务消费者(Feign)
断路器(Hystrix)
断路器监控(Hystrix Dashboard)
路由网关(Zuul)
分布式配置中心(Spring Cloud Config)
消息总线(Spring Cloud Bus)
服务链路追踪(Spring Cloud Sleuth)
1.2微服务之间是如何独立通讯的
1.3 SpringCloud和Dubbo有哪些区别
Dubbo通信机制基于RPC远程过程调用、SpingCloud基于RESTful API调用
最大区别:SpringCloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式
严格来说,这两种方式各有优劣,虽然从一定程度上来说,后者牺牲服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速深化的微服务环境下,显得更加合适
品牌机与组装机的区别
很明显,Spring Cloud的功能比DUBBO更加强大,涵盖面更广,而且作为Spring的拳头项目,它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美整合,这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而Spring Cloud就像品牌机,在Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。
社区支持与更新力度
最为重要的是,DUBBO停止了5年左右的更新,虽然2017.7重启了。对于技术发展的新需求,需要由开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织,显然是不太合适的,中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案,并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
1.4 SpringBoot和SpringCloud,请你谈谈对他们的理解
SpringBoot专注于快速方便的开发单个个体微服务
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目,但是SpringCloud离不开SpringBoot,属于依赖的关系
SpringBoot专注于快速、方便的开发单个微服务个体,SpringCloud关注于全局的服务治理框架。
1.5 什么是服务熔断?什么是服务降级
1.6 微服务的优缺分别是什么?说下你在项目开发中碰到的坑
优点
l 每个服务足够内聚,足够小,代码容易理解这样能聚集一个指定的业务功能或业务需求
l 开发简单、开发效率提高,一个服务可能就是专一的只干一件事
l 微服务能够被小团队单独开发,这个小团队是2到5人的开发人员组成
l 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的
l 微服务能使用不同的语言开发
l 易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins,Hudson,bamboo
l 微服务易于被一个开发人员理解、修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作体现价值。
l 微服务允许你利用整合最新技术
l 微服务只是业务逻辑的代码,不会和HTML,CSS或其他界面组件混合
l 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一数据库
缺点
开发人员要处理分布式系统的复杂性
多服务运维难度,随着服务的增加,运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控…………
开发中,我们们有两种开发模式
1. 前后端分离
a) 我们Java程序员,相对而言比较幸福,why?
b) 我们只需要管理后端,给前端的H5工程师就按照约定
c) Rest地址+输入参数格式和报文约定+输出参数
$.post{rest,jsonParameter,callBack}
可以灵活搭配,连接公共库+连接独立库???
2.全栈工程师
H5+javaEE+………..
1.7你所知道的微服务技术栈有哪些?请列举一二
微服务技术栈:多种技术的集合体
我们再讨论一个分布式的微服务架构的话,它需要有哪些维度??
一个分布式的微服务架构 维度 E时代下的数字化生活
服务治理 手机
服务注册 电脑
服务调用 充电宝
服务负载均衡 路由器
服务监控 …… 小米科技
各个杂牌
SpringCloud
微服务条目 | 落地技术 | 备注 |
服务开发 | SpringBoot、Spring、SpringMVC |
|
服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
|
服务注册与发现 | Eureka、Consul、Zookeeper等 |
|
服务调用 | Rest、RPC、GRP C |
|
服务熔断器 | Hystrix、Envoy等 |
|
负载均衡 | Ribbon、Nginx等 |
|
服务接口调用 (客户端调用服务的简化工具) | Feign等 |
|
消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
|
服务配置中心管理 | SpringCloudConfig、Cherf等 |
|
服务路由(API网关) | Zuul等 |
|
服务监控 | Zabbix、Nagios、Metrics、Spectator等 |
|
全链路追踪 | Zipkin、Brave、Kubernetes等 |
|
服务部署 | Docker、OpenStack、Kubernetes等 |
|
数据流操作开发包 | SpringCloud Stream(封装与Redis、Rabbit、Kafka等发送接收消息) |
|
事件消息总线 | Spring Cloud Bus |
|
…… |
|
|
1.8 eurek和zookeeper都可以提供服务注册与发现的功能,请说说两个的区别?
分布式中著名的CPA理论:一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。
Consistency(一致性), 数据一致更新,所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容忍性) 可靠性
Zookeeper是保证CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka是保证AP
Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中
因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
1.9……..
2.5 为什么选择SpringCloud作为微服务架构
选型依据
整体解决方案和框架成熟度
社区热度
可维护性
学习曲线
当前各大IT公司用的微服务架构有哪些?
阿里Dobbo/HSF
京东JSF
新浪微博Motan
当当网DubboX
……
各微服务框架对比
功能点/服务 框架 | 备选方案 | ||||
Netflix/Spring Cloud | Motan | gRPc | Thrift | Dubbo/DubboX | |
功能定位 | 完整的微服务框架 | RPC框架,但整合了ZK 或Consul,实现集群环境的基本的服务注册/发现 | RPC框架 | RPC框架 | 服务框架 |
支持Rest | 是 Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
支持多语言 | 是(Rest形式)? | 否 | 是 | 是 | 是 |
服务注册/发现 | 是(Eureka) Eureka服务注册表,Karyon服务端框架支持服务自注册和健康检查 | 是(Zookeeper/consul) | 否 | 否 | 是 |
负载均衡 | 是(服务端zuul+客户端Ribbon) Zuul-服务,动态路由 云端负载均衡Eureka( 针对中 间层服务器) | 是(客户端) | 否 | 否 | 是(客户端) |
配置服务 | Netflix Archaius Spring Cloud Config Server集中配置 | 是(zookeeper提供) | 否 | 否 | 否 |
服务调用链监控 | 是(zuul) Zuul提供边缘服务,API网关 | 否 | 否 | 否 | 否 |
高可用/容错 | 是(服务端Hystrix+客户端Ribbon) | 是(客户端) | 否 | 否 | 是(客户端) |
典型应用案例 | Netflix | Sina | Gooogle | Fackbook |
|
社区活跃程度 | 高 | 一般 | 高 | 一般 | 2017.8重新启动 |
学习难度 | 中等 | 低 | 高 | 高 | 低 |
文档丰富度 | 高 | 一般 | 一般 | 一般 | 高 |
其他 | Spring Cloud Bus为我们的应用程序带来了更多管理端点 | 支持降级 | Netflix内部在开发集成gRPC | IDL定义 | 实践的公司比较多 |
单机系统All In One
可以看作eclipse工作空间里面只有一个工程
如:Tmall
com.atguigu.service
商品/交易/积分/订单…….
分布式
专业的事交给专业的人做,尽量降低耦合度
各个模块/服务,各自独立出来,分灶吃饭
各自微小的一个过程,让专业的人专业的模块,来做专业的事情
独立部署
l 拆分
l 各自独立的进程
l 拥有自己独立的数据库
Dubbo通信机制基于RPC远程过程调用、SpingCloud基于RESTful API调用
技术维度理解
微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,
从技术角度就是一种小而独立的处理过程,类似进程的概念,能够自行单独启动或销毁,拥有自己独立的数据库