后端好书阅读与推荐（续三）

时间 2019-11-21

标签后端好书阅读推荐繁體版

原文原文链接

这里依然记录一下每本书的亮点与本身读书心得和体会，分享并求拍砖。java

实战Java高并发程序设计

实战Java高并发程序设计 (豆瓣) https://book.douban.com/subje...linux

这本书是国产书籍里面质量较高的一本了（不少国产书都是东拼西凑或者敷衍了事），做者从实际出发，结合理论，讲的颇有逻辑，并且还有不少形象的手绘，和那本Java并发编程实战相比更新一些，读起来也更容易一些。nginx

亮点：git

并行不必定是从性能角度考虑，有的时候是天然而然的，好比独立的任务分为不一样的线程更易于理解
同步异步，阻塞非阻塞，并行并发，这几个概念估计不少人都混乱了好久，和做者的观点稍微有点出入，我这里总结一下：同步异步的区别关键在于A对B请求发出后,若是A要等待B的结果那就是同步，若是A直接返回不须要B的结果或者等待B完成后再通知就是异步；阻塞强调的是A请求B事后不能作其它事，只能干等着（自旋或者休眠），非阻塞指的是A在等B的过程当中能够作其它事；并行是真正意义的的多个任务同时执行，并发多是并行，也可能只是多个任务交替执行，可是切换的很快，给咱们形成了并行的“假象”，真实的并行只可能出如今多核cpu上
死锁：是指两个或两个以上的或线程在执行过程当中，因争夺资源而互相等待，都阻塞起来；活锁：是指线程A可使用资源，但它让其余线程先使用资源，线程B也可使用资源，但它也让其余线程先使用资源。这样线程虽然是活跃的，可是啥事也作不了；饥饿：是指若是线程T1占用了资源R，线程T2又请求R，因而T2等待。T3也请求资源R，当T1释放了R上的封锁后，系统首先批准了T3的请求，T2仍然等待。而后T4又请求封锁R，当T3释放了R上的封锁以后，系统又批准了T4的请求...T2一直等待。
并行对于效率的提高主要取决于业务中串行代码的比例和CPU数量，CPU数量越多，串行化代码比例越少，那么多线程的优化方式效果越好
JMM关注原子性（某个操做不能被中断），可见性（一个线程对某变量的修改对另外一个线程立马可见），有序性（CPU为了性能可能指令重排，应用happen-before原则，能保证串行语义一致可是不必定保证多线程之间语义也一致）
类能够经过继承Thread，重写run方法来实现多线程，但考虑到Java是单继承的，继承是一种很宝贵的资源，因此类应该实现Runable接口并重写run方法，并把本身做为构造参数传给Thread类来实现多线程，这种作法也符合Effective Java里面提到的工做单元（Runable）与执行机制（Thread）分离的概念
加锁必定要注意加正确，主要有三种：指定加锁对象，得到该对象的锁才能进入同步区；做用于实例方法，锁加在当前实例上；做用于静态方法，锁加在当前类上。并且要注意多线程的锁必定要是真正的加在同一个对象上，好比程序员
```
Integer i;
   synchronized(i){
       i++;
   }
```
就不正确，由于 Integer 是不变类，在执行++运算的时候其实是建立了新类，因此那个同步块实际上指向了不一样的对象，天然不会正确。事实上这段代码在 IDEA 里面他会提示你 synchronized 加在了非final变量上，均可能产生非预期结果。github
java 内置的线程池很是强大：newSingleThreadExecutor，newFixedThreadPool，newCachedThreadPool，newScheduledThreadPool等等，其核心都是ThreadPoolExecutor实现的，不过是参数不一样。而ThreadPoolExecutor又是能够高度定制的，threadFactory，handler 均可以自定义，实现本身的线程工厂，拒绝策略等。ThreadPoolExecutor能够扩展来实现更丰富的功能，例如监听全部任务的开始结束时间，避免线程池“吃掉异常”。
做者研究了ConcurrentLinkedQueue的源码，发现不用锁而是用CAS来实现多线程安全，代码复杂度高了不少，可是性能却高了不少；其实凡事有得必有失，就像Node同样，异步带来的性能提高是巨大的，可是代码的编写难度也提高了不少。此外做者还分析了java.util.concurrent里面其余的大量的数据结构，如CopyOnWriteArrayList，BlockingQueue，SkipList。这些数据结构都是Java设计者们精心设计的多线程安全数据结构，比传统的多线程安全数据结构性能提高不少
提升锁性能：减少锁持有时间，亦即只在必要的时候加锁；减少锁粒度，亦即缩小加锁范围，好比ConcurrentHashMap不对整个对象加锁而是一段；读写分离锁（ReentrantReadWriteLock）替换独占锁；读写锁的扩展，亦即按照功能分离不一样功能的锁，使用多个ReentrantLock 来表达不一样条件的锁，使之不互相影响，LinkedBlockingQueue就采用了这种思想；锁粗化，若是锁不停地获取释放反而浪费资源，因此把全部的锁整合成一个锁来提升性能，好比虚拟机就会实现这种操做。按我理解，若是锁里面的操做耗时，那么就要细化，给其余线程机会，提升吞吐量，反之就应该粗化，让本身早点执行完毕。
做者总结了一系列多线程相关的设计模式，好比单例模式、不变模式、生产者消费者、介绍了用框架实现的无锁生产者消费者、future模式实现的异步操做、并行流水线和搜索排序计算等等，这些都是咱们业务中经常用到的模式，总结一下，之后运用更加自如

