一.不可預(yù)估的費用

在計費中，會遇到兩種計費情況，固定的費用，不可預(yù)估的費用。

1.固定的費用：商品的費用是確定的，我們知道商品的采購價格，我們對商品進行了定價，之后它的費用就是定好了的，當然市場變化它也會發(fā)生變化，但是在一次交易，此時的成本，價格都是確定的。

2.不可預(yù)估的費用：比如車輛外租，按天計算，每天多少費用，但是對于每個客戶來說，使用成本是變化的，比如有些客戶租了車以后，就不還了。還有些造成了損傷，但是我們依然按照平均價格租給客戶。那么這個系統(tǒng)中的價格體系要復(fù)雜得多。還有云平臺，我們也需要租用別人的帶寬，客戶使用我們的產(chǎn)品時候，有些時候我們也難以計算他究竟會使用多少。比如cdn的流量，有的客戶使用量很大，一天可能幾千元的量，有些客戶使用流量小，每天幾元錢。事后給客戶結(jié)算cdn的費用，如果一個月結(jié)算一次，很可能某些客戶欠費幾十萬。如果一天結(jié)一次，也有幾千元。我們的cdn是使用別的產(chǎn)品，最低粒度是每5分鐘查詢一次使用狀況，沒有流量最大限制。

　　解決辦法：

　　　　a.擔保：提供遠遠高于平均消費的保證金，

　　　　b.事后結(jié)算：很顯然這將風險轉(zhuǎn)移到自己這邊。

　　　　c.盡量細化粒度：比如說每5分鐘就查詢所有賬戶一次，但會增加運行負擔。

車輛租用的客戶都是陌生人，發(fā)生風險只能用概率評估，所以保證金什么的都是在綜合所有租戶的使用情況后，通過統(tǒng)計概率方法設(shè)出一個合理的范圍。

但是計算服務(wù)的提供商，每個客戶價值不同，很難用平均統(tǒng)計對待每個客戶。

針對的，我認為解決的方法，應(yīng)該盡量讓欠費風險最低化，定時查詢顯然不能區(qū)分開不同客戶的風險。最好，使得任何客戶欠費發(fā)生時，所有的欠費在一個小額空間內(nèi)。以欠費的最大額度為標準來設(shè)計程序，來量化風險。

比如客戶費用多的時候，增大查詢間隔，金額少的時候，減少查詢間隔，新客戶減少查詢間隔。通過費用監(jiān)控情況來驅(qū)動其他邏輯。

二.客戶的初始付費金額

客戶在購買產(chǎn)品時候，我們?nèi)绾卧O(shè)定客戶的金額，當并不知道他將花費多少cdn流量的狀況下？如果以這個付費開通了，費用不足時候，我們是什么時候停機，隔一個時間段比如一天停機，5分鐘停機，或者當他費用消費超過最大額時候就停機。

如果我們的很多服務(wù)都是不可預(yù)估的情況，那么對費用的管控就必須更加嚴格，采用費用控制是必要的。如果這種預(yù)估風險性不大，那采用定時也沒有問題。

三.定時扣費的危險

每個時間段進行一次扣費的危險在于，有漏洞可以被利用，在客戶付款的時候，他的賬戶余額并沒有被實際扣除，即使購買了多個產(chǎn)品，也會在某個時間去扣除。那樣造成很大的風險，可以在扣費的一個時間差內(nèi)，可以購買超多的服務(wù)。

四.客戶的操作

客戶的權(quán)限，客戶的賬戶余額不足，都會影響在頁面上可提供的操作。頁面當然需要來設(shè)置那些是可操作的，那些是不可操作的。這種可與不可的邏輯有時候分散在各個業(yè)務(wù)邏輯中，很難修改。我覺得應(yīng)該有個統(tǒng)一的地方對類似情形進行管理。比如頁面的所有權(quán)限可操作性歸后臺某個邏輯統(tǒng)一管理，而價格可操作的邏輯歸某個邏輯統(tǒng)一處理。價格處理措施本來是一個綜合性考慮的，代碼卻分散于各個頁面背后的業(yè)務(wù)控制，不合理。頁面的后臺可能主要是驗證前臺的輸入，或者查詢其他獨立模塊，獲取對應(yīng)的展示數(shù)據(jù)。不要寫可能會被復(fù)用的處理邏輯，不要寫別的系統(tǒng)性的體系中的零件。

為什么價格的控制需要在一個地方？因為價格的管理本身在管理上就是統(tǒng)一為體系的，當價格的體系需要修改的時候，想想看到各處的頁面后臺中去尋找處理邏輯的情況吧。

可以將這種控制單獨作為一個服務(wù)，或者制作成一個mixin之類的東西，讓頁面處理繼承使用。

?

轉(zhuǎn)載于:https://www.cnblogs.com/yasmi/p/5481877.html

總結(jié)

以上是生活随笔為你收集整理的价格与用户权限的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。