Java开发网站架构演变过程，到目前为止，大致分为5个阶段，分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术，并且教会你如何区分它们。

　　
第1阶段：单体架构 单体架构介绍

　　单体架构就是将所有的应用、数据库、文件都部署在一台机器上，俗称All-In-One。简单来讲其实就是我们熟知的SSH架构或SSM架构，把所有的业务模块都放在一个应用中开发，这里面又衍生出三层架构，即表示层、业务逻辑层和数据库访问层，虽然在软件设计中划分了经典的三层模型，但是对业务场景没有划分，一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程项目中，最终经过编译、打包，部署在一台服务器上。单体架构图如下：

　　
单体架构优点

　　单体架构缺点

　　单体架构向集群架构过渡（1）：应用和数据分离

　　随着公司业务的不断发展，由于单台服务器性能有限，逐渐无法满足业务需求，大量用户高并发的访问导致系统性能越来越差，数据存储空间开始出现不足，这时我们需要将应用和数据分离，分离后开始使用三台服务器：应用服务器、文件服务器、数据库服务器。如图:

　　

　　应用和数据分离后，不同种类的服务器承担着不同的服务角色，网站的并发处理能力和数据存储空间都得到了很大的改善，支持网站业务进一步发展，但是随着用户量进一步增多，数据库压力依然越来越大，访问延迟不可避免，进而影响整个网站的性能，糟糕的用户体验使得系统需要进一步优化。

　　单体架构向集群架构过渡（2）：缓存的使用

　　随着QPS持续提高，为了降低接口访问时间、提高服务性能和并发，我们注意到，网站访问有个著名的二八定律，即80%的业务集中访问在20%的数据上（热数据），其实部分数据有很多不需要每次都从数据库获取，比如经常被查询但对准确性要求并不是特别高的数据。如果我们将这一小部分热数据缓存在内存中，能够很好的减少数据库的访问压力，并大幅提升网站响应速度，因此网站就开始加入了缓存应用，常用的缓存组件有redis，ehcache等。

　　

　　第2阶段：集群架构

　　缓存在一定程度上解决了数据库访问量比较大的问题，但仍无法解决随着业务增多造成的服务器并发压力大的问题，因为单台服务器的计算能力有限，应用程序运行速度就有限，因此这时想要突破服务器性能的瓶颈，最直接的办法就是增加一台甚至多台应用服务器来分担原来服务器的访问压力和存储压力，多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务。注意，这里的多台应用服务器部署的都是同一套应用程序（即同一套项目源码或war包），这就是集群架构，结构如图:

　　
思考：系统演变到这里，将会出现下面四个问题（不做具体展开）：

　　这时候，你会发现图中多了一个名为负载均衡器的代理服务器，通常我们使用Nginx来实现，它的作用主要就是用户不需要记住两个甚至多个应用服务器的IP或域名，只要记住一台代理服务器IP就可以了。由代理服务器来负责分发用户是访问哪个应用服务器，那么用户具体是访问服务器1、访问服务器2还是服务器N，由Nginx里面的权重设置来决定的，并且通过Nginx的配置，Session共享也可以附带实现，保证多台应用服务器的Session一致性。另外，这样做还有一个好处就是将代理服务器放在外网，应用服务器均放在内网，可以有效防止应用服务器被恶意攻击。

　　集群架构演变（1）：数据库读写分离

　　系统正常运行了一段时间后，虽然加有缓存，使绝大多数的数据库操作可以不通过数据库就能完成，但是仍然有一部分的数据库操作(缓存访问不命中或缓存过期)和全部的写操作需要访问数据库，当用户规模再一步增长后，数据库因为负载压力过大还是会成为系统性能的瓶颈，这时主流的数据库都提供的有主从热备份功能，通过配置两台数据库实现主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。可以利用这一功能来实现数据库读写分离，从而改善数据库的负载压力，如图:

　　

　　在图中我们可以发现主数据库服务器负责写操作，而从服务器负责读操作，这样数据库的压力就被分散在两台服务器上，而我们只需保证主从数据库的数据一致性即可，这里说明下Mysql的读写分离可以通过自身自带的从主复制实现，Oracle数据库可以通过阿里巴巴的mycat组件来实现。

　　概念补充：

　　集群架构演变（2）：反向代理和CDN加速

　　为了应对复杂的网络环境和不同地区用户的访问（比如你的服务器在美国或新加坡，国内用户直接访问可能会很卡），保障各个地区的用户都能流畅地访问系统，可以通过CDN和反向代理来加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理其实本质上都是缓存。CDN部署在网络提供商的机房，用户请求到来的时候从距离自己最近的网络提供商机房获取数据，而反向代理则部署在网站的中心机房中，请求到来的时候先去反向代理服务器中查看请求资源，如果有则直接返回。结构如图：

　　
第3阶段：分布式架构

　　分布式架构的演变涉及分布式文件、分布式数据库、NoSql、搜索引擎以及业务模块的拆分，下面我们一个个看。

　　分布式架构演变（1）：分布式文件和分布式数据库

　　
分布式架构演变（2）：NoSql和搜索引擎

　　

　　NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持，应用服务器通过一个统一的数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

　　分布式架构演变（3）：业务模块拆分成子项目

　　当访问量达到一定规模的时候我们可以通过分而治之的手段将整个系统的业务分成不同的产品线，例如我们将系统的首页，商铺，订单，买家，卖家，支付，订单等模块拆分成不同的产品线，每个产品线都独立成一个子项目，每个子项目都有自己的独立的数据库，子项目之间通过RPC框架(dubbo,webService,httpClient…)建立连接通信，也可以通过消息队列实现异步分发处理，从而构成一个完整的系统，结构如下图:

　　
第4阶段：SOA架构

　　SOA是什么？SOA全英文是Service-Oriented Architecture，意为面向服务编程，也称为服务治理，是一种思想，一种方法论，一种分布式的服务架构，这里的服务可以理解为service层业务服务，它将共同的业务逻辑拆分成独立的应用进行部署，这些应用没有视图层，只对外提供RPC调用接口。

　　SOA 系统原型的一个典型例子是 CORBA，它已经出现很长时间，其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上，通过使用基于 XML 的语言来描述接口，服务已经转到更动态且更灵活的接口系统中，CORBA 中的 IDL 无法与之相比。如图描述了一个完整的 SOA 模型。

　　

　　在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。一个独立的服务基本结构如图所示：

　　

　　服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接口层。通过服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现，服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的，以及消息的传输路径，而是只需要提出服务请求，然后就会得到答案。举个例子：

　　

　　通过上面的图我们可以看出，多个子系统直接相互交互，相互调用非常凌乱，这样我们就很不爽，所以我们就用到了我们的SOA架构，SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准，把我们的服务治理成下图所示，以前我们的服务是互相交互，现在是只对数据总线进行交互，这样系统就变得统一起来。

　　

　　各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如何找到其他子系统，我们只找数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个指路人的作用。

　　SOA的特点：

　　SOA的优点：

　　SOA的缺点：

　　提示了系统的复杂程度，性能有相应影响。

　　第5阶段：微服务架构

　　

　　微服务缺点

　　总结：架构之间的区别

　　

今天的文章 服务器部署架构图（服务器的部署）分享到此就结束了，感谢您的阅读。