Spring Cloud 微服务架构的原理剖析

举例：电商项目中，订单支付功能，所引发的微服务体现。

比如在淘宝中，我们创建了订单后，如果用户紧接着支付了这个订单，那么我们首先要改变这个订单状态为“已支付”
相应扣减库存
然后通知储货中心，发货
给用户这次购买增加相应的积分

针对上述，我们分为，订单服务，库存服务，发货服务，积分服务
那么，当请求上述：
订单服务先去数据库更新状态
订单服务调用库存服务，扣减
订单服务调用发货服务，发货
订单服务调用积分服务，加分
至此整个订单支付流程走完

如下图，我们清晰的看懂以上流程：

接下来，我们使用spirngcloud 微服务来简单绘个图：

我们具体描述一下以上过程：

• Eureka：各个服务启动后，Eureka Client 都会将服务注册在Erueka Server中，并且client可以从server中拉去注册表，从而知道服务那个ip，端口
• Ribbon： 服务间发起请求，微服务中可能有多台机器来部署，基于ribbon负载均衡，通过算法（轮训，权重等）从一个服务中选择一台机器
• Fegin：基于fegin的动态代理会根据接口上的@RequestMapping，@FeginClient，@PathVariable等注解，来动态的构造出请求的路径
• Hystrix：微服务中，是由多个服务组成，有一个服务挂掉，会影响到调用他的服务长时间未响应而停止请求，很容易产生服务雪崩的情况，那么我们通过不同的服务走不同的线程池，实现了不同服务之间的隔离，避免服务雪崩，这只是熔断了服务，但是我们并没有操作什么东西，这个时候，我们可以降级，每次调用挂掉的服务，来新增一条数据，比如积分服务挂掉了，那么等恢复后，我们可以手动给用户增加上，这就是所谓的降级。
• Zuul：如果前端，移动端调用我们后端系统时，你后端有上百个服务器来部署的服务，这样的话让请求统一走网关，网关会根据请求中的一些特征，将请求转发给后端的各个服务