189 8069 5689
导读
10年积累的网站制作、成都网站制作经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先制作网站后付款的网站建设流程，更有金乡免费网站建设让你可以放心的选择与我们合作。
近期与几位企业用户交流 Service Mesh 及其相关技术，大家对于它所展现的形态以及未来发展都表示出极大的兴趣。但对当下企业应用现状如何与 Service Mesh 整合到一起又表现出极大的困惑。本文力图结合Service Mesh技术特性与企业应用的实际情况，就 Service Mesh 如何应对企业应用给出博云自身的思考，欢迎有兴趣的朋友一起讨论。
在进行详细探讨之前，我们首先回顾一下 Service Mesh 的定义：服务网格是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中，服务网格通常实现一组与应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
从定义中我们可以清晰地看到 Service Mesh 的技术定位：“处理服务间通信的基础设施层”。因此我们不能希望它帮我们简化开发测试场景面临的挑战（DevOps 或者应用服务化，当然一定程度上可以解耦应用与基础中间件的调用关系，稍后会详细说明），或者解决应用部署场景的问题（部署问题由容器编排平台处理更加合适）。
总体来说，Service Mesh 专注业务应用部署上线后期的通信领域问题，同时一定程度上解耦业务单元与基础中间件的调用关系（例如服务注册中心）。如图所示：
围绕 Service Mesh 所聚焦的领域以及如何服务于企业级应用，本文重点探讨4个问题：
· Service Mesh 的技术特性；
· Service Mesh 与企业应用的整合之道；
· Service Mesh 的部署管理形态；
· Service Mesh 的远景形态。
考虑到目前 Service Mesh 落地方式集中在以容器化为首的 PaaS 领域之内，因此我们也将重点基于容器化方案探讨 Service Mesh 所具备的技术特性。
从 Service Mesh发 展来看，无论是基础的 Docker 运行环境，还是以Kubernetes 为“事实标准”的容器编排环境，都是 Service Mesh 能够快速发展的基石。以 Kubernetes 为例，Service Mesh 并非技术上的创新，更多是利用 CRD 特性对 Kubernetes 的扩展以及传统技术的整合（防火墙、DNS服务发现等）。以 Isito 为例， Istio 基于引入的标准规范以及 Kubernetes CRD 特性自定义几十种自身的资源，并依赖 kubectl CLI 命令工具对这些 CRD 进行统一管理。
我们发现Service Mesh 的技术特性主要体现在5个方面：容器编排环境；数据代理控制；配置管理分发；服务链路追踪；服务通信安全。
容器编排环境
结合 Service Mesh 落地的几个方案来看，容器编排环境是 Service Mesh 能够落地的必备要素之一（这里暂时不深入讨论容器化采用的技术原理，如namespace，AUFS等）。容器化编排环境的特性能够将企业应用或者业务实例组织成方便管理和寻址的业务单元，方便系统化的方式访问这些单元。这里同样暂时忽略 Mesh 外围对接的各种 Adapter。
数据代理控制
从 Service Mesh 定义中可知，其本身是一个与应用绑定在一起的轻量级网络代理，该代理拦截所有服务请求的出站和入站流量，并依赖控制层面标准化接口提供的规则信息（最终转化成防火墙内的路由配置）进行流量的转发和控制，同时对调用日志、调用链路、响应时长进行记录和汇报。
配置管理分发
Service Mesh 为了保证数据代理功能的独立性，将配置与数据代理进行解耦。配置也称作控制层面，负责从容器环境搜集服务信息，并且以高度抽象化的标准接口提供给数据代理服务，为流量转发提供可靠的路由依赖。同时控制层面面向用户提供“声明式”的规则定义，这些规则会存储在容器平台中，同时生成路由转发的流量控制规则，并且以接口的形式提供给数据代理服务，为路由转发的流量控制提供管理依据。例如在 Istio 中规则定义表现为 Istio 定义的 CRD 资源，规则生效接口表现为 Policy 提供的 XDS 接口。
服务链路追踪
服务链路在 Service Mesh 中是基础必备的功能。它的实现依赖两部分：数据采集和链路呈现。数据采集主要依赖数据代理服务进行服务请求拦截或者转发时记录服务请求的源IP地址、目的IP地址和对应的服务名称等有效信息；链路呈现依赖于分布式跟踪系统，将采集的服务调用链路信息存储在分布式跟踪系统中，做集中呈现，例如 Zipkin 等。
服务通信安全
安全是企业应用必然关注的因素之一，那么 Service Mesh 在安全领域提供哪些技术特性呢？Service Mesh 作为 PaaS 的扩展实现，主要从3个层面为企业应用安全保驾护航：
第一：基于TLS的双向通行加密。例如Isito中可以在部署时打开TLS双向认证配置，并且依赖独立的证书管理功能，实现服务通信过程的加密。
第二：权限控制访问。Service Mesh为了保证服务调用的合法性，提供了权限访问控制。例如Isito中基于RBAC的权限访问控制；
第三：基于策略的黑白名单访问控制以及服务熔断控制。
当然仅仅依靠 Service Mesh 保证企业应用的安全是不够的，同样需要借助其他软硬件手段，例如防火墙、网络安全监控、内部异常检测等，具体不在本文讨论范围。
在了解 Service Mesh 技术特性以后，我们重点来聊一下 Service Mesh 如何与企业级应用整合。
在具体展开之前，首先我们说一下企业应用的现状与特性：根据 Gartner 对当前 PaaS 市场的统计调研结果，大部分企业处于传统应用（物理或者虚拟化）向容器化转型的阶段，不同行业都期望能够把自己的应用合理地迁移到云端（重点考虑 PaaS 领域）。但对于遗留的企业系统，尤其是核心系统上 PaaS 多多少少有一定的顾虑，因此我们把企业应用的部署形态分为三个等级（等级没有先后之分）：
第一：核心系统，短期（未来几年）不会考虑容器化处理，例如金融行业的核心数据库和核心系统等；
第二：支撑系统，当下以虚拟化居多，可能会尝试服务容器化；
第三：外部系统，虚拟化为主，期望迁移到 PaaS 平台；而目前无论是项目交付还是产品自研，绝大多数围绕第三类应用系统展开，这也是我们当下考虑的重点。
其次我们来分析一下企业应用的特性：企业应用在大多数情况下是以业务为驱动的。按照这个层面考虑，构建业务系统时存在两种情况：一体化应用和服务化应用。
针对一体化应用，与 Service Mesh 进行整合时，并不能发挥 Service Mesh 的功效（由于业务集中处理，所有功能及非功能系统全部集中在代码本身，一定程度上 Service Mesh 集成意义不大）。因此我们重点考虑服务化应用与 Service Mesh 的整合。这样考虑的缘由是基于微服务或者云原生应用是构建系统的趋势所在，也更符合应用形态的发展规律。
结合企业级应用的现状以及特性，我们把 Service Mesh 与企业应用的整合划分为四个阶段，如下图所示：
应用服务化
应用服务化与大家所说的微服务构建有一些不同之处。整体来讲，应用服务化还是利用微服务拆分原则，对应用业务单元进行服务拆分，同时确定服务间交互依赖的支撑组件。
不同的地方在于服务直接的交互组件的选型，不再采用 Spring Cloud、Dubbo 或者其他组件提供的支撑功能（如服务注册与发现，服务链路跟踪，负载均衡等），而是依赖容器平台（如 kubernetes 提供的服务注册发现，负载均衡）和 Service Mesh。此种做法的目的是将应用支撑组件下沉，帮助客户从技术调研与选型的细节中解脱出来，完全从业务角度考虑问题。业务之外的事情交由 PaaS 平台、Service Mesh 统一处理。
应用服务化，有两个目的：拆分应用业务单元和梳理业务单元调用链。(需要进一步说明：摒弃服务注册与发现组件，并非抛弃其能力，而是更换一种更方便的实现方式。开发环境下，各个服务联调直接利用 HTTP 或者其他协议的调用框架进行远程服务调用即可；测试或者生产环境中，将服务地址替换为容器平台注册的 Service 地址，从而具备服务注册发现，服务负载的能力)。
当然针对之前已经基于 Spring Cloud 或者 Dubbo 开发的业务系统，在不改变原有架构的基础上同样可以与 Service Mesh 进行整合，但是在服务治理层面会存在一定冲突，目前来看，最有效的解法是把支撑能力交给平台本身，将业务与支撑解耦，实现彻底的服务化。
应用容器化
上面已经提到过，在当下的落地实践中容器化是 Service Mesh 能够存在的必要条件（当然可以非容器化，但代价无疑是巨大的）。应用服务拆分后的容器化改造，目前有多种实现的方式。最直接的是利用 DevOps 工具链，构建应用服务容器镜像。当然针对不同平台或者语言也可以进行独立实现，例如 Maven 的 docker 插件，github 提供的 CI 流程，Jenkins 提供的 pipeline 等都能够很好的实现服务容器化操作，这里不展开讨论。需要指出的是，服务容器化的重点在于构建一套符合企业制度与风格的控制流程规范，这其中技术因素不是主导因素，需要结合企业自身情况决定。
应用Mesh整合
应用服务化和应用容器化能够解决应用向 PaaS 平台迁移的绝大多数场景。但是前两者仅仅解决了服务编排部署问题，并没有对服务上线后的管理支撑提供更多的功能，而 Service Mesh 恰恰定位于这一领域。那么应用如何与 Mesh 进行整合呢？可以分四步进行，如图所示：
第一步，Service Mesh 与 PaaS 基础设施整合。利用 PaaS 平台强大的编排部署能力，部署Service Mesh（具体项目例如Isito）的控制层面，各个组件在启动时会自动初始化 Mesh 所需的环境以及从 PaaS 平台中搜集需要的信息，必要的时候，可以把 Mesh 作为 PaaS 平台基础设施的一部分。
第二步，配置 PaaS 平台。使其具备Mesh中代理程序自动注入的功能（例如 Istio 自动注入Sidecar的配置），当然该步骤可以省略，后续由用户手动注入，目的在于拦截服务请求与转发流量。
第三步，利用 PaaS 平台直接部署业务应用。此时应用已经与Mesh绑定在一起共享整个网络栈资源，实现应用与 Service Mesh 的初步整合。
第四步，利用第二步中部署的 Service Mesh 控制层面入口，设置服务通信规则，从而控制服务之间的通信，最终完成应用与 Mesh 的整合。
Mesh管理控制
Service Mesh 管理控制是客户介入服务间通信的唯一入口。而 Service Mesh 基于“声明式”规则的控制将决定企业管理过程中更多的是规则的设定者，却不具备对规则的有效性进行实时校验的条件。因此需要结合其他外围组件对当前服务是否符合预期进行监测。例如对接 Prometheus，获取服务的运行数据（包括 tcp 连接数，请求成功数，请求链路时长等），并且基于 AlterManager 进行告警策略的管理；或者对接 ELK 日志平台，对服务调用的日志进行统一分析管理。当然还有其他系统，统一称为 Adapter。
总体而言，应用是数据的产生源头，Service Mesh 负责服务通信控制，服务数据收集以及服务数据上报，其他平台负责数据处理，三者通力合作，才能将 Service Mesh 切实和企业应用整合在一起，发挥它最大的功效。
Service Mesh部署形态从当下的技术实现考虑，需要紧紧依赖 PaaS 平台的底层实现，尤其是对容器化环境的依赖。无论是单集群还是夸集群的部署，官方文档都提供了详尽的部署方案，这里不过多说明，可以参考 Istio 的实现（https://preliminary.istio.io/zh/docs/concepts/multicluster-deployments/）。
Servie Mesh 的管理形态最好的方式是与 PaaS 整合在一起，在 PaaS 自身的能力之上，增加服务治理的各种功能，有助于帮助 PaaS 平台更好的整合资源。Service Mesh 同样是对于 PaaS 的补充，从而形成全套的 PaaS 解决方案：包括 DevOps 工具形态，PaaS 编排部署形态，以及 Mesh 的服务治理形态。这时就具备了对应用生命周期各个阶段的集中控制能力。
这个是大胆的预测了，无论从技术角度考虑，还是行业发展趋势，Service Mesh 在未来必然会成为服务治理的主要工具之一。它对于企业应用最大的优势是解耦应用业务，企业能够彻底从业务角度考虑问题。相比纯粹的微服务架构，又向前迈了一步，同时与容器编排部署平台的集成，最终有可能成为企业级应用编排部署和服务治理的标准形态。
