首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

微服务介绍(2)

微服务介绍(2)

更快另一个伴随 而出现的流行词是 DevOps。DevOps                运动使开发人员能够在交付管道中控制更多代码,持续集成,实现更高的可视性。DevOps 的主要原理(如图 6                    中所示,沿顺时针方向)为observeorientdecide 和                    act
图 6. DevOps 的原理还有比更快地交付更小的组件更好的方法吗?您无法每两周向一个庞大的应用服务器实例交付一次更新,但在同样的时间范围内,您肯定能向其他许多服务所使用的单个服务交付更新。构建新的暂存环境,在管道中移动各个组件,并将它们交付到生产环境时,更小的组件可实现更低的开销。
别误会我的意思。持续交付和集成仍可通过单体模型完成。我已看到它发生过。但是,您需要艰难地应对巨石,而不是弹珠。丢弃一颗弹珠,比丢弃一块巨石更容易实现。
与 DevOps                关联的开发周期本身非常适合微服务。您想要的是持续添加功能的更短的开发周期,而不是一次实现整个愿景的更长开发周期。此开发方法称为敏捷开发,是决定                DevOps 的成功的基本实践。无论选择迭代式还是增量式开发,微服务、DevOps                文化和敏捷计划的组合都使您能够快速构建一个完整的基础架构,而几年前,在同样的时间内,仅能计划您的第一个瀑布周期。
更快                的另一方面与执行相关。微服务基于的概念是,如果您想要更快,则需要提供更多资源。经理的梦想!通过将每个服务构建为可独立扩展,可在组件之间实现交互,以充分利用资源池而不是单一的组件接口。
返回到上一个示例,在                  中,您看到了服务注册表服务器和客户端。此功能在基于微服务的应用程序中至关重要。在此示例中,边缘服务包含 Movie Service 和                Review Service 引用。基于负载,这些服务以不同的速率扩展;因此您无法再在相同的规模上以相同方式管理它们。
Movie Services 扩展时,Service Registry                会自动获知创建的新服务实例。当一个边缘服务尝试处理一个请求时,它会调用服务注册表,并获取它依赖的所有服务的客户端引用。Movie Service                客户端引用更可能是最近创建的一个新服务,但是可以返回以前使用的 Review Service                的一个旧实例。这个服务注册表功能使您的微服务能够真正成为                “许多服务中的一个”,在组件之间具有松散耦合的依赖关系,但有一个高度可靠的功能在需要时获取组件的更多副本。
图 7 显示了   中的流视频应用程序的同样的概念架构,但增加了针对 Movie Service                的已扩展的微服务。
图 7. 流视频应用程序的概念扩展示例根据需要高速扩展,拥有能自行感知新实例的系统。不是,这不是 。它使构建于微服务架构之上的应用程序更加强大。
更强不是所有系统都打算持续存在。它们在需要时创建,在不再适合某个用途时就会被删除。正如我之前提到的,这会消除单点故障,将这些点分散在整个系统中,并知道您需要机制来处理不可用或性能糟糕的服务和实例。
是家畜,不是宠物对于微服务,部署的系统的概念成为了家畜,而不是宠物
  • 宠物有名称;而家畜只有编号。
  • 宠物是独一无二的;而家畜通常是相同的。
  • 宠物的健康会得到照料,而家畜在生病时就会被取代。
改编自 Gavin McCance 的   演示。
此概念可帮助创建许多个同一种服务以及许多服务中的一个。我们不再单方面地依靠服务实例,或者管理长期实例,担忧状态的维护、存储、系统修改等问题。不要误解我的意思,我们仍然对性能调优和配置很感兴趣,但这些过程现在发生在开发周期中的更早阶段,而不是发生在暂存或生产环境中。此方法为我们提供了许多服务,以及每个服务的许多实例。
为了证明这方面的优势,Netflix 在其发展过程开始利用混沌概念,确切地说,是 Chaos Monkey(参见图 8)。Chaos Monkey                是一个云应用程序组件,Netflix 使用它来向应用程序操作中引入系统性的混沌。
图 8. Chaos Monkey此功能将经由基础架构,特意关闭对生产至关重要的服务和服务实例。为什么 Netflix 会这么做?它如何在这么做时还能幸存下来?
首先看看为什么。这是一种轻松识别您需要在何处快速失败的方式。新服务是否太慢了?它们是否需要更高效地扩展?当外部服务提供程序(而不是内部服务)发生故障时会发生什么?所有这些问题都需要在微服务架构中考虑。
然后看看如何做。Netflix 之所以能够幸存,得益于我之前提到的猎枪方法。想法很简单:配备足够多的服务实例,使 99.9999%                的请求都能成功完成。任何失败的请求都会在重试后成功。一个服务实例突然中断,而且另一个本地实例将会接管它的工作。整个服务突然中断,而且您的系统应补偿或将用户重新路由到其他包含该特定服务的可用性专区或区域。如果没有其他服务可用,用户或请求应快速失败,而不是等待超时。
Netflix 扩展了 Chaos Monkey 概念并将该功能发布为  (参见图                9),以包含 Chaos Monkey、Janitor Monkey、Conformity Monkey 和 Latency Monkeys                — 向操作中引入了特定的混沌的云应用程序组件,包括延迟和合规性问题
图 9. 一个 Simian Army可以看到,Netflix(和其他采用微服务的公司)同意您应用程序会在挫折中变得更强大的理念。
返回列表