《架构解密：从分布式到微服务》经典读后感有感

《架构解密：从分布式到微服务》是一本由Leader-us著作，电子工业出版社出版的平装图书，本书定价：79.00，页数：300，特精心收集的读后感，希望对大家能有帮助。

《架构解密：从分布式到微服务》读后感(一)：分布式架构师需要了解的知识体系

首先我们的技术栈是python,所以起初看的时候有点反感，因为里面的代码讲解是Java.

但是看完第2章之后，慢慢有了继续读下去的兴趣。

第二章讲解了国际骨干网到地市级网的网络联通情况让我了解了整个IDC的布网方案。后面讲到的NIO相关的知识因为用Java代码讲解就草草的略过了

后续讲解了分布式的几大体系：

1.很多分布式系统经常用来做配置存储,选举Master,实现分布式锁的Zookeeper。建议对于很多创业公司经常把服务的IP:Port硬编码到Client的陋习，改成换用Zookeeper，这样对于后续的分布式服务的运营节省很多时间。

2.连接多个服务的RPC，比较了ZeroC Ice,Dubbo,Thrift,grpc的性能，并推荐了ZeroC Ice为首选.我们公司用的是ZeroRPC和Thrift.后续可能会尝试用gRPC,用于构建Go的技术栈。

3.分布式内存缓存：包括单机的Redis,Memcached,以及分布式的SAPHANA,Hazelcast,VoltDB。现在很多创业公司首选的应该还是Redis,Memcached，当想扩充到分布式的内存缓存的时候，我建议用豌豆荚公司开发的基于Redis开源分布式缓存Codis，他的配置相对比较简单，容易扩充，Admin UI也非常有亲和力。讲这个章节的时候笔者还讲解了CPU和内存的体系架构，从SMP到NUMA的演化过程。整本书每个讲解的构造都是类似，先讲解对应技术的演化历史，让读者了解每个技术发展过程中遇到的问题以及解决思路，然后讲解每个技术的使用方法和原理，这应该是每一个架构师需要具备的能力：面对问题如何突围？如何体系化？如何在行业制造影响力，推广新思路，新技术？如何让技术不断更新，不被新技术所代替？做架构如此，做产品也如此。

4.分布式存储：讲解了NFS，ClusterFS，Ceph。除了书籍里提到的几个分布式文件系统外，对于创业公司，可以推荐使用MooseFS，Hadoop的HDFS。

5.分布式计算：讲解了当前比较流行的Storm,Map-Reduce,除此作者应该要补充下Spark。

6.检索系统：Lucene,Solr,ElasticSearch.我推荐大家用ElasticSearch，系统相对于前两者比较完善，非常易于使用，在数据库排行榜里挤进了Top10。

7.消息队列：包括ActiveMQ,RabbitMQ,Kafka。对于RMQ之于Python,现在没有比较好的库直接调用，如果在Python技术栈里用RMQ实现异步队列，最好直接用Celery。现在很多分布式计算系统都用Kafka来做消息的传递。

8.微服务：涉及到当今比较热门的容器技术docker和Kubernetes。docker的出现给了创业公司很大帮助，避免了重新搭建很多部署需要的工具集。如果集群个数超过20台，Kubernetes一定是一个最好的选择（Kubernetes网络隔离功能，希望尽快能完善起来）。

#推荐语#此书推荐给那些希望了解如何搭建分布式系统以及分布式系统需要具备的技术体系。然而分布式技术是一个非常庞大的体系，如果真正要成为优秀的架构师，可能需要精读上面提到的每一层技术相关的更详细的技术书籍，此书只能成为科普读物。

《架构解密：从分布式到微服务》读后感(二)：架构历史have a glance

我读完了，还是想详细给一些阅读感受吧。我是在京东读书上看完的。本书使用Java来论述和示例。

