提到API，从事技术的同学都十分熟悉，无论是在操作系统上开发软件，还是打造分布式网络服务，都离不开对各种API的调用。对应用程序开发人员来说，都会通过各种编程语言、系统调用和各种类库、编程框架构建系统，为了提升开发效率和统一性，就出现了各种各样的API标准，例如POSIX。这些标准的实现保障了应用程序可以不做过多修改就能运行在各种软硬件平台上，大大促进了整个IT生态的发展。
然而就云计算的API来看，当前并没有类似POSIX这样的API标准，基本上各大厂商各自为政。当然，有一些业界主流标准例如OAS获得多数云厂商的支持，但云厂商本身的API却往往由于历史原因、技术路线原因百花齐放，例如AWS的OpenAPI属于RPC风格，而Azure则是WebService风格，GCP则是基于gRPC为主流。技术方面的论述很多，本文更想从客户体验、研发效能的角度来阐述OpenAPI对云计算整体竞争力的重要性。
如果将阿里云飞天操作系统与传统操作系统类比，那么它也是由内核层、接口层、操作界面、业务应用组成，计算、存储、网络等核心产品构成了内核，API层承担内核的管控和数据通信，各式各样的控制界面则相当于操作系统的Terminal/Windows/mac OS UI，基于云计算的各种行业应用则是跑在这个操作系统上的应用。
阿里云不同于传统操作系统，OpenAPI自然也不同于其他业态的API体系，例如淘系、B2B的开放平台。业务开放平台输出的是以业务数据为主的服务，目的是为了整合商业生态，而阿里云开放平台输出的是云操作系统的管控能力、数据操作能力和其他企业级能力。前者重心是服务商业模型，而后者重心是服务技术底座。因此，云计算的OpenAPI体系要以服务技术开发者和企业场景为中心，保障技术体系的健全稳定，对外紧密对接行业技术体系（例如开源工具、三方厂商），对内促进众多云服务协同管理。
阿里云的OpenAPI有如下特点：
数量多：当前阿里云OpenAPI数量高达1万多个，每天调用量上百亿，分布在近300个产品上。
增速快：业务发展快，近年来每年数量的增速接近100%。
API类型多：OpenAPI大体分为管控、数据两类，管控类又分为RPC/ROA两种形式，数据类又会分为数据流、文件等具体类型，还有很多业务需要有自己的格式。
产品协同要求高：单个OpenAPI是不能满足用户要求的，场景化的用户需求需要多个产品的多个OpenAPI组合才能服务，这对API编排、产品间API协同提出了更高的要求。例如在稳定性方面，一个产品的OpenAPI出问题有可能造成整个管控链路的雪崩。
企业能力需求强烈：OpenAPI主要是用来进行云资源管理或数据传输的，操作对象都是用户资产，除了常规的身份管理、权限管理外，对企业来说还要服务于运维、财务、法务、监管等部门，当涉及众多的云产品时对架构和底层设施的完备性、准确性、及时性要求很高。
与行业技术趋势结合紧密：云是全球化的，作为平台它要想服务好各种场景、人群就离不开与各种业界标准和技术体系相结合，云计算与开源行业高度结合证明了我们做的技术不能闭门造车。
稳定性风险加大：商业开放平台的OpenAPI如果不稳定影响的可能只是客户侧某个业务功能模块或流程，但是云OpenAPI出问题影响的可能是客户底层技术系统，爆炸半径会更大。
调用热点集中：调用量分布基本符合二八原则，20%的云产品承担了80%的调用量，核心产品的体验决定了用户对阿里云的体感，保障客户典型场景的运作至关重要。
上述特点决定了云上的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要有MSDN，Java开发要能够有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就是面向资源的。甚至很多平台服务如账单，也需要资源的概念才能更好地管理。
如果能够统一资源模型，就相当于客户和阿里云在有一套面向对象的Java类或者数据库表，凡是依赖该资源模型的产品都将从中受益，理解更容易，沟通上保持一致性，研发上可以提供统一的技术方案提高效率。
所以，面向资源编程的API设计，对于客户和云平台自身都是非常重要的，如果前期不考虑，后期会付出更大的成本，必将影响阿里云整体服务质量。
元数据是关于数据的数据，它描述的是数据组织、数据域及其关系的信息。元数据平台并不是新鲜事物，比如在大数据领域就有很多应用。由于阿里云有数百个产品，上万个OpenAPI，所以资源的数量也必定是庞大的，这时候就有必要有一个统一的平台来管理资源信息。而资源只是一种抽象，背后还需要依赖 OpenAPI的元数据，两者结合才能对外提供完整的服务。
那么统一OpenAPI/资源元数据能带来哪些价值呢：
1 . 促进产品体验一致性：阿里云各个产品线独立发展，但是会面临此资源非彼资源的尴尬境地，每个产品都有自己的认识，非常不利于统一客户体验。
2 . 提升沟通效率：统一的模型就像一个标准的数据库schema，能够让相关的业务方都能够在一个语境中沟通。
3 . 提升研发效率：结构化的标准模型，能够让程序代替人来处理模式化的数据；以Terraform为例，有了资源元数据，可以直接编写自动化脚本生成terraform模块，将云产品的接入效率提升了50%左右，过程中就节省了Go语言研发资源和联调成本。
4 . 提升业务质量持续保障：软件研发有个痛点是云产品初次发布后，如果随着业务迭代，如何保障过往的功能正确性。以阿里云的RAM产品为例，如果我们能够将资源元数据、API访问日志、RAM的Policy与云产品实际鉴权日志放在一起，通过对比元数据声明内容与实际发生的动作，就可以检查云产品的鉴权行为是否符合预期。相比于人治，基于数据和代码的自动化平台检查机制会更高效、更准确。
5 . 更多的业务场景赋能：Azure有一个产品叫Resource Graph Explorer，它能够按照资源维度管理平台上所有的资源，跨地域也不是问题，有点类似于Windows的资源管理器。完善的元数据管理，将使得这类产品的研发变得可能。可能有人会有疑问：没有元数据就不能做吗？理论上可以，但是一定是事倍功半，因为它需要与各产品反复协调沟通，成本极高，而不是用一套平台来承载着标准化的生产流程，且不好复用，不可同日而语。
所以统一的阿里云OpenAPI/资源元数据管理，对内价值是许多围绕资源的业务开发都将变得更加轻松，甚至无代码化，提升业务效能，对外客户将能得到与内部一致的业务模型，提升用户体验，更加方便地集成。
云操作系统想服务好客户，经过优良设计的API是必需品，否则用户很难快速高效地基于API层来开发和部署应用服务，会对商业竞争力造成严重影响，一个各种理念能力都是顶级但却难以管理的操作系统谁愿意使用呢？
因此，OpenAPI不止是技术问题，也是产品问题，是产品体验的重要组成部分，需要慎重对待。
那么OpenAPI的客户体验能不能被度量？阿里云开放平台刚开始发力OpenAPI时面临的最大问题是：客户和内部都有人吐槽阿里云API不好用，都是点状问题抛出和客户需求驱动，没有一个体系化的方法来衡量客户体验指标，且不能规模化解决问题。
阿里云的 OpenAPI数量1万多个，点状的、模糊的反馈对解决全局问题没有帮助，且用户其实是对具体产品有概念，但针对OpenAPI概念性却不强，调研主观偏差更大。
阿里云的OpenAPI体验是一个全链路问题，如下图：
长长的链路，任何一个环节没做好都有可能导致用户体验不好；而且反馈的信息也是五花八门，难以抽取有效信息。因此有几个核心问题需要依次解决：
我们的做法是这样的：
通过上述动作，我们能够自动化分析出OpenAPI用户的主要痛点，并建立数字化趋势图去跟踪。
3 . 违法必究：联合阿里云用户体验部门一起推动问题改进，并通过检查用户侧工单降量情况来验证效果。
上述能力，都沉淀在内部管理平台上，内部云产品可以一站式管理API及流程化参与API治理过程。
目标是收口外部用户的产品体验。以前OpenAPI的各项功能是分散割裂的，后续我们将所有与OpenAPI相关的功能集成正在一个产品中，即OpenAPI开发者门户 ，除了通过集中的产品建设提升用户体验外，还针对使用链路增加了troubleshooting、搜索、codesample等模块。
通过以上三步，我们整体OpenAPI体验治理大图如下：
通过这套体系运转中发现的问题，都会通过API管理平台和API开发者门户的功能上不断的完善，去逐步提升用户体验，从2020年的工单情况看，有比较明显的下降。
阿里云是个庞大的分布式操作系统，OpenAPI相当于用户层操作内核层的重要通道，保障它的稳定、功能、性能、体验关系到客户的核心体验，关系到公司形象和生态拓展，也关系到内部产品质量和研发效率。接入层必须做深、做厚、做强才能让内外部客户被服务好。从团队两年的实践来看，数字化、体系化的做好基础建设才能做好OpenAPI体验。本文就云上OpenAPI的几个重要概念进行论述，希望能抛砖引玉，引起大家对OpenAPI体系价值的兴趣和关注。
参考文献：
本课程您将学习到如何快速将存量的应用迁移到云开发平台，通过几种常见的应用框架迁移的方法，让存量应用快速实现云原生架构的改造。1. Egg、Express、KOA等Node应用的迁移；2. SpringBoot、SpringMVC等Java应用迁移；3. PHP应用迁移；4. Python应用迁移；5. Midway一体化应用迁移。
本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/zsBcikZpkeMzFxvzj1gmaw
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而，京东官方通过微博发言人发布的消息澄清了这些传言，称这些言论纯属虚假信息和蓄意捏造。
日前，据博主“@超能数码君老周”爆料，国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道，荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦（ASML）CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候，抖音悄然上线了一款名为“青桃”的 App，Slogan 为“看见你的热爱”，根据应用介绍可知，“青桃”是一个属于年轻人的兴趣知识视频平台，由抖音官方出品的中长视频关联版本，整体风格有些类似B站。
日前，威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”，同时，他发文表示：中国汽车普及率低于非洲国家尼日利亚，每百户家庭仅17户有车。意大利世界排名第一，每十户中九户有车。
近日，一项新的研究发现，维生素 C 和 E 等抗氧化剂会激活一种机制，刺激癌症肿瘤中新血管的生长，帮助它们生长和扩散。
据媒体援引消息人士报道，苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后，3D系统一度大涨超10%，不过截至周三收盘，该股涨幅回落至2%以内。
9月2日，坐拥千万粉丝的网红主播“秀才”账号被封禁，在社交媒体平台上引发热议。平台相关负责人表示，“秀才”账号违反平台相关规定，已封禁。据知情人士透露，秀才近期被举报存在违法行为，这可能是他被封禁的部分原因。据悉，“秀才”年龄39岁，是安徽省亳州市蒙城县人，抖音网红，粉丝数量超1200万。他曾被称为“中老年...
9月3日消息，亚马逊的一些股东，包括持有该公司股票的一家养老基金，日前对亚马逊、其创始人贝索斯和其董事会提起诉讼，指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息，为推广自家应用，苹果现推出了一个名为“Apps by Apple”的网站，展示了苹果为旗下产品（如 iPhone、iPad、Apple Watch、Mac 和 Apple TV）开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价，引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金（Future Fund）管理合伙人加里·布莱克发帖称，降价是一种“短期麻醉剂”，会让潜在客户等待进一步降价。
据外媒9月2日报道，荷兰半导体设备制造商阿斯麦称，尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效，但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日，根据美国证券交易委员会的文件显示，苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元（约 4.65 亿元人民币）。用于在 2023-2025 年期间，发射卫星，进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道，马斯克旗下社交平台𝕏（推特）日前调整了隐私政策，允许 𝕏 使用用户发布的信息来训练其人工智能（AI）模型。新的隐私政策将于 9 月 29 日生效。新政策规定，𝕏可能会使用所收集到的平台信息和公开可用的信息，来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日，荣耀CEO赵明在采访中谈及华为手机回归时表示，替老同事们高兴，觉得手机行业，由于华为的回归，让竞争充满了更多的可能性和更多的魅力，对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能（AI）系统，该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日，非营利组织纽约真菌学会（NYMS）发出警告，表示亚马逊为代表的电商平台上，充斥着各种AI生成的蘑菇觅食科普书籍，其中存在诸多错误。
社交媒体平台𝕏（原推特）新隐私政策提到：“在您同意的情况下，我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上，各大企业都带来了最新的理念和产品，而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品，具体内容为：“以我对我‘子公司’的了解，我认为 iPhone 15 跟 iPhone 14 不会有什么区别的，除了序（列）号变了，这个‘不要脸’的东西，这个‘臭厨子’。
