这本书的创作初衷：
任何一本书，都是一个用于承载和传递知识的载体，读者可以从中探寻自己想要的答案。对我而言，书本就是带我领略奇妙计算机世界的最快途径。之所以想创作一本与大型网站架构相关的书籍，是因为最近几年我在实际的开发过程中经历了太多的技术难题，每当我和我的技术团队尝试解决这些问题之前，都会先尝试从市面上现有的技术书籍中寻求解决方案;但事与愿违，目前市面上高歌架构理论的读物居多，真正讲解大型网站架构解决方案的书籍却寥寥无几。对于这块领域的空白，我想尝试着去创作，把我这些年的经历和经验写出来，让更多人受益，毕竟架构是需要落地的，否则便是一纸空谈。
内容讲解
本书共5章，母一草的内容几乎都是独立的，大家完全可以有选择性地阅读。
第1章大系统小做―—大规模服务化架构
第1章以大规模服务化架构作为全书的开篇，主要介绍了分布式系统架构的演变过程，以及在大规模服务调用场景下，如何实施服务治理。
1.1分布式系统的架构演变过程
互联网悄然改变了世界，改变了人们对事物的认知，缩短了人与人之间的距离。无论你是否愿意承认，互联网已经完全影响并融入我们的生活中。笔者的母亲从来就不是一个喜欢追赶潮流的人，但她早己智能设备从不离身，每天早上起床的第一件事情就是拿起智能手机，刷刷朋友圈、看看时事政治、做回“吃瓜群众”八卦下娱乐新闻，甚至衣食住行也几乎都是通过互联网这个载体一键搞定的，如图1-1所示。既然互联网能够使我们的生活变得更美好，那就请张开双臂紧紧拥抱它。
第2章大促备战核弹——全链路压测
第2章重点介绍了在大促前夕，如何在线上实施全链路压测，以及有指导性地进行容量规划和性能优化，让系统坚如磐石。
2.1为什么要在线上实施全链路压测
在为大家介绍本章主题之前，请大家首先冷静思考下，大促前夕我们需要考虑哪些事情?或者说有哪些事情是必须要做的，尽可能做到心中有数，不打无准备之仗。笔者总结了大促前夕最基本，同时也是最棘手的2项备战任务:
- 评估机器扩容数量，
- 验证系统整体容量是否能够有效支撑所预估的流量峰值。
第3章肖填谷―—流控方案
第3章重点介绍了如何有效地对流量实施管制，若采用合理且有效的方式管制住峰值流量，使其井然有序地对系统进行访问，则在任何情况下，系统就都能稳定运行。
3.1为什么需要限流
在讨论系统为什么需要进行限流之前，我们先来聊一聊生活中那些随处可见的流控场景。笔者的居住地和工作地都在深圳，由于是一线城市，就以出行时乘坐地铁为例。在工作日的上下班高峰期，地铁站可谓人满为患，此期间地铁站的负载压力与春运相比简直是有过之而无不及，原本从站厅到站台最多只需花费5分钟左右的时间，却在地铁安保人员的流量管制下被迫花费20～30分钟才能够顺利进入站台，足足是平时的5倍多，其中的艰辛，相信挤过公交、地铁的同学应该都能够感同身受。
第4章大促抢购核心技术押题——读/写优化方案
第4章重点介绍了在大促抢购的场景下，如何解决高并发度和高并发度等核心技术难题。
4.1缓存技术简介
缓存（Cache）早已不再是一门新鲜的技术，在实际的开发过程中，几乎所有的开发同学都与之打过交道。简而言之，缓存指的是将被频繁访问的热点数据存储在距离计算最近的地方，以方便系统快速做出响应，比如静态资源数据（包括图片、音频、视频、脚本文件及HTML网页等），我们可以缓存在CDN(Content Delivery Network，内容分发网络）上，由于用户的请求并不是落到企业的数据中心，而是请求到离用户最近的ISP（ Internet Service Provider，互联网服务提供商）上，因此可以大幅提升系统整体的响应速度，如图4-1所示。
第5章星罗棋布——分库分表方案
第5章详细地介绍了关系型数据库的架构演变过程，还重点介绍了在实际的订单业务场景下，如何保证数据的最终一致性。
5.1关系数据库的架构演变
在互联网场景下，关于数据库常见的性能瓶颈主要有两个，如下所示:大量的并发读/写操作，导致单库出现难以承受的负载压力;单表存储数据量过大，导致检索效率低下。
需要获取这份《人人都是架构师2.0》版本的小伙伴可以直接转发+关注后私信（学习）即可免费获取
服务治理需求
随着业务复杂度的上升，服务化能够有效帮助企业解决共享业务被重复建设、业务系统水平伸缩，以及大规模业务开发团队协作等问题，那么接下来笔者就会重点为大家讲解大规模服务化场景下企业应该如何实施服务治理。
服务治理之调用链
如图1-21所示，在大规模服务调用场景下，服务之间的依赖关系可谓是错综复杂，甚至连架构师们都无法在短时间内梳理清楚服务之间的依赖关系和调用顺序。
需要获取这份《人人都是架构师2.0》版本的小伙伴可以直接点赞+关注后“加我VX小助理”即可免费获取
来源：oschina
链接：https://my.oschina.net/u/4389867/blog/4692025