1703952477
1703952478
物理资源管理,对服务器、存储设备、交换机设备的统一管理系统,基于物理硬件的自动维护、上架和下架、重启等。
1703952479
1703952480
自动调度和监控,功能包括自动添加和踢出应用节点,根据负载自动调节资源数量,提供基于云端的监控服务。
1703952481
1703952482
以上就是企业私有云平台的架构组成,可提供一个私有云的Portal,供企业用户一站式地对IT资源进行管理,包括成本结算、权限控制、资源分配、部署应用程序等。
1703952483
1703952485
9.2.3 服务治理平台架构设计
1703952486
1703952487
在上节“9.1.1大型电商网站架构设计”中,我们提到了大型电商网站是基于SOA架构的,如此大规模的服务架构,需要一个高效、快速、优雅的服务治理平台,本节就给大家介绍,如何搭建一个高效的服务治理平台。
1703952488
1703952489
服务治理平台,建立的初衷是:实现对服务健康状况的管理、跟踪每个服务请求的全生命周期,可实现故障隔离、优雅降级,快速响应和定位问题,可管理服务之间的依赖关系。我们将采用分布式架构、无中心、无单点的设计原则来设计这个服务治理平台。
1703952490
1703952491
如图9-12所示,这就是服务治理平台的架构设计,采用了ZooKeeper、Detector、消息中间件、MySQL、MongoDB等开源技术进行搭建。
1703952492
1703952493
1703952494
1703952495
1703952496
图9-12 服务治理平台架构
1703952497
1703952498
下面我们来看它们是如何工作的。
1703952499
1703952500
步骤1:服务提供方(Service Provider),首先要向ZooKeeper Cluster提交注册申请,注册成功后才可以对外提供服务。
1703952501
1703952502
步骤2:ZooKeeper Cluster把可用的服务提供方列表,推送给服务使用方(Service Consumer),服务使用方只能使用列表里认证的服务提供方。
1703952503
1703952504
步骤3:服务使用方,向服务提供方请求服务。
1703952505
1703952506
步骤4:服务提供方,成功回应服务请求方的请求。
1703952507
1703952508
同时,服务提供方、服务使用方,都会推送一条调用日志给Jumper Broker,信息的主要内容是调用频次、响应时间等,Jumper Broker把这些信息经过分析和处理后,把结果发送给Detector。
1703952509
1703952510
Detector记录这些信息,并且把这些信息推送给ZooKeeper Cluster。
1703952511
1703952512
如果某个服务的响应时间越来越慢,ZooKeeper Cluster就会发现,并且及时做出调整,比如,不再给这个服务分配那么多的调用量,直到它的状态恢复正常为止。
1703952513
1703952514
从图9-12中,注意到ZooKeeper Cluster、Jumper Broker、Detector都是集群部署,确保了服务治理平台本身的高可用性,在技术实现上也采用异步消息机制、RPC框架,使得架构本身无中心、无单点,可支持上万个节点。
1703952515
1703952516
部署起来也非常简单,只要把服务治理平台的客户端,跟服务一起部署,做些简单配置就可以了。
1703952517
1703952519
9.2.4 分布式文件存储架构设计
1703952520
1703952521
分布式文件存储系统,解决的是大文件存储的问题,传统的解决方案是,使用几台NFS存储设备,对图片、视频等大文件进行存储,NFS存储容量一般是3TB左右,单机做raid,双机备份,一读一写。一般的NFS存储,最大支持1亿张的图片,不可扩展。所以这个方案成本比较高,在硬件故障的情况下,服务的可用性存在很大风险。
1703952522
1703952523
我们的架构目标是:伸缩性强、高可用性、高性能、低成本。同时,要具备易用性,支持POSIX,本地化可读可写,高并发读写,高灾备,高稳定性,可线性扩展,可支持海量文件,可存储超大文件。
1703952524
1703952525
这里我们以开源框架FastDFS为基本框架,给大家展示如何设计分布式文件存储系统,如图9-13所示是分布式文件存储的架构,从图中可以看到,架构主要分成两部分:Storage Server、Tracker Server。
1703952526
[
上一页 ]
[ :1.703952477e+09 ]
[
下一页 ]