「微服务架构」亚马逊引领其自有微服务架构的原因
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了「微服务架构」亚马逊引领其自有微服务架构的原因，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4725字，纯文字阅读大概需要7分钟。
内容图文
"新堆栈”的真实故事，一次又一次，是关于具有巨大服务器需求的公司如何受到现有架构无法满足这些需求的限制，如何为自己解决问题，然后转而将其解决方案转售给 剩下的世界。 我们多么快地忘记了最早的例子，但也许仍然是最好的，是亚马逊。
“如果你回到2001年，”亚马逊AWS产品管理高级经理Rob Brigham表示，“亚马逊零售网站是一个庞大的单体架构。”
布里格姆星期三在亚马逊举行的2015年拉斯维加斯发布会上发表了一个主要参与人数很多的主要舞台。 他随行的幻灯片显示了一个公认的“2001”单体，这次高耸于辉煌的华盛顿山湖旁边，可能就在附近。 他对亚马逊的历史时机或者他自己的历史时机的聪明才智只是嗤之以鼻。
“现在，不要误会我的意思。 它的架构分为多层，这些层中有很多组件，“Brigham继续说道。 “但他们都非常紧密地联系在一起，他们表现得像一个巨大的巨石。 现在，许多创业公司，甚至是大公司内部的项目，都是以这种方式开始的。 他们采取一体化的方法，因为它很快就能快速行动。 但随着时间的推移，随着该项目的成熟，随着您在其上添加更多开发人员，随着它的增长和代码库变得越来越大，架构变得越来越复杂，这个整体将为您的流程增加开销，而软件开发生命周期也是如此。 开始减速。“
Brigham提出了软件开发生命周期（SDLC）作为开发团队结构的主题 - 特别是，当处理像Amazon.com这样的单一应用程序在2001年面临的实质内容时，开发人员将彼此区分开来，将团队从最终目标中分离出来。他们真正革命性地解决这个问题的方法成为了导致云计算创建的原型之一（美国宇航局的星云项目是其中之一）。
Brigham还透露的是，原始Amazon.com的非常类似tarball的粘性激发了另一个革命性的概念：服务架构的解耦。也许亚马逊没有发明微服务，也许它不是敏捷方法的先驱。但进化并不总是首先在一个地方发生。有大量证据表明亚马逊确实主动提出了这些概念。
Brigham讲述了亚马逊工程团队的故事，该工程团队在2000年有一项艰巨的任务，即协调数百名开发人员的进程内更改，解决他们之间的所有冲突，将它们合并为一个版本，并生成等待的主版本要移入生产的队列。 “即使你有那么庞大的新版本，”他说，“它仍然会在这个交付渠道上增加很多开销。整个新的代码库需要重建。所有测试用例都需要重新运行，以确保没有任何冲动。然后你需要整个应用程序，并将它全部部署到你的完整生产车队。“
亚马逊的方法不是摆脱管道，而是简化它。该公司的持续部署工具 - CodeDeploy，CodePipeline和CodeCommit - 围绕真正的云原生Web应用程序构建，其中该管道的各个部分可以编写脚本并自动化。 Rob Brigham表示，从世纪之交开始，亚马逊制造的建筑和物流变化直接导致了它现在为开发团队提供的工具。
上个月，Pivotal工程师Rohit Kelapure在详细描述整体架构的分解中描述了SpringOne 2GX会议的记忆，亚马逊的Brigham将他和他的同事们如何“将其分开”与Amazon.com单体相关联面向服务的架构。
“我们完成了代码，并提取了功能单元，这些功能单元只用于一个目的，我们用网络服务接口包装了这些功能单元，”他说。例如，有一项服务在零售商的产品详细信息页面上呈现“购买”按钮。另一个人有结账时计算正确税的功能。
在它们创建时，这些单一用途的功能似乎很容易实现。但想象一下数百个开发团队，其中一些由当时的数十个开发人员组成（而不是更舒适的“两个比萨”大小，不超过八个），其简单，单一用途的功能必须合并在一起一周又一周......以及之后的月份，随着SDLC的结构变得更大更庞大。
解耦管道
单一功能问题的解决方案是创建一个规则，开发人员必须遵守该规则，这些功能只能通过自己的Web服务API与世界其他地方进行通信。 “这使我们能够创建一个非常高度分离的体系结构，”Brigham说，“只要这些服务符合标准的Web服务接口，这些服务就可以彼此独立地迭代而不需要任何协调。”
服务的去耦使创建第一个自动部署系统之一，与原型的大部分时间今天亚马逊提供的客户 - 适当命名的“阿波罗”它帮助引进管道模型亚马逊的文化，它可能是Brigham在会议中明智地应用了一些自由编辑，因为这个过程不可能很简单。
但他对这方面很直率：通过能够看到管道作为图形化的东西，具有大小和形状，亚马逊的工程师可以更加确定他们需要多少改变他们的流程。当然，它们可以实现自动化，但为什么要实现冗余自动化？
“我们仍然注意到代码更改要花费很长时间才能从开发人员签到，到生产中运行，客户可以使用它，”他说。 “因此，作为一家以数据为导向的公司，我们对此进行了研究。 我们测量了代码更改在整个部署生命周期中跨越多个团队所花费的时间。 当我们将这些数据相加，并查看结果，并查看平均花费的时间时，我们坦率地感到尴尬。 这大约是几个星期。“
打破这些行动有助于工程师意识到这个管道中段的顺序和排列导致了“死时间” - 没有发生任何事情的间隔。 这尤其发生在部门之间的人工交接之间 - 其个性化应该引入流程完整性的交接，但实际上，这导致了低效率，浪费的空间和长长的队列。
“对于像亚马逊这样以效率而自豪的公司 - 对于一家在我们的履行中心内使用机器人来移动实体商品的公司，一家希望使用无人机将包裹部署到您家门口的公司 - 您可以想象它有多疯狂， “他说，”我们在软件交付过程中使用人来传递这些虚拟位。“
Brigham的演讲引发了CodePipeline的演示，其中包括在部署管道中发生的事件的内联脚本，以及与Amazon和GitHub上的私有存储库的集成。 亚马逊在这一点上表示，它正在避免将开发商店锁定为亚马逊品牌的做事方式，这与其合作伙伴生态系统之外的一些人所说的相反。
在这一点上你可能会想到Rob Brigham正在向合唱团讲道，或者说他正在捕鱼以获得亚马逊应该为这个行业创造的一些应得的赞誉。 事实上，令人尴尬的是，虽然这可能是为了观众中的很多人并观看现场直播而承认，亚马逊2001年的故事是他们2015年的故事。
内容总结
以上是互联网集市为您收集整理的「微服务架构」亚马逊引领其自有微服务架构的原因全部内容，希望文章能够帮你解决「微服务架构」亚马逊引领其自有微服务架构的原因所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。