2. 程式人生 > >理解OpenShift（1）：網路之 Router 和 Route Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的

理解OpenShift（1）：網路之 Router 和 Route Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的

阿新 • • 發佈：2018-11-26

 理解OpenShift（1）：網路之Router 和 Route

 

1. OpenShift 為什麼需要 Router 和 Route？

顧名思義，Router 是路由器，Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部（就是從除了叢集節點以外的其它地方）訪問服務的需求。不曉得為什麼OpenShift 要將Kubernetes 中的 Ingress 改為 Router，我倒是覺得 Ingress 名字更貼切。

從外部通過 router 和從內部通過 servide 訪問 pod 中的應用兩個過程的簡單的示意圖如下：

上圖中，某個應用的三個pod 分別位於 node1，node2 和 node3 上。OpenShift 中有三層IP地址概念：

  • pod 自己的 IP 地址，可以類比為 OpenStack 中虛擬機器的固定IP。它只有在叢集內才有意義。
  • service 的 IP 地址。Service 通常有 ClusterIP，這也是一種叢集內部的IP 地址。
  • 應用的外部 IP 地址，可以類比為OpenStack 中的浮動IP，或者IDC IP（和浮動IP 之間是NAT 對映關係）。

因此，要從叢集外部訪問 pod 中的應用，無非兩種方式：

  • 一種是利用一個代理（proxy），把外部 IP 地址轉化為後端的 Pod IP 地址。這就是 OpenShift router/route 的思路。OpenShift 中的 router 服務，是一個執行在特定節點（通常是基礎架構節點）上的叢集基礎服務，由叢集管理員負責建立和管理。它可以有多個副本（pod）。router 中可有多個 route，每個 route 能通過外部HTTP 請求的域名找出其後端的 pod 列表，並進行網路包的轉發。也就是將pod 中的應用暴露到外網域名，使得使用者可以外面通過域名訪問到應用。這實際上是一種七層負載均衡器。OpenShift 預設採用 HAProxy 來實現，當然也支援其它實現，比如 F5.
  • 另一種是將服務直接暴露到叢集外。這種方式具體會在『服務 Service』那一篇文章中詳細解釋。

2. OpenShift 如何利用 HAProxy 實現 router 和 route？

2.1 Router 部署

使用 ansible 採用預設配置部署 OpenShift 叢集時，在叢集 Infra 節點上，會以 Host networking 方式執行一個 HAProxy 的 pod，它會在所有網絡卡的 80 和 443 埠上進行監聽。

[[email protected] cloud-user]# netstat -lntp | grep haproxy
tcp        
 
0      0 127.0.0.1:10443         0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 127.0.0.1:10444         0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      583/haproxy

其中，172.0.0.1 上的 10443 和 10444 是HAproxy 自己使用的。下文會有解釋。

因此，在每個 infra 節點上，只能有一個 HAProxy pod，因為這些埠只能被佔用一次。如果排程器找不到滿足要求的節點，則router 服務的排程就會失敗：

0/7 nodes are available: 2 node(s) didn't have free ports for the requested pod ports, 5 node(s) didn't match node selector

OpenShift HAProxy Router 支援兩種部署方式：

  • 一種是常見的單Router 服務部署，它有一個或多個例項（pod），分佈在多個節點上，負責整個叢集上部署的服務的對外訪問。
  • 另一種是分片（sharding）部署。此時，會有多個 Router 服務，每個Router 服務負責指定的若干project，兩者之間採用標籤（label）進行對映。這是為了解決單個 Router 的效能不夠問題而提出的解決方案。

OpenShift 提供了 oc adm router 命令來建立 router 服務。

建立router：

[[email protected] cloud-user]# oc adm router router2 --replicas=1 --service-account=router
info: password for stats user admin has been set to J3YyPjlbqf
--> Creating router router2 ...
    warning: serviceaccounts "router" already exists
    clusterrolebinding.authorization.openshift.io "router-router2-role" created
    deploymentconfig.apps.openshift.io "router2" created
    service "router2" created
--> Success

詳細的部署方法請參見官方文件 https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。

2.2 Router pod 中的 HAProxy 程序

在 Router 服務的每個 pod 之中，openshift-router 程序啟動了一個 haproy 程序：

