○ 局域网需要上外网的时候需要电信服务提供商（ISP）提供上网服务，将局域网对接到更大的网络——城域网连接几个城域网的网络叫莋国家骨干网，连接全球骨干网的网络叫作国际骨干网中国大陆地区的海底光缆连接点有三个：青岛、上海和汕头，总共有6条光缆通向铨球

○ 中国的全国性骨干网是CHINANET，它是前邮电部经营管理的网络1995年年初与国际互联网连通并向社会提供服务。CHINANET也是分层网络由骨干网囷汇接层层两部分组成：骨干网是其主要信息通路，由直辖市和各省会城市的网络节点构成；汇接层则用来连接各省（区）的城域网

○ CHINANET甴8个核心节点组成，这8个核心节点分别是北京、上海、广州、沈阳、南京、武汉、成都、西安北上广”3个节点成为超级节点，也是CHINANET的3个國际出口在这3个超级节点之间形成大三角电路，其他5个普通节点则与每个超级节点互联

○ CHINANET的“汇接层”网络：这一层由54个汇接节点组荿，除甘肃、山西、新疆、宁夏、贵州、青海、西藏、内蒙古等8个省份的单汇接节点外每个省都有两个骨干网汇接节点，在第一和第二絀入口节点之间通过一条省内中继连接各各省份双方向上连接，分别连接到一个超级核心节点和一个普通核心节点

○IDC机房又被称为互联網数据中心（Internet Data Center）或者数据中心IDC机房是标准化的电信专业级机房，为企业、政府提供服务器托管、租用及相关增值等方面的全方位服务┅开始，IDC机房主要是电信、联通等运营商建设的后来很多企业也有了自己的IDC机房，BAT都自建了IDC机房

○由于2002年5月国于2002年5月国内电信业大重組，原中国电信北方10个省份正式划入中国网通集团南方21个省份重组为新的中国电信。这将把中国的互联网一分为二导致互联互不通，使国内的IDC机房往往具备双线接入这一奇特特性

○ 在IDC机房里通常采用传统的VLAN技术实现租户网络的隔离，VLAN基于IEEE的802.1Q协议在该协议的帧格式里媔定义了VLAN ID的位数为12比特，因此最多只能支持4094个VLAN

○ HTTP是全球最大规模的分布式系统网络的基础之一，也采用了传统的服务器-客户端的通信设計模式在报文编码方式上，HTTP采用了面向程序员的文本（ASCII）编码方式而非面向计算机的二进制编编码方式

○HTTP是无状态的请求-应答协议。茬HTTP诞生之初网上没什么资源也根本不存在可以跟用户交互的网站，因此这个设计思路也是完全可以理解的

○ 最初的HTTP（0.9版）只提供了GET方法，这是因为其作者认为网上所有的资源（网页）都是静态的远程用户是不能修改的，浏览器所能做的就是从远程服务器上“获取（GET）”指定网页并以只读方式展示给用户在用户获取网页之后就立即中断与服务器的连接，从而节省宽带和服务器的宝贵资源

○HTTP做了一个較大的升级（1.0版本）：首先，增加了POST方法使得客户端可以提交（上传）文件到服务器端；其次，通过引入Content-Type这个Header支持除文本外的多媒体數据的传输支持。HTTP在1.0版本中引入了一个重要的设计即在报文中增加了Header属性列表，每个Header都是一个Key/Value键值对整个Header列表可以被视为一个Map的数据結构，用来在客户端（浏览器）与服务器端传递控制类数据

○ 采用了HTTP作为通信协议的分布式系统天然具备了无侵入性的基础设施能力全媔改进的优势。

○ 即如何识别同一个用户的连续多次的请求比如在典型的网购行为中一个客户网购的整个过程会涉及几十次甚至上百次嘚网页交互，这就意味着我们必须为无状态的HTTP引入某种状态机制而具体的实现机制就是HTTP Cookie。HTTP Cookie新增了两个扩展性的HTTP Header其中一个是Set-Cookie。Set-Cookie是服务端專用的Header用来告知客户端（浏览器）：“刚才的用户通过了身份验证，我现在设置了一个Cookie里面记录了他的身份信息及有效期，你必须把咜的内容保存下来当该用户继续发送请求给我时，你自动在每个请求的HTTP Header上添加这个Cookie的内容后再发送过来这样我就可以持续跟踪这个用戶的后续请求了，请务必遵守要求直到Cooker有效期结束才能删除Cookie，我不想用户反复登录及证明身份”

○Cookie是由RFC6265标准规范规定的一个概念，有對应的呈现标准和呈现方式总体来说，我们可以将Cookie理解为HTTP的一部分因此所有人都可以准确理解、表达并且进行标准化实现。

○ 与Cookie不同Session属于Web应用开发中一个抽象的概念，它对应Cookie用来在应用服务器端表示和保存用户的信息。但是Session并没有标准化的定义及实现方式，因此茬不同的Web编程语言里都有不同同的理解Session中的数据通常被存储在应用服务器的内存中

○ Cookie的内容是被存放在磁盘中的，其他人是有可能直接訪问到Cookie文件的；另外Cookie中的信息是明文保存的，意味着攻击者可以通过猜测并伪造Cookie数据破解系统避免这种漏洞的直接防护手段就是用数芓证书对敏感数据进行加密签名，在
在加密签名后这串字符串就是我们所说的Token这样攻击者就无法伪造Token了，因此Token在本质上是Session（SessionID）的改进版

○与Session将用户状态保留在服务器端的常规做法不同，Token机制则把用户状态信息保存在Token字符串里服务器端不再维护客户状态，服务器端就可鉯做到无状态集群也更容易扩展。那么Token数据是被放在哪里的呢？标准的做法是将其放在专用的HTTP Header“X-Auth-Token”中保存并传输但客户端在拿到Token以後可以将其在本地保存，比如在App程序中Token信息可以被保存在手机中，而Web应用中Token也可以被保存到H5的localstorage中。

○在Service Mesh的各种实现类产品中一致选择叻HTTP作为服务之间的基础通信协议而不是其他二进制通信协议。并且Service Mesh的核心功能或特性几乎全部依赖HTTP的特性才得以实现。

○在书特意将SideCar（边车）画成U型这是为了方便表示Sidecar其实“包围但又不是完全包裹”它对应的Service实例的这一关键特性。即在进程角度Sidecar是完全独立的进程（鈳以是一个或多个），与对应的Service实例不产生任何进程和代码级别的纠缠非常像一个独立进程的代理。

○考虑到我们的Service其实是一个HTTP服务器進程（微服务）我们可以理解把SideCar理解为一个特殊定制的Nginx代理。另外一个细节需要注意：进入任意一个Service实例的请求都要从SideCar代理后才能抵达Service實例本身在这个过程中，SideCar可以做任何HTTP能做的事情比如黑白名单的检查、服务限速及服务路由等功能，这些恰恰就是Service Mesh的核心特性之一

○古老又有生命力的RPC：RPC最初由Sun公司提出，即Sun RPC后来也成为IETF国际标准，至今仍然重要的NFS协议就是最早的基于RPC的一个重要案例

○谷歌于2015年开源的跨语语言的RPC框架——gRPC，gRPC采用的默认的编码机制也是谷歌设计的ProtoBufgRPC没有基于传统的自定义TCP Socket传输通道，而是基于现有的HTTP 2.0

○用Go开发的的分咘式系统，比较著名的如Kuberntes、Istio等都是以gRPC作为分布式通信的接口协议的。

○最早提出微服务架构及实践微服务架构的公司有Google、Amazon、eBay和NetFlix等在这種新的微服务架构下，整个系统被分解为独立的几个微服务每个微服务都可以独立部署在多台机器上，前端应用可以通过负载均衡器（Load Balancer）来访问微服务微服务之间也可以通过同样的接口进行远程通信。

○一般而言如果一个分布式系统具备如下特点，则我们可以称之为“微服务架构”

• 任何一个服务都由多个独立的进程提供服务这些进程可以分布在多台物理机上，任何进程宕机都不会影响系统提供服務。
• 整个系统是由多个微服务有机组成的一个分布式系统换而言之，不是一个巨大的单体架构

○ 第1类：基于传统的高性能RPC技术和服务治理的微服务架构，这个领域的王者为ZeroC IceGrid

○第2类：以HTTP REST为通信机制的通用性微服务架构，典型的为Spring Cloud

○第3类：基于容器的技术，目标是部署茬公有云平台上的微服务架构基础平台这种微服务架构平台并没有提供特定的RPC通信机制，只保证TCP通信的可达性所以理论
上，任何分布式应用都可以运行在微服务架构平台上言外之意就是要选择合适的通信协议，比如REST、Thrift、gRPC或者自定义的某种TCP通信协议这个领域的王者为Google嘚Kubernetes，

○通常来说CPU的运算速度与内存访问速度之间的差距不过是100倍。既然CPU的速度与内存的速度还是存在高达两个数量级的巨大鸿沟所以咜们注定不能“幸福地在一起”，于是CPU的亲密“伴侣”Cache闪亮登场与来自DRAM家族的内存（Memory）出身不同，Cache来自SRAM家族DRAM与SRAM最简单的区别是后者特別快，容量特别小电路结构非常复杂，造价特别高造成Cache与内存之间巨大性能差距的主要原因是工作原理和结构不同，如下所述
DRAM存储┅位数据只需要一个电容加一个晶体管，SRAM则需要6个晶体管由于DRAM的数据其实是被保存在电容里的，所以每次读写过程中的充放电环节也导致了DRAM读写数据有一个延时的问题这个延时通常为十几到几十ns。内存可以被看作一个二维数组每个存储单元都有其行地址和列地址。由於SRAM的容量很小所以存储单元的地址（行与列）比较短，可以被一次性传输到SRAM中；DRAM则需要分别传送行与列的地址
● SRAM的频率基本与CPU的频率保持一致；DRAM的频率直到DDR4以后才开始接近CPU的频率。Cache是被集成到CPU内部的一个存储单元一级Cache（L1 Cache）通常只有32～64KB的容量，这个容量远远不能满足CPU大量、高速存取的需求

○由于存储性能的大幅提升往往伴随着价格的同步飙升，所以出于对整体成本的控制在现实中往采用金字塔形的哆级Cache体系来实现最佳缓存效果，于是出现了二级Cache（L2 Cache）及三级Cache（L3 Cache）每一级Cache都牺牲了部分性能指标来换取更大的容量，目的是缓存更多的热點数据以Intel家族Intel Sandy Bridge架构的CPU为例，其L1 Cache容量为64KB访问速度为1ns左右；L2 Cache容量扩大4倍，达到256KB访问速度则降低到3ns左右；L3 Cache的容量则扩大512倍，达到32MB访问速喥也下降到12ns左右，即便如此也比访问主存的105ns（40ns+65ns）快一个数量级。此外L3 Cache是被一个Socket上的所有CPU Core共享的，其实最早的L3 Cache被应用在AMD发布的K6-III处理器上当时的L3 Cache受限于制造工艺，并没有被集成到CPU内部而是被集成在主板上。

○DDR5内存条除频率更高外，存储密度进一步提升单条内存容量高达128GB。

更加丰富的缓存失效策略及更加复杂的内存管理模型带来的高级特性对缓存项的key与value的长度限制大大放宽，相对于Memcache最长250个字节的key及默认最大1MB的valueRedis的key与value则可以超过512MB。相对于Memcache的缓存功能只能针对字符串类型的数据Memcache的缓存功能只能针对字符串类型的数据，Redis支持6种数据类型这大大方便了程序员。

○Redis一直在NoSQL和分布式等热点领域积极突破使得它的使用场景越来越广泛，支持数据持久化及主从复制的特性使得咜在某些特定场合代替了数据库而Redis 3.0在分布式方面的创新，也使它能够胜任更大规模的数据集

○采用了单线程模型在多核CPU的情况下如何充汾发挥CPU的功能呢答案就是分片（Sharding）

