• 关于

    数据通信测试是什么

    的搜索结果

问题

ios上socket通信问题(已解决,并附上解决方式)

a123456678 2019-12-01 20:27:44 1101 浏览量 回答数 1

问题

100%移植阿里云移动测试技术,竟仅需1周?! ——移动测试专有云(1)

mqc 2019-12-01 21:11:15 1796 浏览量 回答数 0

回答

回 2楼dongshan8的帖子 您好, 其中B是阿里云的公网, A、C都是其他电信和移动的网络。(是公司的局域网) ------------------------- 回 3楼碧血微剑的帖子 udp是不保证到达的协议,只是一定的丢包率的问题。 但不会导致在几分钟内发到服务器某个udp端口的数据一个都收不到的情况。(是视频数据,所以一分钟内发生了几百个包,服务器一个包都没有收到),而且同一时间,A、B之间另一个udp端口之间的数据还能正常通信。 这个应该不是udp协议导致的。 ------------------------- 回 2楼dongshan8的帖子 上面例子中是通过wireshark,tcpdump抓包验证过,发送端已经发送数据,而接收端没有数据 ------------------------- 回 7楼dongshan8的帖子 您好, 阿里云服务器B的配置是 1核 1G, 2M带宽。 win 2003 server, 关掉了系统自动升级等等消耗系统内存的服务 这台服务器上没有跑其他服务和程序。 ------------------------- 回 9楼dongshan8的帖子 您好, 我这里是现在只测试了  我自己这个程序的其中一个udp端口有的时候会出现一定几率的udp通信失败, 暂时还没有用其他udp测试程序测试过。 因为在A、B、C等系统上都用wireshark、tcpdump同时抓包对比过抓包数据,所以初步排除了是自己程序的问题。(这个程序也使用了很多年,以前没有出现过这种问题。) ------------------------- 回 11楼dongshan8的帖子 您好, 不好意思,前几天出差刚刚回来。 我们是使用ip的,没有域名解析。 等会再出现这个现象后我用其他测试程序试试。 ------------------------- 回 12楼云语科技的帖子 是的, 我也怀疑是被运营商或者其他什么地方丢掉了, 就是不知道怎么规避这个问题?

jeremyxday 2019-12-02 01:47:29 0 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

问题

IOS 后台VOIP的问题

杨冬芳 2019-12-01 20:13:50 1152 浏览量 回答数 1

问题

自建私有云,跨域加密通信实测

gf6 2019-12-01 21:47:07 1509 浏览量 回答数 1

问题

netty多线程通信一次传输较大数据遇到的问题:报错

kun坤 2020-06-06 17:02:03 0 浏览量 回答数 1

问题

【精品问答】大数据计算技术1000问

问问小秘 2019-12-01 21:57:13 6895 浏览量 回答数 2

回答

localhost也叫local ,正确的解释是:本地服务器 127.0.0.1在windows等系统的正确解释是:本机地址(本机服务器) 1、127.0.0.1是回送地址,指本地机,一般用来测试使用。回送地址是本机回送地址(Loopback Address),即主机IP堆栈内部的IP地址,主要用于网络软件测试以及本地机进程间通信,无论什么程序,一旦使用回送地址发送数据,协议软件立即返回,不进行任何网络传输。2、localhost是本地DNS解析的127.0.0.1的域名,这个你打开本机的hosts文件就可以看到,一般位于c:\windows\system32\driver\etc下,一般在最后有这么一行: 127.0.0.1 localhost 3、本机IP则指你连到网络上的IP地址,可以是内网地址,当然也可能是公网IP,这个就是你实际利用TCP/IP协议与网上计算机通信时使用的IP了。 localhot(local)是不经网卡传输,它不受网络防火墙和网卡相关的的限制。 127.0.0.1 是通过网卡传输,依赖网卡,并受到网络防火墙和网卡相关的限制。 一般设置程序时本地服务用localhost是最好的,localhost不会解析成ip,也不会占用网卡、网络资源。 有时候用localhost可以,但用127.0.0.1就不可以的情况就是在于此。猜想localhost访问时,系统带的本机当前用户的权限去访问,而用ip的时候,等于本机是通过网络再去访问本机,可能涉及到网络用户的权限。

Joyven 2019-12-02 03:14:05 0 浏览量 回答数 0

问题

全栈测试:平衡单元测试和端到端测试

技术小菜鸟 2019-12-01 21:30:35 3268 浏览量 回答数 1

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 37578 浏览量 回答数 11

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

阿里云中间件是什么

搞么罗 2019-12-01 21:51:58 1418 浏览量 回答数 0

问题

【精品问答】前端开发必懂之JS技术二百问

茶什i 2019-12-01 22:05:04 146 浏览量 回答数 0

问题

【精品问答】dubbo常见技术问题集

游客pklijor6gytpx 2019-12-01 21:54:03 31 浏览量 回答数 1

问题

【精品问答】Java必备核心知识1000+(附源码)

问问小秘 2019-12-01 22:00:28 870 浏览量 回答数 1

问题

网站打开速度很慢是什么原因

edison_du 2019-12-01 22:06:08 8112 浏览量 回答数 2

问题

Java基础

游客pklijor6gytpx 2019-12-01 22:02:53 69 浏览量 回答数 1

回答

