云服务器平台的选择上，我们都知道Amazon Web Services(AWS)作为云计算和数据解决方案领导者的重要性。随着越来越多的公司发现自己正在处理大量数据，确保访问大数据解决方案以计算和分析此数据非常重要。 AWS提供了各种各样的云计算工具，可提供从计算大数据的框架到用于理解该数据的分析等所有内容。

互联数据除了大家熟悉的国内三大厂阿里云、腾讯云、华为云等国际站平台提供代充服务外，国外也有好多优质的云厂商支持代充服务，如：AWS、Azure、谷歌云等，相较于国内云厂商，因不同的商业条件，导致各自的服务差异化，在其中，AWS亚马逊云也是众多用户热门选择之一。

AWS云计算解决方案：https://www.hkt4.com/zt/2023-05-06/

AWS的技术解决方案有哪些?

1、容灾：既然我们讲到了云服务商的事故，那么，就先从容灾讲起。AWS在此踩了很多坑，也收获了很多宝贵的经验。

首先是availability zone。availibility zone是容灾的最重要一环。在aws分布全球的若干个region里，每个region都有若干个物理上相隔一定距离但又不太远(大概5-15miles)的数个独立的data center，也叫availibility zone(AZ)。物理上独立的意义是：独立的机房，独立的供电系统，独立的ISP接入系统等。这保证在一个AZ完全挂掉的情况下(比如电力故障，网络故障，甚至修路施工队的愚蠢的「实习生」挖断了光缆导致的ISP故障等)，你的应用在另一个AZ还能正常使用。

这一点很重要。若干AZ保持距离但又不太远保证了能够物理容灾的同时，你还可以将其几乎等同于同一个data center进行应用层面的容灾，比如说database的master/savle分别架在两个不同的AZ而不必过分担心网络层面的性能(round trip几乎可以忽略不计，也就几百us到至多几个ms，请自行用光速和距离计算)。

当然一个城市的电力系统可能整体出故障，一个国家的跨海光缆可能被海啸切断，所以AWS还有region的概念。这些region分跨数个大洲，保障物理上一个region整体挂掉的情况下，如果应用做了跨region的容灾，还能继续服务。但应用程序跨region的容灾不好做，距离上增加了两个量级，使得region之间的网络传输可能高达上百ms至几百ms，量变到质变，一些简单的应用层容灾手段(比如直接采用数据库的master/slave)，便无法使用。

不过说句实话，大部分使用云服务商的应用程序还到不了需要跨region容灾的程度(到了这个程度，应该有一只强悍的devops team来处理这种happy sorrow了)，所以，考虑跨AZ就好。

如果你选择一个云服务商，问问他们是否有类似AZ的概念，你的web server，database server能不能跨AZ部署。这是一个应用过了种子期(有了上千用户)首先该考虑的事情。当然，如果你直接上AWS，那么基本的容灾无忧了。

容灾的另一个层面是数据备份。你需要合适的backup/restore机制。AWS提供了S3/Glacier来存储文件类型的数据。数据备份是应对Murphy’s law的，当最坏的事情发生(数据丢失)，对于服务恢复，你究竟有多大的容忍度，决定了你有多大的操作空间。如果你能容忍丢失至多一个小时的数据，那么，起码设置每隔10-30分钟的数据(增量)备份，这样，当DBMS上的数据被恶意删除(并且被同步到了slave)，或者出现掉电文件系统corrupt的情况，备份就是你可耐的七舅老爷。

但是，备份一定不要仅仅放在本地，请务必存储在某个靠谱的，像S3这样的自带数据冗余的云存储服务上。这样的服务一般是把一份数据分成N个切片存在不同的物理位置，只要其中K个切片可用，就能还原出文件。基本上，存储在类似的系统上的文件可以认为是不会丢失的。当然，关键性的数据最好分级备份甚至线下备份，AWS就为此提供了glacier这样的慢速存储，存储空间几乎无限，价格便宜(S3的1/3)，但如果想从中恢复数据，需要几个小时数据才能准备好(因此有wikipedia上有推断glacier是用tape，或者blue ray disk这样的离线方式存储数据)。

陈旧的备份的数据也可以定期清除，节省开销。

2、安全：一个好的云服务商不仅仅要为你提供合适的计算能力和存储能力来部署你的应用，还需要提供某些安全保障。我们看AWS提供了哪些安全手段。

首先是IAM(Identity and Access Management)，也就是身份可权限管理系统。安全的首要原则是least previlige。就像你永远不该使用root来访问一台远程设备(最好disable root)一样，当你访问一个云提供商，你也不应该将初始账户(相当于root)分享给每个团队成员使用，你应该为每个不同的角色创建不同的账号(如果云提供商提供这样的功能，如果没有，你的云提供商需要重新学习security 101)，提供最低的访问权限。比如说，devops可以控制production环境，但dev/qa不能。不但权限分离，任何操作都要有可以用于事后审计的log：谁在哪一天做了什么操作(比如说创建了一个instance，谁disable了某个服务)，需要一清二楚。

其次是内外网分离。绝大多数情况下，你的大部分服务器，如database，是不需要暴露在公网上的。你最好部署一个(至多个)拥有公网IP的load balancer(LB)，类似于AWS的ELB(Elastic Load balancer)，将你N-tier的应用隐藏在LB之后。这样，除了对外的LB之外，其他服务器均在一个内网之内，没有公有IP，阻断黑客直接入侵的可能。

当然你的团队需要访问这些服务器。你可以在网络的边界部署跨内外网的服务器，可以以这台服务器为跳板，登入同一个子网内的内网的其他服务器。更安全的方式是设置openVPN，通过SSLVPN的方式接入到内网，从而访问这些设备(详细信息请参考我之前的文章：应用开发中的网络安全)。

