上周，潭主原计划跟领导汇报近期凿墙的工作进展，没想到既定日程被同事拖堂给耽误了。
失之东隅，收之桑榆。
随后被领导安排旁听了一场新晋“民营一哥”京东的技术分享，小有收获。
印象较深的是京东云有个产品叫“云舰”，定位为“多云一致的云原生混合云平台”，有点绕口，但听上去的确跟之前的多云CMP有些不同。
想来，一切都是为了竞争。
温故而知新
随着技术发展，市场演进，互联网大厂的云计算产品日新月异。
反正你能想到的时髦产品在应用市场里都能找到，企业上云，数字化转型，一网打尽。
像阿里这样的国内互联网大厂在公有云市场抢得先机，占据了不少市场份额，可惜了AWS和Azure，虽然技术领先，但出身不好。
对国内大中型企业和政府机构来说，基于政策、安全和自身等多方面因素，在公有云上步伐缓慢。
于是，近几年京东、字节跳动也纷纷跟进企业云计算市场，谁都想在“由公转私”这事上分一杯羹。
话说这次京东云为我司定制的PPT也算务实，但感觉还缺少对客户现状的了解，更像是抛砖引玉。
会上提到了Service Mesh，引发了潭主的兴致，想来之前学的有关服务网格的东西好像也忘得差不多了。
于是乎，温故而知新。
什么是Service Mesh？
介绍Service Mesh就不得不提Linkerd，算得上是开山鼻祖。
Linkerd是Buoyant公司在2016年开源的高性能网络代理程序，最新的官网描述：
Ultra light, ultra simple, ultra powerful. Linkerd adds security, observability, and reliability to Kubernetes, without the complexity. CNCF-hosted and 100% open source.
之前的版本，还是英文看上去短小精炼。
Linkerd is a transparent proxy that adds service discovery, routing, failure handling, and visibliity to modern software applicaiton.
简单说，Service Mesh是一个专门处理服务通信的基础设施层。
通过独立的网络代理实现服务发现、负载均衡、动态路由和安全通信等功能。而这个进行流量“劫持”的透明代理，就是当下流行的Service Mesh。
业内把这种模式叫做Sidecar，即边车模式。
如果把服务比作一辆摩托，那么注入了Sidecar模式的服务就成了边斗摩托，开起来飒飒的感觉。
至于为什么出现Service Mesh，潭主感觉它是云原生发展到一定阶段的“必然”产物。
从虚拟机膨胀到微服务扩张，云原生带来好处的同时，也带来了很多挑战。
其中，很大的挑战在于如何优雅地管理微服务，使得分布式复杂网络环境中的服务之间能够可靠的通信，保障系统的可用性和SLA。
Linkerd系统架构
Service Mesh实现了业务功能与网络功能的解耦，应用开发人员可以专注于业务代码逻辑，而将复杂的网络通信交给Service Mesh。
Service Mesh通常由两部分构成：
Data Plane：数据平面，负责将应用请求可靠地交付到复杂分布式网络中的目标服务。
Control Plane：控制平面，控制服务间如何通信，以什么样的规则将应用请求交付到目标服务。
写到此处，潭主想起了以前的工作伙伴，原Redhat技术专家出来创业，自研了一个国产的Service Mesh产品，叫Flomesh。
应该说，潭主对于Service Mesh的很多理解都是从Flomesh开始的。
记得几年前最初交流时，Flomesh就实现了传统架构和云原生架构的流量整合，解决了潭主最关心的互联互通问题。
Linkerd的路由机制
在潭主看来是，Linkerd也可以看成是应用网络上路由交换，跟SDN一样，也有相应的控制和流量编排。
Linkerd的核心是路由，接受服务请求并转发给目标服务，整个过程分为鉴别、绑定、解析、转换和负载均衡几个步骤。
鉴别（Identification）：通过identifier（鉴别器）将服务请求转化为Service Name，服务名通常配有前缀。
绑定（Binding）：鉴别后有了服务名，再根据router中dtab进行转换，将Service Name转换成Client Name。
解析（Resolution）：通过interpreter（解释器）将Client Name解析成最终服务的IP和Port。
转换（Transformation）：根据需要，通过transformer对解析后的IP和端口进行地址过滤和端口替换。
负载均衡（Load Balance）：解析后，Linkerd会根据客户端配置的负载均衡算法择优选择处理应用请求。
Dtab是Delegation Table的缩写，可以当做一个路由表，由一系列路由规则（Dentry）组成。
Linkerd配置文件中最重要的是namer（指定使用服务发现工具的方式）和router（配置多种协议的RPC支持），可以配置一个或多个router，但每个router只负责处理一个特定RPC协议的流量，而且区分流向。
Linkerd的部署模式
前面介绍了一些Linkerd的概念，具体到架构层面有两种部署模式：
Per-Host模式：主要用于VM和物理机
Sidecar模式：主要用于云原生K8S环境
无论是Per-host还是Sidecar模式，都需要通过配置对Linkerd进行组网，使Linkerd和服务之间相互通信，关键在于router的设计，分为三种服务模型：
Service2Linkerd：服务请求发送至本地Linkerd，之后通过outgoing router将请求转发至目标服务，该模式无需进行transformer，Linkerd作为Client端实现负载均衡等功能。
Linkerd2Service：服务请求发送给远端Linkerd，之后通过incoming router将请求转发给目标服务，该模式丧失了Client端优势，但能获得服务运行时指标，需要进行端口转换。
Linkerd2Linkerd：集成了上述两种模式的优点，无论客户端负载均衡，还是服务端运行指标都能实现，是Service Mesh原本该有的样子。该模式下，所有服务流量都被经过Linkerd，服务流量被“劫持”，通过outgoing router的transformer完成端口替换后将流量打到远端的incoming router上，通过Linkerd实现端到端的服务。
Namerd的集中管控
讲完了Linkerd的数据平面，再来说说控制平面的大总管Namerd。
在Linkerd中，如何管理分散的Linker实例是一个问题，于是引入了Namerd，通过中心化的方式实现Service Mesh的配置集中管理，将分散在Linkerd实例中的dtab路由统一存放到Namerd支持的后端存储中，如Consul集群。
该架构下，Service Mesh中的Linkerd实例不再直连服务发现工具，而是通过Namerd与后端服务发现工具进行交互，既降低了Linkerd与后端服务发现工具直连带来的潜在性能影响，又借助Namerd提供的CLI或者API动态修改dtab路由，实现灰度发布等功能。
变化一直在路上
从Linkerd 1.x到Conduit，再到Linkerd 2.x，发生了不少变化。
听说Linkerd 2.x又精进了，有一个新Feature，可以用“Service Sidecar”的方式部署Linkerd，而无需在集群范围内整体部署。
不过在Google向CNCF贡献了Istio之后，Istio后来者居上，俨然成了Service Mesh的事实标准。
潭主总体感觉Service Mesh的核心依旧，变化的只是实现方式和组件布局。
之所以花时间复盘Linkerd和Flomesh，是因为了解一些技术的来龙去脉，可以感知到变化，在一定程度上能弥补缺乏实战经验带来的不足。
Service Mesh的话题很大，今天先起个头，后面再补习一下Istio，看看后起之秀到底有何不同。
最后，潭主祝读者朋友们中秋快乐！
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