Layout Go工程项目的整体组织 首先我们看一下整个 Go 工程是怎么组织起来的。 很多同事都在用 GitLab 的,GitLab 的一个 group 里面可以创建很多 project。如果我们进行微服务化改造,以前很多巨石架构的应用可能就拆成了很多个独立的小应用。那么这么多小应用,你是要建 N 个 project 去维护,还是说按照部门或者组来组织这些项目呢?在 B 站的话,我们之前因为是 Monorepo,现在是按照部门去组织管理代码,就是说在单个 GitLab 的 project 里面是有多个 app 的,每一个 app 就表示一个独立的微服务,它可以独立去交付部署。所以说我们看到下面这张图里面,app 的目录里面是有好多个子目录的,比方说我们的评论服务,会员服务。跟 app 同级的目录有一个叫 pkg,可以存放业务有关的公共库。这是我们的一个组织方式。当然,还有一种方式,你可以按照 GitLab 的 project 去组织,但我觉得这样的话可能相对要创建的 project 会非常多。 如果你按部门组织的话,部门里面有很多 app,app 目录怎么去组织?我们实际上会给每一个 app 取一个全局唯一名称,可以理解为有点像 DNS 那个名称。我们对业务的命名也是一样的,我们基本上是三段式的命名,比如账号业务,它是一个账号业务、服务、子服务的三段命名。三段命名以后,在这个 app 目录里面,你也可以按照这三层来组织。比如我们刚刚说的账号目录,我可能就是 account 目录,然后 VIP,在 VIP 目录下可能会放各种各样的不同角色的微服务,比方说可能有一些是做 job,做定时任务或者流式处理的一些任务,有可能是做对外暴露的 API 的一些服务,这个就是我们关于整个大的 app 的组织的一种形式。 微服务中的 app 服务分类 微服务中单个 app 的服务里又分为几类不同的角色。我们基本上会把 app 分为 interface(BFF)、service、job(补充:还有一个 task,偏向定时执行,job 偏向流式) 和 admin。 Interface 是对外的业务网关服务,因为我们最终是面向终端用户的 API,面向 app,面向 PC 场景的,我们把这个叫成业务网关。因为我们不是统一的网关,我们可能是按照大的业务线去独立分拆的一些子网关,这个的话可以作为一个对外暴露的 HTTP 接口的一个目录去组织它的代码,当然也可能是 gRPC 的(参考 B 站对外的 gRPC Moss 分享)。 Service 这个角色主要是面向对内通信的微服务,它不直接对外。也就是说,业务网关的请求会转发或者是会 call 我们的内部的 service,它们之间的通讯可能是使用自己的 RPC,在 b 站我们主要是使用 gRPC。使用 gRPC 通讯以后,service 它因为不直接对外,service 之间可能也可以相互去 call。 Admin 区别于 service,很多应用除了有面向用户的一些接口,实际上还有面向企业内部的一些运营侧的需求,通常数据权限更高,从安全设计角度需要代码物理层面隔离,避免意外。 第四个是 ecode。我们当时也在内部争论了很久,我们的错误码定义到底是放在哪里?我们目前的做法是,一个应用里面,假设你有多种角色,它们可能会复用一些错误码。所以说我们会把我们的 ecode 给单独抽出来,在这一个应用里面是可以复用的。注意,它只在这一个应用里面复用,它不会去跨服跨目录应用,它是针对业务场景的一个业务错误码的组织。 App 目录组织 我们除了一个应用里面多种角色的这种情况,现在展开讲一下具体到一个 service 里面,它到底是怎么组织的。我们的 app 目录下大概会有 api、cmd、configs、 internal 目录,目录里一般还会放置 README、CHANGELOG、OWNERS。 API 是放置 api 定义以及对应的生成的 client 代码,包含基于 pb 定义(我们使用 PB 作为 DSL 描述 API) 生成的 swagger.json。 而 cmd,就是放 main 函数的。Configs 目录主要是放一些服务所需的配置文件,比方说说我们可能会使用 TOML 或者是使用 YAML 文件。 Internal 的话,它里面有四个子目录,分别是 model、dao、service 和 server。Model 的定位职责就是对我们底层存储的持久化层或者存储层的数据的映射,它是具体的 Go 的一个 struct。我们再看 dao,你实际就是要操作 MySQL 或者 Redis,最终返回的就是这些 model(存储映射)。Service 组织起来比较简单,就是我们通过 dao 里面的各个方法来完成一个完整的业务逻辑。我们还看到有个 server,因为我一个微服务有可能企业内部不一定所有 RPC 都统一,那我们处于过渡阶段,所以 server 里面会有两个小目录,一个是 HTTP 目录,暴露的是 HTTP 接口,还有一个是 gRPC 目录,我们会暴露 gRPC 的协议。所以在 server 里面,两个不同的启动的 server,就是说一个服务和启动两个端口,然后去暴露不同的协议,HTTP 接 RPC,它实际上会先 call 到 service,service 再 call 到 dao,dao 实际上会使用 model 的一些数据定义 struct。但这里面有一个非常重要的就是,因为这个结构体不能够直接返回给我们的 api 做外对外暴露来使用,为什么?因为可能从数据库里面取的敏感字段,当我们实际要返回到 api 的时候,可能要隐藏掉一些字段,在 Java 里面,会抽象的一个叫 DTO 的对象,它只是用来传输用的,同理,在我们 Go 里面,实际也会把这些 model 的一些结构体映射成 api 里面的结构体(基于 PB Message 生成代码后的 struct)。 Rob Pike 当时说过的一句话,a little copying is better than a little dependency,我们就遵循了这个理念。在我们这个目录结构里面,有 internal 目录,我们知道 Go 的目录只允许这个目录里面的人去 import 到它,跨目录的人实际是不能直接引用到它的。所以说,我们看到 service 有一个 model,那我的 job 代码,我做一些定时任务的代码或者是我的网关代码有可能会映射同一个 model,那是不是要把这个 model 放到上一级目录让大家共享?对于这个问题,其实我们当时内部也争论过很久。我们认为,每一个微服务应该只对自己的 model 负责,所以我们宁愿去做一小部分的代码 copy,也不会去为了几个服务之间要共享这一点点代码,去把这个 model 提到和 app 目录级别去共用,因为你一改全错,当然了,你如果是拷贝的话,就是每个地方都要去改,那我们觉得,依赖的问题可能会比拷贝代码相对来说还是要更复杂的。 这个是一个标准的 PB 文件,就是我们内部的一个 demo 的 service。最上面的 package 是 PB 的包名,demo.service.v1,这个包使用的是三段式命名,全局唯一的名称。那这个名称为什么不是用 ID?我见过有些公司对内部做的 CMDB 或者做服务树去管理企业内部微服务的时候,是用了一些名称加上 ID 来搞定唯一性,但是我们知道后面那一串 ID 数字是不容易被传播或者是不容易被记住的,这也是 DNS 出来的一个意义,所以我们用绝对唯一的一个名称来表示这个包的名字,在后面带上这一个 PB 文件的版本号 V1。 我们看第二段定义,它有个 Service Demo 代码,其实就表示了我们这个服务要启动的服务的一个名称,我们看到这个服务名称里面有很多个 RPC 的方法,表示最终这一个应用或者这个 service 要对外暴露这几个 RPC 的方法。这里面有个小细节,我们看一下 SayHello 这个方法,实际它有 option 的一个选项。通过这一个 PB 文件,你既可以描述出你要暴露的是 gRPC 协议,又暴露出 HTTP 的一个接口,这个好处是你只需要一个 PB 文件描述你暴露的所有 api。我们回想一下,我们刚刚目录里面有个 api 目录,实际这里面就是放这一个 PB 文件,描述这一个工程到底返回的接口是什么。不管是 gRPC 还是 HTTP 都是这一个文件。还有一个好处是什么?实际上我们可以在 PB 文件里面加上很多的注释。用 PB 文件的好处是你不需要额外地再去写文档,因为写文档和写服务的定义,它本质上是两个步骤,特别容易不一致,接口改了,文档不同步。我们如果基于这一个 PB 文件,它生成的 service 代码或者调用代码或者是文档都是唯一的。 依赖顺序与 api 维护 就像我刚刚讲到的,model 是一个存储层的结构体的一一映射,dao 处理一些数据读写包,比方说数据库缓存,server 的话就是启动了一些 gRPC 或者 HTTP Server,所以它整个依赖顺序如下:main 函数启动 server,server 会依赖 api 定义好的 PB 文件,定义好这些方法或者是服务名之后,实际上生成代码的时候,比方说 protocbuf 生成代码的时候,它会把抽象 interface 生成好。然后我们看一下 service,它实际上是弱依赖的 api,就是说我的 server 启动以后,要注册一个具体的业务代码的逻辑,映射方法,映射名字,实际上是弱依赖的 api 生成的 interface 的代码,你就可以很方便地启动你的 server,把你具体的 service 的业务逻辑给注入到这个 server,和方法进行一一绑定。最后,dao 和 service 实际上都会依赖这个 model。 因为我们在 PB 里面定义了一些 message,这些 message 生成的 Go 的 struct 和刚刚 model 的 struct 是两个不同的对象,所以说你要去手动 copy 它,把它最终返回。但是为了快捷,你不可能每次手动去写这些代码,因为它要做 mapping,所以我们又把 K8s 里类似 DeepCopy 的两个结构体相互拷贝的工具给抠出来了,方便我们内部 model 和 api 的 message 两个代码相互拷贝的时候,可以少写一些代码,减少一些工作量。 上面讲的就是我们关于工程的一些 layout 实践。简单回溯一下,大概分为几块,第一就是 app 是怎么组织的,app 里面有多种角色的服务是怎么组织的,第三就是一个 app 里面的目录是怎么组织的,最后我重点讲了一下 api 是怎么维护的。 Unittest 测试方法论 现在回顾一下单元测试。我们先看这张图,这张图是我从《Google 软件测试之道》这本书里面抠出来的,它想表达的意思就是最小型的测试不能给我们的最终项目的质量带来最大的信心,它比较容易带来一些优秀的代码质量,良好的异常处理等等。但是对于一个面向用户场景的服务,你只有做大型测试,比方做接口测试,在 App 上验收功能的这种测试,你应用交付的信心可能会更足。这个其实要表达的就是一个“721 原则”。我们就是 70% 写小型测试,可以理解为单元测试,因为它相对来说好写,针对方法级别。20% 是做一些中型测试,可能你要连调几个项目去完成你的 api。剩下 10% 是大型测试,因为它是最终面向用户场景的,你要去使用我们的 App,或者用一些测试 App 去测试它。这个就是测试的一些简单的方法论。 单元测试原则 我们怎么去对待 Go 里面的单元测试?在《Google 软件测试之道》这本书里面,它强调的是对于一个小型测试,一个单元测试,它要有几个特质。它不能依赖外部的一些环境,比如我们公司有测试环境,有持续集成环境,有功能测试环境,你不能依赖这些环境构建自己的单元测试,因为测试环境容易被破坏,它容易有数据的变更,数据容易不一致,你之前构建的案例重跑的话可能就会失败。 我觉得单元测试主要有四点要求。第一,快速,你不能说你跑个单元测试要几分钟。第二,要环境一致,也就是说你跑测试前和跑测试后,它的环境是一致的。第三,你写的所有单元测试的方法可以以任意顺序执行,不应该有先后的依赖,如果有依赖,也是在你测试的这个方法里面,自己去 setup 和 teardown,不应该有 Test Stub 函数存在顺序依赖。第四,基于第三点,你可以做并行的单元测试,假设我写了一百个单元测试,一个个跑肯定特别慢。 doker-compose 最近一段时间,我们演进到基于 docker-compose 实现跨平台跨语言环境的容器依赖管理方案,以解决运行 unittest 场景下的容器依赖问题。 首先,你要跑单元测试,你不应该用 VPN 连到公司的环境,好比我在星巴克点杯咖啡也可以写单元测试,也可以跑成功。基于这一点,Docker 实际上是非常好的解决方式。我们也有同学说,其他语言有一些 in-process 的 mock,是不是可以启动 MySQL 的 mock ,然后在 in-process 上跑?可以,但是有一个问题,你每一个语言都要写一个这样的 mock ,而且要写非常多种,因为我们中间件越来越多,MySQL,HBase,Kafka,什么都有,你很难覆盖所有的组件 Mock。这种 mock 或者 in-process 的实现不能完整地代表线上的情况,比方说,你可能 mock 了一个 MySQL,检测到 query 或者 insert ,没问题,但是你实际要跑一个 transaction,要验证一些功能就未必能做得非常完善了。所以基于这个原因,我们当时选择了 docker-compose,可以很好地解决这个问题。 我们对开发人员的要求就是,你本地需要装 Docker,我们开发人员大部分都是用 Mac,相对来说也比较简单,Windows 也能搞定,如果是 Linux 的话就更简单了。本地安装 Docker,本质上的理解就是无侵入式的环境初始化,因为你在容器里面,你拉起一个 MySQL,你自己来初始化数据。在这个容器被销毁以后,它的环境实际上就满足了我们刚刚提的环境一致的问题,因为它相当于被重置了,也可以很方便地快速重置环境,也可以随时随地运行,你不需要依赖任何外部服务,这个外部服务指的是像 MySQL 这种外部服务。当然,如果你的单元测试依赖另外一个 RPC 的 service 的话,PB 的定义会生成一个 interface,你可以把那个 interface 代码给 mock 掉,所以这个也是能做掉的。对于小型测试来说,你不依赖任何外部环境,你也能够快速完成。 另外,docker-compose 是声明式的 API,你可以声明你要用 MySQL,Redis,这个其实就是一个配置文件,非常简单。这个就是我们在单元测试上的一些实践。 我们现在看一下,service 目录里面多了一个 test 目录,我们会在这个里面放 docker-compose 的 YAML 文件来表示这次单元化测试需要初始化哪些资源,你要构建自己的一些测试的数据集。因为是这样的,你是写 dao 层的单元测试的话,可能就需要 database.sql 做一些数据的初始化,如果你是做 service 的单元测试的话,实际你可以把整个 dao 给 mock 掉,我觉得反而还相对简单,所以我们主要针对场景就是在 dao 里面偏持久层的,利用 docker-compose 来解决。 容器的拉起,容器的销毁,这些工作到底谁来做?是开发同学自己去拉起和销毁,还是说你能够把它做成一个 Library,让我们的同学写单元测试的时候比较方便?我倾向的是后者。所以在我们最终写单元测试的时候,你可以很方便地 setup 一个依赖文件,去 setup 你的容器的一些信息,或者把它销毁掉。所以说,你把环境准备好以后,最终可以跑测试代码也非常方便。当然我们也提供了一些命令函,就是 binary 的一些工具,它可以针对各个语言方便地拉起容器和销毁容器,然后再去执行代码,所以我们也提供了一些快捷的方式。 刚刚我也提到了,就是我们对于 service 也好,API 也好,因为依赖下层的 dao 或者依赖下层的 service,你都很方便 mock 掉,这个写单元测试相对简单,这个我不展开讲,你可以使用 GoMock 或者 GoMonkey 实现这个功能。 Toolchain 我们利用多个 docker-compose 来解决 dao 层的单元测试,那对于我刚刚提到的项目的一些规范,单元测试的一些模板,甚至是我写了一些 dao 的一些占位符,或者写了一些 service 代码的一些占位符,你有没有考虑过这种约束有没有人会去遵循?所以我这里要强调一点,工具一定要大于约束和文档,你写了约束,写了文档,那么你最终要通过工具把它落实。所以在我们内部会有一个类似 go tool 的脚手架,叫 Kratos Tool,把我们刚刚说的约定规范都通过这个工具一键初始化。 对于我们内部的工具集,我们大概会分为几块。第一块就是 API 的,就是你写一个 PB 文件,你可以基于这个 PB 文件生成 gRPC,HTTP 的框架代码,你也可以基于这个 PB 文件生成 swagger 的一些 JSON 文件或者是 Markdown 文件。当然了,我们还会生成一些 API,用于 debug 的 client 方便去调试,因为我们知道,gRPC 调试起来相对麻烦一些,你要去写代码。 还有一些工具是针对 project 的,一键生成整个应用的 layout,非常方便。我们还提了 model,就是方便 model 和 DTO,DTO 就是 API 里面定义的 message 的 struct 做 DeepCopy,这个也是一个工具。 对于 cache 的话,我们操作 memcache,操作 Redis 经常会要做什么逻辑?假如我们有一个 cache aside 场景,你读了一个 cache,cache miss 要回原 DB,你要把这个缓存回塞回去,甚至你可能这个回塞缓存想异步化,甚至是你要去读这个 DB 的时候要做归并回源(singleflight),我们把这些东西做成一些工具,让它整个回源到 DB 的逻辑更加简单,就是把这些场景描述出来,然后你通过工具可以一键生成这些代码,所以也是会比较方便。 我们再看最后一个,就是 test 的一些工具。我们会基于项目里面,比方说 dao 或者是 service 定义的 interface 去帮你写好 mock 的代码,我直接在里面填,只要填代码逻辑就行了,所以也会加速我们的生产。 上图是 Kratos 的一个 demo,基本就是支持了一些 command。这里就是一个 kratos new kratos-demo 的一个工程,-d YourPath 把它导到某一个路径去,--proto 顺便把 API 里面的 proto 代码也生成了,所以非常简单,一行就可以很快速启动一个 HTTP 或者 gRPC 服务。 我们知道,一个微服务的框架实际非常重,有很多初始化的方式等等,非常麻烦。所以说,你通过脚手架的方式就会非常方便,工具大于约定和文档这个这个理念就是这么来的。 Configuration 讲完工具以后,最后讲一下配置文件。我为什么单独提一下配置文件?实际它也是工程化的一部分。我们一个线上的业务服务包含三大块,第一,应用程序,第二,配置文件,第三,数据集。配置文件最容易导致线上出 bug,因为你改一行配置,整个行为可能跟 App 想要的行为完全不一样。而且我们的代码的开发交付需要经过哪些流程?需要 commit 代码,需要 review,需要单元测试,需要 CD,需要交付到线上,需要灰度,它的整个流程是非常长的。在一步步的环境里面,你的 bug 需要前置解决,越前置解决,成本越低。因为你的代码的开发流程是这么一个 pipeline,所以 bug 最终流到线上的概率很低,但是配置文件没有经过这么复杂的流程,可能大家发现线上有个问题,决定要改个线上配置,就去配置中心或者配置文件改,然后 push 上线,接着就问题了,这个其实很常见。 从 SRE 的角度来说,导致线上故障的主因就是来自配置变更,所以 SRE 很大的工作是控制变更管理,如果能把变更管理做好,实际上很多问题都不会出现。配置既然在整个应用里面这么重要,那在我们整个框架或者在 Go 的工程化实践里面,我们应该对配置文件做一些什么事情? 我觉得是几个。第一,我们的目标是什么?配置文件不应该太复杂,我见过很多框架,或者是业务的一些框架,它实际功能非常强大,但是它的配置文件超级多。我就发现有个习惯,只要有一个同事写错了这个配置,当我新起一个项目的时候,一定会有人把这个错误的配置拷贝到另外一个系统里面去。然后当发现这个应用出问题的时候,我们一般都会内部说一下,你看看其他同事有没有也配错的,实际这个配错概率非常高。因为你的配置选项越多,复杂性越高,它越容易出错。所以第一个要素就是说,尽量避免复杂的配置文件。配得越多,越容易出错。 第二,实际我们的配置方式也非常多,有些用 JSON,有些用 YAML,有些用 Properties,有些用 INI。那能不能收敛成通用的一种方式呢?无论它是用 Python 的脚本也好,或者是用 JSON 也好,你只要有一种唯一的约定,不需要太多样的配置方式,对我们的运维,对我们的 SRE 同时来说,他跨项目的变更成本会变低。 第三,一定要往简单化去努力。这句话其实包含了几个方面的含义。首先,我们很多配置它到底是必须的还是可选的,如果是可选,配置文件是不是就可以把它踢掉,甚至不要出现?我曾经有一次看到我们 Java 同事的配置 retry 有一个重试默认是零,内部重试是 80 次,直接把 Redis cluster 打故障了,为什么?其实这种事故很低级,所以简单化努力的另外一层含义是指,我们在框架层面,尤其是提供 SDK 或者是提供 framework 的这些同事尽量要做一些防御编程,让这种错配漏配也处于一个可控的范围,比方重试 80 次,你觉得哪个 SDK 会这么做?所以这个是我们要考虑的。但是还有一点要强调的是,我们对于业务开发的同事,我们的配置应该足够的简单,这个简单还包含,如果你的日志基本上都是写在这个目录,你就不要提供这个配置给他,反而不容易出错。但是对于我们内部的一些 infrastructure,它可能需要非常复杂的配置来优化,根据我的场景去做优化,所以它是两种场景,一种是业务场景,足够简单,一种是我要针对我的通用的 infrastructure 去做场景的优化,需要很复杂的配置,所以它是两种场景,所以我们要想清楚你的业务到底是哪一种形态。 还有一个问题就是我们配置文件一定要做好权限的变更和跟踪,因为我们知道上线出问题的时候,我们的第一想法不是查 bug,是先止损,止损先找最近有没有变更。如果发现有变更,一般是先回滚,回滚的时候,我们通常只回滚了应用程序,而忘记回滚了配置。每个公司可能内部的配置中心,或者是配置场景,或者跟我们的二进制的交付上线都不一样,那么这里的理念就是你的应用程序和配置文件一定是同一个版本,或者是某种意义上让他们产生一个版本的映射,比方说你的应用程序 1.0,你的配置文件 2.0,它们之间存在一个强绑定关系,我们在回滚的时候应该是一起回滚的。我们曾经也因为类似的一些不兼容的配置的变更,二进制程序上线,但配置文件忘记回滚,出现过事故,所以这个是要强调的。 另外,配置的变更也要经过 review,如果没问题,应该也是按照 App 发布一样,先灰度,再放量,再全量等等类似的一种方式去推,演进式的这种发布,我们也叫滚动发布,我觉得配置文件也是一样的思路。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 原文链接