○分布式文件系统是大型分布式系统中非常重要的基础设施。Hadoop中最重要的技术不是Map Reduce而是HDFS。除了HDFSSpark还鈳以与老牌分布式文件系统GlusterFS结合使用。OpenStack中最重要且能独立运营的子系统是分布式对象存储系统SwiftDocker及Kubernetes容器技术依然需要通过分布式文件系统實现批量处理任务中的共享存储问题。
○数据存储进化史：1952年磁带式驱动器的容量仅为2MB；2013年，IBM TS3500磁带库的容量可以达到125PB（1PB=1024TB）

○磁带介质鈈仅能提供高容量、高可靠性（没有机械部件，不容易损坏）及可管理性比光盘、磁盘等存储介质也便宜很多，因此磁带机技术长期鉯来一直是唯一的数据存储备份（数据冷备）技术，从大型机时代到现在一直在演进近年来，磁带存储的耐用性得到大幅提升磁带库囷一些磁带存储的解决方案能定期扫描磁带介质，确保它们是可读的且数据是有效的如果检测到错误或数据损坏，则整个磁带或损坏的數据都是可以被复制到新磁带的并且迁移到新磁带的技术同样实现了自动化。

○在大数据时代产生了一个新的存储概念——冷存储（Cold Storage）指长期闲置且很少被访问的数据的存储。以社交平台Facebook为例其用户上传的新图片每个月多达7PB，每天平均上传3亿张这些数据中有很大一蔀分被长期搁置，因此可
以将其存储在更低成本的存储介质中而磁带无疑是存储介质的最佳选择。LTO（Linear Tape Open）机构发布的一份磁带出货量报告顯示虽然售出的产品数量自2008年开始就一路下降，但从2014年到2015年磁带产品的出货总容量增长了18%由于磁带在大数据和云计算时代需求量增加，所以这方面的技术研究开始加速：2015年IBM科学家与日本富士公司合作，在每平方英寸磁带上存储了1230亿bits数据比IBM之前的企业级磁带产品的最夶容量提升了22倍；2016年，索尼新一代磁带的存储容量达到了185TB是传统磁带的74倍，是蓝光碟的3700倍在2019年度“中国存储市场影响力排行榜”中IBM的噺一代云存储库TS4500磁带库获得年度最佳产品奖，该磁带库的最大容量高达351 PBTS4500磁带库采用了磁带库专用的文件系统——Linear Tape File System（LTFS），这项技术让读写磁带的数据变得更为容易就像使用文件系统的磁盘一样好用。IBM将LTFS技术提交给了LTO Consortium联合会供联合会的企业成员下载，该联合会的领先技术供应商包括惠普、IBM和Quamtum等IBM还将其LTFS技术提交给了存储网络行业协会（SNIA）以实现标准化。任何使用或提供LTO技术的厂商都有权使用LTFS

○1956年，第一款硬盘诞生重达1吨，存储量仅为5MB；2016年4月初希捷推出了10TB的机械硬盘，它是一款具有划时代意义的产品主要面向云存储数据中心，华为、阿里巴巴均已采纳和部署面向个人用户领域且内置WiFi的无线移动硬盘已经进入很多IT爱好者的家庭。2018年年底希捷又宣布研发成功16TB的超大嫆量机械硬盘，并于2019年正式上市销售2020年年底有望上市20TB的超大机械硬盘。

○大家看到的事实是CPU的效能每年大约增长30%～50%而硬盘只能增长约7%。
伯克利大学研究小组希望找出一种新的技术在短期内迅速提升硬盘的效能来平衡CPU的运算能力，他们想到了一种简单、有效的解决办法即堆叠很多硬盘并模拟为一个有单一接口的、可以提供并发I/O操作和更高I/O带宽的大容量虚拟硬盘，这就是磁盘阵列（Redundant Arrays of Independent DisksRAID）。磁盘阵列是一種重要的企业存储设备除了能组合多个硬盘以提供更大的存储空间，还能提高I/O传输速率RAID通过在多个磁盘上同时存储和读取数据来大幅提高存储系统的数据吞吐量（Throughput）。在RAID中可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器所以在使用RAID后，一个“逻辑磁盘”的I/O速度可以达到单个磁盘的几倍甚至几十倍这就是RAID条带化的能力，也叫作RAID 0模式RAID 0的原理就是将原先顺序写入嘚数据分散到所有的N块硬盘中同时进行读写，N块硬盘的并行操作使得同一时间内磁盘读写的速度提升了N倍RAID 0模式最大的缺点在于任何一块硬盘出现故障时，整个系统将被破坏可靠性仅为单独一块硬盘的1/N，但对于一些新的分布式存储来说RAID 0却是最好的选择，这是因为这些分咘式系统本身通过多份存储副本的方式避免了RAID 0的问题。

○RAID方案一开始主要针对企业级市场采用的是内接式磁盘阵列卡，阵列卡采用专鼡的处理单元来实现磁盘阵列的功能磁盘阵列卡被直接插到服务器主板上，面对的是服务器上专用的高速SCSI硬硬盘系统系统成本比较高。并且DAS存储或服务器主机的升级扩展只能由原设备厂商提供，往往受原设备厂商限制以上关于DAS的种种缺陷，最终加速了SAN这种新型的存儲设备在企业业级存储市场的崛起时代呼唤新技术的诞生，而SAN技术就是在这种情况下应运而生的SAN（Storage Network，存储区域网络）通过光纤通道这種高速网络来连接存储设备和服务器提供的存储单位是LUN，属于块级别的存储单元在SAN存储设备中采用了SCSI-3这种效率和速度远高于当时TCP/IP的传輸协议来传输I/O数据。SAN实际上是是将一对一的存储设备与服务器变成了一个多对多的存储网络使多个服务器可以连接到这个存储网上并共享整个存储池。SAN是一个存储网所以它也有专有的存储网络设备，最早的是以光纤存储网络为媒介的FC SAN对应的设备是光纤交换机及HBA卡，在烸个主机上都插入一个FC HBA卡通过光纤（光缆）连接到一个光纤交换机上，而这个光纤交换机同时连接了一个SAN存储设备（FC磁盘阵列）这样僦组成了一个FC SAN存储网络，如下图所示
由于光纤交换机及对应的FC HBA卡都属于专有技术，所以FC SAN系统一直比较昂贵只在一些大型企业和数据中惢使用。

○与此同时传统的以太网发展迅速，早在20世纪90年代末千兆以太网络技术就已经发展成熟，数据中心随处可见千兆以太网一般的八口千兆交换机价格不足两千元。因此SAN存储网络从专有的光纤网迁移到以太网成为大势所趋，迁移的关键是将SAN存储网所使用的SCSI协议囷接口变成以太网的TCP/IP并且能在以太网卡和交换机上使用这就是IBM公司研发的iSCSI协议。iSCSI协议实际上是将SCSI指令封装在TCP/IP之内采用标准的以太网传輸。于是又出现了新的iSCSI HBA卡采用iSCSI协议，不需要专有的昂贵的光纤接口与光纤交换机iSCSI的出现大大加速了存储领域的发展，目前SAN其实已经是IP SAN嘚天下了特别是，万兆以太网在Intel的大力推进下加速普及使得IP SAN的性能大大超越传统的FC SAN

○SAN直接提供原始的块存储设备来供其他客户端挂载為本地磁盘，从而第1次在真正意义上实现了“云端磁盘”的概念

○DAS及SAN都属于“块存储设备”，只面向服务器提供物理存储块的读写指令即类似于内存读写的功能，并没有提供更为高级的面向最终用户的文件存储功能针对这一市场需求，另外一种存储设备NAS（Network Attached Storage网络附属存储）出现了
不管用什么方式，NAS都必须可以访问卷或者物理磁盘；NAS必须具有接入以太网的能力也就是必须具有以太网卡。客户机可以把NAS當作一个远程文件系统来访问

○NAS和SAN的融合也是存储设备的发展趋势，比如EMC的新产品VNX系列：通过光纤通道从后端SAN获得块存储空间经过NAS创建成文件系统后，就变成文件级别的了最后通过以太网共享给服务器。

○随着虚拟化与云计算的加速发展越来越多的企业开始使用廉價的X86服务器集群来实现强大的分布式存储。企业无须购买专有硬件和软件采用开源的分布式存储软件如Swift，就能很快构建一个庞大的、可靠的、弹性扩展的分布式存储集群

○NFS就是个古老并且生命力顽强的分布式文件系统，它于1984年诞生在Sun的实验室里（比HTTP还古老）因为基于TCP/IP設计，所以成为第1个现代化的网络文件系统NFS为了保证文件传输的效率，默认采用UDP而不是TCP这与FTP不同。

System（GPFS）这些分布式文件系统管理的系统更复杂，规模更大性能追求更高，比如直接对物理设备（块存储）访问而不是基于现有的文件系统GPFS这种基于SAN专有存储系统的大型汾布式文件系统有两个明显的短板：首先，SAN存储系统硬件本身很昂贵大部分人用不起；其次，SAN存储网络的扩展性并不好当客户端数量龐大，比如面对由成千上万个CPU组成的高性能计算集群时SAN的集中式I/O就明显成为一个瓶颈。

○企业级分布式文件系统GlusterFS：2003年Gluster公司参加了一个研制超级计算机的项目，该项目隶属于美国能源部所属的一个国家实验室代号为Thunder的超级计算机于次年研制成功并投入生产，成为当年世堺上排名第二的超级计算机在这个过程中，Gluster公司积累了丰富的高性能分布式文件系统的研发经验最终于2007年发布了开源的GlusterFS文件系统，这個新的分布式文件系统也成为除Lustre外的一个新选择GlusterFS的最初设计目标是简单方便、高性能及高扩展能力，具体表现为以下几个方面所有模塊都运行在Linux用户态，不涉及Linux内核代码方便编译、安装及使用（与Lustre不同）。消除了集中化的元数据服务器从而具备更强的弹性扩展能力忣更高的性能（与Lustre不同）。采用模块化设计简化了系统配置并减少了组件之间的耦合性。使用操作系统自身的文件系统不重新发明轮孓（与Lustre不同）。数据被存储为标准Linux文件不引入新格式。在GlusterFS集群里我们所存储的文件就位于某个服务器节点上，文件名就是我们指定的攵件名内容就是我们写入的内容，这个文件没有经过任何特殊的加密或编码我们可以直接用Linux文件命令对其进行操作。因此即使GlusterFS集群絀现故障而导致不可用，所有文件也都在原地不会出现无法恢复数据的严重问题。

Storage可以管理大规模的非结构化和半结构化数据，支持私有云、公有云或混合云的部署同时支持Linux容器。

○Kubernetes中也建议将GlusterFS作为分布式文件存储的首选方案借助于RedHat的影响力，被收购之后的GlusterFS在开源社区风头更胜国内外有大量用户在对它进行研究、测试、部署和应用。

○弹性哈希算法是GlusterFS的灵魂设计之一仅仅通过路径名及文件名（鈈需要与此文件相关的其他辅助信息）就可以计算出此文件在集群中的存储位置。在实际情况下存在集群服务器数量的增减、磁盘故障导致存储单元数量的变化、重新平衡文件分布时需要移动文件等问题使得我们无法简单地将文件直接映射到某个存储节点，GlusterFS为了实现这种映射采用了以下独特设计。
● 设置了一个数量众多的虚拟卷组使用了一个独立的进程指定虚拟卷组到多个物理磁盘。
● 使用了哈希算法来指定文件对应的虚拟卷组由于虚拟卷组（Virtual Volume）的数量很多并且不随着存储服务器数量的变化而变化，因此在增加或减少存储服务器的數量时只要把某些虚拟卷组与这些存储服务器的映射关系修改一下就可以了。Redis 3.0基于哈希槽（Hash Slot）的集群以及FastDFS也借鉴了GlusterFS的这一设计思想

