后端好书阅读与推荐系列文章:
后端好书阅读与推荐
后端好书阅读与推荐(续)
后端好书阅读与推荐(续二)
后端好书阅读与推荐(续三)
后端好书阅读与推荐(续四)php
这里依然记录一下每本书的亮点与本身读书心得和体会,分享并求拍砖。html
Docker生产环境实践指南
Docker生产环境实践指南 (豆瓣) https://book.douban.com/subje...java
前面docker的基本概念和一些核心原理都看的差很少了,那么如今该关注一下具体的生产环境的使用方法了。node
亮点:nginx
- 在生产环境中运行docker与在其它环境中相比,最主要的差别是须要在其安全性与稳定性上投入更多的注意力
- 书中提到docker 容器与宿主机是经过IPtables实现的nat转换来进行通讯,这点官网有说明 Docker container networking,而后就说了不适宜网络吞吐量有很高要求的应用(可是能够禁用Docker的NAT来提高网络性能),可是docker已经作出了一些努力,效果并不差,见:1,2,3
- 书中对于docker相关常见的概念解释得很是清晰易懂,这一部分尤为适合初学者
- docker生产环境最好的方式是将应用程序及其依赖预先打包成一个镜像,而包含数据库凭证等铭感信息在运行时动态添加(安全起见);常见流程是开发机上打包并推送到仓库,而后服务器从仓库拉取镜像,这种用例简单可是从工做流和安全角度看并不理想,更标准的作法是使用持续集成 / 持续交付系统在应用程序代码或者dockerfile发生变化时自动重新构建镜像
- 实现开发速度和生产环境稳定的方法之一是拥抱简单,亦即系统的每个部分——容器——有且只有一个目标。系统的简单须要设计时遵守以下原则:倾向无状态服务,倾向静态配置,倾向静态的网络布局,区别对待有状态和无状态的服务
- 保持镜像小巧:能够从空的文件系统开始构建,从相似于busybox、aipine这种轻量级操做系统开始构建,若是嫌包少就能够从主流Linux发行版的容器优化版开始构建,最明智的作法是标准化一个特定的镜像版本,并尽量的用于全部容器;尽量减小层数,也就是相关的命令尽可能放到一行,并且下载的内容用完后要在同一行删除;能够使用docker-squash来减少镜像体积
- 存储镜像:开源、公共项目建议存共有仓库;安全性和性能要求较高的存私有仓库;须要定制的使用save / load。此外,不少人可能不知道,DockerHub实际上是提供了自动构建功能的,只要经过WebHook连上Github就行(亲测)
- 一致性是扩展环境和传播知识的关键,因此应该在一个构建系统中构建全部镜像,并且要实现镜像标准化,让全部镜像(尽量)继承于一个标准基础镜像
- AUFS引擎的挂载速度很是快,能很快的建立新容器因此成为了Docker存储引擎的默认解决方案。其性能瓶颈主要在须要写入大文件的场景,所以使用AUFS来存放数据库文件可能不是一个好主意,一样太多的镜像层可能致使文件查找时间过长,因此不要让本身的文件有太多分层。AUFS有一个最大的问题是没有被容纳到Linux主流发行版。事实上,在生产环境选择存储引擎,一个要点是看业务与特性是否吻合,另外一个要点就是选最有把握能稳定运维的工具
- Docker网络实现包含三方面内容,IP分配、域名解析、容器或服务发现,这也是零配置网络的理论基础。零配置网络便是一组在没有人工干预的状况下自动建立和配置一个TCP/IP网络的技术。
- Docker集群之中的服务发现,目前是consul作得最好,能够自定义健康检查机制,不像zookeeper(和TCP会话周期绑定)和etcd(和TTL值挂钩),提供了一个很是完备的服务发现解决方案
本书名副其实,对于在生产环境中使用docker有不错的方向指导意义,固然细节还得本身扣啊。
注意:因为时间缘由,书中有些内容有些过期可是译者给出了注解(可是译者的注解也可能过期呀,因此必定要本身注意跟踪docker的最新变化)git
The Go Programming Language
The Go Programming Language (豆瓣) https://book.douban.com/subje...程序员
为何要了解一下 golang 呢?最明显的缘由就是,这个语言有一款杀手级应用,也就是前面说过不少次的:Docker;并且前一段时间 nodejs 的创始人不是要拥抱 go 语言了吗,做为一个编程语言的创始人转投另外一门语言,仍是很值得了解一下的;最后,对 go 的协程是早有耳闻,传言能够用同步的方式写出异步的代码,轻松实现高并发......github
亮点:golang
- 正如Rob Pike所说,“软件的复杂性是乘法级相关的”,经过增长一个部分的复杂性来修复问题一般将慢慢地增长其余部分的复杂性。经过增长功能和选项和配置是修复问题的最快的途径,可是这很容易让人忘记简洁的内涵,即便从长远来看,简洁依然是好软件的关键因素。秉承着简洁原则,golang没有内置大多数语言都有的隐式转换、宏、异常、继承等等
- 依然是简洁原则的贯彻,golang 不容许 import 没有使用的包,也不能定义没有使用的变量,不然连编译都不能经过。还有左大括号必须和代码在同一行......感受这些强制要求很是有用,多一些标准,少一些歧义,这应该是利于工程化的
- break 和 continue 均可以加label来实现跳出任一循环,这个有点像 goto 语句,这种语句咱们要少用,通常是在编译器生成代码过程使用的
- 并非全部的词法域都显式地对应到由花括弧包含的语句;还有一些隐含的规则。好比for语句建立了两个词法域:花括弧包含的是显式的部分是for的循环体部分词法域,另一个隐式的部分则是循环的初始化部分,好比用于迭代变量i的初始化。隐式的词法域部分的做用域还包含条件测试部分和循环后的迭代部分(i++),固然也包含循环体词法域
- 结构体中的匿名成员是一个比较有意思的特色,能够用来无缝的实现“对象组合”这一需求,组合是 go 实现面向对象编程的核心
- 大部分语言使用固定大小的函数调用栈,常见的大小从64KB到2MB不等。固定大小栈会限制递归的深度,当你用递归处理大量数据时,须要避免栈溢出;除此以外,还会致使安全性问题。与相反,Go语言使用可变栈,栈的大小按需增长(初始时很小)。这使得咱们使用递归时没必要考虑溢出和安全问题
- 在Go中,错误处理有一套独特的编码风格。检查某个子函数是否失败后,咱们一般将处理失败的逻辑代码放在处理成功的代码以前。若是某个错误会致使函数返回,那么成功时的逻辑代码不该放在else语句块中,而应直接放在函数体中。Go中大部分函数的代码结构几乎相同,首先是一系列的初始检查,防止错误发生,以后是函数的实际逻辑
- 当defer语句被执行时,跟在defer后面的函数会被延迟执行。直到包含该defer语句的函数执行完毕时,defer后的函数才会被执行,不论包含defer语句的函数是经过return正常结束,仍是因为panic致使的异常结束。deferred相似于java的finally,可用于保证资源回收、锁释放等
- 看到第八章终于知道传言的大概意思了,只须要在原来同步的调用函数的代码以前加一个 go 关键字,就能新建一个goroutine(能够类比线程,可是有不一样之处),而后主线程就能继续干活而没必要等待函数执行结束了
- 线程和goroutine的区别主要有几方面:goroutine的栈不是固定大小的,通常从2KB开始动态变化,因此能够打开几百上千的goroutine,而线程是固定栈大小,不可能开不少;goroutine由Go调度器进行调度,而不是操做系统,采用m:n模型(最多n个线程执行m个goroutine),因此goroutine的切换代价较小
- 虽然及时修改了一个源文件也要从新编译该文件对应的包及其依赖包,可是go的编译速度很是快,主要有三点缘由:全部导入包开头显示声明,快速找到;禁止环装依赖,能够并发编译;编译后的包记录了包的依赖关系,编译器不须要遍历全部依赖文件只需读取直接导入包的目标文件
- 程序的复杂性是能够控制的,其中两种技术在实践中被证实颇有效:软件正式部署前的代码评审;自动化测试(写一些小的程序用来检测被测试代码的行为和预期的同样)。go test 命令是一个按照必定的约定和组织的测试代码的驱动程序,在*_test.go文件中:测试函数以Test为函数名前缀,用于测试程序的一些逻辑行为,go test命令会调用这些测试函数并报告PASS或FAIL;基准测试函数以Benchmark为函数名前缀,用于衡量函数的性能,go test命令会屡次运行基准函数以计算一个平均的执行时间;示例函数以Example为函数名前缀,提供一个由编译器保证正确性的示例文档
本书名不虚传,对go的基础知识介绍的很详尽,底层原理也稍微有一些涉及,同时还有一些高级的话题好比各类并发、测试等,是一本入门go的好书,看完后对golang就有一个几乎完整的概念了。web
PS:gitbook有对应中文版。
从PAXOS到ZOOKEEPER分布式一致性原理与实践
从Paxos到Zookeeper (豆瓣) https://book.douban.com/subje...
现在搞分布式的彷佛都离不开Zookeeper了,Zookeeper通常是做为分布式的基础设施,仍是颇有必要了解一下的。本书阐释了从集中式到分布式的问题,如何解决,层层递进引入了Zookeeper,而后介绍了应用场景和技术内幕,算是一个很是全面的介绍了,并且做者的思路很是清晰,咱们读起来很流畅,可是书中涉及的一些协议自己是比较复杂的,读起来有些麻烦。
亮点:
- 集中式的系统保证事务的 ACID 相对而言是比较容易的,并且有不少成熟的解决方案。可是根据 CAP 理论:“一个分布式系统系统不可能同时知足一致性、可用性、和分区容错性,最多只能知足两样”,因此分布式系统不大可能严格知足 ACID 的强一致性,而分区容错性 P 是分布式系统自己存在的意义,因此通常设计者就在 A 和 C 之间寻求平衡了,根据 BASE 理论,通常分布式系统都实现以实现最终一致性、保证高可用性为目标。BASE理论不只应用于分布式系统,也普遍应用于现代关系数据库
- 数据的一致性与可用性之间的反复权衡产生了 一系列的一致性协议,最经典莫过于二阶段、三阶段提交协议和Paxos算法了。这三者层层递进,分别解决了前者的一些问题,并各自在不一样的领域被使用
- Zookeeper是一个典型的分布式数据一致性解决方案(工业级产品),致力于提供一个高性能(高吞吐量)、高可用(解决单点问题)、具备严格顺序访问(主要是写)控制能力(实现复杂同步原语)的分布式协调服务。其设计目标:简单的数据模型(树型、共享、内存)、能够构建集群、顺序访问(请求有惟一递增编号)、高性能,能够保证许多一致性特性:顺序一致性、原子性、单一视图、可靠性、实时性。分布式应用程序能够基于它实现数据发布订阅、负载均衡、命名服务、分布式协调通知、集群管理、Master选举、分布式锁和分布式队列等功能
- 做者对ZooKeeper的常见应用场景进行了详尽的描述,很是有借鉴意义,好比:client利用节点建立的API能够建立一个顺序节点,再加上其type就造成了一个全局惟一的ID了,从而实现命名服务;不一样机器经过在同一节点建立临时子节点,并根据其余机器的临时子节点来判断对应的机器是否存活,从而实现心跳检测;经过强一致性的惟一节点保证来实现master选举(谁能创建特定节点谁就是master,其余机器注册watcher,一旦当前master挂了节点删除,就又开始新的选举);经过节点惟一性来实现排它锁、子节点排序来实现共享锁......总而言之,能够在ZooKeeper子节点惟一性上面作不少文章
- 具体使用案例,Canal这款基于Mysql BinLog的增量订阅消费组件使用ZooKeeper来实现Canal Server的主备切换功能,主要原理就是临时节点和节点惟一性;Canal Client利用ZooKeeper来时刻关注Canal Server的变化,进行消费并记录消费点
- 数据模型:由ZNode(称为节点,类型有持久、临时、顺序节点,可组合)层次化组织而构成的树,路径相似于Unix文件系统,每一个ZNode能够存数据、建立子节点(临时节点无子节点);采用版本号以及CAS来实现乐观锁机制;采用ACL来实现细粒度的权限管理;采用一次性、客户端回调串行执行、推拉结合的轻量级watcher来实现时间发布订阅
- Leader选举的原理简单说来就是谁的数据越新,那么其ZXID(事务ID)越大,就越可以保证数据的恢复,就越能成为Leader,对于相同的ZXID,那么SID较大的成为Leader,这个应该没啥特别的缘由,只是做为一种肯定机制。
- Leader是集群中的核心,主要工做:事务请求的惟一调度者和处理者,保证集群事务处理的顺序性;集群内部各个服务的调度者。Follower是集群状态跟随者,主要工做:处理客户端非事务请求,转发事务请求给Leader;参与事务请求Proposal的投票;参与Leader选举。Observer观察集群最新变化状态并同步过来,工做相似于Follower,只是不参与任何投票,一般用于在不影响集群事务处理的状况下提高集群的非事务处理能力
看彻底书再去看看应用案例可能会产生更好的理解。
现代操做系统(原书第4版)
现代操做系统(原书第4版) (豆瓣) https://book.douban.com/subje...
操做系统是咱们一切编程的根基,不了解操做系统就只是“粘贴复制员”而不是“程序员”更别提“工程师”了。这本书既讲到了传统的重点概念:内存、进程、文件、安全等,又讲到了如今普遍应用的虚拟化、云、Linux、Windows等,无愧于“现代操做系统”的名称。
亮点:
- 抽象是管理复杂性的一个关键,好的抽象能够把一个几乎不可能管理的任务划分为两个可管理的部分,其一是抽象的定义与实现,其二是用这些抽象解决问题。操做系统就是把硬件丑陋的接口转换为一个良好、清晰、优雅、一致的抽象。最为人熟知的抽象就是“文件”,它统一了各类格式的数据、各类IO设备对于用户的接口(操做系统3大抽象:文件,进程与线程,地址空间,分别对应磁盘,处理器,内存)。能够把操做系统理解为一个资源管理者,管理硬件资源如何分配给应用程序,让应用程序更好地使用这些资源
- 技术的变化会致使某些思想迅速过期,可是也可能使得另外一种是思想复活,当技术的变化影响了系统内部不一样组件的相对性能之时就更是如此。好比早期计算机指令由硬件直接执行,微程序设计出现后采用解释执行,RISC又采用了直接执行,java又采用了解释执行,这样来回摆动主要是由于执行速度不老是关键因素,还有多是网络延迟。再好比计算服务过期了,可是又以云计算的形式从新流行,因此对待技术要保持客观、辩证的态度,不要由于如今看起来过期就对它唾弃,说不定未来它又能流行起来发挥大的做用
- 有了进程还要线程的缘由:逻辑上,一个应用中自己能够划分为多个活动,一个活动一个线程便于理解;线程更轻量级,容易建立、撤销;若存在大量IO处理,多线程彼此重叠进行是能够提高吞吐量的(若每一个线程都是CPU密集型则不能);多线程能够真正利用多核。
- 都知道java有偏向锁、轻量级锁、重量级锁的升级,实际上操做系统也有相似锁的概念,并且Linux还采起了“Futex”这个方案来结合自旋锁和重量级锁(阻塞)的优势。一个Futex包含两部分:一个内核服务和一个用户库,简单说来就是在用户态建立一个futex同步变量,当有进程要得到锁时,对futex执行"down"操做即原子性的给futex同步变量减1,若是成功便可继续不需进入内核态,不然进入内核态阻塞,这样就大大减小了低竞争时的吞吐量
- 经过交换技术,系统能够同时运行超过实际内存大小的多个进程;现代计算机都使用某种虚拟内存技术,每一个进程地址被分为一样大小的页面(一般四、8KB),能够被放入空闲内存的任何页框内,有多种页面置换算法,实际应用中用的最多的是老化算法和工做集时钟算法;若是在执行过程当中有大小变化的数据结构能够采用分段的方法,可是几乎没有主流的操做系统考虑分段算法
- 文件系统的存储区分配方案有连续文件、链表、文件分配表和iNode。磁盘空间能够经过位图的空闲表来管理。提高文件系统性能的作法有高速缓存、预读取、以及尽量将一个文件的块放在一块儿等方法
- 操做系统除了负责提供抽象还要负责管理全部IO,IO主要有三种方式实现:程序控制IO、中断驱动IO、DMA
- 死锁发生有四个条件:互斥条件、占有和等待条件、不可抢占条件、环路等待;解决办法有四个:鸵鸟对策、死锁检测与恢复、合理资源分配动态避免死锁、经过破坏引发死锁发生的四个必要条件之一来防止死锁发生
- 虚拟化的好处:能够在节省硬件与电力资源的状况下实现强隔离性、使得各个应用程序很容易拥有本身的运行环境、设置检查点和虚拟机迁移比在普通操做系统中容易的多,目前虚拟化最重要的用途就是云
- 编写操做系统不容易,那么从何入手呢?从对外接口开始,三大原则:简单,不是当没什么东西能够添加而是当没什么东西能够减小时才能达到尽善尽美,或者说KISS原则;完备,完事应该简单,可是不能过于简单,必需要能完成用户所需的一切事情;效率,若是功能不能有效实现那就不值得拥有这个功能。这些原则对于咱们全部的系统设计都有借鉴意义
这本书的字真是太多了,也过小了,吐槽一下印刷,此外,内容也很细很全,仍是应该采起先观其大略、使用时细读的策略。
大规模分布式存储系统
大规模分布式存储系统 (豆瓣): https://book.douban.com/subje...
看了许多分布式概念性的书籍,也了解了java中间件、分布式一致性、ZooKeeper做为基础设施等等概念,是时候找个具体的方向了解分布式了,那么这本书就是分布式在存储这一块的具体实战了。本书从概念到实战,讲了分布式文件、键值系统、表格系统、数据库等等,几乎覆盖了全部涉及存储的方向,看完就能对分布式存储有一个较为完整的了解了。
亮点:
- 分布式存储有几个特性:可扩展(容易扩展到几百几千台集群规模,且性能随数量线性增加)、低成本(构建于普通PC机之上)、高性能、易用(提供易用的对外接口);主要挑战在于数据分布均匀、数据一致性、容错性、负载均衡、事务并发与控制、易用性、压缩解压缩;数据分为非结构化数据(图、文)、结构化数据(关系数据库)、半结构化数据(HTML);不一样的存储系统适合不一样的数据类型,分布式文件系统主要存储Blob对象(文档、图片、视频)等非结构化数据和做为其余分布式系统的基础,分布式键值系统存储简单的半结构化数据,分布式表格存储复杂的半结构化数据,分布式数据库存储结构化数据
- 设计网络系统的基本原则是:网络永远是不可靠的,任何一个消息只有收到对方回复后才可认为发送成功,系统设计时老是假设网络将会出现异常并采起相应处理措施(可是咱们必须假设信道是可靠的,否则任何工做于其之上的任何协议都不能是可靠的)
- 分布式系统在CAP理论的C和A之间权衡时能够参照Oracle的DataGuard复制组件的三种模式:最大保护模式(亦即强同步模式,主库先将操做日志同步到至少一个备库才能返回给客户端成功结果),应用于余额等关键记录;最大性能模式(亦即异步复制,主库完成执行就返回客户端,将重作日志以异步的方式复制到备库),应用于用户操做日志等非关键记录;最大可用性模式(上述两种模式的折中,正常状况至关于最大保护模式,当主备之间的网络出现故障切换为最大性能模式),应用于通常记录
- 故障检测能够经过心跳检测来作,这是最原始的想法,可是机器也可能由于太忙,或者与控制节点的网络断掉而没法进行心跳,这种状况下使用时钟同步(须要考虑一个时间提早量,由于时钟并不能严格一致通常都会有小于1秒的微小偏差)加租约(Lease)的形式能够较好地避免这个问题
- 跨机房部署有三种方案:集群总体切换(实际最多见作法,两个机房保持独立,保持相同的副本数,有主备之分(Primary,Secondary),可能强同步或者异步复制),单个集群跨机房(不一样数据分片的主副本位于不一样机房)、Paxos选主副本(每一个数据分片的多个副本构成一个Paxos复制组,自动选举主副本,下降了对总控节点的依赖可是工程复杂度很高)。
- GFS成功的经验代表:单Master的设计是可行的,不只简化了系统,并且能较好地实现一致性。这是一种中心化的架构,是目前互联网的主流架构,而去中心化的Gossip协议虽然借着Cassandra(Amazon的Dynamo的开源实现)大火了一把,可是因为其复杂性与一致性问题实际上分布式系统不多使用
- OceanBase是一款可扩展的关系型数据库(支持强一致性和跨表事务),主要架构份内四部分:RootServer一主一备,主备强同步,负责集群管理,数据分布以及副本管理;UpdateServer一主一备,主备同步模式可配置,接受写操做,而且按期把新数据同步给Chunkserver;ChunkServer存储基线数据,只提供读取服务,并按期接受UpdateServer的数据同步;MergeServer解析用户Mysql兼容请求,将请求转发给对应的ChunkServer和UpdateServer,无状态,相似于网关的做用
- OceanBase写操做强一致性的原理是:UpdateServer将redo日志发送给备机,redo日志写到本地磁盘,redo日志应用到主机内存表,返回客户端成功。这样即便主备机切换也能保证新的主机有之前全部的操做记录而不会丢失,能够经过增长备机数量来提升可用性保证。固然UpdateServer主备同步也支持异步模式,支持最终一致性,通常用来实现异地容灾。此外主备集群也能够实现错峰合并
- OceanBase借助UpdateServer逻辑单点来实现强一致性,那么这个单点会不会成为瓶颈呢?通常来讲,互联网业务读写比都比较高,因此不会成为瓶颈,即便是双十一这种,也能够经过自动冻结内存表转入SSD硬盘、按期合并与分发、旁路导入、多块网卡配置、RAID卡缓存模块、成组提交等优化方式来避免内存、网络、磁盘的瓶颈;经过主备强一致备份策略与实时同步避免单点故障,这样这个单点问题就几乎不存在了
- 列式存储的主要目的有两个:大部分OLAP只须要读取部分列而不是所有列数据,列式存储能够避免读取无用数据;将同一列的数据在物理上存放在一块儿,可以极大的提升数据压缩率
- 大表左链接是互联网的一个常见问题,通常采起引用(多表主键链接)、或者嵌套(主表冗余连表信息),可是这分别只能适应读取次数少、读写比较高的场景,若是读取次数多且读写比不高那么这两种作法就没辙了。OceanBase采用基线数据冗余连表+修改增量合并的方式解决了这个问题
看完这本书是真的颇有收获,对整个分布式架构有了一个完整的了解,从大大的跨机房到一个小小的数据分片副本,从上到下很是清晰。此外最佳实践那一部分也是很赞的,强烈推荐此书。
微服务设计
微服务设计 (豆瓣): https://book.douban.com/subje...
微服务最近两年愈来愈火,其实这并非什么新鲜概念,计算机体系里面早就有单内核与微内核的架构思想了,微服务也是一种相似的思想,可是是处于更高级别的应用架构层(因此计算机领域里面的许多思想是能够相互借鉴的好比抽象、缓存、LRU算法、并行处理等等)。微服务的好处是不少的,单个服务容易开发、理解和维护;容纳异构技术;部署简单、迭代速度快、变化小bug少;弹性、扩展性好等等。本书就带领咱们从建模、集成、测试到部署和监控,全面了解微服务,为进一步学习指引方向。
亮点:
- 微服务是一种分布式系统解决方案,推进细粒度服务的使用,这些小而自治的服务协同工做,都有本身的生命周期,围绕业务领域建模,根据业务的边界来肯定服务的边界,所以也很容易肯定某个功能代码的位置,避免了传统分层架构的许多问题。一个微服务就是一个实体,不一样微服务经过网络通讯互相调用。咱们知道,直接进程内方法调用是很快,可是也意味着两个对象紧密耦合了,经过网络通讯调用虽然慢一些,可是两个对象就松耦合了,能够随时替换掉一个而另外一个彻底不用知道,我以为随着网速愈来愈快,网络通讯代价愈来愈小,微服务的优点将愈来愈明显,直接耦合调用的方式的优点将愈来愈弱
- 架构师就相似于城市规划师应该专一于大方向,只能参与少许细节,须要保证系统能知足当前的需求,还要可以应对未来的变化,以一种演化的方式来进行规划,这是一个很大的标准,从何入手呢?答案是:分区,定好服务边界与交互方式,能够使用限界上下文。演化的方式就是咱们要理解,随着项目发展,服务必定会愈来愈大,咱们要作的就是让架构增量变化,在拆分这件事变得过度昂贵以前进行拆分
- 重用代码可能引入危险,由于咱们可能引入服务之间的耦合。因此虽然咱们要作到DRY原则,可是也要防止过分追求DRY原则带来的系统过分耦合,这是一个比较微妙的话题,要记住,DRY不是意味着避免重复的代码,而是意味着避免系统行为和知识的重复,在微服务内部不要违反DRY,跨服务时能够适当违反来避免服务之间耦合
- 处理跨服务的业务流程时能够选择:编排,一个中心节点调度其余全部服务完成,这样流程很清晰,可是会致使中心节点承担过多,其它服务沦为贫血的基于CURD的服务;协同,相关服务订阅特定的事件,事件由客户端触发以后每一个服务各自完成本身的处理,这样能明显消除耦合,可是就看不到明显的流程图了,并且可能须要跨服务监控,可是整体而言倾向于协同,利大于弊
- 真正的持续集成要理解3个问题:是否天天签入代码到主线?是否有一组测试来验证修改?构件失败事后是否把修复CI当作第一要务?最好是每个微服务都有本身的代码库和CI,只有这样才能真正实现独立部署
- 微服务部署最好采用单主机(能够是物理主机、虚拟机、容器)单服务的方式,这样利于团队自治、服务部署、监控、故障排查、扩展性更好等,可是这个模式会引入大量主机,这就意味着重复劳动会多起来,因此咱们必定要实现自动化(无论什么技术栈都要追求自动化)
- 自动化测试类型分为单元测试、服务测试、用户测试(端到端测试)。其中单元测试是针对一个函数的、面向技术、帮助开发人员快速发现错误和增长重构信心;服务测试针对一系列函数构成的完整服务,提升测试隔离性,帮助快速定位问题;端到端测试包含整个系统,加强咱们发布服务的信心。这三者的比例最好是前者比后者多一个数量级
- 监控当然要看低层指标好比CPU利用率、空闲内存、带宽使用等等,可是这些指标每每太多而带来噪声不利于监控咱们真正关心的行为,因此须要语义监控,亦即准备一些合成数据和事件来观察系统是否按照咱们的指望完成任务,固然这些数据要注意不能和真实生产数据混淆
- 任何组织在设计一套系统时,所交付的方案在结构上都与该组织的沟通结构一致。这被称为康威定律
- 构建分布式系统须要思惟的转变,那就是故障总会出现,不是全部人都须要像Google或者Netflix同样使用ChaosMonkey来模拟故障测试系统的健壮性,可是咱们都须要为各类故障作好准备好比:超时(设置默认超时并记录日志)、断路器(请求失败必定次数后断路器打开,下次快速失败就不用再等待了)、舱壁(服务内外均可以使用,关注点分离,为每一个下游单独准备链接池)、隔离
PS:书中提到了很多参考书,都是能够看看的。
算法(第4版)
算法(第4版) (豆瓣) https://book.douban.com/subje...
本书讲解的算法和数据结构都是咱们必须掌握的,属于入门级知识,可是做者讲的很仔细,颇有趣,没有那么多的数学证实,比《算法导论》读起来跟容易一些,可是做者的观点也都是立得住的,有理有据,值得通看,造成本身对于算法的初步体系。
亮点:
- 本书提供了全部代码还有教学视频,能够辅助学习,网址。我把代码fork了一份,在这
- 本书对算法性能的分析是科学式的,亦即先对性能提出假设,创建数学模型,而后用多种实验验证它们,必要时重复这个过程
- API的目的是将调用和实现分离(模块化编程),能够将API看作调用和实现之间的一份契约,他详细说明了每一个方法的做用,实现的目标就是遵照这份契约。读到这里就有一个感想,咱们程序的进步都是在努力地把人为的契约固化到代码中,减小出错几率。好比程序员之间直接约定不够可靠,那么就经过接口来强制约定;再好比生产与开发环境不容易保持一致,就经过DockerFile来强制约定
- 做者循循善诱,为了给咱们分析算法性能提供动力,讲了一个3-sum问题的逐步优化过程:暴力的3-sum是一个立方级别的算法,先从简单的状况考虑2-sum,经过线性对数级别的排序,而后用对数级别的二分查找一个元素的相反数来进行统计,这个算法就是线性对数级别的,而后天然扩展到3-sum,获得平方对数级别的快速的3-sum,并查集也是相似按部就班的教法
- 初级算法虽然简单,可是它帮咱们创建了一些基本规则,展现了一些性能基准,在某些特殊状况下也是很好的选择,也是开发更强大的算法的基础,因此仍有必要系统的学习它们
- 把排序算法讲了一遍以后,讲到了规约(为了解决某个问题而发明的算法能够解决另外一个问题),好比排序就能够用了解决不少其余问题,通常能将暴力的平方级别解法降低到非暴力的线性对数级别,好比:找出重复元素、排名、优先队列、中位数、第K个最小/大的值(模仿快速排序的partition操做就能达到线性级别)等
- 散列表的意义是在时间与空间之间取得一个平衡,选择适当大小的数组M,既不会由于空链表形成内存浪费也不会由于链表太长而致使查找效率低
- 书中对于图的表述中,深度优先等遍历方式都给出了详细的算法与示例的轨迹图,你想看不懂都难
- 就解决图的连通性问题,理论上来讲,深度优先比union-find(联合查找或者说并查集)更快,可是实际上union-find更快,由于它不须要对图进行预处理,是一种动态的算法(能用接近常数的时间检查两点是否相通,甚至是添加边),而对于已是图的数据类型使用深度优先更快,由于它能利用已知信息
- 用于子串查找的KMP算法的基本思想是,当文本出现不匹配时就能知晓一部分文本内容,能够利用这些信息避免将指针会退到全部这些已知字符以前,亦即充分利用已知信息,这也是插入排序优于选择排序的缘由。KMP主要亮点是提早判断如何从新开始查找,这种判断不须要文本指针i彻底回退,只需根据模式自己信息从新进行比较位置的选择
- 许多问题均可以规约为排序问题(中位数、不一样值统计)、最短路径问题(任务调度、套汇)、最大流量问题(就业安置、网络可靠性)、线性规划(最大流量)
- NP是全部搜索问题(有解且验证解的正确性的时间不会超过输入规模的多项式的问题)的集合;P是可以在多项式时间内解决的全部搜索问题的集合
本书的java基础部分是至关的丰富,学完算法也能够顺带复习一遍java了,很划算 (* ̄︶ ̄)。
还有,本书虽厚,可是必定要看完,这样才有一个完整的体系,而且算法的细节也能掌握了,之因此不采起往常对待大部头的观其大略的方法是由于这是算法,是常常须要咱们实施的领域,和代码编写直接相关(不像操做系统的知识),因此必须掌握细节。能够参见个人另外几篇专门讲算法的博客
Hadoop权威指南
Hadoop权威指南(第3版) (豆瓣): https://book.douban.com/subje...
Hadoop的出现开启了大数据的序幕,到了如今已经成为一个比较完善的生态,服务于云计算与大数据。记得大三的时候学校有免费的云服务器,我申请了5台本身搭建了一个Hadoop集群跑了一下 Hello World 级别的 Word Count,而后就开始期末考试了,没有再继续深刻了解,如今是时候全面的了解一下了,这本书号称权威指南,看它没错。
亮点:
- MapReduce相对于其余系统的优点:比RDBMS更适合一次写入屡次读取的任务,适合批处理任务,是一种线性可伸缩的编程模型;由于尽可能作到数据本地存储,因此比网格计算(带宽限制,只适宜CPU密集型任务)更能处理巨量数据的任务,同时处理CPU密集型任务也不弱;比志愿计算(贡献CPU而非带宽)更可靠,更易实施,更好控制
- HDFS是Hadoop的旗舰级文件系统,可是Hadoop也能集成其它文件系统如S3,HDFS设计要点:超大文件、流式数据访问、商用硬件(零售店可买)、低延迟访问不太适用(HBASE更佳)、大量的小文件、仅支持单用户写入且不能随机写
- 分布式文件系统的块(chunk)抽象有许多好处:一个文件能够大于任意磁盘的容量(由于无需把一个文件存在一个磁盘上);抽象块简化了存储设计(块大小固定,默认64MB磁盘性能越好越大,故每块盘能存多少块是固定的,并且元数据也能够单独管理);适合数据备份,从而提升容错能力和可用性(每一块能够复制到多个机器上,默认是3个,若是块、磁盘或机器发生故障系统会从其余机器读取副本,此过程对用户透明。并且多个副本能够提升读取性能)
- HDFS 有两种节点,一个namenode做为管理者,管理整个文件系统的命名空间,维护整个文件系统树及其文件与目录,同时也记录着每一个文件中各个块所在的数据节点信息,namenode相当重要必须正常运行,因此提供了两种容错机制,实时同步元数据至其它地方和运行辅助namenode;多个datanode做为实际工做者,存储数据块供读写并按期向namenode发送存储的块的列表
- YARN将JobTracker划分为多个职能的实体(资源管理器和应用管理器),改善了经典的MapReduce面临的扩展性问题,实际上比MapReduce更具通常性,MapReduce只是YARN应用的一种形式,有不少其余的YARN应用如分布式shell
- MapReduce提供了计数器(统计无效数据)、排序、链接(join操做,将两个数据集合二为一)、边数据分布(配置额外的只读数据来完成做业)、MapReduce库类等常见功能
- 部署hadoop时典型配置是同一个机架有一些节点,不一样机架经过交换机链接起来的二级网络架构。由于机架内部通讯更快因此必定要把这些配置告诉Hadoop系统,这样分配MapReduce任务时会倾向于机架内节点,节省传输成本,同时HDFS的文件块的3个副本也会尽可能分布在两个机架上
- Pig是一种探索大规模数据集的脚本语言,省去MapReduce繁琐耗时的步骤(写mapper、reducer,代码编译,打包,提交做业),仅需控制台的几行pig Latin代码就能处理TB级别的数据,并且支持更丰富的数据结构
- Hive能把SQL查询转换为一些列运行在Hadoop上运行的MapReduce做业,它把数据组织为表,经过这种方式为HDFS中的数据赋予结构。Hive与传统数据库有不少相似之处(如SQL语言的支持,尤为相似于Mysql),可是其底层依赖于HDFS和MapReduce而非传统的文件系统,Hive采用读时模式(查询时进行模式检查)而非写时模式(写入时检查模式)能够使得数据加载很是迅速,由于他只是移动数据而不须要读取、解析、序列化等。写时模式有利于提高查询性能,由于能够创建索引、数据压缩等,Hive没有考虑过这些特性(以及事务、更新、删除等),由于MapReduce下,全表扫描是常态
- HBASE是在HDFS上开发的面向列[族]的分布式数据库,若是须要实时的访问超大规模的数据集,就能够使用HBASE。与RDBMS相比,HBASE能解决不少伸缩性问题(表能够高达几十亿行,几百万列)、能水平分区并在上千个普通节点上自动复制、线性扩展与新节点自动处理。RDBMS对于中小规模应用提供的易用性、灵活性和完整的功能性是几乎无可取代的,可是要在数据规模和并发读中任意方面向上扩展就会损失不少性能,由于RDBMS是面向行的具备ACID和事务的强一致性等特性,向上扩展意味着要打破这些特性,使得管理变得复杂
- ZooKeeper通常用来构建分布式服务具备许多特性:简单(核心是一个精简的文件系统)、丰富(提供分布式队列、锁、领导选举等功能)、高可用(运行于一组机器,避免单点故障)、松耦合交互(参与者没必要互相了解)、资源库(提供通用协调模式的开源共享库)
本书做为了解Hadoop的设计思想以及关键点的手段,我还没有进入真正的使用,不少代码以及API部分就省略没看了,因此虽然是个大部头,可是看起来并不会特别慢。固然若是真的要使用,书中的接口和代码可能就已通过时了,要搭配最新官方文档来看
HTTP权威指南
HTTP权威指南 (豆瓣): https://book.douban.com/subje...
Http协议构成了当今互联网的基石,不管是浏览网页仍是使用APP都离不开这个协议,很是有必要进行全面的了解。这本书也是一个权威指南,看完就能有一个完整的概念了,并且本书还讲到了许多架构方面的经验,只赚不赔哈哈。
亮点:
- URI 统一资源标识符,在世界范围惟一标志并定位一个信息资源,包含URL和URN;URL 统一资源定位符,描述一台特定服务器上的某特定资源的位置;URN 统一资源名称,做为特定内容的惟一名称而与资源所在地无关(因此资源能够迁移到另外一处而不影响其访问,URL就不行)。如今几乎全部URI都是URL,URN因为架构的缺少(虽然引入了PURL)和巨大的工程变更仍处于试验阶段并未普遍使用
- HTTP延时通常都是由TCP延时形成的(除非是客户端、服务端超载或者处理复杂的动态资源),若是要编写高性能HTTP程序就要考虑许多的TCP层面的问题与解决方案:TCP握手产生的延时对于传输少许的http报文而言是巨大的开销(复用已有TCP链接);延迟确认算法不太适用于HTTP这种双峰特征的请求响应式行为(调整或禁用这个算法);慢启动影响新的Http链接的传输速度(复用链接,持久链接);Nagle算法影响小的Http报文传输(能够禁用该算法,TCP_NODELAY);TIME_WAIT累计与端口耗尽,TIME_WAIT状态会持续2MSL(如120s)的时间才会转换到CLOSE状态,而后才能建立相同IP和端口的链接(服务器端口有限,如60000个),限制了服务器的链接速率(60000/120=500次每秒),能够增长客户端负载生成器的数量或者虚拟IP
- 减小Http链接延时的方法:并行链接(并行执行多个Http事务),管道化链接(经过共享的TCP链接发起请求),复用链接(交替传送请求与响应报文),持久链接(因为站点本地性,http事务结束后没必要立刻释放TCP链接,由于颇有可能立刻又要向该站点发起请求)。其中持久链接与并行链接搭配多是最高效的方式
- web代理链接的是两个使用相同协议的应用,而网关链接的是两个或多个使用不一样协议的端点。因此web代理扮演的是中间人传输者的角色(改善安全性、提升性能,好比完成访问控制、防火墙、匿名者、缓存、反向代理负载均衡、内容路由器、转码器等等),网关扮演的是协议转换器的角色(好比PHP-FPM能把Nginx转发的http请求解析出来而后调用php-cgi来注入参数并执行PHP代码获得结果真后封装为http协议回复给nginx)
- 大规模web爬虫对其访问管理(避免重复)用到了一些技术:树和散列表(加速查找)、有损的位图(url映射成数字,url无限数字有线因此可能有冲突)、检查点(已访问URL存入本地)、分类(集群爬虫经过通信来分配URL,各自爬取部分)、规范化URL、广度优先爬取、节流、限制url大小、黑名单、内容指纹、人工监视等等
- 内容协商技术能够使得服务器把内容的不一样版本发送给对应的用户,主要有3种机制:客户端驱动、服务器驱动、透明。
- 重定向广泛存在,缘由无非:可靠的执行Http事务(备用节点)、最小化时延(就近访问)、节约网络带宽(服务器分散,减小拥塞)。用到的主要技术有:Http重定向、DNS重定向、任播寻址、IP MAC转发、IP地址转发、显示浏览器配置、代理自动配置、web Proxy代理自动发现等等
这本书详细描述了HTTP协议的方方面面,并且给出了许多参考,若是咱们真的要作一个完美的Http应用,仍是值得咱们细细翻阅的。
阅读原文