Scalability, Availability & Stability Patterns

https://blog.csdn.net/ajian005/article/details/6191814

 

 

一 自我有要求的讀者應該提出問題：（研習：掌握層次：）能力級別：不會（瞭解）——領會（理解）——熟練——精（why）——通（融匯貫通）

1.1 什麼是Scalability, Availability&Stability Patterns ？ 
1.2 以上各個模式都說了些什麼？
  1.2.1 Scalability Patterns 從State和Behavior都說了些什麼？ 是簡單介紹仍是有必定深度呢？
  1.2.2 Availability  Patterns 都說了些什麼？
  1.2.3 Stability Patterns ？都說了些什麼？
  該PPT只是比較全面、輕輕點水般介紹了一下當前架構思想，只能增長架構設計的視野，要想可以很好的使用這些思想，必須選一兩個感興趣有前景的點深刻下去才行。
1.3 （3）這本書說得有道理嗎？ 是所有有道理，仍是部分有道理？why?  
   做者最終的目標，加上他建議的達成目標的方法--這要看你認爲追求的是什麼，以及什麼纔是最好的追求方法而定。
  這些Pattern在什麼狀況下用？如何用? 能夠解決那些問題？而不解決那些問題？
1.4 （4）贊同一本實用性的書以後，確實須要你採起行動。 照着做者但願你作的方式來行動。How
  行動：爲達到某種目的而進行的活動。行動目標，行動方法，行動開始時間，結束時間，行動人，行動地點，行動方式。
  在架構設計時，考慮這些因素會提升系統Scalability，Availability&Stability等？

二 研讀過程當中應該努力尋找問題的答案，對問題的思考越深刻，收穫也就越多：

