重磅推荐
【商品详情】
【编辑推荐】
√ 阿里P0 |百万集群级|电商系统缔造者实践精华 √ 阿里巴巴分布式架构与软负载体系核心骨干执笔
√ 侧重“排坑”，解决|排查Service Mesh常见问题是亮点
√ 从容器到Kubernetes，再到服务网格，全线实战贯通
【内容简介】
《Service Mesh实战：用Istio软负载实现服务网格》为网格服务技术的实战详解图书。作者以初学者角度展示软负载在分布式架构中承担的角色，引入容器时代主角Kubernetes；再从路由层面全面展开对Service Mesh 与Istio 的系统介绍和深入剖析，包括其功能与特色；*后通过源码剖析从实现细节上分析Istio 的几大关键设计。不论你是刚开始接触软负载的初学者，还是有一定经验的架构师，都可以在这本细致入微的图书中找到想要的实用内容。
【作者简介】
周遥：挖财中间件架构师，原阿里巴巴中间件团队技术专家，8年分布式架构经验，三项国家发明专利，在软负载领域拥有相当丰富的经验，阿里软负载核心产品VIPServer原作者。
【媒体评论】
推荐序 1CNCF 所提出的云原生概念在相当短的时间内得到了来自 Alibaba、Google、IBM、Pivotal等公司的支持与参与，背后的核心驱动力在于通过打造“事实标准”的软件去解决云厂商对客户的锁定问题。云原生的本质，是解决应用的弹性（resiliency）、易用性（usability）和可移植性（portability）。当这“三性”得到妥善的解决后，客户所开发的（分布式）应用可以方便、高效地同时部署于多个云厂商所提供的云服务之上，这不仅解决客户所担心的技术锁定问题，还使得应用能很好地满足法规（指要求某些影响国计民生的应用必须同时部署于多个云厂商的云上）、全球多活等严苛的要求。在解决“三性”的道路上，Service Mesh 被视为新一代分布式应用架构的软件基础设施，并被明确地写入了云原生概念的定义中。Service Mesh 可以理解为是微服务软件架构（microservices）的进一步延伸，用于解决大规模微服务应用所面临的多语言支持、服务全局*治理、服务（全球）发现与路由、安全保障等挑战的关键技术手段。开源软件 Istio 的出现，有望成为云原生中 Service Mesh 的软件事实标准。Istio 所提出的“数据平面”（Istio 中的 Pilot-discovery、Mixer 等组件）和“控制平面”（Envoy）通过很好的概念切分践行着软件行业解决复杂问题的终级范式——分而治之，这两个“平面”外加“运维平面”（Service Mesh 中并没有定义）将能很好地助力解决云原生所致力于解决的“三性”问题。Service Mesh 的*境界在于让分布式应用无须关注服务（全球）发现与路由、限流、降级、熔断、安全等通用问题，但达到这一目标并非一蹴而就，这就需要同仁们在各自的岗位上共同学习、运用和成就这一技术。本书的出现能帮助读者更好地理解以 Istio 为代表的 Service Mesh 技术背后的设计思路和了解阶段性的探索成果。——李云 阿里巴巴中间件高级技术专家
推荐序 2近几年，随着 Kubernetes 的兴起，云原生的理念得到了大规模的推广。在整个业界，我们看到了云原生的理念正在重新塑造整个技术栈，从应用编排到服务化，再到Serverless，等等。Linkerd 背后的公司 Bouyant 首先提出了 Service Mesh 的概念，随后 Google、IBM、Lyft 共同推出了 Istio。目前来看，它有成为 Service Mesh 事实标准的趋势。因此，想要了解云原生时代下微服务架构应该如何设计和实现，学习 Istio 是一条逃不开的路径。那么怎么学习 Istio ，就成了摆在 Istio 爱好者面前的一大难题——Istio 组件繁多，功能也非常强大，要搞清楚这些组件的功能，仅凭翻阅 Istio 官方文档当然远远不够。难上加难的是，市场上讲述 Istio 的书屈指可数。好在，周遥的这本《Service Mesh 实战：用 Istio 软负载实现服务网格》适时问世了，它详细剖析 Istio 的各个核心功能，完整弥补了这方面的资料缺失，并且介绍了国内部分互联网企业在 Service Mesh 上的实践，可谓针对这一热门技术不可多得的好书。对于想要快速了解 Istio功能，进而准备上手实践的朋友来说，这本书是有限的选择中*不会让你后悔的一个。——黄挺 蚂蚁金服中间件技术专家
【目录】
第 1 章 分布式发展史1
1.1 单机小型机时期 1
1.1.1 互联网的诞生 2
1.1.2 复杂应用拆分. 3
1.1.3 遭遇性能问题 3
1.2 集群化时期 4
1.2.1 从高端设备到普通 PC 4
1.2.2 硬件负载均衡设备 5
1.2.3 资源配置问题 5
1.2.4 积少成多的优势 6
1.2.5 集群化架构 6
1.2.6 软件负载设备 7
1.3 服务化时期 8
1.3.1 应用到服务 8
1.3.2 远程调用 8
1.3.3 虚拟 IP 地址 9
1.3.4 复杂的调用关系 10
1.3.5 服务治理 11
1.3.6 旁路负载 12
1.4 微服务时期 13
1.4.1 服务细化 13
1.4.2 架构轻量化 14
1.5 服务网格（Service Mesh）新时期 15
1.5.1 多语言的困难 15
1.5.2 指数级增加的系统复杂度 15
1.5.3 Linkerd 诞生 16
1.5.4 *代服务网格架构 17
1.5.5 第二代服务网格架构 18
1.5.6 生产应用情况 19
1.6 本章小结 20
第 2 章 Service Mesh：以 Istio 为例 21
2.1 Istio 的设计理念 21
2.1.1 Istio 的诞生背景 22
2.1.2 控制一切的两个平面 23
2.1.3 接口与平台化 24
2.1.4 中心化与分散化的抉择 25
2.2 数据平面 27
2.2.1 xDS-API . 27
2.2.2 服务负载及流量控制 28
2.2.3 入口与出口网关 31
2.2.4 故障应急机制 32
2.2.5 故障注入 32
2.3 控制平面 33
2.3.1 Pilot 结构及功能 33
2.3.2 Mixer 结构及功能 34
2.3.3 稳定性与容灾能力 37
2.3.4 请求属性（Attribute） 37
2.3.5 操作配置（Operator Config） 38
2.4 安全控制 40
2.4.1 Citadel 结构及功能 42
2.4.2 Istio 身份（Identity） 42
2.4.3 认证（Authentication） 43
2.4.4 鉴权（Authorization） 44
2.5 Hello, Istio!45
2.5.1 安装 Docker 45
2.5.2 安装 Kubernetes 47
2.5.3 初始化 Master 节点 48
2.5.4 配置 weave 网络插件 49
2.5.5 安装 Istio 49
2.5.6 向 Istio 部署*个应用 50
2.5.7 部署 BookInfo 系统 51
2.6 动手体验 Istio 53
2.6.1 几个基本概念 53
2.6.2 体验 1：按版本路由55
2.6.3 体验 2：按权重分流 56
2.7 BookInfo 示例分析 57
【前言】
早在 2013 年，我供职的阿里巴巴集团（以下简称阿里）中间件软负载团队就受运维部门之托，开始着手研究新一代的内部服务调度与治理系统。那个时候微服务概念还没有提出，但阿里在服务化方式上已经走在前列了——强壮的业务由拥有数量庞大的服务群及复杂的调用关系支撑着。运维的需求集中于希望能提供一种“更加灵活、响应更快速且更低成本”的方案来连接、控制、配置整套线上服务系统；因为在当时的 LVS 负载体系下，由于硬件的限制，是不可能做到快速响应的，而独立部署的 LVS 集群在配置与多环境下都又略显得有心无力。当时我的领导蒋江伟（花名小邪）将这一重任交予了我并预示了 SDN（Software Defined Network，即软件定义的网络）的发展方向，我很荣幸能拥有这样的机会，当然也没有辜负他的期望。一年后，VIPServer 系统诞生，*次在阿里内部以纯软路由的形式调度各大系统间的请求，并在两年内完全主宰了内部的服务调用需求。软路由的好处在于“软”，不与实体布线、交换机配置或硬件绑定，对于不同的流量流向什么样的地方可以任意且随时地变更，此即灵活。例如我们可以将来自 Android 客户端的流量指定到链路中拥有 Test 标记的服务器，这样可以实现诸如灰度发布的功能。分布式系统发布至今，系统数量空前爆炸，业务的关系与配置越来越复杂，因此对环境治理与隔离的要求也越来越高。回顾应用容器的发展，从纯硬件到硬件虚拟化、容器化再到弹性编排，无不都是走向“软件定义”这个方向，因此软负载领域也应该如此。2017 年我加入挖财，发现对较大型企业而言，中小规模企业更加饱受服务环境治理之苦，因为中小规模的企业通常没有过多精力自行研发属于自己的软负载体系，大多通过修改开源的组件来实现目的。这样的问题在于无法组成一个平台体系，虽然基本功能（如配置、服务发现）能够满足，一旦涉及多级协调功能（如链路压测、故障注入体系）的时候，便捉襟见肘了。虽然阿里早些年已经拥有这样的能力了，但想要将其直接复制到外部的企业却是一项几乎不可能完成的任务。阿里的关键技术都是定制的（如 RPC 服务 HSF），设计所针对的场景不一定适合中小企业，即关注的点不同；所以对于中小企业而言，需要的就是一个能够连接各软负载开源产品的平面，而且这个平面应该与主流的服务编排、RPC、配置及服务发现完美兼容，并*限度地支持链路功能扩展。带着上述问题，我一直在思考这个产品的存在形式；而在 Istio 问世以后，我便相信这就是它的*形态。我个人看好服务网格（Service Mesh）在服务架构上的影响力，并且相信这是微服务架构的下一个阶段，因为对多数企业而言架构本身的复杂度已经开始超越业务逻辑本身，如果不加以统一管理与规划，那么只是维护成本就已经很高了。服务网格的思想就像是分布式服务本身下沉到技术栈中，只对业务提供接口供其调用。Istio很巧妙地将其分成了“控制平面”与“数据平面”两部分，使得接口本身更加清晰。接口清晰的好处在于更加容易地定义边界与职能，例如“数据平面”部分，Istio 便可以直接依托于开源Envoy 来实现，而且这并不是*的选择；而“控制平面”则为运维人员提供了统一的接口来操作整个链路，相较之前的零散的配置，仅这一点就可以节省不少的人力成本。2018 年，阿里顺势推出了自己的 Nacos 1 来争夺这一领域，蚂蚁金服也公布了 SOFAMesh项目。这说明软负载仍然是大型分布式系统基础的重点，只有将环境与调用梳理清楚、高效利用起来，上层的业务及周边的扩展基础才能快速地推进。未来的分布式架构只会愈加专注，职能划分愈加精细，计算愈加弹性灵活。虽然在本书编写过程中已经尽力反复去论证、实践每一处，但难免遗误，希望大家积极批评指正。*后我要感谢下面这些在编写本书时一直支持我的朋友们，无论是帮忙订正还是写序，感谢你们！同时本书第 6 章得到了蚂蚁金服团队的大力支持，特别感谢你们！当然还有在背后一直支持我的家人们，谢谢！
【免费在线读】
【书摘与插画】