本书这个篇幅，注定不是大而全的一本技术书，适合对象： 1) 身居技术管理高位，个人时间不多，无法深入一线实践，但又想了解技术过程的人看一看。作者还是尝试在很多地方给了勇敢的、深入的评价，字里行间能感受到作者的这种努力。很多人写技术，不敢给评价，都是摆事实，这本书相对来说有自己个人比较鲜明的观点。 2）技术入门书籍。如果你深入做个几个架构项目，想通篇了解一下，那么这本书可以相对把各方面的东西都能给你做一个知识普及，看完有个印象，知道了几个特点和标签，在脑子里大概有了一个轮廓。如果你之前浅显的做过，看完之后，应该能对你自己的总结有一些更好的论述。

我的收获点在于： 1） IDC机房中，由服务器、存储和网络通信等设备产生的功耗约占数据中心机房所需总功耗的50％左右，其中服务器所占的总功耗为40％左右，空调系统的功耗约占数据中心机房所需总功耗的37％左右。 2）ARM架构的成功。看到苹果笔记本刚刚发布，Intel式微。而这本书写于17年，还鼓励大家买arm的股票，这个挺有意思的。 3）双线机房的由来。是因为互通问题。 4）NIO和AIO的架构处理。作者有自己的开发实践，这块讲的比较劲道。 5）命令行和web方式的差异。web方式是界面操作。命令行方式是shell下命令操作。这两种是常见的通用的管理方式。 6）堆外管理内存，要数Hazelcast的典范。 7） VoltDB的这个设计再次验证了靠近数据进行计算的重要性。 8） Replicated ＋ Distributed Volume是最常用的组合，提供分片读取能力、数据一致性、容错性保障。· Replicated ＋Striped Volume可提升大文件的I/O并行能力、数据一致性、容错性保障，特别适合大数据文件计算。 9）Glust而FS、Ceph等分布式存储方案，主要是借用了linux底层的操作系统驱动表，可以模拟linux文件的读写，所以跟操作本地文件效果和方法类似，但体验非常好。 10）actor模型有actmanager来做管理，还可以广播。 ActManage负责创建、启动、停止、管理所有的Actor对象，分配线程给Actor来处理消息。消息可以广播。 11） ThreadPoolExecutor的性能之所以低于ForkJoinPool很多，主要的一个原因是：在高并发情况下多线程锁竞争（来自共享的LinkedBlockingQueue）及由此引发的大量上下文切换，会导致系统并发上不去，而ForkJoinPool的每个工作线程都有自己的任务队列。 12） elasticsearch，为了保证数据最终会持久化保存到磁盘上，可以每1～10分钟自动触发Hard Commit而每秒钟自动触发Soft Commit。Soft Commit也是一把双刃剑，一方面Commit越频繁，查询的实时性越高，但同时增加了Solr的负荷，因为Commit越频繁越会生成小且多的索引段（Segment），于是Solr Merge的行为会更加频繁，在实际项目中建议根据业务的需求和忍受度来确定Soft Commit的频率。 13）schemeless的设计思路，通过自动映射完成。 14） AUTO_ACKNOWLEDGE模式：MQ API自动逐条发送消息回执，开销最大，但可以保证消息逐条传送的可靠性。 · CLIENT_ACKNOWLEDGE 模式：需要客户端自己编程发送回执，如果按批次发送确认，则需要的带宽开销较小，但代价是编程更复杂。 · DUPS_OK_ACKNOWLEDGE模式：无须编程，MQ API会采用某种最佳方式发送回执，开销最小，但代价是消费者可能收到重复的消息。 · NO_ACKNOWLEDGE 模式：不发送回执，因此可以提供最佳性能，代价是可能会丢失消息。 Tomcat的企业版则使用ActiveMQ作为JMS的实现。＂ 15） ActiveMQ、Apollo及HornetQ三大MQ经验与优点的真正下一代开源产品诞生了，它的名字叫作ActiveMQ Artemis。 16）HA方案，就是高可用方案。 17） Exchange的类型有4种：Direct Exchange绑定向发送、Topic Exchange分发订阅、Fanout Exchange广播及Header Exchange。 18） 每个分区的Leader会跟踪与其保持同步的Follower节点，该列表被称为ISR。 19） 对于性能要求不是很高的Java互联网业务平台，采用Spring Cloud是一个门槛相对较低的解决方案。 20） Pod基本上等同于Docker容器，稍有不同的是Pod其实是一组密切捆绑在一起并且“同生共死”的Docker容器。Pod内可以进行进程级的通信。（有点颠覆我的认知） 最典型的例子是Kubenetes Sky DNS Pod，这个Pod里有4个Docker容器。 这组容器共享同一个网络栈与文件系统，相互之间没有隔离，可以直接在进程间通信。 21） Pod可以让开发者将一个或多个容器整体作为一个“原子单元”进行部署。