有只黑白猫 2020-01-09 17:29:54 0 浏览量 回答数 0

回答

服务器和操作系统 1、主板的两个芯片分别是什么芯片,具备什么作用? 北桥:离CPU近,负责CPU、内存、显卡之间的通信。 南桥:离CPU远,负责I/O总线之间的通信。 2、什么是域和域控制器? 将网络中的计算机逻辑上组织到一起,进行集中管理,这种集中管理的环境称为域。 在域中,至少有一台域控制器,域控制器中保存着整个域的用户账号和安全数据,安装了活动目录的一台计算机为域控制器,域管理员可以控制每个域用户的行为。 3、现在有300台虚拟机在云上,你如何进行管理? 1)设定堡垒机,使用统一账号登录,便于安全与登录的考量。 2)使用ansiable、puppet进行系统的统一调度与配置的统一管理。 3)建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。 4、简述raid0 raid1 raid5 三种工作模式的工作原理及特点 磁盘冗余阵列(Redundant Arrays of Independent Disks,RAID),把硬盘整合成一个大磁盘,在大磁盘上再分区,存放数据、多块盘放在一起可以有冗余(备份)。 RAID整合方式有很多,常用的:0 1 5 10 RAID 0:可以是一块盘和N个盘组合 优点:读写快,是RAID中最好的 缺点:没有冗余,一块坏了数据就全没有了 RAID 1:只能2块盘,盘的大小可以不一样,以小的为准 10G+10G只有10G,另一个做备份。它有100%的冗余,缺点:浪费资源,成本高 RAID 5 :3块盘,容量计算10*(n-1),损失一块盘 特点:读写性能一般,读还好一点,写不好 总结: 冗余从好到坏:RAID1 RAID10 RAID 5 RAID0 性能从好到坏:RAID0 RAID10 RAID5 RAID1 成本从低到高:RAID0 RAID5 RAID1 RAID10 5、linux系统里,buffer和cache如何区分? buffer和cache都是内存中的一块区域,当CPU需要写数据到磁盘时,由于磁盘速度比较慢,所以CPU先把数据存进buffer,然后CPU去执行其他任务,buffer中的数据会定期写入磁盘;当CPU需要从磁盘读入数据时,由于磁盘速度比较慢,可以把即将用到的数据提前存入cache,CPU直接从Cache中拿数据要快的多。 6、主机监控如何实现? 数据中心可以用zabbix(也可以是nagios或其他)监控方案,zabbix图形界面丰富,也自带很多监控模板,特别是多个分区、多个网卡等自动发现并进行监控做得非常不错,不过需要在每台客户机(被监控端)安装zabbix agent。 如果在公有云上,可以使用云监控来监控主机的运行。 网络 7、主机与主机之间通讯的三要素有什么? IP地址、子网掩码、IP路由 8、TCP和UDP都可以实现客户端/服务端通信,这两个协议有何区别? TCP协议面向连接、可靠性高、适合传输大量数据;但是需要三次握手、数据补发等过程,耗时长、通信延迟大。 UDP协议面向非连接、可靠性低、适合传输少量数据;但是连接速度快、耗时短、延迟小。 9、简述TCP协议三次握手和四次分手以及数据传输过程 三次握手: (1)当主机A想同主机B建立连接,主机A会发送SYN给主机B,初始化序列号seq=x。主机A通过向主机B发送SYS报文段,实现从主机A到主机B的序列号同步,即确定seq中的x。 (2)主机B接收到报文后,同意与A建立连接,会发送SYN、ACK给主机A。初始化序列号seq=y,确认序号ack=x+1。主机B向主机A发送SYN报文的目的是实现从主机B到主机A的序列号同步,即确定seq中的y。 (3)主机A接收到主机B发送过来的报文后,会发送ACK给主机B,确认序号ack=y+1,建立连接完成,传输数据。 四次分手: (1)当主机A的应用程序通知TCP数据已经发送完毕时,TCP向主机B发送一个带有FIN附加标记的报文段,初始化序号seq=x。 (2)主机B收到这个FIN报文段,并不立即用FIN报文段回复主机A,而是想主机A发送一个确认序号ack=x+1,同时通知自己的应用程序,对方要求关闭连接(先发ack是防止主机A重复发送FIN报文)。 (3)主机B发送完ack确认报文后,主机B 的应用程序通知TCP我要关闭连接,TCP接到通知后会向主机A发送一个带有FIN附加标记的报文段,初始化序号seq=x,ack=x+1。 (4)主机A收到这个FIN报文段,向主机B发送一个ack确认报文,ack=y+1,表示连接彻底释放。 10、SNAT和DNAT的区别 SNAT:内部地址要访问公网上的服务时(如web访问),内部地址会主动发起连接,由路由器或者防火墙上的网关对内部地址做个地址转换,将内部地址的私有IP转换为公网的公有IP,网关的这个地址转换称为SNAT,主要用于内部共享IP访问外部。 DNAT:当内部需要提供对外服务时(如对外发布web网站),外部地址发起主动连接,由路由器或者防火墙上的网关接收这个连接,然后将连接转换到内部,此过程是由带有公网IP的网关替代内部服务来接收外部的连接,然后在内部做地址转换,此转换称为DNAT,主要用于内部服务对外发布。 数据库 11、叙述数据的强一致性和最终一致性 强一致性:在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求,也是最难实现的。关系型数据库更新操作就是这个案例。 最终一致性:和强一致性相对,在某一时刻用户或者进程查询到的数据可能都不同,但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。 12、MySQL的主从复制过程是同步的还是异步的? 主从复制的过程是异步的复制过程,主库完成写操作并计入binlog日志中,从库再通过请求主库的binlog日志写入relay中继日志中,最后再执行中继日志的sql语句。 **13、MySQL主从复制的优点 ** 如果主服务器出现问题,可以快速切换到从服务器提供的服务; 可以在从服务器上执行查询操作,降低主服务器的访问压力; 可以在从服务器上执行备份,以避免备份期间影响主服务器的服务。 14、redis有哪些数据类型? (一)String 最常规的set/get操作,value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象,比较方便的就是操作其中的某个字段。做单点登录的时候,就是用这种数据结构存储用户信息,以cookieId作为key,设置30分钟为缓存过期时间,能很好的模拟出类似session的效果。 (三)list 使用List的数据结构,可以做简单的消息队列的功能。另外还有一个就是,可以利用lrange命令,做基于redis的分页功能,性能极佳,用户体验好。 (四)set 因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重?因为我们的系统一般都是集群部署,使用JVM自带的Set,比较麻烦,难道为了一个做一个全局去重,再起一个公共服务,太麻烦了。 另外,就是利用交集、并集、差集等操作,可以计算共同喜好,全部的喜好,自己独有的喜好等功能。 (五)Zset Zset多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用,取TOP N操作。另外,sorted set可以用来做延时任务。最后一个应用就是可以做范围查找。 15、叙述分布式数据库及其使用场景? 分布式数据库应该是数据访问对应用透明,每个分片默认采用主备架构,提供灾备、恢复、监控、不停机扩容等整套解决方案,适用于TB或PB级的海量数据场景。 应用 16、Apache、Nginx、Lighttpd都有哪些特点? Apache特点:1)几乎可以运行在所有的计算机平台上;2)支持最新的http/1.1协议;3)简单而且强有力的基于文件的配置(httpd.conf);4)支持通用网关接口(cgi);5)支持虚拟主机;6)支持http认证,7)集成perl;8)集成的代理服务器;9)可以通过web浏览器监视服务器的状态,可以自定义日志;10)支持服务器端包含命令(ssi);11)支持安全socket层(ssl);12)具有用户绘画过程的跟踪能力;13)支持fastcgi;14)支持java servlets Nginx特点:nginx是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP代理服务器,处理静态文件,索引文件以及自动索引,无缓存的反向代理加速,简单的负载均衡和容错,具有很高的稳定性,支持热部署。 Lighttpd特点:是一个具有非常低的内存开销,CPU占用率低,效能好,以及丰富的模块,Lighttpd是众多opensource轻量级的webserver中较为优秀的一个,支持fastcgi,cgi,auth,输出压缩,url重写,alias等重要功能。 17、LVS、NGINX、HAPROXY的优缺点? LVS优点:具有很好的可伸缩性、可靠性、可管理性。抗负载能力强、对内存和CPU资源消耗比较低。工作在四层上,仅作分发,所以它几乎可以对所有的应用做负载均衡,且没有流量的产生,不会受到大流量的影响。 LVS缺点:软件不支持正则表达式处理,不能做动静分离,如果web应用比较庞大,LVS/DR+KEEPALIVED实施和管理比较复杂。相对而言,nginx和haproxy就简单得多。 nginx优点:工作在七层之上,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则规则比haproxy更为强大和灵活。对网络稳定性依赖非常小。理论上能PING就能进行负载均衡。配置和测试简单,可以承担高负载压力且稳定。nginx可以通过端口检测到服务器内部的故障。比如根据服务器处理网页返回的状态码、超时等。并且可以将返回错误的请求重新发送给另一个节点,同时nginx不仅仅是负载均衡器/反向代理软件。同时也是功能强大的web服务器,可以作为中层反向代理、静态网页和图片服务器使用。 nginx缺点:不支持URL检测,仅支持HTTP和EMAIL,对session的保持,cookie的引导能力相对欠缺。 Haproxy优点:支持虚拟主机、session的保持、cookie的引导;同时支持通过获取指定的url来检测后端服务器的状态。支持TCP协议的负载均衡;单纯从效率上讲比nginx更出色,且负载策略非常多。 aproxy缺点:扩展性能差;添加新功能很费劲,对不断扩展的新业务很难对付。 18、什么是中间件?什么是jdk? 中间件介绍: 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源 中间件位于客户机/ 服务器的操作系统之上,管理计算机资源和网络通讯 是连接两个独立应用程序或独立系统的软件。相连接的系统,即使它们具有不同的接口 但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递 通过中间件,应用程序可以工作于多平台或OS环境。 jdk:jdk是Java的开发工具包 它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境 19、日志收集、日志检索、日志展示的常用工具有哪些? ELK或EFK。 Logstash:数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储以供后续使用。 Kibana:可视化化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。 Elasticsearch:分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析,并能将这三者结合起来。Elasticsearch 基于 Lucene 开发,现在使用最广的开源搜索引擎之一,Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。 Filebeat:轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说:Filebeat就是新版的 Logstash-fowarder,逐渐取代其位置。 20、什么是蓝绿发布和灰度发布? 蓝绿:旧版本-新版本 灰度:新旧版本各占一定比例,比例可自定义 两种发布都通过devops流水线实现