UID        PID  PPID  C STIME TTY          TIME CMD
1000000+     1     0  0 Nov21 ?        00:14:27 /usr/bin/openshift-router
1000000+ 16011     1  0 12:42 ?        00:00:00 /usr/sbin/haproxy -f /var/lib/haproxy/conf/haproxy.config -p /var/lib/haproxy/run/haproxy.pid -x /var/lib/haproxy/run/haproxy.sock -sf 16004

檢視 haproxy 使用的配置檔案（只是部分）：

global
  maxconn 20000
  daemon
  ca-base /etc/ssl
  crt-base /etc/ssl
 。。。。  

defaults
  maxconn 20000

  # Add x-forwarded-for header.

  # server openshift_backend 127.0.0.1:8080
  errorfile 503 /var/lib/haproxy/conf/error-page-503.http

。。。
  timeout http-request 10s
  timeout http-keep-alive 300s

  # Long timeout for WebSocket connections.
  timeout tunnel 1h

frontend public
    
  bind :80
  mode http
  tcp-request inspect-delay 5s
  tcp-request content accept if HTTP
  monitor-uri /_______internal_router_healthz

  # Strip off Proxy headers to prevent HTTpoxy (https://httpoxy.org/)
  http-request del-header Proxy

  # DNS labels are case insensitive (RFC 4343), we need to convert the hostname into lowercase
  # before matching, or any requests containing uppercase characters will never match.
  http-request set-header Host %[req.hdr(Host),lower]

  # check if we need to redirect/force using https.
  acl secure_redirect base,map_reg(/var/lib/haproxy/conf/os_route_http_redirect.map) -m found
  redirect scheme https if secure_redirect

  use_backend %[base,map_reg(/var/lib/haproxy/conf/os_http_be.map)]

  default_backend openshift_default

# public ssl accepts all connections and isn't checking certificates yet certificates to use will be
# determined by the next backend in the chain which may be an app backend (passthrough termination) or a backend
# that terminates encryption in this router (edge)
frontend public_ssl
    
  bind :443
  tcp-request  inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }

  # if the connection is SNI and the route is a passthrough don't use the termination backend, just use the tcp backend
  # for the SNI case, we also need to compare it in case-insensitive mode (by converting it to lowercase) as RFC 4343 says
  acl sni req.ssl_sni -m found
  acl sni_passthrough req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_sni_passthrough.map) -m found
  use_backend %[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] if sni sni_passthrough

  # if the route is SNI and NOT passthrough enter the termination flow
  use_backend be_sni if sni

  # non SNI requests should enter a default termination backend rather than the custom cert SNI backend since it
  # will not be able to match a cert to an SNI host
  default_backend be_no_sni

。。。

backend be_edge_http:demoprojectone:jenkins
  mode http
  option redispatch
  option forwardfor
  balance leastconn
  timeout server  4m

  timeout check 5000ms
  http-request set-header X-Forwarded-Host %[req.hdr(host)]
  http-request set-header X-Forwarded-Port %[dst_port]
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn -i h2 }
  http-request add-header Forwarded for=%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=%[req.hdr(X-Forwarded-Proto-Version)]
  cookie 4376ea64d7d0abf11209cfe5f7cca1e7 insert indirect nocache httponly secure
  server pod:jenkins-1-84nrt:jenkins:10.128.2.13:8080 10.128.2.13:8080 cookie 8669a19afc9f0fed6824feb9fb1cf4ac weight 256

。。。

為了簡單期間，上面只是配置檔案的部分內容，它主要包括三種類型：

  • 全域性配置，比如最大連線數 maxconn，超時時間 timeout 等；以及front部分，即前端配置，HAProxy 預設會在 443 和 80 兩個埠上分別監聽外部 https 和 http 請求。
  • backend，即每個服務的後端配置，裡面有很多關鍵內容，比如後端協議（mode）、負載均衡方法（balance）、後端列表（server，這裡是pod，包括其IP 地址和埠）、證書等。

因此，OpenShift 的路由器功能需要能對這三部分進行管理和控制。

關於負載均衡器和 HAProxy 的詳細介紹，可以參考 Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的 這篇文章。

2.3 全域性配置管理

要指定或修改 HAProxy 的全域性配置，OpenShift 有提供兩種方式：

（1）第一種是使用 oc adm router 命令在建立 router 時候指定各種引數，比如 --max-connections 用於設定最大連線數。比如：

oc adm router --max-connections=200000 --ports='81:80,444:443' router3

創建出來的HAProxy 的 maxconn 將是 20000，router3 這個服務對外暴露出來的埠是 81 和 444，但是 HAProxy pod 的埠依然是 80 和 443.

