首页 > 大型站点技术架构(七)--站点的可扩展性架构

大型站点技术架构(七)--站点的可扩展性架构

 

大型站点技术架构(一)--大型站点架构演化

大型站点技术架构(二)--架构模式

大型站点技术架构(三)--架构核心要素

大型站点技术架构(四)--站点的高性能架构

大型站点技术架构(五)--站点高可用架构

大型站点技术架构(六)--站点的伸缩性架构

 

 

        扩展性是指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。

        设计站点可扩展架构的核心思想是模块化,并在此基础上,减少模块间的耦合性,提供模块的复用性。模块通过分布式部署,独立的模块部署在独立的server上(集群)从物理上分离模块之间的耦合关系。

        模块分布式部署以后详细聚合方式主要有分布式消息队列和分布式服务

1、利用分布式消息队列减少系统耦合性

        假设模块之间不存在直接调用,那么新增模块或者改动模块对其它模块影响最小,这样系统的可扩展性无疑更好一些。

        事件驱动框架:通过在低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完毕模块间合作,典型的架构就是生产者消费者模式。在大型站点架构中,详细实现手段非常多,最经常使用的就是分布式消息队列,例如以下图所看到的:

 

 

 

       消息队列利用公布-订阅模式工作,消息发送者公布消息,一个或者多个消息接收者订阅消息。

       因为消息发送者不须要等待消息接受者处理数据就能够返回,系统具有更好的响应延迟;同一时候,在站点訪问高峰,消息能够临时存储在消息队列中等待处理,减轻数据库等后端存储的负载压力。

       眼下开源的和商业的分布式消息队列产品有非常多,比較著名的有Apache ActiveMQ等,例如以下是分布式消息队列的架构原理:

 

 

 

 

 2、利用分布式服务打造可复用的业务平台

        使用分布式服务是减少系统耦合性的还有一个重要手段。假设说分布式消息队列通过消息对象分解系统耦合性,不同子系统处理同一个消息;那么分布式服务则通过接口分解系统耦合性,不同子系统通过同样的接口描写叙述进行服务调用。

        大型站点分布式服务的需求与特点:

  1. 负载均衡
  2. 失效转移
  3. 高效的远程通信
  4. 整合异构系统
  5. 相应用最小入侵
  6. 版本号管理
  7. 实时监控

 眼下国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的Dubbo,下图是Dubbo的架构原理:

 

 

        服务消费程序通过服务接口使用服务,而服务接口通过代理载入详细服务,详细服务能够是本地的代码模块,也能够是远程的服务,因此相应用较小入侵;应用程序须要调用服务接口,服务框架依据配置自己主动调用本地或远程实现。

        服务框架client模块通过服务注冊中心载入服务提供者列表(服务提供者启动后主动向服务注冊中心注冊自己可提供的服务接口列表),查找须要的服务接口,并依据配置的负载均衡策略将服务调用请求发送到某台服务提供者server。假设服务调用失败,client模块会自己主动从服务提供者列表选择一个可提供相同服务的还有一台server又一次请求服务,实现服务的自己主动失效转移,保证高可用服务。

3、利用开放平台建设站点生态圈

        大型站点为了更好的服务自己的用户,开放很多其它的增值服务,会把站点内部的服务封装成一些调用接口开放出去,共外部的第三方开发人员使用,这个提供开放接口的平台被称作开放平台。

        开放平台是站点内部和外部交互的接口,外部须要面对众多的第三方开发人员,内部须要面对站点内诸多的业务服务。尽管每一个站点的业务场景和需求都不同样,但开发平台的架构设计却大同小异,例如以下图所看到的:

API接口:是开发平台暴露给开发人员使用的一组API,其形式能够是RESTfull,WebService,RPC等各种形式。

协议转换:将各种API输入转换成内部服务能够识别的形式,并将内部服务的返回封装成API格式。

安全:除了一般应用须要的身份识别、权限控制等安全手段,开放平台还须要分级的訪问带宽限制,以保证资源被公平合理的使用。

审计:记录第三方应用的訪问情况并进行监控、计费等。

路由:将开放平台的各种訪问路由映射到详细的内部的服务。