剑曼红尘 2020-03-23 15:51:44 0 浏览量 回答数 0

回答

ECS磁盘 我想在ECS 跨服务器进行数据拷贝,有没有知道实现方法的? Linux系统服务器重启或初始化系统之后,再登录服务器执行df -h查看磁盘挂载,发现数据不见了。这是为什么?能不能找回来? 重启服务器后发现/alidata目录所有数据丢失。怎么才能找回来呢? ECS Linux扩容格式化磁盘提示magic number in super-block while trying to open /dev/xvdb1 ? Linux 实例初始化系统盘后,怎样才能重新挂载数据盘? 如何在ECS 利用快照创建磁盘实现无损扩容数据盘? ECS云服务器磁盘FAQ云服务器磁盘I/O速度是多少? Linux 购买了数据盘,但是系统中看不到怎么办? ECS系统盘和数据盘二次分区FAQ,系统盘能否再次划分出一个分区用作数据存储? ECS系统盘和数据盘二次分区FAQ,数据盘能否再次划分出一个分区用作数据存储? ECS系统盘和数据盘二次分区FAQ,划分了多个分区的磁盘,做快照时是针对该分区的,还是针对磁盘的? ECS系统盘和数据盘二次分区FAQ,磁盘二次分区有哪些注意事项? ECS系统盘和数据盘二次分区FAQ,数据盘进行二次分区后,此时回滚快照后,数据盘是几个分区? 什么是可用区? 怎么根据服务器应用需求选择可用区? 按量付费云盘和云盘有什么区别? 按量付费云盘和普通云盘的性能和数据安全性一样吗,磁盘性能会有提升吗? 可以使用用户快照创建按量付费云盘吗? 什么是挂载点? 一块按量付费云盘可以挂载到多个 ECS 实例上吗? 一台 ECS 实例能同时挂载多少块按量付费云盘吗? 按量付费云盘能够挂载到包年包月和按量付费 ECS 实例上吗? 为什么挂载按量付费云盘时找不到我想挂载的 ECS 实例? 购买按量付费云盘后,挂载到目标 ECS 实例的挂载点是否还需要执行磁盘挂载操作? 我已经操作过续费变配,在续费变配期内是否还能将普通云盘转为按量付费云盘? ECS快照 为什么我的按量付费云盘没有自动快照了? 重新初始化磁盘时,我的快照会丢失吗? 更换系统盘时,我的快照会丢失吗? 卸载按量付费云盘时,我的磁盘会丢数据吗? 我能够卸载系统盘吗? 什么是独立云磁盘? 什么是可用区? 独立云磁盘跟现在的磁盘有什么区别? 服务器应用与可用区选择的选择关系是怎么样的? 独立云磁盘怎么收费? 独立云磁盘能够挂载到包年包月实例上吗? 独立云磁盘和普通云磁盘的磁盘性能和数据安全性一样吗,磁盘性能会有提升吗? 我的包年包月实例上不需要的磁盘能不能卸载? 为什么我的独立云磁盘和我的实例一起释放了? 为什么独立云磁盘挂载时找不到我想挂载的实例? 为什么我在本实例列表中选择独立云磁盘挂载时找不到我想要挂载的磁盘? 我删除磁盘的时候,快照会被保留吗? 为什么我的独立云磁盘没有自动快照了? 为什么我不能购买独立云磁盘? 一台实例能挂载多少块独立云磁盘? 卸载独立云磁盘时,我的磁盘会丢数据吗? 我的系统盘能够卸载吗? 什么是设备名? 为什么我在控制台上找不到重置磁盘,更换操作系统,回滚快照的操作了? 重新初始化磁盘时,我的快照会丢失吗? 更换系统盘时,我的快照会丢失吗? 为什么我的数据盘不能选择临时磁盘 独立云磁盘服务器的应用场景有哪些? 可以使用用户快照创建独立云磁盘吗? 独立云磁盘购买后挂载到目标实例的挂载点后,是否还需要执行磁盘挂载操作? 本地SSD盘“本地”是指? 本地SSD盘适合的用户场景有哪些? SSD盘相对之前的普通云盘性能提升多少,是否可以提供具体参数? 本地SSD盘是否支持在原ECS上进行添加或者将原云磁盘更换成本地SSD盘? 本地SSD盘购买后是否支持升级? SSD 云盘具备怎样的 I/O 性能? SSD云盘的数据可靠性是怎样的? SSD 云盘适合的应用场景有哪些? SSD 云盘相对普通云盘性能提升多少?是否可以提供具体参数? I/O 优化是什么概念?能将存量的 ECS 实例升级为 I/O 优化的实例吗? 是否支持将原普通云盘更换成 SSD 云盘? 如何购买 SSD 云盘,I/O 优化的实例及 SSD 云盘的价格是多少? 为什么 I/O 优化的实例有时启动比较耗时? 有些自定义镜像不支持创建 I/O 优化的实例,我该如何操作? 购买SSD云盘后是否支持升级? 使用了 I/O 优化实例和 SSD 云盘之后,Linux 系统在分区挂载的时候报错。 为什么我用 fio 测试性能时,会导致实例宕机? 云盘参数和性能测试工具及方法有推荐的吗? 我想扩容系统盘,求详细步骤! 所有块存储都支持系统盘扩容吗?有地域限制吗? 包年包月和按量付费的ECS实例都支持系统盘扩容吗? 新购ECS时,系统盘开始单独收费?老用户存量的系统盘如何收费? 新购ECS时,系统盘开始单独收费?老用户存量的系统盘如何收费?系统盘扩容是否需要停机操作? 系统盘扩容上线后,系统盘的容量范围多少? 哪些镜像支持系统盘扩容? 云服务器续费变配后,不支持更换系统盘时指定系统盘容量? 系统盘扩容之后是否支持再缩容? 扩容系统盘应注意的问题? 回滚磁盘报错,进行快照回滚的时候,出现如下错误提示: 执行回滚磁盘需要停止实例,并确保当前磁盘没有创建中的快照和没有更换过操作系统。 这是什么原因? 普通云盘和SSD云盘添加挂载信息时有哪些要注意的事项? 申请公测资格 什么是共享块存储? 共享块存储适用于哪些行业和业务场景? 为什么需要共享块存储? 如何正确使用共享块存储? 我能跨地域挂载共享块存储吗? 共享块存储产品规格有哪些? 我想知道阿里云产品的售卖模式和公测范围! 公测购买入口是哪,求链接! 有没有谁分享下共享块存储性能测试命令? 数据盘挂载问题导致数据无法访问,我要怎么排查问题? 我要怎样才能在Linux和Windows主机之间挂载ntfs格式云盘? 为什么ECS实例里文件系统和快照空间大小不一致?在ECS实例内删除文件后再打快照,发现快照容量并没有变小。 ECS实例如何优化快照使用成本? 在ECS实例里什么是快照商业化? 在ECS实例里,快照商业化后过渡优惠期是什么时候? 在ECS实例里,快照商业化的用户范围包括有哪些? 在ECS实例里,如果我已经开通了 OSS,快照会自动存到我的 OSS Bucket 吗?是否需要重新再创建一个 Bucket 来存储快照? 已经购买了 OSS 预付费存储包,同时在使用快照和 OSS 服务,那么存储包会优先抵扣哪个产品? 快照商业化之后,我希望继续使用,需要购买哪个产品,云盘还是对象存储OSS资源包? 快照商业化的收费模式是怎样的? 快照费用的计算方法是怎样的? 快照收费后,不停止自动快照是否就开始收取费用? 快照要收费了,之前的快照要被删除吗? 如果不想付费,之前的快照能继续使用吗? 快照收费后,之前创建的手动快照和自动快照都会收费吗? 快照收费前停止快照策略,需手动删除历史快照吗?正式收费后会直接删除我的历史快照吗? 快照收费以后,账户欠费对快照有什么影响? 如果账号欠费,有关联关系(创建过磁盘或者镜像)的快照,在欠费15天之后是否会被删除? 快照服务和块存储服务的关系,在收费方面的关系是什么? 快照容量是如何计算的,是等于磁盘大小吗? ECS实例内删除文件会减少空间占用吗? 为什么快照容量大于文件系统内看到的数据量? 参考快照增量说明,如中间快照被删除,后面的快照能否使用? 如何开通快照服务? 快照和镜像的关系? 如何在保留关联实例和磁盘的情况下,删除快照跟镜像,快照、实例、镜像之间的关系? 快照和块存储、OSS对象存储是什么关系? 一块云盘能否设置多个快照策略? 快照 2.0 服务包括哪些内容? 快照有什么用途? 快照 2.0 服务支持的云盘类型? 快照数量有什么限制? 快照保留时长怎样? 打快照对块存储 I/O 性能有多少影响? 快照怎么收费? 老的自动快照策略什么时候不可用? 老的快照策略产生的快照什么时候删除? 自动快照功能细节有哪些? 用户的自定义快照和自动快照有冲突吗? 我能保留其中想要的自动快照而让系统不删除吗? 如果一个自动快照被引用(用户创建自定义镜像或者磁盘),会导致自动快照策略执行失败吗? 我如果什么都没有设置,自动快照会启动吗? 自动快照能够删除吗? 自动快照具体在什么时间创建能看到吗? 我如何区分哪些快照是自动快照和用户快照? 更换系统盘、云服务器 ECS 到期后或手动释放磁盘时,自动快照会不会释放? 未随磁盘释放和更换系统盘释放的自动快照会一直保留吗? 云服务器 ECS 到期后或手动释放磁盘时,手工快照会不会释放? 我能单独制定某几块磁盘执行或取消自动快照吗? 云服务器 ECS 有没有自动备份? 磁盘无快照是否能够回滚或数据恢复? 快照回滚能否单独回滚某个分区或部分数据? 系统盘快照回滚是否会影响数据盘? 更换系统后,快照能否回滚? 在回滚快照前,有哪些注意事项? 怎样使ECS回滚快照后同步数据? 如何通过API配置定时自定义快照? 超出预付费存储包的流量,会怎么收费? ECS镜像 Aliyun Linux 17.01 特性有哪些,有说明文档吗? 云市场镜像有哪些功能? 镜像能带来哪些便利? 目前镜像支持哪些服务器环境和应用场景? 镜像是否安全? 选择了镜像后能更换吗? 镜像安装使用过程中出问题了怎么办? Docker私有镜像库是什么? 自定义镜像如何查看数据盘? 自定义镜像,如何卸载和删除 disk table 里的数据? 如何确认已经卸载数据盘,并可以新建自定义镜像? ECS 实例释放后,自定义镜像是否还存在? ECS 实例释放后,快照是否还存在? 用于创建自定义镜像的云服务器 ECS 实例到期或释放数据后,创建的自定义镜像是否受影响?使用自定义镜像开通的云服务器 ECS 实例是否受影响? 使用自定义镜像创建的 ECS 实例是否可以更换操作系统?更换系统后原来的自定义镜像是否还可以使用? 更换系统盘时另选操作系统,是否可以使用自定义镜像? 已创建的自定义镜像,是否可以用于更换另一台云服务器 ECS 的系统盘数据? 是否可以升级自定义镜像开通的云服务器 ECS 的 CPU、内存、带宽、硬盘等? 是否可以跨地域使用自定义镜像? 包年包月云服务器 ECS 的自定义镜像,是否可以用于开通按量付费的云服务器 ECS? ECS Windows企业版和标准版区别 什么情况下需要复制镜像? 可以复制哪些镜像? 当前有哪些支持镜像复制功能的地域? 复制一个镜像大概需要多久? 复制镜像怎么收费的? 在复制镜像过程中,源镜像和目标镜像有什么限制? 怎么复制我的云账号的镜像资源到其他云账号的其他地域? 复制镜像有镜像容量限制吗? 如何购买镜像市场镜像? 按次购买的镜像的使用期限是多久? 镜像市场的镜像支持退款吗? 镜像市场商业化后,还有免费的镜像市场镜像吗? 在杭州买了一个镜像市场的镜像,能否在北京创建ECS实例或者更换系统盘? ECS实例使用镜像市场的镜像,升级和续费ECS实例,需要为镜像继续付费吗? ECS实例使用镜像市场的镜像,实例释放后,继续购买ECS实例还可以免费使用该镜像吗? 使用镜像市场镜像创建ECS实例,该实例创建一个自定义镜像,使用该自定义镜像创建ECS实例需要为该镜像付费吗? 来源于镜像市场的镜像复制到其他地域创建ECS实例,是否需要为该镜像付费? 如果把来源于镜像市场的自定义镜像共享给其他账号(B)创建ECS实例,账号B是否需要为该镜像付费? 如果使用镜像市场的镜像或者来源于镜像市场的镜像进行更换系统盘,需要付费吗? ECS实例正在使用镜像市场的镜像,进行重置系统盘需要收费吗? 怎么调用ECS API,使用镜像市场镜像或者来源镜像市场的自定义镜像或者共享镜像,创建ECS实例和更换系统盘? 如果没有购买镜像市场的镜像或者来源于镜像市场的镜像,在调用ECS API 使用该镜像创建ECS实例和更换系统盘,会报错吗? 我的ESS是自动创建机器的,并且量是不固定,设置最小值为10台,最大值为100台,那么使用镜像市场的镜像如何保证我的的需求实例能正常弹出来? 镜像市场的镜像是否支持批量购买? 如果之前使用的镜像市场的镜像,已不存在该商品(如:jxsc000010、jxsc000019),怎能保证已经设置的弹性伸缩组的机器的正常弹出? 1个product code能否支持不同region的镜像? 我买了100 product code同样值的镜像,是否可以支持在所有的地域可用? 为什么有的ECS云服务器无法选择Windows操作系统? 操作系统是否要收费? 我能否自己安装或者升级操作系统? 服务器的登录用户名密码是什么? 能否更换或升级操作系统? 操作系统是否有图形界面? 如何选择操作系统? 操作系统自带 FTP 上传吗? 每个用户最多可以获得多少个共享镜像? 每个镜像最多可以共享给多少个用户? 使用共享镜像是否占用我的镜像名额? 使用共享镜像创建实例的时候存不存在地域限制? 我曾把自己账号中的某个自定义镜像共享给其他账号,现在我可以删除这个镜像吗 我把某个自定义镜像(M)的共享账号(A)给删除了,会有什么影响? 使用共享镜像创建实例存在什么样的风险? 我把自定义镜像共享给其他账号,存在什么风险? 我能把别人共享给我的镜像再共享给他人吗? 我把镜像共享给他人,还能使用该镜像创建实例吗? ECS Windows服务器桌面分辨率过高导致VNC花屏处理方法通过 管理终端 进入服务器后,把 Windows 服务器桌面分辨率设置过高,确定后,WebVNC 出现花屏。 ECS创建自定义镜像创建服务器为何需要注释挂载项 勾选"IO优化实例"选项导致购买ECS实例时无法选择云市场镜像 如何为 Linux 服务器安装 GRUB 历史Linux镜像的问题修复方案 如何处理 CentOS DNS 解析超时? 什么是镜像市场的包年包月和按周付费镜像? 预付费镜像能与哪种 ECS 实例搭配使用? 怎么购买预付费镜像?可以单独购买吗? 预付费镜像怎么付费? 预付费镜像到期了就不能用了吗?怎么继续使用? 购买预付费镜像后,如果我不想再使用这个镜像,能要求退款吗? 退款时,费用怎么结算? 预付费镜像能转换为按量付费镜像吗? 预付费镜像与其它镜像之间能互换吗?更换后费用怎么计算? 在哪里查看并管理我购买的预付费镜像? 使用预付费镜像制作的自定义镜像会收费吗?预付费镜像过期对于自定义镜像有什么影响? ECS 实例操作系统选择说明 阿里云支持哪些 SUSE 版本? SUSE 操作系统提供哪些服务支持? ECS安全组 如何检查 TCP 80 端口是否正常工作? 什么是安全组? 为什么在购买 ECS 实例的时候选择安全组? 安全组配置错误会造成哪些影响? 专有网络实例设置安全组规则时为什么不能设置公网规则? 创建 ECS 实例时我还没创建安全组怎么办? 为什么无法访问 25 端口? 为什么我的安全组里自动添加了很多规则? 为什么有些安全组规则的优先级是 110? 为什么我在安全组里放行了 TCP 80 端口,还是无法访问 80 端口? ECS安全组被添加内网ip地址了,是怎么回事? 能说明下ECS安全组中规则的优先级执行匹配顺序吗? ECS实例安全组默认的公网规则被删除导致无法ping通,ECS 服务器无法ping通,排查防火墙、网卡IP配置无误,回滚系统后仍然无法ping通。 我刚购买了ECS实例,如何选择及配置安全组? 没有添加默认安全组访问规则-导致通过API创建的ECS实例断网,要怎么恢复? 使用ECS安全组工具撤销之前账号间互通的操作 ECS网络 带宽与上传、下载速度峰值的有什么关系? 弹性公网IP在哪里可以查看流量和带宽监控信息? 我用的是ECS Ubuntu系统,要怎么单独禁用和启动内外网卡? ECS 实例子网划分和掩码是什么? ECS 实例网络带宽是否独享? 带宽单线还是双线,电信还是网通? 5 Mbps 带宽怎么理解? 带宽的价格是多少? 不同地域的 ECS 实例之间的内网是通的吗? 为何新建的 ECS 实例就有 200 Kbps 左右入网流量? 我的 ECS 实例经常能在 Web 日志中看到大量的恶意 IP 访问我的网站,疑有刷流量和恶意访问的嫌疑,询问云盾是否有屏蔽 IP 的功能? 包月ECS新购时是否可以选择带宽按照使用流量计费? 包月ECS带宽按流量计费是如何计费的? 目前使用的固定带宽计费,是否可以转换为带宽按流量计费? 是否可以随时调整流量带宽峰值? 续费变更配置时(比如到期时间为2015年3月31日,续费一个月到4月30日),如果将包月ECS按固定带宽计费改成按流量付费计费,操作以后在未生效前(3月31日前),是否还可以升级带宽? 续费变更配置时候将包月ECS带宽按流量计费改成按固定带宽计费,为什么我的带宽服务停掉了? 如果账号没有足够余额,欠费怎么办?ECS实例也会停掉吗? 带宽流量欠费是否有短信通知? 当带宽按照流量计费欠费时,是否可以对实例进行升级 CPU、内存操作? 欠费充值后带宽是自动恢复的吗? 包月带宽转流量计费后,流量价格是多少? ECS 服务器出现了异地登录怎么办? 爱哪里可以查看云服务器 ECS 公网流量统计总和? 我的ECS 实例对外 DDoS 攻击导致被锁定了,要如何处理 ? 什么是云服务器 ECS 的入网带宽和出网带宽? ECS云服务器如何禁用公网IP? ECS 实例停止(关机)后按量付费带宽仍产生流量,ECS 实例在控制台上状态为已停止,但按量付费的带宽每小时仍会产生不小的费用,且此时 ECS 实例正在遭受攻击,云盾控制台中 DDoS 防护中 ECS 的状态为清洗中。 访问ECS服务器的网站提示“由于你访问的URL可能对网站造成安全威胁,您的访问被阻断”,这是什么原因? 服务器黑洞是什么?求科普! 如果想确认该服务器的IP信息和地理位置,要在哪里去查询? 我想知道客户端本地到ECS服务器是不是丢包,要怎么测试? 内网和公共 NTP 服务器是什么?它们两个有什么区别 我能 ping 通但端口不通,这是端口的问题吗? 如何通过防火墙策略限制对外扫描行为? 我想用手机移动端网络路由跟踪探测,可以吗? 云监控中的ECS带宽和ECS控制台中看到的带宽不一致是什么原因? 云服务器ECS三张网卡有什么区别? Ubuntu系统ECS使用“如何通过防火墙策略限制对外扫描行为”脚本之后出现无法远程、数据库连接不上。 什么业务场景需要在专有网络(VPC)类型ECS购买PublicIP? 怎么购买专有网络(VPC)类型分配 PublicIP 的 ECS? 专有网络(VPC)类型 ECS 的 PublicIP 和 EIP 的区别? 专有网络(VPC)类型ECS的 PublicIP 的可以升级带宽吗? 专有网络(VPC)类型ECS的 PublicIP 可以解绑吗? 如果购买网络(VPC)类型 ECS 的时候,没有分配公网 IP,该怎么才能分配一个公网 IP? 怎么查询专有网络(VPC)类型 ECS 的 PublicIP 的监控数据? 怎么查询专有网络(VPC)类型ECS的按流量付费的 PublicIP 的账单? 专有网络和经典网络的 PublicIP 异同? 专有网络(VPC)类型 ECS 购买 PublicIP 的付费方式? ECS API 如何通过 API / SDK 实现不同账号 ECS 实例的内网通信? ECS API绑定公网IP报错:The IP is already in use分析 ECS API修改实例带宽不能指定时间范围吗? 所在可用区不支持相应磁盘类型-导致ECS API创建实例报错 用ECS API创建实例的时候,返回如下错误信息: "Code": "InvalidDataDiskCategory.NotSupported" 如何创建有公网 IP 的 ECS 实例? 通过API或SDK查询安全组规则无法显示所有的规则,这是怎么回事? 如何通过OpenAPI创建ECS实例的流程状态描述? 数据传输服务DTS实时同步功能,我想只同步表结构,要怎么做? 如何获取控制台RequestId? 阿里云中国站部分地域实例什么时候降价? ECS Linux 实例怎么设置 Locale 变量? 克隆ECS服务器的方法 其它国家和地区是否都可以提供经典网络和专有网络的类型呢?网络类型是否可以变更呢? 各个地域的网络覆盖范围是什么呢? 其他相关问题 不同地域的实例,价格一样吗? 如果我使用其它国家和地区的实例搭建了一个网站,我的用户将通过域名访问网站,这个域名需要 ICP 备案吗? 为什么有些实例规格只能在中国大陆地域购买,而在其它国家和地区无法购买? 可否将中国大陆地域的实例迁移到其它国家和地区呢? 如何在其它国家和地区部署 ECS 实例? 我要买其它国家和地区的实例,需要单独申请一个国际站账号吗? ——更多ECS相关问题—— · ECS故障处理百问合集