（2）通過設定 dc/<dc router名> 的環境變數來設定 router 的全域性配置。

在官方文件 https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html#haproxy-template-router 中有完整的環境變數列表。比如執行以下命令後，

 oc set env dc/router3 ROUTER_SERVICE_HTTPS_PORT=444 ROUTER_SERVICE_HTTP_PORT=81 STATS_PORT=1937

router3 會重新部署，新部署的HAProxy 的 https 監聽埠是 444，http 監聽埠是 80，統計埠是 1937.

 2.4 OpenShift passthrough 型別的 route 與 HAProxy backend

（1）通過OpenShift Console 或者 oc 命令建立一條 route，它將 sit 專案的 jenkins 服務暴露到域名 sitjenkins.com.cn：

在介面上建立 route：

結果：

Name:                   sitjenkins.com.cn
Namespace:              sit
Labels:                 app=jenkins-ephemeral
                        template=jenkins-ephemeral-template
Annotations:            <none>
Requested Host:         sitjenkins.com.cn
Path:                   <none>
TLS Termination:        passthrough
Endpoint Port:          web

Service:        jenkins
Weight:         100 (100%)
Endpoints:      10.128.2.15:8080, 10.131.0.10:8080 

這裡，service name 起了一箇中介作用，把 route 和服務的端點（也就是pod）連線了起來。

（2）router 服務的兩個 pod 中的 HAProxy 程序的配置檔案中多了一個backend：

# Secure backend, pass through
backend be_tcp:sit:sitjenkins.com.cn
  balance source

  hash-type consistent
  timeout check 5000ms}
  server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 weight 256 check inter 5000ms
  server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 weight 256 check inter 5000ms

其中，這些後端 server 其實就是 pod，它們是 openshift 通過步驟（1）中的 service name 找到的。balance 是負載均衡策略，後文會解釋。

（3）檔案 /var/lib/haproxy/conf/os_sni_passthrough.map 中多了一條記錄

sh-4.2$ cat /var/lib/haproxy/conf/os_sni_passthrough.map
^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ 1

（4）檔案 /var/lib/haproxy/conf/os_tcp_be.map 中多了一條記錄

sh-4.2$ cat /var/lib/haproxy/conf/os_tcp_be.map
^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_tcp:sit:sitjenkins.com.cn

（5）HAProxy 根據上面的 map 檔案為該條 route 選擇第（2）步中增加的 backend的邏輯如下

frontend public_ssl  #解釋：前端協議 https，

  bind :443  ##前端埠 443
  tcp-request  inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }

  # if the connection is SNI and the route is a passthrough don't use the termination backend, just use the tcp backend
  # for the SNI case, we also need to compare it in case-insensitive mode (by converting it to lowercase) as RFC 4343 says
  acl sni req.ssl_sni -m found ##檢查 https request 支援 sni
  acl sni_passthrough req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_sni_passthrough.map) -m found ##檢查通過 sni 傳來的 hostname 在 os_sni_patthrough.map 檔案中
  use_backend %[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] if sni sni_passthrough ##從 oc_tcp_be.map 中根據 sni hostname 獲取 backend name

  # if the route is SNI and NOT passthrough enter the termination flow
  use_backend be_sni if sni

  # non SNI requests should enter a default termination backend rather than the custom cert SNI backend since it
  # will not be able to match a cert to an SNI host
  default_backend be_no_sni

（6）HAPorxy 程序會重啟，從而應用修改了的配置檔案。

理解（5）中的指令碼需要的一些背景知識：

從上面的藍色註釋中，我們能看到 HAProxy 程序通過 https 請求中通過 SNI 傳入的域名 sitjenkins.com.cn ，在 os_tcp_be.map 檔案中獲取到了 backend 名稱 be_tcp:sit:sitjenkins.com.cn，這樣就和（2）步驟中的 backend 對應上了。

OpenShift 的 router 使用的 HAProxy 採用基於域名的負載均衡路由方式，示例如下，具體說明請參加官方文件。

2.5 OpenShift edge 和 re-encrypt 型別的 route 與 HAProxy

HAProxy 前端：前端依然是在 443 埠監聽外部 HTTPS 請求

frontend public_ssl
  bind :443
.....
  # if the route is SNI and NOT passthrough enter the termination flow
  use_backend be_sni if sni

但是，當 TLS 終止型別不是 passthrough （edge 或者 re-encrypt）時，會使用backend be_sni。

