哈喽！大家好，我是【Bug 终结者】 ，【CSDNJava领域优质创作者】，阿里云受邀专家博主，51CTO人气博主 . <br/>一位上进心十足，拥有极强学习力的【Java领域博主】 <br/>【Bug 终结者】博客的领域是【面向后端技术】的学习，未来会持续更新更多的【后端技术】以及【学习心得】。 偶尔会分享些前端基础知识，会更新实战项目，面向企业级开发应用！ 如果有对【后端技术】、【前端领域】感兴趣的【小可爱】，欢迎关注【Bug 终结者】❤️❤️❤️ 感谢各位大可爱小可爱！ ❤️❤️❤️@[TOC]一、什么是Docker Compose？docker-compose是基于docker的开源项目，托管于github上，由python实现，调用 docker服务的API负责实现对docker容器集群的快速编排，即通过一个单独的yaml文件，来定义一组相关的容器来为一个项目服务。Docker Compose 是一个工具，命令行工具，这个工具可以通过yml文件定义多容器的docker应用，通过一条命令就可以根据yml文件的定义去创建或管理多个容器二、Docker Compose 能用来做什么？我们平时操作Docker，还是很原始的操作，手动操作Docker的步骤可分为找到一个系统镜像安装vm 或者一些基本的工具在vm中安装镜像执行镜像docker-compose 是一个用来把 docker 自动化的东西在我们的 Docker Compose 中，只需要写一个 docker-compose.yml 文件容器编排，然后通过命令去启动就可以达到自动化的操作。三、阿里云服务器安装Docker ComposeDocker Compose 是Docker官方的开源产品，需要自行安装，DockerFile让程序在任何地方执行下载sudo curl -L "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose # 这个可能快点 curl -L https://get.daocloud.io/docker/compose/releases/download/1.29.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose如果下载不下来，那么可以 去我上传的资源上去下载 下载下来之后，我们使用 Filezilla 去将我们下载下来的文件上传至服务器 /usr/local/bin 下下载成功~进行授权chmod +x /usr/local/bin/docker-compose进行测试docker-compose version测试通过，成功安装了我们的Docker Compose~四、初体验Docker Compose☁️安装官方网址这里在官方下载的话太慢了，而且官方使用的是 Flask框架，下载到本地后，可能会起不来，所以说，我们自己来写。创建一个python+Redis的应用，计数器的功能创建工程目录mkdir compose_test cd compose_test # 源码文件夹 mkdir src # 存放Docker执行文件 mkdir docker 创建app.py在 compose_test/src 下创建 app.py 具体内容如下from flask import Flask from redis import Redis app = Flask(__name__) redis = Redis(host='redis', port=6379) @app.route('/') def hello(): count = redis.incr('hits') return 'Hello World! I have been seen {} times.\n'.format(count) if __name__ == "__main__": app.run(host="0.0.0.0", debug=True)创建我们的 需求文件 requirements.txt在 compose_test/src 下创建 requirements.txt 文件，具体内容如下flask redis创建容器的Dockerfile文件在 compose_test 下创建 Dockerfile文件，具体内容如下FROM python:3.7 COPY src/ /opt/src WORKDIR /opt/src RUN pip install -r requirements.txt CMD ["python", "app.py"]Dockerfile介绍从远程仓库拉取python镜像复制src 目录到 /opt/src 目录将容器的工作目录设置为 /opt/src 默认目录安装 Python依赖的关系将容器默认命令设置为 python app.py定义 docker-compose 执行脚本在 compose_test/docker 下新建 docker-compose.yml，具体内容如下version: '3' services: web: build: ../ ports: - "5000:5000" volumes: - ../src:/opt/src redis: image: redis:3.0.7compose具体介绍定义了两个服务，一个是web，一个是redisweb容器：使用了当前 docker-compose.yml 文件所在目录的上级中的Dockerfile构建镜像将容器端口暴露映射至5000端口将容器卷目录挂载到容器外部 /opt/src 目录，持久化到本地磁盘redis容器：redis 服务镜像地址为下载 3.0.7版本⚡测试通过命令测试注意：该命令必须在 存在有docker-compose.yml 的目录下执行# 直接执行 docker-compose up # 后台方式执行 docker-compose up -d服务启动成功docker ps查看网络情况# 查看所有的网络情况 docker network ls #查看某一个网络的详细信息 docker network inspect id输入地址测试# 服务器直接测试 curl localhost:5000测试成功~关闭服务命令docker-compose down ctrl + c五、Yaml规则docker-compose.yml 是核心配置文件他的规则如下# 3层 version: '' # 版本 services: # 服务 服务1: web # 服务配置 images build # 可以通过 该命令指定我们的执行顺序，优先加载数据库 depends_on: mysql redis network ...... 服务2: redis ..... 服务3: mysql ..... # 其他配置 网络/卷 全局规则 volumes： networks： configs ⛵小结以上就是【Bug 终结者】对 【云原生】Docker 进阶 -- 阿里云服务器安装Docker Compose与初体验 的简单介绍，Docker Compose 工具，可以很好的解决我们的微服务部署问题，在小规模的微服务情况下，可采用我们的 Docker Compose！如果这篇【文章】有帮助到你，希望可以给【Bug 终结者】点个赞，创作不易，如果有对【后端技术】、【前端领域】感兴趣的小可爱，也欢迎关注❤️❤️❤️ 【Bug 终结者】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】！

