2017 年 10 月 22 日,又拍云 Open Talk 联合 Spring Cloud 中国社区成功举办了“进击的微服务实战派上海站”。点融网资深架构刘石明作了《从自动化运维的角度谈微服务》,以下是分享实录:

我理解的可视化的目的是在实施微服务的过程中,通过可视化来表达,可视化后的自动化才能让所有人理解一致、执行一致、结果一致。

这次的主题主要介绍以下几个方面的内容:

一、服务治理平台

二、网关规则管理

三、分布式 Trace 服务平台

四、各种第三方组件的运维可视化平台

  • RabbitMq 的 Ops 管理
  • 缓存的 Ops 管理

一、服务治理平台


微服务架构

如上图,是微服务里面提出者提供的一张架构图,图中显示,架构前面是有一个网关,网关构建各种的服务调用,最终展现给服务拆分之后,相应的 DB 拆分,最终展现。

开发模式也是如此,服务拆分之后,开始开发代码,然后 CI / CD 部署,打一个镜像到容器引擎,并排引擎里面,部署起来,然后微服务就实施完毕。其实这中间有一个很大的问题,微服务一个个小的容器,对应的这种服务,怎么去监控与管理呢?这就是服务治理的范畴。服务治理相当于对这些微服务进行的一些管理。

以下是我总结的服务治理的几个范畴:服务治理主要包括服务监控、线下治理、线上治理、权限管理。

  • 服务监控包括服务列表、服务性能、服务报表、服务健康。
  • 线下治理包括开发工具、仿真测试、上线审批、下线通知、文档库、协作流程。
  • 线上治理包括服务流控、优先级、服务降级、超时控制、动态路由、服务分组。
  • 权限管理包括用户管理、角色管理、权限管理、授权管理。

二、点融服务治理平台(Spring Cloud)

点融网针对 Spring Cloud 做了一个 portal ,主要包括以下几个方面:

1、服务列表展示:直接读取配置中心,把整个服务列表展现出来后,直接拉取每一个服务的整个信息;

2、API 鉴权:有些服务是只能特定的人调用,这就需要API鉴权;

3、Health Check 检查:定期在 Spring Cloud 里 Ping 操作是否可用,也可以在平台中看服务是否可用;

4、Swagger 文档库:文档库是用Swagger接入,在平台进行控制;

5、服务依赖梳理:A调用B,B调用C,C调用D,如此多的服务,怎么用动态地去梳理出我们整个服务的依赖关系?我们通过服务调用链数据计算,动态的进行服务依赖梳理。

缺失:我们在具体实施的时候发现,我们动态路由这块没有做,这也是我们最近要做的一件事情。动态路由比较重要,它可在路由器上运行路由协议,使路由器可以自动根据网络拓朴结构的变化调整路由条目,且无需管理员手工维护,不但能减轻管理员的工作负担,也增加了应用的可用性。

image.png

点融服务治理平台

上图是点融网服务治理平台,可以看到我们有一堆服务列表,能够在详情里面展现出具体在服务注册中心里面的一些实例。另外我们内部的运行状况的监控也是通过这个平台来实现。此平台面向的是开发人员。在服务上线后,开发人员通过此平台可以了解到服务的健康状况和服务调用是否正常。

我在之前的公司用的是 Grpc 服务治理平台。点融在服务治理平台上也有用到,它不单是调用链接,服务的依赖相应的菜单也会展现。针对开发人员的友好性,最好是做到可视化的目的,让开发人员用的更舒服,开发效率也更快,这是我们做服务治理平台的初衷。

Zuul 网关管理

针对 Zuul 网关配置的管理,它的整个路由规则是配置在 Groovy 文件里面,包括规定的各种各样的 filter 规则,并没有可视化的配置。所以我们把我们各种 filter 黑白名单,快域的设置、认证的设置、权限的设置,都是我们通过平台化操作来让开发人员在上面配置,而不是手动的去写代码来完成。配置完成后,我们会动态的在 portal 平台通知 Zuul 网关,让规则动态生效,减少通过手动写代码去配置,包括我们 groovy filter 的配置,都是相应的在整个平台里面处理。

路由规则配置第三方存储可以参考:https://github.com/jmnarloch/zuul-route-cassandra-spring-cloud-starter 

三、分布式Trace服务平台(Pinpoint)

追踪每个请求的完整调用链路,收集调用链路上每个服务的性能数据,方便工程师能够快速定位问题。调用链监控,我们选用的是 pinpoint,pinpoint架构比较简单,就是每个服务里的每个服务实例定时的写到一个Agent,然后直接定时上报到日志收集器里去。日志收集器定期写到HBase,然后通过webUI展现出来。它有以下好处,首先它的收集器是基于 UDP 的,不会占用应用网络的数据。其次它也是直接发送到收集器,所以及时性是得到保障的。任何一条调用链进来,基本上立马能在整个 pinpoint平台里面得到完美的展现。而不是像 sleuth ,如果 logstash 挂掉,估计有调用链监控是会失效的,以下是 pinpoint 的架构。

image.png

pinpoint 架构

Pinpoint 架构的有点是:

  • 对代码的零侵入,运用JavaAgent字节码增强技术,只 需要加启动参数即可
  • 基于UDP直接往Collector发送数据

