15.凤凰架构：构建可靠的大型分布式系统 --- 服务网格

第15章　服务网格
		容器编排系统管理的最细粒度只能到达容器层次，在此粒度下的技术细节，仍然只能依赖程序员自己来管理，编排系统很难提供有效的支持。

		服务网格：
			是一种用于管理服务间通信的基础设施，职责是支持现代云原生应用网络请求在复杂拓扑环境中的可靠传递。在实践中，服务网格通常会
		以轻量化网络代理的形式来体现，这些代理与应用程序代码部署在一起，对应用程序来说，它完全不会感知到代理的存在。

		服务网格 只是一种处理程序间通信的基础设施，典型的存在形式是部署在应用旁边，一对一为应用提供服务的边车代理以及管理这些代理的控制
	程序。Netflix Prana 的代理需要由应用程序主动去访问才能发挥作用，但在容器的刻意支持下，服务网格无需应用程序的任何配合，就能强制性的对应用程序
	的通信进行管理。它使用了类似网络攻击里中间人流量劫持的手段，完全透明(既无需程序主动访问，也不会被程序感知到)的接管容器与外界的通信，将管理的粒度从
	容器级别细化到每个单独的远程服务级别，使得基础设施干涉应用程序、介入程序行为的能力大大增强。如此一来，云原生希望用基础设施接管应用程序的非功能
	性需求的目标就能更进一步。


