程序员涂小哥的技术博客

前言几个月前做过一个springCloud服务限流的任务，当时选定的技术是spring-cloud-zuul-rate-limit。之所以选这个而不是别的，是因为项目本身使用了zuul，而且业务需求上spring-cloud-zuul-rate-limit的功能刚好都可以满足，在这种情况下就可以在符合要求的同时尽可能快的完成。这个任务实际上只相当于一个技术调研，只要在现有技术框架的基础上能够集成和实现需求，并且成功测试就可以了。和当时在公司略有不同的是，公司是直接使用内部maven仓库，spring

springcloud微服务一：spring boot基础项目搭建及问题处理springcloud微服务二：Eureka服务治理之服务注册中心springcloud微服务三：Eureka服务治理之注册服务提供者及服务的发现和消费springcloud微服务四：服务容错保护Hystrix断路器springcloud微服务五：客户端负载均衡ribbonspringcloud微服务六：声明式服务调用Feignspringcloud微服务七：网关zuul...

当服务注册中心成功建立以后，就需要有服务的注册和消费，否则这个服务注册中心就没有了存在的意义，而实际上，一个简单的服务注册也是非常简单的，仅仅需要实现四部曲就好。首先，还是建立一个基本的spring boot的项目，创建的时候选择web，然后在pom.xml文件中加入Eureka的依赖，和服务注册中心的maven配置一样，这里就不再罗列代码。第二步，就是修改application.propertie

当初步的学习了spring boot，了解了spring boot的基本实现过程后，我就正式开始学习spring cloud，首先就从Eureka服务治理开始。服务治理包含三个核心的角色：服务注册中心、服务提供者和服务消费者，他们相对独立，新的服务要向服务注册中心注册，新的消费者会向服务注册中心索引服务列表。一番了解之后，让我想到了人才招聘。在我看来，现在普遍存在的招聘形式也是分为了三个部分：招聘网

通过前边的学习，服务注册中心、服务提供者和服务消费者都成功建立并运行起来，而且通过默认的配置restTemplate及@loadbalanced注解开启了负载均衡。 在默认的情况下，负载均衡策略是线性轮询的方式，也就是说在客户端获取到的服务列表中依次交替，例如开启了三个服务server1、server2、server3，那么在线性轮询时，就会按这个顺序来调用。 我之前是开启了两个服务，一个端口是

公司接下来某个项目打算使用微服务架构，使用springcloud以及它集成的一些相关项目，因此虽然在其他方面的很多技术上还感觉急需提高，却又不得不以工作为重，先放下其他来了解一下这方面的技术。一番了解后发现，spring cloud是建立在spring boot的基础上的，而之前虽然听说过，也随便看了一下spring boot，却没有真正使用，因此还必须先花时间学一下spring boot。spri...

一、基本概念理解ribbon用在客户端，或者说消费端，被称作客户端负载均衡。 对于这个称呼，可以解析为三个部分，一个是客户端，一个是负载均衡，然后就是客户端负载均衡。 根据个人理解，所有发起请求的一端、去拿东西的一端，都可以称之为客户端或消费端。 而负载均衡，一般则是针对于至少两个以上的集群而言，重点在于均衡。从相对论的角度而言，一切都是相对的，那么也就不存在绝对的均衡，因此所谓的均衡就...

在有了eureka服务注册中心、ribbon负载均衡及服务消费、hystrix断路器三部分之后，其实在某种程度上就应该能够创建一个基本的spring cloud微服务应用了，只不过这种应用无论是代码层面还是架构层面都还有一定的缺陷。 从代码层面来讲，ribbon和hystrix是一个标准化springcloud应用最基本的模块，通常也都是同时出现的，因此为了简化开发，有一个更高层次的工具来对他们...

理解网关概念根据我个人的理解，对于一个系统来说，不管是微服务架构还是非微服务架构，如果单从功能实现来说，网关其实不是必要的。 但是，如果一个系统的业务涉及到了和外部网络的交互，多数情况下都会加入网关功能，最根源的目的就是提升系统的网络安全性。 因此网关可以理解为是在大的系统架构层面，一个网络策略方面的东西，最基本的需求就是实现请求的路由转发。 但是有的时候，可能网关是一种功能上的实现，而...