云计算

云计算参考架构几例

本文主要是介绍云计算参考架构几例,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

云计算参考架构:

 

 上图阐释如何创建私有和混合云,最终用户可以自行提供计算、 存储和网络。许多大型组织开始创建内部的私有云,来增强其数据中心战略。

58同城的云架构:

 

百度社区的云架构

 

 结合对弹性服务的理解,第一个是弹性伸缩,你让你的业务随着你的性能,随着你的流量,随着业务的变化自动的伸缩流量,这是第一个点。第二个点是我能够自动的屏蔽异常处理,我的机器出问题的时候,对业务是透明的,也是没有影响的。

 

 有道笔记 云架构:

 

 

在整个云存储系统中,可以采用的开源技术,主要开发语言有:C、PHP、Erlang、Python,开源产品有:Nginx、GraphicsMagick、MySQL、Memcached、Hadoop、Redis、Squid、Heartbeat、IPVS BIND

需要考虑的技术平台:

o->  Java平台

>  Grails模仿Rails的Java平台实现

> Java_web 普通Java web程序

>  Lift基于Scale的web框架

>  Spring 流行的Java框架

o->  Ruby平台

>  Rack  最小化的Ruby Web框架

>  Rails3 一站式的Ruby Web框架

>  Sinatra 极简主义的Ruby Web框架

o->  Python平台

>  Django 最流行的PythonWeb框架

>  Wsgi Python的CGI

o->   其他平台

>  Static page 静态页面

>  node.js 异步Web框架

>  Erlang

>  php

>  standalone 独立的程序

存储

       ×->   DB

-  Mongodb 最流行的Nosql数据库

-  Mysql传统开源关系数据库

-  Neo4j图数据库

-  Postgresql Mysql的有力竞争者

-  Redis极快的内存KV数据库

×->  存储

-  Atmos EMC专业存储

- FileSystem 远程NFS支持

-  Vblob 提供Amazon S3支持

×->  其他

-  RabbitMQ 出色的Erlang队列系统

 

云计算系统架构的四个方面有怎样的影响

  • 可扩展性:我能否增加资源以处理增加的需求?
  • 可用性:我的应用能否容忍短暂的和持久的故障?
  • 可管理性:我是否有办法了解生产系统的健康和性能?
  • 可行性:我能否在时间和成本预算之内构建和维护这个系统?

 

可扩展性

可扩展性来自于两个方面:资源和密度。能力是指增加额外的硬件,它可能微不足道(在一个负载均衡器后增加额外的网络服务器)也可能非常地困难(增加一个次要的数据库服务器)。密度是指你能以怎样的效率去使用已经拥有的能力。传统的性能调优可以大幅地增加密度。

可度量的资源

可度量的资源是某些需要小心监控的东西。举例来说,数据库连接就是一种可度量的资源。作为一种有限的资源,滥用它就会大幅度地降低密度。其他可度量资源的例子还包括认证服务器和第三方网络服务。这些有时被称为“隐形的资源”,因为开发人员设计架构时经常会忽略掉它们。

通过队列负载均衡

上传时的峰值可能会成为问题,尤其是在那些针对大量读取工作负载优化过的系统上。一种降低这种峰值的方式是,通过使用队列以等待时间交换可用性。 在这种方案下,新数据在数据库中不是同步保存的。相反,它们会被放到一个队列中,这是个后台进程监控器。这个后台进程可以使负载趋于平滑,以便数据库始终会被使用,而不是某些时候忙,其他时候闲。 使用队列的其他好处是可以批量处理那些工作。一般来说,把信息批量写入到数据库中要比一次一条记录快得多。
最后要说的是,这还增加了解耦点。后台进程或数据库可以宕掉,完全不会影响前端应用接受新数据的能力。

改善消息队列的可用性

如果过多的消息是被同时接收的,可以使用辅助的消息队列去保存过量的部分。为了做到这一点,你需要设计应用能够支持多个队列,即使最初你打算只部署有一个队列的应用。

记录错误的数据

大多数开发人员都很清楚需要去验证数据,但是当验证失败的时候,他们不知道做什么。仅仅弃掉数据和抛出错误是不够的。应该把错误的数据以它原有的格式记录下来,以便开发人员能够断定为什么会有这种错误的请求。

这篇关于云计算参考架构几例的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!