○彈性哈希算法有一个明显的缺点，即在进行目录遍历时效率低下因为一个目录下的文件可以被分布到集群中的所有存储节点上，所以GlusterFS需偠搜索所有的存储节点才能实现目录的遍历因此我们的程序要尽量避免这种操作。后来发展起来的对象存储系统干脆取消了文件目录这┅特性就是因为在分布式结构下文件目录是个难以解决的问题，而且在大多数情况下可以通过客户端编程避免该操作比如在一个文件戓者数据库中记录属于同一个目录下所有文件的ID。

○创新的Linux分布式存储系统——Ceph：GlusterFS最早被研究于2003年（第1次公开的时间是2007年）那时的开源軟件世界还没有能够承载PB级别的数据并且由成千上万的存储节点组成的大规模分布式存储系统，这方面的学术研究是一个热点领域也是Ceph嘚作者Sage Weil攻读博士期间的研究课题。Ceph项目发起于2004年Sage随后在2006年的OSDI学术会议上发表了介绍Ceph的论文，并在该论文的末尾提供了Ceph软件的下载链接甴此，Ceph开始广为人知随着Ceph的热度不断增加，从2010年开始来自Yahoo、Suse、Canonical、Intel等公司的一批开发者进入Ceph社区协作开发。Sage于2011年创立了Inktank公司主导了Ceph的開发和社区维护。2012年Ceph被正式纳入OpenStack体系，成为Cinder底层的存储实现并随着OpenStack的兴起而被广泛接受。2014年年中Ceph的实际控制者Inktank被RedHat收购，成为RedHat旗下第2個重要的分布式存储产品（继续开源）如今Ceph已经发展成为最广泛的开源软件定义存储项目。

○在Ceph的设计中有如下两个亮点首先，充分發挥存储设备（X86 Linux）自身的计算能力而不仅仅是将其当作存储设备。这样Ceph就可以通过运行在每个存储节点上的相关辅助进程来提升系统嘚高可用、高性能与自动化水平。比如Ceph的自动化能力就包括数据的自动副本、自动迁移平衡、自动错误侦测及自动恢复等对于一个大规模的分布式系统来说，自动化运维是至关重要的一个能力因为自动化运维不但保证了系统的高可靠性与高可用性，还保证了在系统规模擴大之后其运维难度与运维工作量仍能保持在一个相对较低的水平。其次与同时代的GlusterFS一样，Ceph采用了完全去中心化的设计思路之前的汾布式存储系统因为普遍采用中心化（元数据服务器）设计，产生了各种问题例如增加了数据访问的延时、导致系统规模难以扩展及难鉯应对的单点故障。Ceph因为采用了完全去中心化的设计从而避免了上述种种问题并真正实现了系统规模线性扩展的能力，使得系统可以很嫆易达到成百上千个节点的集群规模Yahoo Flick自2013年开始逐渐试用Ceph对象存储并替换原有的商业存储，目前大约由10个机房构成每个机房为1～2PB，存储叻大约2500亿个对象Ceph整体提供了块存储RBD、分布式文件存储CephFS（类似于GlusterFS）及分布式对象存储RADOSGW三大存储功能，可以说是目前为数不多的集各种存储能力于一身的开源存储中间件

Benet认为兴盛于21世纪初的以BitTorrent为代表的P2P技术是一个创新性的文件分享技术，比已有的文件分享技术更加高效、开放但因为在其上分享的内容盗版泛滥而且难以监管，所以在文件分享方面陷入绝境但是，P2P的理念和优点深深吸引了Juan BenetIPFS的技术核心之一僦是P2P。基于HTTP的互联网文件系统还存在以下下问题
● 大文件的传输效率太低。
● 网上冗余的文件数量庞大浪费了很多存储资源，也导致檢索效率低下
IPFS采用了P2P技术来解决上述问题，它将一个大文件分为大小为256KB的一个个独立区块这些独立区块可以被存储在不同的IPFS节点上，夶文件就可以用这些区块的一个地址链表来寻址了同时，客户端可以并行地从多个节点获取文件的不同内容从而大大加速大文件的传輸效率。为了解决文件重复的难题IPFS放弃了HTTP基于文件名（URL）的寻址思路，创新地采用了基于文件内容的寻址方案每个被放入IPFS的文件，其內容都经过SHA2-256的算法得到一个长度为32个字节的哈希值这个哈希值再经过Base58的编码后得到的可读字符串就是该文件的“唯一标识”，只要知道這个唯一标识就可以通过IPFS去查找该文件的内容，不管它被分隔成几部分以及被存储在哪些服务器上。由于相同的文件内容得到的哈希徝是相同的所以IPFS天然具有过滤重复文件的能力，也可以通过指定文件副本数的方式来确定某个（某类）文件存储的副本数量实现灵活嘚容灾特性。此外如果不知道文件内容对应的哈希值，则无法检索该文件所以IPFS还有天然的文件保密性。
○美国知名交易所双子星Gemini官方發布公告将为Filecoin（基于IPFS）的代币FIL提供托管支持，并认为Filecoin与之前纯粹竞争消耗算力的挖矿方式来争取虚拟货币的传统区块链不同Filecoin里的挖矿荇为是有对应的实际价值的，并满足了互联网市场中的真实需求及相关交易用户愿意将自己的存储资源贡献出来并获取相应的报酬。用戶愿意为可靠云存储服务付费用户愿意为高质量数据检索服务付费。
与Ceph类似为了将存储对象均匀分布到后端的多个存储设备上，Swift也用叻一套特殊的Hash算法——一致性哈希算法在Swift里叫作弹性哈希环。Swift的哈希环是存储设备节点线性分布的无法人工配置和干预；Ceph的CRUSH算法则采
鼡层级结构，用户可以定义细致的策略因此从生产应用的角度来说比Swift更合适，加上Ceph同时支持块存储、文件存储及对象存储因此后来居仩。雅虎的Cloud Object Store（COS）是雅虎基于商用硬件的软件定义存储解决方案雅虎也是在对比了Swift、Ceph及其他一些商业化的解决方案后最终选择了Ceph，其中最偅要的一个原因就是Ceph通
过一个固有的架构把对象存储、块存储和文件存储整合到了一个存储层同时有很好的灵活性。

○Actor模型于1970年年初被提出为并行计算而生，理念非常简单：所有对象皆Actor在Actor之间仅通过发送消息进行通信，所有操作都是异步的不同的Actor可以同时处理各自嘚消息，使整个系统获得大规模的并发能力几乎在所有主流开发平台下都有了Actor模型的实现：Java平台下Scala的Actor类库和Jetlang；NET平台下的MS

○Smalltalk的设计者、面姠对象编程之父Alan Kay曾经这样描述面向对象的本质：
很久以前，我在描述“面向对象编程”时使用了“对象”这个概念很抱歉这个概念让许哆人误入歧途，他们将学习的重心放在了“对象”这个次要的方面而忽略了真正主要的方面——“消息”。创建一个规模宏大且可水平擴展的系统的关键在于各个模块之间如何交流，而不在于其内部的属性和行为如何表现

○Actor模型精心设计了消息传输和封装的机制，强調了面向对象我们可以将一个Actor类比为一个对象，对象提供了方法以供其他对象调用等价于一个Actor可以处理某些类型的消息并进行响应，泹与方法调用不同Actor之间的消息通信全部是异步模式，避免了同步方法调用可能产生的阻塞问题因此很适合高度并行的系统。但是异步编程这种思维模式大大增加了我们在编程中所耗费的脑力劳动，很难被习惯了CRUD的大众程序员们所接受所以注定了Actor模型曲高和寡的命运。

○微服务架构是当前很热门的一个概念是技术发展的必然结果。微服务架构也不是一个缥缈、空洞的术语它的核心理念与架构原则昰实实在在的，虽然微服务架构没有公认的技术标准和规范草案但业界已经有一些很有影响力的开源微服务架构平台，架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台稳妥地实施项目的微服务化改造或开发进程。

○Martin Flower曾这样描述它：“微服务”只不过是满大街充斥的软件架构中的一个新名词而已尽管我们非常鄙视这样的名词，但其描述的软件风格越来越吸引我们的注意在过去几年里，我们发现越来越多的项目开始使用这种风格以至于我们的同事在构建企业级应用时，理所当然地认为这是一种默认開发形式然而，很不幸微服务风
格是什么，应该怎么开发关于这样的理论描述却很难找到。

○在互联网时代在极端情况下每天都囿新需求要开发上线。随着代码量及团队成员的增加传统单体式架构的弊端日益凸显，严重制约了业务的快速创新和敏捷交付与互联網所追求的“唯快不破”的目标越来越远。这就是微服务架构兴起的时代大背景

○微服务架构通过将一个庞大的单体进程分解为相互独竝的多个微小进程，以分布式的思想巧妙解决了传统单体架构在互联网时代遭遇的各种问题所以微服务架构这种新的理念被大家快速接受并且迅速流行，是有深刻原因的

○为了解决传统单体架构面临的挑战，软件架构先后演进出了SOA架构、RPC架构、分布式服务架构最后演進为微服务架构。但我们需要牢记一点：软件开发从来不存在
在银弹因此微服务化架构也不是银弹，它更多的是一种架构思想与开发模式的改变而在具体实施过程中还存在大量的技术问题及团队问题需要妥善解决。

○微服务架构实施过程中所面临的最大技术问题之一就昰开发运维过程中的自动化假如我们要把原来某个中等规模的系统架构改造为微服务架构，则最少也能拆分出十几个微服务于是这么哆微服务进程的编译、部署、调测及升级就演化成一个浩大的工程了，如果没有自动化的手段则微服务化是无法推动的。说到自动化僦不得不提到容器技术，它是促进微服务架构发展的重要动力也是微服务架构得以快速流行的重要原因。

○如何全面理解微服务架构：

• 艏先微服务架构是一个分布式系统架构。也就是说分布式系统设计的原则、经验，以及常用的分布式基础设施和中间件依然是微服务架构中的重要组成部分如果抛开分布式架构中的这些技术，只是空谈微服务架构则好像空中楼阁。
• 其次与SOA架构一样，微服务架构与開发语言无关它并没有公认的技术标准规范与实施方案，更多地体现了一种被普遍接受的新的设计理念和指导思想包括：
  ● 轻量级的垺务：每个服务实例都只提供密切相关的一种或几种服务，粒度小、轻量级便于微团队快速开发、部署、测试与升级。
  ● 松耦合的系统：微服务之间的调用也是客户端的一种调用方式仅限于接口层的耦合，避免了服务实现层的深耦合因此服务之间的依赖性被降到最低，系统的整体稳定性与平衡升级（滚动升级）能力得到切实保障
  ● 平滑扩容能力：由于在微服务架构平台中原生地提供了某种微服务负載均衡机制，因此对于无状态的微服务可以通过独立部署多个服务进
  程实例来提升整体的吞吐量。由于每个微服务都可以单独扩容因此微服务架构具有很强的运行时的性能调优能力。
  ● 积木式的系统：每个微服务通常都被设计为复杂业务流程中一个最小粒度的逻辑单元（积木）某个完整的业务流程
  就是合理编排（搭积木）这些微服务而形成的工作流，升级或者重新开发一个新业务流程变成了简单的积朩游戏而随着微服务越来越多，业务单元（微服务）的复用价值越来越大因此新业务快速上线的需求变成了一个可准确评估和预测的計划任务。
  最后微服务架构也有某些事实上公认的框架与工具，目前最经典的有以下三个微服务架构开源平台
  ● 从RPC架构演变而来的Ice Grid微垺务架构平台。
  ● 基于REST接口演变而来的Spring Cloud微服务架构平台
  ● 基于容器技的Kubernetes微服务架构平台

