170个可带链接锚文本外链的网站论坛,基层建设论文查询官方网站,wordpress搭建自动发卡,wordpress中文维护插件简介#xff1a; 就云计算的API来看#xff0c;当前并没有类似POSIX这样的API标准#xff0c;基本上各大厂商各自为政。当然#xff0c;有一些业界主流标准例如OAS获得多数云厂商的支持#xff0c;但云厂商本身的API却往往由于历史原因、技术路线原因百花齐放#xff0c;…简介 就云计算的API来看当前并没有类似POSIX这样的API标准基本上各大厂商各自为政。当然有一些业界主流标准例如OAS获得多数云厂商的支持但云厂商本身的API却往往由于历史原因、技术路线原因百花齐放例如AWS的OpenAPI属于RPC风格而Azure则是WebService风格GCP则是基于gRPC为主流。技术方面的论述很多本文更想从客户体验、研发效能的角度来阐述OpenAPI对云计算整体竞争力的重要性。 作者 | 虚明 来源 | 阿里技术公众号
一 导读
提到API从事技术的同学都十分熟悉无论是在操作系统上开发软件还是打造分布式网络服务都离不开对各种API的调用。对应用程序开发人员来说都会通过各种编程语言、系统调用和各种类库、编程框架构建系统为了提升开发效率和统一性就出现了各种各样的API标准例如POSIX。这些标准的实现保障了应用程序可以不做过多修改就能运行在各种软硬件平台上大大促进了整个IT生态的发展。
然而就云计算的API来看当前并没有类似POSIX这样的API标准基本上各大厂商各自为政。当然有一些业界主流标准例如OAS获得多数云厂商的支持但云厂商本身的API却往往由于历史原因、技术路线原因百花齐放例如AWS的OpenAPI属于RPC风格而Azure则是WebService风格GCP则是基于gRPC为主流。技术方面的论述很多本文更想从客户体验、研发效能的角度来阐述OpenAPI对云计算整体竞争力的重要性。
二 云计算OpenAPI的特点
如果将阿里云飞天操作系统与传统操作系统类比那么它也是由内核层、接口层、操作界面、业务应用组成计算、存储、网络等核心产品构成了内核API层承担内核的管控和数据通信各式各样的控制界面则相当于操作系统的Terminal/Windows/mac OS UI基于云计算的各种行业应用则是跑在这个操作系统上的应用。 图1 飞天操作系统
阿里云不同于传统操作系统OpenAPI自然也不同于其他业态的API体系例如淘系、b2b的开放平台。业务开放平台输出的是以业务数据为主的服务目的是为了整合商业生态而阿里云开放平台输出的是云操作系统的管控能力、数据操作能力和其他企业级能力。前者重心是服务商业模型而后者重心是服务技术底座。因此云计算的OpenAPI体系要以服务技术开发者和企业场景为中心保障技术体系的健全稳定对外紧密对接行业技术体系例如开源工具、三方厂商对内促进众多云服务协同管理。
阿里云的OpenAPI有如下特点
数量多当前阿里云OpenAPI数量高达1万多个每天调用量上百亿分布在近300个产品上。增速快业务发展快近年来每年数量的增速接近100%。API类型多OpenAPI大体分为管控、数据两类管控类又分为RPC/ROA两种形式数据类又会分为数据流、文件等具体类型还有很多业务需要有自己的格式。产品协同要求高单个OpenAPI是不能满足用户要求的场景化的用户需求需要多个产品的多个OpenAPI组合才能服务这对API编排、产品间API协同提出了更高的要求。例如在稳定性方面一个产品的OpenAPI出问题有可能造成整个管控链路的雪崩。企业能力需求强烈OpenAPI主要是用来进行云资源管理或数据传输的操作对象都是用户资产除了常规的身份管理、权限管理外对企业来说还要服务于运维、财务、法务、监管等部门当涉及众多的云产品时对架构和底层设施的完备性、准确性、及时性要求很高。与行业技术趋势结合紧密云是全球化的作为平台它要想服务好各种场景、人群就离不开与各种业界标准和技术体系相结合云计算与开源行业高度结合证明了我们做的技术不能闭门造车。稳定性风险加大商业开放平台的OpenAPI如果不稳定影响的可能只是客户侧某个业务功能模块或流程但是云OpenAPI出问题影响的可能是客户底层技术系统爆炸半径会更大。调用热点集中调用量分布基本符合二八原则20%的云产品承担了80%的调用量核心产品的体验决定了用户对阿里云的体感保障客户典型场景的运作至关重要。
上述特点决定了云上的OpenAPI相比于传统开放平台要侧重技术能力的建设同时又要兼顾客户企业级场景才能做好体验工作。 图2 OpenAPI用户需求层次
三 管理自动化是企业客户的核心诉求
那么云计算客户在OpenAPI领域核心体验是什么以阿里云上某实际案例来分析具体要点包括
客户希望全部的流程都是能够自动化的从代码提交到服务器部署全部通过自动化工具进行。许多客户希望使用混合云体系云上云下两部分结合业务系统与云平台紧密集成。客户系统中大量使用多种开源软件例如git/Jfrog/Terraform等希望能够整合形成完整的自动化流程。
总结起来客户的核心诉求是客户业务系统要能够与云平台高度自动化地集成。不仅是客户云厂商经常强调弹性、自愈等概念其背后也是高度自动化的架构在支撑。
要做到高度自动化地集成对OpenAPI体系是全方位的要求。对比一下POSIX一套标准的、完备的、质量良好的API能够促进各操作系统之间的兼容性确保上层应用的开发移植成本最低。而对于云计算这样的规范应该在哪几个方面来满足客户的需求呢实践中我们总结如下
风格一致性POSIX API的风格基本是一致的例如文件处理API其核心错误码都是一致的。一致的风格、术语、错误、操作模式可以让应用程序开发者降低理解成本提升效率。而如果不同产品API设计风格不一致用户理解成本很高使用不便就会对云平台专业性产生质疑。例如当前阿里云的OpenAPI就存在专业术语在不同产品中描述不一样同样的资源信息各产品属性和数据不一致分页API的形式不一致甚至大小写命名也不一样的问题。功能完整性功能完整其实不难理解但是如何定义功能完整性一直有争议一个云产品是开放10个API就够了还是开放100个才够有点见仁见智况且产品也是在一直演进的。POSIX文件处理涵盖了一套标准的文件处理API包括create/close/dup/dup2/fcntl/flock/fsync/lseek/mkstemp/open/read/sync/write等 API所有关于文件操作可能的API都存在了这样用户才能精细控制文件。所以对于云上资源由于客户需要对其进行全生命周期自动化管理那么客户视角的所有管理动作都应该被开放。在实践中一般用实体关系模型去设计一组相互配合的API不可随意零散处理。
服务有效性实践中最大的问题是不同团队对于API SLA的标准不一样。例如在可用性上有些产品要求99.99%有些产品觉得99%也能接受。极端的例子如果某些OpenAPI只能允许一个并发这样的OpenAPI对用户来说是没有服务质量可言的自动化也会因为各种异常被终止。同时如果必须某些限制例如限流ToB场景下是要告知客户的否则客户端将不知道如何去优化自己的调用频率。
配套体系健全性客户体验是客户从知晓到使用产品的心理感受的全过程。Linux/Mac上的开发体验很优秀是因为配套的工具链很成熟具备完整的体系。云上客户基于OpenAPI开发时也应该能够获取专业的、详细的工具支持和技术支持就像visual studio要有MSDNjava开发要能够有IDE任何语言都需要debug工具一样。像SDK、文档、调试工具是必备产品同时诸如代码示例、API调用可视化等功能也是非常有价值的。
除此之外云计算内部系统也需要通过API实现高度自动化。一些典型的场景例如专有云部署、新region扩建、单产品扩容如果不能够自动化部署对公司整体人效是不利的更重要的是实施时间会拉长客户体验也会变差。
要解决上述问题主要难点在于如何统一标准、如何建立全面的配套平台体系、如何衡量服务质量、如何持续推动服务达标以及如何考察客户体验。
四 云计算需要面向资源编程
Linux/UNIX世界中有个著名的说法 万物皆可文件化。那么云上的万物能否资源化呢
阿里云对外的OpenAPI都是基于HTTP协议restful规范有提出基于资源设计的理念。 而实际工作中能坚持这样的原则的API却不多。经常会碰到的疑问是“什么样的东西应该定义为资源”“我的API没有资源化设计不也工作的挺好”“我设计的时候有资源概念但是客户没这需求啊”。
然而客户的困惑却是真实存在的
想自建一个资源管理系统阿里云上怎么能知道我拥有的所有资源列表那如果通过OpenAPI获取怎么能知道这个API对应的是什么资源资源能做什么操作资源与资源之间有什么关系呢不同的产品在同一个资源类型情况下怎么返回的属性不一样啊想查询不同产品若干资源的组合状态目前一个个写代码太麻烦了有什么好办法么自己去理那么多API对应的资源类型工作量太大了能不能说说阿里云自己是怎么做的
面对客户的需求我们需要回答几个问题
什么是资源哪些资源应该被管理无需管理的服务是否也要被定义为资源阿里云到底有哪些资源类型统一的列表在哪里能不能通过OpenAPI自动化获取这些资源类型的属性是怎样的能做什么操作对应的API是什么资源有哪些状态资源与资源之间的关系是什么能不能保证资源都是一致的用什么方法能够面向资源编程减少开发成本
对于云计算场景如果没有资源模型内部研发效率也会受到影响。原因是企业客户不同于个人客户相对成熟的企业都对人、财、物、权、法的监管需求强烈面对内部管理、盈利、监管约束等挑战一套成熟的IT治理体系对资源概念的依赖是极高的如阿里云的RAM/ActionTrail/Config/RD/ResourceManager等。没有资源模型这些产品就要各自定义资源分别找云产品沟通实施落地进度和质量也不能保证一致。开源软件也一样例如terraform就是面向资源的。甚至很多平台服务如账单也需要资源的概念才能更好地管理。 图3 资源生产者和消费者
如果能够统一资源模型就相当于客户和阿里云在有一套面向对象的Java类或者数据库表凡是依赖该资源模型的产品都将从中受益理解更容易沟通上保持一致性研发上可以提供统一的技术方案提高效率。
所以面向资源编程的API设计对于客户和云平台自身都是非常重要的如果前期不考虑后期会付出更大的成本必将影响阿里云整体服务质量。
五 云计算需要沉淀统一的OpenAPI/资源元数据
元数据是关于数据的数据它描述的是数据组织、数据域及其关系的信息。元数据平台并不是新鲜事物比如在大数据领域就有很多应用。由于阿里云有数百个产品上万个OpenAPI所以资源的数量也必定是庞大的这时候就有必要有一个统一的平台来管理资源信息。而资源只是一种抽象背后还需要依赖 OpenAPI的元数据两者结合才能对外提供完整的服务。
那么统一OpenAPI/资源元数据能带来哪些价值呢
1.促进产品体验一致性阿里云各个产品线独立发展但是会面临此资源非彼资源的尴尬境地每个产品都有自己的认识非常不利于统一客户体验。
2.提升沟通效率统一的模型就像一个标准的数据库schema能够让相关的业务方都能够在一个语境中沟通。
3.提升研发效率结构化的标准模型能够让程序代替人来处理模式化的数据以Terraform为例有了资源元数据可以直接编写自动化脚本生成terraform模块将云产品的接入效率提升了50%左右过程中就节省了go语言研发资源和联调成本。 图4 基于API元数据无代码自动化生成
4.提升业务质量持续保障软件研发有个痛点是云产品初次发布后如果随着业务迭代如何保障过往的功能正确性。以阿里云的RAM产品为例如果我们能够将资源元数据、API访问日志、RAM的Policy与云产品实际鉴权日志放在一起通过对比元数据声明内容与实际发生的动作就可以检查云产品的鉴权行为是否符合预期。相比于人治基于数据和代码的自动化平台检查机制会更高效、更准确。
5.更多的业务场景赋能Azure有一个产品叫Resource Graph Explorer它能够按照资源维度管理平台上所有的资源跨地域也不是问题有点类似于windows的资源管理器。完善的元数据管理将使得这类产品的研发变得可能。可能有人会有疑问没有元数据就不能做吗理论上可以但是一定是事倍功半因为它需要与各产品反复协调沟通成本极高而不是用一套平台来承载着标准化的生产流程且不好复用不可同日而语。
所以统一的阿里云OpenAPI/资源元数据管理对内价值是许多围绕资源的业务开发都将变得更加轻松甚至无代码化提升业务效能对外客户将能得到与内部一致的业务模型提升用户体验更加方便地集成。
六 OpenAPI体验是云客户的核心体验之一
云操作系统想服务好客户经过优良设计的API是必需品否则用户很难快速高效地基于API层来开发和部署应用服务会对商业竞争力造成严重影响一个各种理念能力都是顶级但却难以管理的操作系统谁愿意使用呢
OpenAPI是云产品的服务契约。云平台不但要保障服务质量而且一旦上线下线极难产品很难冒风险去强行关闭某个API不兼容变更也不行等同于违约有可能造成客户业务系统的崩溃随后就是法律风险、舆情风险和客户流失。OpenAPI的成熟度很重要。客户在使用云服务的时候货比三家除了价格、稳定、功能等因素外是否能够快速、方便地与客户业务系统集成是重要竞争因素阿里云接触过许多大客户都在API成熟度上有明确要求。良好的开发体验和丰富的服务生态或将成为云厂商的核心竞争力。Windows靠视窗系统的体验代差霸占消费级操作系统市场Linux/Unix在windows环伺下靠企业级开发能力占据企业级市场macOS的良好开发体验又在windows一统天下的局面下杀出一条血路都说明最终制胜必须围绕客户体验展开。当各厂商在核心服务能力上随着时间的推移逐渐同质化之后差异化竞争力就在于价格、体验、服务了而现在国外竞对在体验上的优势也是多年沉淀下来的护城河不投入时间和资源来沉淀是不可能比肩的。客户视角在云计算场景下尤为重要。其逻辑不是我们有什么接口可以开放而是客户需要我们开放什么接口。功能接口开放度不足可能会导致客户的生产流程中断严重影响客户的信心。符合行业规范的API更容易兼容业界技术工具和合作伙伴更容易为社区所接受。比如现在应该很难出现一个不支持POSIX标准的操作系统了不兼容就意味着没有市场。草率设计的API会导致业务难以和外部生态协作如果又必须合作会对内部研发资源造成压力从而影响业务发展速度和商业竞争力。OpenAPI不仅仅是API的问题配套的服务体系必须完善。看看Linux系统上的开发并不是有个系统调用函数就OK了需要文档/代码示例/各种调试工具由此还衍生许多IDE工具。在阿里云上这种全链路服务还比较薄弱客户碰到问题要么反复提工单对公司服务资源造成很大压力要么服务不满意客户用脚投票影响阿里云口碑损害公司长期竞争力。
因此OpenAPI不止是技术问题也是产品问题是产品体验的重要组成部分需要慎重对待。
七 OpenAPI客户体验需要强大的体系支撑
那么OpenAPI的客户体验能不能被度量阿里云开放平台刚开始发力OpenAPI时面临的最大问题是客户和内部都有人吐槽阿里云API不好用都是点状问题抛出和客户需求驱动没有一个体系化的方法来衡量客户体验指标且不能规模化解决问题。
阿里云的 OpenAPI数量1万多个点状的、模糊的反馈对解决全局问题没有帮助且用户其实是对具体产品有概念但针对OpenAPI概念性不强调研主观偏差更大。
阿里云的OpenAPI体验是一个全链路问题如下图 图5 典型OpenAPI用户使用路径
长长的链路任何一个环节没做好都有可能导致用户体验不好反馈的信息也是五花八门难以抽取有效信息。因此有几个核心问题需要依次解决
什么样的客户声音是清晰明确的如何能够拿到这些客户声音有哪些渠道如何处理这些声音如何清洗分类如何定位根因分析是哪个环节的问题如何建立总体和细分量化指标进而针对性治理形成闭环如何推动及运营最终如何检验治理效果
我们的做法是这样的
1 Step1 量化
要有具体用户问题 能够反映客户具体问题的信息过去主流是靠工单但是工单反馈的用户只是冰山一角更多的信息没有被看到。电话、钉群信息、网站反馈等内容也应该被纳入进来这些信息加起来就是一个个具体的问题很多问题汇集在一起就形成了很有价值的大数据集可以给数据化治理奠定数据基础。获取数据我们尝试联系工单系统、内部平台、钉群等渠道需要拉通各个平台的数据。数据清洗客户、工单数据是非结构化数据需要自然语言处理方面的技术阿里云开放平台与达摩院合作通过对特定目标分类输入关键词、打标签等方式训练AI由AI对大量的数据进行自动化抽取、归类、量化对客户声音和根因进行较好的分类和量化。业务价值通过根因分析得出客户主要问题分类后针对性地优化升级产品以问题的单位用户工单量为效果指标来检验产品改进效果。有些问题是从趋势中发现的需要升级产品例如客户抱怨找不到SDK或API我们就要优化API搜索。有些问题是已知内部问题例如API可用性问题就制定机制去督促业务改进。改进效果衡量首先要有具体指标目前主要还是工单降量。但是我们觉得还不够因为工单只是冰山一角数量不够多也不够细节流转周期也长。所以我们也尝试收口OpenAPI开发者门户一方面标准化产品体验另一方面直接触达终端客户拿到最详细的反馈。比如客户的反馈能够详细到当某个API的页码设定为0会导致功能异常文档细节不对必填非必填描述不对这样的精准问题。
通过上述动作我们能够自动化分析出OpenAPI用户的主要痛点并建立数字化趋势图去跟踪。
2 Step 2治理
有法可依制定了《阿里云OpenAPI规范》目前已经迭代到1.3版涵盖设计风格、服务质量、资源规范、域名规范、文档规范等子项在标准层面统一大家认知。 执法必严想要让规范落地只有文本不行必须有配套的平台机制。 收口阿里云所有API管理从提升研发效率和全生命周期体系化管理的角度持续提升API管理平台的核心能力。将规范的审查规则沉淀到规则引擎中用户在开发API的时候自动化扫描检查问题不通过就打回。对于无法自动化约束的规范建立审核流程和管理层审批流程提高不合规问题的生产成本不断提升自动化审核比例。针对API的质量进行数字化治理通过质量分量化评估各个BU各个产品API质量定期同步督促改进。违法必究联合阿里云用户体验部门一起推动问题改进并通过检查用户侧工单降量情况来验证效果。
上述能力都沉淀在内部管理平台上内部云产品可以一站式管理API及流程化参与API治理过程。
3 Step3 产品化
目标是收口外部用户的产品体验。以前OpenAPI的各项功能是分散割裂的FY21我们将所有与OpenAPI相关的功能集成正在一个产品中即过OpenAPI开发者门户 除了通过集中的产品建设提升用户体验外还针对使用链路增加了troubleshooting、搜索、codesample等模块。
通过以上三步我们整体OpenAPI体验治理大图如下 图6 用户体验管理闭环示意图
通过这套体系运转中发现的问题都会通过API管理平台和API开发者门户的功能上不断的完善去逐步提升用户体验从2020年的工单情况看有比较明显的下降。
八 总结
阿里云是个庞大的分布式操作系统OpenAPI相当于用户层操作内核层的重要通道保障它的稳定、功能、性能、体验关系到客户的核心体验关系到公司形象和生态拓展也关系到内部产品质量和研发效率接入层必须做深、做厚、做强才能让内外部客户被服务好。从团队两年的实践来看数字化、体系化的做好基础建设才能做好OpenAPI体验。本文就云上OpenAPI的几个重要概念进行论述希望能抛砖引玉引起大家对OpenAPI体系价值的兴趣和关注。
参考文献
API Design 202: Architectural Layers - API Academy嵌入式 Linux開發Kernel移植一——kernel內核簡介 - IT閱讀Azure Resource Graph | Microsoft AzureLinux File System – Behind.The.Moon.Light
原文链接
本文为阿里云原创内容未经允许不得转载。
