“中台”这个概念火了一年多了,年初的时候又“火”了一次。相信任何事物都有它的两面性,正如我们做架构的时候其实也一直在做取舍。
小鹏汽车的技术中台(Logan)已经快两岁了,今天我们不讨论该不该做技术中台,只说说中台给我们带来了什么。
不管黑猫白猫,捉到老鼠就是好猫。
小鹏汽车的 智能 离不开复杂系统的支撑,其特有的 互联网 基因要求业务能够应对市场的迅速变化:快速响应、快速试错、快速创新。同时,为了给客户提供优质服务,系统需要更高的可靠性,降本增效也是公司快速发展过程中特别关注的。
技术中台正好契合了公司上述所有需求。在公司的引领和推动下,2018 年 4 月召开了小鹏汽车技术中台的启动会,同年 5 月底团队成立。技术中台团队始终坚持“兵不在多而在精”的原则,近两年高峰时期团队也未超过 10 人。
也许有人会怀疑,一支足球队规模的团队,到底能做出个什么样的中台来?
如上图,小鹏汽车的技术中台分为微服务中台和云平台两大部分:
本文主要分享微服务中台的实践经验。
鉴于以上原因,开源软件及产品被列入首选,同时结合现实情况及需求在开源的基础上进行功能的扩展开发。只有实在没有选择的情况下,我们才会考虑自造轮子。
此外,中台通过自定义的 SDK 提供对上述功能开箱即用,包含组件的配置调优、Metrics 输出、统一日志、框架 Bug 的紧急修复以及功能扩展。
参考官方的文档,跑个 DEMO 是很容易的,但是真正在生产级环境中使用又会踩不少坑。
可用性对于车企来说尤为重要,甚至说高于一切也毫不夸张,公司对这一方面也格外重视。
经过两年的不断踩坑填坑,同时借助云平台的能力(比如自我修复、滚动升级等功能)提升了系统的可用性;同时降低应用发布时对业务的影响:从原本的低峰时间版本升级,提升到随时部署升级,甚至部分服务已经可以实现自动扩缩容。
下面列出我们踩过的一部分坑,也是我们不断修炼提升可用性过程中关注的问题点。
使用默认配置的情况下,实例正常上、下线的被发现延迟最大为 90s ,比如,服务 B(提供方)的一个实例上 / 下线,服务 A(调用方)在最长 90s 之后才会发现。这与 Netflix 的设计有关:
Eureka 服务端的三级缓存模型
a. registry :存储服务实例信息 (服务上下线实时更新)
b. readWriteCacheMap :读写缓存 (实时从 registry 中更新,过期时间 180s )
c. readOnlyCacheMap :只读缓存,默认从这里获取服务信息 (每隔 30s 从 readWriteCacheMap 更新)
Eureka 消费端每隔 30s 请求 Eureka 服务端获取增量更新,然后更新本地服务列表
Ribbon 客户端每隔 30s 从 Eureka 客户端的本地服务列表中
可通过修改配置缩短上下线的被发现延迟:
上面提到默认配置下被发现的延迟最大是 90s。运行过程中不可避免的会出现非正常下线的情况,比如进程被强杀(kill -9),实例来不及通知注册中心进行注销操作就退出了。这种情况下,此实例的信息会存在服务调用方的 Ribbon 、实例列表中最长达 240s。如果是 2 个实例的话,会有 50% 的请求受到影响。这同样源于 Netflix 的设计:
可通过修改配置缩短上下线的被发现延迟:
Eureka 是基于 CAP 理论的 AP 模型,用于保证分区容错性,但这也导致注册信息在网络分区期间可能出现不一致,自我保护功能是为了尽可能减少这种不一致。
自我保护(self preservation)是 Eureka 的一项功能,Eureka 注册表在未收到实例的心跳情况超过一定阈值(默认:85%)时停止驱逐过期的实例。
解决了 b 中的延迟问题,必然会导致自我保护模式不准确。
解释自我保护模式的工作原理,需要另开 一篇文章 来说。
解决了 b 中的延迟问题,还会带来一个坑更深的坑:极低的概率下,实例启动后本地处于 UP 状态,而远端(注册中心)的状态持续处于 STARTING 状态,且无法更新。这会导致实例实际正常运行,而且对服务消费者不可见。
这种情况在 Kubernetes 环境下尤为恐怖:实例本地状态为 UP ,健康状态也为 UP 。在 Kubernetes 的 滚动升级 模式下,旧的实例为删除,新的实例正常运行,却对消费端不可见。
问题的分析、重现方式已经记录在 Netflix Eureka 的 issue (又是一长篇,目前只有英文)中, Pull Request 也已经合并到了 1.7.x 分支。不过嘛,呵呵,一直没有发布新版本。
注:在技术中台运行一年多,生产环境累计出现的次数不到 10 次,不是 2 个实例运行的情况下没有对请求出现影响。
Ribbon 大家常听到的就是负载均衡,但是除了负载均衡之外,它还提供容错的能力:重试 。
这里有个隐藏的坑,就是加入开启了对所有操作重试的情况下,且出现 SocketTimeoutException 时,可能会导致一致性的问题:
因为 SocketTimeoutException 不只是连接超时,还有读取超时 。假如一个 POST 请求会更新数据库,出现客户端的读取超时 ,但是服务端可能在客户端断开后完成的更新的操作。如果客户端进行重试,则会再次进行更新。
SpringBoot Tomcat 的优雅退出,不知为何官方没有实现,实在匪夷所思。
为什么需要优雅退出?当 Spring 上下文关闭时,假如有未处理完的请求,不等请求处理完毕就直接退出。从健壮性或者一致性方面考虑,并不是一个好的解决方案。
理想的方案:收到 Spring 上下文关闭事件,阻止 Connector 接受新的请求,然后对线程池执行 #shutdown() 的操作并等待队列中的请求处理完成。当然这里不能无限期的等待下去(滚动升级无法继续),设置一个超时时间比如 30s 或者 60s。如果还没执行完,那就是执行 #shutdownNow() ,让未完成的操作自求多福吧。
这也是我们生产中遇到的一个问题,会在凌晨的低峰时段偶发。异常如下:
org.apache.http.NoHttpResponseException: The target server failed to respond Caused by: org.apache.http.NoHttpResponseException: 10.128.61.43:8080 failed to respond
HttpClient 连接池创建的连接初始默认的有效期 (timeToLive) 是 900s,后续收到响应后会尝试从响应的头信息中获取 KeepAlive: timeout=xxx 服务端连接的保持时间,然后再更新连接的有效期。后续请求从连接池获取连接后,会再次检查有效性,避免使用过期的连接发送请求。
参考 Tomcat 8.5 配置 ,其中也提供 Keep-Alive 相关的配置:
keepAliveTimeout: 默认为 60s. 见 org.apache.coyote.http11.Constants#L28. maxKeepAliveRequests: 默认为 100. 设置为 1, 禁用 keep alive; 设置为 -1, 无限制.
SpringBoot 中通过 server.connectionTimeout 来设置 Tomcat 的 keepAliveTimeout ,如果未设置,则使用 Tomcat 的默认配置。
大写的但是 :Tomcat 并没有在响应头部带上 Keep-Alive:timeout=60 。
可通过增加过滤器–在响应头部增加 Keep-Alive 的 timeout 配置的方式来解决。
微服务中台运行于云平台之上,应用的升级模式为滚动升级:对服务进行升级时会先创建新版本的实例,待相应的检查(借助 Actuator 提供的 /health 接口)通过后,再将旧版本的实例下线。
即使完成 3.1 中 a 和 b 两项的优化,旧的实例还会存在于消费端的本地缓存中一段时间,当然,借助 Ribbon 的容错可以避开这个问题,但是重试会降低吞吐。
借助 Kubernetes 的 Pod 的 preStop lifecycle hook,在 Pod 退出时会先调用 preStop 配置的脚本。在脚本中调用本地服务的 /service-registry/instance-status 接口,将实例的状态修改为 DOWN ,并等待一段时间(比如 30s)。之后才会将退出信号放行到容器中,完成后续的退出动作。以此来降低 Eureka AP 模型带来的不一致隐患。
小鹏汽车的业务比较复杂,除了主要的 Java 技术栈之外,还有基于 CPU/GPU 的 Python 应用,以及 Node.js 应用和前端应用。
而中台的出发点是功能的复用,如何让非 Java 语言的应用使用到中台的能力?
我们的做法是借助 Sidecar 模式实现基础功能下沉,与应用解耦,将 SDK 中的功能,下沉到独立进程中。
对于我们运行在 Kubernetes 上的应用来说,实现这一点就更容易了:在 Pod 中增加一个 Sidecar 的容器。
同时 Sidecar 还给我们带来了意想不到的效果:
当然目前的实现也不是很完美,sidecar 的实现,我们用的是 spring-cloud-netflix-sidecar 。是的,Java 的实现很重,对资源还存在一定的浪费。但是战略有了,战术的选择是多样的,比如 C++ 实现的 Envoy 。
因此当前的方案 不只是一次尝试,也是一个布局 。
服务的容器化,允许我们在统一了日志格式后,将日志直接输出到标准输出 / 错误。通过 Docker 的 json-file driver 统一落盘到 Node(Kubernetes 的工作节点)上。再经由以 DaemonSet 方式运行采集器挂在日志目录对日志进行采集。
详细的工作方式及调优,请期待云平台实践篇(云平台的能力不仅限于此)。
技术中台同样提供了基于 Jenkins 流水线(Pipeline)的 CICD 平台,经历过两个阶段:项目级的流水线和平台级的流水线。
这两个流水线有什么不同?这个跟平台的发展阶段相关。平台发展之初,由于团队规模小,在 CICD 平台上投入的成本相对较少。由于一开始接入的系统不多,流水线的脚本都放在各个项目的代码仓库中(项目级的流水线),每次脚本更新都要去各个项目中更新。随着接入的系统越来越多,更新的成本变得越来越高。
因此我们在后续的演进中进一步将流水线提升到平台级,即平台上的系统使用统一的流水线脚本,脚本保存在 GitLab 仓库中,并提供版本控制。
借助 Job DSL 插件,我们将抽象的项目元数据转化为 Jenkins 作业。在项目注册到平台时,会自动为其创建作业。
每个作业的结构基本一致,包含:
外部对接云平台、Sonar、Nexus 以及自动化测试平台。
微服务中台不仅仅是技术上的开发工作,还包括中台的落地,以及打造各种配套的功能设施,比如流程的简化、DevOps 还有表面上无法体现的各种优化和修复工作。
后续除了云平台,我们还会分享一些其他方向的经验。“生命不止,奋斗不息”,小鹏汽车的技术中台也会持续演进。
张晓辉:资深码农,12 年软件开发经验。曾在汇丰软件、唯品会、数人云等公司任职。目前就职小鹏汽车,在基础架构团队从事技术中台的研发。