网站建设可扩展的重要性（下篇）：分布式消息队列的处理
一、可扩展性架构利用分布式消息队列降低系统耦合性：
如果模块之间不存在直接调用那么新增模块或者修改模块就对其他模块影响最小，这样系统的可扩展性无疑更好一些。
1.事件驱动架构
事件驱动架构(Event Driven Architecture)：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的EDA架构就是操作系统中常见的生产者消费者模式。在大型网站架构中，具体实现手段有很多，最常用的是分布式消息队列，如图7-1所示。
网站建设可扩展性架构经验分享示意图7-1利用消息队列实现的事件驱动架构
消息队列利用发布订阅模式工作，消息发送者发布消息，一个或者多个消息接收者订阅消息。消息发送者是消息源，在对消息进行处理后将消息发送至分布式消息队列，消息接受者从分布式消息队列获取该消息后继续进行处理。可以看到，消息发送者和消息接受者之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，而消息接受者只需要从分布式消息队列获取消息后进行处理，不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展设计。
消息接受者在对消息进行过滤、处理、包装后，构造成个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅处理该消息因此基于事件（消息对象）驱动的业务架构可以是系列的流程。
由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的响应延迟；同时，在网站访问高峰，消息可以暂时存储在消息队列中等待消息接受者根据自身负载处理能力控制消息处理速度，减轻数据库等后端存储的负载压力。
2.分布式消息队列
队列是一种先进先出的数据结构，分布式消息队列可以看作将这种数据结构部署到独立的服务器上，应用程序可以通过远程访问接口使用分布式消息队列，进行消息存取操作．进而实现分布式的异步调用，基本原理如图7-2所示。
网站建设可扩展性架构设计流程示意图7-22分布式消息队列架构原理
消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消息订司列表查找订阅该消息的消息消费者应用程序，将消息队列中的消息按照先进先出(FIFO)的原则将消息通过远程通信接口发送给消息消费者程序。
目前开源的和商业的分布式消息队列产品有很多，比较著名的如Apache ActiveMQ等，这些产品除了实现分布式消息队列的般功能在可用性、伸缩性、数据一致性、性能和可管理性方面也做了很多改善。
在伸缩性方面，由于消息队列服务器上的数据可以看作是被即时处理的，因此类似于无状态的服务器，伸缩性设计比较简单。将新服务器加入分布式消息队列集群中，通知生产者服务器更改消息队列服务器列表即可。
在可用性方面，为了避免消费者进程处理缓慢，分布式消息队列服务器内存空间不足造成的问题，如果内存队列已满，会将消息写入磁盘，消息推送模块在将内存队列消息处理完以后，将磁盘内容加载到内存队列继续处理。
为了避免消息队列服务器宕机造成消息丢失，会将消息成功发送到消息队列的消息存储在消息生产者服务器，等消息真正被消息消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中其他的服务器发布消息。
分布式消息队列可以很复杂，比如可以支持ESB（企业服务总线）、支持SOA（面向服务的架构）等；也可以很简单，比如用MySQL也可以当作分布式消息队列：消息生产者程序将消息当作数据记录写入数据库，消息消费者程序查询数据库并按记录写入时间戳排序，就实现了个事实上的分布式消息队列，而且这个消息队列使用成熟的MySQL运维手段，也可以达到较高的可用性和性能指标。
二、网站建设可扩展性架构利用分布式服务打造可复用的业务平台
使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同个消息；那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。
回顾网站架构发展历程，网站在由小到大的演化过程中，表现为整个网站是由单应用系统逐步膨胀发展变化而来，随着网站功能的日益复杂，网站应用系统会逐渐成为个巨无霸，如图7-3所示。
一个应用中聚合了大量的应用和服务组件，这个巨无霸给整个网站的开发、维护、部署都带来了巨大的麻烦。巨无霸应用系统带来如下几点问题：
一个应用中聚合了大量的应用和服务组件，这个巨无霸给整个网站的开发、维护、部署都带来了巨大的麻烦。巨无霸应用系统带来如下几点问题：1.编译、部署困难：对于网站开发工程师而言，打包构建一个巨型应用是件痛苦的事情，也许只是修改了行代码，输入build命令后，抽完支烟，回来看，还在building;又去喝了杯水，回来看，还在building;又去了次厕所，回来看，还在building;好不容易build结束， 看编译失败，还得重来……
2.代码分支管理困难：复用的代码模块由多个团队共同维护修改，代码merge的时候总会发生冲突。代码merge一般发生在网站发布的时候，经常和发布过程中出现的其他问题互相纠结在起，顾此失彼，导致每次发布都要拖到半夜三更。
3.数据库连接耗尽：巨型的应用、大量的访问，必然需要将这个应用部署在个大规模的服务器集群上．应用与数据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百台服务器集群的应用将需要在数据库上创建数干个连接。数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行般的数据操作。
4.新增业务困难：想要在一个已经如乱麻般的系统中增加新业务，维护旧功能，难度可想而知：一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了，还是不能接手业务，因为不知道水有多深。于是就出现这种怪现象：熟悉网站产品的“老人”忙得要死，加班加点干活；不熟悉网站产品的新人帮忙就出乱，跟着加班加点；整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。
深圳网站建设公司认为解决方案就是拆分，将模块独立部署，降低系统耦台性。拆分可以分为纵向拆分和横向拆分两种纵同拆分：将个大应用拆分为爹个小应用，如果新增业务较为独立，那么就直接将其设计部署为个独立的Web应用系统。
横向拆分：将复用的业务拆分出来．独立部署为分布式服务，新增业务只需要阔用这些分布式服务．不需要依赖具体的模块代码，即可快速搭建个应用系统，而模块内业务逻辑变化的时候，只要接口保持致就不会影响业务程序和其他模块。如图7-4所示。
网站建设可扩展性架构流程示意图7-4业务及模块拆分独立部署的分布式服务架构
纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的Web应用。而对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依赖关系，还需要一个完善的分布式服务管理框架。好了，其他具体应用我们也许需要在现实中见招拆招。网站建设公司旨在通过本文对我们客户在规划大型网络应用平台的时候有一定的前瞻性，并不是需要我们的客户自己动手来搭建平台，搭建这些事情您有需要可以联系我们的在线客户，为您提供更为详细的建站方案策略。谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/fach/1695.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。