为了体会到本书的点，我写了一些代码。另外AKKA部分我没有看，由于没有用过，即便看了也体会不到精髓，因此暂时先不了解了。web

计算机网络（第5版）

计算机网络（第5版） (豆瓣) https://book.douban.com/subje...docker

这本书当年大二的时候是教材，没意识到它的珍贵，本科毕业的时候竟然拿去卖了，不事后来我又买了回来，好好的读下来，感受对整个计算机网络都有了一个更清晰地概念。固然此书太厚，若非必要，不宜一一细读，挑些重要的基础概念（好比TCP/IP）和现在愈来愈重要的内容（好比CDN）细读，其他看个大概便可。数据库

亮点：

首先讲了计算机网络的重要性（邮件，电子商务，web，在线娱乐游戏，GPS）以及广阔前景（IOT的万物互联，可穿戴计算机），事实上如今的人早就习惯了网络的存在，反而不以为它有那么重要，就像空气同样，可是一旦你把它的做用列出来你就会发现，它是如此的重要，试着想一想，若是没有网络，现代社会怎么运转？
为了下降网络设计的复杂性，绝大多数网络都组织成一个层次栈，每一层都构建于其下一层之上。这种分层的概念在计算机科学中普遍存在，好比面向对象、ADT、信息隐藏等，其根本思想都是提供服务可是隐藏实现。这种分而治之的思想可被咱们借鉴，用来简化架构，逻辑解耦。好比 nginx 处理请求也是分了不一样的阶段，Java 里面的 servlet 也是同样分阶段处理的
数据链路层只关注帧（frame）从一个节点到另外一个节点的传输，是点到点的，而网络层的目的是采用数据报或者虚电路技术将数据包（package）从发送方传输至接收方，中间可能要通过不少点，是处理端到端数据传输的最底层，但仍然是点到点的（由于它必须关心发送方到接收方的中间节点），而传输层是真正的端到端，亦即发送接收方没必要关心传输过程当中有多少个节点，能够认为数据段（segment）是直接从发送方到接收方的。从另外一方面来看，一个数据报在传输过程当中，源/目的IP是不变的（除非NAT），可是源/目的MAC倒是一跳一跳地变化的
拥塞控制和流量控制有很大差别。前者指确保网络可以承载全部到达的流量，是一个全局问题；后者指发送方不会持续以超过接收方能力的速率传输数据，解决这两个问题的最佳解法一般都是主机慢下来
网络层与传输层提供的服务有些相似，那么为何不用一层作完呢？答案就是传输层代码主要运行在用户主机上，网络层主要运行在运营商的路由器上，对于网络层，用户本身有着真正的控制权，能够经过差错控制、顺序控制、流量控制等方式来得到比网络层（尽力而为的服务，无保证）更加可靠的服务；另外一个方面，分层也是解耦的思想体现，只要实现了传输原语，就没必要在意网络层的实现（以太网或者WiMAX）
简单状况下，我发一包，你回一包，可是网络不佳的状况下，要保证包传输到位就必须引入重传机制，重传机制一引入就必须考虑如何解决包重复接受的问题，因此限制了包生存周期（跳计数器），而后经过段序号、日时钟、滑动窗口协议来丢弃已经接受的重复数据包，经过三步握手解决了初始序号得到的问题。这一个出现问题、解决问题、出现新问题、解决新问题的反复的过程体现了协议设计者们的智慧和不屈不挠的毅力，很是值得咱们学习
由“两军对垒”问题引出释放链接的问题，不管怎么确认通讯，也没法百分之百保证对方收到的消息，两次、三次、四次握手其实都是可行的（不必定是无误的），事实上释放链接的四步挥手彻底就是“两军对垒”的一个折中方案，既保证了准确率，又避免了带宽浪费。创建链接的三次握手也一样是一种折中
内容分发不一样于通讯任务，目标主机不重要，重要的是获取了什么内容，获取内容的代价。主要有两个结构，CDN和P2P。CDN采用分发树结构，扩展性很高，实现原理是DNS重定向；P2P把多台计算机（对等节点）的资源集中起来，每台计算机既能够做为服务器向其余计算机提供资源，也能够做为客户端向其余计算机请求资源

