最近看了一些架構方面的帖子，包括京東的、支付寶的，加上之前各種微服務，大平台，彈性化等各種架構詞彙，在大腦裡相互衝撞，一時間感覺不知所云，思維被各種概念牽引著，有點慌亂。當然這不是我想要的狀態，於是運用曾文正公的處世之道：「立足當下，化繁為簡」。回到架構的三個哲學問題：1.何為架構？2.它從**來？3.它要到**去？回答了這三個問題，就應該能抓住架構的本質，不至於人云亦云。當然，這只是一家之言，如果說錯了，希望能指正我。
何為架構：與我而言，所謂架構其實是事物與事物之間恰當的關係。這個概念比較大， 我們不妨縮小一點範圍就focus在it架構領域。我們知道，togaf將架構分為業務架構、資料架構、應用架構、技術架構，這四個架構定義從不同的層面和維度解釋了要實現上層企業架構應該具備的架構能力，這裡的業務架構是從業務的維度講業務流程、企業組織以及組織下的人員之間的關係；資料架構是從資料維度講企業的資料資產及資訊間的結構關係；應用架構是從應用系統的維度講應用系統相互間如何協作以提供服務從而滿足業務流程的系統化(也是講系統間的關係)；技術架構是從軟硬體基礎設施維度講它們之間如何組合以提供基本的運算、儲存、網路能力。
它從**來：從架構的本質可以看到，在不同的維度架構需要提供不同的能力和關係，那是不是可以試著從這個角度看架構的發展過程呢？順便也驗證一下我們對架構的本質是否認知準確。我們知道，系統架構過程大致可以分為三個階段:
它要到**去：回答這個問題其實就是回答架構的下一階段，我不是預言家，只是沿著我個人理解的架構發展路線來估測一下。從上面分析的架構路線來看，我們已經通過引入額外的標準規範一定程度上緩解了能力關係的複雜性，只不過這種引入帶來了一定程度上大平台自身的能力挑戰，因此我們可以預見，當需要大平台提供更加強的能力以滿足更複雜關係的管理時，是不是在某一時點上平台自身的能力關係也變得不可控呢？就像馬路上的紅綠燈，想象一下當紅綠燈出現故障時，路況是不是會更加崩潰呢？
所以我們回過頭來，還是從it系統的起源來看，系統是服務於業務的，這一點毋庸置疑，因此架構的發展趨勢一定也是讓業務實現更自由，這種自由其實就是要有載體來負責管理這些關係性，而上面的分析我們發現通過引入外部的能力並非長久之計，那麼很自然我們會想到最終的伺服器會是這些載體，即將所有與技術相關的成本如協議、排程、服務、
通訊、監控、快取、服務排程等關係都最終龜縮成伺服器硬體的基本功能，就像cpu、網路、儲存能力一樣，這種龜縮不一定完全有硬體伺服器廠商來做，可以在驅動層、作業系統層、甚至在作業系統上再抽象出一層，通過這種內建的固化能力關係管理，使得各個維度上的能力真正做到可以按需使用，動態擴充套件。
也許，架構的未來是沒有架構！
來自dimmacro為知筆記(wiz)
悠然亂彈 我的架構觀
既然是亂彈，當然就不能全用正理推斷，因此文中有文不對題的，思維混亂的都屬正常範疇，大家諒解則個。架構，是乙個神秘也是乙個普通的詞彙。曾幾何時，君不見現在架構師就像雨後春筍似的，忽如一夜春風來，千樹萬樹上面結的都是架構師，不管是招聘的，不管是應聘的，動輒就是資深架構師，高階架構師云云。有的人說，架構是...
從軟體的架構觀談起
概述 這一年來讀了讀有關國外大牛和先輩相關的書,最近自己也在做專案架構.見一些同行的言論,有些感觸 有贊同的地方也有不贊同的地方,這裡談談自己的架構觀.1.架構不是為了玩技術 很多人在玩技術技巧,但架構這東西非作秀,然而一些人在這麼幹,架構的審核標準第一條 便捷 易維護 適合於需求不斷調整業務場景....
大資料架構的未來
本文講述了大資料的相關問題，以及 大資料架構 得名的由來。大資料的問題 或許所有讀者都明白這一點 資料正在飛速增長。若是能夠有效利用的話，我們能從這些資料中找到非常有價值的見解 傳統技術有很多都是在40年前設計的，比如rdbmss，不足以創造 大資料 炒作所宣稱的商業價值。在大資料技術的使用上，常見...