一年了，我们都用 Spring Cloud 干了啥？

朱清已阅读 26917 次

朱清，Spring Cloud 中国社区联合创始人之一。 现任冰鉴科技信息技术部总监，曾供职于腾讯。主导建设了冰鉴大数据风控平台，在数据处理、模型估算、规则引擎、贷款核心业务平台的设计上有着丰富的经验。

2017 年 10 月 22 日，又拍云 Open Talk 联合 Spring Cloud 中国社区成功举行了“进击的微服务实战派北京站”。冰鉴科技信息技术部总监朱清作了《一年了，我们用 sc 干了啥》，以下是分享整理：

朱清spring是干什么的，毕业于电子科技大学，融公司、银行等等借贷机构提供风控服务。

1、配置

SpringBoot 是一个在 Spring 的基础下面做了太多简化的框架。首先得益于它“习惯用于配置”的设计模式，所以开启的容易程度要简洁比较多。它有一个 conifg 的 Jar 包，里面有比较多第三方依赖的基础配置，可以直接在 applicationb.yml 对应的 uil，包括 DB 的名字、用户密码、用户名等做修改，可以迅速的推进应用。

2、部署

它的部署比较简洁，使用 SpringBoot 可以一键产生 Jar 包，这上面包含 Code 部分、第三方的模块以及内置的 tomcat / jetty 容器。我们在使用的过程中也不需要在内部融一些网络应用的中间件。

3、监控

它也使监控变得简洁，actuator 是 spring boot 提供的对应用平台的自省和监控的集成功能，可以对应用平台进行配置查看、相关用途统计等。比如做监控的之后，给服务登录与看到插件提供应用状况检测的接口，会帮助我们在开展之后，去访问当前应用 /health 的接口，我们可以获得返回的应用健康信息，包括服务登录与看到中心，是 down 还是 up ，最后会返回一个 states，如果所有东西都没问题，会有一个 states ok，并且 HTTP Code 是200；但是如若你的 DB 根本就是连不通，或者你的 MQR 等等集成如果连接给错了等等，它自己会检查这个措施，会给你一个无开头的 Code，它会被测成一个不可用的示例。

主要暴露的功能

在 SpringBoot 的基础上集成了众多自己常见的第三方的依赖，比如 Mongodb、Redis、Fastdfs、Rocketmq等，除了Rocketmq，Fastdfs，都有现成 starter 可以直接采用。

我们定制了一个自己的 starter ，在已有的那些 starter 基础上，创建配置文件，并把脚手架一键打包起来，开发只要在 top 文件采用 starter 就可以研发业务，不用关心到底使用了哪些部件。

我们的业务主要有两个场景的设计：第一种是实时的标准，A服务调用B服务，需要实时返回结果，这是一个常见的业务流程，调用方实时依赖执行结果的业务场景，我们的基础构架组也在尝试把外部读取集成rpc 协议。

场景设计—http调用

另一种场景是轮询消息，比如做逻辑的前馈，上游不关心下游执行结果，可以直接借助 MQ（消息中间件），做物理上的冗余。生产者产生消息，由 consume 订阅相应的 Q ，就可以知道上游发起了怎样的轮询读取，执行对应的业务。当然在 MQ 方面主要还是发一些简单的消息，并不会在上面放任何数据。因为之前我们有在 MQ 里面放数据，而因为监控不到位，最后把 MQ 搞挂了。这是踩的一个坑，不建议在上面放数据，只是放消息。

场景设计—异步消息

讲到 SpringBoot，它离微服务还差些什么？它显然就是一个构建微服务的框架，在这个基础下面没有注册发现，也没有授权等，也不能通过这个把所有的应用监控出来，配置还是跟应用关联在一起。它也是一个微框架，是结构微服务应用的基础框架。

首先，我们要讲下网关，我们现在使用的是原生的 zuul。

在微服务构架体系下前端服务的例子数一般是动态的，比如我可能加入一个新的服务，这个可能还会有一个影射关系，对于客户端而言很难发现动态改变的服务案例的访问地址信息。这个之后我们会基于 zuul 做一下跟 Nginx 类似的，一个反向代理，对应某一个path，把它转给某一个 serverID 。同时我们在 zuul 上面也用了 zuulset 对授权服务、健全服务的集成。

zuul 常见的有这两种配置的方法，一个是这种直接对 path 的转发，比如某一个网站直接转过去；另外一个是对 serverID，比如所有登录中心的服务都可以借助它的 serverID 做一个对应的请求的转发。

