架构实战(1)——技术选型，选择AWS的苦与乐

本人负责一个项目上线了，非常开心。这个项目是To C的，未来应用的访问压力较大，并且要求高可用性，提供7*24小时的不间断服务。根据项目的业务需求以及团队情况，采用Spring Cloud微服务架构。把用到的技术，和和解决的技术问题，做一个总结。

先说一下啊，本人刚开始对AWS的相关技术并不熟悉，刚开始是带着排斥的心态的，毕竟一直都是用阿里的技术，阿里云上的组件更加得心应手，并且中文资料真是多，遇到问题也能找到解决方案。

那为什么采用AWS呢？难道是老板强压的？当然不是！

首先，这个项目是面向全球客户的。虽然前期服务的主要是国内客户，但是，几个月后就要开启全球站。不是对阿里云没有信心，在全球市场上，AWS的稳定性、可选择性等等各方面，都要好很多。这也是和公司其他全球项目的同事，做了详尽的调研后，得出的结论。

其次，AWS的售前同学真的非常给力，没有内幕啊。在项目前期AWS售前邀请到架构师，帮我们做架构review和架构优化，对于安全、高可用、降低成本等方面的技术支持非常到位。真实感受到了AWS的专业性。

最后呢，公司和AWS有比较好的合作，貌似价格也比较给力。于是乎就选择了AWS。

我只能说，这仅仅是表象，后面有很多的坑，殷切的等待着我们，等着我们去填平。

用到了AWS的哪些服务呢？

首先就是EC2。刚开始，在EC2和ECS之间摇摆了很久。EC2就是虚拟主机，ECS就是容器。在这之前呢，就参加过AWS的workshop，对ECS有了一定的了解。ECS有两种用法，一种是和K8S组合使用；另一种就是传统的，在ECS上部署应用。首先就放弃了K8S，因为这是一个全新的项目，使用全栈Java的解决方案，应用Spring Cloud做微服务治理，K8S并没有应用的价值。ECS相对于EC2呢，有更大的成本优势，可以做到更精细的按需分配。后来考虑到工期比较紧，团队也没有应用ECS的经验，就放弃了，其实有点遗憾。后面有机会在迁移到ECS吧。

再来说说数据库，这里有一个大坑，用了非常长的时间，才解决掉，待我细细说来。

AWS的RDS有Mysql，但是还有另一种数据库，即Aurora，是AWS特有的。AWS的架构师和售前同学，一直力荐Aurora。一方面呢，价格上更有优势，另一方面，更容易维护，而且和Mysql5.6,5.7兼容，什么都不用修改就能用。题外话：之前有个项目用的是mysql，有一个配置项是存储空间，这个需要时刻关注，如果数据库增长到了上限，就会有问题。Aurora就没有这个问题，支持存储空间的自动增长。

我们的应用是采用了读写分离的，在测试的时候，发现了一个问题，延迟严重！查看Aurora的控制台，一直保持在20毫秒左右，但是，我的测试结果超过了500ms，这谁能受得了。经过一系列的折腾，两天后找到问题，貌似有个配置项采用了默认配置，启用了缓存机制。更改了配置后，再通过脚本测试，发现还是有超过100ms的情况。本来就对Aurora不放心，这下好了，经过这一顿的折腾，放弃了Aurora，转战Mysql。

在功能测试的时候，mysql的表现一切正常，延迟都是在几十毫秒的情况。在压测阶段，更大的坑出现了，简直是天坑啊。只要流量上去，mysql主从的使用率只要超过10%，延迟就会达到秒级，稍微高一些，延迟能到十分钟。关键之各种指标正常，CPU、IO、网络等。彻底崩溃，经过DBA同学的努力奋战，各种调试，最终稳定在了1秒左右，这也是无法接受的呀！

好吧，重新转战Aurora。压力测试下，在主从的CPU使用率达到60%的时候，主从延迟平均20ms左右，偶尔有超过100ms的情况，但没有发现超过300ms的，一切正常。这点要说一下啊，Mysql的主从同步，是通过回放binlog实现的，而Aurora是通过块复制实现的，在有压力的情况下，Aurora的块复制方法更稳定。

还用了AWS的redis集群，默认情况下，每个shard都会1个主节点，2个副本节点，并且这些节点在不同的可用区。为了节省成本，硬生生的去掉了一个副本节点，还是能够保障高可用的，我的说法是从6个9变成了4个9，还可以接受。总共6个shard，每个shard 2个节点，总共12个节点。

项目中有数据流的应用场景，刚开始是希望用Kakfa的，但是国内没有。Kinesis是AWS主打的高并发队列服务。不同于Kafka broker的概念，它做了更加抽象的定义。Kinesis可以有多个shards，每个shard可以支持每秒1M的流量，根据业务需求可以添加或删除shard，这点设计非常好。这个服务用起来很顺，没有产生什么幺蛾子。如果发生，就惨了，没人知道它是怎么做的。其实，这也是刚开始比较排斥Kinesis的原因，开源的工具用习惯了，当发生异常的时候，可以去找社区，这种闭源的东西用着心里没底。

还要吐槽一下AWS中国区的队列服务。业务中也会经常用queque，这个应用场景和Kinesis是不同的，AWS确实提供了另一种队列——SQS(Simple Queue Service)。这个命名简直是太准确了！只能简单的实现A到B的消息传输。想要用到类似RabbitMQ消息路由的功能，对不起，它不支持！据说，国际站是有MQ的，希望尽快进入国内吧。

最后说一下LB(Load Balancer)。其实AWS的LB是值得表扬的，LB给的是一个域名，后台对应了2个IP地址，类似于DSN轮询的方式，访问LB的时候，轮流访问这两个IP。这里就有了一个小插曲，在测试环境搭建的时候，我们这边儿的同学配置错了可用区，导致两个IP中的其中一个访问不通。大家在用的时候，看到的现象就是通过域名访问，有时候快有时候慢。经过漫长的查找，大概一天，才找到了这个原因。

总结一下啊，作为架构师，要对选择的技术栈有深入的理解，但同时也要有一定的冒险精神，意思不是用一些奇奇怪怪的东西，而是说要创新，要勇于接受新事物。总体来上来说，AWS的相关服务是挺不错的，虽然中间有那么多的故事，技术研发不就是这样吗，不停地发现问题解决问题。在中国有北京区和宁夏区两个可以选，宁夏区是刚开始投入使用的，价格较低。AWS中国区的客户支持的专业性还是需要提高的，很多问题，并不能马上帮我们定位到问题。

文章来源: https://www.toutiao.com/group/6705710432457327115/