主頁 >  其他 > Istio 運維實戰系列（3）：讓人頭大的『無頭服務』-下

Istio 運維實戰系列（3）：讓人頭大的『無頭服務』-下

2020-09-29 20:03:54 其他

本系列文章將介紹用戶從 Spring Cloud，Dubbo 等傳統微服務框架遷移到 Istio 服務網格時的一些經驗，以及在使用 Istio 程序中可能遇到的一些常見問題的解決方法，

失敗的 Eureka 心跳通知

在上一篇文章中，我們介紹了 Headless Service 和普通 Service 的區別，由于 Headless Service 的特殊性，在 Istio 下發給 Envoy Sidecar 的配置中，此類服務的配置引數和其他服務的引數有所不同，除了我們上次遇到的 mTLS 故障之外，這些差異可能還會導致應用出現一些其他意想不到的情況，

這次遇到的問題現象是：在 Spring Cloud 應用遷移到 Istio 中后，服務提供者向 Eureka Server 發送心跳失敗，

備注：Eureka Server 采用心跳機制來判定服務的健康狀態，服務提供者在啟動后，周期性（默認30秒）向Eureka Server發送心跳，以證明當前服務是可用狀態，Eureka Server在一定的時間（默認90秒）未收到客戶端的心跳，則認為服務宕機，注銷該實體，

查看應用程式日志，可以看到 Eureka 客戶端發送心跳失敗的相關日志資訊，

2020-09-24 13:32:46.533 ERROR 1 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client - was unable to send heartbeat!

com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
	at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$3.execute(EurekaHttpClientDecorator.java:92) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:864) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1423) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[na:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:832) ~[na:na]

過期的 IP 地址

對于請求失敗類的故障，我們首先可以通過 Envoy 的訪問日志查看失敗原因，通過下面的命令查看客戶端 Envoy Sidecar 的日志：

k logs -f eureka-client-66f748f84f-vvvmz -c eureka-client -n eureka

從 Envoy 日志中可以查看到客戶端通過 HTTP PUT 向服務器發出的心跳請求，該請求的 Response 狀態碼為 "UF,URX"，表示其 Upstream Failure，即連接上游服務失敗，在日志中還可以看到，在連接失敗后，Envoy 向客戶端應用回傳了一個 "503" HTTP 錯誤碼，

