作者:觴儿_996 | 来源:互联网 | 2023-05-26 17:22
一.不可预估的费用在计费中,会遇到两种计费情况,固定的费用,不可预估的费用。1.固定的费用:商品的费用是确定的,我们知道商品的采购价格,我们对商品进行了定价,之后它的费用就是定好了的,当然市场变化
一.不可预估的费用
在计费中,会遇到两种计费情况,固定的费用,不可预估的费用。
1.固定的费用:商品的费用是确定的,我们知道商品的采购价格,我们对商品进行了定价,之后它的费用就是定好了的,当然市场变化它也会发生变化,但是在一次交易,此时的成本,价格都是确定的。
2.不可预估的费用:比如车辆外租,按天计算,每天多少费用,但是对于每个客户来说,使用成本是变化的,比如有些客户租了车以后,就不还了。还有些造成了损伤,但是我们依然按照平均价格租给客户。那么这个系统中的价格体系要复杂得多。还有云平台,我们也需要租用别人的带宽,客户使用我们的产品时候,有些时候我们也难以计算他究竟会使用多少。比如cdn的流量,有的客户使用量很大,一天可能几千元的量,有些客户使用流量小,每天几元钱。事后给客户结算cdn的费用,如果一个月结算一次,很可能某些客户欠费几十万。如果一天结一次,也有几千元。我们的cdn是使用别的产品,最低粒度是每5分钟查询一次使用状况,没有流量最大限制。
解决办法:
a.担保:提供远远高于平均消费的保证金,
b.事后结算:很显然这将风险转移到自己这边。
c.尽量细化粒度:比如说每5分钟就查询所有账户一次,但会增加运行负担。
车辆租用的客户都是陌生人,发生风险只能用概率评估,所以保证金什么的都是在综合所有租户的使用情况后,通过统计概率方法设出一个合理的范围。
但是计算服务的提供商,每个客户价值不同,很难用平均统计对待每个客户。
针对的,我认为解决的方法,应该尽量让欠费风险最低化,定时查询显然不能区分开不同客户的风险。最好,使得任何客户欠费发生时,所有的欠费在一个小额空间内。以欠费的最大额度为标准来设计程序,来量化风险。
比如客户费用多的时候,增大查询间隔,金额少的时候,减少查询间隔,新客户减少查询间隔。通过费用监控情况来驱动其他逻辑。
二.客户的初始付费金额
客户在购买产品时候,我们如何设定客户的金额,当并不知道他将花费多少cdn流量的状况下?如果以这个付费开通了,费用不足时候,我们是什么时候停机,隔一个时间段比如一天停机,5分钟停机,或者当他费用消费超过最大额时候就停机。
如果我们的很多服务都是不可预估的情况,那么对费用的管控就必须更加严格,采用费用控制是必要的。如果这种预估风险性不大,那采用定时也没有问题。
三.定时扣费的危险
每个时间段进行一次扣费的危险在于,有漏洞可以被利用,在客户付款的时候,他的账户余额并没有被实际扣除,即使购买了多个产品,也会在某个时间去扣除。那样造成很大的风险,可以在扣费的一个时间差内,可以购买超多的服务。
四.客户的操作
客户的权限,客户的账户余额不足,都会影响在页面上可提供的操作。页面当然需要来设置那些是可操作的,那些是不可操作的。这种可与不可的逻辑有时候分散在各个业务逻辑中,很难修改。我觉得应该有个统一的地方对类似情形进行管理。比如页面的所有权限可操作性归后台某个逻辑统一管理,而价格可操作的逻辑归某个逻辑统一处理。价格处理措施本来是一个综合性考虑的,代码却分散于各个页面背后的业务控制,不合理。页面的后台可能主要是验证前台的输入,或者查询其他独立模块,获取对应的展示数据。不要写可能会被复用的处理逻辑,不要写别的系统性的体系中的零件。
为什么价格的控制需要在一个地方?因为价格的管理本身在管理上就是统一为体系的,当价格的体系需要修改的时候,想想看到各处的页面后台中去寻找处理逻辑的情况吧。
可以将这种控制单独作为一个服务,或者制作成一个mixin之类的东西,让页面处理继承使用。