通过 filter，我们可以推动安全的监控，比如建立、白名单、黑名单的过滤等，都可以在端口的filter 中加入一些对应实现的模块，通过 filter 对应的类别我们可以完成好多自己想推动的功能。比如你想看某一次调用花了多少时间，在后端调用 zuul，上面损失极少的状况下，可以直接统计通过 Nginx 到你的服务转发之间的时间。另外诸如你在 prefilter 和 postfilter 去定义一下对应的时间，也是可以做这个统计的，但是我们并没有这样做，因为代价太小了，基本上可以忽视不计。此外在 prefilter 上面，我们会做太多过滤，包括黑白名单相关的检测以及完善。

服务登录与发现我们使用了 consul，用 consul 做服务登录与看到，对应用本身是完全零侵入的。我们推动的服务注册与看到，主要是基于 Docker ，用了一个叫 Registrator 的模块，主要的作用是借助 Docker events 发现哪一个服务开启了以及哪一个服务的示例启动起来了，对应的 IP 是多少，然后把这个信息发给 consul agent，再从 consul agent 发送到 consul server，这样就可以知道对应的哪一个 service。比如在定义了 service name，它就会直接把这个信息发给 consul，包括后面讲到的用 /health ，去做 server 的健康检测。同时可以去借助它的标签或环境变量设定检测的间隔，比如 5 秒或者 15 秒。

配置中心我们使用config，因为我们是做 2B 业务，很多配置都不怎么动，有很多业务的配置在里面。比如说给某一个用户分配一个渠道，这个渠道对应到上面有哪一些建模或者数据，这些东西都不会写在像 SpringBootconfig - server 里面；而更多的是拿来做一些不同环境里面的，比如说你的 DB 的历史是不一样的，要做一个隔离，直接借助资源信息的命名的规则就可以了。此外如果要动态去改变一些东西，无非就是恢复里面的一些控制。

（四）熔断器 Hystrix

熔断器大家都很熟悉，我们直接使用 Hystrix ，这个貌似是你对开发完善的一些强制的规定。在我们刚开始做这个应用的之后，我们没有太多考虑对第三方的依赖，而最常见的是去加载一个超时，以免这个服务挂掉的之后请求一直 Hold 在那里，大家都很知道人们开默认的有限大小的线城池是 200 。如果我们今天季军来几个第三方的数据源，其中一个服务挂掉了，而同时后端可能有长期的请求应该这个数据源的支持，我们会发好多请求到这个数据源，那么众多现成的资源都会 hold 在那里，其他的服务也会因为这个服务挂了造成不只用。所以我们用到了Hystrix 一个最关键的科技，它借助一个 group 信息对线城池的一个隔离。同时我们可以在它失败的之后，给前端的用户返回一些比较友好的信息。比如“现在服务暂时不可用”。

在服务调用方面我们外部还是用的 feign ，你只应该去定义一下 feign，在里面指定你内部的 serviceID ；而对外部的一些请求，可能涉及到读取链最后的问题。feign 也可以跟 hystrix 结合的比较好，你只要建立专用于调用服务的Component，然后把 component 引入进来就可以了。

假设你以前在一个单体后面，客户发一个请求过来，你把数据的请求、对数据的处置、这个建模的估算、反其他规则的推导、最后角色引擎相关的估算，都在一个单体应用上面完成，所有的日志都能看到他是在同一个线上 ID 下面（假设非多线程情况下），会有太多日志，很容易关联起来。但是当你做了服务拆分之后，显然这个难度就变大了。比如 logstash 收集一个主机采集上来以后，你可以直接借助现成的 ID 看到上下文所有打印的日志的状况，去做故障、客户反馈上面的查询、分析到哪个环节出了问题等。

而当拆成好多时候，第一个可能遭遇的难题是日志搜集的弊端，另一个则是整个调用链的难题。假设我们日志搜集的弊端已经解决了，然后对elasticsearch 收集出来的数据，其实是有时序的，如果我两台主机网络不太好，本来这个请求可能先到了A主机，A 主机调了 B 主机提供的一个服务，理论上来讲我们期望听到的日志是先看见 A，再见到 B。但是有可能由于你的 logstash，或者我们上面采用的 fleentd 到 elasticsearch 网络带宽的问题，会导致 B 主机打起来的日志比 A 先到，这时候你的日志看上去一定是比较乱的。我们如果想去对一个服务上面发生的那些难题定位的话，相比也有比较困难的。

