crm系统架构图，架构设计：标准Web系统的架构分层

有的读者可能会问crm系统架构图，为什么业务系统间通信层没有提到HTTP这样的调用方式。毕竟很多公司目前都采用这种方式作为业务系统间的调用方式。我们首先通过一个图来看看HTTP方式的调用过程。（注意，此过程不考虑http客户端缓存的过程也不考虑DNS域名解析的过程，从HTTP建立可靠的TCP连接开始）：

从上图中我们可以看出以下几个问题：

基于以上的描述，本文并不推荐使用HTTP作为业务间通信/调用的方式，而建议HTTP方式仅限于WEB、iOS、等这样的客户端请求服务的方式。

4、数据存储层

数据存储将是这个系列文章中将要介绍的另一个重点。进行业务计算前的初始数据、计算过程中的临时数据、计算完成后得到的计算结果都需要进行存储。我们通过一张思维导图首先从几个维度阐述一下数据存储的基本分类。

4.1、文件存储原理

我们通过一个最基本的在.5系统上创建Ext4文件系统的过程，讲解文件系统的最基本原理。

4.2、块存储和文件存储

上一小节我们叙述了最简单、最原始的物理块和文件格式规范的工作方式，但是随着服务器端不断扩大的数据存储容量的需求和数据安全性的需求crm系统架构图，很显然单机的存储是没办法满足要求的，目前存储环境两种大的需求类型是：

要解决这两个问题，我们首先要将问题扩展到上一小节的图例中，如下图所示：

很明显图中两个问题的答案是肯定的，也就是我们将要介绍的块存储系统要解决的问题。

4.2.1、块存储系统

我们先来聊一下块存储。之前我们提到的最简单的情况就是磁盘在本地物理机上，传输的物理块I/O命令，也是通过本地物理机主板上的南桥进行的。但是为了扩展更大的磁盘空间，并且保证数据吞吐量，我们需要将磁盘介质和本地物理机分离，并且让物理块的I/O命令在网络上进行传输：

4.2.2、文件存储系统

那么如果是将文件系统从本地物理机通过网络移植到远程呢？当然可以，典型的文件存储系统包括了FTP、NFS、DAS：

从上面的简介中我们可以清楚的知晓，当面对大量的数据读写压力的时候，文件存储系统肯定不是我们的首要选择，而当我们需要选择块存储系统时又面临成本和运维的双重压力（SAN系统的搭建是比较复杂的，并且设备费用昂贵）。并且在实际生产环境中我们经常遇到数据读取压力大，且需要共享文件信息的场景。那么这个问题怎么解决呢？

4.3、对象存储系统

兼具块存储系统的高吞吐量、高稳定性和文件存储的网络共享性、廉价性的对象存储就是为了满足这样的需求出现的。典型的对象存储系统包括：MFS、Swift、Ceph、Ozone等。下面我们简单介绍一下对象存储系统的特点，在后面的文章中，我们将选择一款对象存储系统进行详细说明。

对象存储系统一定是分布式文件系统。但分布式文件系统不一定是对象存储系统

4.3、数据库存储

这篇文章已经写了很多存储层的概要描述了，所以我们熟悉或者不熟悉的数据库存储技术的概述就不在这里介绍了。

后续的文章我将使用Mysql讲解几个常用的架构方案和性能优化点，当然也会讲到Mysql中，诸如这样的核心数据引擎的工作方式。这些架构方案主要解决的是Mysql的单机I/O瓶颈、机房内数据容灾、数据库稳定性、跨机房数据容灾等核心问题。

后续的文章我还会选取目前流行的数据缓存系统，讲解其工作原理、核心算法和架构方案。以便读者们根据自己的业务情况设计符合业务的存储集群。当然还有非关系型数据库、HBase、的深入介绍。

5、评价架构的特性

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

5.1、建设成本

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

5.2、扩展/规划水平

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

5.3、抗攻击水平

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

5.3、容灾恢复等级

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

5.4、业务适应性水平

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

5.5、维护难易程度

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

6、其他说明

原文出处：