2.1 什麼是Scalability, Availability&Stability Patterns ？http://www.jdon.com/jivejdon/thread/38928
  2.1.1 Scalability(伸縮性、可擴展性):（研習:1 掌握層次：理解） Scale up/Scale out
    可伸縮性就是經過增長資源使服務容量產生線性（理想狀況下）增加的能力。可伸縮應用程序的主要特色是：附加負載只須要增長資源，而不須要對應用程序自己進行大量修改。
    在一些大的系統中，預測最終用戶的數量和行爲是很是困難的，伸縮性是指系統適應不斷增加的用戶數的能力。提升這種併發會話能力的一種最直觀的方式就增長資源（CPU，內存，硬盤等），集羣是解決這個問題的另外一種方式，它容許一組服務器組在一塊兒，像單個服務器同樣分擔處理一個繁重的任務。
    儘管原始性能對於肯定應用程序所能支持的用戶數很重要，但可伸縮性和性能是兩個單獨的實體。事實上，性能結果有時可能與可伸縮性結果是對立的。
      可伸縮性Scalable高性能系統設計：http://www.jdon.com/jivejdon/thread/40668
      可伸縮性最佳實戰: http://www.jdon.com/jivejdon/thread/37793
      CAP理論以及Eventually Consistent （最終一致性）解析:http://www.jdon.com/jivejdon/thread/37999
      BASE（Basically Availability、Soft state、Eventually consistent）
      你真的明白什麼是可伸縮性嗎？http://developer.51cto.com/art/200710/57496.htm
  2.1.2 Availability(可用性、有效性) （研習:1 掌握層次：理解）
    ISO9241/11中的定義是：一個產品能夠被特定的用戶在特定的上下文中，有效、高效而且滿意得達成特定目標的程度(The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.)。
    GB/T3187-97對可用性的定義：在要求的外部資源獲得保證的前提下，產品在規定的條件下和規定的時刻或時間區間內處於可執行規定功能狀態的能力。它是產品可靠性、維修性和維修保障性的綜合反映。
    實際比較經常使用Shakel（1991）對可用性的定義：可用性是指技術的「能力（按照人的功能特性），它很容易有效地被特定範圍的用戶使用，通過特定培訓和用戶支持，在特定的環境情景中，去完成特定範圍的任務。」
    單一服務器的解決方案並非一個健壯方式，由於容易出現單點失效。像銀行、帳單處理這樣一些關鍵的應用程序是不能容忍哪怕是幾分鐘的死機。它們須要這樣一些服務在任什麼時候間均可以訪問並在可預期的合理的時間週期內有響應。集羣方案經過在集羣中增長的冗餘的服務器，使得在其中一臺服務器失效後仍能提供服務，從而得到高的可用性。
       可用性：http://baike.baidu.com/view/1436.htm
  2.1.3 Stability（穩定性、穩定度） （研習:1 掌握層次：理解）
    軟件的穩定性，指軟件在持續操做時間內出錯的機率，例如一天時間內會出錯1次或幾回。具體來定義它是否屬不屬於穩定，根據軟件的具體要求來定義。
    軟件的穩定性應該和軟件的可靠性是不一樣的。軟件的穩定性從軟件開發的角度出發，強調軟件架構的穩定，也就是說需求、代碼等的變動對軟件系統的影響儘量地小，這也是架構設計要解決的首要任務。
    這須要做邊緣測試來檢驗，而邊緣測試的定義和實施都是須要不少經驗來支持的，這對於新手來講是沒法作到的。
    邊緣測試，舉個例子：在壓力測試中，能夠在壓力的最大值、最小值附近取值進行測試，甚至考慮超過最大值和最小值的方式進行測試。這就屬於邊緣測試。
    平均無端障時間等指標是說明系統的可靠性的。系統的穩定性應該是指系統的一些邊緣故障。好比系統運行一直很好，只是偶爾出現一些奇怪的問題，可是找不到緣由，通過重啓或者重裝以後就恢復正常，這就在考驗系統的穩定性。從系統自己來講，沒有平白無故的愛也沒有平白無故的恨，出現問題必定是在某個方面有缺陷，並且問題每每是出在設計上。若是要從設計角度去保障軟件的穩定性就須要設計人員充分的考慮系統各個模塊之間的關係，減小耦合度，是問題隔離起來。不少問題都是出在模塊之間的調用上的。模塊內部也是同樣，最大的問題就出在內存的使用上，不過這就到編碼的問題了。總之，穩定的系統須要專業的有豐富經驗的設計人員，合理的劃分系統，詳細設計作到足夠細，避免在開發階段出現問題。
       穩定性：http://baike.baidu.com/view/251942.htm
       什麼是軟件的穩定性：http://topic.csdn.net/t/20051220/22/4471364.html