[2020-09-24T13:31:37.980Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 503 UF,URX "-" "-" 0 91 3037 - "-" "Java-EurekaClient/v1.9.13" "1cd54507-3f93-4ff3-a93e-35ead11da70f" "eureka-server:8761" "172.16.0.198:8761" outbound|8761||eureka-server.eureka.svc.cluster.local - 172.16.0.198:8761 172.16.0.169:53890 - default

從日志中可以看到訪問的 Upstream Cluster 是 outbound|8761||eureka-server.eureka.svc.cluster.local ，Envoy 將該請求轉發到了 IP地址 為 172.16.0.198 的 Upstream Host，

查看集群中部署的服務，可以看到 eureka-server 是一個 Headless Service，

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get svc -n eureka -o wide
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
eureka-server   ClusterIP   None         <none>        8761/TCP   17m   app=eureka-server

在本系列的上一篇文章『Istio 運維實戰系列（2）：讓人頭大的『無頭服務』-上』中，我們了解到 Headless Service 并沒有 Cluster IP，DNS 會直接將 Service 名稱決議到 Service 后端的多個 Pod IP 上，Envoy 日志中顯示連接 Eureka Server地址 172.16.0.198 失敗，我們來看看這個 IP 來自哪一個 Eureka Server 的 Pod ，

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get pod -n eureka -o wide | grep eureka-server
NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE        NOMINATED NODE   READINESS GATES
eureka-server-0                  1/1     Running   0          6h55m   172.16.0.59    10.0.0.15   <none>           <none>
eureka-server-1                  1/1     Running   0          6m1s    172.16.0.200   10.0.0.7    <none>           <none>
eureka-server-2                  1/1     Running   0          6h56m   172.16.1.3     10.0.0.14   <none>           <none>

從上面的命令輸出中可以看到 Eureka 集群中有三個服務器，但沒有哪一個服務器的 Pod IP 是 Envoy 日志中顯示的 172.16.0.198，進一步分析發現 eureka-server-1 Pod 的啟動時間比客戶端的啟動時間晚很多，初步懷疑 Envoy 采用了一個已經被銷毀的 Eureka Server 的 IP 進行訪問，導致訪問失敗，

通過查看 Envoy dump 檔案中 outbound|8761||eureka-server.eureka.svc.cluster.local 的相關配置，進一步加深了我對此的懷疑，從下面的 yaml 片段中可以看到該 Cluster 的型別為 “ORIGINAL_DST”，

{
     "version_info": "2020-09-23T03:57:03Z/27",
     "cluster": {
      "@type": "type.googleapis.com/envoy.api.v2.Cluster",
      "name": "outbound|8761||eureka-server.eureka.svc.cluster.local",
      "type": "ORIGINAL_DST",  # 該選項表明 Enovy 在轉發請求時會直接采用 downstream 原始請求中的地址，
      "connect_timeout": "1s",
      "lb_policy": "CLUSTER_PROVIDED",
   ...

}

根據 Envoy 的檔案說明，“ORIGINAL_DST” 的解釋為：

In these cases requests routed to an original destination cluster are forwarded to upstream hosts as addressed by the redirection metadata, without any explicit host configuration or upstream host discovery.

即對于“ORIGINAL_DST” 型別的 Cluster，Envoy 在轉發請求時會直接采用 downstream 請求中的原始目的地 IP 地址，而不會采用服務發現機制，Istio 中 Envoy Sidecar 的該處理方式和 K8s 對 Headless Service 的處理是類似的，即由客戶端根據 DNS 直接選擇一個后端的 Pod IP，不會采用負載均衡演算法對客戶端的請求進行重定向分發，但讓人疑惑的是：為什么客戶端通過 DNS 查詢得到的 Pod 地址 172.16.0.198 訪問失敗了呢？這是由于客戶端查詢 DNS 時得到的地址在訪問期間已經不存在了，下圖解釋了導致該問題的原因：

  1. Client 查詢 DNS 得到 eureka-server 的三個IP地址，
  2. Client 選擇 Server-1 的 IP 172.16.0.198 發起連接請求，請求被 iptables rules 攔截并重定向到了客戶端 Pod 中 Envoy 的 VirtualInbound 埠 15001，
  3. 在收到 Client 的連接請求后，根據 Cluster 的配置，Envoy 采用請求中的原始目的地址 172.16.0.198 連接 Server-1，此時該 IP 對應的 Pod 是存在的，因此 Envoy 到 Server-1 的鏈接創建成功，Client 和 Envoy 之間的鏈接也會建立成功，Client 在創建鏈接時采用了 HTTP Keep Alive 選項，因此 Client 會一直保持該鏈接，并通過該鏈接以 30 秒間隔持續發送 HTTP PUT 服務心跳通知，
  4. 由于某些原因，該 Server-1 Pod 被 K8s 重建為 Server-1?，IP 發生了變化，
  5. 當 Server-1 的 IP 變化后，Envoy 并不會立即主動斷開和 Client 端的鏈接，此時從 Client 的角度來看，到 172.16.0.198 的 TCP 鏈接依然是正常的，因此 Client 會繼續使用該鏈接發送 HTTP 請求，同時由于 Cluster 型別為 “ORIGINAL_DST” ，Envoy 會繼續嘗試連接 Client 請求中的原始目的地址 172.16.0.198，如圖中藍色箭頭所示，但是由于該 IP 上的 Pod 已經被銷毀，Envoy 會連接失敗，并在失敗后向 Client 端回傳一個這樣的錯誤資訊：“upstream connect error or disconnect/reset before headers. reset reason: connection failure HTTP/1.1 503” ，如果 Client 在收到該錯誤后不立即斷開并重建鏈接，那么直到該鏈接超時之前，Client 都不會重新查詢 DNS 獲取到 Pod 重建后的正確地址，

為 Headless Service 啟用 EDS

從前面的分析中我們已經知道出錯的原因是由于客戶端 HTTP 長鏈接中的 IP 地址過期導致的，那么一個最直接的想法就是讓 Envoy 采用正確的 IP 地址去連接 Upstream Host，在不修改客戶端代碼，不重建客戶端鏈接的情況下，如何才能實作呢？

如果對比一個其他服務的 Cluster 配置，可以看到正常情況下，Istio 下發的配置中，Cluster 型別為 EDS （Endopoint Discovery Service），如下面的 yaml 片段所示：

 {
  "version_info": "2020-09-23T03:02:01Z/2",
  "cluster": {
   "@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
   "name": "outbound|8080||http-server.default.svc.cluster.local",
   "type": "EDS",       # 普通服務采用 EDS 服務發現，根據 LB 演算法從 EDS 下發的 endpoint 中選擇一個進行連接
   "eds_cluster_config": {
    "eds_config": {
     "ads": {},
     "resource_api_version": "V3"
    },
    "service_name": "outbound|8080||http-server.default.svc.cluster.local"
   },
  ...

 }

在采用 EDS 的情況下，Envoy 會通過 EDS 獲取到該 Cluster 中所有可用的 Endpoint，并根據負載均衡演算法（預設為 Round Robin）將 Downstream 發來的請求發送到不同的 Endpoint，因此只要把 Cluster 型別改為 EDS，Envoy 在轉發請求時就不會再采用請求中錯誤的原始 IP 地址，而會采用 EDS 自動發現到的 Endpoint 地址，采用 EDS 的情況下，本例的中的訪問流程如下圖所示：

通過查閱 Istio 原始碼，可以發現 Istio 對于 Headless Service 預設采用了 "ORIGINAL_DST" 型別的 Cluster，但我們也可以通過設定一個 Istiod 的環境變數 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 為 Headless Service 強制啟用 EDS ，

func convertResolution(proxy *model.Proxy, service *model.Service) cluster.Cluster_DiscoveryType {
	switch service.Resolution {
	case model.ClientSideLB:
		return cluster.Cluster_EDS
	case model.DNSLB:
		return cluster.Cluster_STRICT_DNS
	case model.Passthrough: // Headless Service 的取值為 model.Passthrough
		if proxy.Type == model.SidecarProxy {
            // 對于 Sidecar Proxy，如果 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 的值設為 True，則啟用 EDS，否則采用 ORIGINAL_DST
			if service.Attributes.ServiceRegistry == string(serviceregistry.Kubernetes) && features.EnableEDSForHeadless {
				return cluster.Cluster_EDS
			}

			return cluster.Cluster_ORIGINAL_DST
		}
		return cluster.Cluster_EDS
	default:
		return cluster.Cluster_EDS
	}
}

在將 Istiod 環境變數 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 設定為 true 后，再查看 Envoy 的日志，可以看到雖然請求原始 IP 地址還是 172.16.0.198，但 Envoy 已經把請求分發到了實際可用的三個 Server 的 IP 上，

[2020-09-24T13:35:28.790Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 4 4 "-" "Java-EurekaClient/v1.9.13" "d98fd3ab-778d-42d4-a361-d27c2491eff0" "eureka-server:8761" "172.16.1.3:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:39934 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:35:58.797Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 1 1 "-" "Java-EurekaClient/v1.9.13" "7799a9a0-06a6-44bc-99f1-a928d8576b7c" "eureka-server:8761" "172.16.0.59:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:45582 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:36:28.801Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 2 1 "-" "Java-EurekaClient/v1.9.13" "aefb383f-a86d-4c96-845c-99d6927c722e" "eureka-server:8761" "172.16.0.200:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:60794 172.16.0.198:8761 172.16.0.169:53890 - default

神秘消失的服務

在將 Eureka Server Cluster 的型別從 ORIGINAL_DST 改為 EDS 之后，之前心跳失敗的服務正常了，但過了一段時間后，發現原來 Eureka 中注冊的部分服務下線，導致服務之間無法正常訪問，查詢 Eureka Server 的日志，發現日志中有如下的錯誤：

2020-09-24 14:07:35.511  WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode  : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:[email protected]: missing entry.
2020-09-24 14:07:35.511  WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode  : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:[email protected]: cannot find instance

從日志中我們可以看到多個 Eureka Server 之間的資料同步發生了錯誤，當部署為集群模式時，Eureka 集群中的多個實體之間會進行資料同步，本例中的 Eureka 集群中有三個實體，這些實體之間的資料同步如下圖所示：

當改用 EDS 之后，當集群中的每一個 Eureka Server 向集群中的其他 Eureka Server 發起資料同步時，這些請求被請求方 Pod 中的 Envoy Sidecar 采用 Round Robin 進行了隨機分發，導致同步訊息發生了紊亂，集群中每個服務器中的服務注冊訊息不一致，導致某些服務被誤判下線，該故障現象比較隨機，經過多次測驗，我們發現在 Eureka 中注冊的服務較多時更容易出現改故障，當只有少量服務時不容易復現，

找到原因后，要解決該問題就很簡單了，我們可以通過將 Eureka Server 的 Sidecar Injection 設定為 false 來規避該問題，如下面的 yaml 片段所示：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: eureka-server
spec:
  selector:
    matchLabels:
      app: eureka-server
  serviceName: "eureka-server"
  replicas: 3
  template:
    metadata:
      labels:
        app: eureka-server
      annotations:
        sidecar.istio.io/inject: "false"  # 不為 eureka-server pod 注入 Envoy Siedecar
    spec:
      containers:
      - name: eureka-server
        image: zhaohuabing/eureka-test-service:latest
        ports:
        - containerPort: 8761
          name: http

反思

對于 Headless Service，Istio 預設采用 “ORIGINAL_DST” 型別的 Cluster，要求 Envoy Sidecar 在轉發時采用請求原始目的 IP 地址的行為其實是合理的，如同我們在本系列的上一篇文章『Istio 運維實戰系列（2）：讓人頭大的『無頭服務』-上』所介紹的，Headless Service 一般用于定義有狀態的服務，對于有狀態的服務，需要由客戶端根據應用特定的演算法來自行決定訪問哪一個后端 Pod，因此不應該在這些 Pod 前加一個負載均衡器，

在本例中，由于 Eureka 集群中各個節點之間會對收到的客戶端服務心跳通知進行同步，因此對于客戶端來說，將心跳通知發送到哪一個 Eureka 節點并不重要，我們可以認為 Eureka 集群對于外部客戶端而言是無狀態的，因此設定 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 環境變數，在客戶端的 Envoy Sidecar 中對客戶端發往 Eureka Server 的請求進行負載均衡是沒有問題的，但是由于 Eureka 集群內部的各個節點之間的是有狀態的，修改后影響了集群中各個 Eureka 節點之間的資料同步，導致了后面部分服務錯誤下線的問題，對于引發的該問題，我們通過去掉 Eureka Server 的 Sidecar 注入來進行了規避，

對于該問題，更合理的處理方法是 Envoy Sidecar 在嘗試連接 Upstream Host 失敗一定次數后主動斷開和客戶端側的鏈接，由客戶端重新查詢 DNS，獲取正確的 Pod IP 來創建新的鏈接，經過測驗驗證，Istio 1.6 及之后的版本中，Envoy 在 Upstream 鏈接斷開后會主動斷開和 Downstream 的長鏈接，建議盡快升級到 1.6 版本，以徹底解決本問題，也可以直接采用騰訊云上的云原生 Service Mesh 服務 TCM（Tencent Cloud Mesh），為微服務應用快速引入 Service Mesh 的流量管理和服務治理能力，而無需再關注 Service Mesh 基礎設施自身的安裝、維護、升級等事項，

參考檔案

  • All about ISTIO-PROXY 5xx Issues
  • Service Discovery: Eureka Server
  • Istio 運維實戰系列（2）：讓人頭大的『無頭服務』-上
  • Eureka 心跳通知問題測驗原始碼

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/139697.html

標籤：其他

上一篇：Unity周記: 2020.09.21-09.27

下一篇：微型斷路器的選擇使用

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 網閘典型架構簡述

    網閘架構一般分為兩種：三主機的三系統架構網閘和雙主機的2+1架構網閘。 三主機架構分別為內端機、外端機和仲裁機。三機無論從軟體和硬體上均各自獨立。首先從硬體上來看，三機都用各自獨立的主板、記憶體及存盤設備。從軟體上來看，三機有各自獨立的作業系統。這樣能達到完全的三機獨立。對于“2+1”系統，“2”分為 ......

    uj5u.com 2020-09-10 02:00:44 more
  • 如何從xshell上傳檔案到centos linux虛擬機里

    如何從xshell上傳檔案到centos linux虛擬機里及：虛擬機CentOs下執行 yum -y install lrzsz命令，出現錯誤：鏡像無法找到軟體包 前言 一、安裝lrzsz步驟 二、上傳檔案 三、遇到的問題及解決方案 總結 前言 提示：其實很簡單，往虛擬機上安裝一個上傳檔案的工具 ......

    uj5u.com 2020-09-10 02:00:47 more
  • 一、SQLMAP入門

    一、SQLMAP入門 1、判斷是否存在注入 sqlmap.py -u 網址/id=1 id=1不可缺少。當注入點后面的引數大于兩個時。需要加雙引號， sqlmap.py -u "網址/id=1&uid=1" 2、判斷文本中的請求是否存在注入 從文本中加載http請求，SQLMAP可以從一個文本檔案中 ......

    uj5u.com 2020-09-10 02:00:50 more
  • Metasploit 簡單使用教程

    metasploit 簡單使用教程 浩先生， 2020-08-28 16:18:25 分類專欄： kail 網路安全 linux 文章標簽： linux資訊安全 編輯 著作權 metasploit 使用教程 前言 一、Metasploit是什么？ 二、準備作業 三、具體步驟 前言 Msfconsole ......

    uj5u.com 2020-09-10 02:00:53 more
  • 游戲逆向之驅動層與用戶層通訊

    驅動層代碼： #pragma once #include <ntifs.h> #define add_code CTL_CODE(FILE_DEVICE_UNKNOWN,0x800,METHOD_BUFFERED,FILE_ANY_ACCESS) /* 更多游戲逆向視頻www.yxfzedu.com ......

    uj5u.com 2020-09-10 02:00:56 more
  • 北斗電力時鐘（北斗授時服務器）讓網路資料更精準

    北斗電力時鐘（北斗授時服務器）讓網路資料更精準 北斗電力時鐘（北斗授時服務器）讓網路資料更精準 京準電子科技官微——ahjzsz 近幾年，資訊技術的得了快速發展，互聯網在逐漸普及，其在人們生活和生產中都得到了廣泛應用，并且取得了不錯的應用效果。計算機網路資訊在電力系統中的應用，一方面使電力系統的運行 ......

    uj5u.com 2020-09-10 02:01:03 more
  • 【CTF】CTFHub 技能樹 彩蛋 writeup

    ?碎碎念 CTFHub：https://www.ctfhub.com/ 筆者入門CTF時時剛開始刷的是bugku的舊平臺，后來才有了CTFHub。 感覺不論是網頁UI設計，還是題目質量，賽事跟蹤，工具軟體都做得很不錯。 而且因為獨到的金幣制度的確讓人有一種想去刷題賺金幣的感覺。 個人還是非常喜歡這個 ......

    uj5u.com 2020-09-10 02:04:05 more
  • 02windows基礎操作

    我學到了一下幾點 Windows系統目錄結構與滲透的作用 常見Windows的服務詳解 Windows埠詳解 常用的Windows注冊表詳解 hacker DOS命令詳解（net user / type /md /rd/ dir /cd /net use copy、批處理 等） 利用dos命令制作 ......

    uj5u.com 2020-09-10 02:04:18 more
  • 03.Linux基礎操作

    我學到了以下幾點 01Linux系統介紹02系統安裝，密碼啊破解03Linux常用命令04LAMP 01LINUX windows： win03 8 12 16 19 配置不繁瑣 Linux：redhat,centos(紅帽社區版)，Ubuntu server,suse unix:金融機構，證券，銀 ......

    uj5u.com 2020-09-10 02:04:30 more
  • 05HTML

    01HTML介紹 02頭部標簽講解03基礎標簽講解04表單標簽講解 HTML前段語言 js1.了解代碼2.根據代碼 懂得挖掘漏洞 （POST注入/XSS漏洞上傳）3.黑帽seo 白帽seo 客戶網站被黑帽植入劫持代碼如何處理4.熟悉html表單 <html><head><title>TDK標題，描述 ......

    uj5u.com 2020-09-10 02:04:36 more
最新发布
  • 2023年最新微信小程式抓包教程

    01 開門見山 隔一個月發一篇文章，不過分。 首先回顧一下《微信系結手機號資料庫被脫庫事件》，我也是第一時間得知了這個訊息，然后跟蹤了整件事情的經過。下面是這起事件的相關截圖以及近日流出的一萬條資料樣本： 個人認為這件事也沒什么，還不如關注一下之前45億快遞資料查詢渠道疑似在近日復活的訊息。 訊息是 ......

    uj5u.com 2023-04-20 08:48:24 more
  • web3 產品介紹：metamask 錢包 使用最多的瀏覽器插件錢包

    Metamask錢包是一種基于區塊鏈技術的數字貨幣錢包，它允許用戶在安全、便捷的環境下管理自己的加密資產。Metamask錢包是以太坊生態系統中最流行的錢包之一，它具有易于使用、安全性高和功能強大等優點。 本文將詳細介紹Metamask錢包的功能和使用方法。 一、 Metamask錢包的功能 數字資 ......

    uj5u.com 2023-04-20 08:47:46 more
  • vulnhub_Earth

    前言 靶機地址->>>vulnhub_Earth 攻擊機ip：192.168.20.121 靶機ip：192.168.20.122 參考文章 https://www.cnblogs.com/Jing-X/archive/2022/04/03/16097695.html https://www.cnb ......

    uj5u.com 2023-04-20 07:46:20 more
  • 從4k到42k，軟體測驗工程師的漲薪史，給我看哭了

    清明節一過，盲猜大家已經無心上班，在數著日子準備過五一，但一想到銀行卡里的余額……瞬間心情就不美麗了。最近，2023年高校畢業生就業調查顯示，本科畢業月平均起薪為5825元。調查一出，便有很多同學表示自己又被平均了。看著這一資料，不免讓人想到前不久中國青年報的一項調查：近六成大學生認為畢業10年內會 ......

    uj5u.com 2023-04-20 07:44:00 more
  • 最新版本 Stable Diffusion 開源 AI 繪畫工具之中文自動提詞篇

    🎈 標簽生成器 由于輸入正向提示詞 prompt 和反向提示詞 negative prompt 都是使用英文，所以對學習母語的我們非常不友好 使用網址：https://tinygeeker.github.io/p/ai-prompt-generator 這個網址是為了讓大家在使用 AI 繪畫的時候 ......

    uj5u.com 2023-04-20 07:43:36 more
  • 漫談前端自動化測驗演進之路及測驗工具分析

    隨著前端技術的不斷發展和應用程式的日益復雜，前端自動化測驗也在不斷演進。隨著 Web 應用程式變得越來越復雜，自動化測驗的需求也越來越高。如今，自動化測驗已經成為 Web 應用程式開發程序中不可或缺的一部分，它們可以幫助開發人員更快地發現和修復錯誤，提高應用程式的性能和可靠性。 ......

    uj5u.com 2023-04-20 07:43:16 more
  • CANN開發實踐：4個DVPP記憶體問題的典型案例解讀

    摘要：由于DVPP媒體資料處理功能對存放輸入、輸出資料的記憶體有更高的要求（例如，記憶體首地址128位元組對齊），因此需呼叫專用的記憶體申請介面，那么本期就分享幾個關于DVPP記憶體問題的典型案例，并給出原因分析及解決方法。 本文分享自華為云社區《FAQ_DVPP記憶體問題案例》，作者：昇騰CANN。 DVPP ......

    uj5u.com 2023-04-20 07:43:03 more
  • msf學習

    msf學習 以kali自帶的msf為例 一、msf核心模塊與功能 msf模塊都放在/usr/share/metasploit-framework/modules目錄下 1、auxiliary 輔助模塊，輔助滲透（埠掃描、登錄密碼爆破、漏洞驗證等） 2、encoders 編碼器模塊，主要包含各種編碼 ......

    uj5u.com 2023-04-20 07:42:59 more
  • Halcon軟體安裝與界面簡介

    1. 下載Halcon17版本到到本地 2. 雙擊安裝包后 3. 步驟如下 1.2 Halcon軟體安裝 界面分為四大塊 1. Halcon的五個助手 1) 影像采集助手：與相機連接，設定相機引數，采集影像 2) 標定助手：九點標定或是其它的標定，生成標定檔案及內參外參，可以將像素單位轉換為長度單位 ......

    uj5u.com 2023-04-20 07:42:17 more
  • 在MacOS下使用Unity3D開發游戲

    第一次發博客，先發一下我的游戲開發環境吧。 去年2月份買了一臺MacBookPro2021 M1pro(以下簡稱mbp)，這一年來一直在用mbp開發游戲。我大致分享一下我的開發工具以及使用體驗。 1、Unity 官網鏈接： https://unity.cn/releases 我一般使用的Apple ......

    uj5u.com 2023-04-20 07:40:19 more

Copyright © 2010-2020 有解無憂