凌云时刻 · 技术
导读：随着国际云市场竞争越来越激烈，以中美贸易战为导火索，越来越多的国内AWS客户开始从AWS搬迁至阿里云。本篇文章作为系列文章开篇，从整体分析AWS/阿里云产品差异分析，希望能给大家有所借鉴及启发。
作者 | 文强
来源 | 凌云时刻（微信号：linuxpk）
计算
虽然部分产品从功能上有所差异，但整体产品上，AWS和阿里云的计算产品体系完善度相差不大。
AWS在产品方向上犯过大错，在容器产品方面，AWS在之前集中精力搞Elastic Container Service，直接2018年才推出 kubernetes 产品 Fargate。
AWS/阿里云常用计算产品对标如下表所示。
表一：AWS/阿里云常用计算产品
以EC2/ECS为例，下表从ECS/EC2实例按类型分类对比，实例类型丰富度基本是持平的，AWS主要优势在网络性能上，最大规格单实例性能能达100G， AWS在网络基础设施及技术上的确有优势。
表二：AWS/阿里云实例按类型分类对比
另外，AWS的RI（预留实例）对实例规格没有限制，即按总CPU和内存数计算，阿里云预留实例对规格规格是有限制的，灵活性能比AWS略有不足。
网络
常用网络产品竞品对标如下表所示。
值得一提的是，CEN产品是阿里云首发的，AWS的TGW产品比阿里云CEN要晚1年左右。
表三：AWS/阿里云常用网络产品
从功能上看，AWS在负载均衡产品上，转发策略支持比阿里云SLB功能要丰富，具体如下表所示。
表四：AWS/阿里云常用网络产品功能对比
存储
常用存储产品竞品对标如下表所示。
表五：AWS/阿里云常用存储产品
以S3/OSS为例，从以下几点分析S3/OSS差异
API兼容性：
通过S3 API访问OSS
获取OSS主账号或子账号的AccessKeyId和AccessKeySecret，并在客户端和SDK中配置申请的AccessKeyId与AccessKeySecret
考虑到OSS特性支持及运维建议使用OSS SDK
Path style和Virtual hosted style：virtual hosted style是指将Bucket放入host header的访问方式。OSS基于安全考虑，仅支持virtual hosted访问方式，所以在S3到OSS迁移后，客户端应用需要进行相应设置。部分S3工具默认使用Path style，也需要进行相应配置，否则可能导致OSS报错禁止访问。后续S3也慢慢去除Path style方式
公网VPC访问差异：公网或VPC内访问S3，使用同一个Endpoint，VPC内访问相当于公网地址私用。而OSS需要使用不同的endpoint。考虑到迁移速度及费用问题，S3迁移OSS一般采用专线方式，需要在AWS EC2集群搭建迁移服务；如果通过ECS跨专线访问S3默认走公网
多版本：OSS只有部分region开启了多版本
API兼容性：S3/OSS兼容的API，如下表所示：
表六：S3/OSS兼容API
数据库
常用数据库产品竞品对标如下表所示。
表七：AWS/阿里云常用数据库产品
整体上看，数据库产品体系比较类似，其中区别较大的是：
AWS没有原生的MongoDB产品，而是推出了兼容MongoDB API，存储计算分离架构的DocumentDB；
AWS没有原生的HBASE产品，可以通过EMR来快速使用HBASE；阿里云的EMR也是支持HBASE的；
AWS支持原生Oracle，阿里云通过POLARDB-O，PPAS部分兼容oracle，结合ADAM产品做去O评估
以RDS为例，介绍AWS/阿里云的优缺点：
AWS/阿里云共性
托管数据库服务，扩展性好
支持MySQL，PostgreSQL， SQL Server等关系型数据库
高可用部署（多可用区），Failover自动切换
数据加密，安全
可靠的文件存储（基于云盘／EBS）
AWS/阿里云差异
AWS RDS通过 dns 实现容灾，主备切换、升降配时会触发IP变动；Aliyun RDS为了实现读写分离、七层负载均衡和避免连续闪断，引入了proxy链路，升降配或主备切换不会触发IP变动
6版本只读实例不支持Binlog
Aliyun 支持 VPC & Classic ；AWS 只支持 VPC
默认mysql系统参数部分不一致
阿里云优势
更好的数据库性能，AWS RDS均是基于EC2部署，阿里云目前也在推ALL ON ECS，并且RDS已经发布ECS版，实测同等配置下阿里云非ECS版RDS IOPS／QPS比AWS RDS高一倍，且具备 AWS 没有的独占物理机实例
支持异步和半同步复制
更长的镜像，日志保存时间
基于 DTS 实现跨区域同步
SQL 审计
结合DMS，更好的运维体验
AWS优势
原生支持Oracle
更多的数据库参数
AWS具备删除保护开关，避免误删
大数据
常用大数据产品竞品对标如下表所示。
表八：AWS/阿里云常用大数据产品
AWS和阿里云大数据产品规划上差异是较大的，特别是在自研方面，阿里云的MaxCompute+DataWorks从功能上，在AWS没有能与之匹配的产品。
Redshift主要面向的是传统数仓领域，提供大规模数据快速查询分析，Redshift不直接支持MR，可以结合EMR作计算，使用Redshitf存储。IDE方面，AWS没有提供原生产品支持，而是建议他的客户使用开源的IDE。
下面具体说明Redshift和MaxCompute差异。
表九：Redshift和MaxCompute差异对比
另外，AWS的EMR+S3，从网络性能上，要比阿里云高很多，单集群可以达到500g带宽能力，而阿里云侧，EMR+OSS原生只能达到100G，结合jindofs，可以达到类似500g带宽的吞吐。从这一方面，也可以体现AWS在网络基础设施技术方面的优势。
总结
随着阿里云这几年快速发展，在产品体系上，也越来越完善，追上了AWS的脚步，并且，有些产品还有先发的优势，比如CEN，而且，我们少数产品非常有优势，比如SLS，AWS上没有能和SLS对标的产品，日志方面，AWS建设客户使用开源的ELK方案（ElasticSearch可以使用AWS产品）；另外，得益国国内直播行业火热，阿里云CDN直播比AWS成熟。
但整体上，AWS还是领先者，优势主要体现在以下几点：
产品一致性：从AWS用户实际体验，AWS所有产品都是可预期的、标准化体系化的，不会出现惊喜或惊吓，比如AWS产品上线前，在标签功能、IAM接入、lamda对接、CloudWatch对接待横向特性或横向产品对接下，必须是较完善的。而阿里云的很多产品在这些方面都是不完善的，比如我们很多新产品或较新的产品标签功能不完善，DTS产品的迁移/同步任务的监控是在产品自己的控制台配置的，没有接入云监控，等等，这类情况还有很多；
API理念：AWS电商带来的API理念，产品发布严格把控API；AWS API及文档是比较完善的，我们的API还不够稳定，特别是涉及一些新功能或多产品协同API，BUG较多，文档也不够完善
生态：AWS生态比较强大，比如terraform由生态开发者支持，阿里内部专人开发
基于AWS稳定的API，国外AWS主流用户以及国内TOP级客户，对云的理解及使用非常深入，主要体现在以下两点：
极致弹性：
AWS RI（预留实例）对ECS规格不限制，预留实例可以按需随时弹给不同业务，可以是在线应用，也可以离线应用；
在线应用按业务高低峰时间或业务实时流量曲线，稳定的伸缩，保持在线应用CPU使用率30%以上；
离线平台EMR：在白天可以直接释放集群，晚上跑离线任务定时创建
Infrastructure as Code：
完全脱离控制台，基于API操作，使用Terraform稳定、高效的管理云资源
在云上创建k8s集群（基于产品），控制台操作需要20+步骤，还可能出错，而基于Terraform，在配置写好情况下，一步创建，为极致弹性提供助力
云的未来
标准化：未来的云必然是越来越标准化的，不同厂商间底层实现技术上可能不一样，但对用户的提供的功能、协议、接口等是越来越趋于一致的。
壁垒：在标准化的趋势下，不同云厂商的壁垒，更多的是在基础技术、产品质量、用户体验，提供给用户更好的性能，更稳定的产品服务，以及更好的用户体验。
END
往期精彩文章回顾
长按扫描二维码关注凌云时刻
每日收获前沿技术与科技洞见
796
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
