大型网站开发费用

淘宝京东盘踞电商行业十几年，有成熟的体制，我的产品只用在线上传就可以轻易上线销售。我直接在淘宝，京东开店不好吗?不容怀疑，淘宝和京东都是天然的流量池，对于企业短时间获利有很大的好处，那为什么各行业大型公司都纷纷自建独立商城呢?因为如果完全依赖于京东、淘宝等大平台。企业没有自己的渠道，除了依赖别人，没有其他的选择是一件很可怕的事情。还记得当时阿里发出的“二选一”战队吗?品牌商无论选哪边，都会丢失一半业务量。这让众多品牌商安全感缺乏，信任度骤降。

而自建一个多用户商城系统需要多少费用呢?这几乎是众多品牌商最关心的问题。开发一个多用户商城系统会因为系统功能、开发语言、网站模式、行业和多用户商城系统开发商等因素影响多用户商城系统开发报价。每一个影响多用户商城系统开发费用的介绍，如下：

影响价格因素一：使用何种开发语言

常用的多用户商城系统开发语言有PHP、JAVA、、JSP等，但最新的最受欢迎的口碑最好的是JAVA和PHP。然而，做多用户商城系统采用不同语言开发，JAVA架构和PHP架构的多用户商城系统费用也会不同.

PHP多用户商城系统有哪些特点?

1.适用范围广

因其混合了多种语法特性，能够在UNIX、LINUX、WINDOWS、Mac OS、Android等服务器平台运行，并且可以可以与很多主流的数据库建立起连接，如MySQL、ODBC、Oracle、AdabasD、S等。

2.开源

PHP语言开发的是开源的，具有开发成本低、开发速度快的特点，开发者可以更加自由、快速地对多用户商城系统进行开发。

PHP多用户商城系统具有程序开发快、程序运行快、开发人员能快速学习上手的优势，相对于其他语言来说编辑更加简单，实用性更强。

一个好的多用户商城系统应该能够适应企业业务发展而进行二次开发，扩展网站功能。所以，业内有这么个说法：做好多用户商城系统的建设与其说是关注价格，倒不如说是关注自身刚需与现实条件的最理想契合，影响报价的因素很多，我们要选择适合自己的才是正确的，大家一定要选择正规的多用户商城系统搭建系统，以及专业度高的多用户商城系统服务商。

影响价格因素二：商城需要多少功能

一个普通的多用户商城系统会拥有商品管理、订单管理、促销管理、会员管理、物流管理、网站装修、数据统计和营销管理等功能。然而，不少商家会跟上海远丰提出要求，普通多用户商城系统可能已经不能满足发展已久的电商业务，需要拥有更多个性化、行业特性的多用户商城系统功能。那么，定制多用户商城系统功能，费用自然也就会增加，功能需求越多，功能实现难度越高，随之多用户商城系统开发费用也就越高。

影响价格因素三开发商决定建设价格

因为每一家多用户商城系统开发商的技术水平、专业程度、服务质量等不同，开发的多用户商城系统价格也自然不一样。有的多用户商城系统开发商可能前期报价非常的低，针对不懂的企业商家可以在上面介绍到的内容中偷工减料，甚至还会因网站模式不对、行业业务分析不透彻等不专业因素影响多用户商城系统项目开发失败。有的多用户商城系统开发商不管在电商系统框架、多用户商城系统功能、行业开发经验、服务质量等各方面都相对专业全面，自然多用户商城系统报价也会比较贵。但其实往更深一层次想专业全面地开发一个多用户商城系统，在使用上、开发时间上、未来二次开发等优势上考虑，其实会安全性高、费用更节省。

1 架构演化

大型网站的关注指标

高可用

高性能

易扩展

可伸缩

安全

大型网站的特点

高并发，大流量

高可用

海量数据

用户分布广泛，网络情况复杂

安全环境恶劣

需求快速变更，发布频繁

渐进式发展

大型网站架构演化发展过程

初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上

应用服务和数据服务分离，有独立的数据库服务器

使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）

这里需要考虑哪些数据适合缓存

缓存可以是本地缓存，也可以是远程分布式缓存

需要考虑使用合理的缓存策略，防止透传

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

如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

这里需要考虑使用哪些负载均衡的策略

数据库读写分离

可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

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

CDN和反向代理的基本原理都是缓存

CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据

反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户

CDN的重点：——《大型网站系统与Java中间件实践》

全局调度

缓存技术

内容分发

带宽优化

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

网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

使用NoSQL和搜索引擎

ES

MongoDB

业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线

SOA、服务化

中心化的 gataway方式

消息队列

不同服务访问同一个DB等

这部分十分重要，道理很简单，但是执行起来的效果千差万别。

当下火热的微服务，也是基于这种思想。

技术实现方式也有很多

分布式服务

大型网站架构演化的价值观

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。

大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程

驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路

网站架构设计误区

一味追求大公司的解决方案

为了技术而技术

企图用技术解决所有问题

2 架构模式

分层，这是在横向方向对系统进行切分

