系统网站架构(淘宝、京东)& 架构师能力
来一张看上去是淘宝的架构的图:
参考地址: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
说一下认为其中有道理的地方:
要关注的技术领域,高可用、高并发、分布式,以及一些基础技术、新语言、存储、容器、系统等。
架构于不同系统,不同公司文化,不同公司层次(初建期,发展期,成熟期),都有着不同的定义和理解。
公司初建期:用户服务基础。
公司发展期:用户服务基础,满足高速扩充的业务需求,提纯基础结构。
公司成熟期:用户服务基础,满足业务需求,提纯基础结构,技术驱动衍生新生态系统。
架构又可分:基础架构、系统架构、业务架构、代码架构。优秀的架构特点,简单,易懂,多变,相对灵活(根据系统迭代期、研发理解能力、团队大小取决)。
具备哪些素质才能成为是出色的架构师?
一个出色的架构师,至少有一门用很深的编程语言作为常委语言,一个出色架构师需要突出代码读写能力作为基础。
读代码能力尤为重要,要能结合代码读出业务逻辑,以及里面优秀架构思路,不足之处,读代码同时学习。
学习能力,思维方式:学习技术、框架,不光会用、知其原理、并能举一反三的思维。结合已学到的知识组合创新思维,将繁杂的事,简单化处理。
忍耐能力:作为一个团队技术头头,一般都会有一些孤独感。可能这就是大家常说的技术范。
再就是对于系统改造循序渐近的,得忍受那种全部都重做的冲动,一点一点的进行处理。
重生能力:作为架构师,熟悉自己所在团队和系统是必然的。抽时间让自己跳出原有既定思维和惯性,重新认识自己团队和系统。
沟通能力:需要跟与人打交道,当然需要良好沟通能力了。
别于社交网络、搜索和游戏等网站,电商网站的用户流量有哪些特点?
电商网站流量特点,突发性流量暴增,根本无法精确的预估的量。可能刚开始几万的量,突然几分钟就上到几十、几百、上千万、十倍百倍千倍的往上增。
相比社交、搜索、游戏网站,差异最大点,就在直接牵涉精确的金额的问题。所以对于精准和延时,缓存有一些差异化的。
社交网络:一般延时可做大点,及时性通讯可以端对端。
搜索:一般多级缓存,大多计算好往前推,延时也可做大点,另外搜索本就模糊的匹配,精准性方面要求没那么严格。
游戏网站:大多客户端大型游戏,客户端数据缓存几秒之后再进行传输,或者一些直接本地存数据,后端根服务器交互。
根据上面的比对,还是有比较真实感知到是有差异的。差异点主要集中在于 money 交易这一点上。
高流量、高并发情况下,如何保证整个系统的可靠性和稳定性
高流量、高并发是交易所有系统都面临这样一个问题,记忆深刻的用户刷爆品商品的问题,还有利用软件来刷的。
入口层:过滤掉大部分软件刷的情况,衍生了风控系统,秒杀系统。
应用层: 读写分离、缓存、队列、令牌、系统拆分、隔离、系统升级(可水平扩容方向)。
其他:
时间换空间:降低单次请求时间,这样在单位时间内系统并发就会提升。
空间换时间:拉长整体处理业务时间,换取后台系统容量空间。
可靠性和稳定性:会做一堆的容灾方案,从机房、网络、应用、存储、渠道、业务等多维度容灾。做一堆的降级策略,从流量、应用、渠道、业务 等对多维度做。
每年大型促销、流量、订单量不断翻倍。推动你去做异构、拆分系统、异步、服务化、容灾、降级等等,一堆堆的优化。
关于一些技术框架,实际上最终实现都大同小异,会去了解实现原理,以及做的好的地方,比如Elasticsearch底层用的Lucene。
而Lucene之前用过还专门看过源码,基本都是通的。加入了分布式存储的副本概念,以及sharding子机器并行执行理念,收集结果返回。
再来一张不明所以的图:
再来一张牛逼的图: