前言

构建软件是困难的，通过网络连接不同的服务更困难。任何时候，通过网络发送数据包、消息或请求都不能保证其结果。这个请求会发送成功吗？它需要多长时间？如果请求失败，会有人知道吗？

Docker和Kubernetes已经内置了很多功能来支持像微服务这样的分布式服务架构，但是它们加剧了现有的通信问题。一个运行异常的服务可能会毁掉一切。

在与全球各地的采用微服务的组织合作时，我发现让团队持续思考和解决沟通问题是非常困难的，其中涉及许多问题：他们将如何落实服务发现？是采用超时、重试、熔断，还是链路追踪、身份验证这样的方式？像Netflix、Twitter和Google这样的大型云计算公司开创了一些早期成功的微服务架构。这些公司必须建立许多自己的开发者工具和基础设施来解决上述问题，幸运的是，他们开源了其中的大部分功能。那么，其他组织可以使用NetflixOSS全家桶或Twitter Finagle吗？可以，而且有些组织确实这么做了，但这样做会带来一个新的运作上的问题。

例如，NetflixOSS全家桶主要是为Java开发人员编写的。那么Node.js、Golang和Python团队怎么办呢？这些团队要么自己构建库，要么将其在互联网上找到的各种各样的功能组合在一起，而且还必须将这些与“网络通信”相关的代码混合到业务逻辑中。这增加了传递依赖性，使代码变得混乱，并且使修订变得更加困难。使用这些应用程序网络库来构建服务架构、升级、打补丁，以及跨不同语言来进行这些操作，是非常复杂且容易出错的。

服务网格是解决此应用程序网络问题的更简洁的解决方案。通过服务网格，我们将应用程序网络逻辑抽象成一个专用的基础设施，并将其应用到所有的服务中，而不管这些服务是用什么语言编写的。

Istio是一个可扩展的、成熟的、功能强大的服务网格实现方案，它最初来自IBM和Google的一个项目。我于2017年1月来到Istio团队，并且很早就开始承担这个项目的相关工作。2018年年底，我在初创公司Solo.io担任全球领域首席技术官，专注于服务网格技术的研发和服务网格落地的推进。

从头开始创建一家公司，推动这项技术的发展，并就这个话题写一本深入的书，不是一件容易的事情。我需要一个有奉献精神和有激情的人来帮助完成；所以，当我做到一半的时候，Manning团队和我邀请了Rinor Maloku加入进来。感谢我们二人在Solo.io工作期间为社区和客户共同努力而度过的时光。其中一些客户负责世界上最大的Istio部署项目，Rinor和我已经能够根据实际经验为Istio编写一本优秀的书。我们希望这本书能向你展示Istio的价值和力量，并让你像其他许多人一样，轻松地将这项技术应用到生产环境中。