当我们谈论服务网格的时候，有几个问题经常被提及。这些问题的范围覆盖从简单的了解服务网格的历史，到产品和架构相关的比较深入的技术问题。

为了回答这些问题，通过 Aspen Mesh 之旅，我们带来三个主题的系列博文来讨论我们为什么选择了 Istio 。

作为开始，我将重点讨论我最经常被问到的问题之一：

为什么你选择服务网格，是什么原因促使你这样做？

LineRate ：高性能负载均衡软件

这个旅程起源于来自 Boulder 的初创公司 LineRate ，该公司在2013年被 F5 Networks 公司收购。 LineRate 除了是我曾经有幸参与的最聪明、最有才华的工程团队，还是一款轻量级高性能 L7 软件代理。当我说高性能时，我正在谈论的是如何将5年前在数据中心已经存在的服务器，变成一个高性能20+ Gbps 200,000+ HTTP 请求每秒的全功能负载。

虽然性能本身是引入注目的并为我们的客户打开了大门，但是我们的出发点在于客户期望付费的是容量，而不是硬件。这种见解是 LineRate 的核心价值主张。这个简单的概念将使我们的客户能够改变他们在应用之前使用和部署负载均衡的方式。

为了满足这个需求，我们交付了一种产品和商业模式，使我们的客户能够基于 COTS （可在市场上买到的）硬件按需多次复制他们的软件，从而不管部署多少实例都可以获得峰值性能。如果客户需要更多的容量，他们只需要简单的升级其订购层并部署更多的产品副本，直到达到他们许可证允许的带宽，请求速率或者交易速率。

这很有吸引力，我们也取得了一些成就，但是很快我们有了新的想法……

效率优于性能

对于我们而言，应用架构正在发生变化，而客户的价值曲线随之变化的趋势也变得明显。我们在与资深团队沟通的过程中注意到，他们讨论的是诸如效率，敏捷，速度，印迹和横向扩展这类的概念。同时我们也开始听到这些领域的创新者开始采用Docker的新技术，以及它将如何改变应用和服务交付的方式。

我们与这些团队交流的越多，思考我们如何开发自己的内部应用程序，我们就越意识到转变正在发生。团队从根本上改变他们交付应用的方式，结果是我们的客户开始更少的关注原始性能而是更多地关心分布式代理。这些转变还有更多地收益，包含减少应用的故障域，增加部署的灵活性和赋予应用将负载和网络作为配置管理的能力。

与此同时容器和容器编排引擎也开始登上舞台，因此我们开始致力于通过一个新的控制面板以容器的方式交付 LineRate 的产品，并深入的思考人们未来会如何使用这些新技术来交付应用。

这些发生在2015的早期讨论促使我们思考未来应用交付将会如何……

与时俱进的想法

随着我们对于未来应用交付方式的思考，我们开始关注云原声分布式应用领域中有关策略和网络服务的概念。尽管我们仍然有很多不同的优先级项目，改变应用蓝图，云原生应用和基于DevOps交付模式的想法始终在我们思想的最前端。

在这个领域将会有一个新的市场。

我们设计了许多项目，但由于种种原因未能成功。我们亲切的称这些项目为 v1.0 ，v1.5 和 v2.0 。每个项目都有一种解决分布式应用架构（微服务）挑战的独特技术。

我们尽最大可能去思考。下一个应用交付控制架构（ ADC ):一个完全与 API 驱动的控制面板和一个分离的数据面板。数据面板可能来自云你能够设想到的任意一种形式：靠近微服务的专用硬件，商用软件，或者云原生组件（就像服务网格）。这种无限可扩展的架构可以实现优雅的平衡，能够完美的工作于任意规模的任意组织的任意一种工作。很有野心吧？我们陷入了为客户提供所有东西的陷阱。

接下来，我们在“1.5”中完善了我们的方法，我们决定开发一种策略语言…… 关键是要定义开源的策略接口并将它无缝地连接到完成工作的数据路径。在一个真正开放的平台中，其中一些数据路径也是开源的。但是仍然有很多发展中的事情没有一步到位；事后看来，其中一些事情已经到来了…… 市场还没有到来，加上我们在开源方面也没有专业知识，于是我们在描述我们在做什么以及为什么时遇到了麻烦。

但是想法仍然在我们的脑海中燃烧，而我们也没有放弃……

在 2.0 版本，我们设计了一个帮助希望开始容器之旅的 F5 的用户的计划。技术是新的，而市场也刚刚开始走向成熟，我们决定用户将会通过三步开启他们的微服务之旅。

1. 试验 - 在笔记本、服务器或者云主机上通过容器测试应用。
2. 生产规划 - 识别能够帮忙开发人员在生产环境部署容器化应用的技术。
3. 规模经营 - 重点关注容器应用的可观察性，可操作性和安全性，以减少平均停机发现时间 MTTD 和平均故障恢复时间 MTTR。

对于实验性用户我们做不了什么，但是对于生产规划，我们将创造一个开源的连接器，用来连接容器编排环境和 BIG-IP 。我们称之为 BIG-IP Container Connector，我们能够解决现有 F5 客户的问题，并和这些用户讨论下一步工作。BIG-IP ContainerConnector 的团队持续弥合在 ADC 和 快速改变的容器编排环境中的差距。

我们也开始开发一个新的轻量级容器化代理，称之为容器服务代理 （ Application Service Proxy ），或者 ASP 。 与 Linkerd 和 Envoy 类似的是，它被设计来促使微服务间的高效、灵活、可控的通信。与 Linkerd 和 Envoly 不同的是，它并没有开源社区。我们在考虑一种开源策略，同时它对于 ASP 意味着什么。

与此同时，F5 也在发生变化……

Aspen Mesh - F5 的创新

在我们开展 ASP 市场计划的同时，F5 通过孵化计划改变了投资新技术和新兴市场的方式。这两个事件与容器的爆炸性增长相结合，导致我们决定承诺在现有的开源服务网格之上构建产品。我们选择 Istio 是因为它具有吸引力的声明式策略语言，可扩展的控制平面架构以及其他我们将在更深入讨论时会涉及的内容。

计划已定，是时候将我们的想法推向我们力所能及的位置。Aspen Mesh 是这次推广的结果，也是一段历程的结局，同时也开启了一个新的篇章。

本系列文章的第二和第三章节将会重点讨论为什么我们决定将 Istio 作为我们服务网格的核心，和我们将会在未来的几个月内推出什么样的商业化的服务网格。