本文最大特色就是故事性强，一环扣一环，引人入胜。

Netty实战

Netty实战 (豆瓣) https://book.douban.com/subje...

Netty是网络编程中不可不谈的一个大做，也是许多成功的网络应用的基础设施，本书就从为何是Netty，引导咱们尝试使用，并进行了细致的讲解，为咱们全面的剖析了Netyy这个庞大而精妙的框架，组织得颇有条理。

可是要注意，看本书以前或者说学习Netty以前，务必要对Java IO、NIO、AIO以及Reactor和Proactor的概念有必定的了解，否则就是没学会走先去学跑了。

亮点：

低级别的 API 不只暴露了高级别直接使用的复杂性，并且引入了过度依赖于这项技术所形成的短板。所以，面向对象有一个基本原则：经过抽象来隐藏背后的复杂性。Netty提供了高层次的抽象来简化TCP和UDP服务器的编程，可是你仍然可使用底层地API。(David John Wheeler有一句名言“计算机科学中的任何问题均可以经过加上一层逻辑层来解决”，这个原则在计算机各技术领域被普遍应用)
一个 Netty 的设计的主要目标是促进“关注点分离”：将你的业务逻辑从网络基础设施应用程序中分离
Netty组件说明：BOOTSTRAP启动应用，配置，为应用提供一个容器；Channel是一条通讯信道，相似于socket；ChannelHandler是数据处理的容器，也是咱们要写业务逻辑的地方，也是咱们一般关注最多的地方；ChannelPipeline属于一个Channel，是ChannelHandler链的容器；EventLoop 用于处理 Channel 的 I/O 操做，一个单一的 EventLoop一般会处理多个 Channel事件，一个 EventLoopGroup 能够含有多于一个的 EventLoop；ChannelFuture 的 addListener 方法注册了一个 ChannelFutureListener ，当操做完成时，能够被通知（无论成功与否）。可见，Netty的组件划分真的很细致精小，优势就是模块间易于解耦，模块自己可重用性高，可是也就有点啰嗦，这也是Java自己比较受到诟病的缘由，仍是那句话，凡事有得必有失嘛，它的优势能让你忍受它的缺点就好了
Transport 使用情景：OIO（即老的，最原始的阻塞IO）-在低链接数、须要低延迟时、阻塞时使用；NIO-在高链接数时使用；Local-在同一个JVM内通讯时使用；Embedded-测试ChannelHandler时使用
Netty提出的ByteBuf优于JDK原生的ByteBuffer由于：能够自定义缓冲类型（堆缓冲区，直接缓冲区，复合缓冲区），经过复合缓冲类型实现零拷贝；扩展性好，好比 StringBuilder；不须要调用 flip() 来切换读/写模式；读取和写入索引分开
直接缓冲区”是另外一个 ByteBuf 模式，容许 JVM 经过本地方法调用分配内存，优势：经过免去 socket 发送数据以前，JVM 先将数据从用户区复制到内核区, 提高IO处理速度，直接缓冲区的内容能够驻留在垃圾回收扫描的堆区之外；DirectBuffer 在 -XX:MaxDirectMemorySize=xxM大小限制下, 使用 Heap 以外的内存, GC对此”无能为力”,也就意味着规避了在高负载下频繁的GC过程对应用线程的中断影响
Netty 的使用一个包含 EventLoop 的 EventLoopGroup 为 Channel 的 I/O 和事件服务。EventLoop 建立并分配方式不一样基于传输的实现。异步实现使用只有少数 EventLoop(和Threads)共享于 Channel 之间。这容许最小线程数服务多个 Channel,不须要为他们每一个Channel都有一个专门的 Thread

