人人都是架构师：分布式系统架构落地与瓶颈突破

出版者:电子工业出版社

作者:高翔龙

出品人:博文视点

页数:200

出版时间:2017-5

价格:69

装帧:平装

isbn号码:9787121312380

具体描述

《人人都是架构师：分布式系统架构落地与瓶颈突破》并没有过多渲染系统架构的理论知识，而是切切实实站在开发一线角度，为各位读者诠释了大型网站在架构演变过程中出现一系列技术难题时的解决方案。《人人都是架构师：分布式系统架构落地与瓶颈突破》首先从分布式服务案例开始介绍，重点为大家讲解了大规模服务化场景下企业应该如何实施服务治理；然后在大流量限流/消峰案例中，笔者为大家讲解了应该如何有效地对流量实施管制，避免大流量对系统产生较大冲击，确保核心业务的稳定运行；接着笔者为大家讲解了分布式配置管理服务；之后的几章，笔者不仅为大家讲解了秒杀、限时抢购场景下热点数据的读/写优化案例，还为大家讲解了数据库实施分库分表改造后所带来的一系列影响的解决方案。

《人人都是架构师：分布式系统架构落地与瓶颈突破》适用于任何对分布式系统架构感兴趣的架构师、开发人员以及运维人员。相信阅读《人人都是架构师：分布式系统架构落地与瓶颈突破》你将会有知其然和知其所以然的畅快感。

作者简介

高翔龙

杭州云集微店架构师，基础架构组负责人，负责基础技术平台的架构设计和中间件研发等工作，技术书籍《Java虚拟机精讲》作者，热衷于开源技术，常年游走在Github上。

目录信息

第1章 分布式服务案例 1
1.1 分布式系统的架构演变过程 2
1.1.1 单机系统 3
1.1.2 集群架构 4
1.1.3 拆系统之业务垂直化 6
1.1.4 为什么需要实现服务化架构 8
1.1.5 服务拆分粒度之微服务 10
1.2 系统服务化需求 11
1.2.1 服务化与RPC协议 11
1.2.2 使用阿里分布式服务框架Dubbo实现服务化 12
1.2.3 警惕Dubbo因超时和重试引起的系统雪崩 16
1.2.4 服务治理方案 18
1.2.5 关于服务化后的分布式事务问题 20
1.3 分布式调用跟踪系统需求 21
1.3.1 Google的Dapper论文简介 22
1.3.2 基于Dubbo实现分布式调用跟踪系统方案 25
1.3.3 采样率方案 35
1.4 本章小结 37
第2章 大流量限流/消峰案例 38
2.1 分布式系统为什么需要进行流量管制 39
2.2 限流的具体方案 42
2.2.1 常见的限流算法 43
2.2.2 使用Google的Guava实现平均速率限流 45
2.2.3 使用Nginx实现接入层限流 48
2.2.4 使用计数器算法实现商品抢购限流 49
2.3 基于时间分片的消峰方案 51
2.3.1 活动分时段进行实现消峰 52
2.3.2 通过答题验证实现消峰 52
2.4 异步调用需求 53
2.4.1 使用MQ实现系统之间的解耦 54
2.4.2 使用Apache开源的ActiveMQ实现异步调用 55
2.4.3 使用阿里开源的RocketMQ实现互联网场景下的流量消峰 61
2.4.4 基于MQ方案实现流量消峰的一些典型案例 72
2.5 本章小结 75
第3章 分布式配置管理服务案例 76
3.1 本地配置 77
3.1.1 将配置信息耦合在业务代码中 77
3.1.2 将配置信息配置在配置文件中 79
3.2 集中式资源配置需求 82
3.2.1 分布式一致性协调服务ZooKeeper简介 83
3.2.2 ZooKeeper的下载与集群安装 84
3.2.3 ZooKeeper的基本使用技巧 86
3.2.4 基于ZooKeeper实现分布式配置管理平台方案 87
3.2.5 从配置中心获取Spring的Bean定义实现Bean动态注册 93
3.2.6 容灾方案 95
3.2.7 使用淘宝Diamond实现分布式配置管理服务 96
3.2.8 Diamond与ZooKeeper的细节差异 101
3.2.9 使用百度Disconf实现分布式配置管理服务 102
3.3 本章小结 110
第4章 大促场景下热点数据的读/写优化案例 111
4.1 缓存技术简介 112
4.1.1 使用Ehcache实现数据缓存 114
4.1.2 LocalCache存在的弊端 116
4.1.3 神秘的off-heap技术 117
4.2 高性能分布式缓存Redis简介 120
4.2.1 使用Jedis客户端操作Redis 121
4.2.2 使用Redis集群实现数据水平化存储 122
4.3 同一热卖商品高并发读需求 124
4.3.1 Redis集群多写多读方案 125
4.3.2 保障多写时的数据一致性 126
4.3.3 LocalCache结合Redis集群的多级Cache方案 128
4.3.4 实时热点自动发现方案 130
4.4 同一热卖商品高并发写需求 132
4.4.1 InnoDB行锁引起数据库TPS下降 132
4.4.2 在Redis中扣减热卖商品库存方案 134
4.4.3 热卖商品库存扣减优化方案 138
4.4.4 控制单机并发写流量方案 141
4.4.5 使用阿里开源的AliSQL数据库提升秒杀场景性能 142
4.5 本章小结 148
第5章 数据库分库分表案例 149
5.1 关系型数据库的架构演变 150
5.1.1 数据库读写分离 150
5.1.2 数据库垂直分库 151
5.1.3 数据库水平分库与水平分表 152
5.1.4 MySQL Sharding与MySQL Cluster的区别 153
5.2 Sharding中间件 154
5.2.1 常见的 Sharding中间件对比 155
5.2.2 Shark简介 156
5.2.3 Shark的架构模型 157
5.2.4 使用Shark实现分库分表后的数据路由任务 159
5.2.5 分库分表后所带来的影响 166
5.2.6 多机SequenceID解决方案 167
5.2.7 使用Solr满足多维度的复杂条件查询 170
5.2.8 关于分布式事务 172
5.3 数据库的HA方案 173
5.3.1 基于配置中心实现主从切换 174
5.3.2 基于Keepalived实现主从切换 176
5.3.3 保障主从切换过程中的数据一致性 179
5.4 订单业务冗余表需求 180
5.4.1 冗余表的实现方案 181
5.4.2 保障冗余表的数据一致性 183
5.5 本章小结 186
后记 187
· · · · · · (收起)

