分布式电商项目最少用多少台服务器

做电商网站的服务器需要企业级高性能的机型。商城网站因为属于在线交易类型的性质，所以在线人数较多，安全性、稳定性、速度都有要求的。

而且分布式要求使用负载均衡、CDN加速、对象存储等多种不同技术合并使用。

这类网站一般都比较多且大尺寸。服务器建议用 2核4G内存了。

带宽也用3M以上，1M带宽这样的访问会打开慢的。

看需求了，要看网站的规模，网站的日均流量等等来选择的，如果是前期的小站，或者流量不会集中很高的企业站，就不需要很高配置的服务器了，一般1核2g 1m的就够用

首先得弄明白自己用服务器用来干什么放网站、应用运行或者是用来搭建放游戏等，都有一个自己的用途，弄明白用服务器是用来干嘛的，就可以很明确的知道自己需要的是哪种类型的服务器

尝试根据下面四个问题来评估自己的需求：

1 服务器运行什么应用？

2 需要支持多少用户访问？

3 需要多大空间来存储数据？

4 我的业务有多重要？

从你的需求来看，国内选择那几个比较大的商家合适，至于名字和具体配置选择也是一门学问，老魏会帮助你提供参考意见。

电商

网站的服务器需要企业级高性能的机型。商城网站因为属于在线交易类型的性质，所以在线人数较多，安全性、稳定性、速度都有要求的。

这类网站一般都比较多且大尺寸。服务器建议用 2核4G内存了。

带宽也用3M以上，1M带宽这样的访问会打开慢的。

看需求了，要看网站的规模，网站的日均流量等等来选择的，如果是前期的小站，或者流量不会集中很高的企业站，就不需要很高配置的服务器了，一般1核2g 1m的就够用

首先得弄明白自己用服务器用来干什么放网站、应用运行或者是用来搭建放游戏等，都有一个自己的用途，弄明白用服务器是用来干嘛的，就可以很明确的知道自己需要的是哪种类型的服务器

尝试根据下面四个问题来评估自己的需求：

1 服务器运行什么应用？

2 需要支持多少用户访问？

3 需要多大空间来存储数据？

4 我的业务有多重要？

从你的需求来看，国内选择那几个比较大的商家合适，至于名字和具体配置选择也是一门学问，老魏会帮助你提供参考意见。

分布式架构设计属于进阶Java架构师的必经之路，而且大厂也特别喜欢考察，建议大家需要重点掌握。

为了方便大家更好的掌握好分布式架构，也为了让知识更系统化，这里我单独把分布式架构的整个系列一并罗列于此，希望对有用的人有用，也希望能帮助到更多的人！

完整文档，到文末获得~

单点登录是分布式大型网站必备技术，例如淘宝、天猫、聚划算等网站，用户只需要登录一次就可以访问所有系统。

这篇文章主要讲了以下几点：

负载均衡是单机到分布式集群的必经之路，高性能扩展必备。

这篇文章主要讲了以下几点：

幂等性在支付场景、下订单、以及分布式系统都是最常遇到的问题，非常重要。

这篇文章主要讲了以下几点：

大型网站淘宝都是如何从小一步步演变到分布式架构，这里会涉及到分布式服务拆分等关键点。

这篇文章主要讲了以下几点：

在大数据场景下，分布式数据库的数据一致性是分布式最重要的内核技术之一。

这篇文章主要讲了以下几点：

很多同学对分布式、集群等不是很清楚，本篇重点讲解：

大家熟知的淘宝的海量，这就会涉及到分布式文件存储技术。

这篇文章主要讲了以下几点：

这是完整的详解比如淘宝等大型网站是如何一步步从小演变成现在的大型网站的完整过程。

这篇文章主要讲一下几点：

1初始阶段的网站架构

2应用服务和数据服务分离

3使用缓存改善网站性能

4使用应用服务器集群改善网站的并发处理能力

5数据库读写分离