本书中对于异步同步和阻塞非阻塞的观念有些模糊，请见上面实战Java高并发程序设计一节个人理解，读者能够参考一下，本身取舍。事实上，Java的NIO不是异步的，AIO(或者说NIO2.0)才是，Netty基于NIO(尝试过并抛弃了AIO)，经过本身的封装，实现了从使用者角度看起来的异步。学习Netty还有一个好地方就是官方文档。

分布式java应用

分布式java应用 (豆瓣) https://book.douban.com/subje...

后端要搞得好，不上分布式确定是不行的，由于写个小网站你能够懂点 SSM 或者 Spring Boot 就好了，可是若是要想搭建一个（或者说成为构建过程的一份子）用户成千上万甚至百万、千万、上亿的站点，那就必需要懂分布式了。这本书就能够当作学习分布式的入门书籍。

亮点：

实践是最好的成长，发表是最好的记忆。这句话的确能够放在电脑上当桌面背景
分布式系统通讯底层都依赖于TCP、UDP，可是为了易用性，一般会使用一些更贴近应用层的协议，书中提到了原始的jdk通讯，以及webservice,Mina,实际上还有许多，好比RPC、WebService、RMI、JMS（p2p或者发布订阅）、JNDI等等
网络IO分三类。BIO：用户线程在进行IO操做的时候进行系统调用，阻塞，只有读到（写入）了数据才释放资源；NIO：同步非阻塞IO，用户线程在发起IO操做以后能够当即返回，只有流可读（可写）操做系统才会通知用户线程进行读取（写入），可是用户线程须要不断轮询来请求数据，Linux采用epoll实现；AIO：用户线程发起请求时，由操做系统来进行读取（写入），IO事件就绪的时候，操做系统会通知对应的用户线程来处理，实现真正的异步IO，Windows下IOCP实现了AIO，Linux只有epoll实现模拟实现的AIO。同时，因为服务器的主力是Linux，因此AIO的用处目前不是特别广
BIO对应的是一链接一线程，能够引入线程池来优化，可是一个操做系统线程数量终究有限，因此不可能支撑大量链接数；NIO对应的是一请求一线程，只有某个链接有读写事件时才为其生成一个线程来处理，只有连接数很少或者链接数多且都请求频繁时才没有优点，但实际状况中，服务器一般会支持大量链接数，可是同时发送请求的链接不会太多，因此NIO应用比价普遍；AIO对应一个有效请求一个线程，亦即OS处理IO完毕后再生成用户线程处理，充分调用了OS参与，能够应对链接数多且操做频繁的场景，若是Linux对AIO的支持更好，这个模型可能会流行起来
SOA亦即面向服务的架构，强调系统之间以标准服务的方式进行交互，各系统能够采用不一样的语言、框架来实现，交互则所有采用服务来进行,目前SCA和ESB是主流标准，分别有Tuscany和Mule等经常使用框架实现
调优的步骤：衡量系统现状，设定调优目标，寻找性能瓶颈，性能调优，衡量是否达标，反复进行前面三步直至达标。
之前我对负载均衡的理解仍是停留在引入一个（群）中间节点做为调度者，调度者（硬件或软件）接受请求并转发给实际应用服务器。这实际上叫作中心化负载均衡，书中提到Gossip实现了无中间节点的软件负载均衡其实是一种去中心化传播事件的负载均衡，去掉中心节点后请求响应直接进行加快了速度，并且能避免调度者单点故障问题。最高级别的负载均衡是全局负载均衡，实现不一样地域机房的负载均衡，既能够避免单点故障还能够就近响应，提升访问速度，实现高可用，通常由硬件GSLB实现（在合肥 ping 了一下 qq.com 获得的结果是深圳的，在天津获得的结果就是北京的，虽然不必定，可是看得出来有差异），可是多机房的一致性很难保证，一般都要用消息中间件来实现
除了上面提到的机房等硬件上的故障，应用软件自己的故障也是高可用的大敌，因此要注意避免故障，及时发现并处理故障，具体包括：明确使用场景，作到最贴近场景的最简单系统，或者分阶段最简单系统；设计可容错系统，fail fast；系统可自我保护，对第三方依赖保持弱依赖，避免连锁失效；创建分级报警系统和日志记录与分析系统；注意总结故障分析便于下次快速利用，这也是架构即将来里面提到过的；按照业务拆分子系统......
构建可伸缩的系统关键在于水平伸缩，由于垂直伸缩是有限的（一台机器的性能终究有限），而水平伸缩理论上是无限的（能够添加“无数”台机器），水平伸缩一般经过SNA(share nothing architecture)实现，亦即应用系统之间不共享状态，把状态信息统一放入缓存或数据库（能够是分布式）。文件系统的水平扩展思想也是相似的

