深度分析:为啥说API是IT的未来?

版权说明:本文在第一节,参考引用了 刘国强 CA Technologies中国区技术总监的《到底什么是“API经济学”》文章部分内容。本文其他章节技术部分则参考了社区和红帽的技术文档。

一、API经济的兴起

API是随着互联网和云计算的兴起而催生的产物。API是三个英文字母Application Program Interface的首字母简写,即应用程序接口。像云供应商亚马逊、互联网巨头Google、社交媒体Twitter,他们的服务都是通过API的方式来提供的。亚马逊的首席执行官Jeff Bezos要求亚马逊的所有开发人员:

  • 数据和功能只能通过APIs 来提供给使用者
  • APIs 必须设计为便于外部开发人员调用
  • 如果你不遵守这个规定,你将被开除

API热在西方出现较早。早在2012年,API就为国际的互联网巨头们带来了非常可观的经济效益:

Salesforce超过一半的收入:Salesforce 23亿美元的年收入中超过的一半的收入是通过API产生的;

  • 50亿笔交易:Google 每天通过API处理50亿笔交易
  • 130亿笔交易:Twitter每天通过API处理130亿笔交易
  • 1万亿笔交易:亚马逊每天通过API处理1万亿笔交易

相对于国外,API经济在国内也已经开始成形,只是还没有引起太大关注。国内像微信、QQ、人人等,都是有开发平台的,开发平台上就有API的管理。API如果被用于商业用途会进行收费,可以根据功能的多少、调用的次数、优先级等分为不同的费用模式。因此,API计费不只是互联网企业的专利,所有的银行、企业甚至政府都可以使用,就像银联在不同银行之间的转账,都属于API抵用。以前企业大多数是在内部的系统之间调用,现在把系统可以提供的服务都用API的形式开放出来,形成API管理门户,分为企业开放者和个人开发者,要经过认证、付费之后就可以使用,付的费用越高,就可以调用更多的服务,比如像百度地图、高德地图和定位GPS。

API的本质是一种服务,无所不在的服务。移动其实是一个载体、一个表现形式;移动在本质上是让服务变得随时随地可以用。手机上的各种APP,其实都是一个服务的入口和访问口,如何来提供这种服务呢?就是后端跟API相关,安全的去使用API。

以航空公司的服务为例,来做一个API平台的使用场景分析:

系统中首先会包含内部的票务系统,剩余票量是多少,乘客信息,座位情况,各方面信息都会显示。

第二,系统会与银行通讯,来验证乘客有没有付款,使用了何种付款方式。

第三,系统还需要和政府打交道来核实乘客身份。比如身份证的信息是否真实,需要和公安部的信息进行比对。公安部也是通过API进行管理,系统一旦被攻破,所有的信息都会有被泄露的危险。其实我们会发现企业和企业之间都是通过API连接的,这就变成了物联网的概念。物联网中的通信不需要人的干预,我们把它叫做机器和机器之间、系统和系统之间的通信。在系统和系统之间的通信也要管理,不管理就会出问题。系统和系统之间就是通过API通信的。

以前大家购买服务都是以一个整包为单位购买,现在拆分得很清楚,因为后端有很多系统,都会分开进行收费,是按照API来计费的。API本质上是很多的函数。一般是很多小函数,就是并列着有很多功能列出来供选择,选择的越多,收的费用越多,这就是跟API收费了。微信也是一样,都是按量去计费的。

API有两种收费标准,第一个是按量计费,第二个是按功能计费。API有提供很多功能,你选择不同功能的套餐,范围越大收费越高。API不再是简简单单的开放一个函数,而是要涉及到开放给谁,怎么计费的问题。这也是API为什么需要门户(Portal)来管理的原因。我不光要告诉你能不能访问,能访问什么,还要告诉你要交多少钱,也就是和费用、经济挂钩了。

以前API一般访问量很小,就是系统和系统之间调用,或者迫不得已调用。当API突然变成服务概念的时候,你会发现API被调用的数量是海量的,这就意味着对API的管理已经势在必行。API的身份要统一管理,API的单点登陆要统一管理,API的能力、API的计费全部要单点管理,这才催生了API经济的概念。