《架构解密：从分布式到微服务》读后感(三)：不求快，但求坚持到底，系统学习比局部掌握更重要。

寻找最优秀的算法，收获金钱，实现理想。

不求快，但求坚持到底，系统学习比局部掌握更重要。

不怕错，就怕蒙混过关，尝试和出错是学编程的王者之道。

不怕动手，就怕只动眼，原理与实践都重要，技术都是实践和总结出来。

第1章 大话分布式系统

分布式世界是一个很复杂的世界，任何技术都不是孤立存在，任何技术都无法适应所有场景。作为一名分布式系统架构师或资深研发人员，你必须尽可能多地学习与之相关的各种知识，掌握各种技术的演进路线，从一名编程狂人逐渐升级为一名博学的IT专家，实践与理论并行、代码与页码齐飞，唯有如此，你才能更好地成就未来。

一台完整的具备现代计算机4个核心要素（二进制、内存、I/O、计算单元）。

但凡新的学科出现，总有天才人物披荆斩棘地做开路先锋，他们有着常人所不具备的敏锐洞察力和想象力。

图灵划时代的论文《可计算数字及其在判断性问题中的应用》

NASA是目前人气指数第一的云计算平台OpenStack的创始者之一。

精通程序语言、编译器技术、开发工具、Framework及系统架构，并且在每个领域都是顶级专家。

RISC体系结构被X86芯片所挑战，MIPS有可能是起初RISC CPU设计中唯一在21世纪盈利的产品。

30年前，Sun的第5位雇员John Gage提出了云计算的概念——网络即计算机。Gage是加州大学伯克利分校的一位数学讲师，他预言了云计算的出现。

ARM联盟与Intel的路线不同，其经营思路，通过设计低能耗的ARM芯片架构并低价授权众多的制造商去制造。

服务器、存储和网络通信等设备产生的功耗约占数据中心机房所需总功耗的50%左右，其中服务器所占的总功耗为40%左右，空调系统的功耗约占数据中心机房所需总功耗的37%左右。

超级计算机体系结构如下：

1、并行向量处理（PVP）

2、对称式多处理器（SMP）

3、分布式共享内存（DSM）

4、大规模并行处理（MPP）

5、集群式超级计算机

集群系统主要由节点计算机、高速互联网、操作系统、单一系统映像等中间件、并行编程环境和应用程序等部分组成。

云计算的IaaS基础平台OpenStack目前如日中天，惠普高调宣布投入10亿美元启动HP Hellion战略，引得OpenStack之父欣然前往挂帅。IBM、微软、Intel、RedHat、Oracle、惠普、思科及中国的华为、浪潮等纷纷投奔开源OpenStack联盟，这个领域中原先的领导者VMWare、Citrix等也纷纷拥抱开源。

大型机、X86、RISC、ARM、Windows、UNIX、虚拟化、云计算、OpenStack，了解了IBM、惠普、微软、Intel、Google、苹果这些巨头们的恩怨情仇。

一千零一網：網際網路WWW發明人的思想構圖

分布式系统的开国元勋

分布式系统的基石：TCP/IP

第2章 “知识木桶”中的短板——网络基础

在虚拟化、云计算和大数据这些新技术不断涌现的当下，我们忽然发现，原来我们的知识木桶中最短的一块木板就是网络知识。

