架构师之路 — 部署架构 — Overview（架构师之路 沈剑）

目录

文章目录

目录

部署架构 5 大要素

1、性能

2、可用性

3、伸缩性

4、扩展性

5、安全性

部署架构技术手段

分布式系统架构

横向分层

纵向分割

分布式

集群

缓存

CDN 静态化数据

异步

冗余

自动化

安全

部署架构 5 大要素

一般说来，除了功能需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这 5 个要素。

1、性能

性能是网站的一个重要指标，任何软件架构设计方案都必须考虑可能会带来的性能问题。也正是因为性能问题几乎无处不在，所以优化网站性能的手段也非常多，主要的方式可以总结如下：

浏览器：浏览器缓存、使用页面压缩、合理布局页面、减少 Cookie 传输等。

CDN 和反向代理。

本地缓存和分布式缓存。

异步消息队列。

应用层：服务器集群。

代码层：多线程、改善内存管理等。

数据层：索引、缓存、SQL 优化等，以及合理使用 NoSQL 数据库。

2、可用性

网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。

对于应用服务器而言，多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一台服务器宕机，只需把请求切换到其他服务器即可，但是一个前提条件是应用服务器上不能保存请求的会话信息。

对于存储服务器，需要对数据进行实时备份，当服务器宕机时需要将数据访问转移到可用的服务器上，并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。

除了运行环境，网站的高可用还需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能。

3、伸缩性

衡量架构伸缩性的主要标准有：是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器，加入新的服务器后是否可以提供和原来的服务器无差别的服务，集群中可容纳的总的服务器数量是否有限制。

对于应用服务器集群，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。

对于缓存服务器集群，需要使用高效的缓存路由算法，避免加入新服务器导致路由大面积失效。

关系数据库很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

至于大部分 NoSQL 数据库产品，由于其先天就是为海量数据而生，因此其对伸缩性的支持通常都非常好。

4、扩展性

衡量架构扩展性的主要标准就是不同产品之间是否很少耦合。在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。

网站可伸缩架构的主要手段是事件驱动架构和分布式服务。

事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。

分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。可复用服务升级变更的时候，也可以通过提供多版本服务对应用实现透明升级，不需要强制应用同步变更。

5、安全性

网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

部署架构技术手段

分布式系统架构

大型网站要很好支撑高并发，需要长期的规划设计。在初期就需要把系统进行分层，在发展过程中把核心业务进行拆分成模块单元，根据需求进行分布式部署，可以进行独立团队维护开发。

横向分层

将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。

通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护。各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。

但是分层架构也有一些挑战，就是必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层调用及逆向调用。在实践中，大的分层结构内部还可以继续分层。

比如把电商系统分成：应用层，服务层，数据层等，具体分多少个层次根据自己的业务场景。分层架构是逻辑上的，在物理部署上可以部署在同一台物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，分别部署在不同的服务器上，使网站可以支撑更多用户访问。

应用层：网站首页，用户中心，商品中心，购物车，红包业务，活动中心等，负责具体业务和视图展示。

服务层：订单服务，用户管理服务，红包服务，商品服务等，为应用层提供服务支持。

数据层：关系数据库，NoSQL 数据库等，提供数据存储查询服务。

分层架构是逻辑上的，三层结构可以部署在同一个物理机器上。但是随着网站业务的发展，必然需要对已经分层的模块分离部署，使网站拥有更多的计算资源以应对越来越多的用户访问。

纵向分割

分层是将软件在横向方面进行切分，分割则是在纵向方面对软件进行切分。

网站越大，功能越复杂，服务和数据处理的种类也越多。将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。比如用户中心可以分割成：账户信息模块，订单模块，充值模块，提现模块，优惠券模块等

分布式

分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器。当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群。

分布式静态资源，比如：静态资源上传 CDN。

分布式计算，比如：使用 Hadoop 进行大数据的分布式计算。

分布式数据和存储，比如：各分布节点根据哈希算法或其他算法分散存储数据。

但分布式在解决网站高并发问题的同时也带来了其他问题。典型的有下面几点：

意味着服务调用必须通过网络，这可能会对性能造成比较严重的影响。

服务器越多，宕机的概率也就越大，造成的服务不可用可能会导致很多应用不可访问，使网站可用性降低。

数据在分布式的环境中保持数据一致性非常困难，分布式事务也难以保证。

系统依赖错综复杂，开发管理维护困难。

因此分布式设计要根据具体情况量力而行。常用的分布式方案有：