问问小秘 2020-01-02 15:49:17 0 浏览量 回答数 0

回答

$("#Loading").before(txt); txt里大概就是图片的代码吧###### if (allstop == true) { $(window).scroll(function () {######你看不到他后台/ajax/casesList.ajax是如何实现的,这部分是服务器端,你通过网页看到的只是get请求,可以在调试的network部分看到请求方式。如果你想测试你可以尝试用命令行的curl去测试,但是你看不到服务器端的代码,因为他不是开源的###### 引用来自“剑心无痕”的评论 你看不到他后台/ajax/casesList.ajax是如何实现的,这部分是服务器端,你通过网页看到的只是get请求,可以在调试的network部分看到请求方式。如果你想测试你可以尝试用命令行的curl去测试,但是你看不到服务器端的代码,因为他不是开源的 我用f12观察了一下,其中XHR中默认是一个也没有,后来不断的加载,共有三个casesList.aspx 这种情况说明了什么呢? 还有一个问题,她似乎让显示的每一页只有24条记录,以后随着请求的加载,不断的输出后续的记录,如何使每一页保持24条记录呢,如何用sql来控制呢? ######还有忘记说了,后端源码是部署在服务器上,你是看不到的是安全的,前端的js,css,html都是开源的,是不安全的,所以操作数据库尽量不要用js######如果你想了解后段是如何实现的,可以稍微学习一些后段的知识,这里他是用asp.net写的后端,其实用js也可以写后端,不过目前主流的后端框架都是php,python,ruby,asp等的,我个人的理解,后段主要是做复杂的逻辑运算和数据库交互(数据库js也可以直接访问的),然后前后端之间的通信主要是两种,一种是这里的post,get等请求,一种是模板######$("#loading").before(txt);断点在这里的话,你可以看到txt就是有24个li标签的字符串,每次都会把txt添加到id是loading的前面,你看html里loading的前面其实就是li标签,所以实际上就是在现有li标签的末尾添加txt###### 引用来自“ziluopao”的评论 引用来自“剑心无痕”的评论 你看不到他后台/ajax/casesList.ajax是如何实现的,这部分是服务器端,你通过网页看到的只是get请求,可以在调试的network部分看到请求方式。如果你想测试你可以尝试用命令行的curl去测试,但是你看不到服务器端的代码,因为他不是开源的 我用f12观察了一下,其中XHR中默认是一个也没有,后来不断的加载,共有三个casesList.aspx 这种情况说明了什么呢? 还有一个问题,她似乎让显示的每一页只有24条记录,以后随着请求的加载,不断的输出后续的记录,如何使每一页保持24条记录呢,如何用sql来控制呢? 我又观察了一下f12,发现other选项中,有一个不断变化的动态页面,估计这个页面就是后端中的代码吧,当然它不是原码,但毕竟能看出变化来! 还有一个问题,下图中绿色箭头指的东西是不是代码中的,还是说f12强加上去便于解析呢? ######看上去有点像调用的baidu的api,具体的还得你自己去研究研究######手机上面看不到图片,电脑才看到你的图片,绿色箭头是请求的响应吧,headers里能看到请求的信息,估计是在某个地方调用的这个请求,具体可以在源码中搜索一下###### 我有点明白了,它是通过"pageIndex": pageIndex, "category_id": category_id和后端中的代码联系的,这两个参数在后端源码中肯定有######回复 @剑心无痕 : 是这样,我正好想请教你,他的代码怎么出现在百度商桥中了,这是玩的啥技术!?######是的,就是把这两个参数通过post传递到后端,然后获取后端返回的txt,还有刚才查了一下,貌似是百度商桥的api,有兴趣你可以自己查看一下###### 可不可以这样推理,他把代码写在百度商桥中是为了便于百度收录?我是这样想的,其实这种延迟加载技术不利于优化,似乎作者想通过百度商桥弥补一下,不知对不对,不过我真想不出这么做能弥补吗?###### 还有一个问题需要提出:后端如何一次输出五个格式为txt的li呢,只有这样ajax才能一下输出五个li来