6使用反向代理和 CDN 加速网站响应

7使用分布式文件系统和分布式数据库系统

8使用 NoSQL 和搜索引擎

9业务拆分

10分布式服务

这篇文章主要讲一下几点：

1、单体架构

2、单体架构的拆分

3、SOA与微服务的区别

4、微服务的优缺点

5、微服务的消息

6、服务集成

7、数据的去中心化

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用，淘宝开源国内使用较多。

这篇文章主要讲一下几点：

在国内用的比较多的就是Dubbo和Spring Cloud微服务这套体系，所以单独来比较选型。

这篇文章主要比较以下几点：

这篇文章主要比较以下几点：

以上我主要从分布式演变，再到微服务拆分，以及分布式数据一致性等对分布式进行了一个完整的详解，希望这个 分布式系列 能对你有所帮助。

高并发量网站解决方案

一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃。

在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadMole，保证更高的系统消耗和执行效率。

3、数据库集群、库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和ENet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

（1）、硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

(2)、软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

最新：CDN加速技术

CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。

CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。

CDN的类型特点

CDN的实现分为三类：镜像、高速缓存、专线。

镜像站点（MirrorSite），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。

高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。

CDN服务一般会在全国范围内的关键节点上放置缓存服务器。

专线，让用户直接访问数据源，可以实现数据的动态同步。

CDN的实例

举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。

当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。

通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。

由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。

1简介

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以“发表”一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样。

当下我们处在一个互联网飞速发展的信息 社会 ，在海量并发连接的驱动下每天所产生的数据量必然以几何方式增长，随着信息连接方式日益多样化，数据存储的结构也随着发生了变化。在这样的压力下使得人们不得不重新审视大量数据的存储所带来的挑战，例如：数据采集、数据存储、数据搜索、数据共享、数据传输、数据分析、数据可视化等一系列问题。

传统存储在面对海量数据存储表现出的力不从心已经是不争的事实，例如：纵向扩展受阵列空间限制、横向扩展受交换设备限制、节点受文件系统限制。

然而分布式存储的出现在一定程度上有效的缓解了这一问题，之所以称之为缓解是因为分布式存储在面对海量数据存储时也并非十全十美毫无压力，依然存在的难点与挑战例如：节点间通信、数据存储、数据空间平衡、容错、文件系统支持等一系列问题仍处在不断摸索和完善中。

2分布式文件系统的一些解决方案

Google Filesystem适合存储海量大个文件，元数据存储与内存中

HDFS（Hadoop Filesystem）GFS的山寨版，适合存储大量大个文件

TFS（Taobao Filesystem）淘宝的文件系统，在名称节点上将元数据存储与关系数据库中，文件数量不在受限于名称节点的内容空间，可以存储海量小文件LustreOracle开发的企业级分布式系统，较重量级MooseFS基于FUSE的格式，可以进行挂载使用MogileFS

擅长存储海量的小数据，元数据存储与关系型数据库中

1简介

MogileFS是一个开源的分布式文件系统，用于组建分布式文件集群，由LiveJournal旗下DangaInteractive公司开发，Danga团队开发了包括 Memcached、MogileFS、Perlbal等不错的开源项目：(注：Perlbal是一个强大的Perl写的反向代理服务器)。MogileFS是一个开源的分布式文件系统。

目前使用 MogileFS 的公司非常多,比如国外的一些公司,日本前几名的公司基本都在使用这个

国内所知道的使用 MogileFS 的公司有托管网站 yupoo又拍,digg, 土豆, 豆瓣,1 号店, 大众点评,搜狗,安居客等等网站基本很多网站容量，都超过 30T 以上。

2MogileFS特性

1) 应用层提供服务，不需要使用核心组件

2）无单点失败，主要有三个组件组成，分为tracker（跟踪节点）、mogstore（存储节点）、database（数据库节点）

3）自动复制文件，复制文件的最小单位不是文件，而是class