backend be_sni
  server fe_sni 127.0.0.1:10444 weight 1 send-prox

而這個後端是由本機的 127.0.0.1:10444 提供服務，因此又轉到了前端 fe_sni：

frontend fe_sni
  # terminate ssl on edge
  bind 127.0.0.1:10444 ssl no-sslv3 crt /var/lib/haproxy/router/certs/default.pem crt-list /var/lib/haproxy/conf/cert_config.map accept-proxy
  mode http
。。。。。。

  # map to backend
  # Search from most specific to general path (host case).
  # Note: If no match, haproxy uses the default_backend, no other
  #       use_backend directives below this will be processed.
  use_backend %[base,map_reg(/var/lib/haproxy/conf/os_edge_reencrypt_be.map)]

  default_backend openshift_default

map 對映檔案：

sh-4.2$ cat /var/lib/haproxy/conf/os_edge_reencrypt_be.map
^edgejenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_edge_http:sit:jenkins-edge

Edge 型別 route 的 HAProxy 後端：

backend be_edge_http:sit:jenkins-edge
  mode http
  option redispatch
  option forwardfor
  balance leastconn

  timeout check 5000ms
  .....
  server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie 71c6bd03732fa7da2f1b497b1e4c7993 weight 256 check inter 5000ms
  server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie fa8d7fb72a46958a7add1406e6d26cc8 weight 256 check inter 5000ms

Re-encrypt 型別 route 的 HAProxy 後端：

# Plain http backend or backend with TLS terminated at the edge or a
# secure backend with re-encryption.
backend be_secure:sit:reencryptjenkins.com.cn
  mode http
。。。。

    http-request set-header X-Forwarded-Host %[req.hdr(host)]
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-Forwarded-Proto-Version h2 if { ssl_fc_alpn -i h2 }

  server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms #與後端的鏈路採用 ssl 加密，並且要檢查hostname
  server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms

這裡可以看出來重新使用金鑰對連線進行加密，但是不知道為何 mode 依然是 http，而不是 https。

 2.6 設定和修改 route 配置

route 配置主要有以下幾個比較重要的：

（1）SSL 終結方式。共三種：

  • edge：TLS 在 router 上被終結，然後非SSL網路包被轉發給後端 pod。因此需要在 router 上安裝 TLS 證書。不安裝的話，會使用 router 的預設證書。
  • passthrough：加密網路包直接被髮給 pod，router 上不做TLS 終結，因為不需要在 router 上配置證書或金鑰。
  • Re-encryption：是 edge 的一種變種。首先 router 上會使用一個證書做 TSL 終結，然後使用另外的證書再進行加密，然後發給後端 pod。因此，整個網路路徑都是加密的。

設定：

（2）負載均衡策略。也有三種：

  • roundrobin：根據權重輪流使用所有後端。
  • leastconn：選擇最少連線的後端接收請求。
  • source：將源IP進行雜湊，確保來自同一個源IP的請求發給同一個後端。
設定：
  • 要修改整個 router 的負載均衡策略，可使用 ROUTER_TCP_BALANCE_SCHEME 環境變數，為該 router 的所有 passthrough 型別的 route設定負載均衡策略，使用 ROUTER_LOAD_BALANCE_ALGORITHM 為其它型別的 route 設定策略。
  • 可以使用 haproxy.router.openshift.io/balance 為某個 route 設定負載均衡策略。

 舉例：

  • 設定整個 router 的環境變數：oc set env dc/router ROUTER_TCP_BALANCE_SCHEME=roundrobin
改完以後，該 router 例項會重新部署，所有 passthrough 的 route 都是 roundrobin 型別的了。預設為 source 型別。
  • 修改某個 route 的負載均衡的策略：oc edit route aaaa.svc.cluster.local
修改完成後，HAProxy 中對應該 route 的 backend 中的 balance 值會被修改為 leastconn。

3. OpenShift router 服務如何實現高可用？

OpenShift router 服務支援兩種高可用模式。

3.1 單 router 服務多副本，並利用和DNS/LB 實現高可用

這種模式只部署一個 router 服務，它支援叢集的所有對外暴露的服務。要實現HA，需要設定副本數（replicas）大於1，使得會在超過一臺伺服器上建立pod，然後再通過DNS輪詢或者四層負載均衡。 

