一.不可預估的費用

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

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

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

　　解決辦法：

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

　　　　b.事后結算：很顯然這將風險轉移到自己這邊。

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

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

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

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

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

二.客戶的初始付費金額

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

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

三.定時扣費的危險

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

四.客戶的操作

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

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

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

?

轉載于:https://www.cnblogs.com/yasmi/p/5481877.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。