Java程序员进阶—分布式系统架构

分布式系统

　　分布式系统从当初的CORBA 到EJB，Web和SOA，从集群到如今的NoSQL 云计算和大数据Hadoop等分布式系统，横向水平扩展Scala out/in是分布式系统设计的一个特色，可靠性 容错性是两个质量指标。

什么是分布式系统？

　　一大批服务器组成一个集合，对于用户来讲仍然是一个总体连贯系统。

　　A. Tanenbaum定义：分布式网络的计算机中的组件之间协调动做是经过消息进行通信。

　　G. Coulouris定义：当你知道有一台电脑崩溃，可是你的软件运行历来不会中止。

　　Leslie Lamport定义：分布式系统是这样系统：旨在支持应用程序和服务的开发，能够利用物理架构 由多个自治的处理元素，不共享主内存，但经过网络发送异步消息合做。

　　与分层应用区别：分层的应用程序（例如，3层）是 划分应用程序逻辑，是一种逻辑分层，而不是物理，而分布式系统DS是物理分层，和实际部署有关。

与传统集中式系统相比：

　　集中式系统是一种Scale out/in，纵向扩展，要么向上升级服务器到中大型机，要么升级多核，增长CPU核数，集中式纵向扩展适合计算聚合度比较高的数据，而分布式适合计算松散数据，非结构化或半结构化数据。不管采起哪一种扩展伸缩方案，须要根据业务数据特色而定。

　　任何分布式系统老是须要完成两个任务：计算和存储。计算和存储分离是分布式系统的重要特征。而一般在集中式或单机系统中，这二者是可能结合在一块儿，好比经过一个SQL语句实现查询后排序，查询是从存储中得到数据，排序是属于计算，所以这个SQL语句实际是将计算和存储耦合在一块儿。在应对大数据或大并发的状况下，这种方便的捆绑带来性能问题，而分布式计算和分布式存储虽然带来复杂性，可是也为系统的处理能力打开了上升拓展的空间。

分布式系统特色：

1. 并发性：共享资源，采起ACID或Base原则，见：CAP定理。
   分布式系统设计遵循CAP定理， CAP是：Consistency(一致性), Availability(可用性), 和 Partition tolerance(分区容错性) 可靠性 简称，CAP定理认为，CAP三种之中，只能同时知足其中两种。
   
   
2. 可扩展性Scalable是重要特色，经过扩展可以得到高性能 高吞吐量 低延迟Latency。
   
   
3. 可靠性/可用性:故障发现和处理以及恢复 容错处理。在一个正常运做系统中存在一个时间比例的条件。 若是一个用户不能访问系统比例增大，它被认为是不可用。可用性公式：
   Availability = uptime / (uptime + downtime)
   容错failover是指一个系统在错误发生的状况下，仍然一切运行正常。表示这个系统是宽容错误的。
   
4. 消息处理: 具体产品有：RabbitMQ ZeroMQ Netty等等。
   
5. 异构性： 不一样操做系统 硬件 程序语言 开发者，中间件是一种解决方案。
   
6. .安全性：受权认证 SSO单点登陆 Oauth等等。
   
7. 定位命令：
   标识资源 URLs
   命名服务Naming services
   定位寻找Lookup
   主要见SOA中的服务查找。如Zookeeper实现服务查找。
   
8. .透明性：
   访问透明度： 使用相同的操做本地和远程资源
   位置透明：访问资源无需知道其物理或网络位置
   并发透明度：多个流程能够同时运行访问使用共享资源，当不能干扰堵塞 它们的处理流程
   复制透明性： 资源的多个实例能够被用来复制以提升可靠性和性能，但无需由用户编制专门的应用程序来实现。
   故障透明度：出现软件硬件故障时，使用户和应用方案能继续完成他们的任务不受影响。
   移动透明度：容许在 系统存在移动的资源和客户。
   性能透明度：容许系统从新配置以 提升性能负荷变化
   缩放透明度：在应用程序结构没有变化的状况下可以在规模上扩展或伸缩系统，以提升吞吐量处理能力。　　

分布式系统的挑战

　　分布式系统是难于理解、设计、构建 和管理的，他们将比单个机器成倍还要多的变量引入到设计中，使应用程序的根源问题更难发现。SLA(服务水平协议)是衡量停机和/或性能降低的标准，大多数现代应用程序有一个指望的弹性SLA水平，一般按"9"的数量增长(如,每个月99.9或99.99%可用性)。每一个额外的9变得愈来愈难实现。

