PaaS工作思考和规划

jay123jay123

于 2024-11-26 16:36:02 发布

阅读量875

点赞数 24

CC 4.0 BY-SA版权

文章标签： paas 云原生云计算

本文链接：https://blog.youkuaiyun.com/jay123jay123/article/details/144062339

一、PaaS 技术趋势

（一）围绕应用为中心，开启云原生 2.0 时代

云原生 1.0 的局限性：以往企业将业务从线下搬迁上云，此阶段企业主要是将业务简单部署和运行在云上，可称为 “ON CLOUD”。在这种形态下，通过资源池云化，解决了 IDC 时代运维、部署、扩容的难题。然而，传统应用单体架构厚重、烟囱式架构等带来的一系列应用层面的问题并未得到有效解决。此时，云对业务的价值主要停留在资源供给阶段，无法充分发挥云的价值。
迈向云原生 2.0：为了充分发挥云的价值，需要让业务能力 “生于云、长于云”，即由现在的 “ON CLOUD” 进阶到 “IN CLOUD”。同时，基于云构建的新生能力与既有能力应有机协同、立而不破。“生于云” 是指基于云原生的技术、架构和服务来构建企业应用；“长于云” 是指充分利用云的优势助力企业应用和业务发展，将企业的数字化建设、业务智能升级带入新阶段。

（二）云原生 2.0 主要技术架构演变进化

服务化架构模式：
- 架构特点与要求：服务化架构是云时代构建云原生应用的标准架构模式。它要求以应用模块为颗粒度划分软件，以接口契约（如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此互联互通。结合 DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署等方式提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务（Mini Service）模式。其中，小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的软件系统，可避免接口颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。
- 优势与挑战：通过服务化架构，可将代码模块关系和部署关系分离，每个接口可以部署不同数量的实例并单独扩缩容，使整体部署更经济。此外，由于在进程级实现了模块分离，每个接口都可以单独升级，从而提升了整体的迭代效率。但需注意，服务拆分可能导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会使模块管理和组织技能不匹配，反而导致开发和运维效率降低。
Mesh 化架构模式：
- 架构原理：Mesh 化架构是将中间件框架（如 RPC、缓存、异步消息等）从业务进程中分离，使中间件 SDK 与业务代码进一步解耦。这样一来，中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后，在业务进程中只保留很 “薄” 的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通讯。原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。
- 架构优势：实施 Mesh 化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓等）都由 Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包。同时，还能获得更好的安全性（如零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。
Serverless 模式：
- 架构特点：与大部分计算模式不同，Serverless 将 “部署” 这个动作从运维中 “收走”，使开发者不用关心应用在哪里运行，更不用关心装什么操作系统、怎么配置网络、需要多少 CPU 等问题。从架构抽象上看，当业务流量到来或业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭或调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。
- 适用场景：目前，Serverless 还未达到任何类型的应用都适用的地步。架构决策者需要关心应用类型是否适合于 Serverless 运算。如果应用是有状态的，云在进行调度时可能导致上下文丢失，毕竟 Serverless 的调度不会帮助应用做状态同步；如果应用是长时间后台运行的密集型计算任务，会得不到太多 Serverless 的优势；如果应用涉及到频繁的外部 I/O（网络或者存储，以及服务间调用），也因为繁重的 I/O 负担、时延大而不适合。Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务。
可观测架构：
- 架构内容：可观测架构包括 Logging、Tracing、Metrics 三个方面。其中，Logging 提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；Tracing 提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics 则提供对系统量化的多维度度量。
- 架构实施要点：架构决策者需要选择合适的、支持可观测的开源框架（如 OpenTracing、OpenTelemetry），并规范上下文的可观测数据规范（例如方法名、用户信息、地理位置、请求参数等），规划这些可观测数据在哪些服务和技术组件中传播。利用日志和 tracing 信息中的 span id/trace id，确保进行分布式链路分析时有足够的信息进行快速关联分析。由于建立可观测性的主要目标是对服务 SLO（Service Level Objective）进行度量，从而优化 SLA，因此架构设计上需要为各个组件定义清晰的 SLO，包括并发度、耗时、可用时长、容量等。

以上为三种主要架构的演变进化，以及云原生可观测架构来辅佐应用在云上的稳定运行。

二、云原生 2.0 下的 PaaS 运维方式

运维平台一般都经历过手工、脚本、工具、平台、智能化运维等几个发展阶段。现有运维平台虽然实现方式众多，但总体来说分为两类：

（一）指令式

最开始的运维系统一般都是指令式的，通过编写脚本来完成运维动作，包括部署、升级、改配置、缩扩容等。脚本的优点是简单、高效、直接，相对于更早之前的手工运维，这是一种极大的效率提高。在分布式系统和云计算起步阶段，采用这种模式进行运维是完全合理的。基于这个方法，各个部门都会相应建立一些系统和工具来加速工具的开发和使用。