一、Mock概述友情提示：本节为小白科普章节，大神可绕路直奔下一章节。1.1 何为mock？mock即模拟，可以理解为模拟数据。就接口mock而言，就是mock接口返回结果。根据不同层次的需求，也是存在不同的mock层级，可以参考下面的金字塔模型，越往上mock的级别越“高”，对于用户（测试）越“可见”。方法、类级别一般是开发会用到，例如单测开发。而接口和服务级别是测试进行服务联调测试甚至系统测试过程会用到的。1.2 为什么需要mock？这就有必要介绍一下微服务了，微服务架构下，每个服务只完成一块功能，这些服务共同合作来就可以完成某些更加复杂的操作。与单体的复杂系统不同，开发者需要开发和管理一系列相对简单的服务，而这些服务可能以一些复杂的方式交互。这些服务之间的相互协作可以通过异步方式如消息形式，也可以通过同步方式来完成协作的。而这些服务之间可以独立部署与发布。为了让大家更有体感，以散户交易股票的过程为例：（1）用户创建一个订单，用来出售其账户里某只股票的股份；（2）账户中的这部分持仓就会被预留下来，这样它就不可以被多次出售了；（3）提交订单到市场上是要花钱的——账户要缴纳一些费用；（4）系统需要将这个订单发送给对应的股票交易市场。可以看到，微服务有三大关键特性。（1）每个微服务只负责一个功能。这个功能可能是业务相关的功能，也可能是共用的技术功能，比如与第三方系统（如证券交易所）的集成。（2）每个微服务都拥有自己的数据存储，如果有的话。这能够降低服务之间的耦合度，因为其他服务只能通过这个服务提供的接口来访问它们自己所不拥有的数据。（3）微服务自己负责编排和协作（控制消息和操作的执行顺序来完成某些有用的功能），既不是由连接微服务的消息机制来完成的，也不是通过另外的软件功能来完成的。（4）每个微服务都是可以独立部署的。如果做不到这一点，那么到了部署阶段，微服务应用还是一个庞大的单体应用。（5）每个微服务都是可代替的。每个微服务只具备一项功能，所以这很自然地限制了服务的大小。同样，这也使得每个服务的职责或者角色更加易于理解。一般来讲，微服务可以根据业务形态划分服务，然后不同的开发负责对应服务的开发与维护。当然一个服务可能不止有一个上游服务调用，甚至存在多个上游调用，而且不同的上游服务存在不同的调用契约。服务之间的调用链路可以参考如下图：试想如果你是服务A的测试同学A，你的业务需要调用服务C来完成一项业务，即服务A根据服务C的返回结果决定业务的执行结果。那么我是服务B的测试B，也需要调用服务C来完成一项业务，但是我调用服务C和你调用服务C的接口传参不同，返回的结果也可能不同，此外我们依赖的服务C版本号也不同，但是当前环境可能只部署2.0版本，再碰上有时候开发环境不稳定，服务时还是坏，这样服务C就无法同时满足测试A、B同学进行项目测试，而且环境问题也会浪费很多联调时间，导致项目并行难上加难。而Mock也是为了解决上述问题的，具体来讲Mock解决以下问题：1.Mock解决环境不稳定的问题。因为Mock服务非常简单，没有业务逻辑，所以它足够稳定。比如说银行那边的接口挂了，全都接到Mock平台的话，所有的请求权会从Mock平台出，而不会跟银行的接口有什么关联。2.快速构造复杂数据。我们可以自定义一个返回结果，有了自定义的返回结果后，就可以构造非常复杂的数据，不需要银行或者其他第三方给我们准备数据，完全可以用我的数据在返回里面把它定义好，再继续做业务的一个验证。3.快速构造异常场景。对于一些异常的情况，比如网络延迟高，或者返回特殊异常的时候，也可以用Mock来构造。二、Mock功能畅想与其说畅想，不如说是YY，哈哈。1.多协议支持不同于单体架构，微服务场景下，RPC协议由于比较高效，所以应用比较多。HTTP(s)、RPC等2.多格式支持支持一些常见的Json，Xml，还有其他一些自定义格式都是支持。3.异常Mock服务间相互调用，为了保持上下游异常错误做到“通识”性，一般会做服务间的错误码映射，例如服务A调用服务B，则当B返回错误码B-01的时候，需要服务A对外返回错误码A-01，则映射关系A-01 x B-01就建立了。需要支持配置异常错误码。4.动态mock当我们需要写一些很复杂的逻辑时，例如：希望当参数没传的时候，返回一个error信息，我们可以在这里用Java的一个返回结果，然后在这里写具体的一个脚本。比如说city=杭州。5.规则配置可以理解为动态mock的一种实现方式，根据request的入参，通过一个规则 去决策是否返回mock，或者返回哪个mock。6.mock管理支持随着需要mock的服务越来越多，单个服务配置的mock结果越来越多，势必要更高效的管理mock，例如按组、按业务方式管理等7.mock开关这个不用多说，开关打开，即服务打开。8.黑白名单支持多个项目并行的时候，项目A可能需要联调真实链路，而项目B需要将下游服务Mock掉，此时mock服务就存在问题了，如果打开mock，则会影响到项目A，反正，影响项目B的进行。此时可通过黑白名单方式解决上述问题，将项目A的联调环境中的应用服务器IP加入黑名单中，这样项目A就不会走到mock链路了。

1.定义的介绍首先,我向大家介绍一下我们这次使用的KODBOX,Serverless,阿里云函数以及服务的相关概念.1.1 KODBOX的定义KODBOX是可道云推出的企业级私有云存储解决方案，旨在为中小企业提供安全可控、可靠易用的一站式在线文件存储管理与协同办公平台。1.2 Serverless的定义Serverless，又叫无服务器。Serverless 强调的是一种架构思想和服务模型，让开发者无需关心基础设施（服务器等），而是专注到应用程序业务逻辑上。Serverless 也是下一代计算引擎。Serverless 与 FaaS（函数即服务）通常被视为可以互换的术语，但这并不准确。Serverless 是一种抽象层次更高的架构模式，而“FaaS + BaaS”只是 Serverless 这种架构模式的一种实现。其中，FaaS 是一种特定类型的服务，例如 AWS Lambda，Google Cloud Functions，Azure Functions，阿里云函数计算和腾讯云云函数等等；而 BaaS（后端即服务）可以理解为其他类型的托管服务，例如数据库服务，对象存储服务和日志服务等等。1.3 阿里云函数的定义函数计算是事件驱动的全托管计算服务。使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算为您准备好计算资源，弹性地可靠地运行任务，并提供日志查询、性能监控和报警等功能。函数计算帮助您无需管理服务器（Serverless），仅专注于函数代码就能快速搭建应用。函数计算能够弹性地伸缩，您只需要按使用量付费。1.4 服务的定义服务是函数计算资源管理的单位。创建函数前必须先创建服务，同一个服务下的所有函数共享一些相同的设置，例如服务授权、日志配置。从业务场景出发，一个应用可以拆分为多个服务。从资源使用维度出发，一个服务可以由多个函数组成。例如一个数据处理服务，分为数据准备和数据处理两部分。数据准备函数资源需求小，可以选择小规格实例。数据处理函数资源需求大，可以选择大规格实例。2. 相关应用的优势其次,我向大家介绍一下相关应用的优势.2.1 KodBox文件传输方面，KodBox采用数据去重技术，支持相同文件急速上传、系统内多文件快速复制和移动，优化了大文件、多文件上传机制；在新的技术架构基础上，KodBox优化了数据传输、操作体验、权限管理、后台增强、审计日志、存储安全等多方面的功能特性。Kodbox更多针对企业级的应用需求，可支撑高并发、更多用户数、更高协作和安全要求。2.2 Serverless 具有的特质这里叫特质，而非特性，因为这些属于 Serverless 架构的固有元素，我们无法像处理其它可塑特性那样做出调整。而特质是天然存在的。免运维：不需要管理服务器主机或者服务器进程。弹性伸缩：根据负载进行自动规模伸缩与自动配置。伸缩范围零到无穷大。按需付费：根据使用情况决定实际成本。高可用：具备隐含的高可用性。3. 函数使用流程以及重要的环节说明最后,我向大家介绍一下阿里云函数的使用流程以及一些重要环节的说明.3.1 创建流程3.2 重要环节说明3.2.1 创建函数函数（Function）是调度与运行的基本单位，更是一段代码的处理逻辑。您需要根据函数计算提供的函数接口形式编写代码，并将代码以函数的形式部署到函数计算。函数计算中的服务对应于软件应用架构领域中的微服务。在函数计算平台构建应用时，首先根据需求将业务逻辑抽象为微服务，然后再实现为函数计算中的服务。一个服务下可以创建多个函数，每个函数可以设置不同的内存规格、环境变量等属性，并可以结合您的实际业务场景来决定是否开启Initializer功能服务是函数层次化的抽象，在系统抽象和实现灵活度上能够取得平衡。例如，实现一个微服务，需要调用阿里云语音合成服务，将文字转成语音，再把这段语音和一系列图片组合为视频。其中文字转语音函数是调用其他服务，可以设置很小的内存规格。而视频合成函数是计算密集型，需要更大的内存。因此您可以组合多个不同规格的函数实现微服务，优化成本。关于函数的创建、更新和删除等。3.2.2 触发函数函数计算支持直接触发函数或通过事件触发函数。可以根据需要选择合适的触发方式：使用函数计算控制台、Serverless Devs或SDK等方式直接触发函数的执行配置函数计算触发器，通过事件触发函数的执行。4. 具体的操作演示接下来我们就开始真正式操作了,我们首先进入控制台:控制台链接4.1 创建页面展示如果我们之前创建过相关的应用,那么我们的页面会显示之前的部署内容.4.2 创建流程然后我们点击创建应用进行高性能网盘的创建.我们在点击创建之后在部署状态哪里会看到部署状态,因为部署需要时间,所以我们需要安心等待.等待一分钟左右后我们会发现部署成功,然后会出来我们可以访问的域名.4.3 登录页面此时我们可以登录域名进行测试.以下是我们的网盘:以下是我们的桌面:5. 心得体会:对于开发者来说阿里云函数是非常实用和受欢迎的，只需要写代码逻辑，资源按需计算，非高并发，成本低，运维方便，非常契合做 数据接口 和 非复杂业务逻辑接口， 有 http驱动 和 事件驱动(定时/调用API/SDK) 两种编码函数，http接口只是在 事件驱动任务前 提供一个http访问入口，本质上还是事件驱动任务。自己搭建一个高性能网盘，才是开发者最极客、最具性价比的选择！阿里云举办很多的体验活动,既可以帮助我们实实在在掌握一些专业知识,又给到各种体验优惠来帮助开发者,可以说对于开发技术人员是很友好的.网盘的桌面体验跟windows系统差不多,如果可以大量投入使用,我相信用户量还是非常庞大的.市场前景很好.