爱吃鱼的程序员 2020-05-31 00:19:29 0 浏览量 回答数 0

问题

云服务器ECS三张网卡是什么

boxti 2019-12-01 21:51:06 1901 浏览量 回答数 0

回答

Beego https://beego.me/ Beego 框架提供了很多标准附加功能,例如全功能路由器和可用于执行 CRUD 操作的对象到数据库映射工具。Bee 是 Beego 爱好者的最爱,它是一个快速而强大的命令行工具,用于构建、更新、打包和部署应用程序。Bee 可以从模板生成源代码,并保持数据库的最新状态。 Buffalo https://gobuffalo.io/en Buffalo 团队需要能够将 Web 应用程序的所有部分组装在一起的东西,包括应用程序本身的一些设计。他们把能够安装在一起的很多部件叫作“生态系统”。如果你想要路由——很少有人不需要——Buffalo 就包含了 Gorilla/Mux。如果你需要模板,Buffalo 倾向于使用 Plush,而不是使用内置的 Go 语言模板机制。数据库连接模块集合 Pop 可以帮你将数据库信息转换为 Go 对象。你还可以找到连接数据库、处理 cookie 以及完成其他任务的标准方法。 Cobra https://github.com/spf13/cobra 有时候,你只需要一个命令行界面。Cobra 提供了 CLI 的所有标准功能,因此你不必浪费时间实现代码来查找 -h 或 -help 标志。如果你的微服务需要对具有大量标志和其他功能的命令行调用做出响应,那么可以考虑集成 Cobra。 Docker 你当然可以在办公室服务器小黑屋里的裸机上运行微服务,但越来越多的人将他们的代码捆绑在 Docker 容器中,并将容器发到云端。小型的包更容易处理大量不同的代码块,当你对微服务架构的愿景要求你创建很多小的独立代码块时,这将是一项有价值的服务。 值得一提的是,Docker 是用 Go 语言开发的,尽管在部署 Docker 容器时你可能永远不会想到这一点。Docker 社区版是开源的,所以如果有必要,你可以参与其中,但很可能你只是将 Docker 作为部署微服务的工具。Go 语言爱好者之所以想要记住 Docker 是用 Go 语言开发的这一事实,是因为无处不在的 Docker 有力地证明了他们对这门语言的支持。 Echo https://echo.labstack.com/ Echo 是一个极简框架,但它提供了很多最重要的组件。路由器可以将 URL 拆解,然后将拆解的各个部份转换为参数,因此你无需自行解析它们。然后,你可以混合使用身份验证、表单解析、压缩和合理性限制。你可以专注于从函数中返回正确的信息。 Errors https://github.com/juju/errors 有时候,API 的用户会传递错误的参数。你可以自己处理这些参数,也可以把它们创给 Errors,这是一个可以自动执行大部分跟踪的库,方便进行调试。当发生错误时,Errors 会使用注释来详细说明出错的地方和位置。 Gin https://github.com/gin-gonic/gin Gin 是 Martini( https://github.com/go-martini/martini )的下一代框架。可以说,Gin 抛弃了那些额外的东西,专注于提供最有用的部分。花费大量时间构建 Node.js 微服务的开发人员会感到宾至如归。你可以实例化一个对象,然后附加函数来处理特定的调用,这样就可以创建一个微服务。Gin 负责处理路由,而你的函数处理业务逻辑。如果不去考虑标点符号,它的代码甚至看起来有点像 Node.js 代码。 Ginkgo https://onsi.github.io/ginkgo/ 测试可能是微服务开发当中最具挑战性的事情。Ginkgo 通过行为驱动测试扩展了标准 Go 发行版的内置测试机制。Ginkgo 提供了一种高级机制,用于指定函数或服务应该产生哪些结果。结果通常使用 Ginkgo 提供的 Gomega 匹配器( http://onsi.github.io/gomega/ )进行评估,但如果你愿意,也可以使用不同的匹配器库。 Ginkgo 是一个全面的框架,提供了各种选项,用于设置测试数据、运行测试以及在事后释放测试数据。你只需要描述结果,然后让 Ginkgo 处理其他的事情。 Goa https://github.com/goadesign/goa 如果你是一个曾经使用 Ruby 和 Praxis 框架的开发人员,或者是一个欣赏设计语言的强大力量人,那么你会在 Goa 中找到很多你喜欢的东西。你本身不需要编写 Go 代码。你使用 Goa DSL 为 API 编写设计规范,然后 Goa 将其转换为可执行的 Go 代码。DSL 针对微服务 API 进行了优化,并强制你的设计遵循标准的架构。 Gorilla http://www.gorillatoolkit.org/ Gorilla 项目提供了一系列你需要的模块。Gorilla 的 Mux( http://www.gorillatoolkit.org/pkg/mux )路由器被很多其他框架使用,因为它太好用了。很多用户之所以使用 Gorilla,是因为 websocket( http://www.gorillatoolkit.org/pkg/websocket )。 Gotify https://github.com/gotify/server 同步一组微服务所面临的一个挑战是建立有效的消息传递节点。Gotify 是一个简单的服务器,用于发送和接收消息,将你的微服务集合与持续存储的消息组合在一起。最有用的部分可能是它的 Web 接口,可帮助开发者应对最令人头疼的调试问题。 Hugo https://github.com/gohugoio/hugo Hugo 是一种静态站点生成器,可以用这个框架构建的微服务并不多,但如果网站只有有限的重复查询答案时,这是一个值得考虑的选项。Hugo 一次生成答案,然后可以重复使用。如果你已经已 HTML 格式提供答案,那么 Hugo 会非常有用。 Kite https://github.com/koding/kite 如果你希望建立一个更加可控的服务群体,而不是通常的服务之间的互动,那么可以考虑一下 Kite。Kite 的目标是让微服务之间的通信协调变得更简单一些。来自 Kite 以外的 API 调用通过 websocket 进入,然后 Kite 使用更快、更低级别的套接字连接(基于 dnode)传递新消息。中间有一个叫作 Kontrol 的服务注册表和身份验证服务。如果你需要经常交换消息和协调很多的操作,那么在不同服务器之间添加这一层会让一切变得更快。 Logrus https://github.com/sirupsen/logrus 要跟踪 API 的流入和流出数据和可能产生的错误,通常需要将日志写入文件中。这个过程可以很简单,比如在一个打开的文件中写入一行行的数据,但通常使用完整的日志框架会更好。Logrus 提供了格式化程序来标准化你的日志输出,并让后续的自动化日志文件分析变得更容易。不要尝试自己开发日志代码,使用像 Logrus 这样的库会事半功倍。 Nano https://github.com/pasztorpisti/nano 构建一个微服务并不需要太多东西,Nano 就是一个极简主义的例子。它的实际代码不会超过 200 行,如果算上注释也只有 400 多行。你只需要几行代码就可以构建一个微服务——只包含处理请求所需的业务逻辑。这个框架还有一些其他不错的特性,例如与语言无关的 API 结构,这样你的 Go 代码就可以与使用其他语言开发的服务发生交互。它还提供了一个测试过程来,可以嵌入你的本地测试例程。简简单单,但却恰到好处。 Negroni https://github.com/urfave/negroni 有些人看完 Martini 后,决定走一条更简单的道路。他们剥离了路由器和其他一些东西,创建了 Negroni,这是一个非常小型的工具,除了处理标准文件、自定义请求、从基本错误中恢复以及保留日志之外,它不会做更多的工作。如果你想要额外的东西,可以自己加入。Negroni 团队也提供了一系列与可以与 Negroni 一起使用的小型项目。 Renderer https://github.com/thedevsaddam/renderer 在准备输出响应时,你需要获取数据并将其插入到模板中。Renderer 提供了各种输出格式(JSON、JSONP、XML、YAML、HTML、文件)和一个漂亮、快速和标准的模板引擎。 Revel https://revel.github.io/ Revel 借鉴了 Webpack 的一个简洁的特性,这让 Revel 看起来就像一个 IDE 一样,或者至少是 IDE 的一部分,每当你对代码做出更改,它会持续地重新构建你的项目。当你保存修改后,Revel 会检测到更改,然后就编译代码,如果没有编译错误,就启动应用程序。因此,Revel 服务器会自动部署修改的码——在桌面上进行开发时这项功能非常好用,或许对于生产环境代码部署来说也是有点诱人的。 这个框架本身功能齐全,它提供了模板、缓存、验证和过滤器。如果你正在构建很多微服务,它还提供了一个模块系统,让你可以在项目之间共享一些 MVC 组件。 Testify https://github.com/stretchr/testify 使用断言的最简单方法之一是使用 Testify,它是一个 Go 语言项目,还提供了模拟工具,用于快速测试大型微服务的各个部分。只需要几行代码就编写一些基本测试用例。 Tollbooth https://github.com/didip/tollbooth 在你发布 API 之后,当然希望来自世界各个角落的人都可以调用它。但当你的服务器发生熔断,或者你看一看为了获得弹性而为云托管账户支付的费用时,你可能会改变主意。Tollbooth 是一个用于限制传入请求的轻量级系统。限制前门的流量就等于减少了对管道中微服务或数据库的需求,让一切保持运行顺畅。 不使用框架 你只需从头开始编写 Go 代码,不需要导入任何依赖项或者实例化任何控制对象。使用 Go 语言创建微服务其实很容易,因为它已经内置了很多基本代码。这就是为什么只用几百行代码就可以构建出像 Nano 这样的框架。 监听套接字、解压缩 HTTP 请求等工作都是通过标准库完成的。虽然框架提供了一些额外的功能,但很多时候如果你需要一个非常基本的微服务,就不需要用到框架。太多的“附加功能”可能反而会妨碍你,而且 Go 开发人员可能会说,太多的依赖反而让 Go 语言变得更复杂。

