一、基本概念
1、分布式
系统中的多个模块在不同的服务器上部署，即可称之为分布式系统。如Tomcat和数据库分别部署在不同的服务器上，或者两个相同功能的Tomcat分别部署在不同的服务器上。
2、高可用
系统中部分节点失效的时候，其他节点可以继续替它提供服务，则认为系统具有高可用性。
3、集群
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如zookeeper中的master和slave分别部署在不同的服务器上，共同提供服务，在常见的集群中，客户端可以连接任意一个节点获得服务，并且如果有节点挂掉，其他节点可以替代它继续提供服务。
4、负载均衡
客户端发送请求的时候，服务器可以利用某种方式把请求均匀的分发到多个节点上，使得每个节点能够均匀的处理请求负载。
5、正向代理和反向代理
系统内部要访问外网的时候，统一通过一个代理服务器把请求发出去，代理服务器实现的就是正向代理。
如果有外部请求进入系统的时候，代理服务器把这些请求集中转发到某台服务器上，此时，代理服务器实现的就是反向代理。
所以，正向代理就是代理服务器代替系统内部向外发起请求的过程，而反向代理是外部请求通过代理服务器转发到内部服务器的过程。
二、架构演进过程
1、单机架构
Tomcat和数据库部署在同一个服务器上，浏览器访问tabao网址，先通过DNS（域名系统）拿到具体的ip，然后浏览器直接访问该IP的tomcat。
2、tomcat 和 数据库分开部署
将数据库和Tomcat分别部署，独占服务器资源。
3、引入本地缓存和分布式缓存
使用memcached作为本地缓存，使用Redis作为分布式缓存，将热点数据放在缓存里，降低数据库的负载。
4、引入反向代理实现负载均衡
把tomcat部署在多个服务器上，使用反向代理（nginx）把请求均匀的发送到不同的tomcat上，可以抵御高并发，但是数据库压力也会进而增加。
5、数据库读写分离
把数据库分为多个读库和写库，通过同步机制把写库的数据同步到读库，可以利用缓存或的最新数据。Mycat，数据库中间件，可以组织数据库的读写分离和分库分表。
6、数据库按照业务分库
把不同的业务保存到不同的数据库中，使得业务之间的数据库资源竞争降低，访问量大的业务可以部署更多的服务器来支持。
7、把大表拆成小表
把数据库按照一定的属性进行表拆分等，称为分布式数据库。如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。
8 、使用LVS或F5来使多个Nginx负载均衡
一个负载已经不够了
利用LVS和F5在nginx的上层在做一层负载。
LVS和F5是工作在网络第四层的负载均衡的解决方案。
LVS：软件，运行在操作系统内核态，可以对TCP请求或者更高层级的网络协议进行转发，性能远高于nginx；
F5：负载均衡硬件。
可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP的时候，就会被路由器重定向到真实的LVS服务器。
9、通过DNS轮询实现机房间的负载均衡。
在DNS里配置一个域名对应多个IP地址，每个IP地址对应到不同机房的虚拟IP，当用户访问连接的时候，DNS会根据策略（有可能是轮询也有可能是其他策略），来返回某个IP。实现机房的水平扩展。
10、引入NoSQL数据库和搜索引擎等技术
单单的数据库已经无法满足丰富的业务需求了。
数据库中的数据越来越多的时候，或者查询条件越来越复杂的时候，就必须引入其他技术来实现了。
如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。
当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。
11、大应用拆成小应用
把大应用拆成小应用，相互之间独立迭代，应用之间涉及的公公配置，通过分布式配置中心zookeeper来解决。
不同应用之间存在的公共模块，公共模块改变，则所有的应用都要改一遍。
12、复用的功能抽离成微服务
对于所有应用都能用到的小模块，进行抽离，做成单独的服务来管理，也就是微服务，应用和服务之间通过http、tcp、rcp请求等多种方式来访问公共服务，每个单独的服务单独管理。可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。
不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱。
13、引入企业服务总线ESB屏蔽服务接口的访问差异
微服务和应用之间增加ESB统一进行协议转换，应用通过ESB来访问后端服务，服务与服务之间也用ESB来访问。
把单个应用拆成多个应用，公共服务单独抽取出来管理，并使用企业总线来解除服务之间的耦合问题，称为SOA（面向服务）架构。
微服务架构：把系统中的公共服务抽离出来单独运维。
SOA架构：一种拆分服务，使服务接口访问变得统一。
14、引入容器化技术实现运行环境隔离与动态服务管理
目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes（K8S），应用/服务可以打包成Docker镜像，通过K8S来动态发布和部署镜像。Docker镜像可理解为一个能运行应用/服务的最小的操作系统，里面放着代码，运行环境跟实际的需要设置好，把Docker打包成镜像，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像可以启动服务，使服务的部署和运维变得简单。
大促可以增加服务器和镜像的部署，结束之后关闭镜像就好。
15、以云平台承载系统
把系统部署在云服务上，利用云服务的海量机器资源，解决动态硬件资源的我呢提，如遇到大促，则在云平台临时申请更多的资源，结合Docker和K8S快速部署服务，大促结束之后，释放资源。
所谓的云平台，就是把海量的机器资源，通过统一的资源管理，抽象成一个整体，按需动态申请硬件资源，并且提供通过的操作系统，提供常见的技术组件供用户使用，提供开发好的应用。
IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。
三、架构设计总结
1、架构的调整是否必须按照上述演变路径进行？
不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
2、对于将要实施的系统，架构应该设计到什么程度？
对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
3、服务端架构和大数据架构有什么区别？
所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。
4、有没有一些架构设计的原则？
N+1设计：统中的每个组件都应做到没有单点故障；
回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计：：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计：在设计阶段就要考虑监控的手段；
多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
资源隔离设计：应避免单一业务占用全部资源；
架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；
非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
使用商用硬件：商用硬件能有效降低硬件故障的机率；
快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