自我介绍我是一名环境艺术专业的学生，目前是大学二年级由于想与朋友一起玩 我的世界(Minecraft)泰拉瑞亚（Terraria） 需要一台服务器来搭建游戏服务端,所以开始了解阿里云服务器并在这里部署服务端。无论是学习 Linux 还是部署微服务和数据库，拥有远程云服务器都容易得多。通过b站视频了解到了飞天加速计划·高校学生在家实践活动# 阿里云ECS使用攻略领取服务器在飞天加速计划·高校学生在家实践活动页面,按照流程领取免费服务器两周连接到服务器阿里云服务器要用到两个密码，一个是远程登录密码，一个是实例密码，就是我们平常登录服务器的root密码（以linux服务器为例）通过控制台连接服务器需要使用到这两个密码，如果不知道就重置就好了。这里我用的是MobaXterm连接服务器注意：修改实例密码需要重启服务器才可以生效。以部署 <<泰拉瑞亚>>(Terraria) 服务端为例一开始无法挂载后台，一关闭连接服务器也关了，所以就要安装screen输入`jsCentOSyum install screenDebian/Ubuntuapt install screen创建一个叫Hello的虚拟终端screen -S Hello这样在里面运行就可以在后台运行了 # 开通安全组 同样在实例最右侧点击【更多】【网络和安全组】【安全组配置】【配置规则】 入方向看到的就是目前服务器的安全组规则了，你可以在这里添加、修改、删除规则。 比如要开放7777端口，这块挺重要的，规则添加不对了可能就无法正常访问了。 # 收获总结，展望未来