　　让事情更加复杂的是，咱们愈来愈常见地看到：分布式系统的故障表现为间歇性错误或性能降低(俗称的限电)。这些失败模式耗费更多时间来诊断。例如，Joyent经营一些分布式系统做为其云计算基础设施的一部分。在这样一个系统中，包括高可用性、分布式的键/值存储，Joyent最近经历了瞬态应用程序超时。对于大多数用户系统运行正常，其反应延迟也是在SLA范围内。然而，有百分之5 - 10的请求超出了一个预约义的程序超时。这样的失败问题并无重如今开发或测试环境中，他们常常会"消失"几分钟到几小时。排除这个故障的根本是须要大量数据存储的系统分析。

　　这些系统包括：数据存储API(node . js)，RDBMS(关系数据库管理系统)和由系统内部使用(PostgreSQL)以及操做系统和终端用户应用程序依赖于的键/值系统。最终，致使过分的根本问题是在应用程序语义锁定，但肯定以前须要至关大的数据收集和相关性工做，包括工程师耗费大量工做时间以及学习不一样领域的专业知识。

　　分布式系统由两个物理因素的限制：

• 节点的数量（可以增长所需的存储和计算能力）
• 节点之间的距离（信息的传送距离，最好以光速）

　　这两个约束致使下面值得挑战的状况发生：

• 独立节点随着数目的增长发生故障的几率增长（减小可用的和管理成本增长）
• 独立节点随着数目增长可能会增长节点之间的通讯的消耗（随着规模的增大性能下降）
• 地理距离的增长提升遥远的节点之间的通讯延迟（减小某些操做的性能）

如何架构分布式系统

　　适用于分布式系统架构的最多见的一个术语是SOA(面向服务架构)。SOA能够避免不愉快的CORBA(公共对象请求代理体系结构)，经过WS - *标准，一套松散耦合的Web服务完成独立的小功能，而且彼此独立，他们是一个有弹性的分布式系统的基础。对比上一代，服务是新流程，他们是正确的抽象层次系统中的离散功能。

　　构建面向服务架构的第一步是肯定每一个函数功能如何构成总体业务目标，将这些业务映射到离散的服务，且具备独立的断层边界、扩展性和数据负载量。肯定为每一个服务时，您必须考虑下列事项：

• 地理. 系统是全球仍是地区单独运行？
• 数据隔离. 这个系统提供一个单个或多租户模型？
• SLAs. 可用性 延迟 吞吐量 一致性和冗余性都必须定义。
• 安全. IAAA (身份identity, 验证authentication, 受权authorization, 和 审核audit), 数据的保密性和隐私性都必须考虑
• 可用性跟踪. 了解系统的使用是天天系统的平常运做，如容量规划。也可能用于执行计费系统的使用和/或治理(配额/速度限制)。
• 部署和配置管理. 系统是如何部署更新?

分布式系统的模型抽象

• 系统模型（异步/同步）
• 失效模型（崩溃故障，分区）
• 一致性模型（强，最终）

　　一般，咱们最熟悉的模式（例如，一个分布式系统上实现共享内存抽象）是太昂贵了。一个分布式系统越弱势越能保证其中元素有更大的行动自由，从而焕发潜在的更大的性能- 但它也可能致使很难管理。这就须要咱们有极大智慧，不能以牺牲性能换来管理的方便性。所以，试图将分布式系统当作一个统一的单一系统的思惟会阻碍分布式系统的扩展。

　　分布式系统遵循CAP定律，在高一致性 高可用性和分区容错性之间三选二：

　　

• CA (consistency高一致性 + availability高可用性). 使用2pc 两阶段事务提交来保证。其缺点没法实现分区容错性，一旦某个操做失败，整个系统就出错，没法容忍(水至清则无鱼)。
• CP (consistency高一致性 + partition tolerance分区容错性). 使用Paxos来保证，可用性下降。
• AP (availability高可用性 + partition tolerance分区容错性). 使用Gossip等实现最终一致性，如Dynamo.
• 如何正确理解CAP理论？
  

分布式系统的设计技巧：分区和复制

　　对于一个数据集有两种设计方式：

1. 分区：它能够被分割在多个节点，以容许更多的并行处理。有更好的性能，可是容错能力低。
2. 复制：它也能够被复制或缓存在不一样的节点上，以减小在客户端和服务器之间的距离，更强的容错能力，可是复制消耗性能。关键是复制数据之间的一致性。弱一致性提供更低的延迟和更高的可用性。

分布式系统的设计技巧：时钟和顺序

　　分布式系统针对计算和存储的策略是不一样的，对于数据的存储主要是分区和复制，而对于计算主要是保证事件的顺序，由于分布式计算任务是由事件驱动的，好比Storm等等。那么事件的顺序表明了业务逻辑的顺序，事件有时是树形嵌套事件，可靠性就是必须保证一个树形集合全部事件都获得网站执行是一个事务原子的。