4）传输中立，无特殊协议，可以通过NFS或HTTP实现通信

5）简单的命名空间：没有目录，直接存在与存储空间上，通过域来实现

6）不用共享任何数据

3MogileFS的组成

1）Tracker--跟踪器，调度器

MogileFS的核心，是一个调度器，mogilefsd进程就是trackers进程程序,trackers的主要职责有：删除数据、复制数据、监控、查询等等这个是基于事件的( event-based ) 父进程/消息总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到多个"query workers"中,然后让 mogilefs的子进程去处理

mogadm,mogtool的所有操作都要跟trackers打交道,Client的一些操作也需要定义好trackers,因此最好同时运行多个trackers来做负载均衡trackers也可以只运行在一台机器上，使用负载均衡时可以使用搞一些简单的负载均衡解决方案，如haproxy，lvs，nginx等，

tarcker的配置文件为/etc/mogilefs/mogilefsdconf，监听在TCP的7001端口

2）Database--数据库部分

主要用来存储mogilefs的元数据，所有的元数据都存储在数据库中，因此，这个数据相当重要，如果数据库挂掉，所有的数据都不能用于访问，因此，建议应该对数据库做高可用

3）mogstored--存储节点

数据存储的位置，通常是一个HTTP（webDAV）服务器，用来做数据的创建、删除、获取，任何 WebDAV 服务器都可以, 不过推荐使用 mogstored mogilefsd可以配置到两个机器上使用不同端口… mogstored 来进行所有的 DAV 操作和流量,IO监测, 并且你自己选择的HTTP服务器(默认为 perlbal)用来做 GET 操作给客户端提供文件

典型的应用是一个挂载点有一个大容量的SATA磁盘 只要配置完配置文件后mogstored程序的启动将会使本机成为一个存储节点当然还需要mogadm这个工具增加这台机器到Cluster中

配置文件为/etc/mogilefs/mogstoredconf，监听在TCP的7500端口

4基本工作流程

应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器) 做一个 “create_open” 请求

tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。

应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去）

应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了

tracker 将该名称和域命的名空间关联 (通过数据库来做的)

tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则

然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表

应用程序然后按顺序尝试这些URL地址 (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做)

1拓扑图

说明：1用户通过URL访问前端的nginx

2nginx根据特定的挑选算法，挑选出后端一台tracker来响应nginx请求

3tracker通过查找database数据库，获取到要访问的URL的值，并返回给nginx

4nginx通过返回的值及某种挑选算法挑选一台mogstored发起请求

5mogstored将结果返回给nginx

6nginx构建响应报文返回给客户端

2ip规划

角色运行软件ip地址反向代理nginx1921681201存储节点与调度节点1

mogilefs1921681202存储节点与调度节点2

mogilefs1921681203数据库节点

MariaDB1921681204

3数据库的安装操作并为授权

关于数据库的编译安装，请参照本人相关博文http://wangfeng7399blog51ctocom/3518031/1393146，本处将不再累赘，本处使用的为yum源的安装方式安装mysql

4安装mogilefs 安装mogilefs，可以使用yum安装，也可以使用编译安装，本处通过yum安装

5初始化数据库

可以看到在数据库中创建了一些表

6修改配置文件，启动服务

7配置mogilefs

添加存储主机

添加存储设备

添加域

添加class

8配置1921681203的mogilefs 。切记不要初始化数据库，配置应该与1921681202一样

9尝试上传数据，获取数据，客户端读取数据

上传数据，在任何一个节点上传都可以

获取数据

客户端查看数据

我们可以通过任何一个节点查看到数据

要想nginx能够实现对后端trucker的反向代理，必须结合第三方模块来实现

1编译安装nginx

2准备启动脚本

3nginx与mofilefs互联

查看效果

5配置后端truckers的集群

查看效果

大功告成了，后续思路，前段的nginx和数据库都存在单点故障，可以实现高可用集群