因為 router/pod 中的 HAProxy 要實現本地配置檔案，因此實際上它們是有狀態容器。OpenShift 採用 etcd 作為配置的統一儲存，openshift-router 程序應該是採取某種機制（被通知或定時拉取）從 etcd 中獲取 router 和 route 的配置，然後再修改本地的配置檔案，再重啟 HAPorxy 程序來應用新修改了的配置檔案。 要深入瞭解這裡面的工作原理，可以去看原始碼。

3.2 多 router 服務通過分片（sharding）實現高可用

這種模式下，管理員需要建立和部署多個 router 服務，每個router 服務支援一個或幾個 project/namespace。router 和 project/namespace 之間的對映使用標籤（label）來實現。具體的配置請參考官網 https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。實際上，和一些產品（比如mysql，memedcache）的分片功能類似，該功能更多地是為了解決效能問題，而無法完全解決高可用問題。

4. 常見問題如何排查？

從上面的分析可以看出，要使得 router 和 route 都正常工作，至少要確保以下幾個環節都是沒問題的：

  1. 客戶端使用 route 中配置的域名和埠來訪問服務。
  2. DNS 能將域名解析到目標 router 所在的伺服器（在使用分片配置時比較複雜，尤其需要注意）。
  3. 如有采用另外的四層負載均衡器的話，它得配置正確、工作正常。
  4. HAProxy 能通過域名匹配到正確的backend。
  5. router 和 route 的配置被正確地反映到了 HAProxy 的配置檔案中了。
  6. HAProxy 程序重啟了，從而讀取了新修改的配置檔案。
  7. 後端 pod 列表正確，並且至少有一個 pod 正常工作。

如果您看到如下的錯誤頁面，則說明上面的第3到7點至少有一處不能正常功能。此時，進行有針對性的排查即可。

 

感謝您的閱讀，歡迎關注我的微信公眾號：

 

 

 

 

相關推薦

理解OpenShift（1）：網路之 Router 和 Route Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的

 理解OpenShift（1）：網路之Router 和 Route   1. OpenShift 為什麼需要 Router 和 Route？ 顧名思義，Router 是路由器，Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部（就是從除了叢集節點

理解OpenShift（1）：網路之 Router 和 Route

1. OpenShift 為什麼需要 Router 和 Route？ 顧名思義，Router 是路由器，Route 是路由器中配置的路由。OpenShift 中的這兩個概念是為了解決從叢集外部（就是從除了叢集節點以外的其它地方）訪問服務的需求。不曉得為什麼OpenShift 要將Kubernetes

理解OpenShift（2）：網路之 DNS（域名服務）

理解OpenShift（1）：網路之 Router 和 Route 理解OpenShift（2）：網路之 DNS（域名服務）   OpenShift 叢集中，至少有三個地方需要用到 DNS： 一是Pod 中的應用通過域名訪問外網的時候，需要DNS來解析外網的域名 二是在叢集內部（p

理解OpenShift（3）：網路之 SDN

理解OpenShift（1）：網路之 Router 和 Route 理解OpenShift（2）：網路之 DNS（域名服務） 理解OpenShift（3）：網路之 SDN   1. 概況 OpenShift SDN 實現了符合Kubernetes CNI 要求的 OpenShift

深入理解Plasma（1）：Plasma 框架

這一系列文章將圍繞以太坊的二層擴容框架，介紹其基本執行原理，具體操作細節，安全性討論以及未來研究方向等。本篇文章作為開篇，主要目的是理解 Plasma 框架。 Plasma 作為以太坊的二層擴容框架，自從 2017 年被 Joseph Poon（Lightning N

理解Docker（1）：Docker 安裝和基礎用法

來源：https://www.cnblogs.com/sammyliu/p/5875470.html 1. 安裝 1.1 在 Ubuntu 14.04 上安裝 Docker 前提要求： 核心版本必須是3.10或者以上 依次執行下面的步驟： sudo apt-g

理解OpenShift（4）：使用者及許可權管理

理解OpenShift（1）：網路之 Router 和 Route 理解OpenShift（2）：網路之 DNS（域名服務） 理解OpenShift（3）：網路之 SDN 理解OpenShift（4）：使用者及許可權管理   OpenShift 支援 RBAC（Role Based Acc

理解OpenShift（6）：集中式日誌處理

  理解OpenShift（1）：網路之 Router 和 Route 理解OpenShift（2）：網路之 DNS（域名服務） 理解OpenShift（3）：網路之 SDN 理解OpenShift（4）：使用者及許可權管理 理解OpenShift（5）：從 Docker Volume 到