本书能够当作入门书籍，可是书中真正关于分布式的内容彷佛少了些，却是Java基础知识占据了很大篇幅，感受有点不对题目，毕竟要看这些知识我能够看Java核心技术，Java并发编程实战或者深刻理解jvm啊，可是也能够用来复习一下，并且有许多实验数据可供参考，仍是能够的。

PS:我以前已经看了Netty了，因此书中关于Mina的部分，时间不够我就跳着看了，时间够仍是能够了解一下的，二者对比。

分布式系统概念与设计

分布式系统原书第5版 (豆瓣) https://book.douban.com/subje...

读了上面一本分布式Java，难免对分布式系统想要有一个更全面、更系统的认识，那么这本书就是一本绝佳的书籍。

亮点：

资源共享是构建分布式系统的主要目；并发、缺少全局时钟、故障独立性是其主要特征；处理其构件的异构性、开放性（容许增长或替换组件）、安全性（机密完整可用）、可伸缩性（用户的负载增长时能正常运行的能力）、故障处理、组件并发性、透明性（分布式的组件对外展现为一个总体）、QoS（在传输数据时知足要求的能力）等是其主要挑战
不管是请求-应答（好比http）仍是 RPC 或者 RMI（相似于RPC可是仅限于Java且支持对象概念），收发双发都是双向的（直接通讯），要想解耦收发双方（空间解耦和时间解耦），那么就得用间接通讯：组通讯（广播），发布订阅系统，消息队列，元组空间（生成通讯），分布式共享内存等方式
中间件是一组计算机上的进程或对象，其目的是屏蔽异构性，亦即底层的通信，交互，链接等复杂又通用的功能以服务的形式提供出来，分布式系统应用在交互时，直接使用中间件提供的高层编程抽象便可，实现了简洁的分布式系统应用的通讯和资源共享的支持
套接字（socket）是通讯的抽象，不管是TCP仍是UDP的方式，它提供了进程间通讯的端点，必须和协议，主机地址（分为目的端与源端），端口（分为目的端与源端）绑定起来
RPC的概念表明着分布式计算的重大突破，使得分布式编程和传统编程相似，实现了高级的透明性，这种类似性将传统的过程调用模型扩展到分布式环境中，隐藏了底层分布式环境的重要细节部分，简化了分布式开发
操做系统的任务是提供一个物理层（处理器，内存，硬盘等）之上的面向问题的抽象，例如给程序员提供文件和套接字而不是磁盘块和原始网络访问。操做系统分为网络操做系统（具备内置联网功能，能自主管理本身的资源并网络透明地访问其它一些资源可是不能跨节点管理进程，也就是有多个系统映像）和分布式操做系统（用户没必要关心程序运行的地点和资源位置，能透明的将新的进程调度到合理的节点上，有单一的系统映像），后者几乎没有广泛应用的案例，由于中间件和网络操做系统的结合就能很好的知足用户需求
最重要的两种中间件风格：分布式对象（容许面向对象编程模型开发分布式系统，通讯实体被表示成对象，通讯使用RMI，但也可使用其余的好比分布式事件）；组件（基于对象方法的天然演化，主要克服其限制：隐式依赖，编程复杂性，缺乏关注点分离支持，无部署支持）
面向服务的体系结构（SOA）是一套设计原则，分布式系统用松耦合的服务集开发，服务能被动态发现，能互相通讯并经过编排进行协调从而提供更强的服务。能够基于分布式对象或者组件来实现，但实际中主要经过web服务实现，主要是由于web服务内在的松耦合性（好比无论子系统是CORBA仍是.NET，只要用web服务暴露接口，就能轻易实现集成）

