spring cloud

项目参考：distributed_project_cluster_demo / distributed_project_demo

一、什么是微服务

马丁福勒说微服务没有统一的定义和标准，提倡将传统的单体应用服务，
按业务、按功能拆分成多个各自独立的微小的子服务，每个子服务能独立部署、
独立运行类似进程、可以拥有自己独立的数据库DB，
子服务之间通过http rest api 通信或者使用RPC远程过程调用通信，
相互协作完成业务逻辑 。
// 微服务之间的通信手段：
// http rest 通信，spring cloud 框架 // Feign底层也是通过rest通信
// RPC Remote Procedure Call 远程过程调用，dubbo 框架/dubbox/HSF

二、什么是微服务架构

微服务架构是一种设计思想、架构模式，从宏观来看，他是由多个微服务构成，
各微服务之间相互通信完成业务逻辑。
将单体应用（单体架构）按照业务维度垂直拆分，得到是SOA架构的系统，
对SOA架构的系统再进行按照功能维度水平拆分，拆分成诸如网关层、业务逻辑层、数据访问层、
DB存储层等微服务系统，水平拆分得到的是水平分层架构的系统，
垂直拆分+水平拆分=微服务架构，在微服务架构的基础上，如果对一些通用的服务，
诸如注册中心、配置中心、路由网关、熔断器等继续下沉为独立的服务，
就形成服务网格架构service mesh。
// 单体架构：app-->nginx-->war-->DB 需要集群时，将war部署到多台tomcat
// 水平分层同步架构：app-->nginx-->网关层-->业务逻辑层-->数据访问层-->DB 
// 水平分层异步架构：app-->nginx-->网关层-->消息队列MQ-->业务逻辑层-->数据访问层-->DB
// 垂直分层架构、SOA架构：app-->nginx-->多个独立服务，通过企业总线ESB通信
// 垂直+水平拆分微服务架构、对微服务架构的公共模块继续下沉为服务，演变成服务网格架构（service mesh）

三、微服务的优缺点，在项目开发中碰到的坑

优点：
1、将一个单体服务拆分成多个独立的微小服务，每个微服务只做自己关心的一件事，方便开发团队分工协作，做自己擅长的模块，提高开发效率。
2、各个微服务独立部署独立运行、拥有自己独立的DB，可以按照需要单独为某个微服务进行集群，提高可用性。
3、微服务模块之间可以灵活的相互调用，如果有新的业务模块，只需要增加和新业务相关的微服务，其他需要用到的服务，可以调用之前已有的微服务提供服务。

缺点：
1、多个独立的微服务，相互通信完成业务逻辑，增加了通信的成本和开放难度，由于网络原因平均响应延迟比单体服务长。
2、微服务只关注自己独立的业务，一些公共的业务逻辑，难免出现重复代码。
3、微服务数量较多，且都可以各种独立部署，增加了运维方面的难度和成本（系统集成、性能监控、数据一致性问题）。

碰到的坑：
1、springboot、springcloud版本更新快，不同的版本有一定的差异，导致之前能好好工作的组件功能，升级版本后可能就不行了。新版本需要重新调整代码。
2、RestTemplate 的postForObject(url,param,clazz) param：pojo对象、hashmap/linkedHashMap传递参数，提供者那边收不到参数，
param需要转换成json，或者使用linkedMultiValueMap来传递。
3、在eureka服务注册时，application.name应用名最好全部小写或者全部大写，不能使用下划线，可以使用中划线。使用下划线会导致服务发现时出现找不到的情况。

四、springcloud和dubbo有什么区别

1、springcloud微服务之间采用http rest api的方式进行通信，dubbo采用RPC方式通信。
2、springcloud的社区活跃度比dubbo高。dubbo中间停滞了5年没有人维护更新。
3、springcloud提供的是分布式环境下微服务架构的整体解决方案，一站式服务，技术支持完善，dubbo只是一个RPC 远程过程调用的一个通信框架而已。
4、springcloud的注册中心采用Eureka，dubbo的注册和服务发现采用的是Zookeeper，
zookeeper是CP模型，eureka是AP模型的系统，性能高于zookeeper。
// 当前各大IT公司的微服务架构：
// 阿里dubbo，第二代HSF
// 京东JSF
// 新浪微博motan
// 当当网的dubbox

五、微服务技术栈有哪些

