作爲一名合格的開發工程師，不僅僅要在前期開發階段對業務和技術有深入瞭解，知道選用哪種合適的技術，業務如何拆分，還要思考後期線上環境，資源，延遲，性能等如何優化維護以及分佈式系統一些線上生產的一些問題。
本篇主要針對之前瞭解的情況對硬件設備資源做一個簡單的介紹：
首先分佈式系統線上實踐問題，我們應該對公司的流量，各個服務，網管，註冊中心應該如何部署，部署多少臺機器才合適，每臺機器的配置如何，每天整體流量有多少，高峯期的請求量有多少，你的整體系統是否扛得住（注：很多公司現在直接使用K8S docker 實現，但是你至少得知道你的每個服務能扛多少，應該部署多少個，其本質都是一樣的），對硬件資源要有一個可計算，可測量的概念。
本篇就針對中小型的系統進行一個基本硬件分析：
中小型的系統，大概拆分10~20個服務，（龐大的互聯網公司，一般都是成千上百個），當然這裏只是介紹一些重要的服務，其他的服務可以做一個旁類對比
- 服務註冊中心：簡單的思考下，就知道每秒的QPS最多也就幾十個，但是爲了保證分佈式產生的一些問題(分區容錯性等)這裏考慮部署2臺機器，每臺機器4核8G（每臺機器可以抗每秒幾百請求是沒問題的，上千也可以），高可用冗餘，任何一臺機器死掉，都不會影響系統的運行。（注:如果使用ZK作爲服務註冊中心，那麼根據實際的需要就部署3臺，配置靈活調整）
- 網關係統：因爲網關係統是整個系統服務的一個入口，配置4核8G的機器，請求每臺機器每秒幾百是沒有問題的，但是在量上應該多一點，3~4臺，保證每臺機器的壓力小一點，從而進一步保證可靠性。
- 業務服務：這個需要根據實際業務來判定，應爲在每個系統中，都存在冷服務和熱服務，針對單次業務處理週期長，QPS等進行實際的測試才能做出最優的配置，但一般情況下，每個服務4核8G，每臺機器抗幾百請求是完全沒問題的，但是如果業務處理週期太長，一個SQL之類的都要幾秒鐘，這種可能就問題大了，因此，針對核心的業務如果可以，還是最好優化以及實際的壓測，畢竟是產品的核心，需要自己保證
- 數據庫：數據庫應該是整個系統中最重要的資源之一，我們常規的都是使用Mysql,那麼多少合適？物理機最佳，32核64G，平時抗個每秒幾十或者幾百的請求完全沒問題，最多可以抗每秒幾千請求也沒問題，但是此時會導致Mysql機器的負載很高，CPU使用率很高，磁盤IO負載很高，網絡負載很高。
總結
理論如果沒有用於實踐，那麼它永遠都是理論，當它被你自己實踐了，那麼它就是你的經驗，即使結果最後不理想，因此，針對項目的實際生產環境的配置，剛開始可以參考別人標準的進行部署，但後期需要自己根據線上的數據反饋進行後期調整，讓 發佈上線->數據反饋->調整優化->發佈上線 形成一個閉環，持續改進。