15.1　透明通信的涅槃
	15.1.1　通信成本
		从下面5个阶段，理解分布式服务的通信是如何逐步演化为 服务网格的：
			1.第一阶段：将通信的非功能性需求视为业务需求的一部分，通信的可靠性由开发人员来保障
				本阶段是软件企业刚刚开始尝试分布式时选择的早期技术策略。这类系统原本所具有的通信能力一般并不是作为系统功能的一部分被设计出来的，而
			是遇到问题后修修补补积累所形成的。开始时，系统往往只具备最基本的网络API，譬如集成了OKHTTP、gRPC这样的库来访问服务，如果远程访问接收
			到异常后，就编写对应的重试或者降级逻辑去处理。在系统进入生产环境以后，遇到并解决一个个通信问题，逐渐在业务系统中留下了越来越多关于通信
			的代码逻辑。这些通信的逻辑由业务系统的开发人员直接编写，与业务逻辑直接处在一个进程之中。

				这一阶段的主要矛盾是绝大多数擅长业务逻辑的开发人员并不擅长处理通信方面的问题，要写出正确、高效、健壮的分布式通信代码，是一项专业性
			很强的工作。由此决定了大多数普通软件企业都很难在这个阶段支撑起一个靠谱的分布式系统来。另外一方面，把专业的通信功能强加于普通的开发人员，
			无疑为他们带来了更多的工作量，尤其是这些"额外的工作"与原有的业务逻辑耦合在一起，让系统越来越复杂，也越来越容易出错。


			2.第二阶段：将代码中的通信功能抽离重构成公共组件库，通信的可靠性由专业的平台开发人员来保障
				开发人员解耦依赖的一贯有效办法是抽取分离代码与封装重构组件。微服务的普及离不开一系列封装了分布式通信能力的公共组件库，代表的产品有
			Twitter的Finagle、Spring Cloud 中的许多组件等。这些公共的通信组件由熟悉分布式的专业的平台开发人员编写和维护，不仅效率高、质量好，
			一般还都提供了经过良好设计的API接口，让业务代码既可以使用它们的能力，又无需把处理通信的逻辑散布于业务代码之中。

				分布式组件让普通开发人员开发出靠谱的微服务系统成为可能，但普通开发人员使用它们的成本依然很高，不仅要学习分布式的知识，还要学习这些
			公共组件的使用方法。最麻烦的是，对于同一种问题往往需要用到多种不同的组件才能解决。这是因为通信组件首先是一段特定语言编写的程序，是与语言
			绑定的，一个由Python编写的组件再优秀，对Java系统来说也没有太多实用价值。目前，基于组件库开发微服务依然是最为广泛的方案，却不是一种完美
			的解决方案，这是微服务基础设施完全成熟之前必然会出现的应用形态，同时也一定是微服务进化过程中必然会被替代的过渡形态。

			3.第三阶段：将负责通信的公共组件库分离到进程之外，程序间通过网络代理来交互，通信的可靠性由专门的网络代理提供商来保障
				为了能够把分布式通信组件与具体的编程语言脱钩，也为了避免开发人员还要专门学习这些组件的编程模型与API接口，这一阶段进化出了专门负责
			可靠通信的网络代理。这些网络代理不再与业务部署在同一个进程空间，但仍然与业务系统处于同一个容器或者虚拟机中，可以通过回环设备或者UDS(
			unix domain socket)进行交互，具备相当高的网络性能。只要让网络代理接管程序七层或者四层流量，就能够在代理上完成断路、容错等几乎所有
			分布式通信功能。

				通过网络代理来提升通信质量的思路后，它本身的使用范围其实并不算特别广，但方向思路是对的。这种思路后来演化出了两种改进形态。一方面，
			如果将网络代理从进程身边拉远，让它与进程分别处于不同的机器上，这样就可以同时给多个进程提供可靠通信的代理服务，这条路线就演变成了今天
			常见的微服务网关，在网关上同样可以实现流控、容错等功能。另一方面，如果将网络代理往进程方向靠近，不仅让它与进程处于一个共享了网络名称
			空间的容器组之中，还要让它透明并强制的接管通信，这便演变成了下一个阶段说的边车代理。


			4.第四阶段：将网络代理以边车的形式注入应用容器，自动劫持应用的网络流量，通信的可靠性由专门的通信基础设施来保障
				与前一阶段的独立代理相比，以边车模式运作的网络代理有两个无可比拟的优势。

				第一个优势是，它对流量的劫持是强制性的，通常是直接考写容器的iptables转发表来实现的。此前，独立的网络代理只能当程序首先去访问它时，
			它才能被动的为程序提供可靠的通信服务，只要程序有不选择它的可能性，代理就永远只能充当服务者而不是管理者。如15-3中保留了两个容器网络设备
			直接相连的箭头就代表这种可能性，而这个阶段的图15-4中，服务与网络名称空间的虚线箭头代表被劫持后应用程序以为存在，但实际并不存在的流量。

				第二个优势是，边车代理对应用是透明的，无需对已部署的应用程序代码进行任何改动，不需要引入任何的库(有部分边车需要)，也不需要专门的
			去访问某个特定的网络位置。这意味着它对所有现存程序都具备开箱即用的适应性，无需修改旧程序就能直接享受到边车代理的服务，这样它的适用范围
			就变得十分广泛。目前边车代理的代表产品有 Linkerd,Envoy,MOSN等。

				代理能够透明且具有强制力的解决可靠通信的问题，但它本身也需要足够的信息才能完成这项任务，譬如如何获得服务列表，譬如得到每个服务名称
			对应的ip地址，等等。这些信息不会自动到边车里去，需要由管理员主动去告知代理，或者代理主动从约定好的位置获取。可见，管理代理本身也会产生
			额外的通信需求。如果没有额外的支持，这些管理方面的通信都得由运维人员去埋单。为了管理与协调边车代理，程序间通信进化到了最后一个阶段：服务
			网格。


			5.第五阶段：将边车代理统一管控起来实现安全、可控、可观测的通信，将数据平面与控制平面分离开来，实现通用、透明的通信，这项工作由专门
			的服务网格框架来保障。

				从总体上看，服务网格包括两大块内容，分别是由一系列与微服务共同部署的边车代理，以及用于控制这些代理的管理器所构成。代理与代理之间需要通信，
			用以转发程序间通信