分布式服务

分布式数据库和存储

分布式计算

分布式配置

分布式锁

分布式文件系统

分布式静态资源

等。

集群

使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块，还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。例如：应用服务器，数据库，NoSQL 数据库。

核心业务基本上需要搭建集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可。另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。

应用服务器集群：

Nginx 反向代理

SLB

等

数据库集群：

主从分离，从库集群

等

缓存

缓存是改善软件性能的第一手段，在复杂的软件设计中，缓存几乎无处不在。

使用缓存有两个前提条件：

数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；

数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。

缓存除了可以加快数据访问速度，还可以减轻后端应用和数据存储的负载压力，网站数据库几乎都是按照有缓存的前提进行负载能力设计的。例如：高并发业务接口多数都是进行业务数据的查询，包括：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中。

高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数，单台数据库服务器允许的最大连接数量是有限的。

这种高并发的业务接口要考虑缓存设计。数据不经常变化，我们可以把数据进行缓存，缓存的方式有很多种，一般的：应用服务器直接 Cache 内存，主流的：存储在 Memcached、Redis 内存数据库。其中，Cache 是直接存储在应用服务器中，读取速度快。内存数据库服务器允许连接数可以支撑到很大，而且数据存储在内存，读取速度快，再加上主从集群，可以支撑很大的并发查询。

这样不仅可以提高接口响应速度，也可以节约服务器带宽，虽然有些服务器带宽是按流量计费，但是也不是绝对无限的，在高并发的时候服务器带宽也可能导致请求响应慢的问题。

CDN 静态化数据

随着业务不断发展，用户规模越来越大，不同地区的用户访问网站时，速度差别也极大。为了提供更好的用户体验，网站需要加速网站访问速度。主要手段有使用 CDN 和反向代理。

高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成 JSON，XML，HTML等数据文件上传 CDN，在拉取数据的时候优先到 CDN 拉取，如果没有获取到数据再从缓存，数据库中获取，当管理人员操作后台编辑数据再重新生成静态文件上传同步到 CDN，这样在高并发的时候可以使数据的获取命中在 CDN 服务器上。

CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

CDN 节点同步有一定的延迟性，所以找一个靠谱的 CDN 服务器商也很重要。

异步

应用系统的一个重要目标是降低耦合性。系统解耦的手段除了前面提到的分层、分割、分布式等，还有一个重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响，这对网站扩展新功能非常便利。除此之外，使用异步消息队列还有如下优点：

提高系统可用性：消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器恢复正常后，继续处理消息队列中的数据。

加快网站响应速度：处在业务处理前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少。

消除并发访问高峰：用户访问网站是随机的，存在访问高峰和低谷。使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。

例如：在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的。当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现 connection time out 的情况。

像这种涉及数据库操作的高并发的业务，就要考虑使用异步了。客户端发起接口请求，服务端快速响应，客户端展示结果给用户，数据库操作通过异步同步。

使用消息队列，将入库的内容 enqueue 到消息队列中，业务接口快速响应给用户结果。

然后再写个独立程序从消息队列 dequeue 数据出来进行入库操作，入库成功后刷新用户相关缓存，如果入库失败记录日志，方便反馈查询和重新持久化。

这样一来数据库操作就只有一个程序（多线程）来完成，不会给数据带来压力。但需要注意的是，使用异步方式处理业务可能会对用户体验、业务流程造成影响，需要网站产品设计方面的支持。

冗余

网站需要7×24小时连续运行，但是服务器随时可能出现故障，特别是服务器规模比较大时，出现某台服务器宕机是必然事件。

要想保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。

访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。数据库除了定期存档进行冷备份外，还需要对数据库进行主从分离，实时同步实现热备份。

自动化

目前应用系统的自动化架构设计主要集中在发布运维方面，通过自动化可以减少人工的操作的成本，而且可以快速操作，避免人为操作上面的失误。包括：

自动化发布

自动化代码管理

自动化测试

自动化安全监测

自动化部署

自动化监控

自动化告警

自动化失效转移与恢复

自动化降级和自动化分配资源

等

安全

系统在安全架构方面也积累了许多模式：

通过密码和手机校验码进行身份认证；

登录、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理；

为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别；

对于常见的用于攻击网站的 XSS 攻击、SQL 注入、进行编码转换等相应处理；

对于垃圾信息、敏感信息进行过滤；

对交易转账等重要操作根据交易模式和交易信息进行风险控制。

分布式 网站

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。