网络编程始终是分布式软件工程师和架构师的必备高端基础技能之一，而且随着当前大数据和实时计算技术的兴起，高性能RPC框架与网络编程技术再次成为焦点。不管是RPC领域的ZeroC Ice、Thrift，还是经典分布式框架Actor模型中的Akka，或者实时流领域的 Storm、Spark，又或者开源分布式数据库中的Mycat、VoltDB、这些高大上产品的底层通信技术都采用了NIO（非阻塞通信）通信技术。而Java领域里大名鼎鼎的NIO框架——Netty。

难懂的ByteBuffer

Java NIO抛弃了我们所熟悉的Stream、byte[]等数据结构，设计了一个全新的数据结构——ByteBuffer，ByteBuffer的主要使用场景是保存从Socket中读取的输入字节流，并循环利用，一降低GC的压力。

采用堆外内存来存放数据的，因此在访问性能提升的同时带来了复杂的动态内存管理问题。动态内存管理是一项高端编程技术，涵盖了内存分配性能、内存回收、内存碎片化、内存利用率等一系列复杂问题。

ByteBuffer有三种实现方式：

第一种是堆内存储数据的HeapByteBuffer；

第二种是堆外存储数据的DirectByteBuffer；

第三种是文件映射到的MappedByteBuffer。

MappedByteBuffer的主要使用场景有如下两个：

1、基于文件共享的高性能进程间通信（IPC）

2、大文件高性能读写访问

分布式系统的中间件可以划分为如下几个方面：

1、基础设施：如命名服务、RPC框架、消息中间件等。

2、分布式计算：包括定时任务调度、分布式计算框架及正在兴起的流式计算框架。

3、分布式存储：包括分布式内存存储、NoSQL中间件、分布式关系数据库、分布式文件系统等、分布式块存储。

4、特定领域的中间件：如全文检索中间件、负载均衡中间件、日志收集处理的中间件。

第3章 分布式系统的经典基础理论

分布式系统架构的第一原则是不要分布。

分布式系统设计的两大关键目标是性能和容错性。

分布式架构中往往有如下的共性需求：

1、提供集群的集中化的配置管理功能。

2、需要提供简单可靠的集群节点动态发现机制。

3、需要实现简单可靠的节点Leader选举机制。

4、需要提供分布式锁。

互联网中的分布式事务解决方案

1、业务接口整合，避免分布式事务

2、最终一致性方案之eBay模式

eBay是一个最终一致性方案，它主要采用了消息队列来辅助实现事务流程控制，方案的核心是将需要分布式处理的任务通过消息队列的方式来异步执行。

3、X/OpenDTP模型的支付宝的DTS框架

第4章 聊聊RPC

进程间的通信技术

1、管道(Pipe)及有名管道(named pipe)

管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制。

2、套接字socket

3、共享内存

管道用作IPC通信时，以下缺点：

1、只支持单向数据流（双向通信就需要两个管道）

2、匿名管道的缓冲区是有限的（匿名管道存在于内存中，在管道创建时，为缓冲区分配一个页面大小的内存）

3、管道所传送的是无格式的字节流，读出方和写入方必须事先约定好数据的格式。

Linux内核支持多种共享内存的方式：

1、mmap()实现共享内存，当多个程序调用mmap()映射到同一个文件时，它们实际访问的必然是同一个共享内存区域对应的物理页面。

2、Posix共享内存

3、系统共享内存

至今NFS协议就是最早的基于RPC的一个重要案例。

第5章 深入浅析内存

多核CPU与内存共享的问题

多核CPU与内存共享的问题也被称为 Cache一致性问题。在某个数据被某个CPU写入自己的Cache（L1 Cache）以后，其他CPU都应该能看到相同的Cache数据，所以这个问题与分布式Cache保持同步的问题是同一类问题。

来自Intel的MESI协议是目前业界公认的Cache一致性问题的最佳方案，大多数SMP架构都采用了这一方案，虽然该协议是一个CPU内部的协议，但由于它对我们理解内存模型及解决分布式系统中的数据一致性问题有重要的参考价值。