2.2 以上各個模式都說了些什麼？
  2.2.1A Scalability Patterns 從State和方面都說了些什麼？ 是簡單介紹仍是有必定深度呢？
    2.2.1.1 Scalability解決什麼問題？Managing Overload （研習:1 掌握層次：理解）
    2.2.1.2 Scalability有哪兩種擴展方式？ Scale up vs Scale out （研習:1 掌握層次：理解）
    2.2.1.3 關於Scalability通常建議是什麼？ （研習:1 掌握層次：理解）
           *Immutability as the default：不變做爲一個缺省
           *Referential Transparency(FP) :參考透明性
           *Laziness: 懶惰
           *Think about your data:
              *Different data need different guarantees
    2.2.1.4 伸縮擴展系統時，有哪些因素中權衡？Scalability Trade-offs （研習:1 掌握層次：理解）
           沒有免費的午飯,擴展系統是有代價的。
       (1)Performance(單機)       vs  Scalability（多機）?
           How do I know if I have a performance problem? If your system is slow for a single user.
           How do I know if I have a scalability problem? If your system is fast for a single user but slow under heavy load
       (2)Latency(等待時間) vs  Throughtput(容量\吞吐率) ?
           You should strive(力求) for maximal throughput with acceptable latency(等待時間)
       (3)Availability  vs  Consistency ?
           Brewster's CAP theorem: CAP(Consistency\Availability\Partition tolerance) You can only pick 2
           *對於Centralized system 對CAP權衡的因素？
             In a centralized system(RDBMS etc.) we don't have network partitions, e.g. P no in CAP
              So you get both: Availability and Consistency  如ACID(Atomic\Consistent\Isolated\Durable)
           *對於Distributed system 對CAP權衡的因素？
            In a distributed syste we (will) have network partitions, e.g. P in CAP
            So you get to only pick one: Availability or Consistency
           *如何利用CAP理論指導實踐呢？
            there are only two types of systems:
              1. CA == CP (they are equivalent)
              2. AP
            there is only one choice to make. In case of a network partition, what do you sacrifice?
              1. C:Consistency
              2. A:Availabilty
              權衡的選擇：BASE(Basically Avaialable\Soft state\Eventually consistent)
              Eventual Consistency is an interesting trade-off
  2.2.1.5 Scalability Patterns:State都說了些什麼？State（持久化或內存中的數據）
    2.2.1.5.1 Partitioning:分區技術 （研習:1 掌握層次：理解）
    2.2.1.5.2 HTTP Caching （研習:1 掌握層次：理解）
          Reverse Proxy(反向代理:均可以作負載均衡器)軟件: F5/BigIp
             *Varnish:Varnish是一款高性能的開源HTTP加速器，http://www.oschina.net/p/varnish/ 挪威最大的在線報紙 Verdens Gang (http://www.vg.no) 使用3臺Varnish代替了原來的12臺squid，性能竟然比之前更好。
             *Squid:流行的自由軟件（GNU通用公共許可證）的代理服務器和Web緩存服務器。HTTP外，對於FTP與HTTPS的支援也至關好
             *rack-cache
             *Pound:Pound 是一個反向 HTTP 代理，負載均衡器和 SSL 封裝器。可代理客戶的的 HTTPS 請求到 HTTP 的後端服務器，並對這些請求進行分發，支持會話保持，支持 HTTP/1.1。
             *Nginx:Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 服務器，也是一個 IMAP/POP3/SMTP 代理服務器。
             Apache mod_proxy
          CDN(Content Delivery Network 內容分發網絡):使用戶可就近取得所需內容
          Generate Static Content:
            Precompute content:
             *Homegrown + cron or Quartz
             *Spring Batch：SpringBatch是一個批處理的框架，做爲一個 Spring 組件，提供了經過使用 Spring 的 依賴注入(dependency injection) 來處理批處理的條件。
             *Gearman：Gearman是一個分發任務的程序框架，能夠用在各類場合，與Hadoop相比，Gearman更偏向於任務分發功能。它的 任務分佈很是 簡單，簡單得能夠只須要用腳本便可完成。
             *Hadoop：分佈式計算
             *Google Data Protocol
             *Amazon Elastic MapReduce
    2.2.1.5.3 RDBMS Sharding （研習:1 掌握層次：理解）    (屬於SoR:Service of Record)：分片：水平擴展(Scale Out，亦或橫向擴展、向外擴展) Sharding：http://baike.baidu.com/view/3126360.htm
          How to scale out RDBMS?
         2.2.1.5.3.1 Partitioning:例子如:把User[A-C]放到DB1,把User[D-F]放到DB2...把User[X-Z]放到DBn
         2.2.1.5.3.2 Replication :把User[A-C]User[D-F]放到DB1,把User[D-F]User[A-C]放到DB2...把User[N1-N2]User[M1-M2]放到DBn
         2.2.1.5.3.3 anti-pattern(反模式):ORM+rich domain model ,Attempt: Read an object from DB, Result:You sit with your whole database in your lap
    2.2.1.5.4 NOSQL:Not Only SQL (屬於SoR:Service of Record) （研習:1 掌握層次：理解）
       2.2.1.5.4.1 Think about your data?
           When do you need ACID?
           When is Eventually Consistent a better fit?
           Different kinds of data has different needs
           When is a RMDBS not good enough? 
           Scaling reads to a RDBMS is hard!
           Scaling writes to a RDBMS is impossible
           Do we really need a RDBMS? But many times we don't.
           Who's ACID?
             Relational DBs(MySQL,Oracle, Postgres)\Object DBs(Gemstone, db4o)\Clustering products(Coherence, Terracotta)\Most caching products(ehcache)
           Who's BASE?
             Distributed databases: 
                *Cassandra：assandra是一個混合型的非關係的數據庫，相似於Google的BigTable。由Facebook開發，後轉變成了開源項目
                *Riak：Riak是由技術公司basho開發的一個類Dynamo的分佈式Key-Value系統。其以分佈式，水平擴展性，高容錯性等特色著稱。
                *Voldemort：Dynomite 是採用 ErLang 語言開發的分佈式的Key-Value存儲系統。
                *Dynomite：Dynomite 是採用 ErLang 語言開發的分佈式的Key-Value存儲系統。
                *SimpleDB：Amazon SimpleDB
           NOSQL in the wild:
                *Google:Bigtable\Amazon:Dynamo \ Amazon:SimpleDB\Yahoo:HBase\Microsoft:Dynomite\Facebook:Cassandra\LinkedIn:Voldemort
       2.2.1.5.4.2 Chord(和絃) & Pastry（糕點）：
             Distributed Hash Tables(DHT) \ Scalable\ Partitioned\ Fault-tolerant\ Decentralized\ Peer to Peer\ Popularized(Node ring/Consistent Hashing)
           Bigtable
             How can we build a DB on top of Google File System?
             Paper:Bigtable: A distributed storage system for structured data, 2006
             Rich data-model, structured storage
             Clones: HBase|Hypertable|Nepture
           Dynamo:
             Hoe can we build a distributed has table for the data center?
             Paper:Dynamo:Amazon's highly available key-value store, 2007
             Focus:partitioning,replication and availability
             Eventually Consistent
             Clones:Voldemort|Dynomite
       2.2.1.5.4.3 Types of NOSQL stores
             Key-Value databases(Voldemort,Dynomite)
             Column databases(Cassandra,Vertica)
             Document databases(MongoDB,CouchDB)
             Graph databases(Neo4J,AllegroGraph)
             Datastructure databases(Redis,Hazelcast)
      2.2.1.5.5 Distributed Caching （研習:1 掌握層次：理解）
           2.2.1.5.5.1 Write-through
           2.2.1.5.5.2 Write-behind
           2.2.1.5.5.3 Eviction Policies
              TTL(time to live)
              Bounded FIFO(first in first out)
              Bounded LIFO(last  in first out)
              Explicit cache invalidation
           2.2.1.5.5.4 Replication
           2.2.1.5.5.5 Peer-To-Peer(P2P)
              Decentralized:分散
              No"special" or "blessed" nodes
              Nodes can join and leave as they please
           2.2.1.5.5.6 Distributed Caching Products:
              EHCache
              JBoss Cache
              OSCache
              memcached: Simple\Key-Value(string->binary)\Clients for most languages\Distributed\Not replicated - so I/N chance for local access in cluster
           2.2.1.5.6 Data Grids/Custering:數據網格  Parallel data storage （研習:1 掌握層次：瞭解）
              Data replication
              Data partitioning
              Continuous availability
              Data invalidation
              Fail-over
              C+A in CAP
           Data Grids/Custering Products:
              Coherence/Terracotta/GigaSpaces/GemStone/Hazelcast/Infinispan
     2.2.1.5.7 Concurrency:併發
         2.2.1.5.7.1 Shared-State Concurrency （研習:1 掌握層次：理解）
            Every one can access anything anytime
            Totally indeterministic
            Introduce determinism at well-defined places...
            ... using locks
          Problems with locks:
            Locks do not compose
            Taking too few   locks
            Taking too many  locks
            Taking the wrong locks
            Taking locks in the wrong order
            Error recovery is hard
          Please use java.util.concurrent.*:
            ConcurrentHashMap/BlockingQueue/concurrentQueue/ExecutorService/ReentrantReadWriteLock/ParallelArray/and much much more..
         2.2.1.5.7.2 Message-Passing Concurrency （研習:1 掌握層次：理解）
          *Actors: erlang萬物皆Actor, Actor之間只有發送消息這一種通訊方式
             Implemented in Erlang, Occam,Oz
             Encapsulates state and behavior
             Closer to the definition of OO than classes
             Share NOTHING
             Isolated lightweight processes
             Communicates through messages
             Asynchronous and non-blocking
             No shared state   ... hence, nothing to synchronize.
             Each actor has a mailbox(message queue)
             Easier to reson about
             Raised abstraction level
             Easier to avoid  -Race conditions -Deadlocks -Starvation -Live locks
          *Actor libs for the JVM:
             Akka(Java/Scala)/scalaz actors(Scala)/Lift Actors(Scala)/Scala Actors(Scala)/Kilim(Java)/Jetlang(Java)/Actors'Guild(Java)/Actorom(Java)/FunctionalJava(Java)/GPars(Groovy)
         2.2.1.5.7.3 Dataflow Concurrency （研習:1 掌握層次：瞭解）
             Declarative  
             No observable non-determinism
             Data-driven - thread block until data is available
             On-demand, lazy
             No difference between:
                 Concurrent&Sequential code
             Limitations: can't have side-effects
         2.2.1.5.7.4 Software Transactional Memory （研習:1 掌握層次：瞭解）
             See the memory(head and stack )as a transactional dataset
             Similar to a database: begin commit  abort/rollback
             Transactions are retired automatically upon collision
             Rolls back the memory on abort
             Transactions can nest
             Transactions compose
         Transactions restrictions: All operations in scope of a transaction: Need to be idempotent
         STM libs for the JVM:
             Akka(Java/Scala)
             Multiverse(Java)
             Clojure STM(Clojure)
             CCSTM(Scale)
             Deuce STM(Java)

   2.2.1B Scalability Patterns:Behavior(行爲、性能)都說了些什麼？
        1.2.1B.1 Event-Driven Architecture （研習:1 掌握層次：瞭解）
            1.2.1.6.1 Domain Events
            1.2.1.6.2 Event Sourcing
            1.2.1.6.3 Command and Query Responsibility Segregation(CQRS) pattern 
                    in a nutshell
            1.2.1.6.4 Event Stream Processing
            1.2.1.6.5 Messaging
                 Publish-Subscribe
         Point-to-Point
         Store-forward
         Request-Reply
               Standards: AMQP(即Advanced Message Queuing Protocol，高級消息隊列協議) 和JMS（Java Messaging Service）
               Products: RabbitMQ(AMQP)/ActiveMQ(JMS)/Tibco/MQSeries/etc
            1.2.1.6.6 Enterprise Service Bus
               products: ServiceMix(Open Source)|Mule(Open Source)|Open ESB(Open Source)|Sonic ESB|WebSphere ESB|Oracle ESB|Tibco|BizTalk Server
            1.2.1.6.7 Actors
               Fire-forget:Async send
           Fire-And-Receive-Eventually:Async send + wait on Future for reply
            1.2.1.6.8 Enterprise Integration Architecture(EIA)
               參考書《Enterprise Integration Patterns》
               Apache Camel: More than 80 endpoints/XML(Spring) DSL/Scala DSL
        1.2.1.6.2 Compute Grids（研習:1 掌握層次：瞭解）
           Parallel execution:並行執行
                 Automatic provisioning
             Load balancing
             Fail-over
             Topology(拓撲) resolution
           Products：
         Platform/DataSynapse/Google MapReduce/Hadoop/GigaSpeaces/GridGain
        1.2.1.6.3 Load-balancing（研習:1 掌握層次：理解）
               Random allocation 隨機分配算法
               Round robin allocation 循環分配算法
           Weighted allocation 負載分配算法
           Dynamic load balancing:
                  Least connections :鏈接數最少
              Least server CPU  :CPU服務最少
                  etc.
               DNS Round Robin(simplest) : Ask DNS for IP for host/Get a new IP every time
               Reverse Proxy(better)
           Hardware Load Balancing
            Load balancing products:
               Reverse Proxies: Apache mod_proxy(OSS)|HAProxy(OSS)|Squid(OSS)|Nginx(OSS)|VLS
           Hardware Load Balancers: BIG-IP|Cisco
        1.2.1.6.4 Parallel Computing（研習:1 掌握層次：瞭解）
            SPMD Pattern:
        Single Program Multiple Data
            Very generic pattern, used in many other patterns
        Use a single program for all the UEs
            Use the UE's ID to select different pathways through the program. F.e:
           Branching on ID
               Use ID in loop index to split loops
            Keep interactions between UEs explicit
        Master/Worker Pattern
            Good scalability
            Automatic load-balancing
            How to detect termination? Bag of tasks is empty/ Poison pill
            If we bottleneck on single queue? Use multiple work queues/ Work stealing
        What about fault tolerance? Use"in-progress" queue
        Loop Parallelism Pattern
        Fork/Join Pattern
        MapReduce Pattern
            UE:Unit of Execution: Process/Thread/Coroutine/Actor

 2.2.2 Availability  Patterns 都說了些什麼？
      What do we mean with Availability ?
    2.2.2.1 Fail-over:故障切換 （研習:1 掌握層次：理解）
            simple  Fail-over
            complex Fail-over
            Network fail-over

         

Fail-Fast

維基百科地址：http://en.wikipedia.org/wiki/Fail-fast

Fail-fast is a property of a system or module with respect to its response to failures. A fail-fast system is designed to immediately report at its interface anyfailure or condition that is likely to lead to failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. Such designs often check the system's state at several points in an operation, so any failures can be detected early. A fail-fast module passes the responsibility for handling errors, but not detecting them, to the next-higher system design level.

從字面含義看就是「快速失敗」，讓可能的錯誤儘早的被發現，對應的方式是「fault-tolerant（錯誤容忍）」。以JAVA集合（Collection）的快速失敗爲例，當多個線程對同一個集合的內容進行操做時，就可能會產生fail-fast事件。例如：當某一個線程A經過iterator去遍歷某集合的過程當中，若該集合的內容被其餘線程所改變了；那麼線程A訪問集合時，就會拋出ConcurrentModificationException異常，產生fail-fast事件。

 

Fail-Over

維基百科地址：http://en.wikipedia.org/wiki/Failover

In computing, failover is switching to a redundant or standby computer server, system, hardware component or network upon the failure or abnormal termination of the previously active application,  server, system, hardware component, or network. Failover and switchover are essentially the same operation, except that failover is automatic and usually operates without warning, while switchover requires human intervention.

