應用軟件的成本取捨

週末我凌晨聊到一個話題，就是成本怎麼減下來，最終有一個點是服務器的使用率的統計和限制，已經這塊也是好幾億成本了。

當時我是反對的，使用率確定要關注，可是強調這東西的話，取向有問題。

涉及兩個點：

一 如今的軟件系統自己刻意作了不少切分，主要的目的是爲了可靠性，讓每次修改發佈涉及的單元最小、故障涉及的範圍最小、可組合性最強，全部這些取向都是和單臺機器的性能使用率背道而馳的。 從企業的角度來講，可靠性確定要排在必定的（仍是不能太高）成本前面，由於若是成本最重要的話，不作任何系統就天然沒有這部分紅本了。

使用率是要關注、要限制、也要平衡，可是不能由每個一線程序員來作。

架構師、雲平臺、新技術，去搞定，技術若是目前還不太能特別有效的解決，那這些點不正是技術突破點嗎。

引入新思路、新材料從而達成效果是最有效的，限制和控制，是最下下之策。

二 咱們首先要分清本身的軟件類型，而後再說怎麼管理，若是你的軟件主要挑戰是數據（數據量、數據複雜度、數據變化速度），那你的軟件是數據密集型軟件，運算量原本就不是你的點。 若是你是計算密集型的，處理器的速度是瓶頸，那使用率又自然會特別高，不須要考覈什麼服務器使用率。

因此你看看，這麼一個哪哪都不合適的指標。

以終爲始吧，目標拆出過程，而後取捨動做，每個考覈都會引發一串反應，必定要想清楚。

轉回來，數據密集型的軟件到底該如何作呢，目前看起來你們沒啥太多的概念，不少就是湊業務寫，手裏拿這個Mysql的錘子，看啥都是釘子，調用量高了就加緩存，徹底是傻幹。

我戲稱這種軟件開發爲，攤煎餅，能夠把一勺麪糊，攤成特別大的一張餅，因此固然就須要不少的硬件資源，因此想解決就要今後入手，而非其餘。

數據量、數據複雜度、數據變化速度，你們仔細想一想基於這三個緯度，系統到底怎麼設計纔好。