一简介说到API，搞技术的同学都非常熟悉。无论是在操作系统上开发软件，还是创建分布式网络服务，都离不开调用各种AP??I。对于应用程序开发人员来说，他们通过各种编程语言、系统调用、各种类库和编程框架来构建系统。为了提高开发效率和统一性，出现了各种API标准，比如POSIX。这些标准的实现，保证了应用无需过多修改即可运行在各种软硬件平台上，极大地促进了整个IT生态系统的发展。但是，就云计算API而言，目前并没有像POSIX这样的API标准，基本上各大厂商都在各自为政。当然，也有一些业界主流的标准，比如OAS，大部分云厂商都支持，但是由于历史原因和技术路线原因，云厂商的API往往百花齐放。它以gRPC为主流。技术讨论很多，本文想从客户体验和研发效率的角度，阐述OpenAPI对云计算整体竞争力的重要性。2、云计算OpenAPI的特点如果将阿里云飞天操作系统与传统操作系统进行比较，那么它也是由内核层、接口层、操作接口、业务应用等组成。计算、存储、网络等核心产品构成核心，API层负责内核的控制和数据通信，各种控制接口相当于操作系统的Terminal/Windows/macOSUI，以及基于云计算的各种行业应用，都是运行在这个操作系统上的应用。图1飞天操作系统阿里云不同于传统操作系统，OpenAPI自然也不同于淘宝、B2B开放平台等其他业务类型的API系统。业务开放平台输出基于业务数据的服务，融合业务生态；阿里云开放平台输出云操作系统管控能力、数据运营能力等企业级能力。前者侧重于服务商业模式，后者侧重于服务技术基础。因此，云计算的OpenAPI体系应以服务技术开发者和企业场景为核心，保证技术体系的健全和稳定，对外与行业技术体系（如开源工具、第三方厂商）紧密对接，在内部推动许多云服务的协同管理。阿里云OpenAPI具有以下特点：数量大：目前阿里云OpenAPI数量高达1万多个，每天调用量达数百亿，分布在近300个产品中。增长速度快：业务发展快，近年年增长率接近100%。API的种类很多：OpenAPI大致分为两种：控制类和数据类。控件类型分为两种形式：RPC/ROA。数据类型分为数据流、文件等具体类型。产品协同要求高：单一的OpenAPI无法满足用户需求。场景化的用户需求需要多个产品的多个OpenAPI组合来服务，这对产品间的API编排和API协同提出了更高的要求。比如在稳定性方面，一个产品的OpenAPI出现问题，可能会导致整个控制链路雪崩。企业能力需求强：OpenAPI主要用于云资源管理或数据传输，操作对象为用户资产。除了常规的身份管理和权限管理，对于企业来说，它还服务于运维、财务、法务等。、监管等部门，在涉及到很多云产品时，对架构和底层设施的完整性、准确性和时效性都有很高的要求。与行业技术趋势紧密结合：云是全球性的，作为一个平台，要想服务好各种场景和人群，就必须与各种行业标准和技术体系相结合。云计算与开源行业的高度结合，证明了我们做的技术是不能关起门来做的。稳定性风险增加：如果商用开放平台的OpenAPI不稳定，可能只会影响客户端的某个业务功能模块或流程，但云端OpenAPI出现问题，可能会影响到客户端的底层技术系统，爆炸半径会更大。通话热点集中：通话量的分布基本符合二十八条原理。20%的云产品占据了80%的通话量。核心产品的体验决定了用户对阿里云的体验，保障典型客户场景的运行非常重要。以上特点决定了与传统开放平台相比，云上OpenAPI必须注重技术能力的建设，同时兼顾客户的企业级场景，才能做好体验。图2OpenAPI用户需求等级三管理自动化是企业客户的核心需求那么OpenAPI领域云计算客户的核心体验是什么？结合阿里云上的一个实际案例进行分析，具体包括：客户希望所有流程都可以自动化是的，从代码提交到服务器部署全部通过自动化工具。很多客户希望使用混合云系统，云与云结合，业务系统与云平台紧密结合。客户系统中广泛使用了多种开源软件，如Git/Jfrog/Terraform等，希望能将其整合形成一个完整的自动化流程。总结起来，客户的核心需求是：客户的业务系统必须能够与云平台集成，自动化程度高。不仅客户，云厂商也经常强调弹性和自我修复等概念，这些概念也得到高度自动化架构的支持。要实现高度自动化的集成，OpenAPI系统是一个全方位的需求。与POSIX相比，一套标准、完备、优质的API可以促进操作系统之间的兼容性，保证上层应用的开发和移植成本最低。至于云计算，这样的规范应该在哪些方面满足客户的需求？在实践中，我们总结如下：风格一致性：POSIXAPI的风格基本一致。比如文件处理API的核心错误码都是一致的。一致的风格、术语、错误和操作模式使应用程序开发人员能够降低理解成本并提高效率。但如果不同产品的API设计风格不一致，用户理解成本高，使用不方便，云平台的专业性就会受到质疑。比如阿里云的OpenAPI，目前存在不同产品的技术术语描述不同，同一资源信息的产品属性和数据不一致，分页API形式不一致，甚至case名称不一致等问题。功能完备性：功能完备性其实并不难理解，但是如何定义功能完备性一直存在争议。一个云产品是开放10个API就够了，还是开放100个API就够了？见仁见智，产品不断进化。POSIX文件处理涵盖了一套标准的文件处理API，包括create/close/dup/dup2/fcntl/flock/fsync/lseek/mkstemp/open/read/sync/write等API。存在所有可能的文件操作API，以便用户对文件进行细粒度控制。因此，对于云上的资源，由于客户需要对其进行全生命周期管理的自动化，所有站在客户角度的管理行为都应该是开放的。在实践中，实体-关系模型一般用于设计一组相互配合的API，不能胡乱处理。服务有效性：实践中最大的问题是不同的团队对APISLA的标准不同。比如可用性方面，有的产品要求99.99%，有的产品认为99%也可以。举个极端的例子，如果某些OpenAPIs只能允许一种并发，这样的OpenAPIs对用户来说是没有服务质量的，自动化会因为各种异常而终止。同时，如果需要做一定的限制，比如限流，在ToB场景下必须要通知客户端，否则客户端不知道如何优化自己的调用频率。配套体系健全：客户体验是客户从知道产品到使用产品的心理感受的全过程。在Linux/Mac上的开发体验极佳，因为配套的工具链非常成熟，体系完备。云端客户在基于OpenAPI进行开发时，也应该能够获得专业细致的工具支持和技术支持，就像VisualStudio需要MSDN，Java开发需要IDE，任何语言都需要调试工具一样。SDK、文档、调试工具等产品是必备的，代码示例、API调用可视化等功能也很有价值。此外，云计算内部系统也需要通过API实现高度自动化。一些典型的场景，比如私有云部署、新区域拓展、单品扩容等，如果部署不能实现自动化，将不利于公司整体的人力效率。更重要的是，实施时间会延长，客户体验也会变差。解决上述问题，主要难点在于如何统一标准，如何建立完善的支撑平台体系，如何衡量服务质量，如何持续提升服务标准，如何检验客户体验。4.云计算需要面向资源的编程在Linux/UNIX的世界里，有一句名言：Everythingcanbedocumented。那么云上的一切都可以资源化吗？阿里云对外的OpenAPI是基于HTTP协议的，RESTful规范提出了基于资源的设计理念。在实际工作中，能够坚持这样原则的API并不多。经常遇到的问题是“什么样的东西应该定义为资源？”“如果没有基于资源的设计，我的API就不能正常工作吗？”“我设计的时候有资源概念，但是客户没有这个需求？”。然而，客户的困惑是真实的：如果我想自己搭建一个资源管理系统，我怎么知道我在阿里云上拥有的所有资源的列表？那如果我通过OpenAPI获取，我怎么知道这个API对应的是什么资源呢？可以做哪些操作，资源之间是什么关系？为什么同一种资源类型下，不同的产品返回的属性不同？我想查询不同产品的几种资源的组合状态。目前一个一个写代码实在是太多了。麻烦，有什么好办法吗？管理那么多API对应的资源类型，工作量太大。你能告诉我们阿里云是怎么做到的吗？面对客户的需求，我们需要回答几个问题：什么是资源？应该管理哪些资源？不需要管理的服务是否也应该定义为资源？阿里云有哪些资源，统一列表在哪里？可以通过OpenAPI自动获取吗？这些资源类型的属性是什么？可以做什么？对应的API是什么？资源状态是什么？资源之间是什么关系？资源能保证一致吗？面向资源编程有什么方法可以降低开发成本？对于计算场景，如果没有资源模型，内部研发效率也会受到影响。原因是企业客户不同于个人客户。相对成熟的公司在人、财、物、权、法等方面都有很强的监管要求。面对内部管理、盈利能力、监管约束等挑战，成熟的IT治理体系对资源具有强大的影响力。概念依赖性极高，比如阿里云的RAM/ActionTrail/Config/RD/ResourceManager等，没有资源模型，这些产品要自己定义资源，单独和云产品通信，实现进度和质量无法保证保证一致。开源软件也是如此，比如面向资源的Terraform。甚至许多平台服务，如计费，也需要资源的概念来更好地管理。图3如果资源生产者和消费者能够统一资源模型，就相当于客户和阿里云拥有一套面向对象的Java类或数据库表。所有依赖这个资源模型的产品都会从中受益，更容易理解和沟通，在一致性方面，研发可以提供统一的技术解决方案，提高效率。因此，资源编程的API设计对于客户和云平台本身都非常重要。如果前期不考虑，后期成本会更高，势必会影响阿里云的整体服务质量。5、云计算需要沉淀统一的OpenAPI/资源元数据元数据是关于数据的数据，描述了数据组织、数据域及其关系的信息。元数据平台并不新鲜。比如在大数据领域就有很多应用。阿里云有上百种产品，上万个OpenAPI，资源量肯定是巨大的。这时候就需要有一个统一的平台来管理资源信息。资源只是一个抽象，需要依赖背后OpenAPI的元数据。两者结合可以对外提供完善的服务。那么统一的OpenAPI/资源元数据能带来什么价值：促进产品体验的一致性：阿里云的各个产品线独立发展，但会面临一种资源不是另一种资源的尴尬局面。每个产品都有自己的理解，这一点很重要。不利于统一的客户体验。提高沟通效率：统一的模型就像一个标准的数据库模式，使相关业务方能够在一个上下文中进行沟通。提高研发效率：结构化的标准模型可以让程序代替人来处理模型数据；以Terraform为例，有了资源元数据，可以直接编写自动化脚本生成terraform模块，提升了云产品的访问效率，节省了50%左右，过程中节省了Go语言研发资源和联调成本。图4基于API元数据的无代码自动生成，提升业务质量持续保障：软件开发的一个痛点是云产品初发后，如果业务迭代，如何保证之前功能的正确性。以阿里云的RAM产品为例，如果能将资源元数据、API访问日志、RAM策略和云产品实际认证日志放在一起，将元数据声明的内容与实际动作进行对比，就可以检查是否有认证行为云产品符合预期。与人治相比，基于数据和代码的自动化平台检查机制将更加高效和准确。更多业务场景赋能：Azure有一个产品叫ResourceGraphExplorer，可以按照资源维度管理平台上的所有资源，跨地域不成问题，有点类似于Windows资源管理器。完善的元数据管理将使此类产品的研发成为可能。可能有人会有疑问：没有元数据能行吗？理论上是可以的，但是一定事倍功半，因为需要和各种产品反复协调沟通，成本极高，而不是用一个平台来承载标准化的生产流程，而且不容易复用,这是不一样的。因此，统一阿里云OpenAPI/资源元数据管理，其内在价值是很多围绕资源的业务开发会变得更简单，甚至是无代码化，提高业务效率。外部客户将能够获得与内部一致的商业模式，提升用户体验，更容易集成。6、OpenAPI体验是云客户的核心体验之一。一个云操作系统要想服务好客户，一个设计良好的API是必须的。否则，用户将难以基于API层快速高效地开发和部署应用服务，影响业务竞争力。说真的，谁愿意使用一个具有顶级概念和功能却难以管理的操作系统？OpenAPI是云产品的服务契约。云平台不仅要保证服务质量，一旦上线下线，产品很难冒着风险强行关闭一个API，甚至是不兼容的改动，等同于违约，可能导致客户业务系统崩溃，进而引发法律风险、舆论风险和客户流失。OpenAPI的成熟度很重要。客户在使用云服务时货比三家。除了价格、稳定性、功能等因素外，能否快速方便地与客户业务系统集成是重要的竞争因素。阿里云已经接触了很多基于API成熟度的大客户。有明确的要求。良好的开发体验和丰富的服务生态，或将成为云厂商的核心竞争力。Windows基于Windows系统糟糕的体验，在消费级操作系统市场占据主导地位，而Linux/Unix则凭借被Windows包围的企业级开发能力，在企业级市场占据主导地位，一切都表明，最终的胜利一定是围绕客户体验展开的。当各厂商的核心服务能力随着时间的推移逐渐同质化，差异化的竞争力就在于价格、体验、服务。现在，国外竞争对手在经验方面的优势，也是多年来积累的护城河。不可能在降水方面投入时间和资源。客户视角在云计算场景中尤为重要。逻辑不是我们要开放什么接口，而是客户需要我们开放什么接口。功能接口的开放性不够，可能会打断客户的生产流程，严重影响客户的信心。符合行业规范的API更容易与行业技术工具和合作伙伴兼容，更容易被社区接受。比如现在应该很难有不支持POSIX标准的操作系统，不兼容就没有市场。设计不当的API将导致业务难以与外部生态系统合作。如果一定要合作，会给内部研发资源带来压力，进而影响业务发展速度和商业竞争力。OpenAPI不仅仅是API的问题，配套的服务体系一定要完善。纵观Linux系统上的开发，光有系统调用功能是不够的，还需要文档/代码示例/各种调试工具，很多IDE工具都由此衍生。这种在阿里云上的全链路服务还是比较薄弱的。客户遇到问题，要么重复提交工单，对公司服务资源造成很大压力，要么客户对服务不满意，用脚投票，影响阿里云的声誉，损害公司的长远利益。竞争力。因此，OpenAPI不仅仅是一个技术问题，更是一个产品问题。它是产品体验的重要组成部分，需要谨慎对待。7.OpenAPI的客户体验需要强大的系统支持，那么OpenAPI的客户体验是否可以衡量？阿里云开放平台在刚推出OpenAPI时面临的最大问题是：客户和内部人员抱怨阿里云的API不好用。点状问题是由客户需求抛出和驱动的。没有系统的方法来衡量客户体验指标，无法大规模解决问题。阿里云拥有超过10,000个OpenAPI。点状、模糊的反馈无助于解决整体问题，用户对具体产品其实是有概念的，但OpenAPI的概念不强，研究的主观偏差较大。阿里云的OpenAPI体验是全链接问题，如下图所示：图5典型的OpenAPI用户使用长链接。任何一个环节做不好，都可能导致用户体验不佳；反馈的信息也是五花八门。难以提取有效信息。因此，有几个核心问题需要依次解决：什么样的客户声音清晰明了？这些客户声音如何获取，有哪些渠道？这些声音如何处理，如何清洗和分类，如何定位根源，分析在哪个环节？如何建立整体和细分的量化指标，然后进行针对性治理，形成闭环？如何推广和运营？如何最终检验治理效果？我们的做法是：1Step1量化一定要有具体的用户问题：可以反映客户过去具体问题的信息主要是工单，但上报工单的用户只是冰山一角,并没有看到更多的信息。电话、pin群信息、网站反馈等内容也应包括在内。这些信息的总和就是一个具体的问题。许多问题共同构成了一个有价值的大数据集，可以为数据治理奠定基础。根据。获取数据：我们尝试联系工单系统、内部平台、钉钉群等渠道，需要拉通各个平台的数据。数据清洗：客户和工单数据是非结构化数据，需要自然语言处理技术。阿里云开放平台与达摩院合作，通过输入关键词和标注特定目标来训练人工智能。对海量数据进行自动抽取、分类、量化，更好的对客户声音和根因进行分类和量化。商业价值：通过根因分析得到主要客户问题分类后，有针对性地进行产品优化升级，以该问题的单位用户工单数为指标，测试产品改进效果效果指数。有些问题是从趋势上发现的，需要升级。比如客户抱怨找不到SDK或者API，我们需要优化API搜索。有些问题是已知的内部问题，例如API可用性问题，并建立机制来监督业务改进。改善效果衡量：首先要有具体的指标。目前主要是工单的减少。但我们认为还不够，因为工单只是冰山一角，数量不够，细节不够，流通周期也长。因此，我们也尝试关闭OpenAPI开发者门户。一方面，我们可以标准化产品体验，另一方面，我们可以直接联系终端客户，获得最详细的反馈。比如客户的反馈可以细化：当某个API的页码设置为0时，会导致功能异常、文档详情不正确、必填字段和非必填字段描述错误等精准问题。通过以上动作，我们可以自动分析OpenAPI用户的主要痛点，并创建数字趋势图进行跟踪。2Step2:Governance有法可依：《阿里云OpenAPI规范》已经制定，迭代到1.3版本，涵盖设计风格、服务质量、资源规范、域名规范、文档规范等子项.,在标准层面统一大家的认知。执法要严：规范落地，光有文字是不够的，必须要有配套的平台机制。关闭阿里云所有API管理，从提高研发效率和全生命周期系统化管理的角度，不断完善API管理平台的核心能力。将标准化的审核规则沉淀到规则引擎中，在用户开发API时自动扫描检查问题，失败时回调。对于不能自动约束的规范，建立审查流程和管理审批流程，增加不合规问题的生产成本，不断提高自动化审查的比例。对原料药质量进行数字化治理，通过质量量化评估各BU、各产品的原料药质量，定期监督并同步改进。违法必究：与阿里云用户体验部门共同推动问题改善，通过用户侧工单减少情况验证效果。以上能力全部沉淀在内部管理平台上。内部云产品可以一站式管理API，以流程化的方式参与API治理过程。3Step3产品化的目标是关闭外部用户的产品体验。过去，OpenAPI的各种功能是分散的、碎片化的。后来我们把OpenAPI相关的所有功能都集成到一个产品中，就是OpenAPI开发者门户。除了通过产品集中构建提升用户体验外，我们还增加了更多Troubleshooting、search、codesample等模块。通过以上三个步骤，我们整体的OpenAPI体验治理的大图如下：图6用户体验管理闭环示意图通过本系统的运行，逐步完善本系统运行中发现的问题通过不断完善API管理平台和API开发者门户的功能，提升用户体验，从2020年的工单情况来看，出现了比较明显的下滑。8.总结阿里云是一个庞大的分布式操作系统。OpenAPI相当于用户层操作内核层的一个重要通道。保证其稳定性、功能、性能和体验，关系到客户的核心体验、企业形象和生态的拓展，也关系到内部产品质量和研发效率。接入层要深、厚、实，才能服务好内外部客户。从团队两年的实践来看，OpenAPI的体验只能通过数字化、系统化的基础设施建设来实现。本文讨论了云端OpenAPI的几个重要概念，希望能激发大家对OpenAPI系统价值的兴趣和关注。参考资料：https://apiacademy.co/2015/04/api-design-202-architectural-layers/https://www.itread01.com/articles/1475911242.htmlhttps://azure.microsoft.com/zh-cn/features/resource-graph/https://maryamalshamsi98.wordpress.com/2014/05/21/linux-file-system-2/
