SpringCloud与微服务架构

1、微服务架构4个核心问题：

1. 服务模块很多，客户端怎么访问？
2. 这么多服务，服务间如何通信？
3. 这么多服务，如何治理？
4. 服务挂了怎么办？

2、业界较成熟的解决方案：

• SpringCloud NetFlix
• SpringCloud Alibaba
• Dubbo+Zookeeper
• SpringCloud 官方
• SpringCloud K8s

3、问题：

1. 什么是微服务？

2. 微服务之间如何独立通信？

3. SpringCloud和Dubbo区别？

4. SpringBoot和SpringCloud谈谈你对他们的理解？

5. 什么是服务熔断？什么是服务降级？

6. 微服务的优缺点是什么？说下在项目中的坑？

7. 你所知道的微服务技术栈？

8. eureka和zookeeper都可以提供服务注册与发现的功能,请你说说这两个的区别？

微服务与微服务架构

微服务

微服务强调的是服务的大小，他关注服务的某一个点，微服务的核心是将传统的一站式应用拆分成一个一个的服务，彻底去耦合，每一个微服务提供单个业务功能的服务，一个服务去做一件事，从技术的角度看就是一种小而独立的处理过程，类似进程的概念，能够单独启动或销毁，拥有自己独立的数据库。

微服务架构

一种新的架构形式，Martin Fowler 2014年提出，Microservices 原文翻译

微服务的优缺点

优点

• 每个服务足够内聚，足够小，能聚焦一个指定的业务功能或业务需求
• 开发简单，开发效率提高，一个服务只干一件事
• 微服务是松耦合高内聚，无论在开发阶段还是部署阶段都是独立的
• 微服务是一种理念架构，能使用不同的语言开发
• 微服务只是业务逻辑代码，不会和HTML，CSS或其他界面混合
• 每个服务有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

缺点：

• 开发人员要处理分布式系统的复杂性

• 多服务部署，运维的难度，压力增大

• 服务间的通信

• 数据一致性

• 系统集成测试

• 性能监控

微服务相关技术栈

微服务条目	落地技术
服务开发	SpringBoot、SpringMVC、Spring
服务配置与管理	NetFlix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Zookeeper、Consu等
服务调用	RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务的简化工具）	Feign等
消息队列	Kafka、RocketMQ、RabbitMQ
服务配置中心管理	SpringCloudConfig，Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	Zipkin、Brave，Dapper等
服务部署	Docker、OpenStack，K8s
数据流操作开发包	SpringCloud Stream
事件消息总线	SpringCloud Bus

为什么选择SpringCloud作为微服务架构

• 整体解决方案和框架成熟度
• 社区热度
• 可维护行
• 学习曲线

各类微服务框架对比

功能点/服务框架	NetFlix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务架构	RPC框架，但整合了zk或Consul，实现集群环境的基本服务注册/发现	RPC框架	RPC框架	服务框架
支持RPC	是，Ribbon支持多种可拔插的序列化选择	否	否	否	否
支持多语言	是	否	是	是	否
负载均衡	是（服务端zuul+客户端Ribbon），zuul-服务，动态路由，云端负载均衡Eureka	是（客户端）	否	否	是（客户端）
配置服务	NetFlix Archaius，SpringCloudConfig集中配置	是（zk提供）	否	否	否
服务调用链监控	是（zuul）	否	否	否	否
高可用/高容错	是（服务端Hystrix+客户端Ribbon）	是（客户端）	否	否	是（客户端）
典型应用案例	Netflix	Sina	Google	Facebook	当当
社区活跃程度	高	一般	高	一般	2017开始维护，中断5年
学习难度	中等	低	高	高	低
文档丰富度	高	一般	一般	一般	高

SpringCloud是什么

SpringCloud，基于SpringBoot提供的一套完整的微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务注册发现，熔断器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等。

SpringCloud并没有重复造轮子，它只是将目前各家公司开发的比较成熟，经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包。

SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

SpringBoot与SpringCloud关系

• SpringBoot专注开发单个个体微服务。
• 而SpringCloud为全局的微服务提供协调治理解决方案，它将SpringBoot开发的单个服务整合并管理起来，为各个微服务之间提供：配置管理，服务注册发现，熔断器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等集成服务。
• SpringBoot可以离开SpringCloud独立使用，而SpringCloud离不开SpringBoot，属于依赖关系。

SpringCloud VS Dubbo

	Dubbo	SpringCloud
服务注册中心	Zookeeper	SpringCloud NetFlix Eureka
服务调用中心	RPC	REST API
服务监控	Dubbo-monitor	SpringBoot Admin
熔断器	不完善	SpringCloud NetFlix Hystrix
服务网关	无	SpringCloud Zuul
分布式配置	无	SpringCloud Config
服务跟踪	无	SpringCloud Sleuth
消息总线	无	SpringCloud Bus
数据流	无	SpringCloud Stream
批量任务	无	SpringCloud Task

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式

严格来说，这两种通信方式各有优势，虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了原生RPC带来的问题，而且REST相比于RPC更加灵活，服务提供方与服务调用方的依赖只依靠一纸契约，不存在代码级别的强依赖性，这在强调快速演化的微服务环境下，显得更加合适。

解决问题域不一样：Dubbo的定位是一款高性能RPC框架，SpringCloud的定位是微服务架构下的一站式解决方案

SpringCloud有哪些用处？

• Distributed/versioned configuration（分布式/版本化配置）
• Service registration and discovery（服务注册和发现）
• Routing（路由）
• Service-to-service calls（服务与服务间调用）
• Load balancing（负载均衡）
• Circuit Breakers（熔断器）
• Global locks（全局锁）
• Leadership election and cluster state（leader选举和集群状态）
• Distributed messaging（分布式消息传递）

SpringCloud版本号起源

SpringCloud是一个由众多独立子项目组成的大型综合项目，每个子项目有不同的发行节奏，都维护着自己的发行版。SpringCloud通过一个资源清单BOM（Bill of Materials）来管理每个版本的子项目清单。为避免与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。

这些版本名称的命名方式采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Angle，第二个Release版本：Brixton，然后是Camden、Dalston、Edgware

SpringCloud官方文档 ：SpringCloud官方文档
SpringCloud中文文档：SpringCloud中文文档