有只黑白猫 2020-01-08 11:53:57 0 浏览量 回答数 0

问题

如何整合WAN和因特网云服务?

elainebo 2019-12-01 21:04:06 10065 浏览量 回答数 0

问题

健康检查常见问题

行者武松 2019-12-01 21:43:15 3573 浏览量 回答数 0

问题

微服务开发的 10 个最佳实践

游客pklijor6gytpx 2020-01-03 14:59:12 147 浏览量 回答数 1

回答

1、 描述下应用架构的发展历程 目前,架构的发展历程是从单体架构、分布式架构、SOA架构,再到如今流行的微服务架构 2、单体架构的优点、缺点 优点: I 易于开发,开发人员可在短时间内开发完成单体应用 II 易于测试 III 易于部署 缺点: I 灵活程度不够,一旦修改,自上而下需要整体部署,才可以展现出效果,同时开发效率低,降低团队灵活性 II 降低系统的性能 III 系统启动、重启缓慢 IV 扩展性差 3、 什么是传统的分布式架构 简单来说,就是按照业务垂直切分,每个应用都是一个单体架构,通过API接口互相调用 好处是,依赖解耦,理解清晰,开发便捷速度,缺点是调用存在风险,技术复杂,可靠性降低 4、 SOA架构的优点、缺点 面向服务的SOA架构,根据不同的业务建立不同的服务,优点,模块拆分,开发聚合,降低了耦合度,增加功能,增加子项目即可,方便部署,灵活的分布式部署 缺点,调用、交互采用远程通信,接口开发增加工作量 5、 什么是微服务技术 微服务架构在某种程度上是SOA架构的发展。微服务是一种架构风格,对于一个大型的复杂的业务应用系统,业务功能可以拆分为多个独立的微服务,各个服务间是松耦合的,通过各种远程通信协议,实现交互,各个服务可以独立部署、扩容、升降级 6、 目前流行的微服务解决方案 目前最常见的,包括两种,一种基于SpringCloud中间件的微服务解决方案,选型比较中立,内部组件,可以自由更换搭配使用,大致上三种,服务发现,一种Eureka,一种Consul,一种etcd或者阿里nacos,共用组件,服务调用组件Feign。负载均衡ribbon,熔断器hystrix,网关,zuul,gateway,等,配置中心,携程阿波罗,nacos,Config;全链路监控,zipkin,pinpoint,skywalking,其他组件 另一种基于Dubbo实现微服务解决方案,可以Dubbo,nacos,其他 7、 什么是中间件 中间件,是在操作系统之上,应用软件之下的中间层软件。本质上归结为技术架构。常见的中间件,包括服务治理中间件、配置中心、链路监控、分布式事务、分布式定时任务、分布式缓存、消息中间件、API网关、数据库中间件等 8、 什么是Spring Cloud 也是一个中间件,由Spring官方开发维护,基于SpringBoot技术框架,提供了一整套的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等组件,可以随需扩展或替换使用 9、 SpringCloud项目模块 注册中心 Eureka 第一代网关 Zuul 多语言 Sidecar 负载均衡 Ribbon 熔断器 Hystrix 第二代网关 gateway 集群监控 Turbine 声明式HTTP客户端 Feign 注册中心 consul 链路追踪 sleuth 配置中心 config 服务总线 Bus 等 10、 SpringCloud与服务治理中间件 服务治理中间件包含服务注册与发现、服务路由、复杂均衡、自我保护、丰富的治理管理机制等功能。服务路由包含服务上下线、在线测试、就近选择、A/B测试、灰度发布等,负载均衡支持根据状态权重进行负载。自我保护,服务降级、优雅降级、流量控制,Spring Cloud中使用了相关 11、 Springcloud与配置中心中间件 单体应用中,属性配置和代码采用硬编码形式放在一起,简单方便,但是在分布式系统中,多个服务实例,需要分别管理每个服务下对应的配置项,往往配置项项目一致,内容存在偏差,则上线需要检查所有的配置项,如果修改配置项,就要重启等,开发管理相当麻烦,另外还会涉及安全性的问题,比如数据库密码等的存放。分布式系统中,需要我们统一管理,负责管理的中间件,就是配置中心。配置中心,应该具备的功能,分别是支持各种复杂的配置场景,与公司的运维体系和权限体系集成一体,各种配置兼容支持。 SpringCloud Config是配置中心中间件,将应用原本放在本地的配置,统一放置到中心服务器,拥有了更好地管理发布能力,基于应用、环境、版本三个维度管理,配置存储支持git等。无缝支持Spring技术的Environment和PropertySource接口 12、 Springcloud与网关中间件 API是在系统边界上,面向API的串行集中式强管控服务,至少具备如下功能 I 统一接入功能,提供一个高性能、高并发、高可靠的网关服务,也要支持负载均衡、异地多活、容灾切换 Ii 协议适配功能,因为网关是集中式强管控,必须要提供满足各个请求协议,能够协议适配 Iii 流量管控 Iv 安全防护、权限校验 SpringCloud第一代网关采用zuul,根据默认或者配置的路由规则,进行负载或者路由,只能支持基本功能,如果想要实现高度定制更多功能,就需要,进行开发filter过滤器 SpringCloud第二代网关采用Gateway,zuul采用每个请求分配一个线程的方式,不能支持高并发,gateway采用netty框架,具有强大的高并发处理能力,且实现了网管基本功能,例如安全,监控,限流等 13、 Springcloud与全链路监控中间件 分布式系统下,对于日志追踪等,有迫切的需求,需要一个可视化展示监控平台,进行汇集。全链路监控中间件基本功能如下,定位慢调用:各种web服务调用,慢sql执行,定位各种错误,定位各种异常,展现服务依赖,展现调用链路,应用告警SpringCloud采用sleuth 14、 Springcloud与分布式事务 微服务架构之后,困难,在于,1)系统拆分后,服务间调用通信、故障处理变得复杂2)微服务化后,服务调用的分布式事务问题突出3)数量众多,测试部署运维复杂,那么随着Docker容器技术、Devops技术的发展,各种PAAS平台工具的退出,变得愈加容易。分布式事务没有统一方案 15、 Springcloud与领域驱动 微服务作为一种架构风格,提供了快速开发微服务应用的能力,但是对于业务如何开发,业务架构如何治理,架构如何防腐,还需要方法论进行指导,领域驱动作为业务治理和架构防腐的方法论,结合起来,才能更好地提供企业使用 16、 SpringCloud与gRPC协议 通过SpringCloud进行搭建微服务应用,服务间得通信往往采用的是Feign中间件形式,实现简单快捷的调用,底层采用的http形式,相对于gRPC协议或者RPC协议的调用来说,性能相对低下,因此,可以切换开源技术框架gRPC实现 17、 SpringCloud与Dubbo生态融合 SpringCloud与Dubbo在本质上不在一个领域没有可比性。Dubbo是一个基于RPC协议的通信框架,而SpringCloud是实现微服务中间件,随着发展,两者生态也在不断融合,目前已经开源了Spring-cloud-dubbo的项目