a.Spring cloud sleuth对比少去了配置Logback等以 logstash的繁琐

b.准实时,logstash不会成为瓶颈

c. UDP传输不会对应用的网络造成网络拥堵

  • 丰富的Plugin库及良好的Plugin扩展

缺点:

  • 统计与分析功能的缺失
  • 依赖于Jdk1.6、Jdk1.7

剥离Jdk1.6及1.7的依赖 https://github.com/linking12/pinpoint

image.png

pinpoint 的插件列表

Pinpoint 插件列表很多,已经支持 Spring Boot 以及各种第三方中间件,我们也可以开发自己的插件列表,很简单,就写几行 server ,可以把整个插件玩转起来。

image.png

pinpoint 的界面展示

Pinpoint 界面也很漂亮,从前端到各个服务之间的调用,以及调用中间件、云端等,包括MYSQ L也是把它作为一个服务作为依赖。所以在这一点上,做的比其他整个界面的友好性是比较好的方面。

四、各种第三方组件的运维可视化平台

(一)RabbitMq 的 Ops 管理

大家都知道规划微服务之后就涉及到服务拆分,每一个服务做你自己的事情,服务的系统有可能并不需要同步进行调用,许多时候涉及到异步。异步就会用到消息系统,我们这边使用的是 RabbitMq 的消息系统。

RabbitMq 在网络不好的情况下很容易出现网络分区的情况。网络分区是什么意思呢?在使用 RabbitMQ 的时候,如果整个集群网络不好,整个集群每个节点会单独的暴露出来给用户提供服务。而给用户提供服务,最终在把它合并成集群的时候,就会产生这种消息丢失的情况。这就会导致整个异步化没办法进行。所以在这点上我们在RabbitMQ上做了一个增强。

首先我们规范了 Exchange、RouteKey、Queue 的使用,将创建和使用剥离出来,能够将相应的Exchange、RouteKey、Queue找到相应的责任人

其次,我们做了可视化运维,对业务开发人员要足够友好,消息轨迹可查询,消息可回朔、消息丢失后可寻回。

第三,我们队做了消息定制化场景的支持,因为我们没有办法做重复消息,所以做了重复消息的预防。此外我们支持重复队列。因为 RabbitMq 有一个插件可以支持延迟,但是我们整个运维没有支持整个插件,所以要在扩展包里面实现我们的延迟队列。前面说过 RabbitMQ 在网络分区以后,再恢复过程的时候,数据会产生丢失,并且我把它重启以后,我的应用会掉线,所以我们在这里面做了一个不断线支持服务端数据的恢复功能。

image.png

RabbitMq的Ops系统架构

我们整个 OPS 架构很简单,在 SDK 上面拿到一个点,相应的发送消息与接听消息的时候,我们都会异步的写到第三方的存储里面,然后通过我们整个 portal 里面去展现我的一系列信息。

所以我们的功能就是 Exchange维护、Queue维护、Routing维护、消息轨迹的查询。

整个消息全部是通过这种 portal 里面,都能展现出来。通过一些查询,能找到我消息是成功还是失败了,接到这条消息是在哪个 IP 上,应用是多少,有响应操作等,成功了、失败了,相应的异常情况、堆栈情况,都会展现出来。

image.png

RabbitMq 的 Ops 系统功能

(二)缓存的 Ops 系统目标

  • 提供二级缓存,为分布式缓存减负
  • SDK支持spring cache
  • 在缓存穿透、雪崩、击穿上统一处理
  • 提供管理API让开发人员可以动态缓存重新加载、缓存失效
  • 可视化运维,让开发人员可以查看缓存中存放的数据,提供缓存hint、 miss的查看

image.png

缓存的Ops系统架构

我们缓存 OPS 系统,里面 KV 操作的应用端,一级缓存用的是 ehcache,二级缓存用的是 redis,中间的集群式的缓存在微服务所有的节点中能够生效的,用的是 redis 的 pub、sub,发布的相当于队列的操作来做的。我们也有响应的 web 的查看,在里面查看我当前一级缓存和二级缓存存放了哪些数据,相应的命中率和失效率是多少,都是通过这样子来实现的。 我们还有一些redis、管理的API,相当于提供一个小后门,让它动态的刷新它的缓存,或者是失效的缓存。

image.png

缓存的Ops系统功能

这就是我们整个的 OPS 页面,OPS 页面能展现出所有一级缓存和二级缓存里面的数据,相应的统计值也在下面会展现出缓存命中率,一级缓存和二级缓存的缓存命中率是多少,相对都是有一些统计信息给展现的。

这个就是我最近在点融网微服务上基础设施方面所做的建设。回顾一下,首先可视化提供各种各样的 porter 功能,方便开发人员开发实施微服务。我们做了各种各样的平台和 porter,能够可视化的展现数据,动态地通过一些平台运维微服务。

又拍云 Open Talk 是由又拍云发起的系列主题分享沙龙。秉承又拍云帮助企业提升发展速度的初衷,又拍云 Open Talk 将用全干货的形态,为互联网从业人员呈现以技术为主,同时涵盖产品、营销、融资等各个方面的专业知识,帮助企业成员不断的提升自身专业技能,以推动企业更快的发展。