一家公司做两个网站,5G网站建设,青海省住房和建设厅网站首页,长沙手机模板建站简介#xff1a; 在传统软件架构下#xff0c;撇开业务层代码#xff0c;都需要部署计算节点、存储资源、网络资源#xff0c;然后安装、配置操作系统等。而云服务本质上是实现 IT 架构软件化和 IT 平台智能化#xff0c;通过软件的形式定义这些硬件资源#xff0c;充分抽…简介 在传统软件架构下撇开业务层代码都需要部署计算节点、存储资源、网络资源然后安装、配置操作系统等。而云服务本质上是实现 IT 架构软件化和 IT 平台智能化通过软件的形式定义这些硬件资源充分抽象并封装其操作接口任何资源均可直接调用相关 API 完成创建、删除、修改、查询等操作。 作者 | 元吟 来源 | 阿里技术公众号
一 背景
2018年7月9日我通过校招加入阿里云开启了职业生涯。有幸参与了资源编排服务从1.0到2.0的全部设计、开发、测试工作这对我了解云上服务起到了启蒙作用。当然本文源于我在设计开发过程中的思考和感悟。
在传统软件架构下撇开业务层代码都需要部署计算节点、存储资源、网络资源然后安装、配置操作系统等。而云服务本质上是实现 IT 架构软件化和 IT 平台智能化通过软件的形式定义这些硬件资源充分抽象并封装其操作接口任何资源均可直接调用相关 API 完成创建、删除、修改、查询等操作。
有赖于阿里云对资源的充分抽象以及高度统一的OpenAPI这让基于阿里云构建一套完整的 IT 架构并对各资源进行生命周期管理成为可能。客户按需求提供资源模板编排服务将会根据编排逻辑自动完成所有资源的创建和配置。
二 架构设计
伴随着业务场景的增加和业务规模的指数级增长原有架构逐渐暴露出租户隔离粒度大、并发量小、服务依赖严重等问题对于服务架构的重构迫在眉睫其中最重要三个方面就是拓扑设计、并发模型设计和工作流设计。
1 拓扑设计
拓扑设计的核心问题是明确产品形态和用户需求、解决数据通路问题。站在产品角度考虑的点包括: 1. 资源所有者(服务资源[计费单元]、用户资源)、2. 资源访问权限(隔离、授权)。站在用户角度需要考虑的点包括: 1. 服务类型(WebService型-需公网访问、数据计算型-阿里云内网访问)、2. 数据打通(源数据、目的数据)。
资源所有者分为服务账号和用户账号。资源属于服务账号的模式又叫做大账号模式该模式优点有: 1. 管控能力更强2.计费更容易。但易成为瓶颈的点包括1.资源配额2. 依赖服务的接口流控。很显然全量资源托管是不现实的比如VPC、VSwitch、SLB、SecurityGroup等资源客户往往需要和其他系统打通这部分资源通常是用户提供的而ECS实例则比较适合通过大账号创建。
多租户隔离在大账号模式下是非常重要的问题。既要保证某一用户的资源彼此可以相互访问又要保证多个客户之间不能有越界行为。一个常见的例子是所有用户的ECS均开在同一个服务VPC内同一个VPC内实例默认是可以相互访问的存在安全风险因此在系统设计初期就需要考虑到相关问题的应对方案。
对于上述问题我们的设计是ECS实例通过大账号模式创建在服务账号下的资源VPC内 通过企业级安全组实现不同用户实例的访问隔离。涉及用户数据(NAS、RDS等)访问的操作时需要用户提供这些访问点所在的VPC和Vswitch通过在实例上创建ENI并绑定到用户VPC上实现对用户数据的访问。具体数据通路如图所示。 常见的服务架构
2 并发模型设计
模型设计的核心是解决高并发(High Concurrency)、高性能(High Performance)、高可用(High Availability)问题。
资源编排的高并发主要指标为QPS(Queries-per-second)对于动辄以分钟为单位的资源编排逻辑而言同步模型显然不能支撑较高并发请求。资源编排的高性能主要指标为TPS(Transactions-per-second)在根据用户资源模板编排资源的过程中资源彼此间存在一定的依赖关系线性地创建资源会导致大量时间处于忙等状态服务吞吐严重受限。资源编排的高可用主要指标为SLA(Service Level Agreement)在HA基础上若能解耦CRUD对内部服务的依赖在服务升级或发生异常时就可以减小对SLA的影响。
对于上述问题我们的设计是在服务前端仅进行简单的参数检查后立即将用户模板写入持久化层写入成功后立即返回资源ID已持久化的资源模板将被视为未处理完成的任务等待调度处理。随后我们周期性扫表探测任务有序创建资源并同步其状态如遇资源状态不满足向下推进的条件则立即返回经过多轮次处理最终达到期望的状态 一个简化的分布式模型如图所示。 分布式并发模型
为了避免任务较多情况下的锁争抢问题我们设计一套任务发现 租约续租的机制一旦集群从数据库池子中被某个节点争抢到之后会被添加到该节点的调度池中并设定租约 租约管理系统会对即将到期的租约进行续租(加锁)。这样可以确保一个集群在下一次服务被拉起前一直只被某个节点处理如果服务重启则任务会因超时自动解锁并被其他节点捕获。
3 工作流设计
流程设计的核心是解决依赖问题。依赖问题包含两种情况前序资源的状态不符合预期和资源本身状态不符合预期。我们假设各资源的状态只有可用和不可用并且假定可用的资源不会跳转到不可用状态最简单的情况就是一个线性任务如图所示。考虑到部分子资源的编排工作可以并行编排过程就可以看作是一个有向无环图( DAG, Direct Acyclic Graph)任务。 资源线性编排结构
世界不只是非黑即白资源的状态也是一样有向无环成为了美好的愿望有向有环才符合真实世界的运行规律。对于这种情况简单的工作流很难覆盖复杂的流程只有进一步对工作流抽象设计符合要求的有限状态机(FSM, Finite State Machine)。有限状态机说起来过于抽象但ECS实例的状态转移大家都接触过下图就是ECS实例的状态转移模型。 ECS实例状态转移模型 结合实际业务需求我设计了如下图所示的集群状态转移模型。该模型简化了状态转移逻辑有且仅有Running这一稳态其他三种状态(Rolling、Deleting、Error)均为中间态。处于中间态的资源会根据当前资源状态尝试向着稳态越迁每次状态越迁过程均按照一定的Workflow执行相关操作。 集群状态转移模型
从这时起服务的整体架构和设计思路基本确立。
三 核心竞争力
资源(ECS)短缺问题日益严峻加上粗粒度的扩缩容、升降配功能已不能满足客户的需求资源池化(Resource Pooling)、自动伸缩(Auto Scaling)、滚动升级(Rolling Update)被提上日程并成为提升产品竞争力的一大利器。
1 资源池化
资源池化简单来说就是提前预留某些资源以备不时之需很显然资源池化的前提一定是大账号模式。对开发者而言线程池不是陌生的词汇但资源池却相对比较遥远实际上资源池解决的就是资源创建、删除时间开销很大以及库存不可控的问题。当然 池化资源另一个假设是被池化的资源会被频繁使用且可被回收利用(规格、配置相对单一)。
由于计算资源创建周期较长且经常被资源库存等问题困扰加之产品期望在业务上有所拓展因此我们设计了如图所示的资源池化模型并对多种计算资源进行抽象提供了一套可以应对异构资源的处理逻辑。 资源池化模型
资源池化可以大大缩短资源创建等待时间解决库存不足问题另外它可以帮上层使用到资源的服务解耦复杂的状态转移逻辑对外提供的资源状态可以精简到Available和Unknown两种所得即可用。但不得不考虑的问题包括
ECS实例的创建是否受用户资源的限制(如用户提供VSwitch会限制ECS可用区)。如何解决资源闲置问题(成本问题)。
对于第一个问题目前受制于VSwitch由客户提供暂时还没有比较好的解法只能尽量要求客户提供的VSwitch覆盖更多的可用区如果VSwitch属于服务账号就可以比较好规划资源池建在哪个AZ。对于第二个问题资源池本身也是一种资源成本控制我们可以从接下来提到的自动伸缩上得到答案。
2 自动伸缩
云计算最大的吸引力就是降低成本对资源而言最大的好处就是可以按量付费。实际上几乎所有线上服务都有其峰谷而自动伸缩解决的正是成本控制问题。它在客户业务增长时增加ECS实例以保证算力业务下降时减少ECS实例以节约成本如图所示。 自动伸缩示意图
我对自动伸缩的设计思路是先对时间分片触发定时任务再对时间段内配置伸缩策略。伸缩策略也包含两部分一部分是最大ECS规模和最小ECS规模它指定了该时间段内集群规模的浮动范围另一部分是监控指标、耐受度和步进规则它提供了伸缩依据和标准。这里监控指标是比较有意思的点除了采集云监控的CPU、Memory利用率外还可以通过对ECS空闲、忙碌状态的标记计算出工作节点占比率一旦超出耐受范围即可按步进大小触发一次扩容或缩容事件。
3 滚动升级
客户服务架构的修改往往涉及复杂的重建逻辑在重建过程中不可避免的会影响服务质量如何优雅平滑地做升降配成为了诸多客户的刚需。滚动升级正是解决不停服、可调控的升降配问题的。 滚动升级示意图
一次简化的滚动升级过程如上图所示。滚动升级的核心是对升级进行灰度按照一定比例开出Standby资源直到它们可以顺利服役随后再下线掉相应台数的资源。经过多次滚动之后使其全部资源更新到最新预期通过冗余实现升级不停服。
四 可观测性
服务可观测性将来必将成为云服务的核心竞争力之一它包括面向用户的可观测行和面向开发者的可观测性两部分。时至今日仍然记得半夜被客户电话支配的恐惧仍记得对着海量日志调查问题的不知所措仍记得客户一通抱怨后毫无头绪的茫然。
1 面向用户
是的我希望用户在向我们反馈遇到的问题时提供的信息是有效的甚至是能直接指向病灶的。对用户而言能够直接通过API获取资源编排所处的阶段以及各阶段对应资源的状态信息确实能够极大地提高用户体验。针对这个问题我分析了系统处理流程 设计了面向“阶段 - 事件 - 状态”的运行状态收集器。
具体包括对的业务流程进行拆分得到多个处理阶段对每个阶段依赖的事件(资源及其状态)进行整理对每个事件可能出现的状态做结构化定义(尤其是异常状态)。一个典型的样例如代码样例所示。
[{Condition:Launched,Status:True,LastTransitionTime:2021-06-17T18:08:30.55958607708:00,LastProbeTime:2021-06-18T14:35:30.57419618208:00},{Condition:Authenticated,Status:True,LastTransitionTime:2021-06-17T18:08:30.94199457508:00,LastProbeTime:2021-06-18T14:35:30.59222259408:00},{Condition:Timed,Status:True,LastTransitionTime:2021-06-17T18:08:30.94462619808:00,LastProbeTime:2021-06-18T14:35:30.59962826208:00},{Condition:Tracked,Status:True,LastTransitionTime:2021-06-17T18:08:30.94753087308:00,LastProbeTime:2021-06-18T14:35:30.60880778608:00},{Condition:Allocated,Status:True,LastTransitionTime:2021-06-17T18:08:30.95231081108:00,LastProbeTime:2021-06-18T14:35:30.61839058208:00},{Condition:Managed,Status:True,LastTransitionTime:2021-06-18T10:09:00.61158854608:00,LastProbeTime:2021-06-18T14:35:30.62794640408:00},{Condition:Scaled,Status:False,LastTransitionTime:2021-06-18T10:09:00.717290508:00,LastProbeTime:2021-06-18T14:35:30.7496789108:00,Errors:[{Action:ScaleCluster,Code:SystemError,Message:cls-13LJYthRjnrdOYMBug0I54kpXum : destroy worker failed,Repeat:534}]}
]
代码样例集群维度状态收集
2 面向开发者
对开发者而言可观测性包含监控和日志两部分监控可以帮助开发者查看系统的运行状态而日志可以协助问题的排查和诊断。产品从基础设施、容器服务、服务本身、客户业务四个维度进行了监控和数据聚合具体用到的组件如图所示。 各级别监控、告警体系
基础设施主要依托云监控(Cloud Monitor)追踪CPU、Memory等使用率容器服务主要依赖普罗米修斯(Prometheus)监控部署服务的K8S集群情况。对服务本身我们在各个运行阶段都接入了Trace用于故障定位对最难处理的客户业务部分我们按通过SLS收集客户使用情况通过UserId和ProjectId进行数据聚合并整理出普罗米修斯的DashBoard可以快速分析某个用户的使用情况。
除监控外已接入云监控告警、普罗米修斯告警和SLS告警系统、业务分别设置不同告警优先级并整理了丰富的应急响应方案。
原文链接
本文为阿里云原创内容未经允许不得转载。