然而，随着系统复杂性逐步提高，指令式的运维方式的弊端也逐渐显现出来。简单高效的优点同时也变成了最大缺点。因为方式简单，所以无法实现复杂的控制逻辑；因为高效，如果有 bug，那么在进行破坏时也同样高效。往往一个小失误就会导致大面积服务瘫痪：一个变更脚本中的 bug，可能会导致严重事故。在复杂的运维场景下，指令式的运维方式具有变更操作副作用，如不透明、指令性接口一般不具有幂等性、难以实现复杂的变更控制、知识难以积累和分享、变更缺乏并发性等缺点。

（二）声明式

声明式接口的方式相比指令式多一个执行引擎，把用户的目标转化为可以执行的计划。声明式接口实际上代表了一种思维模式：把系统的核心功能进行抽象和封装，让用户在一个更高的层次上进行操作。

采用声明式接口，用户只需通过一种方式描述其要到达的目的，而并不具体说明如何达到目标。

三、友商华为竞品分析

（一）PaaS 产品矩阵概况

PaaS 主要产品介绍：
- 应用编排服务 AOS：通过应用模板，提供华为云上以容器应用为核心的业务应用与资源的开通和部署。将复杂的业务应用与资源配置通过模板描述，实现一键式容器资源与应用的开通与复制。同时提供示例的应用模板，覆盖多种业务场景，方便用户直接使用或为用户设计个性化模板提供参考。
- 函数工作流 FunctionGraph：新一代 Serverless 函数计算与编排服务。基于事件驱动的函数托管计算服务。通过函数工作流，只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数以弹性、免运维、高可靠的方式运行。此外，按函数实际执行资源计费，不执行不产生费用。
- 分布式数据库中间件 DDM：解决数据库分布式扩展问题，突破传统数据库的容量和性能瓶颈，实现海量数据高并发访问。支持 hash 和 range 两种拆分类型，包含多种拆分算法，轻松分库分表；分层架构确保计算、存储都可线性扩展，完美解决单机数据库水平扩展瓶颈；充分利用数据节点（RDS for MySQL）的只读能力，业务零改造，亚秒级数据延迟；支持 DBA 在线管理逻辑库，可根据监控和日志，自定义设置数据库引擎参数。
- 数据管理服务 DAS：赋能和解放开发、运维和 DBA。从基本的主机和实例性能数据，到慢 SQL 和全量 SQL 分析，从实时的性能分析诊断，到历史运行数据的综合分析，能够快速定位出数据库运行中的每一个问题、提前发现潜在风险点。展示慢 SQL 数量趋势和 CPU 占用率曲线，可以直观地定位到慢 SQL 导致 CPU 飙高的问题。可对慢 SQL 进行模板化汇总，根据执行次数、耗时、锁等待时间等指标进行排序，快速找出 TOP N 的慢 SQL。支持自动对慢 SQL 进行诊断，给出 SQL 优化建议，帮助开发者对 SQL 进行自助优化。实时会话和慢 SQL 列表展示，支持一键 kill 会话。全方面的数据库实例的性能及运行状况图形直观展示，能帮助客户快速定位问题。不仅可以直观展示历史性能指标曲线，还能选择不同时间段的性能进行对比分析，也可以自定义生成不同需求的性能指标曲线，多维度分析，帮助客户快速定位、快速恢复故障。
- 应用管理与运维平台 ServiceStage：面向企业的应用管理与运维平台，提供应用开发、构建、发布、监控及运维等一站式解决方案。提供 Java、Go、PHP、Node.js、Docker、Tomcat 等运行环境，支持微服务应用、Web 应用以及通用应用的托管与治理，让企业应用上云更简单。支持原生 SpringCloud、ServiceComb、Dubbo、Service Mesh 主流生态，内置运行时支持 Java、Go、PHP、Node.js 和 Python 等多种语言，并提供自定义 runtime 的支持。支持与 DevCloud、Gitlab、Github 等代码仓对接，本地开发与云上托管无缝集成。
- 云性能测试服务 CPTS：为应用接口、链路提供性能测试的云服务，支持 HTTP/HTTPS/TCP/UDP 等协议。CPTS 丰富的测试模型定义能力可以真实还原应用大规模业务访问场景，帮助用户提前识别应用性能问题。提供灵活的数据报文、事务定义能力、支持多事务组合，事务压测曲线定义，轻松应对复杂测试场景。提供专业性能测试报告，包括事务并发、TPS、吞吐量、响应时延、资源使用、调用链跟踪等多维度统计。
- 应用性能管理 APM：实时监控并管理企业应用性能和故障的云服务，帮助企业快速解决分布式架构下问题定位和性能瓶颈分析难题，改善用户体验。非侵入式性能数据采集，无需修改业务代码即可轻松接入；全链路 APM 提供应用性能追踪能力，用户通过应用全景拓扑，实时了解应用的运行状态，快速故障诊断；AI 智能阈值检测，机器学习历史基线数据产生告警，通过 RCA 分析找到问题根因；分钟级别定位，应用出现崩溃或请求失败时，通过应用拓扑 + 调用链下钻能力分钟级完成问题定位。
- 云监控服务 CES：云监控（Cloud Eye）是面向华为云资源的监控平台，提供了实时监控、及时告警、资源分组、站点监控等能力。丰富的监控场景覆盖；灵活的告警配置；自由定制监控面板，展现立体化的监控平台。
- 应用运维管理 AOM：云上应用的一站式立体化运维管理平台，实时监控应用及云资源，采集各项指标、日志及事件等数据分析应用健康状态，提供告警及数据可视化功能，帮助用户及时发现故障，全面掌握应用、资源及业务的实时运行状况。运维中心：集中管理云监控、云日志、性能、Prometheus 等多维度可观测性数据源，提供统一监控与分析。双视角：应用视角基于 CMDB 为复杂应用提供可观测性分析能力，容器视角提供 Kubernetes 云原生短平快容器运维。自动化运维：提供定时、周期和告警触发系统变更，包括批量主机下发脚本作业、定时开关机等。告警降噪：应对海量告警风暴，提供分组、抑制和屏蔽告警降噪策略。
- 数据库安全服务 DBSS：一个智能的数据库安全服务，基于机器学习机制和大数据分析技术，提供数据库审计，SQL 注入攻击检测，风险操作识别等功能，保障云上数据库的安全。数据库审计：支持对 RDS、ECS/BMS 自建的数据库进行审计，提供用户行为发现审计、多维度分析；等保合规：提供日志审计报表，日志脱敏，日志远程保存，满足等保数据库审计需求；部署简单：采用数据库旁路部署方式，支持 MYSQL 和 GaussDB (for MySQL) 免装 Agent；风险告警：提供 SQL 注入库，可以基于 SQL 命令特征或风险等级，发现异常行为立即告警。
- 安全态势：漏洞扫描服务：集 Web 漏洞扫描、操作系统漏洞扫描、资产及内容合规检测、安全配置基线检查、弱密码检测、开源合规及漏洞检查、移动应用安全检查七大核心功能为一体，自动发现网站或服务器在网络中的安全风险，为云上业务提供多维度的安全检测服务，满足合规要求。态势感知：为用户提供统一的威胁检测和风险处置平台。帮助用户检测云上资产遭受到的各种典型安全风险，还原攻击历史，感知攻击现状，预测攻击态势，为用户提供强大的事前、事中、事后安全管理能力。
- 云备份 CBR：为云内的云服务器、云硬盘、SFS Turbo、云上及本地文件目录，VMware 虚拟化环境，提供简单易用的备份服务，针对病毒入侵、人为误删除、软硬件故障等场景，可将数据恢复到任意备份点。易用：备份策略一次配置，自动执行，资源概览，灾备业务一目了然；可靠：跨 Region 复制，实现异地灾备；高效：增量备份，缩短 95% 备份时长，即时恢复，RTO 可达分钟级；全面：云内的云服务器、云硬盘、文件服务，VMware 均可备份。

