共计 5062 个字符，预计需要花费 13 分钟才能阅读完成。
👉腾小云导读
数字化转型的实质是一个企业一直突破自我壁垒的过程，这种壁垒的突破通常来源于两个方面，一个是技术重构，另一个是组织重构。本次分享次要偏重的是技术重构方面，将围绕如何实现利用现代化，以业务视角找到实现业务云原生化的破局之道，从而取得更高的业务价值。本文依据腾讯云日志服务研发负责人王国梁在 ArchSummit 2023 上海站的演讲内容整顿而成。欢送浏览。
👉看目录，点珍藏
1 腾讯云 CLS 的业务背景和挑战
2 云原生技术的“三个代表”
3 日志服务 CLS 老旧零碎架构挑战剖析
3.1 基础设施凌乱，应该如何革新和抉择？
3.2 有状态利用如何转化为无状态利用？
3.3 如何革新利用的配置管理？
3.4 如何平滑降级架构？
3.5 弹性伸缩，咱们为什么须要它？
3.6 为什么须要流量防护和容错？
3.7 可观测能力的建设和研效？
4 日志服务的云原生化架构和收益
01、腾讯云 CLS 的业务背景和挑战
腾讯云日志服务（Cloud Log Service，CLS）是腾讯云全自研的一站式、高牢靠、高性能日志数据解决方案。反对各种数据源 PB 级的数据接入，提供日志采集、存储、检索、统计分析、数据加工、生产订阅等能力，能够帮忙客户大大降低日志运维门槛，并解决业务数据处理的各种诉求。
CLS 产品能力概览
因为日志和业务属性关联强，业务的高下峰也会间接导致日志量的高下峰。所以与单个业务相比，日志服务的流量洪峰稳定情况更加频繁，也更加不可预估，可能霎时就有几十万 QPS、GB/s 日志写入；
日志数据利用场景也更加敏感，大量客户会间接基于日志配置告警、监控等实时性要求强的场景，就要求日志从产生到可检索进去的提早肯定秒级，更准确的来说要在 3s 以下，不然此时日志的价值将大打折扣。
此外，CLS 在商业化初期，产品迭代十分快，日志量从每天几千万条增长到十万亿条级别，领有百亿级数据秒级检索剖析能力。新增 客户的需要多且简单，技术架构和基础设施古老 ，在应答规模增长、性能要求、迭代需要等多方面压力下，整个服务 稳定性有余 ，研发团队也频于救火，甚至 影响客户口碑、影响支出 **，这也是为什么咱们必须要在技术上实现彻底的革新和降级。
02、云原生技术的“三个代表”
云原生技术对于咱们而言到底意味着什么，这里总结出“三个代表”：
云原生代表着最先进技术生产力的倒退方向
云原生技术（容器、K8S、Serverless 等）都是现在基础设施先进生产力的代名词，技术成熟且被广泛应用；相同，如果基础设施 / 技术理念还放弃古老思路，那必然无奈满足当今业务需要，也会成为企业 / 产品倒退的妨碍。
云原生代表着技术企业产品竞争力的倒退要求
爆炸式的扩张和增长已成为当今新产品和新利用的典型特色，因而产品的研发、测试、公布、交付、运维效率就间接决定了产品迭代周期，研效的晋升肯定水平上决定了咱们的产品是否能够在关键时刻做到“快人一步”。
云原生代表着企业降本增效的技术保障
企业内独立的资源池、资源 Buffer 会导致业务之间重大的“贫富差距”，资源弹性能力差、低效应用间接影响企业经营老本；此外，企业内不同团队的技术栈、架构和反复造“轮子”也会导致研发老本居高不下。
所以，在现在想要实现利用的现代化，云原生技术改造曾经成为企业倒退的必然选择。
02、日志服务 CLS 老旧零碎架构挑战剖析
对日志服务 CLS 而言，在架构上面临的每一个问题都能决定产品最终的成败，例如基础设施凌乱、应突发能力差、性能和稳定性差、服务治理艰难以及资源节约重大，经营老本低等。
3.1 挑战一：基础设施凌乱，应该如何革新和抉择？
CLS 在 21 年绝大部分资源都还是物理机和虚拟机，这会带来一系列问题。
首先是资源环境简单，无论是机型差别、内核版本还是零碎参数等，都会在某个不经意的工夫点导致同样版本的利用行为不统一，对资源上线和保护的要求十分高。
物理机以及虚拟机扩容耗时又是另一个大问题，从提出资源需要到资源到位有时候须要几个小时甚至几天，导致业务侧不得不提前囤资源，但即便囤积 20% 的资源对于业务也是一块不小的老本；其余基础设施的凌乱，例如本地 IDC 和云上治理运维零碎不匹配，监控告警以及观测能力不统一等，成为传统利用面临的最痛点。
基础设施的倒退也经验了从物理机 - 虚拟机 - 容器的演进：
- 服务器：一个服务器外面运行多个业务过程，服务器为物理机或虚拟机，失常每个业务过程是独立的，也存在单个服务多过程的模式。
- 富容器：富容器是企业打包业务利用、实现业务容器化过程中，采纳的一种容器模式。在业务容器化过程比拟受欢迎，因为相似服务器模式，业务无需大的革新老本，也不会对开发和运维造成任何侵入性。一个容器运行多个过程，容器运行时外部主动运行 systemd 等过程作为 1 号过程，而后主动将业务过程和其余辅助过程拉起。公司外部有 Tlinux 镜像，反对业务应用富容器。
- Sidecar 容器：容器外部只有一个业务过程。容器内的 1 号过程就是业务过程，一个利用能够由一个或多个容器组成，他们彼此独立，能够独自降级。
富容器长处在于根本不扭转业务代码和运维代码状况下，疾速从 CVM 迁徙到容器；但实质上是服务器模式到容器的过渡，没有从根本上扭转利用的管理模式，只是把底层介质从服务器转变为容器。
但随着容器技术的倒退，这种模式逐步隐没，更多的还是回到容器实质，一个容器一个过程的模式。随着 K8S 成为容器编排的事实标准，这种模式更合乎云原生的技术要求，也成为以后容器化的规范范式。
3.2 挑战二：有状态利用如何转化为无状态利用？
云原生革新过程中，业务无奈躲避的问题是如何对有状态利用和无状态利用容器化，CLS 在实际过程的教训是：尽量实现全副利用为无状态利用。
无状态代表利用随便横向扩容、宕机甚至随时随地被删除，对服务自身都不会有影响，以此提供高并发的服务能力和更高的容灾能力。
有状态和无状态相比：
- 有状态自身须要保留状态或用户会话，这肯定水平上就减少了解决的复杂性，而无状态则不须要存储任何信息；
- 有状态中一个申请只能被一个实例解决，无状态中任何申请能够被任何实例解决；
- 与无状态利用相比，有状态利用更加简单，扩大更难；
- 有状态对于故障的容忍度低，有时候须要迁徙和同步数据；而无状态利用则不须要，这也是为什么咱们冀望，最好服务不存在有状态的利用。
传统业务大多都是有状态的利用，那咱们应该如何去革新利用架构呢？常见的能够通过两种形式将服务从有状态转变为（近）无状态的服务：
实现多个实例能够相互同步数据，任何一个实例异样都是对等的，能够容忍任意删除和扩容；
实现数据集中存储，将状态信息转变为存储，实例只需从集中存储拉取数据到本地缓存即可。
3.3 挑战三：如何革新利用的配置管理？
云原生革新过程会有一个新的问题是，在简单的云原生应用程序中治理配置信息是十分艰难的，仿佛到处都有配置。在应用基于微服务架构的云原生应用程序中，配置问题会成倍增加。
有针对网络的配置，比方路由规定、端口管制、负载平衡；有针对数据库的配置，服务器的配置，还有泛滥微服务中间件的配置。这些配置大多是零散存储，并且不足治理的。
所以首先要为所有配置对立可信起源，对立配置管理，或者叫配置核心。
此外，配置有些时候会被复制到各处。将一台服务器中应用的配置复制到另一台服务器，而后再复制到另一台服务器。最终，可能会有数百个雷同或简直雷同的配置正本。
所以配置的版本治理就十分重要，保留对配置的所有更改的历史记录；进行更改时，能够记录更改人和更改起因。
随着工夫的推移，配置会产生漂移，导致配置谬误、应用程序故障甚至安全漏洞。其实每个正本的配置其实不尽相同，每个配置正本都须要进行小的更改，就须要定义变量并主动以完全相同的形式保护相似的配置文件，且不会在每次应用配置时发生变化漂移。
这就要求咱们要能进行自动化的配置管理，应用 CI/CD 管道是古代云原生应用程序的规范策略，部署管道应部署所有配置以及所有代码。这能够实现变量的统一利用和对宏的更改，并确保所有更改都部署在须要配置的所有组件中。
为了实现这种降级，咱们须要革新老服务兼容新的配置模式，因而咱们要解决另一个问题，就是如何平滑降级？
3.4 挑战四：如何平滑降级架构？
架构降级对业务无感知是咱们谋求的最终目标，要求咱们要具备平滑的降级流程、牢靠的灰度策略以及欠缺的可观测能力。
咱们的过程很清晰：
- 金丝雀模式：从小地区、局部客户开始切换，逐渐灰度实现全副流量的切换；
- 过程：老服务放弃不变，新服务切换实现后仍旧保留 2 周，后续再下线；
- 危险：危险极小，呈现问题可随时切回；
在降级之前咱们须要做好很多工作，包含新老服务的兼容，不便随时回滚切换；也包含降级预案的筹备，以及咱们如何验证切换到新服务。
3.5 挑战五：弹性伸缩，咱们为什么须要它？
实现弹性服务，就离不开弹性伸缩能力的建设。咱们面临 3 大次要场景的问题：首先是突增流量咱们如何应答？提前扩资源势必会导致大量的资源节约；第二个是扩容资源量上来后，什么时候缩容呢？不缩容造成资源节约，缩容得快又怕来回抖动；最初一个是周期性的流量如何爱护链路更加稳固？
在业务场景，咱们首先须要实现的是应答突发流量，解决了这个痛点后，咱们才会思考降低成本，老本有了保障后，咱们才会进一步思考如何让咱们的服务更稳固。
所以，从这几种场景咱们能够总结弹性伸缩的“应突发、降老本、保稳固”的 3 步走策略：
- 应突发: 利用 HPA 实现在失常水位之外的突增流量主动弹性扩容，保障服务质量；
- 降老本: 利用 HPA 实现节省成本并且可能应答突发；
- 保稳固: 可能感知服务链路上下游同步扩缩，以及用户自定义指标弹性伸缩。
在理论的策略利用过程，咱们还须要关注扩容和缩容的技巧：
- 快扩容：尽快扩容进去 Pod 来承当增长的流量；
- 慢缩容：CPU 使用率短时间稳定较大，缩容速度如果过快，很有可能导致缩容后利用率回升又须要扩容。
践行这样的策略和准则，弹性伸缩就能施展最大的价值。
3.6 挑战六：为什么须要流量防护和容错？
日志服务其实是十分多业务的汇合，同时面临对外和对内两方面的危险治理。
因而，CLS 设计了全链路接入和流量治理能力，能够应答每一个已知场景的问题：包含客户端本地缓存、退却重试、异样上报实现端到端的观测能力，接入链路实现基于泛域名的 DNS 隔离、限流、限频、隔离拉黑等，能够应答异样上报和攻打等；外部首先全弹性能力接入，理论场景能够实现分钟级扩容上万外围资源，针对依赖零碎的容灾降级以及最终的兜底复原。
3.7 挑战七：可观测能力的建设和研效
最初但也是最重要的问题：零碎的可观测能力。
- 被动发现问题：问题发现依赖客户反馈，发现问题就是工单或故障；
- 故障继续时长过长：发现问题过晚，故障可能曾经继续了很久，影响大；
- 故障范畴未知：很难给客户及时反馈故障影响范畴以及复原速度和预期；
- 频于救火：研发团队苦，常常中午和节假日解决故障，产品稳固差，导致业务口碑差，丢单危险大。
利用的可观测其实曾经超过了咱们应用的监控和告警自身，须要从 用户视角、利用自身、中间件零碎、基础设施 等多方面进行数据收集和剖析，实现从代码到用户的端到端可观测能力建设，包含监控大盘、业务剖析、链路追踪和智能运维等，实现对立的利用可观测能力。
研效的晋升次要有两点：
CI 流水线的建设：咱们现网有十分多的工单和问题，工单解决在某半年成为累赘最重的工作，基于问题的自动化用例建设每次公布都回归历史问题，为了在短时间内将工单疾速收敛，CLS 建设了 1000+ 用例，保障版本迭代的兼容性和稳定性；也包含代码剖析、单元测试覆盖率等门禁。
利用的公布编排：云服务产品有几十个地区，公布工作之前每周须要投入 2 - 3 个人力，基于利用的编排在效率的晋升非常明显，也缩小了人工犯错的概率。
04、日志服务的云原生化架构和收益
通过上述一系列云原生革新，最终日志服务 CLS 实现的全自研架构指标：围绕云原生技术（容器、K8S、申明式 API、弹性伸缩等），建设合乎古代利用和数字化业务的倒退需要架构。
整个架构演进破费了近 1 年的工夫，经验了三个比拟大的阶段，实现了从 0 到 95% 以上利用的容器化，经营老本节俭 2 千万 +/ 年，缩小 2 +HC，节俭了 10 万 + 核的资源，同时扩缩容耗时升高 90%，资源利用率晋升 40%+。
同时日志服务 CLS 产品稳定性可达 99.99%+，领有适应客户场景 PB 级突发流量的弹性接入能力；作为平台级云服务，本身的云原生革新也进一步助力客户数字化降级的疾速迭代和价值交付。
以上是本次分享全部内容，欢送大家在评论区分享交换。如果感觉内容有用，欢送转发～
-End-
原创作者|leonglwang
技术责编|leonglwang