之后你需要认真考虑网络的访问权限，设置物理的或者虚拟的防火墙。AWS的Security Group(SG)就是这样一个简单的基于ACL(Access List)的防火墙，你可以在这个级别设置允许流入流出的端口，以及源IP地址。当然，在服务器的iptables里，你也需要做相应的设置。安全是有层级的，不能打造了个无比强硬的门就高枕无忧了：城外的地壕，护城河，城墙，城内的翁城都是要配置的。

这一切还不够，按照你的开发部署流程，你很可能需要dev环境，staging环境(QA testing)，还有production的环境，每套按照上面的定义，都各自有不同的安全标准和访问许可。在AWS里，VPC(Virtual Private Cloud)可以很方便地帮你定义出这些环境，你的云服务商最好也有相同的概念，或者你通过划分子网(和子网的访问权限)，自行提供简单的隔离。

3、服务可伸缩

很多人言及AWS，谈到的首先是EC2的auto scaling。scaling不是简单的computation scale up/out的概念，而是一揽子解决方案。在考虑scaling之前，最好先把基本的容灾(起码备个份)，和安全(行行好，最起码不要把你的数据库裸奔在公网上，不要直接用密码登陆你的ssh服务器等等)做好，有了这个基础，再谈scaling。没有容灾和安全的scaling，就像在地震活跃带，打个浅浅的地基，盖了一个没有门没有窗，四处透风的摩天大厦。

AWS提供几个层面的scaling：

Computation：EC2 auto scaling。配合ELB，可以让服务的计算能力随业务需求自动增减。

Storage：S3可以认为是一个无穷大的，访问时间恒定的storage。

Database：无需做任何管理，只需关心业务逻辑和配额的dynamodb(NoSQL);以及需要基本的管理(但不需要做打patch这样的事)的RDS(Relational)。

SQS：无需任何管理，可以认为容量无限大，访问速度恒定的Message Queue

Cache：需要一定管理的Elastic Cache(使用memcached或redis)

这基本上是不需要大数据处理，不需要流媒体处理，不需要machine learning的应用的基本服务了(AWS都有对应的服务)。当然，在早期的产品里，面临的scaling的问题还主要集中在web/app server和database server上，你更多地考虑在LB后面根据需要在不同的AZ下放置更多的web/app server(如果你的云服务商能够做auto scaling再好不过，没有在早期也不是大事)，然后数据库除了跨AZ的Master/Slave的配置外，加上若干个Read replica。一写多读能应付大部分scaling的需求，除非你的应用是特殊的，写多读少的应用(此时考虑那些专门设计的，优先写速度的数据库服务器，如cassandra)。

再往后的scaling，其实主要也是在数据层面腾挪：静态资源放CDN，session store使用ElastiCache或者DynamoDB，某些复杂的查询结果塞到ElastiCache里减少对数据库的请求;然后数据库进一步切分，根据读写的量级，把不同量级的表独立在不同的数据库，然后对读写频繁的设置更多的read replica。这个一个数据库切分多个数据库，运行在不同的replica set里。

走过了这一步，如果数据层面无法换或者不想换DynamoDB，依旧使用RDS，AWS能帮你的也不多了。接下来就是应用程序的切分。应用的不同部分也许可以通过queue decouple，然后每个独立发展，独立scale out，就像数据库所做的那样。这便是所谓的micro service，或者service oriented architecture(SOA)。AWS提供了SQS帮你完成这个变化，如果你的云服务商没有类似的能力，也可依服务的需求部署kafka(没用过)，rabbitmq等消息队列和消息分发软件。

再往后，用户还在疯涨，如果你已经成功切换到DynamoDB，那么只需要提供更多的读写配额，让AWS替你scale out，但如果还对SQL DB不离不弃，就要走数据库表的sharding，不过这个时候，你可能已经接近于下一个instagram了。所以，即便切表切得肉疼，心情还是舒爽的，任何问题都不过相当于躺在马尔代夫的沙滩椅上吹着海风，看着比基尼，享受精油按摩的时候，被不开眼的蚊子叮了个包而已。

稍微多说两句DynamoDB。DynamoDB是AWS的私有技术，不过Amazon publish相关的paper，催生了riak这样带着同样理念的开源产品。按照我粗浅的理解，这类可以无限扩容的NoSQL数据库，其核心是consistent hashing：

consistent hashing的概念是我有一个足够大的keyspace(2的160次方，比较一下：IPv6是2的128次方)，我们记作X，然后将X放在一个环形的空间里划分成大小相等的Y个partition，依次循环排列(如图)，每个partition由一个vnode(riak的概念)管理，当你有M个database server(node)，Y个vnode再平均映射到M个node上。当数据要插入时，将其主键(hash key)映射到K中的一个地址(addr)，对应到某个vnode，再进一步对应到某个node，如果这个数据需要N个replica，则将数据写入addr(vnode a)，addr + 1(vnode b)， …，add + N(vnode n)。在这种设置下，M就是你的shards，N是replica。以后添加新的node时，映射发生变化，只需要把相应的变化了的vnode迁移到新的node上即可。在这种结构下，sharding/replica对程序员基本上是透明的。

所以最后看AWS的解决方案，想想它为何提供这样的工具，有助于我们思考自己的application的架构，以及在不得已的情况下，寻找替代产品。

上一篇：年人百万，什么服务器上行速度1G，支持IP伪装.数据包发送？
下一篇：海外节点软件小火箭和V2ray的上网常见问题