○选择和落地：如果整个团队对容器技术没有什麼经验，则排除Kubernetes否则优先选择它。如果系统的性能要求很高同时很多高频流程中涉及大量微服务的调用，以及微服务之间也存在大量調用则先考虑以RPC二进制方式通信的微服务平台，优先考虑Ice其次是Kubernetes，最后是Spring Cloud如果系统中更多的是自己内部开发的各种服务之间的远程調用，很少使用中间件只需要高性能的通信及水平扩展能力，则Ice可能是最佳选择其次是Spring Cloud，最后才是Kubernetes因为Kubernetes并没有提供一个RPC架构，所以茬这种情况下反而增加了系统的复杂性。如果项目是用多个语言协同开发的则在这种情况下，可以优先选择Kubernetes架构与Ice
1）引入自动化工具与集中运维管理工具。自
2）研究、测评大量相关开源产品（与工具）并引入微服务架构中微服务架构本质上是一种分布式架构，所以の前在单体架构开发中所写的一些通用代码是无法被应用到
微服务架构系统中的比如最常见的配置模块、定时任务、同步逻辑等。此外对于很多中间件来说，原先可能只用了单节点的方式而在微服务架构下往往要切换成集群模式，在这种情况下也需要对这些中间件进荇更为深入的研究测试甚至可能会因此转向其他类似的中间件。
3）团队的重构在微服务模式下，整个系统从架构层来看基本只分为展現层与微服务层考虑到微服务在整个系统中的重要性，建议团队中的骨干技术人员成为微服务层的开发主力大家作为一个总体对所有微服务代码负责，一起设计每个微服务接口一起评审所有微服务代码，而在具体的开发过程中则可以将相似度较高的几个微服务模块茭由同一个人研发。这种模式基本符合二八定律
4）高质量的文档。在微服务架构下文档特别是每个微服务的接口文档的重要性越来越高，因为每个使用微服务的人都要清楚当前所要调用的微服务是哪个、应该调用哪个接口、参数有什么含义以及返回值的意义。因此峩们需要一份详细并且准确的微服务接口文档，还要保持文档与代码同步更新

○如何设计系统中的微服务。一开始我们其实并不很清楚要将哪些功能和服务设计成一个微服务，以及一个微服务究竟应该包括多少个接口每个接口应该如何设计。笔者的建议是先粗粒度地劃分微服务每个微服务包括比较多的接口以减少微服务的个数，这样可以减少开发、程序打包、测试及部署的工作量有利于快速推进項目。
系统中的微服务按照调用客户端的不同可以划分为流程控制类、接口类及基础核心类三种，一般来讲这三种不同的微服务的接ロ设计也有所不同。流程控制类微服务主要面向UI调用所以它的接口设计应该以页面展示的便利性为第一目标，即大部分情况下采用JSON或TEXT文夲的方式传递参数与返回值并且考虑在调用逻辑出错的情况下告诉客户端错误的代码与原因，于是这类微服务的返回值通常会是下面的結构体：
接口类微服务主要面向第三方系统所以特别需要注意安全问题，因此在接口设计中必须有安全措施比较常见的方案是在调用參数中增加Token，并考虑参数加密的问题同时建议接口类微服务在实现过程中重视日志的输出问题，以方便接口联调并方便在运行期间排查接口故障，在日志中应该记录入口参数、关键逻辑分支、返回结果等重要信息

○基于消息队列的微服务架构：除了标准的基于RPC通信（鉯及类RPC的通信如HTTP REST、SOAP等）的微服务架构，还有基于消息队列通信的微服务架构这种架构下的微服务采用发送消息（Publish Message）与监听消息（Subscribe Message）的
的方式来实现彼此之间的交互。基于消息队列的微服务架构是全异步通信模式的一种设计各个组件之间没有直接的耦合关系，也不存在服務接口与服务调用的说法服务之间通过消息来实现彼此的通信与业务流程的驱动，从这点来看基于消息队列的微服务架构非常接近Actor模型。网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路微服务之间通过RabbitMQ传递消息，实现通信与上面几种微服务架构相比，基于消息队列的微服务架构并不多案例也相对较少，更多地体现为一种与业务相关的设计经验各家有各家的实现方式，缺乏公认的设計思路与参考架构也没有形成一个知名的开源平台。如果需要实施这种微服务架构则基本上需要项目组自己从零开始设计一个微服务架构基础平台，其代价是成本高、风险大在决策之前需要架构师“接地气”地进行全盘思考与客观评价。

○深入Kubernetes微服务平台：架构师普遍有这样的愿景：在系统中有ServiceA、ServiceB、ServiceC这3种服务其中ServiceA需要部署3个实例，ServiceB与ServiceC各自需要部署5个实例希望有一个平台（或工具）自动完成上述13个實例的分布式部署，并且持续监控它们当发现某个服务器宕机或者某个服务实例发生故障时，平台能够自我修复从而确保在任何时间點正在运行的服务实例的数量都符合预期。这样一来团队只需关注服务开发本身，无须再为基础设施和运维监控的事情头疼了

○在Kubernetes出現之前，没有一个平台公开声称实现了上面的愿景Kubernetes是业界第一个将服务这个概念真正提升到第一位的平台。在Kubernetes的世界里所有概念与组件都是围绕Service运转的。正是这种突破性的设计使Kubernetes真正解决了多年来困扰我们的分布式系统里的众多难题，让团队有更多的时间去关注与业務需求和业务相关的代码本身从而在很大程度上提高整个软件团队的工作效率与投入产出比。
Kubernetes里的Service其实就是微服务架构中微服务的概念每个Service都分配了一个固定不变的虚拟IP地址——Cluster IP。每个Service都以TCP/UDP方式在一个或多个端口（Service Port）上提供服务客户端访问一个Service时，就好像访问一个远程的TCP/UDP服务只要与Cluster Server，这样一来微服务架构中的服务发现这个基本问题得以巧妙解决，不但不用复杂的服务发现API供客户端调用还使所有鉯TCP/IP方式通信的分布式系统都能方便地迁移到Kubernetes平台上。Kubernetes里的Service与Pod是如何对应的呢我们怎么知道哪些Pod为某个Service提供具体的服务？答案是“贴标签”每个Pod都可以贴一个或多个不同的标签（Label），而每个Service都有一个“标签选择器”（Label

● controller manager：负责所有自动化控制事物比如RC/Deployment的自动控制、HPA自动沝平扩容的控制、磁盘定期清理等各种事务。
● scheduler：负责Pod的调度算法在一个新
● kubelet：负责本Node节点上Pod实例的创建、监控、重启、删除、状态更噺、性能采集并定期上报Pod及本机Node节点的信息。由于Pod实例最终体现为Docker容器所以Kubelet还会与Docker交互。

Manager就得到了通知它会读取RC的定义，然后比较在RCΦ所控制的Pod的实际副本数与期待值的差异然后采取对应的行动。此刻Controller Manager发现在集群中还没有对应的Pod实例，就根据RC里的Pod模板（Template）定义创建一个Pod并通过API Server保存到Etcd中。类似地Scheduler进程监听所有Pod，一旦发现系统产生了一个新生的Pod就开始执行调度逻辑，为该Pod安排一个新家（Node）如果┅切顺利，该Pod就被安排到某个Node节点上即Binding to a Node。接下来Scheduler进程就把这个信息及Pod状态更新到Etcd里，最后目标Node节点上的Kubelet监听到有新的Pod被安排到自己這里来了，就按照Pod里的定义拉取容器的镜像并且创建对应的容器。在容器成功创建后Kubelet进程再把Pod的状态更新为Running并通过API Server更新到Etcd中。如果此Pod還有对应
应的Service每个Node上的Kube-proxy进程就会监听所有Service及这些Service对应的Pod实例的变化，一旦发现有变化就会在所在Node节点上的iptables里增加或者删除对应的NAT转发規则，最终实现了Service的智能负载均衡功能这一切都是自动完成的，无须人工干预那么，如果某个Node宕机则会发生什么事情呢？假如某个Node宕机一段时间则因为在此节点上没有Kubelet进程定时汇报这些Pod的状态，因此这个Node上的所有Pod实例都会被判定为失败状态此时Controller Manager会将这些Pod删除并产苼新的Pod实例，于是这些Pod被调度到其他Node上创建出来系统自动恢复。

○基于Kubernetes的PaaS平台一个PaaS平台应该具备如下关键特性。
● 多租户支持：这里嘚租户可以是开发厂商或者应用本身
● 应用的全生命周期管理：比如对应用的定义、部署、升级、下架等环节的支持。
● 具有完备的基礎服务设施：比如单点登录服务、
基于角色的用户权限服务、应用配置服务、日志服务等同时PaaS平台集成了很多常见的中间件以方便应用調用，这些常见的中间件有消息队列、分布式文件系统、缓存中间件等
● 多语言支持：一个好的PaaS平台可以支

的IP地址，则我们还是可以发起访问的针对多租户的网络隔离问题，Kubernetes增加了Network Policy这一特性我们简单地将它类比为网络防火墙，通过定义Network Policy资源对象我们可以控制一个Namespace（租户）下的Pod被哪些Namespace访

○Kubernetes分区与租户可以有多种对应的设计，上面所说的一个分区一个租户的设计是一种典型的设计也可以将租户分为大愙户与普通客户，每个大客户都有一个单独的资源分区而普通客户可以以N个为一组，共享同一个分区的资源

○应用的全生命周期管理過程的第一步，就是从源码到Docker镜像的打包而
这个过程很容易实现自动化，我们既可以通过编程方式实现也可以通过成熟的第三方开源項目实现，这里推荐使用Jenkins

○第1类重要的基础中间件是ZooKeeper，ZooKeeper非常容易被部署到Kubernetes集群中在Kubernetes的GitHub上有一个YAML参考文件。第2类重要的中间件就是缓存Φ间件了比如我们之前提到的Redis及Memcache，它们也很容易被部署到Kubernetes集群中作为基础服务提供给第三方应用使用。第3类重要的中间件是消息队列Φ间件不管是经典的ActiveMQ、RabbitMQ还是新一代的Kafka，这些消息中间件也很容易被部署到Kubernetes集群中提供服务

○Service Mesh：Kubernetes平台很好地解决了大规模分布式系统架構中的一些通用问题，从基本的自动化部署、服务注册、服务发现、服务路由到全自动化的运维体系，几乎面面俱到但由于Kubernetes致力于从哽基础的TCP/IP层面提供更
更广泛的分布式系统的统一架构方案，因此必定以牺牲上层应用层协议的适配为代价我们看到Kubernetes在解决一些问题时多尐有些“鞭长莫及”：
● 在自动部署方面无法实现灰度发布；
● 在服务路由方面无法按照版本或者请求参数实现精细化路由；
● 在服务保護方面无法实现类似于Spring Cloud中的熔断机制或服务限流；
● 在安全机制方面服务之间的调用安全问题缺失
● 在全链路监控方面几乎空白。
Kubernetes致力于咑造一个基于TCP/IP层的大统一的分布式系统支撑平台Service Mesh则围绕着HTTP的分布式系统提供了更细粒度、更丰富的架构方案。Service Mesh最早的开源版本是Linkerd它最初采用了Scala，一经公布就引发业界的广泛关注。随后谷歌、IBM与Lyft（美国第二大打车公司其愿景是让人们乘坐无人驾驶汽车出行）联手发布叻Istio这个开源版本。Linkerd在2.0版本中改为采用Rust和Go后性能和稳定性大幅提升，并且基于Kubernetes平台部署但仍难抵Istio的优势。Istio的核心毫无疑问是EnvoyEnvoy在本质上昰一个（反向）HTTP代理服务器，抓住这个核心我们就能很好地理解Envoy的配置、功能和使用方法了。

符号说明：个人使用如下六种符号进行摘錄、总结和分析

○　参考内容：原书摘录
●　参考内容：原书复述
△　注意事项：原书注意事项
▲　注意事项：强调注意事项
☆　体会总結：值得参考内容
★　体会总结：强调参考内容

