微服务架构及其原理3.1注册中心3.2.1
微服务架构是业界非常流行的分布式服务治理方案，解决了原来多个服务之间通过rpc框架进行调用和通信的问题。是业务从单体架构发展到集群架构，再到配备多种服务的集群组织。它带来的好处是
1 将业务拆分成多个微服务，提高业务之间的隔离性，增强系统面对高并发大流量时的稳定性。系统各个模块的拆分，保证了各个模块的稳定性，可以让业务调用更全面，业务解耦更充分
2 系统可以横向规模化发展，各个团队之间的分工也更加明确。
当然：在微服务时代，我们面临着很多需要解决的问题，比如：系统复杂度增加、服务依赖、服务性能监控、全链路日志、容灾、断路器、限流等。
本文将从几个方面介绍微服务架构的原理
1 微服务原理 2 微服务框架介绍与选择 云架构及其原理 3.1 注册中心 3.2 熔断与限流 3.4.5 Zuul1 微服务原理
这里我们来看一个流程，以电商网站下单为例。原来的流程是创建订单——调用库存——加点——发货。如果原本的逻辑是按照这个流程来的，如果中间任何一个环节出现问题，都可能导致用户购买不成功。加入微服务开发之后，就是通过这一系列的逻辑来订购服务-库存服务-点服务
通过这样的服务化，保证了各项服务的稳定运行
2常见的微服务架构和框架
微服务框架一般包括、、微服务本身等，现在比较流行的微服务框架有cloud和dubbo。cloud出自家族，提供一整套分布式服务治理方案，从注册中心到微服务、监控、限流等，阿里的dubbo只做服务治理。云端提供更多功能
由于dubbo是二进制传输，占用带宽会少（基于netty等）是http协议传输，带宽会比较多。同时，如果使用http协议（http+api），一般会使用JSON消息服务器运维外包，消耗会更大。http协议的通信真的会成为应用负载的瓶颈点吗（云端不绑定http+JSON，如果有需要也可以使用高效的RPC和序列化协议作为替代）
dubbo的开发难度更大服务器运维外包，因为dubbo的jar包依赖（在代码层面存在强依赖）是很多大型项目无法解决的问题。
dubbo的注册中心可以选择zk、redis等，注册中心只能从体系结构上使用或者自己开发简单程序：.cloud程序结构简单，"+"=-cloud.dubbo相对复杂,url,,,,,, 从dubbo序列化的性能来看：dubbo的网络开销比cloud略小，但是可以通过压缩、二进制、缓存、段降级等方式解决开发难度：神奇dubbo的坑是jar包依赖，开发阶段难度极大，jar升级是个大问题，比较自由，但带来的问题是不能“强行约束接口规范”，建议解决它以行政方式
3 云架构及其原理 3.1 注册中心
spring的注册中心有两者Eureka 和consul 以Euraka为例子
Eureka Client：负责将这个服务的信息注册到Eureka Server中
Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号
3.2 假装
原本微服务间的通信需要写大段通信代码，并且很有可能踩坑。通过feign可以很简单的调用微服务。
3.3
通过feign调用微服务，但是某个微服务部署在多台服务器上，这个时间需要挑选一台进行访问。而ribbon就是这个挑选机制。
Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法，按照顺序一圈圈轮训
它与feign和注册中心的关系如下图
3.4
一个系统中有很多微服务和很多组件。这么多服务互相调用，如果不做保护，如果一个服务失败，就会引起连锁反应，导致其他服务也挂掉。比如点服务挂了，那么订单服务的所有线程都会卡在请求点服务，所有线程都无法工作，导致订单服务瞬间挂掉，订单的所有请求别人的服务会卡住，无法响应。
会有很多小线程池。比如订单服务请求库存服务是一个线程池，请求存储服务是一个线程池，请求点服务是一个线程池。线程池中的每个线程仅用于请求该服务。如果红利服务宕机，只会影响请求红利服务的线程池，对其他服务的调用仍然有效。
：但是如果信用服务都挂了，为什么每次调用都要卡几秒？是否有意义？当然不是！所以我们只需要直接融合点服务即可。比如你在5分钟内请求积分服务，它会直接返回。不要去网络请求卡了几秒。这个过程就是所谓的断路器！
降级：每次调用积分服务，都会在数据库中记录一条信息，说你给某个用户加了多少积分，因为积分服务宕机了，所以加不成功！这样，当积分服务恢复后，你就可以根据这些记录手动加分了。
3.5 祖尔
Zuul，又称微服务网关。该组件负责网络路由。不懂网络路由？好吧，我告诉你，如果没有 Zuul，你的日常工作会怎样？假设你后台部署了上百个服务，现在有个前端小哥，人家的请求直接从浏览器发出来。比如：如果有人要请求一个库存服务，你还让他们记住这个服务的名字是-吗？部署在 5 台机器上？就算人家愿意记住这个，你有后台上百个服务的名称和地址吗？难不成别人要了一个，就得记住一个？要这么玩，真是友谊之舟，说来就翻！
上面的情况简直是不现实的。所以在一般的微服务架构中，一定要在里面设计一个网关，比如，ios，pc前端，微信小程序，H5等等，你不用关心后端几百个服务，你懂的有一个网关，所有的请求都被处理了。到网关，网关会根据请求的一些特征，将请求转发给后端的各个服务。
而且有了网关之后，还有很多好处，比如统一降级、限流、认证授权、安全等等。
总结
上述Cloud核心组件在微服务架构中的作用
：Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka
Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
售前咨询专员
