关于腾讯云:如何削减-50-机器预算人机对抗探索云端之路

前言

人机反抗旨在联结各个平安团队，独特治理黑灰产。因为历史起因，业务端对各个平安能力的拜访形式入口多，对接零碎 / 协定有十几个，出现碎片化的状态，对外不利于业务对平安能力的便捷接入，对内不利于平安团队间的协同共建。为了晋升各方面的效率，人机反抗服务在建设过程中大范畴应用云服务，获得了很好的成果。回顾平安能力上云的过往，是一个从含糊到清晰，从踌躇到动摇的过程，在此给大家做个简要的分享。

对于云

云是什么

我了解的云实质能够了解为自在灵便的资源共享。资源随时退出，随时脱离，如地面飘动的云，来去无定，云起云落，看起来是那片云，细看又不一样。

对云的期待

站在计算机利用的角度，现实的云是能够让计算 / 网络 / 存储资源变成生存中的水和电，操控开关即可呼之即来挥之即去。比照物理机部署时代，云用户不必因某台机器死机造成数据损坏而暴走，也不必因机器损坏加班复原服务而黯然神伤，

• 主动容灾(异样拉起，故障迁徙)
• 轻松异地部署(多集群)
• 资源隔离 - 死道友不死贫道，你贪婪了，安眠吧

• 快捷扩容，资源呼之即来，来即能战

  所有如许完满，开发运维测试兄弟的福音啊！

零碎上云剖析

随着公司根底服务的欠缺，目前公司内已有的服务设施可反对咱们上云。通过调研发现，公司云相干平台及部署形式有:

CVM

在物理机根底上是对机器硬盘及 cpu 等资源做了虚拟化，用户应用形式上实质还是物理机的形式，只是能够防止机器裁撤的苦楚，用户体验层面上没有实质的扭转。

容器化部署平台

docker 容器化部署是目前业界云次要部署形式，docker 容器化部署让咱们一次建构，到处运行，完满满足自在运行，资源隔离的要求，零碎环境人造是强保护的，所有程序 / 脚本 / 配置都在镜像中，不再有失落或脱漏保护的问题。物理机时代机器损坏导致脚本配置毁坏无奈复原的景象不会再呈现，系统维护靠盲目或强束缚这些问题人造地隐没了。

而相似 K8s 这样的容器编排调度零碎的呈现，反对了主动容灾 / 故障切换 / 多集群部署等弱小的平台个性，使咱们离云服务的指标更近一步。基于 K8s 容器编排调度机制，目前公司内开发出一系列的部署平台，比方 123 平台，GaiaStack，TKE 等，再完满配合 L5/ 北极星等寻址服务的主动关联治理，为云服务提供了残缺的平台机制撑持。再加上基于资源管理平台对资源的灵便调配，使云计算应用的便捷性更上一台阶。比方在云梯上资源申请 TKE 容器资源(CPU/ 内存 / 存储等)，过程就像到淘宝下单购物一样晦涩，资源到位疾速，在强推动审批下可达到分钟级到位，我第一次体验时是诧异赞叹的。

基于对公司服务的深刻理解及剖析，最终咱们决定应用 TKE 部署平台，采纳 docker 容器化部署的形式对人机反抗服务上云

上云对开发的外围影响

上云带来一个外围变动就是资源是易变的，为了便于系统资源调度，服务结点 IP 是可变的，上云后须要面对包含上游业务端 / 本身 / 上游依赖端的 IP 变动，由此衍生出一系列的束缚及依赖

1. 上游变动: 对客户端通过起源 IP 鉴权模式不再可行，须要一种更灵便有弹性的鉴权形式
2. 本身变动: 对外服务地址可将服务地址关联绑定到北极星的形式向外提供服务，如果所依赖的上游须要鉴姑且应用源 IP 鉴权的话，上游须要革新反对更灵便的鉴权形式。少数状况下，服务须要对本身做一些例行运维工作，比方须要频繁批改配置下发，老的运维工具不再行得通，须要一个集中的运维配置核心。
3. 上游的变动: 这个倒问题不大，只有提供 L5 或北极星形式主动寻址即可，目前平台提供了相应的服务治理性能。

零碎架构及上云布局

人机反抗数据中心次要模块为变量共享平台，它的外围有 2 个，一个查问服务模块，另一个是反对变量治理 api 的 web 模块，这两模块都基于 tRPC-Go 框架开发，零碎架构图如下:

疏忽一些依赖零碎，目前临时只对两个外围局部应用 TKE 部署上云，整个 TKE 部署架构如下:

整个零碎的部署布局，别离在 TKE 上创立两个零碎负载 black_centre，http_apiserver，这两局部都是外围，其中 black_centre 承载用户的变量查问，web 端的申请通过智能网关，再通过 CLB，而后进入 http_apiserver 才失去了真正的业务解决，次要反对查 case 及零碎变量治理，变量查问接入申请等性能。大家可能留神到，为什么 http_apiserver 引入了 clb 而不是间接由智能网关拜访，次要因为模块上云后，计算结点的 IP 是随时可能变动的，然而公司外部申请域名指定服务地址时是不反对北极星或 L5 配置的，只能配置固定 IP，而 CLB 提供的固定 VIP 的个性，很好地解决这个问题。

这里简略提一下 CLB（Cloud Load Balancer），它是对多台云服务器进行流量散发的服务。CLB 能够通过流量散发扩大利用零碎对外的服务能力，通过打消单点故障晋升利用零碎的可用性。最常见的用法时是依据关联转发规定(拜访端口 /http url 等，主动转发到规定绑定的工作负载上。回到人机反抗的利用场景，咱们次要是低负载的 http 服务，多个服务只有配置一下对 url 的转发规定就能够共用同一个服务地址资源。比方集群服务 A 和 B 都对外提供 http 服务，然而都须要应用 80 端口，按传统形式个别至多须要部署两台机器，然而利用共享的 CLB，咱们只有配置 url 散发规定，就能够将不同接口散发到相应的云服务上。当然应用 nginx 也有相似的性能，然而易用性可维护性稳定性方面，CLB 强了不止一个级别

TKE 云利用部署时，容器易于缩扩容，容器自身个别不固定在某个 IP 上，所以云利用天生就应该设计为无状态依赖的模式。整个镜像尽量小，业务逻辑尽量微服务模式，防止同时糅合过多的逻辑。因为人机反抗相干模块是一个全新的模块，没有太多的负累，尽管协定灵便兼容性强，然而实质上性能独立，责职繁多的，比拟好地适应了这个场景。

至于如何申请资源，如何创立空间，创立负载之类的，流程很长，就不再大量截图了，产品帮忙文档曾经提供了较良好的指引，可参见 https://cloud.tencent.com/doc…，尽管我应用的是内网 TKE，但内外网的云服务，总体上体验差异不大。

在应用 TKE 过程中，继续感触到 TKE 的弱小和稳固，但最迫切的感触是须要一个容器参考复制性能，因为在事实的应用场景中，常常是想基于某个已存在的容器，稍修 2 - 3 个参数(大概率就是负载名 / 镜像版本)，就能疾速把负载创立起来。罕用应用场景是测试验证 / 异地部署，或负载重部署(负载中有很多参数改不了，要改只能重建)，甚至部署新服务(跟已有负载的资源应用及运行模式一样)。当初碰到要创立新负载，要填很多参数操作多了就感觉很繁琐，小需要，大提高，如果能解决这个问题，TKE 应用的便捷性置信也能上一大台阶。

发现云中君

从下面的架构流程剖析来看，筹备好镜像，利用 TKE 平台咱们的服务曾经跑起来，然而他人怎么找到我的服务地址? 有人说将服务地址录入 L5/ 北极星搞定，然而不要忘了，云结点运行过程中，服务 IP 是随时可变的，须要想方法把云服务的变动的地址跟北极星建设关联，对北极星的地址列表进行关联治理，能力真正做到举重若轻。刚好 TKE 就提供了这样的个性，完满实现咱们的目标。按上面的步骤来可解决:

1. 创立负载，就是让服务跑起来，咱们的曾经没问题了。
2. 为负载创立一个对应的北极星服务，供前面应用。
3. 新建北极星关联规定，先进入北极星关联操作页面如下图

留神抉择到对应的业务集群，进入创立页面:

如此这般，把曾经创立的北极星服务信息填进去，再跟指定的容器服务关联起来，再提交实现，最初实现北极星与动静服务地址的绑定

当咱们对负载中的容器服务进行扩缩容时，咱们能够发现北极星服务中的地址列表也会跟着进行减少或删除，这样无论服务部署变更或容灾迁徙，业务方看到的服务地址都是无效的。

同时北极星为了兼容一些老用户应用 L5 的习惯，还反对对北极星服务创立 L5 的别名，用户能够利用别名，应用 L5 形式，就能够欢快寻址到与北极星公布的雷同的服务。进入北极星官网左侧的菜单栏 ” 服务治理 ”->” 服务别名 ” 创立别名

过往剖析是老版本的 l5agent 对这方面兼容性不够，把 l5agent 降级到最新版本就能解决了。

云上鉴权思路的扭转

零碎上云后，因为结点 IP 的不固定，带来最典型的变动就是鉴权模式的影响。老模式下的按起源 IP 鉴权曾经不实用，须要应用更灵便的鉴权形式。业界罕用的两种认证鉴权的计划:

1. SSL/TLS 认证形式，这种形式常常被用来做传输加密，而不是访问控制，tRPC-Go 的 API 曾经有了相应反对。
2. 基于 Token 的认证形式，这也是本零碎重点要实现的计划

尽管办法很多，然而咱们须要依据不同的场景依据需要抉择不同的计划。

上游接入鉴权

当用户申请接入拜访时，须要对用户进行认证鉴权，起源 IP 鉴权必定是行不通的，衡量之下咱们应用了 token 鉴权的形式，当用户申请接入时，咱们会给他们调配 appid/token，当用户来拜访时，咱们会要求他们在音讯头中带上工夫戳，序列号，appid，rand 字符串，签名。其中签名依据工夫戳，序列号，appid，rand 字符串及 token 联结生成。当服务端收到申请时，也会依据相应的字段应用与客户端同样的算法生成签名，并与申请的签名做比拟，如果统一则通过，否则回绝。其中工夫戳的作用可用于防重播。

其实公司内的鉴权平台 knocknock 也提供了一套 token 签名鉴权形式，它是一种基于 tRPC-Go 认证鉴权形式。然而基于用户拜访的简略性及升高平台依赖，所以最终人机反抗按下面的思路定制了本人的 token 鉴权形式。

上游依赖鉴权

目前咱们的上游比较简单，大数据查问代理 (见架构图) 曾经革新为反对 token 鉴权形式，ckv+ 是登录时明码鉴权形式。除了 CDB，其它服务没有太多的问题。拜访 CDB，按平安标准不容许应用 root，而且须要针对 IP 受权拜访，而受权须要先指定特定 IP，在上云过程中，容器 IP 常常漂移。这些状况 TKE 曾经在布局实现跟业务上游买通受权，CDB 就在其中。各个业务也能够对接 TKE 来买通注册。其实实质是在 CDB 与 TKE 之间减少一个主动注册机制，依据服务 IP 的变动，主动将 IP 注册到 CDB 的鉴权列表，逻辑上相似北极星之与 TKE 负载变动的关联关系。

为什么是 tRPC-Go

在人机反抗服务平台建设开始阶段，已经面对过语言框架选型问题，部门原来习惯 c ++，框架上有 SecAppFramework 或 spp framework，新零碎咱们要怎么抉择? 答复这个问题前，回到咱们面对的问题及指标:

1. 访问量大，高并发性要求及较高的机器资源利用率
2. 业务的疾速倒退要求咱们高效撑持，包含开发 / 运维公布 / 定位问题 / 数据分析
3. 公司内各服务上云是趋势，将会用到公司内各种云相干平台及服务，所用语言及 framework 最好能方便快捷把这些能力用起来，c++ 及 AppFramework 看起来就头大，各种服务撑持不够或用起来很难，有点力不从心，

面对部门老框架 /spp Framework/tRPC-cpp/tRPC-Go 等一系列的抉择，从性能 / 开发便捷性 / 并发管制 / 周边服务撑持丰盛水平多个角度，最终选用了 tRPC-Go，指标就是围绕研效晋升，更细化的剖析如下:

1. Golang 语言简略，各种代码包齐备丰盛，性能靠近 c ++，然而天生反对协程且并发管制简略，简略的并发设计就可榨干机器资源，绝对 c ++ 心智累赘更低，生产能力更强。
2. spp framework 和 tRPC-C++ 等公司内的一系列协程框架都是基于 c++，同时 spp 框架下，worker 单过程最多只能应用单核，而且 proxy 自身会成为瓶颈，tRPC-C++ 也应用过，复杂性比拟高
3. tRPC 是公司力推的 OTeam，并在不断完善，tRPC-Go 服务接口开发简略，而且周边服务反对组件丰盛，减少到配置文件即能够跑起来，比方北极星 /L5，智研日志 / 监控，各种存储拜访组件(比方 mysql/redis 等)，应用 R 配置服务等。开发层面各个环节根本笼罩，再加上原来有肯定的应用应用教训，相熟水平高，调用各种服务如臂使指。

应用 tRPC-Go 构建零碎过程中，除了在相熟过程碰到一些问题，但没碰到过很大的坑，代码写错也能很快定位，没碰到过那种神鬼莫测的诡异问题。总体上是晦涩顺滑的，心智累赘轻，能更聚焦于业务，生产能力强

众生之力加持

除了模块的外围逻辑，为了让服务更稳固，运维更高效，须要一系列的周边服务来反对，比方日志 / 监控 / 配置核心等反对服务

对立日志

云上结点，写本地日志对定位问题是不适合的，最外围起因在于问题呈现时，本地日志你得先找到问题所在的结点再进去查看，光这个就是个麻烦的过程，而且云结点重启可能会使日志失落，所以应用一个对立的网络日志核心势在必行，目前公司内支流的日志服务有:

• 智研，TEG 产品，操作简略，易用，在验证码有成功实践。在 tRPC-Go 框架应用下，更简略易用，只有配置一下，不批改业务代码就能够把日志转发到日志核心
• 鹰眼，零碎功能丰富，但接入简单，易用性须要增强
• uls，cls 等

最终选用的是智研日志，次要是在满足要求条件下足够简略易用，在 tRPC-Go 加持下，仅须要:

1. 在代码中引入代码包
2. 在 yaml 中简略配置即可应用:

​

在问题定位的时候，能够在 web 端查看日志:

具体中间件实现细节及帮忙可见 tRPC-Go 上面的智研日志插件工程

弱小监控

监控服务有:

1. 智研: TEG 产品，多维度监控，功能强大易用，应用简捷，部门内屡次应用验证
2. monitor: 基于属性定义的监控，老产品，成熟稳固，然而监控形式繁多
3. 007: 零碎功能丰富，接入简单，易用性须要增强

最终选用的是智研监控，智研的多维度监控，使监控能力更丰盛，定位问题更疾速，且应用足够简略，在 tRPC-Go 体系下，仅须要插件配置 / 插件注册 / 调用 api 进行数据上报，即可实现例行的数据监控，同时多维度监控，能够利用适合的维度定义，使监控数据更平面，更利于剖析问题:

以下面这个图为例，能够定义一个变量查问的指标，关联起源 ip/ 处理结果两个纬度，在咱们关注对应业务的拜访状况时，能够看到来自每个起源 IP 的访问量，也能够看到每种处理结果 (如上图) 的各个访问量，服务的整体状况高深莫测，跟原来 monitor 监控相比，这是一个维度晋升。

对立配置核心

咱们的业务个别是基于肯定配置运行的，咱们也会常常批改配置再公布。过来传统的形式是到每个机器上批改配置文件，再重启。或是把配置集中存储，各机器上模块定时读取配置，再加载到程序中去。在 Oteam 合作的状况下，公司提供了各种配置同步服务，目前公司次要有两种同步计划:

T 配置服务

应用简略，功能丰富水平个别

配置权限管制繁多，经征询数据加密方面也没版本打算

R 配置服务

公司级计划，有专门的 Oteam 反对

配置同步有权限管制，后续会反对加密个性

配置模式反对丰盛，json，yaml，string，xml 等

反对私有 / 公有配置组，不便配置的复用及配置在模块间的划分，同时反对灰度 / 分步公布

两个服务在 tRPC-Go 的开发模式下都简略易用，而且数据批改后后盾能够即时失效，综合思考下最终选用 R 配置服务做为配置同步同台，应用形式比较简单:

1. 先在 R 配置服务上注册我的项目，并配置分组
2. 在代码中连贯 R 配置服务，读取数据并侦听可变配置项的变动。

上面是简略易用的操作界面:

以对外公布变量 ID 的配置为例，这个 ID 列表会依据需要不停减少或批改，只有用户在 web 端批改公布，云上各结点就能感知到配置的变动并立刻失效。无论是服务稳定性还是公布效率，绝对传统配置批改公布形式都有了质的晋升

tRPC-Go 对服务进行插件模式的设计，大大简化了各个服务的调用形式，再加上 tRPC-Go 上面沉闷的开源我的项目，对研效的晋升超过 50%。以咱们罕用的拜访 mysql/redis 为例，以通常的开源库应用或封装，须要解决异样 / 连接池封装 / 寻址封装 (公司内应用 L5 或北极星) 等，开发 + 测试根本须要 1 - 2 天，然而应用 trpc-go/database 下的对应开源组件可降到 2 小时左右。再说配置同步 / 日志核心服务的应用与自研或半自研相比，开发工夫能够由 2 天降到 4 小时。主观而论，相干组件如果自研或半自研，在这么短的工夫内，只能做到定制能用，稳定性通用性方面，置信是较难比得上平台服务的。要害是公司内的代码协同及各种 Oteam，将会有个性日益丰盛弱小的过程，他们成熟度的的晋升，也会衍化为整个组织生产力的跃升。整体评估，应用公司内成熟的中间件是一个正确的抉择

上云带来了什么

目前人机反抗服务一直在引入老零碎流量或接入新业务，整个零碎读写访问量最高超过 1200 万 /min，变量纬度拜访流量最高达 1.4 亿 /min(单个拜访申请能够拜访多个变量)。整个服务在云上稳固运行超 3 个月，不负众望。

稳定性晋升

疏忽模块自身的代码品质，稳定性提供次要是由云上容器部署所具备的几个平台个性所带来的:

1. TKE 反对服务心跳查看，利用异样拉起，故障迁徙

2. 轻松反对异地部署，多地容灾
3. 资源隔离，异样业务不影响失常业务

如果 99.999% 是咱们对服务稳定性的谋求，绝对老部署模式下小时 / 天级别的机器异样复原工夫，服务稳定性晋升 1 - 2 个 9 这是能够预感的

晋升资源利用率

在物理机 /CMV 的部署模式下，个别整机资源利用率达到 20% 就不错了，特地是一些小模块。然而上云后 TKE 的弹性扩缩容机制之下，通过配置轻松能够使容器资源利用率达到 70%。

比方上面就是目前我的利用大盘监控，为了应答可能的大流量冲击，我配置了主动扩容，且设置了较多的根底结点数，所以 cpu 占用率较低，实际上这些都是能够配置的。云上容器模式部署绝对传统模式能够晋升 50% 的系统资源利用率。

上云后的晋升

1. 利用公司内的开源技术，需要开发效率晋升 50% 以上
2. 因为机器资源利用率的晋升，人机反抗方面的机器估算比原来缩减了 50%
3. 各种服务的中心化使得公布及问题定位变得更快捷，比方 R 配置服务及智研的投入使用，公布及问题解决由半小时 -> 分钟级
4. 容器部署模式，零碎进入人造强保护状态。因为镜像是残缺可重演的，有问题修复后也会必定记录入库，没有失落或脱漏的后顾之忧。在物理机 /CVM 时代，程序 / 脚本 / 配置很可能是繁多搁置到某个机器上(特地是某些离线预处理零碎)，机器损坏或零碎解体这些货色就没了，当然你会说物理机部署也能做到备份或及时入库，然而那须要依赖于人的盲目或对行为的强束缚，老本是不一样的。然而大多数状况下，墨菲定律会变成你绕不开的梦魇

结语

回首这么多年核心和公司在研效晋升的致力，零碎框架从最开始的 srv_framework，到核心的 Sec Appframework，再到 spp framework 等各种协程框架，再到 tRPC 的蓬勃发展。数据同步一致性从手工同步，主备同步，到应用同步核心同步再到公司内的各种分布式存储服务，零碎部署从物理机手工部署到各种形形色色的公布工具到织云蓝鲸，从物理机，CVM 再到承载服务的云失去大规模业务的胜利验证等，公司的研效晋升一路走来，从一个蹒跚学步的小孩，成长为一个健步如飞的少年。站在古代算力体系巅峰的云上回望，公司对云的的意识和摸索实际，也经验了从含糊到清晰，从踌躇到动摇的过程，而咱们的致力并没有被这个时代所辜负，一串串晋升的各种指标形容及用户的认可就是对咱们的必定和嘉奖，激励咱们义无反顾向将来前行。

意识并建设云，翻新并开辟云，咱们脚踏大地，可是咱们更俯视星空。子在川上曰：“逝者如斯夫！不舍昼夜。”

以上是我在人机反抗上云过程中的一点实际跟感悟，跟大家分享共勉。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！