快速使用AWS的14个经验分享合编.docxVIP

快速使用AWS的14个经验分享在今天的文章中，我整理出了大量当初曾经错过、而至今仍将我追悔莫及的Amazon Web Services（简称AWS）使用心得。在几年来的实践当中，我通过在AWS之上新手构建及部署各类应用程序而积累到了这些经验。虽然内容有些杂乱，但相信仍然能给各位带来一点启示。从物理服务器向“云环境”转移的过程不仅仅是一项技术任务，同时也意味着我们的思维方式需要作出针对性的转变。总体而言，在物理环境下我们需要关注的只是每一台独立主机; 它们各自拥有自己的静态IP，我们能够对其分别加以监控。而一旦其中一台发生故障，我们必须尽最大可能让其快速恢复运转。大家可以以为只要将基础设施转移到AWS环境之下，就能直接享受到“云”技术带来的种种收益了。遗憾的是，事情可没那么简单(相信我，我亲身尝试过了)。在AWS环境之下，我们必须转变思维，而且这方面的任务往往不像技术难题那么容易被察觉。因此，受到了SehropeSarkuni最近一篇帖子的启发，我将自己几年来积累得出的AWS 使用心得汇总于此，而且说实话、我真希望自己当初刚刚接触AWS时能有人告诉我这些宝贵经验。这些心得总结自我在AWS之上部署个人及工作应用程序时的亲身感受，其中一部分属于需要高度关注的“疑难杂症”(我自己就是直接受害者)，而另一部分则是我听其他朋友说起过、并随后亲自确认有效的解决方案。不过总体而言，为了积累这些经验，我确实付出了相当惨痛的代价：)应用程序开发千万不要把应用程序状态保存在自己的服务器上。之所以这么说，是因为一旦我们的服务器发生故障，那么应用程序状态很可能也随之彻底消失。有鉴于此，会话应当被存储在一套数据库(或者其它某些集中式存储体系、memcached或者redis当中)而非本地文件系统内。日志信息应当通过系统日志(或者其它类似方案)进行处理，并被发送至远程位置加以保存。上传内容应当直接指向S3(举例来说，不要将其存储在本地文件系统内，并通过其它流程随后迁移到S3)。再有，任何已经处理过或者需要长期运行的任务都应该通过异步队列(SQS非常适合处理此类任务)来实现。编辑点评:对于S3上传内容而言，HN用户Krallin指出，我们可以彻底避免其与自有服务器的接触，并利用预签名URL保证用户的上传数据被直接发送至S3当中。将额外信息保存在日志当中。日志记录通常包含有时间戳以及pid等信息。大家也可能希望将实例id、服务区域、可用区以及环境(例如分步环境或者生产环境等)添加进来，而这些都能在日后的调试工作中作为参考。大家可以从instance metadata service当中获取到这些信息。我所采用的方法是将这些信息作为引导脚本的组成部分，并将其以文件形式存储在文件系统当中(例如/env/az或者 /env/region等)。这样一来，我就用不着持续查询元数据服务来获取这些信息了。大家应当确保这些信息能够在实例重新启动时得到正确更新，毕竟我们都不希望在保存AMI时发现其中的数据还跟上次完全一样，这肯定属于非正常状况。如果我们需要与AWS进行交互，请在当前语言中使用对应SDK。千万不要试图自己动手。我当初就犯过这个错误，因为我认为自己只是单纯需要向S3上传内容，但随着后续服务的持续增加、我发现自己的决定简直愚蠢至极。AWS SDK的编写质量很高，能够自动处理验证、处理重试逻辑，而且由Amazon官方负责维护与迭代。此外，如果大家使用EC2 IAM角色(大家绝对应该这么做，这一点我们后面会进一步提到)，那么该SDK将帮助我们自动获取到正确的证书。利用工具查看应用程序日志。大家应当采用管理员工具、系统日志查看器或者其它方案，从而帮助自己在无需在运行中实例内使用SSH的方式查看当前实时日志信息。如果大家拥有集中式日志记录系统(我强烈建议大家使用此类系统)，那么当然希望能在不使用SSH的情况下完成日志内容查看任务。很明显，将SSH引入正处于运行状态的应用程序实例会引发诸多弊端。运营心得如果将SSH引入自己的服务器，那么自动化机制恐怕将无法生效。在全部服务器上禁用SSH访问。这听起来确实有点疯狂，我知道，但在大家的安全组当中、请务必确保端口22不向任何人开放。如果各位想从今天的文章中获得什么启示，那请千万牢记以下一点：如果将SSH引入自己的服务器，那么自动化机制恐怕将无法生效。从防火墙级别(而非服务器本身)禁用SSH有助于整套框架实现思维转变，因为这样一来我们就能了解到哪些区域需要进行自动化改造，同时大家也能更轻松地恢复访问来解决当前面临的问题。在意识到再也不必将SSH引入实例之后，大家肯定会像我一样感到浑身轻松。没错，这是我在实践中了解到的最惊世骇俗、但也却具实用性的心得。编辑点评:很多人对这项心得表现出了高度关注(HackerNews网站上还出现了不少值得一