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调用
技术维度理解
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，
从技术角度就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库