标准Web系统的架构分层

在上图中我们描述了Web系统架构中的组成部分。并且给出了每一层常用的技术组件/服务实现。需要注意以下几点：

• 系统架构是灵活的，根据需求的不同，不一定每一层的技术都需要使用。例如：一些简单的CRM系统可能在产品初期并不需要K-V作为缓存；一些系统访问量不大，并且可能只有一台业务服务器存在，所以不需要运用负载均衡层。

• 业务系统间通信层并没有加入传统的HTTP请求方式。这是因为HTTP请求-响应的延迟比较高，并且有很多次和正式请求无关的通信（这在下面的内容中会详细讲到）。所以，传统的HTTP请求方式并不适合在两个高负载系统之间使用，其更多的应用场景是各种客户端（WEB、IOS、Android等）->服务器端的请求调用。

• 我们把业务编码中常使用的缓存系统归入到数据存储层，是因为类似于Redis这样的K-V存储系统，从本质上讲是一种键值数据库。为什么Redis会很快以至于可以作为缓存使用，我将在随后的文章中进行详细的描述。

• 还有一点需要注意的是，上面架构图中的每层之间实际上不存在绝对的联系（例如负载层一定会把请求转送的业务层，这样的必然性是不存在的），在通常情况下各层是可以跨越访问的。举例说明：如果HTTP访问的是一张图片资源，负载层不会把请求送到业务层，而是直接到部署的分布式文件系统上寻找图片资源并返回。再比如运用LVS做Mysql负载时，负载层是直接和数据存储层进行合作。

我们如何来评价一个服务系统的顶层设计是否优秀呢？抛开八股文式的扩展性、稳定性、健壮性、安全性这样的套话不说。我从实际工作中为大家总结了一下几个评价要点。

1、建设成本

任何系统架构在进行生产环境实施的时候，都是需要付出建设成本的。显然各个公司/组织对成本的承受度是不一样的（这些成本包括：设计成本、资产采购成本、运维成本、第三方服务成本），所以如何利用有限的成本建设出符合业务需求、适应访问规模的系统，就是一个复杂的问题。另外，这种要求下架构师是不能进行过度设计的。

2、扩展/规划水平

根据业务的发展，整个系统是需要进行升级的（这包括已有模块的功能升级、合并已有的模块、加入新的业务模块或者在模块功能不变的情况下提高数据吞吐量）。那么如何尽量不影响原业务的工作，以最快的速度、最小的工作量来进行系统的横向、纵向扩展，也就是一个复杂的问题了。好的系统架构是可以在用户无任何感觉的情况下进行升级的，或者只需要在某些关键子系统升级时才需要短暂的停止服务。

3、抗攻击水平

对系统的攻击肯定是瞄准整个系统最薄弱的环节进行的，攻击可能来自于外部（例如Dos/DDos攻击）也可能来自于内部（口令入侵）。好架构的系统不是“绝对不能攻破”的系统，而是“预防很好”的系统。所谓预防，就是预防可能的攻击，分阶段对可能遇到的各种攻击进行模拟；所谓隐藏，就是利用各种手段对整个系统的关键信息进行涉密管理，ROOT权限、物理位置、防火墙参数、用户身份。

4、容灾恢复等级

好的架构应该考虑不同等级的容灾。集群容灾，在集群中某一个服务节点崩溃的情况下，集群中另外一台主机能够接替马上接替他的工作，并且故障节点能够脱离；分布式容灾：分布式系统一般会假设整个系统中随时都在发生单点故障/多点故障，当产生单点故障/多点故障时，整个分布式系统都还可以正常对外提供服务，并且分布式系统中的单点故障/多点故障区可以通过自动/人工的方式进行恢复，分布式系统会重新接纳它们；异地容灾（机房等级容灾）：在机房产生物理灾难的情况下（物理网络断裂、战争摧毁、地震等），在某个相隔较远的异地，备份系统能够发现这样的灾难发生，并主动接过系统运行权，通知系统运维人员（根据系统不同的运行要求，可能还有多个备份系统）。异地容灾最大的挑战性是如何保证异地数据的完整性。

5、业务适应性水平

系统架构归根结底还是为业务服务的，系统架构的设计选型一定是以服务当前的业务为前提。在上文中提到的业务通信层中，选择SOA组件还是消息队列组件，又或者选择什么样的消息队列，就是一个很好的业务驱动事件。例如，A业务是一种WEB前端服务，需要及时反馈给客户操作结果，B业务的服务压力又非常大。A业务在调用B业务时，B业务无法在毫秒级的时间内返回给A业务调用结果。这种业务场景下可以使用AMQP类型的消息队列服务。另外说明两点，目前行业内有很多为解决相同业务场景存在的不同方案，架构师在进行方案选型的过程中，一定要对各种解决方案的特点足够掌握，这样才能做出正确的选择；另外行业内的解决方案已经足够多，架构师在业务没有特殊要求的情况下一定不要做“ 重复发明轮子”的事情。

6、维护难易程度

一套服务系统从架设之初就需要运维团队不断的进行投入。显然根据系统的复杂程度和物理机器的数量，运维团队的知识复杂性也是不一样的。在架构师进行顶层架构设计时，必须还要考虑系统的运维难度和运维成本。