读后感

把阿里的中间件粗略的讲一遍（吹牛逼），其他分布式系统相关设计讲的也很肤浅，当故事书随便翻翻就行了，阿里中间件在业内确实知名，但就技术来说，无非就是东拼西凑，想要了解更深层次的理论，还是看经典论文，讲真，谷歌技术领先太多了，不过工程实践方面，可以参考阿里的。...  

大概看了一周的时间，因为正好我们目前在分库分表和服务化遇到一些瓶颈。 我看了一下在第1章中，通过dubbo的filter的方式实现调用链，但是我在GitHub上没有找到分析层，这个还望解决。分库分表是shark中间件，之前了解过，现在可以考虑用起来。 总之这本书感觉还可以，作者的...

把阿里的中间件粗略的讲一遍（吹牛逼），其他分布式系统相关设计讲的也很肤浅，当故事书随便翻翻就行了，阿里中间件在业内确实知名，但就技术来说，无非就是东拼西凑，想要了解更深层次的理论，还是看经典论文，讲真，谷歌技术领先太多了，不过工程实践方面，可以参考阿里的。...  

大概看了一周的时间，因为正好我们目前在分库分表和服务化遇到一些瓶颈。 我看了一下在第1章中，通过dubbo的filter的方式实现调用链，但是我在GitHub上没有找到分析层，这个还望解决。分库分表是shark中间件，之前了解过，现在可以考虑用起来。 总之这本书感觉还可以，作者的...

大概看了一周的时间，因为正好我们目前在分库分表和服务化遇到一些瓶颈。 我看了一下在第1章中，通过dubbo的filter的方式实现调用链，但是我在GitHub上没有找到分析层，这个还望解决。分库分表是shark中间件，之前了解过，现在可以考虑用起来。 总之这本书感觉还可以，作者的...

用户评价

这本书的视角实在是太独特了，它并没有那种高高在上的理论说教，而是实实在在地把“架构师”这个角色拉下了神坛，让它变得触手可及。我记得最清楚的是，作者在描述一个复杂系统重构的章节，他没有直接给出完美的解决方案，而是花了大量篇幅去剖析团队内部的沟通障碍、技术选型过程中的权衡取舍，以及上线后如何面对突如其来的线上故障。那种感觉就像是，你不是在看一本教科书，而是潜入了某个大厂的架构复盘会议现场，听着资深工程师们推心置腹地交流血泪史。特别是关于“技术债务的量化评估”那一段，提供了一套非常实用的框架，让我能更清晰地向业务方解释为什么必须投入资源来偿还那些看似不紧急的隐形成本。这本书最大的价值，在于它构建了一种“以终为始”的思维模式，教会你如何从业务价值出发，而不是仅仅为了技术上的优雅而去设计系统，这对于我这种长期在需求和技术之间拉扯的工程师来说，简直是醍醐灌顶，让我对如何平衡短期交付和长期健康有了全新的认知。