Fail-Over的含義爲「失效轉移」，是一種備份操做模式，當主要組件異常時，其功能轉移到備份組件。其要點在於有主有備，且主故障時備可啓用，並設置爲主。如Mysql的雙Master模式，當正在使用的Master出現故障時，能夠拿備Master作主使用。

 

Fail-Safe

維基百科地址：http://en.wikipedia.org/wiki/Fail-safe

A fail-safe or fail-secure device is one that, in the event of failure, responds in a way that will cause no harm, or at least a minimum of harm, to other devices or danger to personnel.

Fail-Safe的含義爲「失效安全」，即便在故障的狀況下也不會形成傷害或者儘可能減小傷害。維基百科上一個形象的例子是紅綠燈的「衝突監測模塊」當監測到錯誤或者衝突的信號時會將十字路口的紅綠燈變爲閃爍錯誤模式，而不是所有顯示爲綠燈。

另外就是咱們誤用的「自動功能降級」翻譯作「Auto-Degrade」會更好一些。

 

     2.2.2.2 Replication （研習:1 掌握層次：理解）
        *Active  replication - Push
        *Passive replication - Pull
           * Data not available, read from peer, then store it locally
             Works well with timeout-based caches
          Master-Slave
          Tree replication
          Master-Master
          Buddy(夥伴) Replication

  2.2.3 Stability Patterns ？都說了些什麼？ （研習:1 掌握層次：瞭解）
      2.2.3.1 Timeouts:Always use timeouts (if possible):
      2.2.3.2 Circuit Breaker:斷路開關,斷路器
      2.2.3.3 Let-it-crash
      2.2.3.4 Fail fast
      2.2.3.5 Bulkheads
      2.2.3.6 Steady State
      2.2.3.7 Throttling

  2.2.4 Extra material(Client-side consistency|Server-side consistency) （研習:1 掌握層次：理解）
     Client-side consistency
     Server-side consistency

