一个优秀的架构师，抽象思维能力是必不可少的，架构师要善于“店丁解牛”，将实物概念化并归类，比如一个大型网站，你能够迅速根据业务功能的不同，将业务垂直化；

而扎实的技术功底又是架构师能力版图中所占比例最大的一块，因为抽象思维能力是虚的，技术能力是实的，只有做到虚实结合 ，才能够达到“手中无剑，心中有剑”的境界：技术前瞻性是需要架构师凭借自身经验和觉预估当前架构的缺陷会为将来埋下哪些隐患、哪些技术问题是需要在网站发展到一定阶段就必须重构的、哪些技术在未来是趋势，需要提前进行了解和学习的领域知识既要求了架构师的知识广度，又要求了架构师的知识深度，因为架构师的技术能力不能够仅局限在自己所擅长的那一亩三分地；

沟通交流能力其实非常重要，因为大多数情况下，我们都是在与人而非计算机打交道，比如，我们构建的系统先是给人使用的，其次才是让计算机理解。

除此之外，业务的沟通探讨、技术方案的探讨等诸多事项都是人与人面对面的直接沟通交流，如果你不善于沟通，那么如何能够让别人明确你的用意 又如何顺利开展工作呢？

架构师的能力版图

本书主要有五部分组成：

只需要转发关注小编，私信小编“学习”就可以获得！

分布式系统的架构演变过程

在移动互联网的浪潮中，你我正生逢其时地 受着当下，如果你愿意做 只站在风口上 待起飞的猪，那么请认真地问问自己，是否已经准备好了？互联网究是什么？简而言之，互联网诠释的是 种精神，融入了高度开放、分 ，以及自由的精神。如果你想融入这个圈子，那么请务必先舍弃掉与互联网精神背道而驰的陈旧观念和思维，否则你自始至终都只会被孤立在局外。

互联网悄然改变了世界，改变了人们对事务的认知，缩短了人与人之间的距离无论你是否愿意承认，互联网已经完全影响并融入我们的生活中。我们的长辈们，也从早期对新鲜事物的排斥，变成现在的欣然接受，这就是互联网与生俱来的魅力和魔力。

笔者的母亲从来就不是 个喜欢追赶潮流的人，但是她早已智能设备从不离身，每天早上起床的第一 件事情就是拿起智能手机，刷刷朋友圈、 看看时事政治、做回“吃瓜群众”，八卦下娱乐新闻，甚至衣食住行也几乎是通过互联网这个载体键搞定的，如图所示。既然互联网能使我们的生活质量更好，那就请张开双臂紧紧拥抱它。

拥有互联网的生活

大流量限流／消峰案例

天猫、淘宝这种级别的大型互联网电商网站，主要的技术挑战来自于庞大的用户规模所带来的大流量和高并发，在“双 11 ”、“双 12 ”等大促场景下尤为明显。

如果不对流量进行合理管制，肆意放任大流量冲击系统，那么将导致 系列的问题出现，比如一些可用的连接资源被耗尽、分布式缓存的容量被撑爆、数据库吞吐量降低，最终必然会导致系统产生雪崩效应。当然，应对大流量和高并发也没有大家想象得那么复杂和神秘。

一般来说，大型互联网站通常采用的做法是通过扩容、动静分离、缓存、服务降级及限流五种常规手段来保护系统的稳定运行。

不同的企业可能会采用不同的解决方案来应对大流量和高并发，因为不同业务之间存在的差异性决定了不会诞生通用的解决方案，所谓条条大路通罗马，只要能够换取同质性的结果，过程如何就显得不是特别重要，这就好比如果能够提前知道罗马的具体位置，那么处处都是路，怎么走都行。

本章的重点是流量管制，只要我们能够采用合理且有效的方式管制住用户流量 让其有秩序地对系统进行访问，那么无论是在平时还是在大促的时候，系统都能够稳定运行。需要明确的是，流量管制的目的是保护系统，让系统的负载处于 个比较均衡的水位，而不是刻意为了限流而限流，否则将会严重影响用户体验，得不偿失。

分布式配置管理服务案例

相信大家对配置信息都不会感到陌生，在实际的开发过程中，无论是访问数据库、分布式缓存系统、消息队列，还是通过 Dubbo 框架实现 RPC 调用，都需要提前配置好目标 URL 、账号／密码等信息，因此这类信息也被称为配置信息。在大部分情况下，我们都会选择将相关配置信息配置在配置文件中，当系统启动时，会从指定的目录下进行加载，通过获取配置文件中的配置信息项来完成环境的初始化工作。

除此之外，我们在使用电脑进行办公、娱乐时，也会高频率地与配置信息打交道，比如，通过操作系统的控制面板来设置显示器的分辨率、鼠标的双击速度 ，以及区域和语言设置等，这些都属于配置信息，所以如果你告诉我你从未接触过配置信息，那么我一定会摇摇头对你说这不可能。

大促场景下热点数据的读／写优化案例

在秒杀、限时抢购这种大促场景下，由于峰值流量较大，大量的并发读／写操作一定会导致后端的存储系统产生性能瓶颈。

前面已经讲解过，提升单机处理能力最有效的办法就是采用集群技术对服务器进行扩容，只要系统能够具备良好的伸缩性，那么从理论上来说，其容量便可以是无限的。

在此需要注意 ，大促场景下因热点数据导致的单点瓶颈已经不再是简单地通过横向扩容就能够顺利解决的，尽管对于读操作我们可以将热点数据缓存在分布式缓存中以达到提升系统 QPS 的目的，但是缓存系统的单点容量还是存在上限的 ，因此应对大促场景下的峰值流量仍显得杯水车薪。

除此之外，由于热点数据的写操作无法直接在缓存中完成，那么这必然会引起大量的线程相互竞争 nnoDB 的行锁。并发越大时，等待的线程就越多，这会严重影响数据库的 TPS ，导致 RT 线性上升，最终可能引发系统出现雪崩。

数据库分库分表案例

大型网站几乎时时刻刻都在接受着高并发和海量数据的洗礼，随着用户规模的线性上升，单库的性能瓶颈会逐渐暴露出来，由于数据库的检索效率越来越慢，导致生产环境中产生较多的慢速 SQL。

对于非结构化的数据，可以将其存储在 NoSQL数据库中来提升性能，但是重要的业务数据，仍然要落盘在关系型数据库（如 MySQL数据库）中。

那么如何提升关系型数据库的并行处理能力和检索效率就成为了架构师需要思考和解决的棘手问题，并且单库如果岩机，业务系统也就随之瘫痪了。

因此，在互联网场景下，架构师务必要确保后端存储系统具备高可用性和高性能，为了解决这些问题，目前互联网场景下常见的做法便是对数据库实施分库分表，即Sharding 改造。