SpringCloud（一）微服务概述

---

微服务概述

马丁福勒微服务论文：https://martinfowler.com/articles/microservices.html

什么是微服务

• 目前的微服务并没有一个统一的标准，一般是以业务来划分
• 将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。
• 与微服务相对的叫巨石

微服务与微服务架构

• 微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务独立部署，服务之间相互配合、相互协调，每个服务运行于自己的进程中。
• 服务与服务间采用轻量级通讯，如 HTTP的RESTful API等
• 避免统一的、集中式的服务管理机制

微服务的优缺点

优点

1. 每个服务足够内聚，足够小，比较容易聚焦
2. 开发简单且效率高，一个服务只做一件事情
3. 开发团队小，一般2-5人足以（当然按实际为准）
4. 微服务是松耦合的，无论开发还是部署都可以独立完成
5. 微服务能用不同的语言开发
6. 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等）
7. 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
8. 微服务允许你融合最新的技术
9. 微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合。
10. 每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活。

缺点

1. 开发人员要处理分布式系统的复杂性
2. 多服务运维难度，随着服务的增加，运维的压力也会增大
3. 依赖系统部署
4. 服务间通讯的成本
5. 数据的一致性
6. 系统集成测试
7. 性能监控的难度

微服务的技术栈

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

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

选型依据

1. 整体解决方案和框架的成熟度
2. 社区热度
3. 可维护性
4. 学习曲线

当前各大IT公司的微服务架构

1. 阿里Dubbo/HSF
2. 京东JSF
3. 新浪Motan
4. 当当DubboX

各微服务的框架对比

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务架构	RPC框架，但整合了ZK或Consul，实现集群环境的基本服务注册/发现	RPC框架	RPC框架	服务框架
支持Rest	是，Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是	是	是	是
支持多语言	是（Rest形式）	否	是	是	否
服务注册/发现	是（Eureka） Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查	是（zookeeper/consul）	否	否	是
负载均衡	是（服务端zuul+客户端Ribbon） zuul-服务，动态路由 云端负载均衡 Eureka（针对中间层服务器）	是（客户端）	否	否	是（客户端）
配置服务	Netflix Archaius SpringCloud Config Server集中配置	是（zookeeper提供）	否	否	否
服务调用链监控	是（zuul） Zuul提供边缘服务，API网关	否	否	否	否
高可用/容错	是（服务端Hystrix+客户端Ribbon）	是（客户端）	否	否	是（客户端）
典型应用案例	Netflix	Sina	Google	Facebook
社区活跃度	高	一般	高	一般	2017年7月才重启
学习难度	中等	一般	高	一般	低
文档丰富度	高	一般	一般	一般	高
其他	Spring Cloud Bus为我们应用程序带来了更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践公司比较多

SpringCloud入门概述

• Spring的三大模块：SpringBoot（构建），Spring Cloud（协调），Spring Cloud Data Flow（连接）

SpringCloud是什么

• 分布式系统的简化版（官方介绍）
• SpringCloud基于SpringBoot提供了一整套微服务的解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于Netflix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件
• SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统的基础设施开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线，全局所、决策精选、分布式会话等等，他们都可以用SpringBoot的开发风格做到一键启动和部署。
• 一句话概括：SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的几何体，俗称微服务全家桶

SpringCloud 和 SpringBoot 的关系

SpringBoot：专注于快速方便的开发单个个体微服务（关注微观）

SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）

• SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系

Dubbo是怎么到SpringCloud的？哪些优缺点去技术选型

目前成熟互联网架构（分布式+服务治理Dubbo）

对比

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

最大区别：

• Spring Cloud抛弃了RPC通讯，采用基于HTTP的REST方式。Spring Cloud牺牲了服务调用的性能，但是同时也避免了原生RPC带来的问题。REST比RPC更为灵活，不存在代码级别的强依赖，在强调快速演化的微服务环境下，显然更合适。
• 一句话：Dubbo像组装机，Spring Cloud像一体机
• 社区的支持与力度：Dubbo曾经停运了5年，虽然重启了，但是对于技术发展的新需求，还是需要开发者自行去拓展，对于中小型公司，显然显得比较费时费力，也不一定有强大的实力去修改源码

总结

1. 解决的问题域不一样：Dubbo的定位是一款RPC框架，Spring Cloud的目标是微服务架构下的一站式解决方案

SpringCloud的参考资料

SpringCloud的中文参考资料：https://springcloud.cc/spring-cloud-netflix.html
SpringCloud的中文API：https://springcloud.cc/spring-cloud-dalston.html
SpringCloud中国社区：http://springcloud.cn/
SpringCloud中文网：https://springcloud.cc/

版本技术选型说明

从2.2.x 和 H版 开始说起

• 以 SpringBoot 2.X版 和 SpringCloud X版
• SpringCloud Alibaba

SpringBoot 版本选择

git 源码地址：https://github.com/spring-projects/spring-boot/releases/
SpringBoot 2.0新特性：https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes/

通过上面官网发现，Boot官网强烈建议你升级到2.X以上版本。

SpringCloud 版本选择

git 源码地址：https://github.com/spring-projects/spring-cloud/wiki
官网：https://spring.io/projects/spring-cloud

Cloud 命名规则

SpringCloud的版本关系
SpringCloud采用了英国伦敦地铁站的名称来命名，并由地铁站名称字母A-Z依次类推的形式来发布迭代版本
SpringCloud是一个由许多子项目组成的综合项目，各子项目有不同的发布节奏。为了管理SpringCloud与各子项目的版本依赖关系，发布了一个清单，其中包括了某个SpringCloud版本对应的子项目版本。为了避免SpringCloud版本号与子项目版本号混淆，SpringCloud版本采用了名称而非版本号的命名，这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序。例如Angel是第一个版本，Brxton是第二个版本。
当SpringCloud的发布内容积累到临界点或者一个重大BUG被解决后，会发布一个’service releases’版本，简称SR远本，比如Greenwich.SR2 就是 Springcloud发布的 Greenwich 版本的第2个SRX版本。

SpringBoot 与 SpringCloud 之间依赖关系如何看

https://spring.io/projects/spring-cloud#overview

更详细的版本对应查看方法：https://start.spring.io/actuator/info

看不懂可以使用在线工具转化：https://tool.lu/

查看json串返回结果

所以 SpringBoot 和 SpringCloud 的最终版本：

• cloud：Hoxton.SR1
• boot：2.2.2.RELEASE
• cloud alibaba：2.1.0.RELEASE
• Java：Java8
• Maven：3.5及以上
• Mysql：5.7及以上

关于Cloud 各个组件的停更/ 升级/ 替换

由于停更引发的“升级惨案”

停更不停用

• 被动修复bugs
• 不在接受合并请求
• 不在发布新版本

明细条目

以前：

now2020：

参考资料见官网

SpringCloud：

https://cloud.spring.io/spring-cloud-static/Hoxton.SR1/reference/htmlsingle/

SpringCloud中文文档：https://www.bookstack.cn/read/spring-cloud-docs/docs-index.md

SpringBoot：

https://docs.spring.io/spring-boot/docs/2.2.2.RELEASE/reference/htmlsingle

---

如果有收获！！！ 希望老铁们来个三连，点赞、收藏、转发。
创作不易，别忘点个赞，可以让更多的人看到这篇文章，顺便鼓励我写出更好的博客