主流分布式---系统架构分析
目录
一、前言 (3)
二、SOA架构解析 (3)
三、微服务（Microservices）架构解析 (7)
四、SOA 和微服务架构的差别 (9)
五、服务网格（Service Mesh）架构解析 (9)
六、分布式架构的基本理论 (11)
七、分布式架构下的高可用设计 (15)
八、总结 (19)
一、前言
本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微服务架构是最常见两种分布式架构，而且目前服务网格的概念也越来越火了。那我们本文就先从这些常见架构开始。
二、SOA架构解析
SOA 全称是: Service Oriented Architecture，中文释义为“面向服务的架构”，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。架构图如下：
跟SOA 相提并论的还有一个ESB(企业服务总线)，简单来说ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通; 随着我们业务的越来越复杂，会发现服务越来越多，SOA架构下，它们的调用关系会变成如下形式：
很显然，这样不是我们所想要的，那这时候如果我们引入ESB的概念，项目调用就又会很清晰，如下：
SOA所要解决的核心问题
?系统间的集成: 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。
?系统的服务化: 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。
?业务的服务化: 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从
技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是【高效】。
三、微服务（Microservices）架构解析
微服务架构和SOA 架构非常类似,微服务只是SOA 的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。组件表示的就是一个可以独立更换和升级的单元，就像PC 中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把PC 中的各个组件以服务的方式构建，那么这台PC 只需要维护主板（可以理解为ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 需要调用CPU 做计算处理，只需知道CPU 这个组件的地址就可以了。
微服务的特征
1.通过服务实现组件化
2.按业务能力来划分服务和开发团队
3.去中心化
4.基础设施自动化(devops、自动化部署)
四、SOA 和微服务架构的差别
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时以SOA 的思想进入到单个业务系统内部实现真正的组件化。
Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似Spring Boot 或者Node 等技术独立运行。
还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微服务关注的是完全分离。
五、服务网格（Service Mesh）架构解析
17 年年底，非侵入式的Service Mesh 技术慢慢走向了成熟。Service Mesh ，中文释义“服务网格”，作为服务间通信的基础设施层在系统中存在。如果要用一句话来解释什么叫Service Mesh，我们可以将它比作是应用程序或者说微服务间的TCP/IP层，负责服务间的网络调用、熔断、限流和监控。我们都知道在编写应用程序时程序猿一般都无须关心TCP/IP 这一层（比如提供HTTP 协议的Restful 应用），同样如果使用服务网格我们也就不需要关系服务间的那些原来是由应用程序或者其他框架实现的事情(熔断、限流、监控等)，现在只要交给Service Mesh 就可以了。服务网格架构图如下：
目前流行的Service Mesh 开源软件有Linkerd、Envoy 和Istio，而最近Buoyant（开源Linkerd 的公司）又发布了基于Kubernetes 的Service Mesh 开源项目Conduit。
关于微服务和服务网格的区别，我这样理解：微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和DevOps 更好的结合等。
服务网格的特征
1.应用程序间通讯的中间层
2.轻量级网络代理
3.应用程序无感知
4.解耦应用程序的重试/超时、监控、追踪和服务发现
六、分布式架构的基本理论
在说CAP、BASE 理论之前，我们先要了解下分布式一致性的问题。实际上对于不同业务的服务，我们对数据一致性的要求是不一样的，如12306，它要求数据的严格一致性，不能把票卖给用户以后却发现没有座位了;再比如银行转账，我们通过银行转账的时候，一般都会收到一个提示: 转账申请将会在24 小时内到账。实际上这个场景满足的是最终钱只要转账成功了即可，同时如果钱没汇出去还要保证资金不丢失。所以说，用户在使用不同的服务的时候对数据一致性的要求是不一样的。关于分布式一致性问题
分布式系统中要解决的一个非常重要的问题就是数据的复制。在我们的日常开发经验中，相信大多数开发人员都遇过这样的问题: 在做数据库读写分离的场景中，假设客户端A 将系统中的一个值V 由V1 变更为V2，但客户端B 无法立即读取到V 的最新值，e而需要在一段时间之后才能读取到。这再正常不过了，因为数据库复制之间存是在延时的。
所谓分布式一致性的问题，就是指在分布式环境中引入数据复制机制后，不同数据节点之间可能会出现的、且无法依靠计算机应用程序自身解决的数据不一致的情况。简单来说，数据一致性就是指在对一个副本数据进行变更的时候，必须确保也能够更新其它的副本，否则不同副本之间的数据将出现不一致。那么如何去解决这个问题呢？按照正常的思路，我们可能会想到既然是网络延迟导致的问题，那么我们就把同步动作进行阻塞，用户2 在查询的时候必须要等数据同步完成以后再来做。
但这个方案会非常影响性能。如果同步的数据比较多或比较频繁，那么阻塞操作可能会导致整个新系统不可用。故我们没有办法找到一种既能够满足数据一致性、又不影响系统性能的方案，所以就诞生了一个一致性的级别:
1.强一致性: 这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么，
用户体验好，但实现起来往往对系统的性能影响较大。
2.弱一致性: 这种一致性级别约束了系统在写入成功后，不保证立即可以读到写入的值，也不保证多
久之后数据能够达到一致，但会尽可能地保证到某个时间级别(如秒级别)后，数据能够达到一致状态。
3.最终一致性: 最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到数据一致
的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。
CAP 理论
它是一个经典的分布式系统理论。CAP 理论告诉我们: 一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求，最多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度，也被称为“帽子理论”，它是由Eric Brewer 教授在2000 年举行的ACM 研讨会提出的一个著名猜想: 一致性(Consistency)、可用性(Availability)、分区容错(Partition-tolerance)三者无法在分布式系统中被同时满足，并且最多只能满足两个!
?一致性: 所有节点上的数据时刻保持同步
?可用性: 每个请求都能接收一个响应，无论响应成功或失败
分区容错: 系统应该持续提供服务，即使系统内部(某个节点分区)有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些server 与集群中的其他机器失去联系。
分区是导致分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不应该是从3 个特性中选取两个，所以我们只能被迫适应，根本没有选择权。CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的NoSql 场景中，并不适用于数据库系统。
BASE 理论
从前面的分析中我们知道: 在分布式(数据库分片或分库存在的多个实例上)前提下，CAP 理论并不适合数据库事务(因为更新一些错误的数据而导致的失败，无论使用什么高可用方案都是徒劳的，因为数据发生了无法修正的错误)。此外XA 事务虽然保证了数据库在分布式系统下的ACID (原子性、一致性、隔离性、持久性)特性，但同时也带来了一些性能方面的代价，对于并发和响应时间要求都比较高的电商平台来说，是很难接受的。
eBay 尝试了另外一条完全不同的路，放宽了数据库事务的ACID 要求，提出了一套名为BASE 的新准则。BASE 全称为Basically Available,Soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。相对于CAP 来说，它大大降低了我们对系统的要求。
Basically Available(基本可用)
表示在分布式系统出现不可预知的故障时，允许瞬时部分可用性
1.比如我们在淘宝上搜索商品，正常情况下是在0.5s 内返回查询结果，但是由于后端的系统故障导致
查询响应时间变成了2s
2.再比如数据库采用分片模式，100W 个用户数据分在5 个数据库实例上，如果破坏了一个实例，那
么可用性还有80%，也就是80%的用户都可以登录，系统仍然可用
3.电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级
服务。这就是损失部分可用性的体现
Soft-state(软状态).
表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时; 比如订单状态，有一个待支付、支付中、支付成功、支付失败，那么支付中就是一个中间状态，这个中间状态在支付成功以后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。
Eventually consistent(数据的最终一致性)
表示的是所有数据副本在一段时间的同步后最终都能达到一个一致的状态，因此最终一致性的本质是要保证数据最终达到一致，而不需要实时保证系统数据的强一致
BASE 理论的核心思想是: 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
七、分布式架构下的高可用设计
避免单点故障
1.负载均衡技术(failover/选址/硬件负载/ 软件负载/去中心化的软件负载(gossip(redis- cluster)))
2.热备(linux HA)
3.多机房(同城灾备、异地灾备)
应用的高可用性
1.故障监控(系统监控(cpu、内存)/链路监控/日志监控) 自动预警
2.应用的容错设计、(服务降级、限流)自我保护能力
3.数据量(数据分片、读写分离)
分布式架构下的可伸缩设计
1.垂直伸缩
2.提升硬件能力
3.水平伸缩
4.增加服务器
加速静态内容访问速度的CDN
CDN 全称是Content Delivery Network，中文释义是内容分发网络。CDN 的作用是把用户需要的内容分发到离用户最近的地方进行响应，这样用户能够快速获取所需要的内容。CDN 本质上就是一种网络缓存技术，能够把一些相对稳定的资源放到距离最终用户较近的地方，一方面可以节省整个广域网的带宽消耗，另外一方面也可以提升用户的访问速度、改善用户体验。现实系统中我们一般会把静态的文件(图片、脚本、静态页面等)放到CDN 中。
1.当用户访问网站页面上的内容URL，经过本地DNS 系统解析，DNS 系统最终会将域名的解析权交
给CNAME 指向的CDN 专用DNS 服务器。
2.CDN 的DNS 服务器将CDN 的全局负载均衡设备IP 地址返回用户。
3.用户向CDN 的全局负载均衡设备发起内容URL 访问请求。
4.CDN全局负载均衡设备根据用户IP地址，以及用户请求的内容URL，选择一台用户所属区域的区
域负载均衡设备，告诉用户向这台设备发起请求。
5.区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务。
6.选择的依据包括: 根据用户IP 地址，判断哪一台服务器距离用户最近。根据用户所请求的URL 中
携带的内容名称，判断哪一台服务器上有用户所需内容;查询各个服务器当前的负载情况，判断哪一台服务器上有服务能力。基于以上条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP 地址。
7.局负载均衡设备把服务器的IP 地址返回给用户。
8.用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容返回到用户终端。如果这台
缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直到追溯到包含该内容的源服务器并将内容拉到本地。
什么情况下用CDN？
最适合的是那些不会经常变化的内容，比如图片，js 文件，CSS 文件，图片文件包括程序模板中CSS 文件中用到的背景图片，还有就是作为网站内容组成部分的那些图片等等。
灰度发布
我们的应用即使经过了测试部门的测试，也仍然很难全面覆盖用户的使用场景，为了保证万无一失，我们在进行发布的时候一般都会采用灰度发布，也就是会对新应用进行分批发布，逐步扩大新应用在整个及集群中的比例直到最后全部完成。灰度发布是说针对新应用在用户体验方面完全无感知。
灰度发布系统的作用在于，可以根据自己的配置，来将用户的流量导到新上线的系统上，来快速验证新的功能，而一旦出问题，也可以马上的回滚发布，简单的说，就是一套A/BTest 系统.
八、总结
通过本文，我们就对主流的SOA架构、微服务架构、服务网格架构做了解析，然后知道了分布式架构中的几个基本理论，然后还分析了如何设计出高可用的分布式架构.
分布式汽车电气电子系统设计和实现 架构
分布式汽车电气/电子系统设计和实现架构在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电子/电气系统开发工程师广泛使用基于模型的功能设计与仿真来迎接这一复杂性挑战。新兴标准定义了与低层软件的标准化接口，最重要的是，它还为功能实现工程师引入了一个全新的抽象级。 这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度环境中的可靠和高效系统实现方面的指导却几乎没有。 另外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设计方法学，包括、分布在多个ECU中的网络和任务调度、线束设计和规格生成。 为什么需要AUTOSAR? 即使在同一家公司，“架构设计”对不同的人也有不同的含义，这取决于她们站在哪个角度上。物理架构处理系统的有形一面，如布线和连接器，逻辑架构定义无形系统的结构和分配，如软件和通信协议。当前设计物理架构和逻辑架构的语言是独立的，这导致相同一个词的意思能够完全不同，设计团队和流程也是独立的，这也导致了一个非常复杂的设计流程(如图1所示)。
图1：物理和逻辑设计流程。 这种复杂性导致了次优设计结果，整个系统的正确功能是如此的难于实现，以致于几乎没有时间去寻求一种替代方法，它可导致更坚固的、可扩展性更好的和更具成本效益的解决方案。为了实现这样一种解决方案，设计师需要新的方法，它能够将物理和逻辑设计流程紧密相连，并依然允许不同的设计团队做她们的工作。 新兴的AUTOSAR标准为系统级汽车电子/电气设计方法学提供了一个技术上和经济上都可行的选择，尽管它主要针对软件层面，即逻辑系统的设计。不过，大量广泛的AUTOSAR元模型及其丰富的接口定义允许系统级电子/电气架构师以标准的格式表示她的设计思想。从经济上看，AUTOSAR标准打开了一个巨大的、统一的市场，它使得能够创立合适的设计工具。
目录 第1章. 概述 (2) 第2章. 存储网络方案 (3) 2.1. 存储系统目标 (3) 2.2. 需求分析 (3) 2.3. 方案设计 (5) 2.3.1. SAN拓朴结构 (5) 2.3.2. 核心存储产品 (6) 2.4. 方案分析 (6) 2.4.1. 基于SAN的存储解决架构 (7) 2.4.2. ADIC StorNext软件解决了SAN中异构平台间的数据共享 (7) 2.4.3. 采用以数据和存储为中心的SAN存储解决架构的优势 (8) 2.4.4. 基于SAN的备份 (9) 2.4.5. 存储阵列的选型 (10) 2.4.6. 光纤通道交换机的选型 (12) 2.4.7. HBA光纤卡的选型 (13) 2.4.8. SAN的管理软件的选型： (13) 第3章. HDS9500V产品综述 (14) 3.1. HDS 9500V产品硬件介绍 (15) 3.2. HDS 9500V产品软件介绍 (17) 3.2.1. 存储资源管理解决方案—Resource Manager (17) 3.2.2. 通道负载平衡解决方案—Dynamic Link Manager (18) 3.2.3. 业务连续性解决方案--ShadowImage (19) 3.2.4. 数据远程备份管理系统件 -- TrueCopy (19) 3.2.5. HDS安全管理软件 SANtinel Software (19) 3.2.6. HDS FlashAccess软件对系统性能的贡献 (20) 第4章. HDS TrueCopy容灾系统详细介绍 (22) 4.1. HDS TrueCopy 系统部件 (22) 4.2. 磁盘卷组的状态 (23) 4.3. HDS Truecopy同步方式 (26) 4.3.1. 高可靠性方案： (27) 4.3.2. 高可用性方案 (27) 第5章. HDS 数据迁移方法 (28) 5.1. 数据迁移 (28) 5.2. 数据迁移的难题 (29) 5.3. 数据迁移相关因素 (29) 5.3.1. 数据的保护 (29) 5.3.2. 在线或离线迁移 (29) 5.3.3. 维护时间窗口 (29) 5.3.4. 迁移技术 (29) 5.3.5. 计划和应用停顿的容忍程度 (30) 5.3.6. 测试需求 (30)
系统架构典型案例 共享平台逻辑架构 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。 一般性技术架构设计案例 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。整体架构设计案例 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下： 综上，我们对整体应用系统架构图进行了设计，下面我们将分别进行说明。 应用层级说明
介绍 1. 项目核心代码结构截图
大型电商分布式架构设计与优化 本文主题为电商网站架构案例，将介绍如何从电商网站的需求，到单机架构，逐步演变为常用的、可供参考的分布式架构原型。除具备功能需求外，还具备一定的高性能、高可用、可伸缩、可扩展等非功能质量需求（架构目标）。
本文大纲： 1. 使用电商案例的原因 2. 电商网站需求 3. 网站初级架构 4. 系统容量估算 5. 网站架构分析 6. 网站架构优化 根据实际需要，进行改造、扩展、支持千万PV，是没问题的。 使用电商案例的原因 分布式大型网站，目前看主要有几类： 1.大型门户（比如网易、新浪等）； 2.SNS网站（比如校内、开心网等）； 3.电商网站（比如阿里巴巴、京东商城、国美在线、汽车之家等）。
大型门户一般是新闻类信息，可以使用CDN、静态化等方式优化。而开心网等交互性比较多，可能会引入更多的NoSQL、分布式缓存、使用高性能的通信框架等。电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NoSQL等技术。因此，我们采用电商网站作为案例，进行分析。 电商网站需求 客户需求： ?建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款； ?用户购买时可以在线与客服沟通； ?用户收到商品后，可以给商品打分和评价； ?目前有成熟的进销存系统，需要与网站对接； ?希望能够支持3~5年，业务的发展； ?预计3~5年用户数达到1000万； ?定期举办双11、双12、三八男人节等活动； ?其他的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导、挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业以及参考网站，给客户提供方案。其它的这里暂不展开。
详解NAS存储系统那个架构与存储的实现 对于一个成功的、具有极高可扩展性的NAS存储系统来说，要想架构云存储系统解决方案需要什么? 云存储的概念始于Amazon提供的一项服务(S3)，同时还伴随着其云计算产品(EC2)。在Amazon的S3的服务背后，它还管理着多个商品硬件设备，并捆绑着相应的软件，用于创建一个存储池。新兴的网络公司已经接受了这种产品，并提出了云存储这个术语及其相应的概念。 云存储是一种架构，而不是一种服务。你是否拥有或租赁了这种架构是一个次要问题。从根本上来看，通过添加标准硬件和共享标准网络(公共互联网或私有的企业内部网)的访问，云存储很容易扩展云容量和性能。事实证明，管理数百台服务器，使得其感觉上去就像是一个单一的、大型的存储池设备是一项相当具有挑战性的工作。早期的供应商(如Amazon)承担了这一重任，并通过在线出租的形式来赢利。其它供应商(如Google)雇用了大量的工程师在其防火墙内部来实施这种管理，并且定制存储节点以在其上运行应用程序。由于摩尔定律(Moore’s Law)压低了磁盘和CPU的商品价格，云存储渐渐成为了数据中心中一项具有高度突破性的技术。
这十年来，集群NAS存储系统已经出现了好转。本文综述了构建一个云存储或大规模可扩展的NAS存储系统的各种不同架构方法，对于那些寻求构建私有云存储以满足其消费的企业IT管理者或是对于那些寻求构建公共云存储产品从而以服务的形式来提供存储的服务提供商来说，这些方法与他们息息相关。架构方法分为两类：一种是通过服务来架构;另一种是通过软件或硬件设备来架构。 传统的系统利用紧耦合对称架构，这种架构的设计旨在解决HPC(高性能计算、超级运算)问题，现在其正在向外扩展成为云存储从而满足快速呈现的市场需求。下一代架构已经采用了松弛耦合非对称架构，集中元数据和控制操作，这种架构并不非常适合高性能HPC，但是这种设计旨在解决云部署的大容量存储需求。各种架构的摘要信息如下： 紧耦合对称(TCS)架构： 构建TCS系统是为了解决单一文件性能所面临的挑战，这种挑战限制了传统NAS存储系统的发展。HPC系统所具有的优势迅速压倒了存储，因为它们需要的单一文件I/O操作要比单一设备的I/O操作多得多。业内对此的回应是创建利用TCS架构的产品，很多节点同时伴随着分布式锁管理(锁定文件不同部分的写操作)和缓存一致性功能。这种解决方案对于单文件吞吐量问题很有效，几个不同行业的很多
分布式汽车电气/电子系统设计和实现架构在过去的十几年里，汽车的电气和电子系统已经变得非常的复杂。今天汽车电子/电气系统开发工程师广泛使用基 于模型的功能设计与仿真来迎接这一复杂性挑战。新兴标准定义了与低层软件的标准化接口，最重要的是，它还为功能实现工程师引入了一个全新的抽象级。 这提高了软件组件的可重用性，但不幸的是，关于如何将基于模型的功能设计的结果转换成高度环境中的可靠和 高效系统实现方面的指导却几乎没有。 此外，论述设计流程物理端的文章也非常少。本文概述了一种推荐的系统级设计方法学，包括、分布在多个ECU中的网络和任务调度、线束设计和规格生成。 为什么需要AUTOSAR? 即使在同一家公司，“架构设计”对不同的人也有不同的含义，这取决于他们站在哪个角度上。物理架构处理系统的有形一面，如布线和连接器，逻辑架构定义无形系统的结构和分配，如软件和通信协议。目前设计物理架构和逻辑架构的语言是独立的，这导致相同一个词的意思可以完全不同，
设计团队和流程也是独立的，这也导致了一个非常复杂的设计流程(如图1所示)。 图1：物理和逻辑设计流程。 这种复杂性导致了次优设计结果，整个系统的正确功能是如此的难于实现，以致于几乎没有时间去寻求一种替代方法，它可导致更坚固的、可扩展性更好的和更具成本效益的解决方案。为了实现这样一种解决方案，设计师需要新的方法，它可以将物理和逻辑设计流程紧密相连，并仍然允许不同的设计团队做他们的工作。 新兴的AUTOSAR标准为系统级汽车电子/电气设计方法学提供了一个技术上和经济上都可行的选择，尽管它主要针对软件层面，即逻辑系统的设计。不过，大量广泛的AUTOSAR 元模型及其丰富的接口定义允许系统级电子/电气架构师以标准的格式表达他的设计思想。从经济上看，AUTOSAR标准
Hadoop分布式文件系统：架构和设计 引言 (2) 一前提和设计目标 (2) 1 hadoop和云计算的关系 (2) 2 流式数据访问 (2) 3 大规模数据集 (2) 4 简单的一致性模型 (3) 5 异构软硬件平台间的可移植性 (3) 6 硬件错误 (3) 二HDFS重要名词解释 (3) 1 Namenode (4) 2 secondary Namenode (5) 3 Datanode (6) 4 jobTracker (6) 5 TaskTracker (6) 三HDFS数据存储 (7) 1 HDFS数据存储特点 (7) 2 心跳机制 (7) 3 副本存放 (7) 4 副本选择 (7) 5 安全模式 (8) 四HDFS数据健壮性 (8) 1 磁盘数据错误，心跳检测和重新复制 (8) 2 集群均衡 (8) 3 数据完整性 (8) 4 元数据磁盘错误 (8) 5 快照 (9)
引言 云计算（cloud computing)，由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。在此过程中被服务者只是提供需求并获取服务结果，对于需求被服务的过程并不知情。同时服务者以最优利用的方式动态地把资源分配给众多的服务请求者，以求达到最大效益。 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS 能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。 一前提和设计目标 1 hadoop和云计算的关系 云计算由位于网络上的一组服务器把其计算、存储、数据等资源以服务的形式提供给请求者以完成信息处理任务的方法和过程。针对海量文本数据处理,为实现快速文本处理响应,缩短海量数据为辅助决策提供服务的时间,基于Hadoop云计算平台,建立HDFS分布式文件系统存储海量文本数据集,通过文本词频利用MapReduce原理建立分布式索引,以分布式数据库HBase 存储关键词索引,并提供实时检索,实现对海量文本数据的分布式并行处理.实验结果表 明,Hadoop框架为大规模数据的分布式并行处理提供了很好的解决方案。 2 流式数据访问 运行在HDFS上的应用和普通的应用不同，需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3 大规模数据集 运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
视频云存储系统设计 1.1.1.1系统概述 结合目前视频存储系统技术发展的主要方向，本次视频存储系统的建设需要达成以下目标： ?采用目前技术领先的视频云存储方式，新建视频云存储系统，有效解决海量高清视频图像数据的存储和管理需求，实现分布式存储，虚拟化集中管理。 ?为充分利旧，将原有的视频存储系统改造融入视频云存储系统，实现全县范围内可利用视频资源的统一存储、统一管理、统一调阅，避免重复投资。 ?视频云存储系统提供高速数据接口，为应用平台提供视频数据高效检索、快速调取等服务功能，为公安业务应用提供有力支撑。 ?视频云存储系统提供标准的运维接口，维护便捷，实现高效实用的管理及使用机制。 1.1.1.2存储技术选择 视频监控数据的存储系统历经了多个阶段的发展，传统的视频存储技术主要有DVR存储、IPSAN存储等存储模式。而新兴的视频云存储模式基于云架构开发，采用面向用户业务应用的设计思路，融合了集群应用、负载均衡、虚拟化、云结构化、离散存储等技术，可将网络中大量各种不同类型的存储设备，通过专业应用软件集合起来协同工作，共同对外提供高性能、高可靠、不间断的视频、图片数据存储和业务访问服务。 总的来说，相比于传统的存储模式，云存储模式具有以下优势： 视频监控云存储与传统存储对比表
因此，根据项目实际情况，基于视频监控应用对存储系统的要求，着眼于技术的先进性和用户使用的便捷性，视频存储系统的建设推荐采用新型监控云存储技术来实现。 1.1.1.3存储系统架构 1.1.1.3.1视频云存储技术架构 视频云存储系统采用分层结构，整个系统从逻辑上分为五层，分别为设备层、存储层、管理层、接口层、应用层。 系统技术架构如下：
高并发分布式服务架构方案 下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取 分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格， 适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过 读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案， 但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对
于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。 基础服务 基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时 定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源 开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高 可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。 应用层 应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群， 可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。
第1章前言. 3 第2章存储基本概念. 5 第1节存储设备分类. 6 1.1 SCSI存储设备. 7 1.2 SAS存储设备. 13 1.3 FC光纤通道存储设备. 15 1.4 ISCSI存储设备. 15 1.5 存储设备的融合和演变. 20 1.6 磁带存储. 20 1.7 应用存储. 20 第2节存储网络结构. 20 2.1 DAS存储系统网络结构. 20 2.2 SAN存储系统网络结构. 22 2.3 NAS存储系统网络结构. 22 2.4 网络结构的融合和演变. 22
第3节FC网络和FC交换机. 22 3.1 FC网络. 22 3.2 FC交换机设计. 22 第4节接口速率和存储带宽. 22 第5节存储共享. 22 5.1 设备共享. 22 5.2 文件系统共享. 22 5.3 存储共享管理软件. 22 第6节业务系统分类. 22 第3章数据库系统存储设计. 23 第1节存储应用特点. 23 第2节设计准备. 23 第3节主备数据库系统设计. 23 第4节双机数据库系统设计. 23 第5节数据库备份系统设计. 23
第1节非性线编辑制作系统存储应用特点. 24 第2节带宽分析. 26 第3节容量分析. 26 第4节小型制作网存储设计. 26 第5节中型制作网存储设计. 26 第6节大型制作网存储设计. 26 第7节高清制作网存储设计. 26 第8节媒资系统存储设计. 26 第5章视频监控系统存储设计. 27 第1节视频监控系统存储应用特点. 27 第2节带宽分析. 27 第3节容量分析. 27 第4节小型视频监控系统存储设计. 27 第5节中型视频监控系统存储设计. 27
主流分布式系统架构分析 主流分布式---系统架构分析
目录 一、前言 (3) 二、SOA架构解析 (3) 三、微服务( Microservices )架构解析 (7) 四、SOA和微服务架构的差别 (9) 五、服务网格( Service Mesh )架构解析 (9) 六、分布式架构的基本理论 ......................................................................................... 1 1 七、分布式架构下的高可用设计 (15) 八、总结 .......................................................................................................... 1 9
、八、 、 》 本文我们来聊一聊目前主流的分布式架构和分布式架构中常见理论以及如何才能设计出高可用的分布式架构好了。分布式架构中，SOA和微服务架构是最常见两种分布式架构，而且目前服务网格的 概念也越来越火了。那我们本文就先从这些常见架构开始。 、SOA架构解析 SOA全称是：Service Oriented Architecture ，中文释义为"面向服务的架构"，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立 的形式部署运行，服务之间通过网络进行调用。架构图如下：
Appl 跟SOA 相提并论的还有一个 ESB （企业服务总线），简单来说ESB 就是一根管道，用来连接各个服 务节点。 ESB 的存在是为了集成基于不同协议的不同服务， ESB 做了消息的转化、解释以及路由的工 作，以此来让不 同的服务互联互通；随着我们业务的越来越复杂， 会发现服务越来越多，SOA 架构下， 它们的调用关系会变成如下形式: App 2 App 6 App 3 App 4
第十二章海量存储系统设计 以传统的方式存储和管理日益增长的数据，意味着你需要不断地增加磁盘，投入更多的人力与物力，导致成本上升。以优秀的分级存储软件和自动磁带库系统，即可以轻松实现海量数据存储。 12.1 海量数据存储系统架构方案 考虑到海量存储系统是IT 构架的核心模块，这里存储网络架构采用双Fabric 网络结构，这种结构一方面带来了高可用性，另一方面提供了更多的数据通信带宽。下面是海量存储系统的双Fabric 网络结构图： 图12-1 双光纤通道结构 其中网络核心采用director 级别的核心光纤通道交换机1 台（端口数>=128），通过在其内部划分虚拟SAN 分别构成两个独立的fabric；为保证高可靠性和提高系统的运行速度，存储工程师在各服务器群的每台主机上都通过两个HBA 连接到不同的Fabric 网络中，而
且存储设备（磁盘阵列和磁带库）也是同时接入两个fabric，这样构成了一个无单点故障的网络系统。 双Fabric 存储网络设计要点和优势： ?主机和存储设备的冗余连接，整体提高系统的可靠性 ?主机和存储设备的双路连接，工作在Active-Active 模式，整体提高系统的性能?双网络结构设计，提高网络的可靠性，避免由于意外系统故障造成网络中断 ?双网络结构设计，核心-边缘体系架构，方便未来网络的扩充 ?交换机具有很强的向下兼容性，即可兼容1G 的交换机，又可兼容1G 的存储设备，如磁带库等设备都可直接连接到交换机中，提高设备的利用率 ?可做LAN-Free 备份，减少备份对网络带宽的占用，整体提高数据备份和恢复的速度 ?有利于系统的在线维护和扩展，而不影响系统的正常运行 ?采用硬件实现的网络安全性管理，保证数据的安全性 与外部存储网络的互联方案 外部存储网络的接入是为了更好的提供基于数据复制（异步或同步）的容灾服务。本着为客户各部门不同容灾需求服务的原则，这里存储工程师设计了采用三种形式的存储网络外部互联方案，即： FCIP 接入方案 DWDM 接入方案 SDH 接入方案 在100Km 以内的连接上这三种接入方案的特点如下： 表12-1 外部网络存储通道比较
系统架构典型案例 一、共享平台逻辑架构 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。 二、一般性技术架构设计案例 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。
三、整体架构设计案例 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下： 综上，我们对整体应用系统架构图进行了设计，下面我们将分别进行说明。 1.应用层级说明 整体应用系统架构设计分为五个基础层级，通过有效的层级结构的划分可以全面展现整体应用系统的设计思路。 基础层 基础层建设是项目搭建的基础保障，具体内容包含了网络系统的建设、机房建设、多媒体设备建设、存储设备建设以及安全设备建设等，通过全面的基础设置的搭建，为整体应用系统的全面建设良好的基础。 应用数据层 应用数据层是整体项目的数据资源的保障，本次项目建设要求实现全面的资源共享平台的搭建，所以对于应用数据层的有效设计规划对于本次项目的建设有着非常重要的作用。 从整体结构上划分，我们将本次项目建设数据资源分为基础的结构型资源和非结构型资源，对于非结构型资源我们将通过基础内容管理平台进行有效的管理维护，从而供用户有效的查询浏览；对于结构型数据，我们进行了有效的分类，具体包括政务公开资源库、办公资源库、业务经办资源库、分析决策资源库、内部管理资源库以及公共服务资源库。通过对资源库的有效分类，建立完善的元数据管理规范，从而更加合理有效的实现资源的共享机制。 应用支撑层 应用支撑层是整体应用系统建设的基础保障，根据本次招标文件相关需求，我们进行了相关面向服务体系架构的设计，通过统一的企业级总线服务实现相关引用组件包括工作流、表单、统一管理、资源共享等应用组件进行有效的整合和管理，各个应用系统的建设可以右下基于基础支撑组件的应用，快速搭建相关功能模块。 由此可见，应用支撑层的建设是整体架构设计的核心部分，其关系到本次项目的顺利搭建以及今后区劳动局信息化的发展。 应用管理层
本文作者Kate Matsudaira是一位美丽的女工程副总裁，曾在Sun Microsystems、微软、亚马逊这些一流的IT公司任职。她有着非常丰富的工作经验和团队管理经验，当过程序员、项目经理、产品经理以及人事经理。专注于构建和操作大型Web应用程序/网站，目前她的主要研究方向是SaaS（软件即服务）应用程序和云计算（如大家所说的大数据）。 本文是作者在AOSA一书介绍如何构建可扩展的分布式系统里的内容，在此翻译并分享给大家。 开源软件已经成为许多大型网站的基本组成部分，随着这些网站的逐步壮大，他们的网站架构和一些指导原则也开放在开发者们的面前，给予大家切实有用的指导和帮助。 这篇文章主要侧重于Web系统，并且也适用于其他分布式系统。 Web分布式系统设计的原则 构建并运营一个可伸缩的Web站点或应用程序到底是指什么？在最初，仅是通过互联网连接用户和访问远程资源。 和大多数事情一样，当构建一个Web服务时，需要提前抽出时间进行规划。了解大型网站创建背后的注意事项以及学会权衡，会给你带来更加明智的决策。下面是设计大型Web系统时，需要注意的一些核心原则： ?可用性 ?性能 ?可靠性 ?可扩展 ?易管理 ?成本 上面的这些原则给设计分布式Web架构提供了一定的基础和理论指导。然而，它们也可能彼此相左，例如实现这个目标的代价是牺牲成本。一个简单的例子：选择地址容量，仅通过添加更多的服务器（可伸缩性），这个可能以易管理（你不得不操作额外的服务器）和成本作为代价（服务器价格）。 无论你想设计哪种类型的Web应用程序，这些原则都是非常重要的，甚至这些原则之间也会互相羁绊，做好它们之间的权衡也非常重要。 基础
第二章《计算机网络基础知识》 计算机系统由硬件和软件组成，软件通常分为系统软件和应用软件。 系统软件支持应用软件的运行，为用户开发应用软件提供平台，用户可以使用它，但不能随意修改它。 常用的系统软件有操作系统、语言处理程序、连接程序、诊断程序、数据库等。 应用软件指计算机用户利用软硬件资源为某一专门的应用目的而开发的软件。 2.1 操作系统基础知识 操作系统Operating System，是计算机系统的核心系统软件。 2.1.1 操作系统的原理、类型、结构 1、操作系统定义 硬件资源包括中央处理器、存储器、输入输出设备。 软件资源是以文件形式保存在存储器上的程序和数据。 操作系统既有效组织和管理系统中各种软硬件资源，合理地组织计算机系统的工作流程，又控制程序的执行，为用户使用计算机提供了一个良好的环境和友好的接口。 2、操作系统分类 按功能不同分：单用户操作系统、批处理操作系统;分时操作系统、实时操作系统;网络操作系统、分布式操作系统;嵌入式操作系统。
3、操作系统的特征 并发性、共享性、虚拟性、不确定性。 4、操作系统的功能 进程管理、文件管理、存储管理、设备管理、作业管理。 2.1.2 处理机与进程管理 1、进程的定义及其分类 进程通常由程序、数据、进程控制块PCB组成。 2、进程的状态转换与控制 就绪、运行、阻塞。 进程控制是通过进程控制原语实现的，进程控制原语主要有：创建原语、撤销原语、挂起原语、激活原语、阻塞原语、唤醒原语。 注：原语不可分割，不允许中断。 3、进程互斥与同步以及P/V 操作 同步是使在异步环境下的各进程按一定的顺序和速度执行。 互斥要保证临界资源一次只能提供一个进程使用，称为临界资源CR。 PV操作是低级通信原语，在执行期间不可分割，P表示申请一个资源，V表示释放一 个资源。
分布式文件系统架构设计
目录 1.前言 (3) 2.HDFS1 (3) 3.HDFS2 (5) 4.HDFS3 (11) 5.结语 (15)
1.前言 Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS，解决了海量数据存储的问题；实现了一个分布式计算引擎MapReduce，解决了海量数据如何计算的问题；实现了一个分布式资源调度框架YARN，解决了资源调度，任务管理的问题。而我们今天重点给大家介绍的是Hadoop里享誉世界的优秀的分布式文件系统-HDFS。 Hadoop重要的比较大的版本有:Hadoop1，Hadoop2，hadoop3。同时也相对应的有HDFS1，HDFS2，HDFS3三个大版本。后面的HDFS的版本，都是对前一个版本的架构进行了调整优化，而在这个调整优化的过程当中都是解决上一个版本的架构缺陷，然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题，所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进，通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。 2.HDFS1
最早出来投入商业使用的的Hadoop的版本，我们称为Hadoop1，里面的HDFS就是HDFS1，当时刚出来HDFS1，大家都很兴奋，因为它解决了一个海量数据如何存储的问题。HDFS1用的是主从式架构，主节点只有一个叫：Namenode，从节点有多个叫：DataNode。 我们往HDFS上上传一个大文件，HDFS会自动把文件划分成为大小固定的数据块（HDFS1的时候，默认块的大小是64M，可以配置），然后这些数据块会分散到存储的不同的服务器上面，为了保证数据安全，HDFS1里默认每个数据块都有3个副本。Namenode是HDFS的主节点，里面维护了文件系统的目录树，存储了文件系统的元数据信息，用户上传文件，下载文件等操作都必须跟NameNode进行交互，因为它存储了元数据信息，Namenode为了能快速响应用户的操作，启动的时候就把元数据信息加载到了内存里面。DataNode是HDFS的从节点，干的活就很简单，就是存储block文件块。
存储架构 三种常见架构：DAS DAS、、NAS NAS、 、SAN 在数据存储中，存储设备与服务器的连接方式通常有三种形式：1、存储设备与服务器直接相连接--DAS；2、存储设备直接联入现有的TCP/IP 的网络中NAS； 3、将各种存储设备集中起来形成一个存储网络，以便于数据的集中管理--SAN。 1、什么是直接附属存储（、什么是直接附属存储（DAS DAS DAS）？ ）？DAS（Direct Attached Storage，直接附属存储），也可称为SAS（Server-Attached Storage，服务器附加存储）。DAS 被定义为直接连接在各种服务器或客户端扩展接口下的数据存储设备，它依赖于服务器，其本身是硬件的堆叠，不带有任何存储操作系统。在这种方式中，存储设备是通过电缆（通常是SCSI 接口电缆）直接到服务器的，I/O（输入/输入）请求直接发送到存储设备。DAS 适用于以下几种环境： 1）服务器在地理分布上很分散，通过SAN（存储区域网络）或NAS（网络直接存储）在它们之间进行互连非常困难； 2）存储系统必须被直接连接到应用服务器； 3）包括许多数据库应用和应用服务器在内的应用，它们需要直接连接到存储器上，群件应用和一些邮件服务也包括在内。
典型DAS 结构如图所示: 对于多个服务器或多台PC 的环境， 使用DAS 方式设备的初始费用可能比较 低，可是这种连接方式下，每台PC 或 服务器单独拥有自己的存储磁盘，容量 的再分配困难；对于整个环境下的存储 系统管理，工作烦琐而重复，没有集中管理解决方案。所以整体的拥有成本（TCO）较高。目前DAS 基本被NAS 所代替。 2、什么是网络附属存储（、什么是网络附属存储（NAS NAS NAS）？ ）？NAS NAS（（Network Attached Storage Storage：网络附属存储） ：网络附属存储）是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。按字面简单说就是连接在网络上,具备资料存储功能的装置，因此也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。NAS （Network Attached Storage，网络附属存储），是一种专业的网络文件存储及文件备份设备，或称为网络直联存储设备、网络磁盘阵列。NAS 存储的特点
分布式系统与集中式系统 根据管理信息系统的硬件、软件、数据等信息资源在空间的分布情况，系统的结构又可分为集中式和分布式两大类型。 一、分布式系统 利用计算机网络把分布在不同地点的计算机硬件、软件、数据等信息资源联系在一起服务于一个共同的目标而实现相互通信和资源共享，就形成了管理信息系统的分布式结构。具有分布结构的系统称为分布式系统。 实现不同地点的硬、软件和数据等信息资源共享，是分布式系统的一个主要特征。分布式系统的另一个主要特征是各地与计算机网络系统相联的计算机系统既可以在计算机网络系统的统一管理下工作，又可脱离网络环境利用本地信息资源独立开展工作。 下图是分布式的图例： a)硬件环境 原来系统内中央处理器处理的任务分散给相应的处理器，实现不同功能的各个处理器相互协调，共享系统的外设与软件。 b)网络环境 多数分布式系统是建立在计算机网络之上的，所以分布式系统与计算机网络在物理结构上是基本相同的。分布式操作系统的设计思想和网络操作系统是不同的，这决定了他们在结构、工作方式和功能上
也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解 网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件 资源、网络文件结构等情况，在网络中如果用户要读一个共享文件时，用户必须知道这个文件放在哪一台计算机的哪一个目录下；分布式操 作系统是以全局方式管理系统资源的，它可以为用户任意调度网络资 源，并且调度过程是“透明”的。当用户提交一个作业时，分布式操 作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提 交到该处理程序，在处理器完成作业后，将结果传给用户。在这个过 程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个 处理器一样。 c)优缺点 分布式系统具有以下优点： 1、可以根据应用需要和存取方便来配置信息资源； 2、有利于发挥用户在系统开发、维护和信息资源管理方面的积极性和 主动性，提高了系统对用户需求变更的适应性和对环境的应变能力； 3、系统扩展方便。增加一个网络结点一般不会影响其他结点的工作。 系统建设可以采取逐步扩展网络结点的渐进方式，以合理使用系统开发所需 资源； 4、系统的健壮性好（网络上一个结点出现故障一般不会导致全系统 瘫痪）。 分布式系统具有以下缺点： 1、由于信息资源分散，系统开发、维护和管理的标准、规范不易统一； 2、配置在不同地点的信息资源一般分属管理信息系统的各子系统。 不同子系统之间往往存在利益冲突，管理上协调有一定难度； 3、各地的计算机系统工作条件与环境不一，不利于安全保密措施的 统一实施。 现在企业组织结构在朝小型化、扁平化、网络化方向发展。管理信息 系统必须适应这一发展。八十年代以来，随着计算机网络与通信技术的迅速 发展，分布式系统已经成了当前信息系统结构的主流模式。 二、集中式系统