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

介绍架构比较不错链接：