SpringCloud微服务

微服务架构：微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中进行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

微服务架构的九大特征：

　　1、服务组件化

    　　组件：是一个可以独立更换和升级的单元，而不影响其他单元

　　2、按业务组织团队

   　　 按业务线的方式进行拆分

　　3、做“产品”的态度

   　　 每个小团队对其产品的整个生命周期负责，而不是以项目的模式，已完成开发与交付并将成果交接给维护者以最终目标

　　4、智能端点与哑管道

    　　在单体应用中，组件间通过函数调用的方式进行交互协作，而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改

　　　成rpc方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以我们需要更粗粒度的通信协议

    　　（1）使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发

    　　（2）通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件

　　5、去中心化治理

　　6、去中心化管理数据

    　　让每一个服务来管理其自有的数据库

　　7、基础设施自动化

　　8、容错设计

　　9、演进式设计

 

springboot 用于构建微服务的基础框架

 

高可用：

　　高度可用性，用平均故障时间MTTF来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。

服务注册：

　　在服务治理框架中，通常都会构建一个服务注册中心，每个服务单元向注册中心提供的服务，将主机与端口号，版本号，通信协议等一些附加信息告知注册中心，注册中心按服务名分类组织服务清单。

 

服务发现：

　　由于在服务治理框架下运行，服务间的调用不再通过指定具体的实例地址来实现，而是通过向服务名发起请求调用实现。所以，服务调用方在调用服务提供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中心咨询服务，并获取所有服务的实例清单， 以实现对具体服务实例的访问。

 

高可用服务注册中心：

　　实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的同步，达到高可用的效果。

 

服务发现与消费：

　　服务发现的任务由Eureka客户端来完成，而服务消费的任务由Ribbon完成，Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的

　　RibbonServerList服务端列表去轮询访问以达到负载均衡的作用。当Ribbon与Eureka联合使用时，Ribbon的服务实例清单 RibbonServerList会被DiscovEnableNIWServerList

 

Spring Cloud五大核心组件：

　　一、Eureka：服务注册中心，维护一个注册表，包含了各个服务所在机器的ip地址和端口号

　　二、Feign：使用@FeignClient注解在服务上声明实际调用的服务，Feign Client会在底层根据你的注解，使用动态代理跟你指定的服务建立连接、构造请求、发起靕求、

　　　　获取响应、解析响应，等等

　　三、Ribbon：提供了客户端对服务调用的负载均衡，使用Round Robin轮询算法

　　四、Hystrix：Hystrix是隔离、熔断以及降级的一个框架

　　五、Zuul：为微服务应用程序提供服务路由功能。Zuul是代理服务请求的服务网关

 

　　参考：

　　

　　Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里

　　Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台

　　Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求

　　Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题

　　Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务