列举网首页
1、概述
本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章后汇总了一些架构设计的原则。
2、基本概念
在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个基础的概念进行介绍。
1）什么是分布式？
系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上。
2）什么是高可用？
系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。
3）什么是集群？
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。
如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。
在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。
4）什么是负载均衡？
请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的。
5）什么是正向代理和反向代理？
系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；
当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。
简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
3、架构演示
图片显示不了，详细进入：www.***.cn
4、架构设计总结
1）架构的调整是否必须按照上述演变路径进行？
不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进
在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。
如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
2）对于将要实施的系统，架构应该设计到什么程度？
对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。
对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
3）服务端架构和大数据架构有什么区别？
所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术
如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。
总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。
而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。
4）有没有一些架构设计的原则？
N+1设计：系统中的每个组件都应做到没有单点故障；
回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计：在设计阶段就要考虑监控的手段；
多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
资源隔离设计：应避免单一业务占用全部资源；
架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；
非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
使用商用硬件：商用硬件能有效降低硬件故障的机率；
快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