流程:将一组离散的服务组织成一个上下文相关的新服务,隐藏服务细节,提供统一接口供开发人员调用。

 

 

 

 

 

 

 

更多相关:

  • 这周本来是要写一篇Dubbo源码分析的,被突发事件耽搁了,下周有时间再补上。这周,笔者经历了一次服务雪崩。服务雪崩,听到这个词就能想到问题的严重性。是的,整个项目,整条业务线都挂了,从该业务线延伸出来的下游业务线也跟着凉了。笔者是连续三天两夜的忙着处理问题,加起来睡眠时间不足5小时,今天才得以睡个好觉。但事故之后还有很多问题等着去...

  •     由于工作中需要直接从MySQL后台读取数据,所以安装了PHPnow,装的过程中提示Apache安装失败,80端口被占用。     在cmd中输入netstat –ano命令,发现80端口被一个PID为4的服务所占用,打开任务管理器,发现PID为4的进程为系统进程,其描述信息为NT Kernel & System,在服务里面又...

  • Dubbo 2.7 版本增加新特性,新系统开始使用 Dubbo 2.7.1 尝鲜新功能。使用过程中不慎踩到这个版本的 Bug。 系统架构 Spring Boot 2.14-Release + Dubbo 2.7.1 现象 Dubbo 服务者启动成功,正常提供服务,消费者调用偶现失败的情况。错误如下图: 可以看出,主要原因为 ca...

  • 越来越多的软件,开始采用云服务。 云服务只是一个统称,可以分成三大类。 IaaS:基础设施服务,Infrastructure-as-a-servicePaaS:平台服务,Platform-as-a-serviceSaaS:软件服务,Software-as-a-service 它们有什么区别呢? IBM 的软件架构师 Albert...

  • Docker最全教程——从理论到实战(六) 原文:Docker最全教程——从理论到实战(六)托管到腾讯云容器服务 托管到腾讯云容器服务,我们的公众号“magiccodes”已经发布了相关的录屏教程,大家可以结合本篇教程一起查阅。 自建还是托管? 在开始之前,我们先来讨论一个问题——是自建容器服务还是托管到云容器服务? 这里...

  • 首先对微擎的工作原理做简单描述, 微擎使用规则和模块的机制来处理公众平台的请求数据并返回响应的结果.执行流程描述为: 粉丝用户与公众号码进行对话或交互, 而后公众平台将粉丝用户的请求消息(当前包括: 文本, 图片, 位置, 链接, 事件. 请参阅消息类型)传递给微擎系统, 微擎系统按照消息类型和对应的公众号所设定的规则列表匹配到合适的...

  • 消息队列的使用场景以下介绍消息队列在实际应用常用的使用场景。异步处理、应用解耦、流量削锋和消息通讯四个场景。1】异步处理:场景说明:用户注册后,需要发注册邮件和注册短信。引入消息队列后架构如下:用户的响应时间=注册信息写入数据库的时间,例如50毫秒。发注册邮箱、发注册短信写入消息队列后,直接返回客户端,因写入消息队列的速度很快,基...

  • 下面是我凭记忆想到的几个题目,有需要的同学就拿去吧,我也算做了点善事. 中体骏彩C++笔试题 2013-11-18 1.指针的含义是:B A.名字 B.地址 C.名称 D.符号 2.给出下面的程序输出: #include #include #include ...

  • 双端通信描述 利用消息队列针对发送接受消息的类型唯一性 进行多个客户端之间消息传递,而不需要server端进行消息转发。 同时消息队列的读阻塞和写阻塞特性(消息队列中已经写入数据,如果再不读出来,则无法再次写入)让消息队列的实现过程只能如下: 客户端1的父进程用来处理类型1的消息写,子进程处理类型2的消息读客户端2的父进程处理类型...

  • 文章目录基本介绍编程接口代码实例消息队列的发送和接收消息队列中的消息对象的属性控制 基本介绍 支持不同进程之间以消息(messages)的形式进行数据交换,消息能够拥有自己的标识,且内核使用链表方式进行消息管理。进程之间的通信角色为:发送者和接受者 发送者: a. 获取消息队列的ID(key或者msgid) b. 将数据放入...