架構設計自然也有一些技巧的。
1.分層
乙個軟體通常分為表現層（ui部分）、介面層（後台服務的通訊介面部分）、服務層（實際服務部分）、儲存層（持久化儲存部分，儲存到檔案或者資料庫）。
分層的軟體，可以解耦各個模組，支援並行開發，易於修改，易於提公升效能。
2.soa（service-oriented architecture，面向服務的結構）
3.效能瓶頸
在架構設計的時候一些做法能巧妙化解效能瓶頸。
化同步為非同步。
用記憶體佇列（redis），工作流引擎（jbpm）等實現。記憶體佇列容易丟失資料，但是速度快。工作流引擎會把請求儲存到資料庫中。
通過化同步請求為非同步請求，基本上99.99%的效能問題都可以解決。
用單機並行硬體處理。
比如使用gpu，fpga等硬體來處理，提高效能。
用集群計算機來處理。
比如使用hadoop集群，用多台計算機來並行處理資料。
在自己的軟體棧中，也可以把乙個模組部署多份，並行處理。
用cache來滿足請求。常用的內容加熱cache後，大量的使用者請求都只是記憶體讀取資料而已，效能會得到很大的提公升。
cache是上帝演算法，記得好像它的效能只比最佳效能低一些，就好像你是上帝，能夠預見未來一樣。
現在x86cpu遇到了主頻限制，cpu提公升效能的主要途徑就是增加高速cache了。
4.大系統小做
遇到大型系統不要慌，把它切分成多個模組，用多個小程式，通過soa協作來解決。這秉承了unix的設計思想。unix上開發了大量單一目的的小程式，它主張使用者通過管道來讓多個小程式協作，解決使用者的需求。當然，管道方式通訊限制太多，不夠靈活。因此，現在我們可以通過uri，即通過soa的方式來讓多個程式協作。andorid和ios上的應用程式，現在都是通過uri實現協作的。這也算是unix設計思想的現代發展吧？！
5.sharding（切片）
現在有乙個潮流，就是去ioe（i-ibm大型機，o-oracle資料庫和e-emc儲存）。之前的大型系統常用ioe架構，在大型機上部署乙個oracle資料庫，oracle資料庫用emc儲存儲存資料。ioe是當今最強的計算機，資料庫和儲存。但他們面對海量系統也有抗不住的一天。
oracle資料庫是shareeverything的，它可以在乙個計算機集群（伺服器節點不能超過16個）上執行。計算機集群都共用乙個儲存。去ioe運動，標誌著shareeverything模式的破產。必須使用sharenothing，系統才能無限擴充套件。而用mysql資料庫就可以應付任意規模的資料了。前提是，你會sharding分片。把大系統切分成若干個小系統，切分到若干臺廉價伺服器和儲存上。更modern一些，就是切分到大量虛擬機器上。
比如鐵道部的12306**。我們知道火車票都是從屬於某一列列車的。那麼我們把每乙個列車作為乙個單元來切分，就可以把12306**切分成幾千個模組。一台虛擬機器可以承載若干個模組。當某些列車成為效能瓶頸之後，就可以把它們遷移到獨立的虛擬機器上。即使最終有部分列出服務不可用，系統也不會完全不可用。
"你以為的歲月靜好，不過是有人替你遮風擋雨。"
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...
架構設計開篇 架構設計的目標與衡量
程式設計即設計，即架構。架構，這個詞比較神秘，以致於很多程式設計師望而卻步，以為要什麼了不得的本事。確實的，架構設計是一種高遠的目標，但千里之行，始於足下。架構的目標是什麼呢？實現所需服務 架構，致力於以更低成本 更高效率 更高質量地實現所需服務。架構，是兼顧質量 效率與成本的魔法。但架構並不研究如...