微服务理论篇(整理)

微服务概念:

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。微服务是利用组织的服务投资组合,然后基于业务领域功能分解它们,在看到服务投资组合之前,它还是一个业务领域。

Spring Boot

Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。通过这种方式,Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。

理解:

Spring Boot就是一个快速开发的微框架,许多配置采用默认方式,来减少配置,内置容器,达到快速开发的目的。

Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

理解:

Spring Cloud框架比较大,因为涵盖了服务治理的方方面面,大致框架们分为两种,一种是直接封装现有的框架,另一种就是开发的一些东西的如Spring Cloud Stream。

第一种

Spring Cloud Netflix
  是对Netflix开发的一套分布式服务框架的封装,包括服务的发现和注册,负载均衡、断路器、REST客户端、请求路由等。
Spring Cloud Config
  将配置信息中央化保存, 配置Spring Cloud Bus可以实现动态修改配置文件
Spring Cloud Bus
  分布式消息队列,是对Kafka, MQ的封装
Spring Cloud Security
  对Spring Security的封装,并能配合Netflix使用
Spring Cloud Zookeeper
  对Zookeeper的封装,使之能配置其它Spring Cloud的子项目使用
Spring Cloud Eureka

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中的一部分,它基于Netflix Eureka 做了二次封装,主要负责完成微服务架构中的服务治理功能。

Spring Cloud Netflix

1、Eureka,服务注册和发现,它提供了一个服务注册中心、服务发现的客户端,还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。
2、Zuul

,网关,所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求。
3、Ribbon

,即负载均衡,Zuul网关将一个请求发送给某一个服务的应用的时候,如果一个服务启动了多个实例,就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。
4、Feign,服务客户端,服务之间如果需要相互访问,可以使用RestTemplate,也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。
5、Hystrix,监控和断路器。我们只需要在服务接口上添加Hystrix标签,就可以实现对这个接口的监控和断路器功能。
6、Hystrix Dashboard,监控面板,他提供了一个界面,可以监控各个服务上的服务调用所消耗的时间等。
7、Turbine,监控聚合,使用Hystrix监控,我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。

微服务场景

1、我们把整个系统根据业务拆分成几个子系统。
2、每个子系统可以部署多个应用,多个应用之间使用负载均衡。
3、需要一个服务注册中心,所有的服务都在注册中心注册,负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。
4、所有的客户端都通过同一个网关地址访问后台的服务,通过路由配置,网关来判断一个URL请求由哪个服务处理。请求转发到服务上的时候也使用负载均衡。
5、服务之间有时候也需要相互访问。例如有一个用户模块,其他服务在处理一些业务的时候,要获取用户服务的用户数据。
6、需要一个断路器,及时处理服务调用时的超时和错误,防止由于其中一个服务的问题而导致整体系统的瘫痪。
7、还需要一个监控功能,监控每个服务调用花费的时间等。

下面就是使用上述的子框架实现的为服务架构的组架构图:
在上图中,有几个需要说明的地方:

1、ZUUL网关也在注册中心注册,把它也当成一个服务来统一查看。
2、负载均衡不是一个独立的组件,它运行在网关、服务调用等地方,每当需要访问一个服务的时候,就会通过Ribbon来获得一个该服务的实例去掉用。Ribbon从Eureka注册中心获得服务和实例的列表,而不是发送每个请求的时候从注册中心获得。
3、我们可以使用RestTemplate来进行服务间调用,也可以配置FeignClient来使用,不管什么方式,只要使用服务注册,就会默认使用Ribbon负载均衡。(RestTemplate需要添加@LoadBalanced)
4、每个服务都可以开启监控功能,开启监控的服务会提供一个servlet接口/hystrix.stream,如果你需要监控这个服务的某一个方法的运行统计,就在这个方法上加一个@HystrixCommand的标签。
5、查看监控信息,就是在Hystrix Dashboard上输入这个服务的监控url: http://serviceIp:port/hystrix.stream,就可以用图表的方式查看运行监控信息。
6、如果要把所有的服务的监控信息聚合在一起统一查看,就需要使用Turbine来聚合所需要的服务的监控信息。

我们也可以从上图中看出该架构的部署方式:

1、独立部署一个网关应用
2、服务注册中心和监控可以配置在一个应用里,也可以是2个应用。
3、服务注册中心也可以部署多个,通过区域zone来区分,来实现高可用。
4、每个服务,根据负载和高可用的需要,部署一个或多个实例。