上幾天，以前公司一個同事在Q群上發了一個《高性能存儲平臺設計文檔》，說請大家幫忙看下，指點一下。

下圖是這個設計里的【系統主體架構圖】：

看了當即覺得有點蛋疼。

首先是網關那里，使用的是PHP來做守護進程；其次數據節點使用MongoDB和MySQL來做主從，對，你沒看錯，可是MongoDB和MySQL怎么做主從？那哥們說，利用PHP做控制。

對于這個架構，我不怎么給面子，直接批為不行。那哥們跟我一樣，只懂PHP，不懂C++，所以會寫出這樣的架構也就不奇怪了。但是即使是不懂C++我也知道，要做到高性能不能用PHP。PHP 1.不支持多線程，2.進程非常笨重，加載的東西太多，3.解釋性語言運行速度比C++慢一個數量級，4.長期運行穩定性差。5.而且要做到高并發最好是使用epoll模板，要使用epoll模型就要用到libevent，據我所知PHP是沒有這個擴展的。單靠PHP自己的話，估計幾百個并發就將網關的內存和CPU耗盡了。

?

我問那哥們這個模型的一些關鍵點如何處理：

1.選擇節點的一致性hash算法是怎樣的，如何保證SELECT和UPDATE操作的數據在同一個節點上。

2.MongoDB和MySQL間的數據主從同步如何保證，出現異常如何處理。

3.MongoDB緩存數據的淘汰機制如何考慮。

4.由于MongoDB和MySQL的操作是異步的，能否保證異常的情況下，數據在MySQL端不丟失。

5.每個節點可以達到多高的讀寫性能。整個系統總體的讀寫性能又如何。

哥們無法很好的回答以上的問題，我看出來他只是將一些很棒、看起來好玩的技術拼合在一起而已。

?

其實我以前也經常像我那哥們一樣，不滿足于做單調乏味的運營開發工作，希望在技術上往橫向和縱向不斷發展。可是受限于自己的知識和技能，所以往往會向一些看上去更淺短易懂的方向去做嘗試。例如畫系統架構圖就是一個看上去比較簡單的、又讓人覺得是比較牛B的工作。一想到自己設計的架構可以支撐海量用戶，一股成就感就涌上心頭。

后來一次跟組長tenfy和總監minos的談話讓我的困惑頓結。那是在一次方案評審會上。我在數據層的設計上，擔心服務器承受不住壓力，所以打算使用cache。不過這樣做就會增加系統復雜度，要考慮處理各種cache和DB間的異常情況，拉長開發時間。但是minos和tenfy否決了cache方案，說直接查詢MySQL就行了。minos向我們解釋，淘寶在查詢個人訂單的時候，就是直接讀數據庫的。如果使用cache的話，就會有cache數據和DB不一致的問題需要解決，復雜度大大增加了。可是直接查DB不擔心服務器壓力的問題嗎？minos說淘寶做過統計，用戶查看個人訂單的訪問次數很少，直查DB完全可以撐得住這個量。

會后tenfy又跟我們說了系統架構設計方面的一些經驗。他問我們，知道我們外網DB服務器平均每秒可以處理多少次查詢請求嗎？如果使用了cache后，又可以支撐多少次查詢請求？系統的最高并發是多少？知道我們的網站現在一天的PV是多少嗎，高峰值是多少？要支撐目前的業務，最好使用哪些技術，而這些技術的性能又是如何，極限值是多少，優點是什么，缺點又是什么？要支撐每天的訪問高峰，至少需要幾臺機器？而這些機器間應該用什么技術去聯合成一個架構，DB主從？LVS？每種架構的性能表現又是如何，優點和缺點又是什么？成本呢？

對于以上這些運維數據，我是一點都不清楚的，而tenfy則幾乎都能說出這些數據的一個大概值。tenfy說，只要對所有的這些數據了然于心，在設計項目架構的時候就能很快想出在成本、性能、時間、復雜度等權衡最優的架構。從這里可以看出，設計架構這件事并不是簡單的畫圖，也不是簡單的將一些技術拼合起來，更不是拍腦袋的事情。它是需要根據實際數據分析后才能決定的事情。

?

?

轉載于:https://www.cnblogs.com/lefeng/archive/2012/05/13/2498074.html

總結

以上是生活随笔為你收集整理的关于架构的一点思考(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

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