我有几个问题困扰着我，并希望在这里有一些很棒的有经验的人帮助。
1）每当我访问AWS ec2 t2.medium实例上托管的phpMyAdmin时，我都会遇到这个特定问题（虽然不常见但是我觉得访问REST API以上传文件到ec2服务器的android应用程序无法上传文件而我认为它是由于下面的网络丢失造成的，不确定，因为我是AWS的新手）：
请求的服务器在事务
之前关闭了连接
我的AWS实例正在运行：
2）我不熟悉使用AWS并在AWS上成功部署了基于Laravel的后端，我的Android应用程序访问了托管在同一ec2 t2.medium实例上的REST API。现在困扰我的是，我不确定它将如何自动扩展？因为当我们运行现在已经停止的营销活动时，应用程序被超过7000个用户下载+因为许多用户在将媒体文件上传到服务器时面临问题，在某些％ge之后文件停止上传文件而其他用户能够上传文件。
Android应用程序做的一切都很好，但大多数人在尝试将文件上传到在AWS ec2 t2.medium实例上托管的Laravel中编码的REST API网址时遇到问题，我使用下面的android库将文件上传到我的服务器通过我的后端的文件上传API：
https://github.com/gotev/android-upload-service
我构建的文件上传laravel API是这样的：
public function uploadFile(Request $request, userSubmitData $udb)
{
$creds = $request->all();
$idFromDB = $udb::where('token', $creds['token'])->value('token');
$uid = $udb::where('token', $creds['token'])->value('user_id');
$hasFile = "false";
$file = $request->file('myFile');
$extension = $file->getClientOriginalExtension();
$fileName = $file->getClientOriginalName();
$fileName = $uid."_".$fileName;
Storage::disk('local')->put($fileName, File::get($file));
$udb->where('token', $creds['token'])->update(['fileHandle' => $fileName, 'mime' => $file->getClientMimeType(), 'original_filename' => $file->getClientOriginalName(), 'approved' => NULL, 'rejected' => NULL]);
$hasFile="1";
return Response($hasFile, 200);
}
请告诉我您对构建可扩展技术以及将AWS高效设置为容错，高度可扩展且高度可用的架构和技术的见解。
谢谢。
PS：我不是一个伟大的程序员或任何东西，只是一个喜欢编码和建造美丽事物的新手建筑师，有很多伟大和令人惊叹的人比我在那里哈哈。所以不要介意我在这里执行事情的方式我正在努力使事情正常运行，并使其工作得很漂亮：）
答案 0 :(得分：1)
我可以向您提出两个选项，它们都将为您提供所需的可扩展性以及所需的容错能力。这有点罗嗦，但我恳请您仔细阅读并随意提出后续问题！ ：）
选项一 - Route53，ELB，ASG和冗余。
对于此解决方案，您需要使用Route53运行状况检查，Elastic Load Balancer和Auto Scaling组。
筹码：
Route53将为负载均衡器提供DNS需求，但它也可以为您提供一些非常好的运行状况检查和自动故障转移功能。根据您在高可用性策略中可接受的容错级别，您可以使用此运行状况检查来评估其目标（在本例中为ELB）的整体运行状况，并将DNS故障转移到您的备用堆栈在任何时候都跑步和站立。这可能很昂贵，但这取决于您的商业案例。
Elastic Load Balancer将定位Auto Scaling组中的实例，您应该将Auto Scaling组配置为使用至少2个可用区。这意味着如果AZ失败，您的应用程序仍可供您的客户使用。一个以上的AZ同时失败是极不寻常的，但它可能会发生。同样重要的是要知道，当AZ失败时，剩余的AZ将很快超额认购。这意味着如果您使用2个AZ并且其中一个失败，这意味着您的应用程序将以50％的容量减少运行，并且由于每个人都从失败的AZ运行到剩余的AZ，因此您的Auto Scaling Group可能会遇到困难在该AZ中自动配置其他实例。因此，如果您的应用程序高可用性与您以高质量服务客户的能力一样至关重要，则意味着基于您使用2个AZ的情况，您需要在每个AZ中提供100％的BAU容量。如果您希望在您的某个AZ失败时能够在剩余的AZ中配置一些替换实例，则可以将此值减少到较小的百分比。或者，您可以使用另一个AZ（总共3 +）。
我可以谈几天，但继续......
最后是您的应用程序实例。您需要创建一个脚本，将它们从您选择的Ubuntu AMI直到生产就绪。 Auto Scaling组将使用Instance的UserData元数据中的此脚本启动新实例，Instance将使用此实例做好准备。如果没有此脚本，您必须手动设置和配置Auto Scaling组创建的每个实例，这不是理想的。
重要提示： 以防万一，如果您的应用无法因内存中的会话状态而缩放，那么您就需要解决问题。有几种方法可以做到这一点，但亚马逊的方式是利用ElastiCache进行会话存储。可能是一点点工作，但它会使你的解决方案更有弹性。
这将为您的应用程序创建一个高度可用的解决方案，但依赖于您在成本与HA方面做出一些商业决策。
选项2 - 真正的云和AWS方法，无服务器。
从上面您可以快速了解获取应用程序，将其置于云中并保持高水平的HA和QOS的成本。然而，以您的应用程序的某些部分（无服务器设计）的初始重新开发为代价，您可以使用更好，更便宜且更少维护的方法。
为此，您将有效地取消应用程序服务器并使用以下产品：
使用Lambda替换您的应用程序逻辑和对实例的依赖性将使您能够执行代码，而无需在出现故障时关注AZ，ELB，ASG，冗余和超额预订。 Lambda具有极高的成本竞争力，我敢说甚至不会只是使用所有HA配置等运行实例应用程序的成本的一小部分。
使用API网关，您可以以可管理，高度可用的方式向您的用户公开您的Lambda功能，与上述选项相比，只需很少的工作量和成本。
DynamoDB是AWS的NoSQL产品。它的HA，快速，轻松地自己定制，以满足您的需求。另一种选择是Amazon RDS，它将为您提供更传统的SQL体验，但在一天结束时，您仍然需要支付群集中的实例以及管理费用。
我将总结一下，选项2是您应该瞄准的地方，但是如果您已经拥有一个已编写并为客户提供服务的产品，那么您现在应该继续使用选项1并获得该HA并具有可扩展的可信度然后投影选项2以后。
以下是我所讨论的所有主题的补充阅读材料，但如果您需要，可以随时提出更多问题。
选项1文档
Route53健康检查和故障转移 http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
弹性负载均衡器 https://aws.amazon.com/documentation/elastic-load-balancing/
Auto Scaling Groups（请同时查看启动配置） https://aws.amazon.com/autoscaling/ http://docs.aws.amazon.com/autoscaling/latest/userguide/LaunchConfiguration.html
AWS ElastiCache https://aws.amazon.com/documentation/elasticache/
选项2文档
亚马逊API网关 https://aws.amazon.com/api-gateway/
AWS Lambda https://aws.amazon.com/documentation/lambda/
AWS DynamoDB https://aws.amazon.com/documentation/dynamodb/
亚马逊RDS https://aws.amazon.com/documentation/rds/
干杯，
济