基于微服务架构的PaaS云平台架构设计

常秀岩

唐山科技职业技术学院 信息多媒体系 河北 唐山 063000

引言

近年来，微服务架构及容器技术备受关注，在各类文章、演讲、博客中频频亮相，成为业界最热门的话题。诸多研发人员开始重新思考互联网时代服务的架构以及应用开发、运维的方法。微服务以一种全新的架构设计模式，牵动了互联网应用从设计到运维整个流程方法论的变革。而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，进而实质性的改变了新一代应用开发和发布的方式。

1 微服务架构的原理与实施

1.1 微服务架构的原理 微服务架构是一种架构风格和设计模式，提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制(如HTTP/REST)相互沟通、配合来实现完整的应用，满足业务和用户的需求。微服务作为架构模式的变革，其诞生绝非偶然。它是当传统服务架构在互联网时代遭遇挑战时，人们对于架构模式，开发和运维方法论的一种反思。

目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，在本文的微服务架构设计中，使用了诸多Spring Cloud Netflix框架的组件。其微服务架构的组成及原理如下图1所示：

图1 微服务架构的组成及原理

由上图可知，微服务访问大致路径为：外部请求→负载均衡→服务网关(Gate Way)→微服务→数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。

1.2 微服务架构的实施 本文采用亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能；ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载，使用Nginx对加密请求进行卸载处理，外部请求经过ELB负载均衡后路由到Gate Way集群中的某个Gate Way服务，由Gate Way服务转发到微服务。

由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务(通过配置Eureka服务信息)到Eureka服务器中进行注册，并定时发送心跳进行健康检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒(默认配置90秒，可以通过配置参数进行修改)后，才认定服务已经死亡(即连续3次没有接收到心跳)，在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。

微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。这里我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。

2 PaaS云平台架构的设计

2.1 服务网关的设计 服务网关作为内部系统的边界，应具备以下功能：

(1)动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。

(2)限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。

(3)身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。

(4)监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。

(5)访问日志：网关可以收集访问日志信息，比如访问的是哪个服务、处理过程出现什么异常和结果、花费多少时间等，通过分析日志内容对后台系统做进一步的优化。

本文采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器，通过重写过滤器，使我们能够灵活的实现网关的各种功能。

2.2 微服务的部署 传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务和后端服务，前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备(如PC、Phone等)，所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。本文的Eureka服务器部署架构如下图2所示：

微服务以镜像的形式，运行在Docker容器中，Docker容器技术让我们的服务部署变得简单、高效。使用Docker容器技术，我们只需要将所需的基础镜像和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swar m对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。

图2 Eureka服务器部署架构图

2.3 服务容错机制的设计 微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理，Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退(fallback)和限流等机制对服务进行弹性容错保护，保证系统的稳定性。Hystix使用命令模式Hystrix Command包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。

3 微服务动态配置中心的设计

传统的实现信息配置的方法，比如放在x ml、y ml等配置文件中和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。

本文使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver(配置中心)服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post－receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。

4 结论

本文设计了一套基于微服务架构的PaaS云架构平台，上述系统框架和组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等。根据业务需要自行选择使用，在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括服务网关、服务注册与发现、服务容错、客户端负载均衡等，这些优秀的开源组件，为我们实施微服务架构提供了捷径。