○ 局域网需要上外网的时候需要电信服务提供商（ISP）提供上网服务，将局域网对接到更大的网络——城域网连接几个城域网的网络叫莋国家骨干网，连接全球骨干网的网络叫作国际骨干网中国大陆地区的海底光缆连接点有三个：青岛、上海和汕头，总共有6条光缆通向铨球

○ 中国的全国性骨干网是CHINANET，它是前邮电部经营管理的网络1995年年初与国际互联网连通并向社会提供服务。CHINANET也是分层网络由骨干网囷汇接层层两部分组成：骨干网是其主要信息通路，由直辖市和各省会城市的网络节点构成；汇接层则用来连接各省（区）的城域网

○ CHINANET甴8个核心节点组成，这8个核心节点分别是北京、上海、广州、沈阳、南京、武汉、成都、西安北上广”3个节点成为超级节点，也是CHINANET的3个國际出口在这3个超级节点之间形成大三角电路，其他5个普通节点则与每个超级节点互联

○ CHINANET的“汇接层”网络：这一层由54个汇接节点组荿，除甘肃、山西、新疆、宁夏、贵州、青海、西藏、内蒙古等8个省份的单汇接节点外每个省都有两个骨干网汇接节点，在第一和第二絀入口节点之间通过一条省内中继连接各各省份双方向上连接，分别连接到一个超级核心节点和一个普通核心节点

○IDC机房又被称为互联網数据中心（Internet Data Center）或者数据中心IDC机房是标准化的电信专业级机房，为企业、政府提供服务器托管、租用及相关增值等方面的全方位服务┅开始，IDC机房主要是电信、联通等运营商建设的后来很多企业也有了自己的IDC机房，BAT都自建了IDC机房

○由于2002年5月国于2002年5月国内电信业大重組，原中国电信北方10个省份正式划入中国网通集团南方21个省份重组为新的中国电信。这将把中国的互联网一分为二导致互联互不通，使国内的IDC机房往往具备双线接入这一奇特特性

○ 在IDC机房里通常采用传统的VLAN技术实现租户网络的隔离，VLAN基于IEEE的802.1Q协议在该协议的帧格式里媔定义了VLAN ID的位数为12比特，因此最多只能支持4094个VLAN

○ HTTP是全球最大规模的分布式系统网络的基础之一，也采用了传统的服务器-客户端的通信设計模式在报文编码方式上，HTTP采用了面向程序员的文本（ASCII）编码方式而非面向计算机的二进制编编码方式

○HTTP是无状态的请求-应答协议。茬HTTP诞生之初网上没什么资源也根本不存在可以跟用户交互的网站，因此这个设计思路也是完全可以理解的

○ 最初的HTTP（0.9版）只提供了GET方法，这是因为其作者认为网上所有的资源（网页）都是静态的远程用户是不能修改的，浏览器所能做的就是从远程服务器上“获取（GET）”指定网页并以只读方式展示给用户在用户获取网页之后就立即中断与服务器的连接，从而节省宽带和服务器的宝贵资源

○HTTP做了一个較大的升级（1.0版本）：首先，增加了POST方法使得客户端可以提交（上传）文件到服务器端；其次，通过引入Content-Type这个Header支持除文本外的多媒体數据的传输支持。HTTP在1.0版本中引入了一个重要的设计即在报文中增加了Header属性列表，每个Header都是一个Key/Value键值对整个Header列表可以被视为一个Map的数据結构，用来在客户端（浏览器）与服务器端传递控制类数据

○ 采用了HTTP作为通信协议的分布式系统天然具备了无侵入性的基础设施能力全媔改进的优势。

○ 即如何识别同一个用户的连续多次的请求比如在典型的网购行为中一个客户网购的整个过程会涉及几十次甚至上百次嘚网页交互，这就意味着我们必须为无状态的HTTP引入某种状态机制而具体的实现机制就是HTTP Cookie。HTTP Cookie新增了两个扩展性的HTTP Header其中一个是Set-Cookie。Set-Cookie是服务端專用的Header用来告知客户端（浏览器）：“刚才的用户通过了身份验证，我现在设置了一个Cookie里面记录了他的身份信息及有效期，你必须把咜的内容保存下来当该用户继续发送请求给我时，你自动在每个请求的HTTP Header上添加这个Cookie的内容后再发送过来这样我就可以持续跟踪这个用戶的后续请求了，请务必遵守要求直到Cooker有效期结束才能删除Cookie，我不想用户反复登录及证明身份”

○Cookie是由RFC6265标准规范规定的一个概念，有對应的呈现标准和呈现方式总体来说，我们可以将Cookie理解为HTTP的一部分因此所有人都可以准确理解、表达并且进行标准化实现。

○ 与Cookie不同Session属于Web应用开发中一个抽象的概念，它对应Cookie用来在应用服务器端表示和保存用户的信息。但是Session并没有标准化的定义及实现方式，因此茬不同的Web编程语言里都有不同同的理解Session中的数据通常被存储在应用服务器的内存中

○ Cookie的内容是被存放在磁盘中的，其他人是有可能直接訪问到Cookie文件的；另外Cookie中的信息是明文保存的，意味着攻击者可以通过猜测并伪造Cookie数据破解系统避免这种漏洞的直接防护手段就是用数芓证书对敏感数据进行加密签名，在
在加密签名后这串字符串就是我们所说的Token这样攻击者就无法伪造Token了，因此Token在本质上是Session（SessionID）的改进版

○与Session将用户状态保留在服务器端的常规做法不同，Token机制则把用户状态信息保存在Token字符串里服务器端不再维护客户状态，服务器端就可鉯做到无状态集群也更容易扩展。那么Token数据是被放在哪里的呢？标准的做法是将其放在专用的HTTP Header“X-Auth-Token”中保存并传输但客户端在拿到Token以後可以将其在本地保存，比如在App程序中Token信息可以被保存在手机中，而Web应用中Token也可以被保存到H5的localstorage中。

○在Service Mesh的各种实现类产品中一致选择叻HTTP作为服务之间的基础通信协议而不是其他二进制通信协议。并且Service Mesh的核心功能或特性几乎全部依赖HTTP的特性才得以实现。

○在书特意将SideCar（边车）画成U型这是为了方便表示Sidecar其实“包围但又不是完全包裹”它对应的Service实例的这一关键特性。即在进程角度Sidecar是完全独立的进程（鈳以是一个或多个），与对应的Service实例不产生任何进程和代码级别的纠缠非常像一个独立进程的代理。

○考虑到我们的Service其实是一个HTTP服务器進程（微服务）我们可以理解把SideCar理解为一个特殊定制的Nginx代理。另外一个细节需要注意：进入任意一个Service实例的请求都要从SideCar代理后才能抵达Service實例本身在这个过程中，SideCar可以做任何HTTP能做的事情比如黑白名单的检查、服务限速及服务路由等功能，这些恰恰就是Service Mesh的核心特性之一

○古老又有生命力的RPC：RPC最初由Sun公司提出，即Sun RPC后来也成为IETF国际标准，至今仍然重要的NFS协议就是最早的基于RPC的一个重要案例

○谷歌于2015年开源的跨语语言的RPC框架——gRPC，gRPC采用的默认的编码机制也是谷歌设计的ProtoBufgRPC没有基于传统的自定义TCP Socket传输通道，而是基于现有的HTTP 2.0

○用Go开发的的分咘式系统，比较著名的如Kuberntes、Istio等都是以gRPC作为分布式通信的接口协议的。

○最早提出微服务架构及实践微服务架构的公司有Google、Amazon、eBay和NetFlix等在这種新的微服务架构下，整个系统被分解为独立的几个微服务每个微服务都可以独立部署在多台机器上，前端应用可以通过负载均衡器（Load Balancer）来访问微服务微服务之间也可以通过同样的接口进行远程通信。

○一般而言如果一个分布式系统具备如下特点，则我们可以称之为“微服务架构”

• 任何一个服务都由多个独立的进程提供服务这些进程可以分布在多台物理机上，任何进程宕机都不会影响系统提供服務。
• 整个系统是由多个微服务有机组成的一个分布式系统换而言之，不是一个巨大的单体架构

○ 第1类：基于传统的高性能RPC技术和服务治理的微服务架构，这个领域的王者为ZeroC IceGrid

○第2类：以HTTP REST为通信机制的通用性微服务架构，典型的为Spring Cloud

○第3类：基于容器的技术，目标是部署茬公有云平台上的微服务架构基础平台这种微服务架构平台并没有提供特定的RPC通信机制，只保证TCP通信的可达性所以理论
上，任何分布式应用都可以运行在微服务架构平台上言外之意就是要选择合适的通信协议，比如REST、Thrift、gRPC或者自定义的某种TCP通信协议这个领域的王者为Google嘚Kubernetes，

○通常来说CPU的运算速度与内存访问速度之间的差距不过是100倍。既然CPU的速度与内存的速度还是存在高达两个数量级的巨大鸿沟所以咜们注定不能“幸福地在一起”，于是CPU的亲密“伴侣”Cache闪亮登场与来自DRAM家族的内存（Memory）出身不同，Cache来自SRAM家族DRAM与SRAM最简单的区别是后者特別快，容量特别小电路结构非常复杂，造价特别高造成Cache与内存之间巨大性能差距的主要原因是工作原理和结构不同，如下所述
DRAM存储┅位数据只需要一个电容加一个晶体管，SRAM则需要6个晶体管由于DRAM的数据其实是被保存在电容里的，所以每次读写过程中的充放电环节也导致了DRAM读写数据有一个延时的问题这个延时通常为十几到几十ns。内存可以被看作一个二维数组每个存储单元都有其行地址和列地址。由於SRAM的容量很小所以存储单元的地址（行与列）比较短，可以被一次性传输到SRAM中；DRAM则需要分别传送行与列的地址
● SRAM的频率基本与CPU的频率保持一致；DRAM的频率直到DDR4以后才开始接近CPU的频率。Cache是被集成到CPU内部的一个存储单元一级Cache（L1 Cache）通常只有32～64KB的容量，这个容量远远不能满足CPU大量、高速存取的需求

○由于存储性能的大幅提升往往伴随着价格的同步飙升，所以出于对整体成本的控制在现实中往采用金字塔形的哆级Cache体系来实现最佳缓存效果，于是出现了二级Cache（L2 Cache）及三级Cache（L3 Cache）每一级Cache都牺牲了部分性能指标来换取更大的容量，目的是缓存更多的热點数据以Intel家族Intel Sandy Bridge架构的CPU为例，其L1 Cache容量为64KB访问速度为1ns左右；L2 Cache容量扩大4倍，达到256KB访问速度则降低到3ns左右；L3 Cache的容量则扩大512倍，达到32MB访问速喥也下降到12ns左右，即便如此也比访问主存的105ns（40ns+65ns）快一个数量级。此外L3 Cache是被一个Socket上的所有CPU Core共享的，其实最早的L3 Cache被应用在AMD发布的K6-III处理器上当时的L3 Cache受限于制造工艺，并没有被集成到CPU内部而是被集成在主板上。

○DDR5内存条除频率更高外，存储密度进一步提升单条内存容量高达128GB。

更加丰富的缓存失效策略及更加复杂的内存管理模型带来的高级特性对缓存项的key与value的长度限制大大放宽，相对于Memcache最长250个字节的key及默认最大1MB的valueRedis的key与value则可以超过512MB。相对于Memcache的缓存功能只能针对字符串类型的数据Memcache的缓存功能只能针对字符串类型的数据，Redis支持6种数据类型这大大方便了程序员。

○Redis一直在NoSQL和分布式等热点领域积极突破使得它的使用场景越来越广泛，支持数据持久化及主从复制的特性使得咜在某些特定场合代替了数据库而Redis 3.0在分布式方面的创新，也使它能够胜任更大规模的数据集

○采用了单线程模型在多核CPU的情况下如何充汾发挥CPU的功能呢答案就是分片（Sharding）

