什么是微服务

简而言之 : 微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统的.其中每个小型服务都运行在自己的进行中,并经常采用HTTP资源API
这样轻量的机制来相互通信.这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署.这些微服务可以使用不同的语言来编写,并且可以使用不同的数据
存储技术.对这些微服务我们仅做最低限度的集中管理.

1. 每个微服务可独立运行在自己的进程里;
2. 一系列独立运行的微服务共同构建起了整个系统;
3. 每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如 : 订单管理,用户管理等.
4. 微服务之间通过一些轻量的通信机制进行通信,例如通过REST API或者RPC的方式进行调用.
5. 全自动部署机制.

1. 易于开发和维护;
	一个微服务只关注一个特定的业务功能,所以它的业务清晰,代码量较少.开发和维护单个微服务相对是比较简单的.而整个应用是由着若干个微服务构建而成的.所以
	整个应用也会维持在可控状态.
2. 启动较快;
	单个微服务代码量较少,所以启动会比较快.
3. 局部修改容易部署;
	单体应用只要修改,就得重新部署整个应用,微服务解决了这样的问题.一般来说,对某个微服务进行修改,只需要 重新部署这个服务即可.
4. 技术栈不受限;
	在微服务中,我们可以结合项目业务及团队的特点,合理的选择技术栈.例如某些服务可使用 关系型数据库MySQL;某些微服务有图形计算的需求,我们可以使用Neo4j;甚至可以
	根据需要,部分微服务使用java开发,部分微服务使用NodeJS进行开发.
5. DevOps

1. 运维要求较高;
	更多的服务意味着更多的运维投入.在单体架构中,只需要保证一个应用的正常运行;而在微服务中,需要保证几十甚至几百个服务的正常运行与协作,这给项目的运维带来了很大挑战.
2. 分布式的复杂性;
	使用微服务构建的是分布式系统.对于一个分布式系统,系统容错,网络延迟,分布式事务等都给我们带来了很大的挑战.
3. 接口调整成本高;
	微服务之间通过接口进行通信.如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整.
4. 重复劳动.
	很多服务可能会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复.

1. 单一职责原则;
2. 服务自治原则;
3. 轻量级通信原则;
4. 接口明确原则.

	当一台服务器请求发送到另一台服务器,另一台服务器由于宕机无法响应,这样请求的服务器会一直发送请求,会堆积大量的线程和进程,当堆积到一定程度以后系统资源被
消耗殆尽,这样这台服务器也就宕机了,如果其他服务器访问这台服务器也会以此类推的出现无法响应,导致请求服务器等待响应,无法获取结果,这样一台服务器接着一台服务器
宕机,形成雪崩效验.	

1. 为请求设置超时
	通过网络请求其他服务时，都必须设置超时。正常情况下，一个远程调用一般在几十毫秒内就能得到响应了。如果依赖的服务不可用，或者网络有问题，响应时间将会变得很长（几十秒）。
	通常情况下，一次远程调用对应着一个线程/进程。如果响应太慢，这个线程/进程就得不到释放。而线程/进程又对应着系统资源，如果得不到释放的线程/进程越积越多，服务资源就会被耗尽，从而导致服务不可用。
	因此，必须为每个请求设置超时，让资源尽快地得到释放。
	 
2. 使用断路器
	试想一下，如果家庭里没有断路器，电流过载了（例如功率过大、短路等），电路不断开，电路就会升温，甚至是烧断电路、起火。有了断路器之后，当电流过载时，会自动切断电路（跳闸），从而保护了整条电路与家庭的安全。当电流过载的问题被解决后，只要将关闭断路器，电路就又可以工作了。
	同样的道理，当依赖的服务有大量超时时，再让新的请求去访问已经没有太大意义，只会无谓的消耗现有资源。譬如我们设置了超时时间为1秒，如果短时间内有大量的请求（譬如50个）在1秒内都得不到响应，就往往意味着异常。此时就没有必要让更多的请求去访问这个依赖了，我们应该使用断路器避免资源浪费。
	断路器可以实现快速失败，如果它在一段时间内侦测到许多类似的错误（譬如超时），就会强迫其以后的多个调用快速失败，不再请求所依赖的服务，从而防止应用程序不断地尝试执行可能会失败的操作，这样应用程序可以继续执行而不用等待修正错误，或者浪费CPU时间去等待长时间的超时。断路器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
	断路器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。	

为开发人员提供了快速构建分布式系统中的一些通用模式,是基于SpringBoot的一整套实现微服务的框架.他提供了微服务开发所需的配置管理 ,服务发现,短路器,智能路由,微代理,控制总线,全局锁,决策竞选,分布式会话和集群状态管理等组件.

	就是我们通常意义上的配置中心.Spring Cloud Config把应用原本放在本地文件的配置抽取出来放在中心服务器,本质是配置信息从本地迁移到云端.
	从而能够提供更好的管理,发布能力.
	Spring Cloud Config分服务端和客户端,服务端负责将git(svn)中存储的配置文件发布成REST接口,客户端可以从服务端REST接口获取配置.但客户端并不能主动感知到配置
	的变化,从而主动去获取新的配置,这需要每个客户端通过POST方法触发各自的/refresh.

	提供在分布式环境下的服务发现,服务注册的功能.

	该项目是Spring Cloud的子项目之一,主要内容是对Netflix公司一系列开源产品的包装,它为Spring Boot应用提供了自配置的Netflix OSS整合.
	通过一些简单的注解,开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统.它主要提供的模块包括 : 服务发现 (Eureka), 断路器(Hystrix), 智能路由(Zuul)
	,客户端负载均衡(Ribbon)等.
		Netflix Eureka : 云端负载均衡,一个基于REST的服务,用于定位服务,以实现云端的负载均衡和中间层服务器的故障转移.
		Netflix Hystrix : 容错管理工具,旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力.
		Netflix Zuul : 边缘服务工具,是提供动态路由,监控,弹性,安全等边缘服务.
		Netflix Archaius : 配置管理API,包含一系列配置管理API,提供动态类型化属性,线程安全配置操作,轮询框架,回调机制等功能.

		断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打卡开关),并在远程服务恢复时自动恢复(闭合开关)的设施.
		断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关),并在远程服务恢复时自动恢复(闭合开关)的设施,Spring Cloud通过Netflix组件
		的Hystrix组件提供断路器,资源隔离与自我修复功能.

: 事件,消息总线,用于在集群(例如,配置变化事件)中传播状态变化,可与Spring Cloud Config联合实现热部署;

: 通过Oauth2协议帮到服务到CloudFoundry,CloudFoundry是VMware推出的开源PaaS平台.

	 : 日志收集工具包,冯总了Dapper,Zipkin和HTrace操作.

	 : 大数据操作工具,通过命令行方式操作数据流.

	: 安全工具包,为你的应用程序添加安全控制,主要是指OAuth2.

	: 封装了Consul操作,consul是一个服务发现与配置工具,与Docker容器可以无缝集成.

	: 操作Zookeeper的工具包,用于使用zookeeper方式的服务注册和发现.

	: 数据流操作开发包,封装了与Redis,Rabbit,Kafka等发送接收消息.

	: 基于SpringBoot CLI,可以让你命令行方式快速建立云组件.

	1 : 约定优于配置;
	2 : 开箱既用,快速启动;
	3 : 适用于各种环境
	4 : 轻量级组件;
	5 : 组件支持丰富,功能齐全.
	6 : 选型中立.