以前API一般访问量很小,就是系统和系统之间调用,或者迫不得已调用。当API突然变成服务概念的时候,你会发现API被调用的数量是海量的,这就意味着对API的管理已经势在必行。API的身份要统一管理,API的单点登陆要统一管理,API的能力、API的计费全部要单点管理,这才催生了API经济的概念。

二、API经济之路

近些年,IT发展的速度呈加速度不断增加的情况。

开发流程:从瀑布、敏捷到devops

应用架构:从单体应用、多层应用到微服务

部署方式:才能高物理机、虚拟机到容器

应用基础架构:从数据中心到云

应用架构的发展道路是:

SOA(面向服务的架构)-> Microservice (Smart endpoint)-> Microservice(simple pipeline) ->API-> Event-based architecture -> Container -> distributed environment-> devops enabled事件驱动

一个完整的API管理方案应该具备上图描述功能。

三、API管理的方案

关于API管理的方案,我们看一下全生命周期API管理魔力象限:

2016年:

2018年:

我们看到红帽的3scale是属于领导者之一。

3scale API管理提供了5个关键功能,它们是:

  • 访问控制和安全
  • API合同和费率限制
  • 分析和报告
  • 开发人员门户和交互式API文档
  • API帐单和付款

您如何管理API?谁有权接入?您能否为不同类型的用户制定并控制不同的接入权限?您能否控制哪些不同应用可以做到这一点?

接入控制是保证仅有经过成功验证的有效证书的API调用命令能够接入您的API。

3scale为您提供的多种标准的API验证和安全选项,这些选项可以单独或结合使用,用于签发证书并控制接入:

•标准API密钥•应用ID和密钥对•OAuth v1.0和2.0

于安全需求更加复杂的客户,3scale计划提供更多定制选项,例如IP地址和域白名单。

集中仪表板可用于轻松地根据需要签发和撤销证书,并且即时抛弃恶意的API调用,从而使您能够保护后端服务。

3scale的接入控制能力不限于基础的安全和验证。应用和账户计划允许您限制对特定终端、方法和服务的接入,并且轻松地对用户组采用接入策略。分层接入权限使您能够轻松地通过收费计划而从API中获益。

为什么提到合约,IT发展到一定阶段,一方面可以把我们的服务提供给集成商,商业伙伴。

所以,API管理的另外一个很重要的商业价值,那就是收费和限制。

应用计划允许您为API的使用设置速率限制,并控制开发人员组的流量。您可以设置按时间段限制进来的API调用,以保护您的基础架构,并且使流量顺利地流动。对于达到或超过速率限制的应用,自动触发超速提醒,并且为超限应用定义行为。速率限制可应用于收费计划,而且这种计划可以通过配置而对于超过速率限制的调用收取更高的费用。

您可以采用3scale的分析能力监控使用量,触发相关系统中的操作或工作流,并且对于任何计量指标进行追踪。

3scale允许您定义追踪每个终端的指标和方法。根据您的API的用例,您可能希望追踪每个应用或账户的所有以下方面:

••一个或多个服务或终端的整体流量(点击或交易)•CPU时间,例如计算时间或者另一种内部资源的使用量•通过API上传或下载的数据传输量,以MB或GB为单位•每次调用返回的数据对象或记录数量

报告是全方位而且细颗粒度

ActiveDocs

通过基于Swagger框架的3scale ActiveDocs,您的开发人员可以从文档网页实时探索API。只需向您的API添加一个符合Swagger要的规范,将其添加到您的管理门户中,交互式文档就能够供开发人员立即使用。

Swagger是一种开源框架,用于友好且轻松地进行API文档记录和探索。它是API的极为简单但强大的RESTful展示方式。借助Swagger,开发人员可以学习、处理、测试并调试您的API的每个要素。另外,它使得开发人员能够以更简单的方式开发应用。

开发人员门户

