springcloud
Spring Cloud是一系列框架的有序集合，它提供了一套完整的微服务解决方案。包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。springcloud的出现对微服务技术提供了非常大的帮助。
微服务架构的特点：
1.微服务强调每个服务独立部署，保证服务于服务之间互不影响，每个服务运行在单独的进程中，实际上有自己独立的缓存、数据库、消息队列等资源。
2.服务与服务间的通讯采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中，采用二进制。
3.一个服务只关注一个特定的业务，服务与服务可以使用不同的语言和数据存储技术。
sprincloud中文网：https://www.springcloud.cc/
springcloud包含众多子项目
Eureka：在springcloud中担任注册中心，是c/s模式的架构，Eureka为闭源项目，可以使用consul、zookeeper作为注册中心。
consul: consul是一个服务发现与配置工具，与Docker容器可以无缝集成。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点。
Ribbon: ribbon从Eureka上获取服务注册信息列表，缓存到本地,在本地实现负载均衡策略。
feign: Feign客户端是一个web声明式http远程调用工具，提供了接口和注解方式进行调用。
springcloudconfig: 分布式配置中心，可以实现对配置文件的统一管理，当配置文件发生变化的时候，系统会自动更新获取新的配置。
hystrix: 服务保护框架,是springcloud的断路器组件。当服务调用在一定时间内超过默认次数，该服务的断路器会打开。
zuul: 网关适用于请求的过滤和拦截，可以实现负载均衡、路由转发、日志、权限控制、监控等。
swagger: 为了方便进行测试后台restful接口并实现动态的更新，引入swagger接口工具。自动生成接口文档界面，支持在界面测试api接口功能
sleuth: 它在整个分布式系统中能跟踪一个用户请求的过程(包括数据采集，数据传输，数据存储，数据分析，数据可视化)
架构的演变过程：
传统架构-----分布式架构----SOA架构----微服务架构
1.传统架构也就是单点应用，业务没有进行拆分，都写同一个项目里面，一般是适合于个人或者是小团队开发。这种架构模式的缺点是，一旦有一个模块不可用，可能会影响整个项目。
2.分布式架构，将传统的单体项目以项目模块进行拆分，例如拆分为会员项目、订单项目、支付项目、优惠券项目等，从而降低耦合度，这种架构模式慢慢适合于互联网公司规模人数开发。
3.SOA架构，俗称服务化，将共同的业务逻辑抽取出来形成一个服务，提供给其他服务接口进行调用，服务与服务之间调用使用rpc远程调用技术。SOA架构的底层通过WebService和ESB（xml与中间件混合物）实现。
4.微服务架构，倡导应用程序设计成多个独立、可配置、可运行和可微服务的子服务，比SOA架构粒度更加精细，目的是提高效率。
Eureka注册中心的搭建：
1.创建一个maven项目，在pom文件中加入eureka-server依赖
eureka服务依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
2.配置文件
server:
port: 8100
eureka:
instance:
hostname: 127.0.0.1
client:
serviceUrl:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
register-with-eureka: false
fetch-registry: false
3.创建启动类
@SpringBootApplication
@EnableEurekaServer
public class AppEureka {
public static void main(String[] args) {
SpringApplication.run(AppEureka.class, args);
}
}
4.在浏览器输入eureka的ip地址和端口号可访问eureka界面
127.0.0.1:8100
eureka集群环境搭建：
在微服务中，注册中心非常核心，可以实现服务治理，一旦注册出现故障，可能会导致整个微服务无法访问。Eureka高可用实际上将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组相互注册的服务注册中心，从而实现服务清单的互相同步，达到高可用效果。
只需要客户端集成eureka集群就可以实现eureka的高可用了。
1.建立多个eureka服务端，改为不同的端口即可
2.分别启动eureka服务
可以看到eureka集群中的节点互相注册，eureka与zookpper的不同之处在于eureka保证服务的可用性
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP
eureka与zookeeper的区别：
1.eureka在设计时保证可用性，各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用。
2.zookeeper保证一致性，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。这便是优先使用eureka的原因。
eureka的自我保护机制：
默认情况下eurekaClient会定时向eurekaServer端发送心跳包
如果eurekaServer在一定时间内没有收到eurekaClient发送的心跳，默认时间为90秒，那么便会从注册列表中将该服务信息剔除，但是在短时间内，如果丢失了大量心跳，这时候Eureka Server会开启自我保护机制，不会剔除该服务
Eureka的自我保护机制是为了防止在网络不通的情况下，eurekaClient依然可以正常运行，不会剔除服务
本地开发的时候建议关闭自我保护机制，生产环境下开启自我保护机制。