作者：尹航作为业内首个全托管 Istio 兼容的阿里云服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景，详情可点击原文链接查看。前言服务网格是一个通过“Sidecar”模式进行服务治理简化的平台。整个服务网格可以划分为包括核心组件 Istiod 的“控制面”以及包括了每个服务的 Sidecar 的“数据面”。如果各位使用过服务网格，相信对上面的概念也算是略有了解了。在服务网格 Istio 中，我们知道每个 Sidecar 都是一个 envoy 应用，内部有着包含着 listener、route、cluster、secret 等部分的完整配置；envoy 就是根据这些配置来改变自身行为，实现不同的流量控制手段的。而控制面组件的主要任务，就是将网格中的 VirtualService、DestinationRule 等资源“翻译”成 envoy 的具体配置，并将配置发送给数据面的每个 envoy，我们简称这个过程为“配置推送”。在 envoy 中，cluster 配置对应着 envoy 内部的“集群”这个概念，一个 cluster 是指“Envoy 连接的一组逻辑相同的上游主机”，其实大多数时候也就是对应着一个具体的服务。如果我们实际查看 envoy 的完整配置会发现，我们在什么都没做的时候，envoy 内部就已经包含着一些动态下发的 cluster 了，也就是说，Sidecar 自动发现并包含了集群中的服务信息。这里就引出一个核心问题：服务网格的“服务发现”是如何完成的呢？我们通常会用“网格内服务”来称呼对应 Pod 注入了 Sidecar 的服务；那么，是不是说服务网格会将注入了 Sidecar 的“网格内服务”自动的加入每个 Sidecar 的 cluster 配置呢？今天这篇文章就来主要聊一聊服务网格的“服务发现”和“配置推送”。服务网格的“服务发现”一个简单的小实验就可以解答上面的这些问题。我们在 Kubernetes 集群中安装服务网格平台（可以使用 aliyun ASM + ACK 来快速搭建服务网格平台），然后在 default 默认命名空间之外，再建立一个 test 命名空间。然后，我们为 default 命名空间开启 Sidecar 自动注入，也就是说，default 命名空间内的服务将自动成为“网格内”的服务，而 test 命名空间内的服务将不会注入 Sidecar，也就是“网格外”的服务。在服务网格 ASM 中，我们可以在控制台的“全局命名空间”管理中来方便地开启和关闭自动注入（开启/关闭后别忘了同步一下自动注入哦）：我们可以随意在这两个命名空间内部署一些中意的服务，我在这里向 default 命名空间部署了一个 sleep 服务。这个服务就如字面意思，里面是一个 curl 容器，并且一进去就一直在睡大觉 (￣o￣).zZ ，可以进入这个服务的 Pod 方便地 curl 其它服务。在 Istio 的社区官方 github 仓库中，可以找到 sleep 这个示例服务的 YAML 文件：istio/samples/sleep/sleep.yaml，我们可以拷贝这个文件后执行：kubectl apply -f sleep.yaml同理，在 test 命名空间下，我们随便部署点啥服务，我这里部署了一个 Istio 使用者的老朋友 bookinfo，我们同样可以在 Istio 的官方 github 中找到它的 YAML 文件：istio/samples/bookinfo/platform/kube/bookinfo.yaml，将其拷贝后执行：kubectl apply -f bookinfo.yaml -n test顺带一提，为了不让 sleep 太寂寞，我还在 default 命名空间部署了一个 httpbin 应用陪他，不过不部署也无所谓┐(ﾟ～ﾟ)┌。我们现在准备好了，大家可能猜到接下来要干啥了。我们就来看看——这个 Sidecar 里都有哪些 cluster 配置。如果你使用 Istio，可以用 istioctl 命令行工具方便地查看 Sidecar 中的各项配置的总结信息；在服务网格 ASM 中这招可能行不通，不过 ASM 也有一个能够部分兼容的命令行工具 asmctl，我们可以进入阿里云帮助中心，搜索 asmctl，找到“安装和使用诊断工具 asmctl”，按照文档提示下载安装此工具。以 asmctl 为例，可以用这个姿势来查看 Sidecar 内部的 cluster 配置（需要提前配置好数据面集群的 Kubeconfig）：$ asmctl proxy-config cluster sleep-557747455f-g4lcs SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE 80 - inbound ORIGINAL_DST BlackHoleCluster - - - STATIC InboundPassthroughClusterIpv4 - - - ORIGINAL_DST InboundPassthroughClusterIpv6 - - - ORIGINAL_DST PassthroughCluster - - - ORIGINAL_DST agent - - - STATIC asm-validation.istio-system.svc.cluster.local 443 - outbound EDS controlplane-metrics-aggregator.kube-system.svc.cluster.local 443 - outbound ORIGINAL_DST details.test.svc.cluster.local 9080 - outbound EDS envoy_accesslog_service - - - STRICT_DNS heapster.kube-system.svc.cluster.local 80 - outbound EDS httpbin.default.svc.cluster.local 8000 - outbound EDS istio-ingressgateway.istio-system.svc.cluster.local 80 - outbound EDS istio-ingressgateway.istio-system.svc.cluster.local 443 - outbound EDS istio-sidecar-injector.istio-system.svc.cluster.local 443 - outbound EDS istio-sidecar-injector.istio-system.svc.cluster.local 15014 - outbound EDS istiod.istio-system.svc.cluster.local 15012 - outbound ORIGINAL_DST kiali.istio-system.svc.cluster.local 20001 - outbound EDS kube-dns.kube-system.svc.cluster.local 53 - outbound EDS kube-dns.kube-system.svc.cluster.local 9153 - outbound EDS kubernetes.default.svc.cluster.local 443 - outbound EDS metrics-server.kube-system.svc.cluster.local 443 - outbound EDS productpage.test.svc.cluster.local 9080 - outbound EDS prometheus_stats - - - STATIC ratings.test.svc.cluster.local 9080 - outbound EDS reviews.test.svc.cluster.local 9080 - outbound EDS sds-grpc - - - STATIC sleep.default.svc.cluster.local 80 - outbound EDS storage-crd-validate-service.kube-system.svc.cluster.local 443 - outbound EDS storage-monitor-service.kube-system.svc.cluster.local 11280 - outbound EDS xds-grpc - - - STATIC zipkin这里就有一个有意思的事情了，虽然整套 bookinfo 应用都没有注入 Sidecar，但我们还是能在 sleep 的 Sidecar 中找到 productpage、reviews、ratings 等 bookinfo 应用的服务信息。这一切是怎么完成的呢？实际上 Istio 官方在社区文章《Traffic Management》中，有对这一过程进行解释：In order to direct traffic within your mesh, Istio needs to know where all your endpoints are, and which services they belong to. To populate its own service registry, Istio connects to a service discovery system. For example, if you’ve installed Istio on a Kubernetes cluster, then Istio automatically detects the services and endpoints in that cluster.简要地说，服务网格 Istio 并不进行服务发现。所有的服务都经由服务网格底层平台的服务发现（Kubernetes、Consul 等，大多数情况下都是 Kubernetes），通过控制面适配后传入网格自己的服务注册中心（也就是 Sidecar 的那一堆 cluster 配置了）。此外，如果你查看 Sidecar 中记录的 endpoint，你会发现无论是否注入 Sidecar，Kubernetes 集群内所有 Pod 的 ip 地址都会记录在内。尝试在 test 命名空间内部署下面这么个 VirtualService：apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: namespace: test name: test-vs spec: hosts: - productpage.test.svc.cluster.local http: - match: - uri: prefix: /test/ rewrite: uri: / route: - destination: host: productpage.test.svc.cluster.local port: number: 9080这个 VirtualService 实现了一个 uri 的重写，但目标 host 是一个“网格外”的服务 productpage。尝试一下，curl 一个会被重写的路径/test/productpagekubectl exec -it sleep-557747455f-g4lcs -c sleep -- curl productpage.test:9080/test/productpage会发现重写生效了，请求正常有返回。上述行为可以说明，所谓“网格内外”只是以是否注入 Sidecar 确定的一个区分手段，并不是说网格本身和网格外的服务有着严格的隔离边界。在上面的例子中，VirtualService 实际上生效于请求发送方 Sidecar 的 route 配置之中，而 productpage 服务即使没有 Sidecar，也是会被服务网格控制面发现、并加入 cluster 配置之中的，有对应的 cluster。因此，网格当然可以设定针对此 cluster 的路由规则，只要请求发送方的 Pod 是注入 Sidecar 的，VirtualService 的功能就能正常工作。当然，实际使用中，服务网格的其它资源可能生效于入站流量配置之中，此时请求接收方也必须注入 Sidecar 才行。但 Sidecar 注入并不对网格的服务发现起到决定作用，这一点是可以肯定的 。服务网格的“配置推送”上面我们探索了服务网格的“服务发现”机制，可以说还是十分巧妙，这套机制既让服务网格免于再去实现一套冗余的服务发现机制，也方便网格本身与不同的底层平台进行对接。然而，仔细思考就会发现这其中存在的问题与隐藏的反直觉现实情况。就以上面测试中我们在 Kubernetes 集群中部署的应用为例。Sleep 应用与 bookinfo 应用是两个独立的应用，彼此之间其实没有太大关系（只不过想访问的话彼此还是访问的通而已）。在实际的生产环境中，相信很多用户都会有这样的实践：利用 Kubernetes 命名空间的隔离机制，在同一个集群中部署多个应用对外提供服务，每个应用包含几个微服务，而应用之间彼此的关系则比较独立。而其中又只有部分的应用需要使用服务网格的治理能力（多语言服务互通、蓝绿发布等），因此注入了 Sidecar。问题是，服务网格的控制面也不能假设用户服务之间的关系，因此还是需要一视同仁地 watch 集群内所有的服务与端点:-( 更难受的是，控制面还需要向及时向数据面的每一位 Sidecar 同步集群内最新的服务信息，这就导致了以下的“费力不讨好”局面：1、一开始大家相安无事，岁月静好2、Service2 扩容了！3、Istiod 下发新的配置4、尴尬的事情发生了，Service1 和 Service2 其实是两个独立的应用，网格内的 Sidecar 不需要记录 Service2 的任何信息。如果网格内的服务不多，这倒也不能造成什么巨大的问题，无非就是网格的控制面组件多做点无用功罢了。可是正所谓量变引起质变，无用功堆积起来就会成为不可忽视的大问题。如果您的集群中部署着成千上百个服务，而其中只有少量的服务加入了网格，网格的控制面就会淹没在大量的无效信息中，控制面组件的负载居高不下，并且不断向所有 Sidecar 推送他们并不需要的信息。由于控制面组件不比网关，只是负责向 Sidecar 推送配置，控制面的负载过高可能很难引起服务网格用户的注意。然而一旦负载过高导致 Pilot SLB 超限/控制面组件重启等状况，用户就会轻则面临新的路由配置推送过慢、重则面临注入 Sidecar 的 Pod 起不来的窘境。因此，在享受服务网格为我们带来的便利的流量治理能力的同时，适度地关心服务网格控制面的身心健康，对控制面进行配置推送的优化，也是非常有必要的。配置推送优化-之选择性服务发现针对上面所述的状况，我们可以手动地去配置服务网格，让网格的控制面只去“发现”特定命名空间内的服务，而对其它的命名空间置之不理。在社区中，Istio 于 1.10 版本后提供了“discovery selector”的能力。而服务网格 ASM 也对应提供了“选择性服务发现”的能力，二者的生效机制是完全相同的。我们以服务网格 ASM 的“选择性服务发现”为例。首先给网格内应用所在的命名空间打一个特定的标签，用来区分网格内与网格外应用所在的命名空间（注意是给数据面的命名空间打标签）：# 在这里，default命名空间开启了自动注入，属于“网格内”命名空间 kubectl label namespace default in-mesh=yes # 其实我们也可以直接用 istio-injection:enabled标签，不用再打一个进入我们的 ASM 实例管理页面，在左侧菜单中选择“配置推送优化 -> 选择性服务发现”。在“选择性服务发现”页面中，选择“添加标签选择器” -> “添加标签精确匹配规则”，输入我们刚才打好的标签。然后点击“确定”就好了，真是非常地方便。这之后网格会经过一个短暂的更新阶段，更新我们刚才写下的这个配置，然后重新进入“运行中”状态。再来运行一遍我们最开始的指令，查看一下 sleep 服务的 Sidecar 中的 cluster 配置：$ asmctl proxy-config cluster sleep-557747455f-g4lcs SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE 80 - inbound ORIGINAL_DST BlackHoleCluster - - - STATIC InboundPassthroughClusterIpv4 - - - ORIGINAL_DST InboundPassthroughClusterIpv6 - - - ORIGINAL_DST PassthroughCluster - - - ORIGINAL_DST agent - - - STATIC envoy_accesslog_service - - - STRICT_DNS httpbin.default.svc.cluster.local 8000 - outbound EDS kubernetes.default.svc.cluster.local 443 - outbound EDS prometheus_stats - - - STATIC sds-grpc - - - STATIC sleep.default.svc.cluster.local 80 - outbound EDS xds-grpc - - - STATIC zipkin - - - STRICT_DNS可以看到 sleep 服务的 Sidecar 中已经没有任何一个 bookinfo 应用中服务的信息了，现在 Sidecar 中的配置看起来精简多了。可喜可贺可喜可贺\(^o^)/当然，我们做的不只是减少 Sidecar 中的配置数量而已。如上文所说，使用“选择性服务发现后”，控制面将不会 watch 除 default 命名空间外的任何服务，也因此控制面的工作负担得到了大幅削减，服务网格重回高效运转状态~我们也可以没有后顾之忧地向集群中部署其它服务了。总结服务网格的服务发现机制其实说起来是一个十分简单的东西，毕竟服务网格根本就没有服务发现机制呢！不过不去实际了解的话，想必很少有人能够直接确定每个 Sidecar 里记录的那些林林总总的服务到底是如何发现的。同时，Istiod 作为服务网格中负责配置推送的核心组件，做的却是修改翻译和修改配置这样的后台工作，也导致网格的用户通常很难意识到控制面组件到底在进行什么工作，以及现有的实践是否给控制面组件造成了过大的多余负担。希望这篇文章能让更多的服务网格用户意识到，配置推送的优化也是网格平台维护的重要一环。使用“选择性服务发现”的话，仅用1分钟的时间就能够大幅度优化网格的配置优化，减少使用网格时无谓的隐患，岂不美哉？对于大多数用户来说，“选择性服务发现”就已经足够对配置推送进行优化了。不过如果您想做的更“绝”，还可以直接使用服务网格的 Sidecar 资源来对 Sidecar 的配置进行最大限度地优化。服务网格 ASM 针对 Sidecar 资源这一机制，也提供了基于访问日志分析自动推荐的 Sidecar 资源来帮助客户进行使用上的深度简化。欢迎使用服务网格 ASM，即刻让您拥有简化的无侵入式服务治理能力！从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景。

概述随着开发周期的推移，项目会不断变大，切分出的服务也会越来越多，这时一个个的微服务构成了错综复杂的系统。对于各个微服务系统的健康状态、会话数量、并发数、服务资源、延迟等度量信息的收集就成为了一个挑战。Spring Boot Admin 应运而生，它正式基于这些需求开发出的一套功能强大的监控管理系统。Spring Boot Admin 有两个角色组成，一个是 Spring Boot Admin Server，一个是 Spring Boot Admin Client，接下来就是实现 Spring Boot Admin 的搭建。创建 Spring Boot Admin Server创建一个工程名为 hello-spring-cloud-admin 的项目，pom.xml文件如下：<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.ycq</groupId> <artifactId>hello-spring-cloud-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../hello-spring-cloud-dependencies/pom.xml</relativePath> </parent> <artifactId>hello-spring-cloud-admin</artifactId> <packaging>jar</packaging> <name>hello-spring-cloud-admin</name> <dependencies> <!-- Spring Boot Begin --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.jolokia</groupId> <artifactId>jolokia-core</artifactId> </dependency> <dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-starter-server</artifactId> </dependency> <!-- Spring Boot End --> <!-- Spring Cloud Begin --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <!-- Spring Cloud End --> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.ycq.hello.spring.cloud.admin.AdminApplication</mainClass> </configuration> </plugin> </plugins> </build> </project>主要增加了 2 个依赖，org.jolokia:jolokia-core、de.codecentric:spring-boot-admin-starter-server<dependency> <groupId>org.jolokia</groupId> <artifactId>jolokia-core</artifactId> </dependency> <dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-starter-server</artifactId> </dependency>其中 spring-boot-admin-starter-server的版本号为：2.0.0，这里没写版本号是因为我已将版本号托管到 dependencies 项目中Application通过 @EnableAdminServer 注解开启 Admin 功能package com.ycq.hello.spring.cloud.admin; import de.codecentric.boot.admin.server.config.EnableAdminServer; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; @SpringBootApplication @EnableEurekaClient @EnableAdminServer public class AdminApplication { public static void main(String[] args) { SpringApplication.run(AdminApplication.class, args); } }application.yml设置端口号为：8084spring: application: name: hello-spring-cloud-admin zipkin: base-url: http://localhost:9411 server: port: 8084 management: endpoint: health: show-details: always endpoints: web: exposure: # 注意：此处在视频里是 include: ["health", "info"] 但已无效了，请修改 include: health,info eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/主要增加了 Spring Boot Admin Server 的相关配置management: endpoint: health: show-details: always endpoints: web: exposure: # 注意：此处在视频里是 include: ["health", "info"] 但已无效了，请修改 include: health,info测试访问监控中心打开浏览器访问：http://localhost:8084 会出现以下界面

ZipKin 简介ZipKin 是一个开放源代码的分布式跟踪系统，由 Twitter 公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。它的理论模型来自于 Google Dapper 论文。每个服务向 ZipKin 报告计时数据，ZipKin 会根据调用关系通过 ZipKin UI 生成依赖关系图，显示了多少跟踪请求通过每个服务，该系统让开发者可通过一个 Web 前端轻松的收集和分析数据，例如用户每次请求服务的处理时间等，可方便的监测系统中存在的瓶颈。服务追踪说明微服务架构是通过业务来划分服务的，使用 REST 调用。对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：术语解释Span：基本工作单元，例如，在一个新建的 Span 中发送一个 RPC 等同于发送一个回应请求给 RPC，Span 通过一个 64 位 ID 唯一标识，Trace 以另一个 64 位 ID 表示。Trace：一系列 Spans 组成的一个树状结构，例如，如果你正在运行一个分布式大数据工程，你可能需要创建一个 Trace。Annotation：用来及时记录一个事件的存在，一些核心 Annotations 用来定义一个请求的开始和结束cs：Client Sent，客户端发起一个请求，这个 Annotation 描述了这个 Span 的开始sr：Server Received，服务端获得请求并装备开始处理它，如果将其 sr 减去 sc 时间戳便可得到网络延迟ss：Server Sent 表明请求处理的完成(当请求返回客户端)，如果 ss 减去 sr 时间戳便可得到服务端需要的处理请求时间cr：Client Received 表明 Span 的结束，客户端成功接收到服务端的回复，如果 cr 减去 cs 时间戳便可得到客户端从服务端获取回复的所有所需时间将 Span 和 Trace 在一个系统中使用 ZipKin 注解的过程图形化：创建 ZipKin 服务端创建一个工程名为 hello-spring-cloud-zipkin 的项目，pom.xml 文件如下：<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.ycq</groupId> <artifactId>hello-spring-cloud-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../hello-spring-cloud-dependencies/pom.xml</relativePath> </parent> <artifactId>hello-spring-cloud-zipkin</artifactId> <packaging>jar</packaging> <name>hello-spring-cloud-zipkin</name> <dependencies> <!-- Spring Boot Begin --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <!-- Spring Boot End --> <!-- Spring Cloud Begin --> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin</artifactId> </dependency> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-server</artifactId> </dependency> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-autoconfigure-ui</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <!-- Spring Cloud End --> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.ycq.hello.spring.cloud.zipkin.ZipKinApplication</mainClass> </configuration> </plugin> </plugins> </build> </project>主要增加了 3 个依赖，io.zipkin.java:zipkin、io.zipkin.java:zipkin-server、io.zipkin.java:zipkin-autoconfigure-ui<dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin</artifactId> </dependency> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-server</artifactId> </dependency> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-autoconfigure-ui</artifactId> </dependency>注意版本号为：2.10.1，这里没写版本号是因为我已将版本号托管到 dependencies 项目中Application通过 @EnableZipkinServer 注解开启 Zipkin Server 功能package com.ycq.hello.spring.cloud.zipkin; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; import zipkin.server.internal.EnableZipkinServer; @SpringBootApplication @EnableEurekaClient @EnableZipkinServer public class ZipKinApplication { public static void main(String[] args) { SpringApplication.run(ZipKinApplication.class, args); } }application.yml设置端口号为：9411，该端口号为 Zipkin Server 的默认端口号spring: application: name: hello-spring-cloud-zipkin server: port: 9411 eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ management: metrics: web: server: auto-time-requests: false追踪服务在 所有需要被追踪的项目（就当前教程而言，除了 dependencies 项目外都需要被追踪，包括 Eureka Server）中增加 spring-cloud-starter-zipkin 依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>这些项目的 application.yml 配置文件中增加 Zipkin Server 的地址即可spring: zipkin: base-url: http://localhost:9411测试追踪启动全部项目，打开浏览器访问：http://localhost:9411/ 会出现以下界面：刷新之前项目中的全部测试接口（刷多几次）点击 Find a trace，可以看到具体服务相互调用的数据点击 Dependencies，可以发现服务的依赖关系

企业运维训练营之云上网络原理与实践课程第二讲配套实验：访问4层&7层 CLB场景对比 视频地址：https://developer.aliyun.com/learning/course/991/detail/14976 一、实验简介： 在大量真实业务场景（如微服务）中，在CLB后端提供服务的ECS之间存在服务上的依赖关系（ECS既做客户端又做服务端），本实验以CLB后端的一个ECS来访问CLB的4层监听与7层监听的端口，以理解其转发规则的不同。 实验网址：https://developer.aliyun.com/adc/scenario/exp/e39b51556c34432faae378075ac99abb 二、实验步骤： 1. 创建资源。 a.   在体验实验室页面左侧，单击创建资源，创建所需资源。b.   在页面左侧导航栏中，单击云产品资源列表，查看本次实验资源相关信息。 说明：资源创建过程需要1~3分钟。完成实验资源的创建后，您可以在云产品资源列表查看已创建的资源信息，例如：IP地址、用户名和密码等。 2. 了解实验架构。 本实验架构为1台CLB，后端挂载了2台ECS，以CLB后端的一个ECS来访问CLB的4层监听与7层监听的端口。 3. 实验准备。 注：后台已创建好了对应的云产品资源，这里仅了解和核实环境和相关配置。 如下仅供学员了解和参考，不需要去手动创建（如了解，可跳过）： 创建ECS 参考文档：https://help.aliyun.com/document_detail/25422.html私网CLB实例创建 参考文档：https://help.aliyun.com/document_detail/86454.html  4. 手动安装nginx并设置自定义首页。 注：不同学员会有属于自己的ECS实例（后台自动创建），请以实际配置中实例的信息（id、IP等）为准。系统默认资源创建过程需要1~3分钟。完成实验资源的创建后，您可以在“云产品资源”列表查看已创建的资源信息，例如：IP地址、用户名和密码等。 本实验演示的ECS示例为杭州地域下的ECS，以其ECS IP为：192.168.11.180和192.168.11.181做样例演示。 在系统内手动安装nginx（yum install nginx）； yum install nginx 在/usr/share/nginx/html目录下使用本机的hostname替换原有的index.html文件，内容为ECS本机的hostname； cd /usr/share/nginx/html/hostname > index.html 最后启动nginx服务； service nginx start  5. 将ECS1、ECS2加入到CLB的默认服务器组 注：不同学员会有属于自己的CLB实例（后台自动创建），请以实际配置中实例的信息（id、IP等）为准。 本实验演示的杭州地域clb实例ID为lb-bp1srfo9275l6vlxq9mg2，IP地址为192.168.11.175。 将ECS1、ECS2加入到CLB的默认服务器组内。  6. 创建CLB实例的监听，80端口的TCP和8080端口的HTTP，并配置默认服务器组。 7. 在CLB监听的后端服务器ECS1上安装telnet，以便访问4层CLB的80端口，同时在ECS1内部抓包。 抓包时注意需要抓取any网卡：由于回包时目标IP为本机IP，在当前的系统路由表中，本机IP的路由会走loop网卡，如果只抓eth0，会出现回包无法抓到的情况。 访问时为什么会出现时通时不通的现象？  8. 在CLB监听的后端服务器上测试ECS1访问4层CLB的80端口，并在ECS1内部抓包。 抓包时注意需要抓取any网卡。 [root@ECS1 ~]# tcpdump -nni any port 80 and not net 100.64.0.0/1013:45:15.962843 IP 192.168.11.181.48092 > 192.168.11.175.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 013:45:15.964410 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 013:45:15.964429 IP 192.168.11.181.80 > 192.168.11.181.48092: Flags [S.], seq 1270453242, ack 3268167504, win 43690, options [mss 65495,sackOK,TS val 818984 ecr 818983,nop,wscale 7], length 013:45:15.964439 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [R], seq 3268167504, win 0, length 0 9. 在CLB监听的后端服务器上测试ECS1访问4层CLB的8080端口，并在ECS内部抓包。 访问时建议需要使用curl，因为：7层监听是http层面的动作，如果只用telnet来测试，三次握手建立好了之后，客户端和proxy集群（tengine集群）进行了连接，没有发起任何数据的时候，在CLB部分集群上不会向后端ECS建立连接发送数据的，所以必须用curl实际的发送一些7层的数据。 抓包时我们关注的信息有哪些？除了192开头的IP，我们还可以看到来自100网段的IP数据包，这些数据包正是7层监听交互的表现。 14:24:03.135859 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [S], seq 1995438430, win 29200, options [mss 1460,sackOK,TS val 3146156 ecr 0,nop,wscale 7], length 014:24:03.137054 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [S.], seq 2376897256, ack 1995438431, win 29200, options [mss 1440,nop,nop,sackOK,nop,wscale 9], length 014:24:03.137071 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 1, win 229, length 014:24:03.137179 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [P.], seq 1:84, ack 1, win 229, length 83: HTTP: GET / HTTP/1.114:24:03.138336 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [.], ack 84, win 58, length 014:24:03.139023 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [S], seq 1176088477, win 28480, options [mss 1424,sackOK,TS val 4003383056 ecr 0,nop,wscale 9], length 014:24:03.139038 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [S.], seq 2293269875, ack 1176088478, win 28960, options [mss 1460,sackOK,TS val 3146159 ecr 4003383056,nop,wscale 7], length 014:24:03.140054 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [.], ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 014:24:03.140073 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [P.], seq 1:162, ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 161: HTTP: GET / HTTP/1.114:24:03.140078 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 014:24:03.140254 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [FP.], seq 1:264, ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 263: HTTP: HTTP/1.1 200 OK14:24:03.141713 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [F.], seq 162, ack 265, win 58, options [nop,nop,TS val 4003383059 ecr 3146160], length 014:24:03.141732 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 163, win 235, options [nop,nop,TS val 3146161 ecr 4003383059], length 014:24:03.141742 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [P.], seq 1:247, ack 84, win 58, length 246: HTTP: HTTP/1.1 200 OK14:24:03.141754 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 247, win 237, length 014:24:03.141889 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [F.], seq 84, ack 247, win 237, length 014:24:03.143047 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [F.], seq 247, ack 85, win 58, length 014:24:03.143056 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 248, win 237, length 0 三、实验分析 1、实验结果 从以上的实验结果来看，ECS1访问CLB的80端口，会出现时通时不通的表现，而访问CLB的8080端口，则是100%连通。 2、实验分析  a.   由于四层CLB下， CLB会将客户端的原始链接转发到后端服务器上，因此在这种情况下，ECS1访问CLB内网地址的80端口时相当于访问自己的80端口，从抓包可看到源目IP都是自己，在回SYN_ACK时直接由lo网卡转发到本机，内核未看到SYN_ACK包对应五元组的SYN包，导致内核直接发送了RST。 b.   七层CLB下，由于CLB在中间隔离了TCP链接，因此ECS1看到的源IP均为CLB的内网IP，因此地址不会冲突。 

概述在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、熔断器、只能路由、配置管理等，由这几个基础组件相互协作，共同组件了一个简单的微服务系统。一个简单的微服务系统如下图：Zuul 简介Zuul 的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如 /api/user 转发到 User 服务，/api/shop 转发到 Shop 服务。Zuul 默认和 Ribbon 结合实现了负载均衡的功能。创建路由网关pom.xml 文件如下：<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.ycq</groupId> <artifactId>hello-spring-cloud-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../hello-spring-cloud-dependencies/pom.xml</relativePath> </parent> <artifactId>hello-spring-cloud-zuul</artifactId> <packaging>jar</packaging> <name>hello-spring-cloud-zuul</name> <dependencies> <!-- Spring Boot Begin --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <!-- Spring Boot End --> <!-- Spring Cloud Begin --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency> <!-- Spring Cloud End --> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.ycq.hello.spring.cloud.zuul.ZuulApplication</mainClass> </configuration> </plugin> </plugins> </build> </project>主要是增加了 Zuul 的依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency>Application增加 @EnableZuulProxy 注解开启 Zuul 功能package com.ycq.hello.spring.cloud.zuul; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; import org.springframework.cloud.netflix.zuul.EnableZuulProxy; @SpringBootApplication @EnableEurekaClient @EnableZuulProxy public class ZuulApplication { public static void main(String[] args) { SpringApplication.run(ZuulApplication.class, args); } }application.yml设置端口号为：8769增加了 Zuul 配置spring: application: name: hello-spring-cloud-zuul server: port: 8769 eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ zuul: routes: api-a: path: /api/a/** serviceId: hello-spring-cloud-web-admin-ribbon api-b: path: /api/b/** serviceId: hello-spring-cloud-web-admin-feign路由说明：以 /api/a 开头的请求都转发给 hello-spring-cloud-web-admin-ribbon 的服务以 /api/b 开头的请求都转发给 hello-spring-cloud-web-admin-feign 的服务测试访问一次运行 EurekaApplication、ServiceAdminApplication、WebAdminRibbonApplication、WebAdminFeignApplication、ZuulApplication打开浏览器访问：http://localhost:8769/api/a/hi?message=HelloZuul 浏览器显示You message is HelloZuul，You port is 8763打开浏览器访问：http://localhost:8769/api/b/hi?message=HelloZuul 浏览器显示You message is HelloZuul，You port is 8763至此说明 Zuul 的路由功能配置成功配置网关路由失败时的回调package com.ycq.hello.spring.cloud.zuul.provider; import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.cloud.netflix.zuul.filters.route.FallbackProvider; import org.springframework.http.HttpHeaders; import org.springframework.http.HttpStatus; import org.springframework.http.MediaType; import org.springframework.http.client.ClientHttpResponse; import org.springframework.stereotype.Component; import java.io.ByteArrayInputStream; import java.io.IOException; import java.io.InputStream; import java.util.HashMap; import java.util.Map; /** * 路由 hello-spring-cloud-web-admin-feign 失败时的回调 * Title: WebAdminFeignFallbackProvider * Description: * * @author yaoChuanQing * @date 2020-11-22 22:51 * @version 1.0.0 */ @Component public class WebAdminFeignFallbackProvider implements FallbackProvider { @Override public String getRoute() { // ServiceId，如果需要所有调用都支持回退，则 return "*" 或 return null return "hello-spring-cloud-web-admin-feign"; } @Override public ClientHttpResponse fallbackResponse(String route, Throwable cause) { return new ClientHttpResponse() { /** * 网关向 api 服务请求失败了，但是消费者客户端向网关发起的请求是成功的， * 不应该把 api 的 404,500 等问题抛给客户端 * 网关和 api 服务集群对于客户端来说是黑盒 * @return * @throws IOException */ @Override public HttpStatus getStatusCode() throws IOException { return HttpStatus.OK; } @Override public int getRawStatusCode() throws IOException { return HttpStatus.OK.value(); } @Override public String getStatusText() throws IOException { return HttpStatus.OK.getReasonPhrase(); } @Override public void close() { } @Override public InputStream getBody() throws IOException { ObjectMapper objectMapper = new ObjectMapper(); Map<String, Object> map = new HashMap<>(); map.put("status", 200); map.put("message", "无法连接，请检查您的网络"); return new ByteArrayInputStream(objectMapper.writeValueAsString(map).getBytes("UTF-8")); } @Override public HttpHeaders getHeaders() { HttpHeaders headers = new HttpHeaders(); // 和 getBody 中的内容编码一致 headers.setContentType(MediaType.APPLICATION_JSON_UTF8); return headers; } }; } }

概述在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以通过 RPC 相互调用，在 Spring Cloud 中可以用 RestTemplate + Ribbon 和 Feign 来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或自身的原因，服务并不能保证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 "雪崩" 效应。为了解决这个问题，业界提出了熔断器模型。Netflix 开源了 Hystrix 组件，实现了熔断器模式，Spring Cloud 对这一组件进行了整合。在微服务架构中，一个请求需要调用多个服务是非常常见的，如下如：较低层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystrix 是 5 秒 20 次）熔断器将会被打开。熔断器打开后，为了避免连锁故障，通过 fallback 方法可以直接返回一个固定值。Ribbon 中使用熔断器在 pom.xml 中增加依赖<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency>在 Application 中增加 @EnableHystrix 注解package com.ycq.hello.spring.cloud.web.admin.ribbon; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; import org.springframework.cloud.netflix.hystrix.EnableHystrix; @SpringBootApplication @EnableDiscoveryClient @EnableHystrix public class WebAdminRibbonApplication { public static void main(String[] args) { SpringApplication.run(WebAdminRibbonApplication.class, args); } }在 Service 中增加 @HystrixCommand 注解在 Ribbon 调用方法上增加 @HystrixCommand 注解并指定 fallbackMethod 熔断方法package com.ycq.hello.spring.cloud.web.admin.ribbon.service; import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate; @Service public class AdminService { @Autowired private RestTemplate restTemplate; @HystrixCommand(fallbackMethod = "hiError") public String sayHi(String message){ return restTemplate.getForObject("http://hello-spring-cloud-service-admin/hi?message=" + message, String.class); } public String hiError(String message){ return String.format("Your message is %s , but request bad", message); } }测试熔断器此时我们关闭服务提供者，再次请求 http://localhost:8764/hi?message=HelloRibbon 浏览器会显示：Your message is HelloRibbon , but request bad", messageFeign 中使用熔断器Feign 是自带熔断器的，但默认是关闭的。需要在配置文件中配置打开它，在配置文件增加以下代码：feign: hystrix: enabled: true在 Service 中增加 fallback 指定类package com.ycq.hello.spring.cloud.web.admin.feign.service; import com.ycq.hello.spring.cloud.web.admin.feign.service.hystrix.AdminServiceHystrix; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import org.springframework.web.bind.annotation.RequestParam; @FeignClient(value = "hello-spring-cloud-service-admin", fallback = AdminServiceHystrix.class) public interface AdminService { @RequestMapping(value = "hi", method = RequestMethod.GET) public String sayHi(@RequestParam(value = "message") String message); }创建熔断器并实现对应的 Feign 接口package com.ycq.hello.spring.cloud.web.admin.feign.service.hystrix; import com.ycq.hello.spring.cloud.web.admin.feign.service.AdminService; import org.springframework.stereotype.Component; @Component public class AdminServiceHystrix implements AdminService { @Override public String sayHi(String message) { return String.format("Your message is %s , but request is bad", message); } }测试熔断器此时我们关闭服务提供者，再次请求 http://localhost:8765/hi?message=HelloFeign 浏览器会显示：Your message is HelloFeign , but request is bad