共计 6831 个字符，预计需要花费 18 分钟才能阅读完成。
简介：上云素来都不是一片坦途，在此过程中咱们总会遇到一些艰难和挑战，得益于云原生技术的日益成熟，这些问题肯定会有相应的解法。
作者：纳海
背景
在云原生时代，国内外泛滥云厂商开释出弱小的技术红利，如何利用便宜、稳固且高效的云设施是当今的一个次要命题。在云上，咱们能够很不便地创立虚构网络、虚拟机、数据库、音讯队列等基础设施和中间件，也能够应用容器服务、EDAS、SAE、函数计算等 PaaS 和 Serverless 服务来加重利用管控的压力。
但事件并不是一帆风顺的。利用上云已是历史大潮不可阻挡，但随之而来开发者很快就领会到上云的另一面：由云上和云下网络不通所带来的开发体验割裂感。在上云之前，开发者能够在本地实现代码开发、测试、联调等开发流程闭环；而上云之后，数据库、缓存、音讯队列和其余微服务利用都部署在云上的虚构网络之中，咱们再无奈在本地实现开发流程。
如果是中东土豪，他可能会思考应用物理专线来买通网络。因为他只需领取光纤铺设费、楼内光缆租赁费、端口占用费、流量费等百万量级的钱，同时压服平安团队来容许齐全买通环境而已。
如果是业余运维人员，他可能会思考搭建 VPN 来买通网络。当他破费精力搭建 VPN 服务器，发现共事们还是用不起来，纷纷埋怨：
•“一关上 VPN，整个本地零碎网络流量都转发到云端了，其余事件干不了啦！”
•“除了配置 VPN，还要配置利用运行参数，太麻烦了！”
•“云端服务怎么调用不了本地服务，云端网络路由增加了吗？”
• …
看到这些问题，运维小哥心田也感到心累 …
而当初，咱们提供了一个开箱即用的插件工具，无需你破费大量的金钱或者人力。你所须要的只是在 IDE 中一键开启开关，而后通过 IDE 所启动的利用就能拜访到云端环境里的数据库、MQ、缓存和其余微服务。所有的事件都由插件来帮你实现。
介绍
这款工具是咱们自主研发的“端云互联”插件，“端”指的是开发端，“云”指的是云上网络，通过某种形式实现“端”和“云”的双向互通，并且没有传统 VPN 的问题。
端云互联性能集成在 Alibaba Cloud Toolkit（简称 ACT）这个上云工具产品中，并反对 Intellij IDEA 和 Eclipse 两款 IDE。你只需在插件市场中搜寻“Alibaba Cloud Toolkit”进行装置即可，例如在 Intellij IDEA 中搜寻如下：
咱们在 2018 年就开始了端云互联我的项目的研发，这个过程中迭代了大大小小的版本，共经验了三个里程碑，至今有数十万人次的应用。上面来介绍它的个性反对和实现原理。
端云互联 1.0
1.0 阶段解决了本地和云端双向互联的问题，使得本地服务不仅仅可拜访云端资源，还能够跟云端服务相互通信。
双向互联
以下为端云互联的外围架构，整体分为两个模块：通道服务和代理机。
其中，模块性能如下：
• 代理机：负责云端的流量转发。端云互联计划对代理机的要求很低，一台一般规格的 ECS 就能够充当“乞丐版”的代理机。并且，Debian、Ubuntu、Redhat 等 Linux 零碎曾经蕴含端云互联所依赖的底层库，无需额定装置其他软件。
• 通道服务：负责本地的流量转发。当咱们关上端云互联开关并启动利用时，插件会在本地拉起一个通道服务过程。这个过程的职责非常简单，它只负责本地利用和云端代理机之间的流量转发，无其余操作。
通道服务和代理机之间是应用加密通道来通信的，中间人无奈窃取通道中的数据。而在微服务利用中，咱们联合 Java 原生的代理参数和自研的流量拦挡计划来将利用的流量转发至通道服务。
开发人员在 IDE 中启动利用时，端云互联插件会主动拉起通道服务，并注入相干参数至利用中。启动后，利用流量主动转发至通道服务，无需人工干预。
从架构上来看，端云互联跟 VPN 有点相似，都分为服务端和客户端。但实际上，两者有很大的差别，下图进行了比照总结：
其中，在“云端拜访本地”这一点上，尽管两者都反对，但具体原理并不相同。如果采取 VPN 计划，那么其余云端服务拜访本地服务时，须要手动配置网络路由，否则网络不可达。而端云互联通过革新微服务框架，可使得云端服务调用代理机，再通过代理机转发到本地利用中，无需设置网络路由。在易用性和安全性上，端云互联都优于 VPN。
端云互联 2.0
在 1.0 阶段，咱们实现了本地和云端的双向互通，这满足了最根本的开发需要。在理论业务中，客户提出了更高的要求。
咱们一个客户有宏大的研发团队，他们都应用端云互联进行开发，但在联调时发现一个问题：研发人员 A 发动的服务调用有时候调到别的节点去了，没有到所冀望的研发人员 B 的本地节点上。这个问题是因为微服务框架的路由机制引起的，当环境中一个服务存在多个节点时，会应用随机（或轮流）算法来进行调用。微服务模块越多，链路越长，这个问题就越重大。
在 2.0 中，咱们提供了多人精准联调能力，此能力可使得服务申请“指哪打哪”，可大幅提高服务联调效率。除此之外，咱们还提供基于代理的近程调试能力，不便本地对云端环境中的微服务节点进行调试，进步调试效率。
同时，通过横向产品反对，端云互联 2.0 可服务于云原生产品 EDAS、SAE 和 MSE 等开发者，受到宽泛好评。
多人精准联调
下图形容了多人联调的一个典型场景：
小王负责服务 A，小张负责服务 B，在一次需要迭代中他们实现了代码开发，正在进行联调。因为微服务框架应用随机（或轮流）策略进行调用，导致了两个问题：
• 测试同学小马正在环境中进行功能测试，测试申请调用到小王和小张的本地节点上来了，导致测试不合乎预期；
• 小王发动的测试申请调到其余节点去了，没到他和小张的节点上，联调效率很低；
通过多人精准联调能力，能够使得只有小王发动的申请调到他的本地节点和小张的本地节点，而测试小马的申请只在云端稳固环境中调用。
小王和小张须要做的事件比较简单，他们只须要在控制台开启全链路流控性能，创立一个用于测试的流控环境。流控环境可配置申请辨认规定，可通过 Cookie、Header、申请参数等维度来判断是否为测试申请，如果判断通过则将申请调用到该环境中的节点中去。
而后小王和小张在 IDE 中将本地节点增加到这个测试环境中去即可，如下所示：
这样配置实现后，那么只有合乎特色的申请才会调用到小王和小张的节点，下图中只有 Header 蕴含“测试”的申请才会到他们节点中：
近程调试
近程调试（Remote Debug）始终都是排查问题的重要伎俩，但在云原生环境里近程调试并不是一件简略的事件。这是因为在默认状况下云上的微服务节点通常不能被公网拜访，如果须要进行近程调试，咱们须要对指标节点凋谢公网拜访，并且设置安全策略以放通调试端口流量。
如果以后有 A，B，C 三个服务，每个服务有 3 个节点，那么咱们须要别离建设 3 个平安组，并绑定 9 个公网网卡到机器节点。如下所示：
这种形式存在以下问题：
• 节约老本：每个微服务节点都须要绑定公网网卡，老本跟测试节点数成正相干。
• 配置简单：在云上往往采取弹性伸缩的策略来保护机器节点，达到“用时即建，用完即放”的按需应用目标。而每当创立新的机器节点咱们都须要独自配置公网网卡和平安组，应用上较繁琐。
• 存在安全性隐患：如果微服务节点都对外裸露公网拜访，会存在较大的平安危险。
甚至在有些场景下，因为平安要求内网机器节点不容许挂载公网网卡。对于这些问题，端云互联反对基于代理的近程调试，如下所示：
调试申请通过通道服务来转发给代理机，再由代理机转发至指标调试节点。通道服务和代理机之间的通道是加密的。对于平安要求十分严格的场景，能够应用平安组（或白名单）策略来进一步提高代理机的平安水位。
在应用上，你只需配置 Alibaba Cloud Remote Debug，配置内容跟 IDE 自带的近程调试配置基本相同，但反对应用代理进行连贯，如下所示：
其中有如下配置项：
• Proxy：指定云端代理机。当运行时，插件会主动拉起通道服务连贯代理机，无需人工干预。
• Host：指定近程调试的指标机器节点 IP。图中为 172.16.0.1。
• Port：指定近程调试的指标机器调试端口。图中为 5005。
云原生产品反对
端云互联 2.0 反对了阿里云上微服务畛域三大产品，EDAS（企业级分布式应用服务）、SAE（Serverless 利用引擎）和 MSE（微服务引擎）。这三个产品都反对微服务治理能力，满足不同的企业需要，产品个性如下：
• 企业级分布式应用服务 EDAS（Enterprise Distributed Application Service）：是利用全生命周期治理和监控的一站式 PaaS 平台，反对部署于 Kubernetes/ECS，无侵入反对 Java/Go/Python/PHP/.NetCore 等多语言利用的公布运行和服务治理，Java 反对 Spring Cloud、Apache Dubbo 近五年所有版本，多语言利用一键开启 Service Mesh。
• Serverless 利用引擎（Serverless App Engine，简称 SAE）：实现了 Serverless 架构 + 微服务架构的完满交融，真正按需应用、按量计费，节俭闲置计算资源，同时免去 IaaS 运维，无效晋升开发运维效率。SAE 反对 Spring Cloud、Dubbo 等风行的微服务架构，反对控制台、Jenkins、云效、插件等部署形式。除了微服务利用外，您还能通过 Docker 镜像部署任何语言的利用。
• 微服务引擎 (Micro Service Engine，简称 MSE)：是一个面向业界支流开源微服务生态的一站式微服务平台，帮忙微服务用户更稳固、更便捷、更低成本的应用开源微服务技术构建微服务体系。提供注册核心、配置核心全托管(兼容 Nacos/ZooKeeper/Eureka)、网关(兼容 Zuul/Kong/Spring Cloud Gateway) 和无侵入的开源加强服务治理能力。
因而，无论你是 EDAS 用户、SAE 用户还是 MSE 用户，都能够应用端云互联能力来进步上云的开发效率。在插件上，这三个产品的配置步骤是基本相同的，除了产品本身的差异性以外。配置页如下所示：
在将来，咱们会反对阿里云上更多的云原生产品进行互联，同时也会服务于阿里云以外的云原生开发者，敬请期待。
端云互联 3.0
2.0 版本解决了 Java 利用跟云端互联互通的问题，很多细节也打磨的比较完善，但它不足对容器畛域和诊断能力的反对。这些能力咱们在 3.0 阶段进行了补齐。
如果你是 Kubernetes 用户，那么能够应用 3.0 插件的 Kubernetes 代理能力，无需额定配置云端代理机。
如果你是非 Java 语言用户，或者对利用运行环境有肯定要求，那么能够应用 3.0 插件的容器级互联能力，来在本地应用 Docker 运行利用。在 Docker 容器中，利用能够失常拜访云端服务和资源，流量主动通过代理来转发。
如果你对本地运行利用所产生的调用异样感到无从下手，那么能够应用 3.0 插件的本地链路诊断能力，咱们会对立收集本地利用的调用链路，调用异样高深莫测。
上面来具体介绍这些个性。
Kubernetes 代理
3.0 版本的 Kubernetes 代理能力可基于 Kubernetes 集群主动买通代理通道。
在面向 Kubernetes 的开发中，咱们能够通过 kubectl 命令和 kubeconfig 配置文件来跟 API Server 进行通信，并拜访集群中的容器。API Server 会对申请进行身份认证、鉴权和加密解决。如果凋谢 API Server 的公网拜访，那么咱们在本地通过 kubectl 执行交互式命令时，此时 API Server 将充当两头代理角色，如下所示：
基于此个性，端云互联 3.0 插件在利用启动时，调用 kubectl 长期创立一个代理容器。通过联合 API Server 和长期代理容器进行买通，本地利用可拜访云端服务和其余资源。整体链路如下所示：
代理容器占用 64MB ~ 128MB 的节点内存，并在本地利用进行时主动删除。
而在插件配置上也非常简单，你只需在插件中设置 kubeconfig 配置文件和抉择 Kubernetes 命名空间：
在启动本地利用时，插件应用该 kubeconfig 配置文件来调用 kubectl 创立长期容器，并进行通道买通和流量转发。在终止利用时，插件应用该 kubeconfig 配置文件来调用 kubectl 删除该长期容器。
容器级互联
容器级互联是指，本地会启动 Docker 容器，并在容器内运行你的微服务利用，微服务利用可跟云端环境进行互联。如果你存在如下场景，那么容器级互联是你的最佳抉择：
• 非 Java 语言利用；
• 利用运行时对操作系统存在特定要求；
在此模式下，微服务利用和通道服务都应用容器来运行，整体交互如下：
在实现层面上，容器级互联基于 iptables 来拦挡和转发流量到代理容器中的通道服务，通道服务再将数据通过云端代理转发至指标地址。在架构上，这种模式跟 Service Mesh 的 Sidecar 模式有点相似，利用容器把流量转发给通道服务容器（sidecar 容器）。不过端云互联的通道容器只是做数据的通明转发，而 Service Mesh 的 sidecar 可进行微服务发现和治理的能力，这一点有所不同。
在应用上，插件运行容器的 Alibaba Microservice Container 配置，交互如下所示：
如果你在利用容器中运行的是 Java 语言利用，插件还反对快捷的利用调试，无需额定设置具体参数。启动利用时，插件会通过环境变量注入 JDWP 调试参数，以关上调试端口。插件进一步联合 Intellij IDEA 的智能检测，可通过 Attach debugger 来一键调试容器中的 Java 利用，如下所示：
由图可见，插件会将容器中利用的日志输入打印在 IDE 窗口中，日志中的“Listening for transport dt_socket at address: 5005”示意容器中的 Java 利用已关上调试端口。点击 Attach debugger，IDE 将会连贯到容器中 Java 利用的调试端口，接下来便可进行代码调试，如下所示：
本地链路诊断
在开发过程中，你是否遇到过这个场景：上游服务接口返回了 500，你只晓得接口调用失败了，但具体起因并不通晓？找该模块研发人员来排查时，他过了半天回复一句“当初有点忙，待会我看看”？等他有空排查后，发现问题出在另一个模块，让你去找另一个同学来排查？…
诸如此类的场景在开发过程中不足为奇，往往一个小问题要花费大量精力和工夫来进行排查。这个场景是链路追踪技术的典型场景。当初，咱们把链路追踪也集成到端云互联能力上，使得本地调用链路也能上报到云端，当出现异常时问题高深莫测。
比方，以后环境中有交易中心、商品核心和库存核心三个服务，你正在和测试同学验证新版本个性。测试同学在页面测试下单流程时，发现下单失败，如下所示：
因为波及模块多，问题排查耗时十分长。端云互联 3.0 插件集成了 ARMS（利用实时监控服务）的 Java Agent，它通过代码无侵入的埋点机制来收集调用链路上的信息并上报到 ARMS 服务端进行对立收集和智能剖析。出现异常时，只需在云端依据 TraceId 来查问调用链路，问题了然于胸：
TraceId 是用于链路追踪底层的概念，从前端页面开始生成并透传至上游各节点。为方便使用，插件还提供了打印本地链路的开关，开启后将会输入本地应用服务调用链路的相干信息，如下所示：
链路输入中蕴含如下信息：
• TraceId：用于标记申请的整体处理过程。在散布式微服务调用场景下，TraceId 会从最前端的利用节点透传至上游链路各个节点，可依据此 TraceId 在 EDAS 控制台或 ARMS 控制台查问整体链路处理过程。
• Service：以后利用的申请解决入口，如 Spring Cloud 服务、Dubbo 服务、HSF 服务等。
• API：链路处理过程中的办法签名。
• Line：办法解决的具体行数。
• Cost：此办法及其上游解决的耗时，单位毫秒。
• Ext：扩大信息，蕴含申请解决状态码、数据库拜访 SQL、资源指标地址等信息。
• Console link：ARMS 管制台上收集的此链路信息，可点击此链接间接查看全链路信息。
点击 Console link 链接，可查看此申请的上下游解决链路，如下所示：
咱们还能够进一步查看每个服务内的解决详情：
看到这里，是不是感觉排查问题有更多思路了呢：）
写在最初
云原生浪潮浩浩荡荡不可阻挡，业务上云也是企业的必经之路。但上云素来都不是一片坦途，在此过程中咱们总会遇到一些艰难和挑战。得益于云原生技术的日益成熟，这些问题肯定会有相应的解法。
在开发态这一畛域，咱们是国内云厂商当中走在前沿的探索者。从 2018 年开始孵化端云互联 1.0 版本，到目前 2021 年的端云互联 3.0 版本，当中遇到了大大小小的问题和挑战，但最终都一一解决了。此能力为公共云和专有云的开发者带来了极大的便当，使其在本地就能够实现开发、测试和联调闭环。
在将来咱们会一直提供更好用、更弱小、更易用的云原生工具来
原文链接
本文为阿里云原创内容，未经容许不得转载。