分层的挑战在于必须合理规划层次边界和接口

分层包括物理分层和逻辑分层两种

分割，这是在纵向方向对系统进行切分

将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

分布式

1） 分布式应用和服务；

2） 分布式静态资源；

3） 分布式数据和存储；

4） 分布式计算；

5） 分布式配置、分布式锁、分布式文件系统。。。

1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

2） 服务器越多，宕机的概率越大

分层和分割的目的在于小模块便于分布式部署

带来的问题：

常用的分布式方案：

集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务

即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

缓存，即将数据放在距离计算最近的位置以加快处理速度

CDN

反向代理

本地缓存

分布式缓存

异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作

1） 提高系统可用性；

2） 加快网站响应速度；

3） 消除并发访问高峰

通常需要使用消息队列

带来的好处：

冗余

集群带来的必然结果

安全需求的必然结果

自动化，DevOps思维，尽量减少人工干预

自动化发布

自动化代码管理

自动化测试

自动化安全监测

自动化部署

自动化监控

自动化报警

自动化失效转移、恢复

自动化分配资源

......

安全

3 大型网站核心架构要素

性能

一个性能问题可能会导致网站用户严重流失

衡量性能的指标：响应时间、TPS、系统性能计数器等

可用性

没有网站可以完美的7*24运行

网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

必要的手段是集群，即冗余

伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求

衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

扩展性，直接关注网站的功能，保证可以快速响应需求变更

衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

安全性

衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

4 瞬时响应 - 网站的高性能架构

不同视角下的网站性能

用户视角

主要是端到端的感觉

主要通过前段优化的手段来提升用户体验

开发人员视角

主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

运维人员视角

主要关注基础设施性能和资源利用率

主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

性能测试指标

响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间

并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性

吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力

性能计数器， 描述服务器或者操作系统性能的一些数据指标

性能测试方法

性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期

负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值

压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求

稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定

Web前端优化

浏览器访问优化

减少http请求

使用浏览器缓存

启用压缩

CSS放在页面最上面，JavaScript放在页面最下面

减少Cookie传输

CDN加速

反向代理

应用服务器性能优化

分布式缓存

一般会使用消息队列，带来的额外好处是会削平峰值

1）不同的缓存服务器之间进行通信，例如JBoss Cache；

2）不同缓存服务器之间不进行通信，例如Memcached

缓存从本质上来说，就是一个内存hash表

缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

缓存也需要注意缓存热点数据

缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

对于分布式缓存来说，目前有两类：

异步操作

使用集群

代码优化

多线程

1） 将对象设计成无状态对象；

2） 使用局部对象；

3） 并发访问资源时使用锁

需要注意线程安全问题，方法：

资源复用

主要是单例和资源池（对象池）

数据结构，选择合适的算法

垃圾回收

合理设置垃圾回收策略

存储性能优化

机械硬盘 vs 固态硬盘

B+树 vs LSM树

RAID vs HDFS

5 万无一失 - 网站的高可用架构

网站可用性度量

网站不可用时间 = 故障修复时间点 - 故障发现时间点

网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%

一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

高可用的应用

无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。

通过负载均衡进行无状态服务的失效转移

负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

应用服务器集群的Session管理

Session复制

Session绑定

利用Cookie记录Session

Session服务器

高可用的服务

分级管理

核心服务与非核心服务隔离

核心服务优先使用高性能服务器

超时设置

异步调用

必须满足可以使用异步调用方式

服务降级

幂等性设计

服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

高可用的数据

数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。

主要手段：数据备份和失效转移

缓存服务高可用

观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件

数据高可用含义：

副本间数据一致

多个副本可读

同时写入数据副本

1）数据持久性

2）数据可访问性

3）数据一致性

数据一致性分类：

1） 数据强一致；

2） 数据用户一致；

3） 数据最终一致

数据备份

1） 异步热备；

2） 同步热备

冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

热备分为两种：

失效转移

1） 心跳检测（Keepalived、Heartbeat）；

2） 应用程序访问失败报告

失效确认：

访问转移

数据恢复

高可用网站的软件质量保证

网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似

一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

自动化测试

一般使用Selenium来进行测试

预发布验证

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问

代码控制

主干开发，分支发布

分支开发，主干发布，这是目前使用的主流方式

自动化发布

火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待�...

1 架构演化

大型网站的关注指标

高可用

高性能

易扩展

可伸缩

安全

大型网站的特点

高并发，大流量

高可用

海量数据

用户分布广泛，网络情况复杂

安全环境恶劣

需求快速变更，发布频繁

渐进式发展

大型网站架构演化发展过程

初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上

应用服务和数据服务分离，有独立的数据库服务器

使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）

这里需要考虑哪些数据适合缓存

缓存可以是本地缓存，也可以是远程分布式缓存

需要考虑使用合理的缓存策略，防止透传

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

如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

这里需要考虑使用哪些负载均衡的策略

数据库读写分离

可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

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

CDN和反向代理的基本原理都是缓存

CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据

反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户

CDN的重点：——《大型网站系统与Java中间件实践》

全局调度

缓存技术

内容分发

带宽优化

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

网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

使用NoSQL和搜索引擎

ES

MongoDB

业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线

SOA、服务化

中心化的 gataway方式

消息队列

不同服务访问同一个DB等

这部分十分重要，道理很简单，但是执行起来的效果千差万别。

当下火热的微服务，也是基于这种思想。

技术实现方式也有很多

分布式服务

大型网站架构演化的价值观

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。

大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程

驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路

网站架构设计误区

一味追求大公司的解决方案

为了技术而技术

企图用技术解决所有问题

2 架构模式

分层，这是在横向方向对系统进行切分

分层的挑战在于必须合理规划层次边界和接口

分层包括物理分层和逻辑分层两种

分割，这是在纵向方向对系统进行切分

将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

分布式

1） 分布式应用和服务；

2） 分布式静态资源；

3） 分布式数据和存储；

4） 分布式计算；

5） 分布式配置、分布式锁、分布式文件系统。。。

1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

2） 服务器越多，宕机的概率越大

分层和分割的目的在于小模块便于分布式部署

带来的问题：

常用的分布式方案：

集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务

即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

缓存，即将数据放在距离计算最近的位置以加快处理速度

CDN

反向代理

本地缓存

分布式缓存

异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作

1） 提高系统可用性；

2） 加快网站响应速度；

3） 消除并发访问高峰

通常需要使用消息队列

带来的好处：

冗余

集群带来的必然结果

安全需求的必然结果

自动化，DevOps思维，尽量减少人工干预

自动化发布

自动化代码管理

自动化测试

自动化安全监测

自动化部署

自动化监控

自动化报警

自动化失效转移、恢复

自动化分配资源

......

安全

3 大型网站核心架构要素

性能

一个性能问题可能会导致网站用户严重流失

衡量性能的指标：响应时间、TPS、系统性能计数器等

可用性

没有网站可以完美的7*24运行

网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

必要的手段是集群，即冗余

伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求

衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

扩展性，直接关注网站的功能，保证可以快速响应需求变更

衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

安全性

衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

4 瞬时响应 - 网站的高性能架构

不同视角下的网站性能

用户视角

主要是端到端的感觉

主要通过前段优化的手段来提升用户体验

开发人员视角

主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

运维人员视角

主要关注基础设施性能和资源利用率

主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

性能测试指标

响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间

并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性

吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力

性能计数器， 描述服务器或者操作系统性能的一些数据指标

性能测试方法

性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期

负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值

压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求

稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定

Web前端优化

浏览器访问优化

减少http请求

使用浏览器缓存

启用压缩

CSS放在页面最上面，JavaScript放在页面最下面

减少Cookie传输

CDN加速

反向代理

应用服务器性能优化

分布式缓存

一般会使用消息队列，带来的额外好处是会削平峰值

1）不同的缓存服务器之间进行通信，例如JBoss Cache；

2）不同缓存服务器之间不进行通信，例如Memcached

缓存从本质上来说，就是一个内存hash表

缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

缓存也需要注意缓存热点数据

缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

对于分布式缓存来说，目前有两类：

异步操作

使用集群

代码优化

多线程

1） 将对象设计成无状态对象；

2） 使用局部对象；

3） 并发访问资源时使用锁

需要注意线程安全问题，方法：

资源复用

主要是单例和资源池（对象池）

数据结构，选择合适的算法

垃圾回收

合理设置垃圾回收策略

存储性能优化

机械硬盘 vs 固态硬盘

B+树 vs LSM树

RAID vs HDFS

5 万无一失 - 网站的高可用架构

网站可用性度量

网站不可用时间 = 故障修复时间点 - 故障发现时间点

网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%

一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

高可用的应用

无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。

通过负载均衡进行无状态服务的失效转移

负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

应用服务器集群的Session管理

Session复制

Session绑定

利用Cookie记录Session

Session服务器

高可用的服务

分级管理

核心服务与非核心服务隔离

核心服务优先使用高性能服务器

超时设置

异步调用

必须满足可以使用异步调用方式

服务降级

幂等性设计

服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

高可用的数据

数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。

主要手段：数据备份和失效转移

缓存服务高可用

观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件

数据高可用含义：

副本间数据一致

多个副本可读

同时写入数据副本

1）数据持久性

2）数据可访问性

3）数据一致性

数据一致性分类：

1） 数据强一致；

2） 数据用户一致；

3） 数据最终一致

数据备份

1） 异步热备；

2） 同步热备

冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

热备分为两种：

失效转移

1） 心跳检测（Keepalived、Heartbeat）；

2） 应用程序访问失败报告

失效确认：

访问转移

数据恢复

高可用网站的软件质量保证

网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似

一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

自动化测试

一般使用Selenium来进行测试

预发布验证

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问

代码控制

主干开发，分支发布

分支开发，主干发布，这是目前使用的主流方式

自动化发布

火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待�...