huc_逆天 2020-02-24 21:01:42 0 浏览量 回答数 0

回答

1、 描述下应用架构的发展历程 目前,架构的发展历程是从单体架构、分布式架构、SOA架构,再到如今流行的微服务架构 2、单体架构的优点、缺点 优点: I 易于开发,开发人员可在短时间内开发完成单体应用 II 易于测试 III 易于部署 缺点: I 灵活程度不够,一旦修改,自上而下需要整体部署,才可以展现出效果,同时开发效率低,降低团队灵活性 II 降低系统的性能 III 系统启动、重启缓慢 IV 扩展性差 3、 什么是传统的分布式架构 简单来说,就是按照业务垂直切分,每个应用都是一个单体架构,通过API接口互相调用 好处是,依赖解耦,理解清晰,开发便捷速度,缺点是调用存在风险,技术复杂,可靠性降低 4、 SOA架构的优点、缺点 面向服务的SOA架构,根据不同的业务建立不同的服务,优点,模块拆分,开发聚合,降低了耦合度,增加功能,增加子项目即可,方便部署,灵活的分布式部署 缺点,调用、交互采用远程通信,接口开发增加工作量 5、 什么是微服务技术 微服务架构在某种程度上是SOA架构的发展。微服务是一种架构风格,对于一个大型的复杂的业务应用系统,业务功能可以拆分为多个独立的微服务,各个服务间是松耦合的,通过各种远程通信协议,实现交互,各个服务可以独立部署、扩容、升降级 6、 目前流行的微服务解决方案 目前最常见的,包括两种,一种基于SpringCloud中间件的微服务解决方案,选型比较中立,内部组件,可以自由更换搭配使用,大致上三种,服务发现,一种Eureka,一种Consul,一种etcd或者阿里nacos,共用组件,服务调用组件Feign。负载均衡ribbon,熔断器hystrix,网关,zuul,gateway,等,配置中心,携程阿波罗,nacos,Config;全链路监控,zipkin,pinpoint,skywalking,其他组件 另一种基于Dubbo实现微服务解决方案,可以Dubbo,nacos,其他 7、 什么是中间件 中间件,是在操作系统之上,应用软件之下的中间层软件。本质上归结为技术架构。常见的中间件,包括服务治理中间件、配置中心、链路监控、分布式事务、分布式定时任务、分布式缓存、消息中间件、API网关、数据库中间件等 8、 什么是Spring Cloud 也是一个中间件,由Spring官方开发维护,基于SpringBoot技术框架,提供了一整套的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等组件,可以随需扩展或替换使用 9、 SpringCloud项目模块 注册中心 Eureka 第一代网关 Zuul 多语言 Sidecar 负载均衡 Ribbon 熔断器 Hystrix 第二代网关 gateway 集群监控 Turbine 声明式HTTP客户端 Feign 注册中心 consul 链路追踪 sleuth 配置中心 config 服务总线 Bus 等 10、 SpringCloud与服务治理中间件 服务治理中间件包含服务注册与发现、服务路由、复杂均衡、自我保护、丰富的治理管理机制等功能。服务路由包含服务上下线、在线测试、就近选择、A/B测试、灰度发布等,负载均衡支持根据状态权重进行负载。自我保护,服务降级、优雅降级、流量控制,Spring Cloud中使用了相关 11、 Springcloud与配置中心中间件 单体应用中,属性配置和代码采用硬编码形式放在一起,简单方便,但是在分布式系统中,多个服务实例,需要分别管理每个服务下对应的配置项,往往配置项项目一致,内容存在偏差,则上线需要检查所有的配置项,如果修改配置项,就要重启等,开发管理相当麻烦,另外还会涉及安全性的问题,比如数据库密码等的存放。分布式系统中,需要我们统一管理,负责管理的中间件,就是配置中心。配置中心,应该具备的功能,分别是支持各种复杂的配置场景,与公司的运维体系和权限体系集成一体,各种配置兼容支持。 SpringCloud Config是配置中心中间件,将应用原本放在本地的配置,统一放置到中心服务器,拥有了更好地管理发布能力,基于应用、环境、版本三个维度管理,配置存储支持git等。无缝支持Spring技术的Environment和PropertySource接口 12、 Springcloud与网关中间件 API是在系统边界上,面向API的串行集中式强管控服务,至少具备如下功能 I 统一接入功能,提供一个高性能、高并发、高可靠的网关服务,也要支持负载均衡、异地多活、容灾切换 Ii 协议适配功能,因为网关是集中式强管控,必须要提供满足各个请求协议,能够协议适配 Iii 流量管控 Iv 安全防护、权限校验 SpringCloud第一代网关采用zuul,根据默认或者配置的路由规则,进行负载或者路由,只能支持基本功能,如果想要实现高度定制更多功能,就需要,进行开发filter过滤器 SpringCloud第二代网关采用Gateway,zuul采用每个请求分配一个线程的方式,不能支持高并发,gateway采用netty框架,具有强大的高并发处理能力,且实现了网管基本功能,例如安全,监控,限流等 13、 Springcloud与全链路监控中间件 分布式系统下,对于日志追踪等,有迫切的需求,需要一个可视化展示监控平台,进行汇集。全链路监控中间件基本功能如下,定位慢调用:各种web服务调用,慢sql执行,定位各种错误,定位各种异常,展现服务依赖,展现调用链路,应用告警SpringCloud采用sleuth 14、 Springcloud与分布式事务 微服务架构之后,困难,在于,1)系统拆分后,服务间调用通信、故障处理变得复杂2)微服务化后,服务调用的分布式事务问题突出3)数量众多,测试部署运维复杂,那么随着Docker容器技术、Devops技术的发展,各种PAAS平台工具的退出,变得愈加容易。分布式事务没有统一方案 15、 Springcloud与领域驱动 微服务作为一种架构风格,提供了快速开发微服务应用的能力,但是对于业务如何开发,业务架构如何治理,架构如何防腐,还需要方法论进行指导,领域驱动作为业务治理和架构防腐的方法论,结合起来,才能更好地提供企业使用 16、 SpringCloud与gRPC协议 通过SpringCloud进行搭建微服务应用,服务间得通信往往采用的是Feign中间件形式,实现简单快捷的调用,底层采用的http形式,相对于gRPC协议或者RPC协议的调用来说,性能相对低下,因此,可以切换开源技术框架gRPC实现 17、 SpringCloud与Dubbo生态融合 SpringCloud与Dubbo在本质上不在一个领域没有可比性。Dubbo是一个基于RPC协议的通信框架,而SpringCloud是实现微服务中间件,随着发展,两者生态也在不断融合,目前已经开源了Spring-cloud-dubbo的项目

huc_逆天 2020-02-25 11:08:12 0 浏览量 回答数 0

问题

【春招必备】初级程序员必备Linux面试题

黄一刀 2020-03-12 19:15:24 7685 浏览量 回答数 3

问题

Java开发工程师必备技能

小柒2012 2019-12-01 20:55:20 11780 浏览量 回答数 3
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站