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

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

参考地址：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.html 2.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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

 

 

 再来一张不明因此的图：

 

 

再来一张牛逼的图：