这本书的叙事风格非常接地气，它没有过多使用晦涩难懂的术语，而是倾向于用清晰的类比和流程图来阐述复杂的概念。我特别喜欢它将架构设计比作“盖房子”的比喻，从地基（数据存储）到承重墙（核心服务）再到通风系统（消息队列和缓存），每一个模块都有其不可替代的作用和潜在的薄弱环节。当谈到服务拆分时，作者没有强行推销“微服务至上论”，而是深入分析了单体应用在特定业务场景下可能具有的优势，比如事务一致性的简化和部署的便利性。这种非黑即白的叙事方式，极大地拓宽了我的思维边界。它不是告诉你“应该”怎么做，而是告诉你“在什么情况下，这样做可能更好”，这种基于场景的分析，才是真正有价值的架构经验，让我能更自信地去应对项目初期那种信息不全、需求不断变化的环境。

坦白说，这本书在“如何建立架构师的软技能”这一点上，给我带来了超预期的收获。我们往往把架构师定义为技术能力最强的人，但事实是，架构师的工作有超过一半的时间在与人沟通、说服和管理预期。书中有一章专门探讨了如何有效地进行“跨部门技术方案评审”，它不仅提供了提问的技巧，更重要的是，它指出了评审的目的——达成共识而非赢得辩论。作者分享了如何用数据和图表来构建一个不可辩驳的论点，从而引导利益相关方接受一个更稳健但初期成本更高的技术方案。对于我个人而言，如何清晰地向非技术背景的管理者解释“技术选型背后的商业逻辑”，这本书给出了非常实用的模板和范例，让我在下一次汇报时，能够更有条理、更有说服力地表达我的设计意图，极大地提升了我的职场影响力。

读完这套书，我最大的感受是，终于有人敢于直面分布式系统中最棘手的“脏活累活”了。很多市面上的书籍热衷于介绍最新的云原生技术栈或者微服务的各种“最佳实践”，读起来光鲜亮丽，但真正落地时，你会发现性能瓶颈往往藏在那些不起眼的角落：网络延迟的抖动、序列化反序列化的开销、甚至是数据库连接池的细微配置错误。这本书的后半部分，简直是一部“故障排查宝典”。作者详尽地拆解了几个经典的案例，比如某个高并发场景下的“雪崩效应”是如何一步步被触发的，以及如何通过精细化的限流和降级策略来保证核心链路的存活。我尤其欣赏它在讨论CAP理论时，并没有停留在理论层面，而是结合实际的跨地域部署场景，分析了在不同一致性模型下的具体业务影响和用户心智模型，这使得原本抽象的概念变得有了血有肉，也让我对未来设计SLA（服务等级协议）时有了更明确的指导方针。

这本书的价值在于它的“复盘”和“前瞻”的结合做得非常到位。它没有满足于讲述已经发生的成功案例，而是花了大量篇幅去深入探讨，在当前的架构设计中，哪些地方埋下了未来五年可能爆发的定时炸弹。比如，它对“数据治理”和“元数据管理”的强调，在当前许多企业只顾着堆砌服务而忽略数据血缘的背景下，显得尤为重要。作者通过模拟未来数据量级爆炸后，现有Schema设计带来的查询性能灾难，让我深切体会到“前瞻性设计”的必要性。这种让你在舒适区外感到一丝寒意的洞察力，是判断一本技术书是否真正有深度的标志。它迫使你跳出眼前的CRUD和API接口，去思考更宏观的系统生命周期和组织结构对架构演进的制约，是一部值得反复研读、常看常新的实践指南。

排版需要加强

一般吧，内容太浅

看评论不错，打算购入一本； -------- 2017年十一读完； 没有其他牛鬼蛇神出来一句话点评，加分 逻辑清晰，废话少，加分； 作者的技术栈为 java，因此技术原型有明显站队，这一点不太好，不过好在没有大量篇幅； 第四章和第五章值得反复阅读！！

提供了一些通用的解决方案

一本"套路"书