系统网站架构（淘宝、京东）& 架构师能力

来一张看上去是淘宝的架构的图：

参考地址：http://hellojava.info/?p=520

说几点我认可的地方：

架构需要掌握的点：

通信连接方式：
大量的连接通常会有两种方式：
1. 大量client连一个server
在现如今NonBlocking-IO这么成熟的情况下，一个支持大量client的server已经不那么难写了。
有一个点要特别注意，就是当server挂掉的时候，不能出现所有client都在一个时间点发起重连，那样基本就是灾难。
通常可以采用的方法是client重连前都做随机时间的sleep，另外就是重连的间隔采取避让算法。

2. 一个client连大量的server

高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，
通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。

伸缩性：
伸缩性的问题围绕着以下两种场景在解决：
1. 无状态场景
无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。

2. 有状态场景
所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：
2.1 规则Sharding

2.2 一致性Hash
参考我的另一篇文章：http://www.cnblogs.com/charlesblc/p/6033345.html2.3 Auto Sharding
Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，
而这个通常也就会造成一些限制，这种方案例如HBase。

2.4 Copy
Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，
全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。

稳定性：
1. 无状态场景

2. 有状态场景
全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。

可维护性
整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。

再来一张貌似是京东架构的图：

参考页面地址：http://geek.csdn.net/news/detail/98500

说一下认为其中有道理的地方：

要关注的技术领域，高可用、高并发、分布式，以及一些基础技术、新语言、存储、容器、系统等。

架构于不同系统，不同公司文化，不同公司层次（初建期，发展期，成熟期），都有着不同的定义和理解。

公司初建期：用户服务基础。
公司发展期：用户服务基础，满足高速扩充的业务需求，提纯基础结构。
公司成熟期：用户服务基础，满足业务需求，提纯基础结构，技术驱动衍生新生态系统。

架构又可分：基础架构、系统架构、业务架构、代码架构。优秀的架构特点，简单，易懂，多变，相对灵活（根据系统迭代期、研发理解能力、团队大小取决）。

具备哪些素质才能成为是出色的架构师？
一个出色的架构师，至少有一门用很深的编程语言作为常委语言，一个出色架构师需要突出代码读写能力作为基础。
读代码能力尤为重要，要能结合代码读出业务逻辑，以及里面优秀架构思路，不足之处，读代码同时学习。

学习能力，思维方式：学习技术、框架，不光会用、知其原理、并能举一反三的思维。结合已学到的知识组合创新思维，将繁杂的事，简单化处理。
忍耐能力：作为一个团队技术头头，一般都会有一些孤独感。可能这就是大家常说的技术范。
再就是对于系统改造循序渐近的，得忍受那种全部都重做的冲动,一点一点的进行处理。
重生能力：作为架构师，熟悉自己所在团队和系统是必然的。抽时间让自己跳出原有既定思维和惯性，重新认识自己团队和系统。
沟通能力：需要跟与人打交道，当然需要良好沟通能力了。

别于社交网络、搜索和游戏等网站，电商网站的用户流量有哪些特点？

电商网站流量特点，突发性流量暴增，根本无法精确的预估的量。可能刚开始几万的量，突然几分钟就上到几十、几百、上千万、十倍百倍千倍的往上增。
相比社交、搜索、游戏网站，差异最大点，就在直接牵涉精确的金额的问题。所以对于精准和延时，缓存有一些差异化的。

社交网络：一般延时可做大点，及时性通讯可以端对端。
搜索：一般多级缓存，大多计算好往前推，延时也可做大点，另外搜索本就模糊的匹配，精准性方面要求没那么严格。
游戏网站：大多客户端大型游戏，客户端数据缓存几秒之后再进行传输，或者一些直接本地存数据，后端根服务器交互。
根据上面的比对，还是有比较真实感知到是有差异的。差异点主要集中在于 money 交易这一点上。

高流量、高并发情况下，如何保证整个系统的可靠性和稳定性

高流量、高并发是交易所有系统都面临这样一个问题，记忆深刻的用户刷爆品商品的问题，还有利用软件来刷的。

入口层：过滤掉大部分软件刷的情况，衍生了风控系统，秒杀系统。
应用层: 读写分离、缓存、队列、令牌、系统拆分、隔离、系统升级（可水平扩容方向）。
其他：
时间换空间：降低单次请求时间，这样在单位时间内系统并发就会提升。
空间换时间：拉长整体处理业务时间，换取后台系统容量空间。
可靠性和稳定性：会做一堆的容灾方案，从机房、网络、应用、存储、渠道、业务等多维度容灾。做一堆的降级策略，从流量、应用、渠道、业务 等对多维度做。

每年大型促销、流量、订单量不断翻倍。推动你去做异构、拆分系统、异步、服务化、容灾、降级等等，一堆堆的优化。

关于一些技术框架，实际上最终实现都大同小异，会去了解实现原理，以及做的好的地方，比如Elasticsearch底层用的Lucene。

而Lucene之前用过还专门看过源码，基本都是通的。加入了分布式存储的副本概念，以及sharding子机器并行执行理念，收集结果返回。

再来一张不明所以的图：

再来一张牛逼的图：