著名的Cache伪共享问题

内存计算技术的前世今生

内存数据库TimesTen是内存数据库领域的佼佼者。

内存数据网格/内存计算网格（In Memory Data grid/In Memory Compute grid，即IMDG/IMCG）的内存计算技术也在独立发展，与内存数据库的不同之处在于，它是一个完全分布式的内存存取系统。

首先，IMDG/IMCG存放在内存中的是序列化对象，它们之间没有依赖关系。

其次，IMDG/IMCG集群还得考虑动态增添主机所带来的复杂问题。

Hazelcast：通过Java实现的开源商业性方案

Terracotta的BigMemory：通过Java实现的开源商业性方案

VMware Pivotal Gemfire：铁道部采用的方案，解决了售票系统瘫痪的历史难题

Apache Ignite：与Hazelcast是老对手，两种都有开源及商业版本

Oracle Coherence：Oracle的商业产品，通过Java实现

Gigaspaces XAP：商业性的整体技术解决方案

JBoss Infinispan：开源方案，通过Java实现，目前可以对接Hadoop和Spark

分布式内存数据库领域的代表作品为VoltDB。VoltDB虽然主要在内存中执行SQL，但它也符合ACID原则，并定期将数据持久化到磁盘中，也存在开源和商业两个不同的版本。

大数据时代，无论是存储还是计算，都已经离不开内存计算技术了，越来越多的新型软件都要高级的内存编程技术。Java在这方面不断前进，如果有志于这方面的研发，则建议你深入学习和掌握Java Unsafe所提供的底层内存控制API的用法。

内存缓存技术分析

缓存的目的是提供高速的数据访问性能，而一旦涉及磁盘I/O操作，则性能必然大打折扣，从而降低缓存的价值。

在有限的存储空间中，究竟哪些数据适合缓存，一般原则是优先考虑缓存符合下述特征的数据：

1、一旦生成就基本不会变的数据。

2、频繁访问的数据（热点数据）。

3、计算代价很大的数据。

缓存淘汰策略

1、Least Frequently Used LFU策略

2、Least Recently Used LRU策略

3、Adaptive Replacement Cache ARC策略

缓存实现的几种方式：

1、进程内缓存

进程缓存是用得最多的一种缓存实现机制，缓存的数据占用进程的内存空间，在这种情况下，缓存数据的访问速度最快，编程也最简单，在极端情况下一个HashTable即可实现目的。进程内缓存的缺点是占用主进程的内存，能缓存的数据量比较有限，而且对于Java来说，比较大的堆内存容易导致GC响应缓慢，从而产生让人意想不到的影响。为了解决这个矛盾，通常有两种做法。

内存结合文件的二级缓存方式，限制缓存使用的内存大小

Java堆外缓存，绕过GC的影响

2、单机版的缓存中间件

3、分布式缓存中间件

学习Memcache的内存管理技术

如何在有限的内存里保存尽可能多的数据，这个问题其实很不好解决。

1、缓存数据的长度无法预估，可能从几十个字节到几十个KB，甚至到几MB

2、需要清除缓存项以释放空间，这个过程会产生内存碎片。

3、动态内存管理的编程很难。

本质上，缓存系统的核心就是一个高效的动态内存管理组件，这个组件精确地控制和管理整个系统的内存，最大可能地提升内存的空间使用率及缓存命中率，从而使得宝贵、有限的服务器内存得以被更高效地利用。

第6章 深入解析分布式存储

OpenStack里最重要、能独立运营并且能赚钱的子系统是分布式对象存储系统Swift。

Docker及Kubernetes容器技术依然需要分布式文件系统来实现批量处理任务中的共享存储问题。

掌握分布式存储相关的知识和技能，对于一名分布式系统架构师来说很重要。

持久化存储作为计算机最重要的外设之一，进化的目标如下：

1、单位体积的存储密度

2、存储容量

3、读写速度

4、存储成本