大概过程与技术原理

脑洞一下：中台以后各个部门的数据以微服务API形式放在API store里面供其它部分消费，为了避免部门打架、中台成本谁来出、费用怎么收的问题。在想能不能基于istio开发为请求计费的插件（计费链），技术实现的大概思路就是就是像zipkin每个调用单元（span）加一个价格，一次API的价格等于调用链路中所有单元（span）价格的求和。

最后的大概可视化效果就是这张图的时间ms，换成人民币单位（估计不要一分钱）

比如调用一次A服务某API价格为a，一次B服务某API价格为b，调一次C服务需要调A和B，那么C调用费用就是a + b + c。其中C分别要给别的服务a和b的费用，c是给自己的。上面为了介绍思想，这里只是做一个简单的求和，其实也许我们可以做更复杂的方案。就像卖商品一样卖自己的API请求。

比如每个服务可以这样定价：

• 基于硬件资源：数据查询次数、CPU、内存
• 数据价值人为定价
• 以上的综合

以上可称为API as Product, Data as Product的按量收费方案。

解决了什么问题

• 第一个上面所说的平台服务谁来买单的问题，实际调用者买单，价格为调用单元的费用总和。
• API请求的定价问题，更科学的定价方案，单纯按照API请求数，忽略了不同请求之间可能耗费硬件资源、业务逻辑复杂度的差异
• 衍生到数据部门，解决数据到底值多少钱的问题
• 收费限制了其它消费者恶意调用的问题，让他们在消费其它第三方数据服务时考虑消费成本，让他们更加节约。对于复杂度较高、数据价值较大的API提高价格，利用市场化手段将API或数据作为产品来管理API。服务提供者可以通过抬价方式限制访问，通过降价方式促销自己的数据。

为什么聊到istio

• istio实现了网络流量的透明代理，对其它服务没有倾入性，新建一个独立的中心服务，不用修改其它服务代码；
• 不用其它服务去配合一个一个在header里面加traceId，parentId，其一是麻烦，需要一个人员去协调那么多微服务团队增加组织协调成本；主要是你觉得别人会配合？我加上这玩意意味着你就要像我收费，我凭啥配合你加？也防止服务使用什么黑科技逃避收费。
• 中心化控制公平公道可仲裁，价格在一个地方，一目了然，API商店里面一个个API明码标价。

 

Q&A

 

• API Gateway可以计费啊？为什么还需要这个

不是从基础架构方面计费，按业务价值；中台没有业务价值，怎么给它定义价值，而且做到每一个API请求他的价格不一样，不是简单地按调多少次来收费；

每一次API请求需要多少钱，是它自己本身花费的费用，加上它调用其它一些服务的成本

• 收费模式？

比如服务A定价取一次user信息2分钱，服务B定价取一次商品信息3分钱），订单服务C调了一次user和商品，就要分别给A和B付2分钱和3分钱，然后D调C，可能它要花8分钱，然后它想知道为什么要花8分钱，于是点开调用链可以看到收费清单，上面明明白白地告诉它8毛钱花在哪里，分别给哪些服务付了多少钱。

• 一个公司内部的，有必要算的这么细吗？

有必要。 第一点，我在公司内部运营部门呆过，因为免费，发现做的API各种被调，不被限制地被调。通过只是想通过收费手段来降低API的调用压力。也有些API服务可以机械性地限流，调用多少次限流，而这种模式是市场化调节。收费高你自然谨慎地调。 第二点，公司高层往往觉得公司的运营部门是一个纯成本消耗的部门，很难去衡量一个内部部门的价值。通过这种方式，可以让高层知道每个部门掌握的业务数据到底值多少钱。为其对内部部门的投资决策提供参考。

第三点，其实在一个公司里面，内部还是各种算账啊，不展开赘述。