OpenShift 4 之Istio-Tutorial (6) 服务恢复能力(重试、超时、断路器)
2024-04-14 13:56:23
《OpenShift 4.x HOL教程汇总》
说明：本文已经在OpenShift 4.8环境中验证
文章目录
- 准备环境
- 重试（Fail Try）
- 超时（Timeout）
- 断路器（Circuit Breaker）
准备环境
在开始操作前，我们先把以前针对Recommendation定义的DestinationRule和VirtualService删除掉，然后把运行recommendation-v2微服务的Pod设为1个。
$ oc delete -f istiofiles/destination-rule-recommendation_lb_policy_app.yml -n tutorial
$ oc get istio-io -n tutorial
NAME GATEWAYS HOSTS AGE
virtualservice.networking.istio.io/customer-gateway ["customer-gateway"] ["*"] 146mNAME AGE
gateway.networking.istio.io/customer-gateway 146m$ oc scale deployment recommendation-v2 --replicas=1 -n tutorial
$ oc get pod -n tutorial
NAME READY STATUS RESTARTS AGE
customer-694668f65f-c5l2x 2/2 Running 0 150m
preference-v1-56969db6fb-mwtpl 2/2 Running 0 148m
recommendation-v1-dd8544f7c-s64sx 2/2 Running 0 147m
recommendation-v2-5494578985-mx7ft 2/2 Running 0 108m
重试（Fail Try）
当通过Service访问一个微服务的Pod出现错误（例如503）后，Istio可以自动（缺省配置，可以修改）尝试访问其它运行微服务的Pod。
- 在一个窗口中运行以下命令，可以看到此时recommendation v1和recommendation v2是交替被调用的。
$ export INGRESS_GATEWAY=$(oc get route istio-ingressgateway -n ${ISTIO_SYSTEM} -o 'jsonpath={.spec.host}')
$ ./scripts/run.sh $INGRESS_GATEWAY/customer
customer => preference => recommendation v2 from 'recommendation-v2-5494578985-mx7ft': 47
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-s64sx': 1451
customer => preference => recommendation v2 from 'recommendation-v2-5494578985-mx7ft': 48
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-s64sx': 1452
此时在Kiali中可以看到recommendation v1和recommendation v2各有50%的调用机会。
- 将recommendation-v1的pod减少到“0”
$ oc scale deployment/recommendation-v1 -n tutorial --replicas=0
- 查看运行recommendation-v2的Pod中recommendation容器的日志。
$ oc logs -n tutorial -f $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
- 在第二个窗口执行以下命令进入运行recommendation v2微服务的容器，以便能模拟recommendation v2微服务运行不正常。
$ oc exec -n tutorial -it $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
bash-4.4$
- 先在recommendation容器中分别使用本地地址和recommendation服务地址做调用一次recommendation微服务，确认可正常访问。
bash-4.4$ curl localhost:8080
recommendation v2 from 'recommendation-v2-5494578985-k7qrm': 49
bash-4.4$ curl recommendation:8080
recommendation v2 from 'recommendation-v2-5494578985-k7qrm': 50
- 然后在第一个窗口查看recommendation容器的日志，确认只有2条新纪录。
2021-09-19 09:25:42,331 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 49
2021-09-19 09:25:51,411 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 50
- 然后在运行recommendation v2微服务的容器内部执行以下命令，调用微服务接口模拟运行异常（返回503，但是服务内部还是可以统计计数的）。随后再次使用本地地址和recommendation服务地址做调用一次recommendation微服务确认，确认已经返回“misbehavior”错误提示。最后退出recommendation 容器。
bash-4.4$ curl localhost:8080/misbehave
Following requests to / will return a 503
bash-4.4$ curl localhost:8080
recommendation misbehavior from 'recommendation-v2-5494578985-k7qrm'
bash-4.4$ curl recommendation:8080
recommendation misbehavior from 'recommendation-v2-5494578985-k7qrm'
bash-4.4$ exit
- 然后在第一个窗口查看recommendation 容器的日志，确认只有4条新纪录。说明：通过本地地址“localhost:8080”访问recommendation 微服务产生1条纪录，而使用服务地址“recommendation:8080”访问recommendation 微服务产生3条纪录，这是由于istio默认在发现服务请求出现错误后会再自动重试2次（因此每次是3条纪录）。
2021-09-19 09:26:18,281 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 51
2021-09-19 09:26:25,555 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 52
2021-09-19 09:26:25,580 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 53
2021-09-19 09:26:25,629 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 54
- 在第二个窗口执行以下命令，确认出现“503”错误提示。
$ curl $INGRESS_GATEWAY/customer
customer => Error: 503 - preference => Error: 503 - recommendation misbehavior from 'recommendation-v2-5494578985-k7qrm'
- 然后在第一个窗口查看recommendation v2容器的日志，确认有27条新纪录。说明：这可能是customer-preference-recommendation的调用路径都是通过服务完成的，因此每级服务调用发现错误后都重试3次，因此总共是 3x3x3 = 27 次重试调用。
2021-09-19 09:50:12,011 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 55
2021-09-19 09:50:12,016 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 56
2021-09-19 09:50:12,068 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 57
2021-09-19 09:50:12,081 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 58
2021-09-19 09:50:12,085 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 59
2021-09-19 09:50:12,111 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 60
2021-09-19 09:50:12,158 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 61
2021-09-19 09:50:12,185 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 62
2021-09-19 09:50:12,221 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 63
2021-09-19 09:50:12,261 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 64
2021-09-19 09:50:12,282 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 65
2021-09-19 09:50:12,293 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 66
2021-09-19 09:50:12,320 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 67
2021-09-19 09:50:12,331 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 68
2021-09-19 09:50:12,382 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 69
2021-09-19 09:50:12,406 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 70
2021-09-19 09:50:12,416 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 71
2021-09-19 09:50:12,458 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 72
2021-09-19 09:50:12,514 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 73
2021-09-19 09:50:12,541 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 74
2021-09-19 09:50:12,588 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 75
2021-09-19 09:50:12,618 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 76
2021-09-19 09:50:12,626 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 77
2021-09-19 09:50:12,632 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 78
2021-09-19 09:50:12,654 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 79
2021-09-19 09:50:12,666 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 80
2021-09-19 09:50:12,699 INFO [com.red.dev.dem.rec.res.RecommendationResource] (executor-thread-1) recommendation request from recommendation-v2-5494578985-k7qrm: 81
- 文件istiofiles/virtual-service-recommendation-v2_retry.yml修改了recommendation的Servic的重试配置，将其增加到3次。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:name: recommendation
spec:hosts:- recommendationhttp:- route:- destination:host: recommendationretries:attempts: 3perTryTimeout: 2s
在第二个窗口执行命令修改重试的配置。
$ oc apply -f istiofiles/virtual-service-recommendation-v2_retry.yml -n tutorial
- 在第二个窗口再次进入运行“recommendation”的容器，然后再次通过服务访问recommendation v2微服务。
$ oc exec -n tutorial -it $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
bash-4.4$ curl recommendation:8080
recommendation misbehavior from 'recommendation-v2-5494578985-k7qrm'
然后在第一个窗口查看recommendation容器的日志，确认有4条新纪录。说明：这是由于我们刚刚将重试次数设为“3”次，加上初始访问，总共4次访问。
在第三个窗口执行命令将运行recommendation-v1微服务的pod数量恢复到“1”。然后查看运行recommendation-v1微服务的容器日志。
$ oc scale deployment/recommendation-v1 -n tutorial --replicas=1
$ oc logs -n tutorial -f $(oc get pods -n tutorial | grep recommendation-v1 | awk '{ print $1 }') -c recommendation -- /bin/bash
- 在第二个窗口连续访问customer，确认2次全部返回是有“recommendation v1”响应的。这说明istio暂时将有问题的“recommendation v2”隔离。
$ curl $INGRESS_GATEWAY/customer
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-pfd7j': 1
$ curl $INGRESS_GATEWAY/customer
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-pfd7j': 2
分别在窗口1和窗口3查看运行“recommendation v2”和“recommendation v1”的容器日志，确认每个窗口新增2条日志。说明：istio利用每次访问“recommendation v1”的同时对“recommendation v2”进行测试以判断它是否恢复正常（在这种测试中，前面的“重试”将不再起作用）。
此时在Kiali中可以看到recommendation v1有100%的调用机会，这是由于recommendation服务虽然会轮训调用v1和v2版的recommendation pod，但是由于调用v2版出错，所以recommendation服务会尝试调用v1版recommendation pod。
选中recommandation v2的小方框，然后将鼠标放在右侧红色App：recommendation上，此时可以看到提示：100%的Inbound请求出错。
选中preference的方框，然后将鼠标放在右侧红色App：preference上，此时可以看到提示：有一部分Outbound请求出错。
再恢复recommendation v2微服务正常运行，确认此时又可以访问到recommendation v2微服务了。
$ oc -n tutorial exec -it $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
bash-4.4$ curl localhost:8080/behave
Following requests to / will return a 200
bash-4.4$ exit
exit
超时（Timeout）
为访问微服务设置超时时间，当超过Timeout时间后自动结束访问。
- 首先我们根据本文开始说明，重新准备环境，确保recommendation v1和recommendation v2都可以正常访问。执行以下命令，删掉正常的recommendation v2的Deployment，然后部署一个超时版的recommendation v2。
$ oc delete -n tutorial -f recommendation/kubernetes/Deployment-v2.yml
$ oc apply -n tutorial -f recommendation/kubernetes/Deployment-v2-timeout.yml
- 执行脚本连续访问customer，可以发现recommendation v2返回结果比较慢。
$ export INGRESS_GATEWAY=$(oc get route istio-ingressgateway -n ${ISTIO_SYSTEM} -o 'jsonpath={.spec.host}')
$ ./scripts/run.sh $INGRESS_GATEWAY/customer
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-s64sx': 3078
customer => preference => recommendation v2 from '379afb614fb1': 1
customer => preference => recommendation v1 from 'recommendation-v1-dd8544f7c-s64sx': 3079
customer => preference => recommendation v2 from '379afb614fb1': 2
- 为recommendation服务创建一个VirtualService。文件istiofiles/virtual-service-recommendation-timeout.yml内容如下，其中为访问recommendation定义了timeout为1s。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:name: recommendation
spec:hosts:-- recommendationhttp:-- route:- destination:host: recommendationtimeout: 1.000s
执行命令，创建VirtualService
$ oc apply -f istiofiles/virtual-service-recommendation-timeout.yml -n tutorial
- 执行脚本持续访问customer，可以看到由于recommendation v2超时，所以返回的只有recommendation v1。
$ export INGRESS_GATEWAY=$(oc get route istio-ingressgateway -n ${ISTIO_SYSTEM} -o 'jsonpath={.spec.host}')
$ ./scripts/run.sh $INGRESS_GATEWAY/customer
customer => preference => recommendation v1 from '67976848-4l4s7': 3084
customer => preference => recommendation v1 from '67976848-4l4s7': 3085
customer => preference => recommendation v1 from '67976848-4l4s7': 3086
- 在Kiali控制台中，选中recommendation的红色方框，鼠标点到右上方App：recommendation后，可以看到50%的Inbound出现错误。由于此步骤没有配置“retry”
- 最后恢复环境，删除超时的recommendation v2部署和recommendation的VirtualService，并重新部署正常的recommendation v2。
$ oc delete -f istiofiles/virtual-service-recommendation-timeout.yml -n tutorial
$ oc delete -f recommendation/kubernetes/Deployment-v2-timeout.yml -n tutorial
$ oc apply -f recommendation/kubernetes/Deployment-v2.yml -n tutorial
断路器（Circuit Breaker）
当一个被调用服务出现错误后，下一次Istio还会将请求发给出错的服务。回顾本文的“重试(Fail Try)”中的第二章截图，访问recommendation v2的失败率是33%。这是由于Istio会轮训将请求发给recommendation v1和recommendation v2，当发现recommendation v2出现错误后再尝试发给recommendation v1。我们可以在DestinationRule上设置断路器（Circuit Breaker），以便在访问某个服务失败后暂时断开对这个服务实例的访问。Istio会在指定的时间后尝试将请求再次发给recommendation v2，如果此时失效的recommendation v2已经恢复正常，Istio会停止作用于recommendation v2的断路器。
- 根据本文“准备环境”的说明，删除所有recommendation微服务相关的VirtualService、DestinationRule。此时请求可以被轮训发到recommendation v1和recommendation v2上。
- 进入运行recommendation v2的容器里，执行命令把状态设为disbehave状态，然后退出。
$ oc -n tutorial exec -it $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
bash-4.4$ curl localhost:8080/misbehave
Following requests to / will return a 503
bash-4.4$ exit
exit
- 执行命令，连续访问customer。此时从调用客户端看到的是recommendation v1响应处理的请求。
$ export INGRESS_GATEWAY=$(oc get route istio-ingressgateway -n ${ISTIO_SYSTEM} -o 'jsonpath={.spec.host}')
$ ./scripts/run.sh $INGRESS_GATEWAY/customer
customer => preference => recommendation v1 from '67976848-4l4s7': 3492
customer => preference => recommendation v1 from '67976848-4l4s7': 3493
customer => preference => recommendation v1 from '67976848-4l4s7': 3494
customer => preference => recommendation v1 from '67976848-4l4s7': 3495
...
- 在另一个窗口执行以下命令，查看运行recommendation v2的容器日志。我们可以发现recommendation v2微服务还继续不断有日志输出，说明有请求还是不断发给它。因为此时我们还没有为recommendation v2设置断路器。
$ oc logs -n tutorial -f $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation
recommendation request from 3cbba7a9cde5: 1
recommendation request from 3cbba7a9cde5: 2
recommendation request from 3cbba7a9cde5: 3
...
- 在第三个窗口执行命令，为recommendation服务创建带有断路器的DestinationRule。文件istiofiles/destination-rule-recommendation_cb_policy_version_v2.yml定义了DestinationRule：
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:name: recommendation
spec:host: recommendationsubsets:- labels:version: v1name: version-v1- labels:version: v2name: version-v2trafficPolicy:connectionPool:http:http1MaxPendingRequests: 1maxRequestsPerConnection: 1tcp:maxConnections: 1outlierDetection:baseEjectionTime: 3mconsecutiveErrors: 1interval: 1smaxEjectionPercent: 100
执行命令为recommendation服务创建DestinationRule。
$ oc apply -f istiofiles/destination-rule-recommendation_cb_policy_version_v2.yml -n tutorial
- 此时可从从窗口1看到还不断发送对customer的请求，但是窗口2已经不再有日志输出，说明请求没有被发到recommendation v2微服务上，这是由于断路器暂时不再将请求发给出问题的recommendation v2微服务。
- 再次进入运行recommendation v2的容器里，执行命令把状态设为behave状态，然后退出。这样recommendation v2微服务又恢复了正常访问。
$ oc exec -it -n tutorial $(oc get pods -n tutorial | grep recommendation-v2 | awk '{ print $1 }') -c recommendation -- /bin/bash
bash-4.4$ curl localhost:8080/behave
Following requests to / will return a 503
bash-4.4$ exit
exit
- 继续观察窗口1和窗口2的输出，需要等3分钟左右。从以下窗口1的日志可以看到请求再次被转发到recommendation v2，而窗口2也会有新的日志输出，说明recommendation v2已经恢复接收到转发的请求。
customer => preference => recommendation v1 from '67976848-4l4s7': 4522
customer => preference => recommendation v2 from '3cbba7a9cde5': 20
customer => preference => recommendation v1 from '67976848-4l4s7': 4523
customer => preference => recommendation v2 from '3cbba7a9cde5': 21
customer => preference => recommendation v1 from '67976848-4l4s7': 4524
customer => preference => recommendation v2 from '3cbba7a9cde5': 22
customer => preference => recommendation v1 from '67976848-4l4s7': 4525
customer => preference => recommendation v2 from '3cbba7a9cde5': 23
OpenShift 4 之Istio-Tutorial (6) 服务恢复能力(重试、超时、断路器)相关推荐
- OpenShift 4 之Service Mesh教程（1）- 创建ServiceMesh环境，部署Istio的微服务
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.8环境中验证 文章目录 创建ServiceMesh环境 部署Istio的微服务 参考 创建Servi ...
- dbnetlib不存在或拒绝访问_idou老师教你学Istio 16：如何用 Istio 实现微服务间的访问控制...
本文由华为云容器Istio团队撰稿,未经允许谢绝转载. 摘要 使用 Istio 可以很方便地实现微服务间的访问控制.本文演示了使用 Denier 适配器和黑白名单两种方法. 使用场景 有时需要对微服务 ...
- 华为云讲解：2. Istio Pilot 与服务发现
华为云讲解:2. Istio Pilot 与服务发现 文章目录 华为云讲解:2. Istio Pilot 与服务发现 服务发现 看图说话 在Istio里面Service A 访问ServiceB 如何 ...
- [翻译]什么是Istio? 它是服务网格。棒极了，那什么是服务网格？
2019独角兽企业重金招聘Python工程师标准>>> 我不知道在技术社区中有多少人有这样的观点,35年之后,我们的生活就会像是"银翼杀手"的续集."银 ...
- 使用Istio打造微服务（第1部分）
Istio 是一个由Google,IBM和Lyft团队合作开发的开源项目,它提供了基于微服务的应用程序复杂性的解决方案,仅举几例: 流量管理 :超时,重试,负载均衡, 安全性: 最终用户身份验证和授权 ...
- 等待 dg597 服务的连接超时
等待 dg597 服务的连接超时 dg597服务 是dgbased,驱动精灵的运行服务. 自己找到管理,关闭这个驱动精灵服务.或者卸载就可以解决了
- Hystrix面试 - 基于 timeout 机制为服务接口调用超时提供安全保护
Hystrix面试 - 基于 timeout 机制为服务接口调用超时提供安全保护 一般来说,在调用依赖服务的接口的时候,比较常见的一个问题就是超时.超时是在一个复杂的分布式系统中,导致系统不稳定,或者 ...
- 微博中微服务缓存_微服务之间调用超时的设置治理
原标题:微服务之间调用超时的设置治理 作者 | 奇正 微服务是⼀种分布式架构,系统内各部分(服务)被部署为单独的应用程序,并通过某种远程访问协议进⾏通讯.分布式应⽤的挑战之⼀就是如何管理远程服务的可用 ...
- OpenShift 4 之Istio-Tutorial (8) 在服务之间配置Mutual TLS双向传输安全
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.6环境中验证 在Service Mesh中,两个微服务之间双向传输安全是由Sidecar完成的.如下 ...
最新文章
- 360浏览器使用评价
- 使用mybatis自动生成指定规则的编号
- 发现你的身形——OpenCV图像轮廓
- java ftp 下载慢_Java实现ftp文件上传下载解决慢中文乱码多个文件下载等问题
- 拥有Mac的你怎么可以不知道Downie，Downie4最新更新「安装与使用」
- 华强北二手手机卖不出去，闲鱼砸一亿现金帮扶
- LogDashboard 1.0.4 版本发布
- Oracle分组取前n条记录
- ajax传递数组_利用AJAX+PHP+MySQL实现不重新加载页面进行用户名已注册检测
- es的query及filter 1
- 安川伺服总线通讯方式_终于有人把常用的三种通讯方式：RS485、RS232、RS422讲明白了...
- 王晶：华为云OCR文字识别服务技术实践、底层框架及应用场景 | AI ProCon 2019
- CBCGPToolBarImages和CImageList创建与使用
- 基于vue+muse-ui的简历生成器
- IDEA MyEclipse Eclipse 快捷键大全(最终版)
- sql 遇到多个重复列名报错：Ambiguous column reference ***
- html 标签英文全称,html标签英文全称
- C语言编写九九乘法表，实现不同三角形形状表格输出
- 萌新改代码系列（一）--VINS+GPS
- Altium Designer 10对集成库的理解
热门文章
- 修复老相片_将老相片数码化
- 阐述HTML语言的基本语法规则,HTML基本语法和语义写法规则与实例
- # 根据三边求角度_七年级数学：怎么求旋转射线构成的角度？掌握这种方法口算出结果...
- linux一次执行多个命令,linux 一次执行多条命令
- 设计素材|剪纸风新年春节烫金PSD分层模板,牛气！
- 设计灵感|纯文字排版也能让海报引人注目
- 建议设计日常多逛，多学习的网站
- 亚麻纤维截面形态_纺织品知识点--纺织纤维的分类get
- vps没有mysql怎么用商店_如何在本地搞一个小程序的服务器之我没有vps我也很绝望呀...
- mysql日志输出到syslog_在chroot环境下将MySQL日志输出到syslog