之前只要一提起架構，給我一種很深奧、玄妙的感覺，認為很牛X，曾幾何，以為軟件架構無非就是將幾大框架(各層次)整合在一起而已，后來當我從事系分一段時間之后，體會到如果你不能從整體上認識一個系統(軟件)的話是沒法做架構的，因為滿足系統(軟件)的功能是一個架構師最起碼的要求。從這個層面上講，那系統分析師與系統架構師一樣都要對系統有一個整體的認識，更要認識到該系統在未來可能的變化及做成產品后如何時維護的問題。感覺系統分析師與系統架構師好像沒什么區別似的，雖說早就知道一個偏重業務一個偏重技術。
但自我開始閱讀“架構之美”這本書后，開始對架構有了進一步的認識：
本質上，架構只是系統設計中的一部分，無非架構更突出某些細節，并通過抽象省略另一些細節。關注實現系統組件的開發者可能不會特別關心所有組件是如何裝配在一起，而是主要關注少數組件的設計和開發，包括他們必須遵守的架構約束和可以應用的規則。因此，開發者和架構師面對的是系統設計的不同方面。如果說架構關注的是組件之間的關系和系統組件外部可見的屬性，那么設計還要關注這些組件的內部結構。
 架構這個詞本質上是從建筑學這個行業引申過來的，所以在軟件開發這個領域好多概念跟現在的建筑都相似。
項目關注點：
功能性、
可變性、
容量、
生態系統、
模塊化、
可構建性、
產品化、
安全性
架構還會影響到組織機構。
架構觀點中的常見思想是結構，每種結構都由各種類型的組件及其關系構成：它們如何組合、相互調用、通信、同步，以及進行其他交互。組件可以是建筑中的支架棟梁或故事中的章節或人物。每種結構都是為了幫助架構師理解如何來滿足特定的關注點，如可變性或性能。展示某些關注點得到滿足時，可能會影響到其他方面的關注點，但架構師必須能夠說明所有關注點都已得到滿足。
架構師的角色：就是做設計上的決定包括行為上和結構上。
信息隱藏結構是面向對象設計方法的基礎，它滿足的關注點：信息隱藏結構的設計應該能滿足可變性、模塊化和可構建性的要求。
定義良好的使用結構將創建系統的適當子集，可以用于驅動迭代式或增量式的開發循環，滿足的關注點：產品化和生態系統。
信息隱藏模塊結構和使用結構是靜態的結構，存在于設計時和編碼時，進程結構是運行時的結構。
進程結構滿足的關注點：性能和容量。
一：伸縮性架構設計
胖客戶端與廋客戶端
在線游戲環境與企業環境幾乎完全相反，
經典的企業環境可以描述為一個“瘦”客戶端連接一個“胖”服務器（這個服務器又常常連接到一個更“胖”的數據庫服務器）。服務器將保存客戶端需要的絕大部分信息，在最理想的情況下，客戶端內在不多，沒有自已的硬盤，它是服務器的一個稱職的顯示設備，絕大多數據真正的工作在服務器上完成。
游戲世界特別是大型多人在線游戲（MMO）
MMO和虛擬世界的環境始于一個非常胖的客戶端：
它通常是頂級的PC、具有最強勁的CPU、很大的內存，以及本身計算能力很強的顯卡。只要有可能，數據就會存放在這些客戶端上，特別是那些不會改變的信息，如地理信息、材質貼圖和規則集。服務器保持盡可能的簡單，通常只保存非常抽象的世界表示和其世界中的實體的表示。而且服務器的設計目標是盡可能少地進行計算。絕大部分的計算留給了客戶端。服務器的真正工作是保存共享的世界真實狀態，確保不同客戶端對世界的看法差異可以根據需要得到糾正。真實狀態需要由服務器來保存，因為控制客戶端的玩家很有興趣讓他們的表現變成最強，所以可能會受到誘惑，根據他們的喜好修改共享的真實（如查他們可以）。在一般情況下，如果有可能，玩家就會作弊，所以服務器必須是共享真實的最終來源。
MMO和虛擬世界的數據訪問模式也和企業中看到的情有著很大的區別。企業中的一般經驗法則是90%的數據訪問都是只讀的，大多數任務會讀取大量數據，然后會再改寫少量數據。在MMO和虛擬世界的環境中，大多數任務只訪問服務器上少量的狀態數據，但在它們訪問的數據中，大約一半會被改寫
在線游戲環境與企業環境的共同關注點：
1，延遲是敵人，但也有不同。最大的不同要追溯到用戶所做的事情的不同。在企業環境中，目標是管理業務，如果總吞吐量得到改進，在處理中有一點延遲是可以接受的，在MMO和虛擬世界的環境中，目標是開心，而延遲是開心的敵人，所以MMO或虛擬世界的基礎設施需要圍繞著盡可能限定延遲的需求來設計即便以吞吐量為代價也在所不惜。
XX在線游戲（Darkstar）架構的目標：
1，對伸縮性的需求表明，系統應該是分布式的、并發的，游戲程序員應該把系統視為一臺單機，運行著一個線程，所有允許部署到多線程和多
計算機上的機制都應由XX在線游戲的基礎設施來考慮。
2，支持隨時伸縮，同時不要求游戲邏輯受到伸縮的影響，這個架構應該支持游戲動態地響應負載，而不是讓這種響應成為游戲設計的工作的一部分。
架構：
Darkstar由一組獨立的服務構成，用一組相互聯系的服務來構建系統，“分而治之”，分而治之是設計所有大型計算機系統的基本方法。
客戶端連接到游戲邏輯使用的通信機制是基礎設施的一部分，這些機制支持客戶端到服務器的直接通信，也支持一種“發布-訂閱”通道，任何發往通道的消息都會送達該通道的所有訂閱者。
游戲服務器的設計方式和游戲為為支持并玩家所采取的伸縮性技術。
并行與延遲

二：數據增長——Facebook平臺的架構

這兩天學習REST及其java實現框架Restlet.
 

Overview of a Restlet architecture

Here is a diagram illustrating how the API composes components, connectors, virtual host and applications. Applications are in turncomposed of resources.

用白說來講就是：Application通過Router 將某個URI與Resource綁定在一定，而一個componet可能含有多個Application,
還有Representation 這個類其實也很重要。Representation entity：Restlet中全部的接受和返回對象都Representation類的子類。 
如在WEB APP中經常需要從一個FORM中拿到其Representation(getWebRepresentation() )或組裝成一個Representation 
Form(Representation webForm) ,以便客戶端與服務器進行交互。我們知道REST是以資源為中心的，一個URI就代表了對這個資源的CURD操作。@Path這個注解提明了
哪個操作是由該資源的那個方法來實現的如:
@POST
@Path("add")
public String addStudent(Representation entity) { 
}
...
@DELETE
@Path("delete/{id}")
public String deleteStudent(@PathParam("id") int id) {
  int status = ResourceHelper.deleteStudent(id);
  return String.valueOf(status);
} 
representation package overriew:
Restlet 對表現層的技術支持也就是通來representation這個類來實現的，representation 
  Restlet并沒有你Setvlet API那樣有自已的JSP作表現的技術，它是通過將這三種模板技術整合起來而已如 : XSLT, FreeMarker and Apache Velocity 
The org.restlet.representation package contains common representation data elements. Here is a hierarchy diagram with the core Representation classes:

Overview  Representation package

當然restlve只是提供了一個入口，碰到要對數據庫進行CURD操作時，基具體實現還是由JDBC等技術來實現.