【随笔】中台服务,谁为你的服务买单 | 王柏元的博客

174 阅读2分钟
原文链接: wangbaiyuan.cn

大概过程与技术原理

脑洞一下:中台以后各个部门的数据以微服务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明码标价。