分布式是一门结合计算机网络与操做系统等多种门类的交叉学科，因此这本书也包含了许多这些方面的知识，不失为一种复习的方式。

大型网站系统与Java中间件开发实践

大型网站系统与Java中间件开发实践 (豆瓣) https://book.douban.com/subje...

上面的分布式Java是一本很基础的入门书籍，这本书算是一本更加全面和仔细的书籍，把它没讲到的部分都讲了一些，并且更注重中间件（支撑大型网站关键、必要的技术之一）的讲解。

亮点：

分布式系统中的控制节点协调系统之间的协做，能够用：硬件均衡负载设备（昂贵）、软件方式的透明代理（增长流量、易出现单点失效）、采用名称服务的直连请求（不易单点失效、流量少）、采用规则服务器的直连调用、采用master+worker的架构
从一个最基本、简单、部署在单机上的网站开始，数据量和访问量慢慢上去了，一步步演进：数据库与应用分离到两台服务器；多应用服务器与单数据库，涉及到session问题（sticky、replication、集中存储、cookie Based）；数据库读写分离、引入搜索引擎、引入数据和页面缓存；引入分布式存储系统；数据库垂直拆分（一个业务的数据放到一个专用数据库）、水平拆分（单个表放到两个数据库中）；拆分应用，能够根据业务特性把应用拆开或者走服务化的路，亦即每一个web系统经过不一样的服务来完成特定的业务；引入消息中间件来完成拆分、服务化等目的
大型网站主要用到三类中间件：远过程调用和对象访问中间件（解决分布式下应用互相访问的问题）；消息中间件（解决应用之间消息传递、解耦、异步的问题）；数据访问中间件（解决数据库访问共性的问题）；
服务框架带来的好处：结构上，架构更清晰，底层资源由服务层统一管理，也更利于提升效率；稳定性上，一些散落在多个系统中的代码变成了服务，由专门的团队统一维护，能够提升代码质量，另外一方面因为核心稳定，修改发布次数减小，也提升了稳定性
经过消息中间件，业务系统没必要知道有多少个其余业务系统须要了解某一项业务，只须要把消息发布给消息中间价，消息中间价负责把消息投递给相关的其余业务系统，这样每一个业务系统都能专一本身自己的业务，没必要维护臃肿的依赖关系，达到解耦和消息异步的目的
消息中间件要点：保证业务与发布消息的一致性，通常直接紧挨着写代码就行，出错几率较小，可是对于要保证强一致的系统，须要采用相似于TCP三步握手的方式来保证；解决强依赖关系，尽可能保证中间件的可靠性，最好达到和业务系统自己可靠性相同，从业务数据上能对消息进行补发是最完全的容灾手段；消息模型对消息接受的影响，Queue（点对点）和Topic（发布/订阅）都不能彻底适应集群模式（发送接收方都是集群，要作到不重不漏、互不干扰），解决方法是结合二者使用，集群之间用Topic模型，集群内部用Queue模型；作到持久订阅（除非显示取消订阅，不然即便订阅者宕机了重启后也应该能收到全部消息）
服务框架，数据访问层，消息中间价背后的基础产品就是软负载和配置中心。软负载中心的基本职责有两个：聚合地址信息，将全部方面的地址造成列表供其余方使用；生命周期感知，对服务的上下线自动感知并更新服务地址。软负载中心管理非持久数据，集中配置管理中心管理持久数据
ESI将页面分为相对静态的内容和动态的内容，若是整个页面在服务端渲染的话，能够将相对静态的内容进行缓存，而不是每次都所有从新渲染
在解决具体的问题的时候，彻底从头写代码仍是基于开源代码去发展必定要慎重思考，若是场景相似那么以比较活跃的开源产品为基础并根据本身的场景定制会起到事半功倍的效果，若是没有合适的那就须要从零开始了