1、服务开发：springboot、springcloud、springmvc
2、服务注册与发现：客户端的发现组件：eureka、zookeeper，服务端的发现组件：consul、nginx
3、负载均衡：ribbon、feign、nginx
4、服务熔断器、服务降级：hystrix、envoy
5、路由网关：zuul、springcloud gateway、nginx/kong、tyk、node.js
// zuul的IO模型是BIO、springcloud gateway是netty，nginx/kong是epoll,tyk是AIO、node.js是AIO，AIO的底层采用的是netty，netty的底层采用的epoll
6、配置中心：spring-cloud-config
7、服务调用：rest、rpc、grpc
8、服务部署：docker
9、数据流开发包：springcloud stream
10、事件消息总线：springcloud bus
// 客户端的发现组件：eureka、zookeeper
// 服务端的发现组件：consul、nginx
// 服务发现组件的功能：
// 1、服务注册表：是一个记录当前可用实例的网络信息的数据库，是服务发现机制的核心，提供查询API和管理API，使用查询API获得可用的服务实例，使用管理API实现注册和注销。
// 2、服务注册
// 3、健康检查

六、springboot和springcloud请你谈谈对他们的理解

1、springboot是一个快速开发框架，继承了spring的优秀基因，
使我们对spring的使用变得更加简单，取消了繁杂的xml配置，采用纯java注解的方式，
对各种应用场景进行封装，自动装配，通过maven子工程的方式快速整合第三方框架，
且内嵌了web容器，通过主程序main方法启动，方便了开发，方便了部署，方便了配置，方便了监控。springboot虽然很优秀很方便了，但也有他的不足，缺少像eureka、zookeeper这样注册与发现的解决方案，
缺少像spring security、shiro这样的外围权限控制解决方案、缺少外网的服务监控解决方案，
比如hystrix熔断监控，他仅仅是一个微框架，距离微服务框架还有点距离，他的这些不足，
统统可以通过springcloud微服务框架来弥补。
2、springcloud是基于springboot的一个微服务框架，提供分布式环境下的整体解决方案，
是一系列框架的有序集合，
诸如：路由网关、服务注册与发现、服务熔断降级、负载均衡、配置管理、微代理、控制总线等。
/**
springcloud的5大核心组件：
1、路由网关：zuul
2、断路器、服务降级：hystrix
3、负载均衡：ribbon
4、配置中心：springcloud config
5、服务注册与发现：eureka
**/

七、什么熔断、什么降级

1、熔断就类似于保险丝的概念，在互联网系统中下游服务由于访问压力过大从而影响整体服务失败或变慢，上游服务为了保护系统的整体可用性，可以暂时切断对下游服务的调用。
2、降级就是服务降级，由于下游服务被熔断，或被迫关闭了其中某些微服务，对于整体服务来说，就是服务降级了。这种降级的做法，为其他微服务节省出来资源，保证了整体系统的可用性。
3、熔断降级组件，我使用的是hystrix，引入hystrix相关依赖，开启@EnableCircuitBreaker熔断机制，一种方案是在服务提供者的controller层处理，通过@HystrixCommand(fallbackMethod="处理熔断的方法")注解的方式实现。经这个注解修饰的方法，会被hystrix dashboad 监控到。这种方案的缺点是业务逻辑的方法和熔断处理的方法，会耦合在一起，并且引起方法膨胀，一个业务逻辑方法就对应一个熔断处理的方法。
另一种方案：是在消费者的接口层面处理，服务提供者正常提供服务，当我们去消费时，如果请求压力过大，这时产生的问题，就该在消费方处理，这样就能使业务逻辑和熔断处理不高耦合。在消费者的接口层，通过实现FallbackFactory接口，以泛型的方式，对某个服务的接口进行服务降级处理，重写该服务接口的所有方法，加入熔断处理的逻辑。这里需要注意的是，这个实现FallbackFactory接口的类对象必须放在IOC容器中，即通过@component注解标识。在消费方通过Feign的方式调用服务时，通过@FeignClient注解来完成。@FeignClient(name="CLOUD-PROVIDER",fallbackFactory = xxxFallbackFactory.class) ，所有的方法的熔断处理统统通过fallbackFactory工厂来处理。
// Feign是通过接口+注解 来实现客户端的负载均衡请求的响应，消费方这里没有具体的业务实现，消费方通过调用服务提供方来获得服务实现，故Feign在接口上通过@FeignClient的方式来指定调用哪个微服务的服务和指定使用哪个fallbackFactory来处理服务降级。Feign底层通过rest去和服务提供者通信，故接口的方法上，需要做好与服务提供者相关的映射请求，springcloud对feign进行了使之支持springmvc注解。

当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游。一旦下游服务C因某些原