3、（3）這本書說得有道理嗎？ 是所有有道理，仍是部分有道理？why?  

   在你不能回答上面兩個問題時，沒法回答這個問題的
   做者最終的目標，加上他建議的達成目標的方法--這要看你認爲追求的是什麼，以及什麼纔是最好的追求方法而定。
   這些Pattern在什麼狀況下用？如何用? 能夠解決那些問題？而不解決那些問題？
   
   3.1.1 做者最終的目標：讓軟件架構師及產品經理們，瞭解當前主流架構模式。
   3.1.2 他建議的達成目標的方法？ 先了解基本軟件架構特性如：Scalability\Avaiability\Stability Pattern, 
         其次介紹各個Pattern具體技術思想，便於本身在設計軟件時思考借鑑，
         再其次，介紹各個Pattern具體技術產品（開源），便於在設計軟件時作參考等。
   3.1.3 這些Pattern在什麼狀況下用？在軟件開發週期：設計階段（尤爲架構設計，粗粒度技術選型時）
   3.1.4 如何用? 這個文檔指示給你一個引子，後續如何使用，須要研究具體的技術產品（通常產品都有：deom\reference\api help 等）
   3.1.5 能夠解決那些問題？而不解決那些問題？ 能夠幫助架構設計技術選型等，幫助提升找到知足設計目標的方法程度。
         不解決那些問題: 具體如何設計、如何技術選型、如何研習選型產品、編碼。。。。