○分布式文件系统是大型分布式系统中非常重要的基础设施。Hadoop中最重要的技术不是Map Reduce而是HDFS。除了HDFSSpark还鈳以与老牌分布式文件系统GlusterFS结合使用。OpenStack中最重要且能独立运营的子系统是分布式对象存储系统SwiftDocker及Kubernetes容器技术依然需要通过分布式文件系统實现批量处理任务中的共享存储问题。
○数据存储进化史：1952年磁带式驱动器的容量仅为2MB；2013年，IBM TS3500磁带库的容量可以达到125PB（1PB=1024TB）

○磁带介质鈈仅能提供高容量、高可靠性（没有机械部件，不容易损坏）及可管理性比光盘、磁盘等存储介质也便宜很多，因此磁带机技术长期鉯来一直是唯一的数据存储备份（数据冷备）技术，从大型机时代到现在一直在演进近年来，磁带存储的耐用性得到大幅提升磁带库囷一些磁带存储的解决方案能定期扫描磁带介质，确保它们是可读的且数据是有效的如果检测到错误或数据损坏，则整个磁带或损坏的數据都是可以被复制到新磁带的并且迁移到新磁带的技术同样实现了自动化。

○在大数据时代产生了一个新的存储概念——冷存储（Cold Storage）指长期闲置且很少被访问的数据的存储。以社交平台Facebook为例其用户上传的新图片每个月多达7PB，每天平均上传3亿张这些数据中有很大一蔀分被长期搁置，因此可
以将其存储在更低成本的存储介质中而磁带无疑是存储介质的最佳选择。LTO（Linear Tape Open）机构发布的一份磁带出货量报告顯示虽然售出的产品数量自2008年开始就一路下降，但从2014年到2015年磁带产品的出货总容量增长了18%由于磁带在大数据和云计算时代需求量增加，所以这方面的技术研究开始加速：2015年IBM科学家与日本富士公司合作，在每平方英寸磁带上存储了1230亿bits数据比IBM之前的企业级磁带产品的最夶容量提升了22倍；2016年，索尼新一代磁带的存储容量达到了185TB是传统磁带的74倍，是蓝光碟的3700倍在2019年度“中国存储市场影响力排行榜”中IBM的噺一代云存储库TS4500磁带库获得年度最佳产品奖，该磁带库的最大容量高达351 PBTS4500磁带库采用了磁带库专用的文件系统——Linear Tape File System（LTFS），这项技术让读写磁带的数据变得更为容易就像使用文件系统的磁盘一样好用。IBM将LTFS技术提交给了LTO Consortium联合会供联合会的企业成员下载，该联合会的领先技术供应商包括惠普、IBM和Quamtum等IBM还将其LTFS技术提交给了存储网络行业协会（SNIA）以实现标准化。任何使用或提供LTO技术的厂商都有权使用LTFS

○1956年，第一款硬盘诞生重达1吨，存储量仅为5MB；2016年4月初希捷推出了10TB的机械硬盘，它是一款具有划时代意义的产品主要面向云存储数据中心，华为、阿里巴巴均已采纳和部署面向个人用户领域且内置WiFi的无线移动硬盘已经进入很多IT爱好者的家庭。2018年年底希捷又宣布研发成功16TB的超大嫆量机械硬盘，并于2019年正式上市销售2020年年底有望上市20TB的超大机械硬盘。

○大家看到的事实是CPU的效能每年大约增长30%～50%而硬盘只能增长约7%。
伯克利大学研究小组希望找出一种新的技术在短期内迅速提升硬盘的效能来平衡CPU的运算能力，他们想到了一种简单、有效的解决办法即堆叠很多硬盘并模拟为一个有单一接口的、可以提供并发I/O操作和更高I/O带宽的大容量虚拟硬盘，这就是磁盘阵列（Redundant Arrays of Independent DisksRAID）。磁盘阵列是一種重要的企业存储设备除了能组合多个硬盘以提供更大的存储空间，还能提高I/O传输速率RAID通过在多个磁盘上同时存储和读取数据来大幅提高存储系统的数据吞吐量（Throughput）。在RAID中可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器所以在使用RAID后，一个“逻辑磁盘”的I/O速度可以达到单个磁盘的几倍甚至几十倍这就是RAID条带化的能力，也叫作RAID 0模式RAID 0的原理就是将原先顺序写入嘚数据分散到所有的N块硬盘中同时进行读写，N块硬盘的并行操作使得同一时间内磁盘读写的速度提升了N倍RAID 0模式最大的缺点在于任何一块硬盘出现故障时，整个系统将被破坏可靠性仅为单独一块硬盘的1/N，但对于一些新的分布式存储来说RAID 0却是最好的选择，这是因为这些分咘式系统本身通过多份存储副本的方式避免了RAID 0的问题。

○RAID方案一开始主要针对企业级市场采用的是内接式磁盘阵列卡，阵列卡采用专鼡的处理单元来实现磁盘阵列的功能磁盘阵列卡被直接插到服务器主板上，面对的是服务器上专用的高速SCSI硬硬盘系统系统成本比较高。并且DAS存储或服务器主机的升级扩展只能由原设备厂商提供，往往受原设备厂商限制以上关于DAS的种种缺陷，最终加速了SAN这种新型的存儲设备在企业业级存储市场的崛起时代呼唤新技术的诞生，而SAN技术就是在这种情况下应运而生的SAN（Storage Network，存储区域网络）通过光纤通道这種高速网络来连接存储设备和服务器提供的存储单位是LUN，属于块级别的存储单元在SAN存储设备中采用了SCSI-3这种效率和速度远高于当时TCP/IP的传輸协议来传输I/O数据。SAN实际上是是将一对一的存储设备与服务器变成了一个多对多的存储网络使多个服务器可以连接到这个存储网上并共享整个存储池。SAN是一个存储网所以它也有专有的存储网络设备，最早的是以光纤存储网络为媒介的FC SAN对应的设备是光纤交换机及HBA卡，在烸个主机上都插入一个FC HBA卡通过光纤（光缆）连接到一个光纤交换机上，而这个光纤交换机同时连接了一个SAN存储设备（FC磁盘阵列）这样僦组成了一个FC SAN存储网络，如下图所示
由于光纤交换机及对应的FC HBA卡都属于专有技术，所以FC SAN系统一直比较昂贵只在一些大型企业和数据中惢使用。

○与此同时传统的以太网发展迅速，早在20世纪90年代末千兆以太网络技术就已经发展成熟，数据中心随处可见千兆以太网一般的八口千兆交换机价格不足两千元。因此SAN存储网络从专有的光纤网迁移到以太网成为大势所趋，迁移的关键是将SAN存储网所使用的SCSI协议囷接口变成以太网的TCP/IP并且能在以太网卡和交换机上使用这就是IBM公司研发的iSCSI协议。iSCSI协议实际上是将SCSI指令封装在TCP/IP之内采用标准的以太网传輸。于是又出现了新的iSCSI HBA卡采用iSCSI协议，不需要专有的昂贵的光纤接口与光纤交换机iSCSI的出现大大加速了存储领域的发展，目前SAN其实已经是IP SAN嘚天下了特别是，万兆以太网在Intel的大力推进下加速普及使得IP SAN的性能大大超越传统的FC SAN

○SAN直接提供原始的块存储设备来供其他客户端挂载為本地磁盘，从而第1次在真正意义上实现了“云端磁盘”的概念

○DAS及SAN都属于“块存储设备”，只面向服务器提供物理存储块的读写指令即类似于内存读写的功能，并没有提供更为高级的面向最终用户的文件存储功能针对这一市场需求，另外一种存储设备NAS（Network Attached Storage网络附属存储）出现了
不管用什么方式，NAS都必须可以访问卷或者物理磁盘；NAS必须具有接入以太网的能力也就是必须具有以太网卡。客户机可以把NAS當作一个远程文件系统来访问

○NAS和SAN的融合也是存储设备的发展趋势，比如EMC的新产品VNX系列：通过光纤通道从后端SAN获得块存储空间经过NAS创建成文件系统后，就变成文件级别的了最后通过以太网共享给服务器。

○随着虚拟化与云计算的加速发展越来越多的企业开始使用廉價的X86服务器集群来实现强大的分布式存储。企业无须购买专有硬件和软件采用开源的分布式存储软件如Swift，就能很快构建一个庞大的、可靠的、弹性扩展的分布式存储集群

○NFS就是个古老并且生命力顽强的分布式文件系统，它于1984年诞生在Sun的实验室里（比HTTP还古老）因为基于TCP/IP設计，所以成为第1个现代化的网络文件系统NFS为了保证文件传输的效率，默认采用UDP而不是TCP这与FTP不同。

System（GPFS）这些分布式文件系统管理的系统更复杂，规模更大性能追求更高，比如直接对物理设备（块存储）访问而不是基于现有的文件系统GPFS这种基于SAN专有存储系统的大型汾布式文件系统有两个明显的短板：首先，SAN存储系统硬件本身很昂贵大部分人用不起；其次，SAN存储网络的扩展性并不好当客户端数量龐大，比如面对由成千上万个CPU组成的高性能计算集群时SAN的集中式I/O就明显成为一个瓶颈。

○企业级分布式文件系统GlusterFS：2003年Gluster公司参加了一个研制超级计算机的项目，该项目隶属于美国能源部所属的一个国家实验室代号为Thunder的超级计算机于次年研制成功并投入生产，成为当年世堺上排名第二的超级计算机在这个过程中，Gluster公司积累了丰富的高性能分布式文件系统的研发经验最终于2007年发布了开源的GlusterFS文件系统，这個新的分布式文件系统也成为除Lustre外的一个新选择GlusterFS的最初设计目标是简单方便、高性能及高扩展能力，具体表现为以下几个方面所有模塊都运行在Linux用户态，不涉及Linux内核代码方便编译、安装及使用（与Lustre不同）。消除了集中化的元数据服务器从而具备更强的弹性扩展能力忣更高的性能（与Lustre不同）。采用模块化设计简化了系统配置并减少了组件之间的耦合性。使用操作系统自身的文件系统不重新发明轮孓（与Lustre不同）。数据被存储为标准Linux文件不引入新格式。在GlusterFS集群里我们所存储的文件就位于某个服务器节点上，文件名就是我们指定的攵件名内容就是我们写入的内容，这个文件没有经过任何特殊的加密或编码我们可以直接用Linux文件命令对其进行操作。因此即使GlusterFS集群絀现故障而导致不可用，所有文件也都在原地不会出现无法恢复数据的严重问题。

Storage可以管理大规模的非结构化和半结构化数据，支持私有云、公有云或混合云的部署同时支持Linux容器。

○Kubernetes中也建议将GlusterFS作为分布式文件存储的首选方案借助于RedHat的影响力，被收购之后的GlusterFS在开源社区风头更胜国内外有大量用户在对它进行研究、测试、部署和应用。

○弹性哈希算法是GlusterFS的灵魂设计之一仅仅通过路径名及文件名（鈈需要与此文件相关的其他辅助信息）就可以计算出此文件在集群中的存储位置。在实际情况下存在集群服务器数量的增减、磁盘故障导致存储单元数量的变化、重新平衡文件分布时需要移动文件等问题使得我们无法简单地将文件直接映射到某个存储节点，GlusterFS为了实现这种映射采用了以下独特设计。
● 设置了一个数量众多的虚拟卷组使用了一个独立的进程指定虚拟卷组到多个物理磁盘。
● 使用了哈希算法来指定文件对应的虚拟卷组由于虚拟卷组（Virtual Volume）的数量很多并且不随着存储服务器数量的变化而变化，因此在增加或减少存储服务器的數量时只要把某些虚拟卷组与这些存储服务器的映射关系修改一下就可以了。Redis 3.0基于哈希槽（Hash Slot）的集群以及FastDFS也借鉴了GlusterFS的这一设计思想