针对服务化应用全链路追踪的难题，Google 发表了 Dapper 论文，介绍了他们能否进行服务跟踪分析。其基本模式是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用很多信息，可以可视化地剖析服务调用链路和服务间的依赖关系。如果使用 sleuth ，开两个服务，A 服务到 B 服务，如果抓一个包，肯定会看到在 A 调 B 的之后，如果 A 引入了 sleuth ，B 也引入了 sleuth ，它会在 A 这边，进到你的机制里面，假设先形成一个 Trace ID，是一个 http 请求，会在调用 B 的之后，把这个Trace ID 带到 handles 里面 ，当 B 收到 A 调用请求的之后，会在 handles 确认，已经造成的一个Trace ID，就接着往上面用就可以了，其实就是这样一个思路。此外我们也有借助消息中间件的方法做了一个 A 与 B 服务调用之间的轮询的前馈，就不是一个http 调用的方法，你就应该你集成一下 MQ 对 sleuth 的支持。

zipkin 我们没有用，由于使用elk检索日志，sleuth 帮助记录了 traceid，故认为有点鸡肋，直接运用了检索traceid。

服务访问结构

在讲完整个运用的服务以后，大家眼睛上面需要会浮现这样一张图，对我们来说，在一个外部请求过来的之后，会先经过我们的服务端口，我们把我们的授权，以及认证的服务单独做了一个 service ，这样一旦有一些升级，它可以独立地去发布。服务端口，现在主要是一个 token base 的认证模式，会获得这个 token 到 server 上面做一个验证，验证通过以后外部请求才会通过我们的 zuul 做一个反向代理，会查是向哪一个 service 转，会在服务登录与看到的中心根据它的 service name 拿到一堆实例，在这个例子后面，会向对应的服务出现一个调用，可能编排层的服务会调用能力层的服务，这时候就涉及到外部服务之间的调用，我们内部服务之间的调用时没有健全的说话的。

1、运维有测试能力是积淀

在整个做微服务的过程中，运维与检测相关的素养是积淀。因为如果你的运维和测试能力跟不上，在你服务做拆分之后，部署、测试就会遭遇特别大的压力。我们整个“运维+测试”两个团队才6个人，如果服务从以前包括单体应用只有4个，到今天40多个，而没有一个很好的，比如持续集成与推进相关设备的，那绝对是灾难性的。刚才说到的那些日志收集都要搜集起来，有一个服务之间的读取关系的调用链的管控，能帮我迅速的定位一些难题。

2、持续集成与推进

在持续集成与部署方面，我们主要还是在用 git 和 jenkins 。通过 jenkins 我们自己做了一个自动化接口检测系统。目前也是做接口测试，而功耗检测在大版本公布之前会集中来做。通过我们的测试，构建之后会发到 harbor，一个企业级的镜像仓库spring是干什么的，而实际的推进，是用到 rancher，不可否认 rancher 是在容器管理编排方面的小白入门的神器，我们起初用它也有因为它的界面比较精致，有出来比较简洁。在 rancher 上主要推动两个方案，一个是推进，一个是更新。

3、日志收集

此外需要切记日志收集的个别。像传统的方式存在一个问题，在 Docker 环境下，一个宿主机后面有很多不同服务的业务案例，那很多日志怎么办？难道要按个做脚本收集文件信息吗？更大的问题是你是有 file 的，如果是云上买的，你可能还要缩减磁盘的容量，因为你有可能还要做监控脚本，清理日志。在做到微服务、容器化之后，第一个要做的就是让你的日志增加，这样就没有文件，直接借助 SDD Out 的方法，对 logstash、sleuth 采集出来以后，可以直接送日志数据，中间不会产生一个日志，不会清理。因为我们之前一开始还没有做这套运维基础的之后，经常都应该手工的清日志，在业务量突增的之后会造成诸多日志。我们做征信的之后后面要打好多日志，可能一次请求上面要打十几兆的日志，因为涉及到的第三方数据源实在很多了，中间有很多计算的过程也要打印出来，否则的话只能明白前面到底出了什么疑问。

4、监控与告警

我认为监控与告警就是一个先行的东西，在我们没有做微服务之前也是。对我们做 IT 系统来讲，如果发生问题，要保证在用户没有投诉我们之前，快速的发觉并且去处理很多疑问。这个之后我们就应该对我们搜集上来的日志做一个日志级别的完善和定义，比如我定义了 error、info 等，当一个第三方的数据源挂了，打了一个 error 级别的日志，这个日志是我一定要通知你的，这就应该一个规范。我们从 ES 上每分钟会传上来这些日志，会看上面 error 级别的日志对应的 service 是哪一台，并把它发到对应负责的开发那。这个我们也有借助微信发的，但是要留意不要乱发告警信息，多了以后一定会疲惫，一天如果收到 200 多条，真正有重要的信息回来的之后，你可能看都没看，直接就摆脱掉了。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-120401-1.html