Spring Cloud学习笔记（一）概要
什么是微服务
微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。
单体应用架构
单体应用架构概念
一个应用中包含了应用程序的所有功能（比如：页面，代码，配置等），把应用打成一个war或jar包部署到Tomcat中，通常称为单体应用架构。
单体架构图
可以看到单体架构就是把所有的东西都揉到一起去了，它的优缺点如下：
优点
- 易于开发&测试：单个应用包含所有功能，不涉及多个应用的互联互调，便于在团队之间开发与测试。
- 易于部署：只需将单个应用打成war或jar包，进行部署到Tomcat即可，运维起来比较方便。
- 易于整体扩展：当应用负载压力大时，将这个应用复制几份，分别部署在不同的服务器上，再通过负载均衡即可提高应用的并发能力。
缺点
- 复杂性高：由于是单个应用，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
- 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
- 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
微服务架构
微服务架构概念
开头已经说明了微服务架构的概念，就是把项目分为不同的业务模块，每个模块都作为一个单独的应用来开发，既然是单独的项目那就可以使用不同的语言，不同的技术，不同的数据存储系统等等。如果一个业务模块需要另一个业务模块的功能的话，怎么办呢？采用轻量级RESTful API通信进行交互即可。然后采用一个集中式管理工具来管理这些个独立模块的应用，这些独立的模块就称之为微服务。springcloud就是提供了一站式管理技术的管理工具。至于如何管理的，之后会有说明。
微服务架构图
通过这张图可以说明微服务的扩展优势。
优点
- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快
- 局部修改容易部署：单一应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
- 按需伸缩：可根据需求，实现细粒度的扩展。
缺点
- 运维要求高：更多的服务意味着要投入更多的运维。
- 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
- 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
微服务架构总结：
- 微服务的核心就是将传统的单一应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事。
- 在 IDEA 工具中使用Maven构建的一个个独立的 Module ，也就是使用Spring Boot 开发的一个个小模块就是一个个微服务，将专业的事交给专业的模块来做。比如一个大型项目可能有上百个微服务，将这些微服务集中起来构成一个大的系统，对外暴露服务进行调用与使用。
- 从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
微服务架构技术栈
|
微服务技术维度
|
技术实现
|
|
服务开发
|
Spring Boot、Spring、Spring MVC等
|
|
服务注册与发现
|
Eureka、Zookeeper等
|
|
服务调用
|
Rest、RPC等
|
|
服务熔断器
|
Hystrix、Envoy等
|
|
负载均衡
|
Ribbon、Nginx等
|
|
服务接口调用(客户端调用服务的简化工具)
|
Feign等
|
|
消息队列
|
Kafka、ActiveMQ等
|
|
服务配置中心管理
|
Spring Cloud Confifig等
|
|
服务路由（API网关）
|
Zuul等
|
|
服务监控
|
Zabbix、Nagios等
|
|
全链路追踪
|
Zipkin，Brave等
|
|
服务部署
|
Docker、OpenStack等
|
|
数据流处理
|
Spring Cloud Stream（Redis,Rabbit,Kafka等发送接收消息）
|
|
事件消息总线
|
Spring Cloud Bus
|
以上列出了部分技术栈，更多信息请看官网，有同学说我看英文很难受，嘻嘻，来这里，springcloud中文网
以上的技术栈，后续我在学习的过程中会一一介绍的。
什么是 Spring Cloud
所以，Spring Cloud，基于 Spring Boot 提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件。NetFlix是美国的一家网络影音公司，差不多就像腾讯视频，爱奇艺这样的，他们有一些很牛X的分布式开源组件，spring对他们的开源组件进行了进一步的封装，又集合了其他的优秀的开源组件，就变成了现在的这个微服务架构管理工具。
来张图：
上图包含了技术栈中的部分内容，先简单解释一下：
Zuul 路由网关：网关大家都了解，通过一个子网的信息都走网关，这里如果我们为微服务架构配置一个网关，那么访问整个系统所有的微服务的请求，都要先经手网关，然后再转发给各个微服务，有什么用呢？那就要问一问朋友们，拦截器有什么用呢？Zuul就是整个系统的一个拦截器，在这里搞一个权限控制，每个微服务都拦的到，它不香吗？
Eureka 服务注册中心:这个是啥呢？大家思考这么个问题，我们搞了很多个微服务，微服务之间要通信吧？要相互之间用对方的功能。不通信搞什么微服务对不对？那通信要不要对方地址？怎么找对方地址？曾记得很久很久以前，也许是民国时代，那时候打电话还不能直接打给对方，要打到一个中转站，然后告诉人家，我要找陈冠希，人家就帮你转给了陈冠希，这样你跟陈冠希就能友好的交流。那它为什么可以转呢？明显这个转发中心有所有人的联系方式，当来一个电话说我要找谁谁谁，就给你转过去。服务注册中心是个啥？就是一个记录各个微服务地址的一个集中站。每个微服务把自己信息注册到注册中心，然后，A微服务想要访问B微服务就去注册中心找B注册的信息，从而就知道B在哪里了。至于这么做的好处，我们在学习Eureka那一章节再讨论。
Hystrix 熔断器：微服务之间会相互调用，这个调用不单单是两级或者一对一，也许会出现A调用B，B调用C，C还调用了D，E，F等等。假如此时D挂掉了，咋办？C得等着，C等着B就得等着，B等着A就得等着。这时候又来一个Q调用B，Q也得等着，巴拉巴拉。于是出现了挂了一个D，慢慢整个系统都挂掉了。这就是微服务调用可能产生的雪崩效应。熔断器是啥？家里电路短路时，电流过大会烧坏保险丝，保证不会因此造成更多的危险。这叫及时止损。熔断器就是这样，D挂掉了，访问D的微服务等不到D的回应，就假装D有问题了，然后就不等了，直接返回一个预设好的熔断信息。及时止损。这里说的是客户端熔断，还有服务端熔断，之后讨论。
Spring Cloud Confifig配置中心：这个概念简单，就是把配置文件集中管理不写在本地了，应用启动时去配置中心拿配置信息。目的是为了配置文件的管理。
服务跟踪：这是一个追踪微服务的日志收集工具包。
SpringBoot和SpringCloud的关系
- Spring Boot 可以离开 Spring Cloud 单独使用开发项目，但是Spring Cloud离不开SpringBoot，属于依赖的关系.
- Spring Boot 专注于快速方便的开发单个个体微服务，Spring Cloud 关注全局的服务治理框架。
- Spring Cloud 是关注全局的微服务协调整理治理框架，它将 Spring Boot 开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。