PTA 資料結構題目（1）：最大子列和問題（分而治之、線上處理演算法）

題目來源： 問題描述： 問題分析： 對於一般的問題，原始解 都能通過一種 蠻力演算法，即窮舉法的思想得到。這題也不例外。 如果我們，把輸入的陣列，所有的子列都歷遍，並從中找出最大，即可得出我們的演算法。也就是版本一。 學習要點： 1、如何

理解 OpenStack 高可用（HA）（1）：OpenStack 高可用和災備方案 [OpenStack HA and DR]

本系列會分析OpenStack 的高可用性（HA）概念和解決方案： 1. 基礎知識 1.1 高可用 （High Availability，簡稱 HA）     高可用性是指提供在本地系統單個元件故障情況下，能繼續訪問應用的能力，無論這個故障是業務流程、物理設施、IT軟/硬體的

Nginx專題（1）：Nginx之反向代理及配置

摘要：本文從Nginx的概念出發，分別從反向代理的概念、優勢、配置程式碼3個方面介紹了Nginx的特性之一反向代理。 文章來源：宜信技術學院 & 宜信支付結算團隊技術分享第一期-宜信支付結算八方資料團隊高階技術經理 周恆《Nginx的細枝末節》 分享者：宜信支付結算八方資料團隊高階技術經理 周恆 原

ActiveMQ（18）：Message之延遲和定時消息投遞

jms activemq 延遲和定時消息投遞 一、簡介延遲和定時消息投遞（Delay and Schedule Message Delivery） 有時候我們不希望消息馬上被broker投遞出去，而是想要消息60秒以後發給消費者，或者我們想讓消息沒隔 一定時間投遞一次，一共投遞指定的次數。。。

C++學習（1）：最大子段和（多種解法）

多少 問題： code namespace 數據 組成 amp using () 問題：給定由n個數（可能為負數）組成的序列a1,a2,a3,...,an,求該序列子段和的最大值。 第一種解法：（最容易考慮的方法，將所有的子段一一相加，然後比較） 1 #include&

基礎知識概念（1）：Socket 長連線和短連線的概念

1.短連線 連線->傳輸資料->關閉連線     HTTP是無狀態的，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，但任務結束後就中斷連線。短連線是指SOCKET建立連線後 ，傳送後或接收完資料後，就馬上斷開連線。 2.長連線

多執行緒（1）：繼承Thread類和實現Runnable介面

多執行緒的兩種實現方法： 1.繼承Thread類     繼承Thread類，重寫run()方法。建立多執行緒的時候，需要建立物件例項，然後呼叫start()方法。類物件的屬性屬於執行緒私有，執行緒之間互不影響。 public class ClassExtendT

機器學習儲備（1）：協方差和相關係數

為了深刻理解機器學習演算法的原理，首先得掌握其中涉及到的一些基本概念和理論，比如概率，期望，標準差，方差。在這些基本概念上，又衍生出了很多重要概念，比如協方差，相關係數等。今天我們就來聊聊這些組成機器學習的基本概念。 1、概率 概率 P 是對隨機事件發生的可能性的度量。 例如，小明在期末

理解JVM（六）：執行緒安全和鎖優化

執行緒安全的實現方法 互斥同步 互斥是因，同步是果；互斥是方法，同步是目的。 synchronized關鍵字 synchronized關鍵字是基本的互斥同步手段。它在編譯後會在同步程式碼塊前後加入2條位元組碼指令：monitorenter和mo

gdb除錯（1）：單步執行和跟蹤函式呼叫

轉發自：http://songjinshan.com/akabook/zh/gdb.html#id1看下面的程式： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18#include <stdio.h> in

Kubernetes部署（十）：儲存之glusterfs和heketi部署

概觀 本指南支援在Kubernetes叢集中整合，部署和管理GlusterFS容器化儲存節點。這使Kubernetes管理員能夠為其使用者提供可靠的共享儲存。 包括設定指南、其中包含一個示例伺服器pod，它使用動態配置的GlusterFS捲進行儲存。對於那些希望測試或瞭解有關此主題的更多資訊的人，請按照主

排序演算法（1）：簡單選擇排序和堆排序

1.簡單選擇排序 （1）本質：每一趟從給定待排序序列A[ 1......n ] ，選擇出第i小元素，並和A[i]交換。 程式碼： /************************************************* 演算法：簡單選擇排序(升序) 時間