找独服我们都知道Amazon Web在云服务器平台的选择上。
服务(AWS)作为云计算和数据解决方案领导者的重要性。随着越来越多的公司发现自己在处理大量数据，确保获得大数据解决方案来计算和分析这些数据非常重要。
AWS提供了各种云计算工具，可以提供从计算大数据的框架到理解数据的分析的一切。
找独服除了大家熟悉的国内三大厂，如阿里云、腾讯云、华为云等国际站平台，国外也有很多优质的云厂商支持该服务，如AWS、Azure、Google Cloud等。与国内云厂商相比，由于业务情况不同，其服务是差异化的。其中，AWS亚马逊云也是很多用户的热门选择之一。
AWS有哪些技术解决方案？
1.容灾:既然说了云服务商的事故，那就先说一下灾难。AWS在这里踩了很多坑，收获了很多宝贵的经验。
第一个是可用性区域。可用性
区域是容灾最重要的部分。在全球分布aws的几个地区，每个地区都有几个独立的数据，这些数据在物理上相隔一定的距离，但不会太远(大约5-15英里)。
中心，也称为可用性
区域(AZ).物理独立是指:独立的机房、独立的供电系统、独立的ISP接入系统等。这就保证了在一个AZ完全没电的情况下(比如停电、网络故障，甚至是修路队的傻“实习生”挖光缆导致的ISP故障)，你的应用在另一个AZ上仍然可以正常使用。
这一点非常重要。几个AZ保持距离但不太远保证了物理容灾，同时你几乎可以把它们等同于相同的数据。
中心在应用程序级别执行灾难恢复。例如，数据库的master/savle安装在两个不同的AZ中，而不用太担心网络级别的性能(round
行程几乎可以忽略不计，也就是几百us到最多几ms，请用光速和距离来计算)。
当然，一个城市的电力系统可能整体瘫痪，一个国家的跨海光缆可能被海啸切断，所以AWS也有地域的概念。这些区域跨越几个大洲，确保如果整个区域被物理挂起，应用程序可以继续服务，如果它是跨区域的容灾的。而应用跨区域容灾并不容易，距离增加了两个数量级，使得区域间的网络传输可能高达数百ms到数百ms，从量变到质变，一些简单的应用层容灾手段(如直接使用数据库的主/从)无法使用。
但说实话，大部分使用云服务提供商的应用都达不到跨地域容灾的水平(这个级别，应该有强大的devops。
队来处理这种快乐的悲哀)，所以才考虑渡海阿兹。
如果你选择云服务提供商，问他们是否有类似AZ的概念，你的web服务器，数据库。
服务器可以跨AZ部署吗？这是应用的种子期(拥有成千上万的用户)之后首先要考虑的事情。当然，如果直接上AWS，那么基本容灾无忧。
容灾的另一个方面是数据备份。你需要一个合适的备份/恢复机制。AWS提供S3/冰川来存储文件类型的数据。数据备份是为了对付墨菲斯。
定律，当最坏的情况发生时(数据丢失)，你对服务恢复有多大的容忍度，就决定了你有多大的操作空间。如果您可以忍受最多一个小时的数据丢失，那么至少每10-30分钟进行一次数据(增量)备份。这样，当DBMS上的数据被恶意删除(并同步到slave)，或者出现断电文件系统损坏时，备份就是你的七叔了。
但是，备份不仅必须放在本地，而且必须存储在像S3这样具有数据冗余的可靠云存储服务中。这种服务通常将一块数据分成n个片，并存在于不同的物理位置。只要K个切片可用，就可以恢复文件。基本上，存储在类似系统上的文件可以被认为没有丢失。当然，最好是对关键数据进行不同级别甚至离线的备份，所以AWS提供了像glacier这样的慢速存储，几乎无限的存储空间，价格便宜(S3的1/3)，但是如果要从中恢复数据，需要几个小时数据才能准备好(所以在维基百科上推断glacier用的是磁带或者blue)。
像光盘一样离线存储数据)。
过时的备份数据也可以定期清除，节省开支。
2.安全性:一个好的云服务提供商不仅要为你提供合适的计算能力和存储能力来部署你的应用，还要提供一些安全保障。让我们看看AWS提供了哪些安全措施。
首先是iam(身份与访问管理)，即身份权限管理系统。安全的首要原则是最少。
前情提要.就像您永远不应该使用root访问远程设备一样(最好禁用
Root)，当您访问云提供商时，您不应该与每个团队成员共享您的初始帐户(相当于root)。您应该为每个不同的角色创建不同的帐户(如果云提供商提供了此功能，如果没有，您的云提供商需要重新学习安全性。
101)，提供最低的访问权限。比如devops可以控制生产环境，dev/qa就不行。不仅权限是分离的，而且任何操作都必须有一个日志，可以用于审计后的目的:需要清楚谁在哪一天做了什么操作(例如，谁创建了一个实例并禁用了一个服务)。
其次是内外网分离。在大多数情况下，您的大多数服务器(如数据库)不需要暴露在公共网络上。您最好使用公共IP部署一个(或多个)负载。
平衡器(LB)类似于AWS的ELB(弹性负载)。
平衡器)，将您的N层应用程序隐藏在LB后面。这样除了外部LB，其他所有服务器都在一个内网内，没有公共IP，堵住了黑客直接入侵的可能。
当然，你的团队需要访问这些服务器。可以跨内网和网络边界的内网部署一台服务器，可以用这台服务器作为跳板登录同一子网内的内网其他服务器。比较安全的方法是设置openVPN，通过SSLVPN访问内网来访问这些设备(详见我之前的文章:应用开发中的网络安全)。
之后，你需要认真考虑网络的访问权限，设置物理或虚拟防火墙。AWS的安全组(SG)就是这样一个简单的ACL(Access)
List)防火墙，可以设置允许流入和流出本级的端口，以及源IP地址。当然，在服务器的iptables中，也需要进行相应的设置。安全是分等级的，建不出极其坚韧的大门就不能高枕无忧:城外的壕沟、护城河、城墙、城内的瓮城都需要配置。
这一切都不够。根据您的开发和部署流程，您可能需要开发环境、试运行环境(QA
测试)，以及生产环境，根据上面的定义，每一套都有不同的安全标准和访问权限。在VPC AWS(虚拟私有)
Cloud)可以很容易的帮你定义这些环境，你的云服务提供商最好也有同样的概念，或者你可以通过划分子网(以及子网的访问权限)来提供简单的隔离。
3.该服务是可扩展的
很多人说起AWS，第一个说的就是EC2的autocaling。缩放不是简单的计算缩放。
Up/out概念，而是一揽子解决方案。在考虑扩展之前，最好做好基本的容灾(至少准备一份)和安全(善良一点，至少不要在公网上裸奔你的数据库，不要用密码直接登录你的ssh服务器等等。)，然后再讲这个基础之后的缩放。没有容灾能力和安全性的规模扩张，就像在地震活跃区打一个浅地基，盖一座无门窗无处通风的摩天大楼。
AWS提供了几个级别的扩展:
计算:EC2自动缩放.使用ELB，服务的计算能力可以随着业务需求自动增加或减少。
存储:S3可以看作是一个访问时间不变的无限存储器。
数据库:dynamodb(NoSQL)没有任何管理，只关心业务逻辑和额度；以及需要基本管理(但不需要打补丁之类的事情)的RDS(关系型)。
SQS:没有任何管理的无限容量和恒定访问速度的消息队列。
缓存:需要管理的弹性缓存(使用memcached或redis)。
这个基本不需要大数据处理，流媒体处理，机器。
学习应用的基础服务(AWS有相应的服务)。当然，在早期的产品中，扩展性问题主要集中在web/app上。
在服务器和数据库服务器上，你应该根据需要将更多的web/app放在不同AZ下的LB后面。
服务器(如果你的云服务提供商可以自动。
伸缩性不能再好了，早期没什么大不了的)，然后数据库除了跨AZ的主/从配置之外还增加了几个Read。
复制品.一写多读可以满足scaling的大部分需求，除非你的应用比较特殊，多写少读(这种情况下可以考虑那些专门设计的优先考虑写速度的数据库服务器，比如cassandra)。
4.未来的扩展其实主要是在数据层面:静态资源放在CDN，session。
Store使用elastic cache或DynamoDB，将一些复杂的查询结果塞进elastic cache，减少对数据库的请求；然后数据库进一步划分。根据读写的大小，不同大小的表在不同的数据库中是独立的，然后频繁设置更多的read进行读写。
复制品.此数据库拆分多个数据库，并在不同的副本集中运行。
过了这一步，如果数据层不能改或者不想改DynamoDB，还是用RDS，AWS帮不了你什么。下一步是应用程序细分。应用程序的不同部分可以通过队列获得
解耦，然后各自独立开发，独立向外扩展，就像数据库一样。这就是所谓的微服务，或者说面向服务。
架构(SOA).AWS提供SQS来帮助您完成这一改变。如果你的云服务提供商不具备类似的能力，你也可以根据服务需求部署kafka(未使用)和rabbitmq等消息队列和消息分发软件。
5.未来，用户还在飙升。如果你已经成功切换到DynamoDB，你只需要提供更多的读写配额让AWS为你进行横向扩展，但是如果你仍然对SQL感兴趣，
如果DB一直不走，那就要走数据库表的分片了，但这个时候，你可能已经接近下一个instagram了。所以，就算切桌子疼，心情还是舒服的。任何问题就像躺在马尔代夫的沙滩椅上，吹着海风，看着比基尼享受着精油按摩，睁着眼睛被蚊子咬一样。
多说两句DynamoDB。DynamoDB是AWS的专有技术，但亚马逊
Publish-related paper催生了riak这样的开源产品，有着相同的概念。根据我粗浅的理解，这种可以无限扩展的NoSQL数据库的核心是一致的。
哈希:
一致的
哈希的概念是，我有一个足够大的keyspace(2的160次方，比较:IPv6的2的128次方)，我们把它记为X，然后把X放在一个环形空间里，分成大小相等的Y个分区，依次循环排列(如图)。每个分区由一个VNODE管理(Riak的概念)。当您有M个数据库时，
服务器(节点)，y个vnodes平均映射到m个节点。当要插入数据时，其主键(散列
Key)到k中的地址(addr)，到vnode，然后到节点。如果该数据需要n个副本，则将数据写入addr(vnode)。
a)，addr + 1(vnode b)，…，add + N(vnode
n).在这个设置中，m是你的碎片，n是复制品。将来添加新节点时，映射会发生变化，只需将相应变化的vnode迁移到新节点即可。在这种结构下，分片/复制对程序员来说基本是透明的。
因此，查看AWS解决方案并思考它为什么提供这样一个工具，将有助于我们思考我们自己的应用程序的架构，并在必要时找到替代产品。
评论前必须登录！
注册