4、（4）贊同一本實用性的書以後，確實須要你採起行動。 照着做者但願你作的方式來行動。How

  行動：爲達到某種目的而進行的活動。行動目標，行動方法，行動開始時間，結束時間，行動人，行動地點，行動方式。
  在架構設計時，考慮這些因素會提升系統Scalability，Availability&Stability等？
   4.1 我看這個技術資料的目的：
       1 在關於當前主流架構設計討論中，能清楚知作別人說的概念，可以討論一些相關技術，提升本身設計水平
       2 在本身產品設計中如何應用這些思想，幫助設計出更好的產品
   4.2 我應該採起什麼實際行動：
       1. 技術交流要可以說相關知識點，及why
       2. 大型分佈式架構設計、網管架構設計、中心架構設計、。。。可以用上這些Pattern思想提升設計水平

 

Jdom對這個主題描述

在這個PPT中，你會發現大量詞語在本站討論過：
分佈式緩存；數據網格計算；NoSQL;RDBMS；Http緩存如CDN 反向代理；CAP理論，併發模式（消息傳遞模式 軟事務內存 數據流併發 狀態共享併發）；分區；複製。EDA事件驅動架構；負載平衡；並行計算(MapReduce模式 Fork/Join模式)。

因爲可貴一見的全面，須要反覆多看幾回，理清頭緒。我下面就逐步詮釋一下：

（1）Scalability可伸縮性，可伸縮性扣住「狀態」這個關鍵詞，2006年我就寫了一篇狀態對象：數據庫的替代者，應該說當時已經隱約感受到了狀態這根主線，現在在這個PPT獲得全面詮釋，很是釋然。狀態又分爲：
分區 Http緩存 RDBMS Sharding碎片 NoSQL 分佈式緩存，數據網格，併發Concurrency.