（二）我们当前阶段

与技术趋势和竞品比较：
- 在 PaaS 技术趋势上，我们暂时还停留在云原生 1.0 + 阶段。我们的客户群体里基本上已经使用了服务化架构，但是客户的应用还仅仅处于 “ON CLOUD” 阶段，没有真正进入 “生于云、长于云” 阶段。
- 云原生 2.0 时代，PaaS 运维平台将会进入声明式方式，逐渐脱离以前的指令式工作方式。这需要云平台引擎技术支持，当前友商华为云已能支持。
- 缺少 Serverless 模式可选性，让客户不在关心 CPU 多少、内存多少、存储多少，也不需要运维部署和维护操作。
- 与竞品对比上，当前只能从云原生产品上面进行比较，缺少云服务对比项。我们缺少部分 PaaS 分布式组件，特别是数据库分库分表中间件、MongoDB 只有 cluster 没有 sharding 等。
- 竞品都有 Serverless 产品，我们暂时还没有。公司当前还处在内部推广和普及 mesh 架构阶段。
- 竞品支持声明式运维管理资产，包括 ECS、K8S、网络、存储等；我们只支持 K8S，开源 K8S 本身就支持声明式运维，所以我们几乎没有进行任何的拓宽支持。
- Devops 方面，竞品有完整的解决方案产品工具链，可以开箱即用；我们只有部分产品，但可以对接开源产品来构建一套完整的解决方案。
- 应用性能监控方面，竞品有应用接口、JVM 虚拟机、调用链下钻、堆栈信息打印等功能，同时是无侵入式加载的；我们虽然有应用接口和 JVM 虚拟机监控，但是需要应用加载华三 SDK 包才能抓取和展示数据。
- 运维管理方面，竞品拥有云监控、安全服务、运维管理（资产 cmdb 和视图）、云备份等；我们缺少安全服务、云备份。
- 产品规划方面，友商的产品琳琅满目，功能粒度细，可选余地多，更加适应不同场景使用，例如日志服务分为日志分析服务 LOG 和云日志服务 LTS。