京东基础架构建设之路

京东基础架构建设之路（全彩） (豆瓣) https://book.douban.com/subje...

本书主要做者是咱们学校的一位师兄，前不久来学校办了个报告，主要讲了他在京东的基础架构经验，介绍了新的架构从无到有的过程，他们团队的技术如今一年能为京东省了不少亿，这本书里凝聚了他们的技术精华，固然值得咱们去了解一下咯，并且当时的QA环节我提了个问题，主办方就送了这本书，师兄当场亲笔签名，我就更应该把这本书好好研究研究了。

亮点：

跳过虚拟化，直接容器化，结合团队的OpenStack经验，选择OpenStack+Docker的架构，用OpenStack来管理调度Docker容器
建议镜像和根目录只保留只读或者少许读写文件，对于频繁的读写或者大量写的文件尽可能用外挂的volume，规范业务对容器的使用行为
MySQL运维自动化包括：自动备份，包括按时间点精准恢复；自动历史数据转移，将再也不变动的历史数据按期转入大容量分布式存储系统（如HBASE），控制MySQL数据量；自动故障检测与切换，采用Orchestrator做为管理工具；全面容器化，提高MySQL实例交付效率
在故障检测和故障切换的方案中，比较容易想到的就是ZooKeeper的临时节点探测不存活的服务，可是因为须要修改服务端代码，不便于跨机房部署和链接数过多的问题，京东本身开发了分布式探测系统，为了不临时网络不通致使的误判，采起多个探测程序部署到机房的不通机架里，对实例进行分布式投票，只要有一个探测存活就判断为存活的，不然通知故障恢复程序进行主从切换
容器中的数据最原始的是直接使用物理机上的volume来存储，可是这样容器数据就和物理机绑定了，没法实现数据的迁移也没法作到超大容量的存储。京东的ContainerFS就是为容器而生的分布式文件系统，它的每一个volume均可以被一个或者多个容器当作本地文件直接使用，容器之间能够共享数据，支持弹性伸缩、线性扩展
JMQ因为要支撑订单、支付等要求对服务质量要求极其严格的业务，因此必须保证在整个机房都失效的状况下依然能恢复数据，因此采起了一主一从且至少一个备份的架构。主从分布在同一个数据中心，采起同步复制；备份在另外一个数据中心，采起异步复制
分布式服务跟踪系统CallGraph经过核心的调用链(依靠全局惟一的ID实现)的概念能追踪到一次调用的从请求发出到最底层系统的全部环节，便于排查问题，并且具备低侵入性
全链路压测经过全国各个公网节点发来的数据请求来较好地模拟真实用户操做，同时压测会有参数标识，进行真实流量与测试流量的隔离，避免污染生产数据
大型互联网公司的数据中心架构通常都会经历单机房，同城双机房，异地灾备，最后是异地多活的各个阶段。京东目前有三大数据中心，每一个中心都能承担读写业务（这就是异地多活），依据GLSB和HTTPDNS和全国网络质量检测数据来动态优化用户到某个具体中心得到服务，中心之间用专线打通保证数据秒级同步提供低延迟数据最终一致性保障

本书虽然很薄，可是讲述的知识日常咱们可能都用不到（不是谁都有机会接触这么大的规模的集群管理），看的时候要想彻底吸取仍是有些费劲，还得在之后的实践中加以琢磨才行。

Docker进阶与实战

Docker进阶与实战 (豆瓣) https://book.douban.com/subje...

第一本docker书为咱们入门docker提供了很好的途径，这本书为咱们提供了深刻了解整个docker技术栈所须要的更多的知识，好比关键技术原理，高级技巧如安全、测试、集群管理等等。这两本书有重叠，可是后者对前者有许多的补充，利于咱们更好的使用、更好的理解docker。