PPT指出可 伸縮性是沒有免費午飯，須要在如下因素權衡：
性能和可 伸縮性
什麼是性能問題？若是你的系統對於一個用戶訪問還很慢，那就是性能問題；
什麼是可 伸縮性問題？若是你的系統對一個用戶來講是快的，可是在高訪問量下就慢了。

延遲和吞吐量
你要爲以下目標奮鬥：用可接受的延遲得到最大的吞吐量。

可用性和一致性
就是CAP原理，傳統的集中式關係數據庫只能得到CA。大量章節談了 NoSQL，本站已經相關介紹，基本都已經涵括。

狀態
在狀態方面，首先談的是Http緩存，反向代理：Varnish squid Nginx mode_proyx這些都很熱門，經過CDN在離客戶端最近佈置狀態服務器。

頁面靜態化主要概括爲Precompute content方面，不少人喜歡將動態頁面靜態化，變成html，經過引入AJAX異步，也是一種可 伸縮性提升手段，靜態化實時性差，適合能夠預先計算的頁面，預先計算能夠採起：樸素的crontab 或Java的Quartz框架，Gearman，hadoop雲計算已經google的數據協議，亞馬遜的Elastic MapReduce。經過設置http協議，使用客戶端瀏覽器本地 緩存，加長http中失效期限，這些在國內被概括爲SEO範疇，也是可 伸縮性一個小章節。


（2）可用性這裏意思應該是咱們一般的可靠性概念，可用性包括複製Replication和失敗恢復failover（過去稱爲 集羣）。

何爲可用性？是99.999%在線運行。7x24全天候運行。PPT講了failover的複雜性已經fail back。

Replication複製性分Active複製（推）和Passive複製（拉），形式上分主從 雙主 Tree和Buddy夥伴四種，這些技術是MySQL Oracle以及追求CP類 NoSQL數據庫採起的同步策略。
主從Master-slave：主用來讀寫，可多個slave用來讀；雙主則是兩個都用來讀寫；夥伴複製採起一對一結伴，相似Weblogic的 集羣策略。


(3)穩定性包括let it crash (Akaa框架) SEDA Throttling.

其餘
PPT將傳統關係數據庫和 NoSQL概括爲Service of Record SOR模式，講了水平垂直伸縮，RDBMS的Sharding碎片技術包括分區和複製。

文章認爲：ORM +富模型Rich domain model是一種反模式，會致使你就把精力浪費在照料數據庫上。
避免方式是：從新思考你的數據，何時你須要ACID，何時能夠從最終一致性中得到好處？不一樣種類數據有不一樣的需求。見本站過去討論： ORM已是過去的事情

文章認爲除了關係數據庫之外，對象數據庫如db4o 以及 集羣，如Terracotta兵馬俑 ehcach都屬於ACID。

在 緩存概念中，解釋了什麼是write-through，什麼是write-behind，什麼是 緩存的Eviction驅逐策略 好比先進先出FIFO；

在message-passing模式中，提到了Erlang Scala的Actors模型，最先提出由1973的Carl Hewitt，他比傳統的類Class概念更加符合 OO。

Actors模式特色：share nothing；隔離輕量處理，經過消息通信；異步且非堵塞，由於不共享就不用同步。每一個Actor有一個郵箱。

在Dataflow併發中提到，數據是On-demand, lazy裝載懶加載數據(jdonframeowork經過domain events實現數據隨用隨取，見其 PPT說明)

該PPT將domain events明確爲EDA架構，固然還有咱們討論的CQRS。並對Event Sourcing事件源進行了說明，若是有事件記錄，就無需ORM，只要持久化事件就能夠。

總之，該PPT是對近期熱點模式進行總結。值得推薦一看。

 

可伸縮性, 可用性和穩定性模式

http://www.jdon.com/jivejdon/thread/38928
http://www.jdon.com/jivejdon/thread/38928
http://www.slideshare.net/jboner/scalability-availability-stability-patterns

介紹架構比較不錯鏈接：