代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中分布式配置中心组件Spring Cloud Config支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持，可以方便的对微服务各个环境下的配置进行实时更新、集中式管理。
Spring Cloud Config分为Config Server和Config Client两部分。
Config Server负责读取配置文件，并且暴露Http API接口，Config Client通过调用Config Server的接口来读取配置文件。
使用方式：
1）添加pom依赖
2）配置文件添加相关配置
3）启动类添加注解@EnableConfigServer
zuul：是Netflix的，是基于servlet实现的，阻塞式的api，不支持长连接。
gateway：是Spring Cloud自己研制的微服务网关，是基于Spring5构建，能够实现响应式非阻塞式的Api，支持长连接。
针对不同场景分别有不同的解决方案，如下所示：
1、硬件故障：多机房容灾，跨机房路由，异地多活等。
2、流量激增：采用自动扩缩容以应对突发流量，或在负载均衡器上安装限流模块。
3、缓存穿透：缓存预加载、缓存异步加载等。
4、程序BUG：修改程序bug、及时释放资源等。
5、同步等待：资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池；不可用服务调用快速失败一般通过超时机制，熔断器以及熔断后降级方法等方案实现。
流量控制的具体措施包括：
1）网关限流。
2）用户交互限流，采用加载动画，提高用户的忍耐等待时间；提交按钮添加强制等待时间机制。
3）关闭重试。
服务调用者降级服务的措施包括：
1）资源隔离，主要是对调用服务的线程池进行隔离。
2）对依赖服务进行分类。
3）不可用服务的调用快速失败。
同步通讯
RPC、REST等，比如Dobbo通过RPC远程过程调用；Spring Cloud通过REST接口json调用等。
异步通讯
消息队列，考虑消息的可靠传输、高性能，以及编程模型的变化等，比如：RabbitMq、ActiveMq、Kafka等。
Ribbon添加maven依赖spring-starter-ribbon使用@RibbonClient(value="服务名称") 使用RestTemplate调用远程服务对应的方法。
Feign添加maven依赖 spring-starter-feign服务提供方提供对外接口 调用方使用在接口上使用@FeignClient("指定服务名")。
Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
1、启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2、服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3、调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应，当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）。
断路器有完全打开状态（Open）：一段时间内达到一定的次数无法调用并且多次监测没有恢复的迹象。断路器完全打开，那么下次请求就不会请求到该服务。
半开（Half-Open）：短时间内有恢复迹象断路器会将部分请求发给该服务，正常调用时断路器关闭。
关闭（Close）：当服务一直处于正常状态 能正常调用。
分布式架构中断路器模式的作用基本类似的，当某个服务单元发生故障，类似家用电器发生短路后，通过断路器的故障监控，类似熔断保险丝，向调用方返回一个错误响应，不需要长时间的等待。这样就不会出现因被调用的服务故障，导致线程长时间占用而不释放，避免了在分布式系统中故障的蔓延。
Spring Cloud优点：
1）服务拆分粒度更细，有利于资源重复利用，有利于提高开发效率，每个模块可以独立开发和部署、代码耦合度低；
2）可以更精准的制定优化服务方案，提高系统的可维护性，每个服务可以单独进行部署，升级某个模块的时候只需要单独部署对应的模块服务即可，效率更高；
3）微服务架构采用去中心化思想，服务之间采用Restful等轻量级通讯，比ESB更轻量，模块专一性提升，每个模块只需要关心自己模块所负责的功能即可，不需要关心其他模块业务，专一性更高，更便于功能模块开发和拓展；
4）技术选型不再单一，由于每个模块是单独开发并且部署，所以每个模块可以有更多的技术选型方案，如模块1数据库选择mysql，模块2选择用oracle也是可以的；
5）适于互联网时代，产品迭代周期更短。系统稳定性以及性能提升，由于微服务是几个服务共同组成的项目或者流程，因此相比传统单一项目的优点就在于某个模块提供的服务宕机过后不至于整个系统瘫痪掉，而且微服务里面的容灾和服务降级机制也能大大提高项目的稳定性；从性能而言，由于每个服务是单独部署，所以每个模块都可以有自己的一套运行环境，当某个服务性能低下的时候可以对单个服务进行配置或者代码上的升级，从而达到提升性能的目的。
Spring Cloud缺点：
1）微服务过多，治理成本高，不利于维护系统，服务之间接口调用成本增加，相比以往单项目的时候调用某个方法或者接口可以直接通过本地方法调用就能够完成，但是当切换成微服务的时候，调用方式就不能用以前的方式进行调试、目前主流采用的技术有http api接口调用、RPC、WebService等方式进行调用，调用成本比单个项目的时候有所增加；
2）分布式系统开发的成本高（容错，分布式事务等）对团队挑战大
2）独立的数据库，微服务产生事务一致性的问题，由于各个模块用的技术都各不相同、而且每个服务都会高并发进行调用，就会存在分布式事务一致性的问题；
3）分布式部署，造成运营的成本增加、相比较单个应用的时候，运营人员只需要对单个项目进行部署、负载均衡等操作，但是微服务的每个模块都需要这样的操作，增加了运行时的成本；
4）由于整个系统是通过各个模块组合而成的，因此当某个服务进行变更时需要对前后涉及的所有功能进行回归测试，测试功能不能仅限于当个模块，增加了测试难度和测试成本；
总体来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的微服务框架，目前很多企业开始用微服务，Spring Cloud的优势是显而易见的。
Eureka：服务注册与发现，Eureka服务端称服务注册中心，Eureka客户端主要处理服务的注册与发现。
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求url地址，发起请求。
Ribbon：负载均衡，服务间发起请求时基于Ribbon实现负载均衡，从一个服务的多台机器中选择一台。
Hystrix：提供服务隔离、熔断、降级机制，发起请求是通过Hystrix提供的线程池，实现不同服务调用之间的隔离，避免服务雪崩问题。
Zuul：服务网关，前端调用后端服务，统一由Zuul网关转发请求给对应的服务。
单个轻量级服务一般为一个单独微服务，微服务讲究的是专注某个功能的实现，比如登录系统只专注于用户登录方面功能的实现，讲究的是职责单一，开箱即用，可以独立运行。
微服务架构系统是一个分布式的系统，按照业务进行划分服务单元模块，解决单个系统的不足的问题并满足越来越复杂的业务需求。
马丁福勒（Martin Fowler）
就目前而言，对于微服务业界并没有一个统一的、标准的定义。
但通常而言，微服务架构是一种架构模式或者说是架构风格，它提倡将单一应用程序划分成一组小的服务。
每个服务运行在其独立的自己的进程中服务之间相互配合、相互协调，为用户提供最终价值。
服务之间采用轻量级通信。
每个服务都围绕具体业务进行构建，并能够独立部署到生产环境等。另外应尽量避免统一的、集中的服务管理机制。
通俗的来讲：
微服务就是一个独立且职责单一的服务应用程序。在IntelliJ IDEA工具中可以使用maven管理工具开发每个独立的module组件，具体就是使用Spring boot框架开发一个功能模块，该功能模块只处理单一专业的业务逻辑。
分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。
举例：用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。
简单来说就是分布式事务用于在分布式系统中保证不同节点之间的数据一致性。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
