Netflix 流：大众化的微服务诞生无论您是否听说过微服务，我敢肯定您听说过 Netflix。我甚至敢打赌您听说过 Netflix 开源软件 (NOSS)，这得益于 Netflix 在创建和发布管理云基础架构的软件上取得的成功，它是为 Netflix 数字-娱乐-流媒体帝国提供强力支持的软件。
从大约 2009 年开始（完全由 API 推动且乘着我们所称的微服务的第一波浪潮），Netflix 完全重新定义了它的应用程序开发和操作模型。在那时，该公司被一些行业旁观者嘲笑 “你们疯了！” 或 “这可能适合 Netflix，但没有其他任何公司能这么做。”很快来到看 2013 年，大部分人的态度已转变为 “我们正在努力使用微服务”。525,000 多条的 Google 微服务 搜索结果，暗示该概念无疑既有效又强大。
但什么是微服务？什么是基于微服务的架构？图 1 给出了一个旅游预定服务的微服务概念视图。图中 7 个磁贴中的每个磁贴都表示一个单独的微服务。它们用来显示哪些微服务可与其他微服务交互，向面向内部和外部的应用程序提供必要的功能。这些服务不同的垂直高度代表着它们被使用的相对数量。在本文中，我将介绍微服务的基础知识，以便您可以了解如何表示您自己的基于微服务的架构。
图 1. 概念化的微服务 有关微服务的初衷的深入解释，请查阅 。我在这里将尝试提取这篇博客的精髓，微服务对您如今的环境的适用性，以及如何应用它。
跟进阅读如果您不熟悉 SOA，但又希望熟悉它，可以查阅一篇有关 SOA 起源和它在实现级别上与微服务的技术区别的 。
在一次大会演讲上，Adrian Cockcroft（Netflix 的前身）将微服务定义为 “细粒度的 SOA（面向服务的架构）”。您不需要非常熟悉 SOA（一种十几年前创造的架构风格），只需熟悉一些术语缩略语。理想情况下，从一开始就使用服务来构建整个架构。在微服务中，每个服务拥有单一用途，没有副作用，使您能够让更少的专门工程师处理更大量的工作。
为了定义微服务和关联的架构，我调整并修改了用于描述现代运动员的 “更大、更快、更强” 短语：更小、更快、更强（参见图 2）。实质上，微服务是许多更小的架构组件，它们快速构建和交付，在单独和整体上变得越来越强大。
图 2. 微服务：更小、更快、更强 更小微服务意味着不再有单体模型。单体模型很大、僵硬、缓慢且低效，就像图 3 中的 Grim Monolith。我们正在远离 2GB WAR 文件的世界（是的，只是 WAR 文件。不是应用服务器或操作系统组件。这是一个真实的故事！），朝着一个充满许多 500MB 大小的服务的世界发展，这个世界包含完整的应用程序、服务器和必要的操作系统组件。
图 3. Grim Monolith 从大型机向客户端/服务器架构的迁移是重要的一步，这一步也是许多公司和开发人员都难以迈出的一步。最近从基于 Web 的核心应用服务器向 SOA 的迁移也是一个类似的难题。过去几年应用服务器中包含的许多组件本身有利于采用微服务；但是，它们仍被包装在数 GB 的安装二进制文件中。举例而言，图 4 给出了一种使用 WebSphere® Application Server 和 Java™ Enterprise Edition 组件部署的传统 Web 应用程序架构。
图 4. 标准 WebSphere Application Server 应用程序架构 微服务是集成所有非常松散地耦合的交互组件的一种实践。微服务的整体理念是变得即插即用。我将在 小节中详细介绍此主题，基本上讲，基于微服务的系统大规模地采用猎枪方法，维护和保护更小的组件，而不是更少的大型组件。您消除了单点故障，将这些故障点分散在各处。
容错式构建只有通过更小的组件来完成。如果构建一个单体模型来容错，则需要花多得多的时间来处理每个边缘案例的低效性。如果构建单个服务实例来容错，其他服务实例会在用户发出请求时接管工作。
图 5 给出了一个使用微服务的实现示例。
图 5. 流视频应用程序的概念路由示例 在图 5 中，每个框自行维护，自行扩展，知道它位于何处，而且知道在何处获取它需要的信息。不是每种微服务架构都需要此图中的每个组件，但它们确实有所帮助！
对比图 4 和图 5，就可以看到部署一个类似的应用程序有何区别。在 中，所有组件都部署在一个可垂直扩展的系统的单个进程中。需要更多吞吐量时，整个服务器堆栈会反复扩大。每个服务器在自己的进程内运行。在图 4 的 Web 服务引擎或 EJB 容器 中获取更多吞吐量的惟一方法是，将整个服务器 JVM 扩展到集群化的环境内的一个新实例。但是，这也会创建另一个 Web 容器、另一个嵌入式 HTTP 服务器，另一个消息引擎等，无论这些组件是否需要扩展。
与图 4 中的扩展类型相比， 拥有可独立扩展的组件。我将在 小节中介绍各个组件和它们如何扩展，但现在仅关注每个组件和服务的分布式性质。不同于图 4 中的示例应用程序（它需要高度可用的 Web 应用服务器堆栈来提供可用性），这些组件具有分布式性质，仅提供单个专一的功能，通常使用与其他组件不同的技术。此结构使应用程序架构能够快得多地演变，而且与其他组件独立地包含更新的技术和更新的版本。
总之，越小越容易开发、操作、维护和交互。
更快 |
