在計費中,會遇到兩種計費狀況,固定的費用,不可預估的費用。spa
1.固定的費用:商品的費用是肯定的,咱們知道商品的採購價格,咱們對商品進行了訂價,以後它的費用就是定好了的,固然市場變化它也會發生變化,可是在一次交易,此時的成本,價格都是肯定的。設計
2.不可預估的費用:好比車輛外租,按天計算,天天多少費用,可是對於每一個客戶來講,使用成本是變化的,好比有些客戶租了車之後,就不還了。還有些形成了損傷,可是咱們依然按照平均價格租給客戶。那麼這個系統中的價格體系要複雜得多。還有云平臺,咱們也須要租用別人的帶寬,客戶使用咱們的產品時候,有些時候咱們也難以計算他究竟會使用多少。好比cdn的流量,有的客戶使用量很大,一天可能幾千元的量,有些客戶使用流量小,天天幾元錢。過後給客戶結算cdn的費用,若是一個月結算一次,極可能某些客戶欠費幾十萬。若是一天結一次,也有幾千元。咱們的cdn是使用別的產品,最低粒度是每5分鐘查詢一次使用情況,沒有流量最大限制。cdn
解決辦法:繼承
a.擔保:提供遠遠高於平均消費的保證金,產品
b.過後結算:很顯然這將風險轉移到本身這邊。後臺
c.儘可能細化粒度:好比說每5分鐘就查詢全部帳戶一次,但會增長運行負擔。監控
車輛租用的客戶都是陌生人,發生風險只能用機率評估,因此保證金什麼的都是在綜合全部租戶的使用狀況後,經過統計機率方法設出一個合理的範圍。權限
可是計算服務的提供商,每一個客戶價值不一樣,很難用平均統計對待每一個客戶。程序
針對的,我認爲解決的方法,應該儘可能讓欠費風險最低化,定時查詢顯然不能區分開不一樣客戶的風險。最好,使得任何客戶欠費發生時,全部的欠費在一個小額空間內。以欠費的最大額度爲標準來設計程序,來量化風險。方法
好比客戶費用多的時候,增大查詢間隔,金額少的時候,減小查詢間隔,新客戶減小查詢間隔。經過費用監控狀況來驅動其餘邏輯。
客戶在購買產品時候,咱們如何設定客戶的金額,當並不知道他將花費多少cdn流量的情況下?若是以這個付費開通了,費用不足時候,咱們是何時停機,隔一個時間段好比一天停機,5分鐘停機,或者當他費用消費超過最大額時候就停機。
若是咱們的不少服務都是不可預估的狀況,那麼對費用的管控就必須更加嚴格,採用費用控制是必要的。若是這種預估風險性不大,那採用定時也沒有問題。
每一個時間段進行一次扣費的危險在於,有漏洞能夠被利用,在客戶付款的時候,他的帳戶餘額並無被實際扣除,即便購買了多個產品,也會在某個時間去扣除。那樣形成很大的風險,能夠在扣費的一個時間差內,能夠購買超多的服務。
客戶的權限,客戶的帳戶餘額不足,都會影響在頁面上可提供的操做。頁面固然須要來設置那些是可操做的,那些是不可操做的。這種可與不可的邏輯有時候分散在各個業務邏輯中,很難修改。我以爲應該有個統一的地方對相似情形進行管理。好比頁面的全部權限可操做性歸後臺某個邏輯統一管理,而價格可操做的邏輯歸某個邏輯統一處理。價格處理措施原本是一個綜合性考慮的,代碼卻分散於各個頁面背後的業務控制,不合理。頁面的後臺可能主要是驗證前臺的輸入,或者查詢其餘獨立模塊,獲取對應的展現數據。不要寫可能會被複用的處理邏輯,不要寫別的系統性的體系中的零件。
爲何價格的控制須要在一個地方?由於價格的管理自己在管理上就是統一爲體系的,當價格的體系須要修改的時候,想一想看到各處的頁面後臺中去尋找處理邏輯的狀況吧。
能夠將這種控制單獨做爲一個服務,或者製做成一個mixin之類的東西,讓頁面處理繼承使用。