3scale提供了内置的最新CMS门户,允许您非常简单地创建带有定制域的自有品牌的中心,用于管理开发人员交互并提高API普及度。

除了文档外,您可以考虑添加用例、代码样本、轻松“开始”信息、文档和定价。

•为应用计划定义并设置定价规则•通过API以自定义的频率生成发票•处理多种类型的信用卡付款

为您的API定义收费计划和支付规则

根据您的API的业务目标以及提供的特性的数据,您可能希望提供免费和收费形式的API接入服务,或者为满足不同的开发人员需求提供多级收费账户接入服务。API的货币化通常依赖定价模式,而大家模式考虑了以下三个因素:

业务量或使用量

制定计划的最简单方式是基于业务量或使用量。调用量更高的客户一般会通过接入API而获得更多价值。3scale允许您根据全局的API调用次数而采用这种定价模式,或者对于不同的方法进行更加细化的使用。您还可以选择是否希望允许客户在达到计划中规定的调用限制后继续调用,以及是否希望在达到计划限制后对API调用实施超限定价。

功能

接入某些终端或方法是另一种定义不同计划等级或区分标准和高级计划等级的方式。客户通过支付更多费用而接入更先进的功能或者价值更高的功能,而享受低价或免费的用户仍然能够以高效的方式使用您的API。

资源使用

定价计划有时考虑客户在每个计划等级内直接或间接产生的基础设施成本。用户数量、带宽消耗以及支持可用性或SLA条款都是将资源使用量用于定价模式的常见方式。

红帽的API管理方案是3scale:

上图中:

API Gateway的作用: 处理API管理策略执行(流量管理)

API Manager的作用:API管理策略配置,分析,计费。

3Scale可以做到:

1.定义API消费者细分,为每个细分配置策略

2. 每个包的指标

API端点访问

费率限制

3.能够通过API创收和创建商业模式

3 Scale中的分析报表功能,可以提供:

(1)API性能和流量模式智能

(2)提供应用程序或开发人员在什么时候访问了那个API endpoint

(3)可以跟踪和监控使用情况,并通过API,应用程序,方法和指标生成报告

(4)可以导出数据并创建自动警报

API的计费和付款:

(1)完全集成的API计费和支付管理

(2)使客户能够简化API访问的货币化

(3)提供支付解决方案集成:Stripe,Braintree / PayPal,Adyen等

(4)让客户在API消费者和提供者之间实现简单的端到端计费

3 scale有在线体验的服务,地址:https://www.3scale.net

可以自行注册账户:

注册成功以后,登录界面:

查看默认的组织:

查看默认的用户:

查看用户的app:

查看API的调用情况(无调用)

四、集成API管理展示

本实验将展现3scale如何与一个已经存在的API做集成。

本实验使用的api是finto。Finto是芬兰语辞典服务,它可以实现词汇表的出版和浏览。该服务还提供了将叙词表和本体集成到其他应用程序和系统中的接口。

查看finto的API:

接来下,我们在3scale中集成finto API。

登录界面,选择API菜单,选择定义。

增加API定义:

然后保存,选择API集成:

选择集成,API集成菜单中,有三部分内容:API、API网关、client。

在API部分,private base url选择finto api的地址:

在API网关部分,增加mapping rules:

在client配置部分,增加API test get request地址:

然后保存

然后,我们到分析界面,查看API调用,可以看到GET /vocabularies被调用的次数是8:

接下来,通过Postman工具,模拟客户端对api的访问,发一个get请求:

再查查看,GET /vocabularies 被调用次数增加到9:

再次发起3次请求后:

API调用次数增加到:

四、配置Application Plan展示

3scale API管理平台使用application plan的概念,来定义具有不同API管理策略的API消费者细分。这些策略可以是不同的访问权限集合、onboarding procedures、终端或资源访问权限、货币化模式。

在本实验中,我们将配置一个application plan,然后将一个应用的转到这个plan中。

首先创建一个application plan:

输入名称:

给plan定义limit:

也就是说一个小时最多被访问五次:

然后增加一个feature:

输入名称:

保存后,启用这个feature:API Promotional Campaign

然后,创建一个新的用户:

用户名称:davidwei

用户创建好以后,会自动创建一个默认的app:

我们进入这个app的配置,将这个app指定到刚才创建好的application plan:public api

报错以后,我们看到这个application plan的预设值,已经附加到这个应用上:

五、API分析数据的展现

我们看一下API分析数据的具体内容:

可以下载详细的分析数据表格:

选择以天方式显示:

以小时为单位显示:

从应用视角查看调用:

给用户配置查看报告的权限:

魏新宇

  • "大魏分享"运营者、红帽资深解决方案架构师
  • 专注开源云计算、容器及自动化运维在金融行业的推广
  • 拥有MBA、ITIL V3、Cobit5、C-STAR、TOGAF9.1(鉴定级)等管理认证。
  • 拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证。

参考资料:

3Scale GithubOrganization,https://github.com/3scale

3Scale Blog,https://www.3scale.net/blog/

Red Hat 3Scale FAQ,https://mojo.redhat.com/docs/DOC-1104042

sme-apis mailing list,http://post-office.corp.redhat.com/mailman/listinfo/sme-apis

3Scale One-Stop,https://docs.google.com/document/d/1iYyn666wo1D02Wn0nxCS5NR1_rRmgPvkav-hMWiWyNE/edit#heading=h.1ft5mwfmvjh5

原文发布于微信公众号 - 大魏分享(david-share)

原文发表时间:2018-05-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏星流全栈

2016年十大顶级开源项目

1983
来自专栏达观数据

从“集装箱运输”了解容器技术

容器技术的火爆和日益普及已经成为不争的事实,众多公有云平台纷纷支持Docker,AWS、Google、Azure、阿里云以及国内的各大公有云厂商都推出了容器云业...

801
来自专栏韩伟的专栏

如何设计运维友好的服务器端系统

如果我们在开发的时候,就充分考虑到系统的运维需求,就算只进行了一些简单的约束,都能让运维工作有巨大的改进。我想这也是所谓DevOps流行起来的原因吧。

4750
来自专栏ThoughtWorks

关于前端的思考:AngularJS 2.0以及前后端边界 | TW洞见

今日洞见 文章作者来自ThoughtWorks:吕靖,文中插图来自网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任...

4188
来自专栏北京马哥教育

20款开发运维必备的顶级工具

开发运维工具与软件开发领域的最佳实践密切相关,也与必要的规范密切相关。在整个开发生命周期涉及到一大批新旧工具,从规划、编码、测试、发布到监控。本文介绍你应该考...

3466
来自专栏即时通讯技术

微信团队分享:iOS版微信的高性能通用key-value组件技术实践

本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程,该组件在微信内部被命名为MMKV(以下简称MMKV)。

622
来自专栏极乐技术社区

一周小程序【资讯教程Demo】更新

轻松一刻 ? 漫画来自于设计师西乔《神秘的程序员们》 资讯与教程 【微信小程序】再次授权地理位置getLocation+openSetting使用 实战分享,蓝...

2058
来自专栏ATYUN订阅号

Firefox利用机器学习驱动的扩展帮助用户探索网络

Mozilla的Firefox浏览器今天宣布了一项名为Advance的新实验扩展,它使用机器学习来帮助用户在上下文中更直观地浏览网页。此扩展是Firefox正在...

401
来自专栏精讲JAVA

前后端分离实践的架构设计

前后端分离的项目开发策略已经不是什么新鲜东西了,网上介绍这方面的文章非常多。我自己是在14年的时候接触到的,对这种开发策略一直爱不释手,不管新老项目都会首先用前...

803
来自专栏互联网杂技

开始学习Linux的一些建议

建议读者范围 1、有开发经验者。 2、科研人员(由其Numrical)。 3、动手能力强的。 4、只是好奇,对于Linux只是浅尝辄止的就不建议继续往下看了。 ...

5417

扫码关注云+社区