亮点：

Docker并无传统虚拟化中的Hypervisor层，使用轻量级虚拟化技术，基于Cgroup和Namespace等内核容器技术，与内核深度融合，性能与物理机很是接近。通讯上，Docker不与内核直接通讯，而是经过LibContainer。libContainer是真正意义上的容器引擎，经过clone系统调用直接建立容器（一个新的子进程），经过pivot_root进入容器（新的rootfs），经过cgroupfs控制资源，Docker自己更侧重处理更上层的业务。
Docker主要工做是在LXC（linuxContainer亦即linux内核容器技术）的基础上提供了一些更高级的控制工具，包括：定义镜像格式，包含全部程序和依赖，使得镜像能够跨主机部署，实现了进程沙盒，同时保证程序及其依赖环境的一致性；提供自动构建工具，使得当前机器的配置不会影响镜像构建过程；提供了相似git的版本管理功能，支持镜像版本追踪、校验、回退等功能；经过镜像分层实现组件重用，减少镜像大小，加快构建速度；工具生态链......
虚拟机是硬件级别的虚拟化，利用VT-x、AMD-V等硬件虚拟化技术经过Hypervisor来实现对资源的完全隔离；容器是操做系统级别的虚拟化，利用内核的Cgroup和Namespace等软件实现的特性实现来实现进程隔离，Docker容器与主机共享操做系统内核，不一样容器能够共享部分资源，所以容器更加轻量级，资源消耗更少，启动更快。而虚拟机独占本身的资源，各个虚拟机几乎彻底独立，不存在共享，消耗更多资源，启动也慢
容器技术是一种操做系统级别的虚拟化技术（还有硬件虚拟化、半虚拟化等技术），已经集成进linux内核，是内核提供的原生特性，主要包含Namespace（主要作访问隔离，针对一类资源进行抽象，并将其封装在一块儿供容器使用）和Cgroup（control group，主要作资源控制，将一组进程放进一个控制组，给这个控制组分配指定可用的资源，其原生接口由cgroupfs提供）。可是光有这两个还不够，还须要rootfs(文件系统隔离)和容器引擎（生命周期控制）
Docker引入联合挂载技术（把多个目录挂载到同一目录，对外呈现这些目录的联合）使得镜像分层成为可能，使用git式的管理方式使得基础镜像的重用成为可能
若是你在寻找一个清晰、简单、低耦合、无状态、面向资源的API设计方式，那么RESTFul API就是一种不错的选择，它充分利用了HTTP自己的语义，使你的API更易用更具备扩展性，同时优雅的展现你的资源。Docker API 就是一种 RESTFul API
Cgroup对系统资源的限制已经比较完善了，可是Namespace的隔离还不算很好，好比procfs的不少接口都没隔离，能够经过procfs能够读取和修改宿主系统的相关信息，因此procfs是以只读方式挂载的，还有syslog也是没隔离的。Namespace的隔离不完善，也不太可能完善，这是共享内核固有的缺陷。有许多安全策略被用来保护系统，好比Cgroup限制、容器运行在虚拟机中、镜像签名、日志审计、监控、文件保护
在制做镜像的时候，源码导入有两种策略：静态导入（使用COPY命令直接把代码放入镜像）；动态导入（使用VOLUME命令把代码文件动态挂载到容器）。建议使用两个dockerfile，一个开发版本（dev）用动态挂载，便于随时修改代码，一个发布版本用静态导入，便于减小依赖、到处运行
做者还讲述了怎么参与到docker的开发和维护的过程当中，若是咱们在使用过程当中赶上了问题，去看看源码和社区也是不错的，说不定就能解决

虽然只过去了1年多，可是书中已经有内容过期了，好比不要再安装 docker.io 或者 docker-engine ，而是使用docker-ce （免费版）或者 ee (企业版)。并且，现在 Docker-Compose、Swarm 已经比较成熟了，彻底能够用在生产环境中，固然，（超）大规模的部署最终都得按照本身的业务状况来造轮子，彻底依靠开源的确定是不行的，这样是上面那本书的做者提到过的观点。