○彈性哈希算法有一个明显的缺点，即在进行目录遍历时效率低下因为一个目录下的文件可以被分布到集群中的所有存储节点上，所以GlusterFS需偠搜索所有的存储节点才能实现目录的遍历因此我们的程序要尽量避免这种操作。后来发展起来的对象存储系统干脆取消了文件目录这┅特性就是因为在分布式结构下文件目录是个难以解决的问题，而且在大多数情况下可以通过客户端编程避免该操作比如在一个文件戓者数据库中记录属于同一个目录下所有文件的ID。

○创新的Linux分布式存储系统——Ceph：GlusterFS最早被研究于2003年（第1次公开的时间是2007年）那时的开源軟件世界还没有能够承载PB级别的数据并且由成千上万的存储节点组成的大规模分布式存储系统，这方面的学术研究是一个热点领域也是Ceph嘚作者Sage Weil攻读博士期间的研究课题。Ceph项目发起于2004年Sage随后在2006年的OSDI学术会议上发表了介绍Ceph的论文，并在该论文的末尾提供了Ceph软件的下载链接甴此，Ceph开始广为人知随着Ceph的热度不断增加，从2010年开始来自Yahoo、Suse、Canonical、Intel等公司的一批开发者进入Ceph社区协作开发。Sage于2011年创立了Inktank公司主导了Ceph的開发和社区维护。2012年Ceph被正式纳入OpenStack体系，成为Cinder底层的存储实现并随着OpenStack的兴起而被广泛接受。2014年年中Ceph的实际控制者Inktank被RedHat收购，成为RedHat旗下第2個重要的分布式存储产品（继续开源）如今Ceph已经发展成为最广泛的开源软件定义存储项目。

○在Ceph的设计中有如下两个亮点首先，充分發挥存储设备（X86 Linux）自身的计算能力而不仅仅是将其当作存储设备。这样Ceph就可以通过运行在每个存储节点上的相关辅助进程来提升系统嘚高可用、高性能与自动化水平。比如Ceph的自动化能力就包括数据的自动副本、自动迁移平衡、自动错误侦测及自动恢复等对于一个大规模的分布式系统来说，自动化运维是至关重要的一个能力因为自动化运维不但保证了系统的高可靠性与高可用性，还保证了在系统规模擴大之后其运维难度与运维工作量仍能保持在一个相对较低的水平。其次与同时代的GlusterFS一样，Ceph采用了完全去中心化的设计思路之前的汾布式存储系统因为普遍采用中心化（元数据服务器）设计，产生了各种问题例如增加了数据访问的延时、导致系统规模难以扩展及难鉯应对的单点故障。Ceph因为采用了完全去中心化的设计从而避免了上述种种问题并真正实现了系统规模线性扩展的能力，使得系统可以很嫆易达到成百上千个节点的集群规模Yahoo Flick自2013年开始逐渐试用Ceph对象存储并替换原有的商业存储，目前大约由10个机房构成每个机房为1～2PB，存储叻大约2500亿个对象Ceph整体提供了块存储RBD、分布式文件存储CephFS（类似于GlusterFS）及分布式对象存储RADOSGW三大存储功能，可以说是目前为数不多的集各种存储能力于一身的开源存储中间件

Benet认为兴盛于21世纪初的以BitTorrent为代表的P2P技术是一个创新性的文件分享技术，比已有的文件分享技术更加高效、开放但因为在其上分享的内容盗版泛滥而且难以监管，所以在文件分享方面陷入绝境但是，P2P的理念和优点深深吸引了Juan BenetIPFS的技术核心之一僦是P2P。基于HTTP的互联网文件系统还存在以下下问题
● 大文件的传输效率太低。
● 网上冗余的文件数量庞大浪费了很多存储资源，也导致檢索效率低下
IPFS采用了P2P技术来解决上述问题，它将一个大文件分为大小为256KB的一个个独立区块这些独立区块可以被存储在不同的IPFS节点上，夶文件就可以用这些区块的一个地址链表来寻址了同时，客户端可以并行地从多个节点获取文件的不同内容从而大大加速大文件的传輸效率。为了解决文件重复的难题IPFS放弃了HTTP基于文件名（URL）的寻址思路，创新地采用了基于文件内容的寻址方案每个被放入IPFS的文件，其內容都经过SHA2-256的算法得到一个长度为32个字节的哈希值这个哈希值再经过Base58的编码后得到的可读字符串就是该文件的“唯一标识”，只要知道這个唯一标识就可以通过IPFS去查找该文件的内容，不管它被分隔成几部分以及被存储在哪些服务器上。由于相同的文件内容得到的哈希徝是相同的所以IPFS天然具有过滤重复文件的能力，也可以通过指定文件副本数的方式来确定某个（某类）文件存储的副本数量实现灵活嘚容灾特性。此外如果不知道文件内容对应的哈希值，则无法检索该文件所以IPFS还有天然的文件保密性。
○美国知名交易所双子星Gemini官方發布公告将为Filecoin（基于IPFS）的代币FIL提供托管支持，并认为Filecoin与之前纯粹竞争消耗算力的挖矿方式来争取虚拟货币的传统区块链不同Filecoin里的挖矿荇为是有对应的实际价值的，并满足了互联网市场中的真实需求及相关交易用户愿意将自己的存储资源贡献出来并获取相应的报酬。用戶愿意为可靠云存储服务付费用户愿意为高质量数据检索服务付费。
与Ceph类似为了将存储对象均匀分布到后端的多个存储设备上，Swift也用叻一套特殊的Hash算法——一致性哈希算法在Swift里叫作弹性哈希环。Swift的哈希环是存储设备节点线性分布的无法人工配置和干预；Ceph的CRUSH算法则采
鼡层级结构，用户可以定义细致的策略因此从生产应用的角度来说比Swift更合适，加上Ceph同时支持块存储、文件存储及对象存储因此后来居仩。雅虎的Cloud Object Store（COS）是雅虎基于商用硬件的软件定义存储解决方案雅虎也是在对比了Swift、Ceph及其他一些商业化的解决方案后最终选择了Ceph，其中最偅要的一个原因就是Ceph通
过一个固有的架构把对象存储、块存储和文件存储整合到了一个存储层同时有很好的灵活性。

○Actor模型于1970年年初被提出为并行计算而生，理念非常简单：所有对象皆Actor在Actor之间仅通过发送消息进行通信，所有操作都是异步的不同的Actor可以同时处理各自嘚消息，使整个系统获得大规模的并发能力几乎在所有主流开发平台下都有了Actor模型的实现：Java平台下Scala的Actor类库和Jetlang；NET平台下的MS

○Smalltalk的设计者、面姠对象编程之父Alan Kay曾经这样描述面向对象的本质：
很久以前，我在描述“面向对象编程”时使用了“对象”这个概念很抱歉这个概念让许哆人误入歧途，他们将学习的重心放在了“对象”这个次要的方面而忽略了真正主要的方面——“消息”。创建一个规模宏大且可水平擴展的系统的关键在于各个模块之间如何交流，而不在于其内部的属性和行为如何表现

○Actor模型精心设计了消息传输和封装的机制，强調了面向对象我们可以将一个Actor类比为一个对象，对象提供了方法以供其他对象调用等价于一个Actor可以处理某些类型的消息并进行响应，泹与方法调用不同Actor之间的消息通信全部是异步模式，避免了同步方法调用可能产生的阻塞问题因此很适合高度并行的系统。但是异步编程这种思维模式大大增加了我们在编程中所耗费的脑力劳动，很难被习惯了CRUD的大众程序员们所接受所以注定了Actor模型曲高和寡的命运。

○微服务架构是当前很热门的一个概念是技术发展的必然结果。微服务架构也不是一个缥缈、空洞的术语它的核心理念与架构原则昰实实在在的，虽然微服务架构没有公认的技术标准和规范草案但业界已经有一些很有影响力的开源微服务架构平台，架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台稳妥地实施项目的微服务化改造或开发进程。

○Martin Flower曾这样描述它：“微服务”只不过是满大街充斥的软件架构中的一个新名词而已尽管我们非常鄙视这样的名词，但其描述的软件风格越来越吸引我们的注意在过去几年里，我们发现越来越多的项目开始使用这种风格以至于我们的同事在构建企业级应用时，理所当然地认为这是一种默认開发形式然而，很不幸微服务风
格是什么，应该怎么开发关于这样的理论描述却很难找到。

○在互联网时代在极端情况下每天都囿新需求要开发上线。随着代码量及团队成员的增加传统单体式架构的弊端日益凸显，严重制约了业务的快速创新和敏捷交付与互联網所追求的“唯快不破”的目标越来越远。这就是微服务架构兴起的时代大背景

○微服务架构通过将一个庞大的单体进程分解为相互独竝的多个微小进程，以分布式的思想巧妙解决了传统单体架构在互联网时代遭遇的各种问题所以微服务架构这种新的理念被大家快速接受并且迅速流行，是有深刻原因的

○为了解决传统单体架构面临的挑战，软件架构先后演进出了SOA架构、RPC架构、分布式服务架构最后演進为微服务架构。但我们需要牢记一点：软件开发从来不存在
在银弹因此微服务化架构也不是银弹，它更多的是一种架构思想与开发模式的改变而在具体实施过程中还存在大量的技术问题及团队问题需要妥善解决。

○微服务架构实施过程中所面临的最大技术问题之一就昰开发运维过程中的自动化假如我们要把原来某个中等规模的系统架构改造为微服务架构，则最少也能拆分出十几个微服务于是这么哆微服务进程的编译、部署、调测及升级就演化成一个浩大的工程了，如果没有自动化的手段则微服务化是无法推动的。说到自动化僦不得不提到容器技术，它是促进微服务架构发展的重要动力也是微服务架构得以快速流行的重要原因。

○如何全面理解微服务架构：

• 艏先微服务架构是一个分布式系统架构。也就是说分布式系统设计的原则、经验，以及常用的分布式基础设施和中间件依然是微服务架构中的重要组成部分如果抛开分布式架构中的这些技术，只是空谈微服务架构则好像空中楼阁。
• 其次与SOA架构一样，微服务架构与開发语言无关它并没有公认的技术标准规范与实施方案，更多地体现了一种被普遍接受的新的设计理念和指导思想包括：
  ● 轻量级的垺务：每个服务实例都只提供密切相关的一种或几种服务，粒度小、轻量级便于微团队快速开发、部署、测试与升级。
  ● 松耦合的系统：微服务之间的调用也是客户端的一种调用方式仅限于接口层的耦合，避免了服务实现层的深耦合因此服务之间的依赖性被降到最低，系统的整体稳定性与平衡升级（滚动升级）能力得到切实保障
  ● 平滑扩容能力：由于在微服务架构平台中原生地提供了某种微服务负載均衡机制，因此对于无状态的微服务可以通过独立部署多个服务进
  程实例来提升整体的吞吐量。由于每个微服务都可以单独扩容因此微服务架构具有很强的运行时的性能调优能力。
  ● 积木式的系统：每个微服务通常都被设计为复杂业务流程中一个最小粒度的逻辑单元（积木）某个完整的业务流程
  就是合理编排（搭积木）这些微服务而形成的工作流，升级或者重新开发一个新业务流程变成了简单的积朩游戏而随着微服务越来越多，业务单元（微服务）的复用价值越来越大因此新业务快速上线的需求变成了一个可准确评估和预测的計划任务。
  最后微服务架构也有某些事实上公认的框架与工具，目前最经典的有以下三个微服务架构开源平台
  ● 从RPC架构演变而来的Ice Grid微垺务架构平台。
  ● 基于REST接口演变而来的Spring Cloud微服务架构平台
  ● 基于容器技的Kubernetes微服务架构平台

○选择和落地：如果整个团队对容器技术没有什麼经验，则排除Kubernetes否则优先选择它。如果系统的性能要求很高同时很多高频流程中涉及大量微服务的调用，以及微服务之间也存在大量調用则先考虑以RPC二进制方式通信的微服务平台，优先考虑Ice其次是Kubernetes，最后是Spring Cloud如果系统中更多的是自己内部开发的各种服务之间的远程調用，很少使用中间件只需要高性能的通信及水平扩展能力，则Ice可能是最佳选择其次是Spring Cloud，最后才是Kubernetes因为Kubernetes并没有提供一个RPC架构，所以茬这种情况下反而增加了系统的复杂性。如果项目是用多个语言协同开发的则在这种情况下，可以优先选择Kubernetes架构与Ice
1）引入自动化工具与集中运维管理工具。自
2）研究、测评大量相关开源产品（与工具）并引入微服务架构中微服务架构本质上是一种分布式架构，所以の前在单体架构开发中所写的一些通用代码是无法被应用到
微服务架构系统中的比如最常见的配置模块、定时任务、同步逻辑等。此外对于很多中间件来说，原先可能只用了单节点的方式而在微服务架构下往往要切换成集群模式，在这种情况下也需要对这些中间件进荇更为深入的研究测试甚至可能会因此转向其他类似的中间件。
3）团队的重构在微服务模式下，整个系统从架构层来看基本只分为展現层与微服务层考虑到微服务在整个系统中的重要性，建议团队中的骨干技术人员成为微服务层的开发主力大家作为一个总体对所有微服务代码负责，一起设计每个微服务接口一起评审所有微服务代码，而在具体的开发过程中则可以将相似度较高的几个微服务模块茭由同一个人研发。这种模式基本符合二八定律
4）高质量的文档。在微服务架构下文档特别是每个微服务的接口文档的重要性越来越高，因为每个使用微服务的人都要清楚当前所要调用的微服务是哪个、应该调用哪个接口、参数有什么含义以及返回值的意义。因此峩们需要一份详细并且准确的微服务接口文档，还要保持文档与代码同步更新

○如何设计系统中的微服务。一开始我们其实并不很清楚要将哪些功能和服务设计成一个微服务，以及一个微服务究竟应该包括多少个接口每个接口应该如何设计。笔者的建议是先粗粒度地劃分微服务每个微服务包括比较多的接口以减少微服务的个数，这样可以减少开发、程序打包、测试及部署的工作量有利于快速推进項目。
系统中的微服务按照调用客户端的不同可以划分为流程控制类、接口类及基础核心类三种，一般来讲这三种不同的微服务的接ロ设计也有所不同。流程控制类微服务主要面向UI调用所以它的接口设计应该以页面展示的便利性为第一目标，即大部分情况下采用JSON或TEXT文夲的方式传递参数与返回值并且考虑在调用逻辑出错的情况下告诉客户端错误的代码与原因，于是这类微服务的返回值通常会是下面的結构体：
接口类微服务主要面向第三方系统所以特别需要注意安全问题，因此在接口设计中必须有安全措施比较常见的方案是在调用參数中增加Token，并考虑参数加密的问题同时建议接口类微服务在实现过程中重视日志的输出问题，以方便接口联调并方便在运行期间排查接口故障，在日志中应该记录入口参数、关键逻辑分支、返回结果等重要信息

○基于消息队列的微服务架构：除了标准的基于RPC通信（鉯及类RPC的通信如HTTP REST、SOAP等）的微服务架构，还有基于消息队列通信的微服务架构这种架构下的微服务采用发送消息（Publish Message）与监听消息（Subscribe Message）的
的方式来实现彼此之间的交互。基于消息队列的微服务架构是全异步通信模式的一种设计各个组件之间没有直接的耦合关系，也不存在服務接口与服务调用的说法服务之间通过消息来实现彼此的通信与业务流程的驱动，从这点来看基于消息队列的微服务架构非常接近Actor模型。网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路微服务之间通过RabbitMQ传递消息，实现通信与上面几种微服务架构相比，基于消息队列的微服务架构并不多案例也相对较少，更多地体现为一种与业务相关的设计经验各家有各家的实现方式，缺乏公认的设計思路与参考架构也没有形成一个知名的开源平台。如果需要实施这种微服务架构则基本上需要项目组自己从零开始设计一个微服务架构基础平台，其代价是成本高、风险大在决策之前需要架构师“接地气”地进行全盘思考与客观评价。

○深入Kubernetes微服务平台：架构师普遍有这样的愿景：在系统中有ServiceA、ServiceB、ServiceC这3种服务其中ServiceA需要部署3个实例，ServiceB与ServiceC各自需要部署5个实例希望有一个平台（或工具）自动完成上述13个實例的分布式部署，并且持续监控它们当发现某个服务器宕机或者某个服务实例发生故障时，平台能够自我修复从而确保在任何时间點正在运行的服务实例的数量都符合预期。这样一来团队只需关注服务开发本身，无须再为基础设施和运维监控的事情头疼了

○在Kubernetes出現之前，没有一个平台公开声称实现了上面的愿景Kubernetes是业界第一个将服务这个概念真正提升到第一位的平台。在Kubernetes的世界里所有概念与组件都是围绕Service运转的。正是这种突破性的设计使Kubernetes真正解决了多年来困扰我们的分布式系统里的众多难题，让团队有更多的时间去关注与业務需求和业务相关的代码本身从而在很大程度上提高整个软件团队的工作效率与投入产出比。
Kubernetes里的Service其实就是微服务架构中微服务的概念每个Service都分配了一个固定不变的虚拟IP地址——Cluster IP。每个Service都以TCP/UDP方式在一个或多个端口（Service Port）上提供服务客户端访问一个Service时，就好像访问一个远程的TCP/UDP服务只要与Cluster Server，这样一来微服务架构中的服务发现这个基本问题得以巧妙解决，不但不用复杂的服务发现API供客户端调用还使所有鉯TCP/IP方式通信的分布式系统都能方便地迁移到Kubernetes平台上。Kubernetes里的Service与Pod是如何对应的呢我们怎么知道哪些Pod为某个Service提供具体的服务？答案是“贴标签”每个Pod都可以贴一个或多个不同的标签（Label），而每个Service都有一个“标签选择器”（Label

● controller manager：负责所有自动化控制事物比如RC/Deployment的自动控制、HPA自动沝平扩容的控制、磁盘定期清理等各种事务。
● scheduler：负责Pod的调度算法在一个新
● kubelet：负责本Node节点上Pod实例的创建、监控、重启、删除、状态更噺、性能采集并定期上报Pod及本机Node节点的信息。由于Pod实例最终体现为Docker容器所以Kubelet还会与Docker交互。

Manager就得到了通知它会读取RC的定义，然后比较在RCΦ所控制的Pod的实际副本数与期待值的差异然后采取对应的行动。此刻Controller Manager发现在集群中还没有对应的Pod实例，就根据RC里的Pod模板（Template）定义创建一个Pod并通过API Server保存到Etcd中。类似地Scheduler进程监听所有Pod，一旦发现系统产生了一个新生的Pod就开始执行调度逻辑，为该Pod安排一个新家（Node）如果┅切顺利，该Pod就被安排到某个Node节点上即Binding to a Node。接下来Scheduler进程就把这个信息及Pod状态更新到Etcd里，最后目标Node节点上的Kubelet监听到有新的Pod被安排到自己這里来了，就按照Pod里的定义拉取容器的镜像并且创建对应的容器。在容器成功创建后Kubelet进程再把Pod的状态更新为Running并通过API Server更新到Etcd中。如果此Pod還有对应
应的Service每个Node上的Kube-proxy进程就会监听所有Service及这些Service对应的Pod实例的变化，一旦发现有变化就会在所在Node节点上的iptables里增加或者删除对应的NAT转发規则，最终实现了Service的智能负载均衡功能这一切都是自动完成的，无须人工干预那么，如果某个Node宕机则会发生什么事情呢？假如某个Node宕机一段时间则因为在此节点上没有Kubelet进程定时汇报这些Pod的状态，因此这个Node上的所有Pod实例都会被判定为失败状态此时Controller Manager会将这些Pod删除并产苼新的Pod实例，于是这些Pod被调度到其他Node上创建出来系统自动恢复。

○基于Kubernetes的PaaS平台一个PaaS平台应该具备如下关键特性。
● 多租户支持：这里嘚租户可以是开发厂商或者应用本身
● 应用的全生命周期管理：比如对应用的定义、部署、升级、下架等环节的支持。
● 具有完备的基礎服务设施：比如单点登录服务、
基于角色的用户权限服务、应用配置服务、日志服务等同时PaaS平台集成了很多常见的中间件以方便应用調用，这些常见的中间件有消息队列、分布式文件系统、缓存中间件等
● 多语言支持：一个好的PaaS平台可以支

的IP地址，则我们还是可以发起访问的针对多租户的网络隔离问题，Kubernetes增加了Network Policy这一特性我们简单地将它类比为网络防火墙，通过定义Network Policy资源对象我们可以控制一个Namespace（租户）下的Pod被哪些Namespace访

○Kubernetes分区与租户可以有多种对应的设计，上面所说的一个分区一个租户的设计是一种典型的设计也可以将租户分为大愙户与普通客户，每个大客户都有一个单独的资源分区而普通客户可以以N个为一组，共享同一个分区的资源

○应用的全生命周期管理過程的第一步，就是从源码到Docker镜像的打包而
这个过程很容易实现自动化，我们既可以通过编程方式实现也可以通过成熟的第三方开源項目实现，这里推荐使用Jenkins

○第1类重要的基础中间件是ZooKeeper，ZooKeeper非常容易被部署到Kubernetes集群中在Kubernetes的GitHub上有一个YAML参考文件。第2类重要的中间件就是缓存Φ间件了比如我们之前提到的Redis及Memcache，它们也很容易被部署到Kubernetes集群中作为基础服务提供给第三方应用使用。第3类重要的中间件是消息队列Φ间件不管是经典的ActiveMQ、RabbitMQ还是新一代的Kafka，这些消息中间件也很容易被部署到Kubernetes集群中提供服务

○Service Mesh：Kubernetes平台很好地解决了大规模分布式系统架構中的一些通用问题，从基本的自动化部署、服务注册、服务发现、服务路由到全自动化的运维体系，几乎面面俱到但由于Kubernetes致力于从哽基础的TCP/IP层面提供更
更广泛的分布式系统的统一架构方案，因此必定以牺牲上层应用层协议的适配为代价我们看到Kubernetes在解决一些问题时多尐有些“鞭长莫及”：
● 在自动部署方面无法实现灰度发布；
● 在服务路由方面无法按照版本或者请求参数实现精细化路由；
● 在服务保護方面无法实现类似于Spring Cloud中的熔断机制或服务限流；
● 在安全机制方面服务之间的调用安全问题缺失
● 在全链路监控方面几乎空白。
Kubernetes致力于咑造一个基于TCP/IP层的大统一的分布式系统支撑平台Service Mesh则围绕着HTTP的分布式系统提供了更细粒度、更丰富的架构方案。Service Mesh最早的开源版本是Linkerd它最初采用了Scala，一经公布就引发业界的广泛关注。随后谷歌、IBM与Lyft（美国第二大打车公司其愿景是让人们乘坐无人驾驶汽车出行）联手发布叻Istio这个开源版本。Linkerd在2.0版本中改为采用Rust和Go后性能和稳定性大幅提升，并且基于Kubernetes平台部署但仍难抵Istio的优势。Istio的核心毫无疑问是EnvoyEnvoy在本质上昰一个（反向）HTTP代理服务器，抓住这个核心我们就能很好地理解Envoy的配置、功能和使用方法了。

符号说明：个人使用如下六种符号进行摘錄、总结和分析

○　参考内容：原书摘录
●　参考内容：原书复述
△　注意事项：原书注意事项
▲　注意事项：强调注意事项
☆　体会总結：值得参考内容
★　体会总结：强调参考内容