分類: 3C資訊

  • 三、netcore跨平台之 Linux配置nginx負載均衡

    三、netcore跨平台之 Linux配置nginx負載均衡

    前面兩章講了netcore在linux上部署以及配置nginx,並讓nginx代理webapi。

    這一章主要講如何配置負載均衡,有些步驟在前兩章講的很詳細了,所以這一章我就不會一個個截圖了。

    因為本人只有一個服務器。所以我會在同一台服務器上部署兩套差不多的實例。

    同樣的代碼,我們在Program.cs進行了修改,如圖所示:

    這裏我把原來的端口6666改成了8888

     

     然後你可以改一改你的接口部分的代碼,便於讓你更好的看到效果。

    這裏把value1和value2改成value3和value4,這裡是為了看到測試效果,在實際的開發中這裏不用改。

     

     然後發布和上傳到服務器,如何發布和上傳,我在第一章有講到:https://www.cnblogs.com/dengbo/p/11878766.html

    注意的是你同樣的地方新建一個新的目錄保存你新上傳的程序,netcore是我第一章建立的,netcore1是新建的,

    你把你新的發布包放在netcore即可。如圖:

    上傳結束后,在這個目錄中運行你的程序,輸入下面的命令

    dotnet WebApiTest.dll   --server.urls "http://*:8888"

    如圖所示

     

     然後去看看你的接口是否正常

     

     

    好了,這裏的準備工作完成了,下面我們進入到nginx的配置的目錄中

    輸入下面的命令:

    cd /usr/local/nginx/conf

    然後對文件進行編輯

    vim nginx.conf

     

     我們需要在這裏修改一下配置。

    在如圖的server的平級添加如下的代碼

    upstream NgWebApi {
                    server localhost:6666;
                    server localhost:8888;
        }

    上面的 NgWebApi是隨意寫的名稱,不要糾結這裏。

    然後在修改 proxy_pass後面的內容:

    proxy_pass http://NgWebApi;

    最終的結果如下:

     

     這樣你就修改完成,輸入:wq退出並保存即可。

    最後檢查並重啟nginx

    /usr/local/nginx/sbin/nginx -t
    /usr/local/nginx/sbin/nginx -s reload

    最後不要忘記把你的8888端口的webapi啟動一下。

    這裏我務必要提醒你,請進入到你的程序的目錄中執行這段代碼,

    cd /root/netcore1
    dotnet WebApiTest.dll   --server.urls "http://*:8888"

    啟動如下:

     

     

     好了,配置結束了,下面我們來測試下

     

    還是昨天的那個網站進行測試   https://www.sojson.com/httpRequest/

     

     

     

    多次發送請求會出現下面的響應

     

     

    看到上面兩個請求,就說明你配置成功了,是不是很簡單。

    上面這種配置,系統會採用默認的輪詢訪問不同的端口,nginx作為強大的反向代理,強大的遠遠不止這裏

    下面簡單講講分發策略。

    1)、輪詢 ——輪流處理請求(這是系統默認的)

          每個請求按時間順序逐一分配到不同的應用服務器,如果應用服務器down掉,自動剔除它,剩下的繼續輪詢,如果您的服務器都差不多,建議這個。 

    2)、權重 ——誰的設置的大,誰就承擔大部分的請求

          通過配置權重,指定輪詢幾率,權重和訪問比率成正比,用於應用服務器性能不均的情況,有時候你買的服務器可能參差不齊,有的性能強大

        有的一般,你可以通過設置權重,把服務器性能強大權重設置大一點,這樣可以合理分配壓力。 

    3)ip_哈希算法

          每一次的請求按訪問iphash結果分配,這樣每個訪客固定訪問一個應用服務器,可以解決session共享的問題。

     

     

    關於權重的策略,如下圖示的 你只要加一個  weight=6 即可這裏不一定是6,是整數都行。

     

     

     然後保存即可

    這裏不要忘記重啟nginx,以及運行8888端口的程序了,如果你不會,可以看前面的部分

    最後我們看看效果

    結果和上面的測試結果差不多,唯一不同的是出現下面這個結果的次數要大於另外一個的。

     

     

    到這裏就結束了,感謝觀看。

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

    ※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

    ※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

    ※專營大陸快遞台灣服務

    台灣快遞大陸的貨運公司有哪些呢?

  • 利用SSH隧道技術穿越內網訪問遠程設備

    利用SSH隧道技術穿越內網訪問遠程設備

    本文為作者原創,轉載請註明出處:

    通常,我們用於調試的計算機無法遠程訪問位於局域網中的待調試設備。通過 ssh 的端口轉發(又稱 ssh 隧道)技術,可以實現這種遠程調試功能。

    下文中,sshc 指 ssh 客戶端,sshd 指 ssh 服務器。

    1. ssh 端口轉發模式簡介

    ssh 客戶端運行於本地機器,它的作用是:登錄到目標機器並在目標機器上執行命令。它可以建立一個安全通道,為不安全網絡上兩個不受信任的主機提供安全的加密通信。X11 連接、任意 TCP 端口和 UNIX 域套接字也可以通過 ssh 安全通道進行轉發。

    ssh 連接並登錄到指定的主機名(用戶名可選)。如果指定了命令,命令將在遠程主機上執行,而不是在本機 shell 里執行。

    1.1 ssh 常用選項簡介

    ssh 端口轉發相關的常用選項如下:

    -C

    請求壓縮所有數據(包括 stdin、stdout、stderr 和用於轉發的 X11、TCP 和 UNIX 域連接的數據)。壓縮算法與 gzip 使用的算法相同,壓縮級別由 ssh 協議版本 1 的 CompressionLevel 選項控制。在調製解調器線路和其他慢速連接上採用壓縮是可取的,但它會減慢快速網絡上的速度。

    -f

    請求 ssh 在執行命令之前轉到後台。如果用戶希望 ssh 在後台運行,但 ssh 需要用戶提供密碼或口令,使用 -f 選項就很有用,在用戶輸入密碼之後,ssh 就會轉入後台運行。這個選項隱含了 -n 選項的功能(-n 選項將 stdin 重定向到 /dev/null,從而避免後台進程讀 stdin)。在遠程站點上啟動 X11 程序的推薦方法是使用 “ssh -f host xterm” 。

    如果 ExitOnForwardFailure 配置選項設置的是 “yes”,則使用 -f 選項啟動的 ssh 客戶端會等所有的遠程端口轉發建立成功后才將自己轉到後台運行。

    -n

    將 stdin 重定向到 /dev/null (實際上是為了防止後台進程從stdin讀取數據)。當 ssh 在後台運行時必須使用此選項。

    一個常見的技巧是使用它在目標機器上運行 X11 程序。例如,ssh -n shadow.cs.hut.fi emacs & 將在 shadows.cs.hut.fi 上啟動 emacs 程序。X11 的連接將通過加密通道自動轉發。ssh 程序將在後台運行。(如果 ssh 需要請求密碼或口令,則此操作無效;參見-f選項。)

    -N

    不執行遠程命令。此選項用於只需要端口轉發功能時。

    -g

    允許遠程主機連接到本地轉發端口。如果用於多路復用連接,則必須在主進程上指定此選項。

    -t

    強制分配一個偽終端。在目標機上執行任意的基於屏幕的程序時(例如,實現菜單服務),分配偽終端很有用。使用多個 -t 選項則會強制分配終端,即使 ssh 沒有本地終端。

    -T

    禁止分配偽終端。

    -L [bind_address:]port:host:hostport
    -L [bind_address:]port:remote_socket
    -L local_socket:host:hostport
    -L local_socket:remote_socket

    數據從本機轉發到遠程。本機上指定 TCP 端口或 UNIX 套接字的連接將被轉發到目標機上指定端口或套接字。

    上述參數中,bind_address 指本地地址;port 指本地端口;local_socket 指本地 UNIX 套接字;host 指遠程主機地址;hostport 指遠程端口;remote_socket 指遠程 UNIX 套接字。

    本地(ssh 客戶端)與遠程(ssh 服務端)建立一條連接,此連接的形式有四種:

    本地 [bind_address:]port    <====>   遠程 host:hostport  
    本地 [bind_address:]port    <====>   遠程 remote_socket  
    本地 local_socket           <====>   遠程 host:hostport  
    本地 local_socket           <====>   遠程 remote_socket  

    位於本機的 ssh 客戶端會分配一個套接字來監聽本地 TCP 端口(port),此套接字可綁定本機地址(bind_address, 可選,本機不同網卡具有不同的 IP 地址)或本地 UNIX 套接字(local_socket)。每當一個連接建立於本地端口或本地套接字時,此連接就會通過安全通道進行轉發。

    也可在配置文件中設置端口轉發功能。只有超級用戶可以轉發特權端口。

    默認情況下,本地端口是根據 GatewayPorts 設置選項綁定的。但是,使用顯式的bind_address 可將連接綁定到指定地址。bind_address 值是 “localhost”時,表示僅監聽本機內部數據[TODO: 待驗證],值為空或“*”時,表示監聽本機所有網卡的監聽端口。

    注意:localhost 是個域名,不是地址,它可以被配置為任意的 IP 地址,不過通常情況下都指向 127.0.0.1(ipv4)和 。127.0.0.1 這個地址通常分配給 loopback 接口。loopback 是一個特殊的網絡接口(可理解成虛擬網卡),用於本機中各個應用之間的網絡交互。

    GatewayPorts 說明 (查閱 man sshd_config):指定是否允許遠程主機(ssh客戶端)連接到本機(ssh服務端)轉發端口。默認情況下,sshd(8)將遠程端口轉發綁定到環回地址,這將阻止其他遠程主機連接到本機轉發端口。GatewayPorts 也可設置為將將遠程端口轉發綁定到非環回地址,從而允許其他遠程主機連接到本機。GatewayPorts 值“no”,表示強制遠程端口轉發僅對本機可用;值“yes”,表示強制遠程端口轉發綁定到通配符地址;值“clientspecified”,表示允許客戶端選擇轉發綁定到的地址。默認是“no”。

    -R [bind_address:]port:host:hostport
    -R [bind_address:]port:local_socket
    -R remote_socket:host:hostport
    -R remote_socket:local_socket

    此選項在本地機上執行,目標機上指定 TCP 端口或 UNIX 套接字的連接將被轉發到本機上指定端口或套接字。

    上述參數中,bind_address 指遠程地址;port 指遠程端口;remote_socket 指遠程 UNIX 套接字;host 指本地地址;hostport 指本地端口;local_socket 指本地 UNIX 套接字。

    工作原理:位於遠程的 ssh 服務端會分配一個套接字來監聽 TCP 端口或 UNIX 套接字。當目標機(服務端)上有新的連接建立時,此連接會通過安全通道進行轉發,本地機執行當前命令的進程收到此轉發的連接后,會在本機內部新建一條 ssh 連接,連接到當前選項中指定的端口或套接字。參 2.3 節分析。

    也可在配置文件中設置端口轉發功能。只有超級用戶可以轉發特權端口。

    默認情況下,目標機(服務端)上的 TCP 監聽套接字只綁定迴環接口。也可將目標機上的監聽套接字綁定指定的 bind_address 地址。bind_address 值為空或 “*” 時,表示目標機上的監聽套接字會監聽目標機上的所有網絡接口。僅當目標機上 GatewayPorts 設置選項使能時,通過此選項為目標機指定 bind_address 才能綁定成功(參考 sshd_config(5))。

    如果 port 參數是 ‘0’,目標機(服務端)可在運行時動態分配監聽端口並通知本地機(客戶端),如果同時指定了 “-O forward” 選項,則動態分配的監聽端口會被打印在標準輸出上。

    -D [bind_address:]port

    指定本地“動態”應用程序級端口轉發。它的工作方式是分配一個套接字來監聽本地端口(可選綁定指定的 bind_address)。每當連接到此端口時,連接都通過安全通道進行轉發,然後使用應用程序協議確定將遠程計算機連接到何處。目前支持 SOCKS4 和 SOCKS5 協議,ssh 將充當 SOCKS 服務器。只有 root 用戶可以轉發特權端口。還可以在配置文件中指定動態端口轉發。

    IPv6 地址可以通過將地址括在方括號中來指定。只有超級用戶可以轉發特權端口。默認情況下,本地端口是根據 GatewayPorts 設置選項進行綁定的。但是,可以使用顯式的 bind_address 將連接綁定到特定的地址。bind_address 值為 “localhost” 時表示監聽端口僅綁定為本地使用,而空地址或 “*” 表示監聽所有網絡接口的此端口。

    1.2 ssh 端口轉發模式

    ssh 的端口轉發有三種模式:

    • 本地:ssh -C -f -N -g -L local_listen_port:remote_host:remote_port agent_user@agent_host

      將本地機監聽端口 local_listen_port 上的數據轉發到遠程端口 remote_host:remote_port

    • 遠程:ssh -C -f -N -g -R agent_listen_port:local_host:local_port agent_user@agent_host

      將代理機監聽端口 agent_listen_port 上的數據轉發到本地端口 local_host:local_port

    • 動態:ssh -C -f -N -g -D listen_port agent_user@agent_host

    2. 利用 ssh 隧道建立遠程調試環境

    組網環境下設備角色如下:

    代理機:把一個具有公網 IP 的中間服務器用作 ssh 代理,將這台代理機稱作代理 A(Agent)。

    目標機:把待調試的目標機器稱作目標機 T(Target)。目標機通常是待調試的設備,處於局域網內,外網無法直接訪問內網中的設備。

    本地機:把調試用的本地計算機稱作本地機 L(Local)。本地機通常也位於局域網內。

    L 和 T 無法互相訪問,但 L 和 T 都能訪問 A。我們將 T 通過 ssh 連接到A,將 L 也通過 ssh 連接到A,A 用於轉發數據,這樣就能使用本地計算機 L 來訪問遠端設備 R。

    2.1 目標機 T (sshc)

    2.1.1 shell 中 T 連接 A

    目標機 T 上的 sshc 連接代理機 A 上的 sshd:

    ssh -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126

    這條命令的作用:
    1. 建立一條 ssh 連接,T 上的 ssh 客戶端連接到 A 上的 ssh 服務器,A 的 IP 是 120.198.45.126,端口號是 10022,賬號是10022;
    2. 如果有其他 ssh 客戶端連接到了 A 的 10022 端口上,則 A 會將這條連接轉發到 T,T 在內部建立新的連接,連接到本機 22 端口。

    這條命令在 T 上執行。在 T 連接 A 這條命令里,T 是本地主機(local),A 是遠程主機(remote)。

    解釋一下此命令各選項:

    • -T 不分配偽終端;
    • -f 使 ssh 進程在用戶輸入密碼之後轉入後台運行;
    • -N 不執行遠程指令,即遠程主機(代理機A)不需執行指令,只作端口轉發;
    • -g 允許遠程主機(代理機A)連接到本地轉發端口;
    • -R 將遠程主機(代理機A)指定端口上的連接轉發到本機端口;
    • frank@120.198.45.126
      表示使用遠程主機 120.198.45.126 上的用戶 frank 來連接遠程主機;
    • :10022:127.0.0.1:22
      表示本機迴環接口(127.0.0.1,也可使用本機其他網絡接口的地址,比如以太網 IP 或 WiFi IP)的 22 端口連接到遠程主機的 10022 接口,因遠程主機 10022 綁定的地址為空,所以遠程主機會監聽其所有網絡接口的 10022 端口。

    在目標機 shell 中查看連接是否建立:

    root@localhost:~# ps | grep ssh
    22850 root      2492 S    ssh -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    22894 root      3500 S    grep ssh

    在目標機 shell 中關閉 ssh 連接:

    kill -9 $(pidof ssh)

    此時在目標機 T 和代理機 A 中查看 ssh 連接信息,兩端都可以看到 ssh 連接不存在了。

    2.1.2 C 代碼中 T 連接 A 的處理

    C 代碼中主要還是調用 2.1.1 節中的命令。但是由 C 代碼編譯生成的進程無法在命令行和用戶進行交互,因此要避免交互問題。

    1. 避免首次連接時的 y/n(或yes/no) 詢問

    如果是首次登錄代理機 A,本機(目標機 T)沒有 A 的信息,需用用戶手動輸入 y 之後才能繼續。打印如下:

    root@localhost:~# ssh -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    
    Host '120.198.45.126' is not in the trusted hosts file.
    (ssh-rsa fingerprint md5 86:09:0c:1b:fd:0b:02:8c:29:62:7f:ff:70:1b:64:f5)
    Do you want to continue connecting? (y/n) 

    如果 T 上有 A 的信息,可通過執行刪除操作:rm ~/.ssh/known_hosts 再進行上述測試。

    如果是在 C 代碼中執行登錄命令,進程在後台自動運行,是無法和用戶進行交互的。為了避免交互動作,應該禁止 ssh 發出 y/n 的詢問。

    如果 ssh 客戶端是 dropbear ssh,則添加 -y 參數,如下:

    ssh -y -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126

    如果 ssh 客戶端是 openssh,則添加 -o StrictHostKeyChecking=no 選項,如下:

    ssh -o "StrictHostKeyChecking no" -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126

    2. 避免輸入登錄密碼

    避免由用戶手動輸入登錄密碼有如下方法:

    1) 用 ssh-copy-id 把本地主機的公鑰複製到遠程主機的authorized_keys文件上,登錄不需要輸入密碼。
    2) 用 expect 調用 shell 腳本,向 shell 腳本發送密碼。這種方式是模擬鍵盤輸入。
    3) 如果是 openssh,則用 sshpass 向 ssh 命令行傳遞密碼。如果是 dropbear,則通過 DROPBEAR_PASSWORD 環境變量向 ssh 命令行傳遞密碼。

    我們採用第 3 種方法。

    假如代理機 A 上用戶 frank 密碼是 123456,則最終 C 代碼里應執行的指令如下:

    # openssh
    sshpass -p '123456' ssh -o "StrictHostKeyChecking no" -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    
    # dropbear
    DROPBEAR_PASSWORD='123456' ssh -y -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126

    dropbear 無法接收 DROPBEAR_PASSWORD 變量傳遞密碼的處理方法:

    dropbear 包含 ssh 客戶端和 ssh 服務器,體積小巧,常用於嵌入式設備。dropbear ssh 無法接收 sshpass 傳入的密碼信息。但 dropbear ssh 可以通過環境變量 DROPBEAR_PASSWORD 傳入密碼信息。openwrt 從某一版開始,通過打補丁的方式禁用了 DROPBEAR_PASSWORD 選項,我們可以找到對應的補丁,開啟 DROPBEAR_PASSWORD 選項,再重新編譯生成 dropbear。如下:

    修改 dropbear patch 文件(如下路徑位於 openwrt 源碼根目錄):

    vim package/network/services/dropbear/patches/120-openwrt_options.patch

    將如下幾行刪除:

    @@ -226,7 +226,7 @@ much traffic. */
      * note that it will be provided for all "hidden" client-interactive
      * style prompts - if you want something more sophisticated, use 
      * SSH_ASKPASS instead. Comment out this var to remove this functionality.*/
    -#define DROPBEAR_PASSWORD_ENV "DROPBEAR_PASSWORD"
    +/*#define DROPBEAR_PASSWORD_ENV "DROPBEAR_PASSWORD"*/
     
     /* Define this (as well as ENABLE_CLI_PASSWORD_AUTH) to allow the use of
      * a helper program for the ssh client. The helper program should be

    重新編譯生成 dropbear,並替換設備里已安裝的 dropbear。

    #define DEFAULT_SSH_AGENT_HOST      "120.198.45.126"
    #define DEFAULT_SSH_AGENT_PORT      "10022"
    #define DEFAULT_SSH_AGENT_USER      "ssha_debug"
    #define DEFAULT_SSH_AGENT_PASSWD    "220011ssha"
    int login_to_ssh_agent(const char *host, const char *port, const char *user, const char *passwd)
    {
        // openssh client:
        // sshpass -p '123456' ssh -o "StrictHostKeyChecking no" -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    
        // dropbear ssh clent:
        // DROPBEAR_PASSWORD='123456' ssh -y -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    
        char cmd[256];
        snprintf(cmd, sizeof(cmd), "DROPBEAR_PASSWORD='%s' ssh -y -T -f -N -g -R :%s:127.0.0.1:22 %s@%s", 
                 (passwd != NULL) ? passwd : DEFAULT_SSH_AGENT_PASSWD, 
                 (port != NULL) ? port : DEFAULT_SSH_AGENT_PORT,
                 (user != NULL) ? user : DEFAULT_SSH_AGENT_USER,
                 (host != NULL) ? host : DEFAULT_SSH_AGENT_HOST);
        printf("login to ssh agent: \n%s\n", cmd);
        system(cmd);
    
        return 0;
    }

    2.2 代理機 A (sshd)

    在 /etc/ssh/sshd_config 中添加如下幾行后重啟 ssh 服務:

    GatewayPorts yes
    UseDNS no
    GSSAPIAuthentication no

    目標機 T 發起連接后,在代理機 A 上查詢目標機 T 是否連接成功:

    sudo netstat -anp | grep 10022

    打印形如:

    tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      8264/sshd: frank
    tcp6       0      0 :::10022                :::*                    LISTEN      8264/sshd: frank

    上述打印中,8264 就是和目標機 T 保持連接的 sshd 進程號,如需關閉當前連接重新建立一個新的連接,則先在代理機 A 上執行:

    kill -9 8264

    然後再執行 2.1 節的指令,就會建立一次新的代理連接。

    為了安全,我們可以專門新建一個用戶,僅用於 ssh 端口轉發功能,不能在 shell 中使用此用戶登錄。如下創建一個 ssha_debug 的用戶,無 shell 登錄權限。然後為此用戶創建密碼。注意系統中 nologin 文件的位置,不同系統可能路徑不同。

    sudo useradd ssha_debug -M -s /usr/sbin/nologin
    sudo passwd ssha_debug

    2.3 本地機 L (sshc)

    2.3.1 本地機 L 登錄目標機 T

    有三種方式:

    1. 在本地機 L 上通過 ssh 登錄代理機 A,在 A 的 shell 中再登錄目標機 T

    代理服務器的公網 ip 是 120.198.45.126,內網 ip 是 192.168.1.102。

    1) 先使用 ssh(SecureCRT 或 OpenSSH 命令行) 登錄上代理服務器的 shell。如果調試機在內網,既可登錄代理機的外網 ip,也可登錄其內網 ip。

    2) 在代理機的 shell 中執行如下命令登錄遠程設備:

    ssh -p 10022 root@127.0.0.1 -vvv

    注意,此命令中用戶 root 及其密碼是遠程設備上的賬戶。

    如果提示 Host key 認證失敗之類的信息,請按提示執行如下命令:

    ssh-keygen -f "/home/frank/.ssh/known_hosts" -R [127.0.0.1]:10022

    也可直接刪除當前用戶目錄下的 .ssh/known_hosts 文件。
    然後重新執行登錄設備操作。

    建議優先使用此方法。

    2. 在本地機 L 上使用 ssh 命令登錄目標機 T

    Win 10 系統默認安裝有 OpenSSH 客戶端。可以在調試機 Windows 命令行中執行:

    ssh -p 10022 root@120.198.45.126 -vvv

    對於本地計算機來說,待調試的設備 ip 地址不可見。本機登錄到代理機 120.198.45.126 的轉發端口 10022,通過代理機轉發功能,本地機能成功登錄到遠程設備上。注意,此命令中用戶 root 及其密碼是設備上的賬戶,不是 SSH 代理服務器上的賬戶。

    如果出現認證失敗之類的信息。可刪除 C:/Users/當前用戶/.ssh/known_hosts 文件,然後再試。

    3. 在本地機 L 上使用 SecureCRT 工具登錄目標機 T

    也可以直接使用 SecureCRT 軟件,設置好代理機的 ip(120.198.45.126) 和端口號(10022),填上設備的登錄用戶和登錄密碼。

    不建議使用此方法。因為連接過程太長或連接失敗的話,無法看到錯誤提示信息。

    2.3.2 查看代理機 A 打印信息

    在 L 執行登錄 T 之前查看打印信息:

    frank@SERVER:~$ sudo netstat -anp  | grep 10022
    tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      106438/sshd: frank
    tcp6       0      0 :::10022                :::*                    LISTEN      106438/sshd: frank

    在 L 執行登錄 T 之後查看打印信息:

    frank@SERVER:~$ sudo netstat -anp  | grep 10022
    tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      106438/sshd: frank
    tcp        0      0 192.168.1.102:10022     120.229.163.51:27027    ESTABLISHED 106438/sshd: frank
    tcp6       0      0 :::10022                :::*                    LISTEN      106438/sshd: frank

    可以看到,上述第二行是 L 執行登錄命令后新出現的打印信息。表示新建立了一條 L 到 A 的 ssh 連接。

    L 端的外網地址 120.229.163.51:27027 連接到 A 上的 192.168.1.102:10022,L 通常位於局域網內、具有一個內網地址,120.229.163.51 可能是 L 連接的路由器的公網 IP。

    這條連接建立后,A 將這條連接轉發到 R。

    2.3.3 查看目標機 T 打印信息

    在 L 執行登錄 T 之前查看打印信息:

    root@localhost:~# netstat -anp | grep 22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      917/sshd
    tcp        0      0 192.168.202.140:47989   120.198.45.126:22       ESTABLISHED 9452/ssh
    tcp        0      0 192.168.202.140:22      192.168.202.100:64737   ESTABLISHED 2041/sshd
    tcp        0      0 :::22                   :::*                    LISTEN      917/sshd

    在 L 執行登錄 T 之後查看打印信息:

    root@localhost:~# netstat -anp | grep 22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      917/sshd
    tcp        0      0 192.168.202.140:47989   120.198.45.126:22       ESTABLISHED 9452/ssh
    tcp        0      0 192.168.202.140:51732   192.168.202.140:22      ESTABLISHED 9452/ssh
    tcp        0      0 192.168.202.140:22      192.168.202.140:51732   ESTABLISHED 9579/sshd
    tcp        0      0 :::22                   :::*                    LISTEN      917/sshd

    可以看到,上述第 3 行和第 4 行是登錄之後新增加的打印信息。

    第 2 行,表示 T 上的 ssh 客戶端連接到了 A 上的 ssh 服務端,進程號是 9452。第 3 行,表示進程 9452 收到了 A 轉發來的 ssh 連接后,在本機內部建立新的 ssh 連接,使用 51732 端口號作為 ssh 客戶端,連接到本機 22 端口,22 端口是 sshd 端口。第 4 行,表示本機新啟動一個 sshd 進程,來接收 sshc 的連接。

    這樣,L 到 T 的 ssh 通路徹底打通了。A 將來自 L 的連接轉發到 R,R 在內部啟動了 sshd 來處理來自 L 的請求,通過 A 的代理作用,實現了 L 上的 sshc 和 T 上的 sshd 的交互。

    3. 典型使用場景步驟總結

    上文已涵蓋詳細使用方法,但篇幅太長。此處簡單總結使用步驟如下:

    3.1 在代理機 A 上執行

    使用 SecureCRT 登錄代理機 A。代理機外網 ip 120.198.45.126,內網 ip 192.168.1.102,端口 22。如果本地機與代理機在同一個局域網裡,使用代理機的內網 ip 登錄即可。

    在代理機 shell 中查看是否有未關閉的 ssh 隧道:

    sudo netstat -anp | grep 10022

    若打印形如:

    tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      8264/sshd: frank
    tcp6       0      0 :::10022                :::*                    LISTEN      8264/sshd: frank

    則表示有未關閉的 ssh 隧道連接。執行如下命令可關閉連接。

    kill -9 8264

    3.2 在目標機 T 上執行

    使用遠程應用程序接口或者在遠程設備 T 上做一些特殊操作,觸發 T 執行如下兩條指令之一:

    # openssh
    sshpass -p '123456' ssh -y -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126
    
    # dropbear
    DROPBEAR_PASSWORD='123456' ssh -y -T -f -N -g -R :10022:127.0.0.1:22 frank@120.198.45.126

    3.3 在本地機 L 上執行

    在本地機 L 上執行如下指令,登錄遠程目標機 T:

    ssh -vvv -p 10022 root@120.198.45.126

    另外一種變通的方式是,在本地機先通過 ssh 登錄上代理機 A 的 shell。然後在 A 的 shell 中執行如下指令:

    ssh -vvv -p 10022 root@127.0.0.1

    4. 注意事項

    1. 確保代理機 A 所在的網絡防火牆不屏蔽 10022 端口
    2. 確保代理機 A 上 /etc/ssh/sshd_config 配置文件設置正確
    3. 關閉 ssh 隧道既可在代理機 A 上進行(關閉相應的 sshd 進程),也可在目標機 T 上進行(關閉相應的 ssh 進程)
    4. 每次只能訪問一台目標機。如果想同時訪問多台,可以代理機上設置多個轉發端口,每條連接使用一個端口進行轉發
    5. 為保證安全,打開 ssh 隧道時盡量使用無登錄權限的用戶,並且此用戶的密碼建議經常更新

    5. 參考資料

    [1] 阮一峰,
    [2]
    [3]

    6. 修改記錄

    2019-11-20 V1.0 初稿

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

    ※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

    ※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

    台灣海運大陸貨務運送流程

    兩岸物流進出口一站式服務

  • Zabbix-(五)監控Docker容器與自定義jvm監控項

    Zabbix-(五)監控Docker容器與自定義jvm監控項

    Zabbix-(五)監控Docker容器與自定義jvm監控項

    一.前言

    前文中講述了Zabbix對服務器硬件方面的監控功能,本文將講述利用Zabbix監控Docker容器中的Java Web服務,並通過自定義監控項,監控JVM老年代使用情況以及GC信息。Zabbix其實提供了,自帶了JMX模板能夠直接監控JVM信息,本文主要側重於自定義參數與自定義監控項,關於JMX會在之後的文章中介紹。

    準備

    • Zabbix Server (Zabbix 4.4) (ip:192.168.152.140)
    • 運行Java應用的主機 以下簡稱Server-A (已被Zabbix監控) (ip:192.168.152.142)

    二.開啟agent用戶自定義參數配置

    1. 修改配置

      使用自定義參數時,首先需要修改Server-A的agent配置

      # vim /etc/zabbix/zabbix_agentd.conf

      修改配置 UnsafeUserParameters=1

      UnsafeUserParameters=1
    2. 重啟zabbix-agent

      # systemctl restart zabbix-agent

    三.運行tomcat容器

    在Server-A運行tomcat容器

    # docker run --name tomcat -p 8080:8080 -dit tomcat:jdk8-adoptopenjdk-hotspot

    將zabbix賬號添加到docker組。參考

    # sudo gpasswd  -a zabbix docker

    外部訪問測試一下

    四.創建自定義Docker模板

    我們可以定義一個比較通用的Docker模板,有服務需要被監控時,直接鏈接該模板即可。

    1. 創建群組

      點擊【配置】-【主機群組】-【創建主機群組】

      定義一個組名 Docker Group

      配置項
      * 組名 Docker Group
    2. 創建模板

      創建一個自定義模板,模板名稱Docker Template,選擇上步驟創建的Docker Group群組

      配置項
      * 模板名稱 Docker Template
      * 群組 Docker Group

    五.編寫腳本與自定義監控參數

    我們需要編寫一個腳本,用於發現當前正在運行的docker容器(這裏使用容器名稱)。

    1. 在Server-A編寫發現運行容器的python腳本

      創建腳本

      # cd /data/zabbix
      # touch find_container.py
      # chmod a+x find_container.py
      # vim find_container.py

      腳本內容:

      #!/usr/bin/env python
      import os
      import json
      
      # 查看當前運行的docker容器
      t=os.popen(""" docker ps  |grep -v 'CONTAINER ID'|awk {'print $NF'} """)
      container_name = []
      for container in  t.readlines():
              r = os.path.basename(container.strip())
              container_name += [{'{#CONTAINERNAME}':r}]
      # 轉換成json數據
      print json.dumps({'data':container_name},sort_keys=True,indent=4,separators=(',',':'))

      運行腳本,查看一下json數據格式:

      {
          "data":[
              {
                  "{#CONTAINERNAME}":"tomcat"
              }
          ]
      }
    2. 在Server-A自定義容器發現參數

      我們需要自定義一個鍵值對的配置類型,以便Zabbix可以通過鍵讀取到值。

      增加自定義參數

      # cd /etc/zabbix/zabbix_agentd.d
      # vim userparameter_find_container.conf
      docker.container /data/zabbix/find_container.py (腳本的運行結果)
      UserParameter=docker.container,/data/zabbix/find_container.py
    3. 在Server-A創建查看容器JVM GC情況的腳本

      我們可以使用jstat -gcutil 命令查看GC情況

      創建python腳本

      # cd /data/zabbix
      # touch monitor_gc.py
      # chmod a+x monitor_gc.py
      # vim monitor_gc.py

      腳本內容

      #!/usr/bin/python
      import sys
      import os
      
      def monitor_gc(container_name, keyword):
              cmd = ''' docker exec %s bash -c "jstat -gcutil 1" | grep -v S0 | awk '{print $%s}' ''' %(container_name, keyword)
              value = os.popen(cmd).read().replace("\n","")
              print value
      
      if __name__ == '__main__':
              # 參數1:容器的名稱
              # 參數2:查看第幾列(例如 Eden區在第3列傳入3,Full GC次數在第9列傳入9)
              container_name, keyword = sys.argv[1], sys.argv[2]
              monitor_gc(container_name, keyword)

      測試腳本,查看當前tomcat容器Full GC次數

      # /data/zabbix/monitor_gc.py 'tomcat' '9'

    4. 在Server-A自定義Zabbix JVM GC參數

      同樣,增加一個conf文件,表示自定義參數

      # cd /etc/zabbix/zabbix_agentd.d
      # touch userparameter_gc_status.conf
      # vim userparameter_gc_status.conf
      jvm.gc.status[*] /data/zabbix/monitor_gc.py $1 $2
      UserParameter=jvm.gc.status[*], /data/zabbix/monitor_gc.py $1 $2

      jvm.gc.status[*] 表示可以使用參數。其中$1表示參數1,即容器名稱;$2表示參數2,需要查看哪項GC信息,$1 $2都是通過Zabbix配置時傳遞的。

    5. 在Zabbix server上測試自定義參數

      為zabbix sever安裝zabbix-get

      # yum install -y zabbix-get

      測試自定義參數,如果有權限問題,可以參考

      # zabbix_get -s 192.168.152.142 -p 10050 -k docker.container
      # zabbix_get -s 192.168.152.142 -p 10050 -k "jvm.gc.status['tomcat', 9]"

    六.Zabbix模板增加自動發現規則

    上述配置中,已經可以通過腳本獲取到已運行的容器信息,此步驟將通過Zabbix配置界面,在模板中添加自動發現規則,以發現被監控主機中正在運行的docker容器,並利用這些獲取的數據進一步監控容器中jvm數據。

    1. 創建自動發現規則

      點擊【配置】-【模板】-【Docker Template】

      點擊【自動發現規則】-【創建發現規則】

      先配置【自動發現規則】

      配置項
      * 名稱 發現正在運行的Docker容器規則
      類型 Zabbix 客戶端
      * 鍵值 docker.container (這是我們上述步驟中自定義的鍵值)
      其他配置 根據需要配置

      鍵值配置項是之前

      再配置【過濾器】

      則配置自定義腳本返回json數據中的

      配置項
      {#CONTAINERNAME}
    2. 添加監控項原型

      點擊新建的自動發現規則的【監控項原型】-【創建監控項原型】

      輸入參數

      配置項
      * 名稱 Tomcat Full GC次數監控項
      類型 Zabbix 客戶端
      * 鍵值 jvm.gc.status[{#CONTAINERNAME} , 9]
      其他配置項 根據需要填寫

      鍵值是定義的參數,{#CONTAINERNAME} 是jvm.gc.status的參數1,使用了自動發現規則,發現到的docker容器名稱(本文中即是 tomcat);參數2 9 則是表示需要查看FullGC次數,FGC列(第9列)

      除此之外,還可以添加Old老年代(對應第4列),Full GC時間(對應第10列)等監控項,這裏就不一一添加了,和上述過程基本一致,只需修改參數2即可(也可以利用剛新建的監控項原型進行【克隆】)。

    七.鏈接模板

    將上述鏈接到Server-A主機

    八.DashBoard添加可視化圖形

    回到Zabbix首頁可以為新增的自定義監控項,增加圖形(添加圖形步驟可以參考)

    九.其他

    部署問題

    • zabbix在執行腳本時,是使用的zabbix賬戶,因此可能要注意要給zabbix賬號賦予權限。

      例如,zabbix賬戶無法使用docker命令,將zabbix添加到docker組

      # sudo gpasswd -a zabbix docker
    • zabbix server無法執行agent自定義參數中的腳本

      為agent主機設置

      # setenforce 0

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    小三通海運與一般國際貿易有何不同?

    小三通快遞通關作業有哪些?

  • 數組與鏈表

    數組與鏈表

    前言

    數組和鏈表是兩種數據結構,數組非常簡單易用但是它有兩個非常大的缺點,一個是數組一旦創建無法擴展,另一個則是數組的查找和刪除的速度很慢.

    鏈表改善了一些數組的缺點,但是同樣的鏈表自身也存在一些自己的缺點.

    本篇博客將為大家介紹一下這數組和鏈表特點及各自的優缺點.

    閱讀前的準備工作

    ,一種粗略的評價計算機算法效率的方法.後面的內容會用到表示效率的方法.

    1. 數組

    我們按數組中的數組是否排序對數組進行劃分,將數組分為無序數組和有序數組.無序數組中的數組是無序的,而有序數組中的數據則是升序或者降序排序的.

    1.1 無序數組

    因為無序數組中的數據是無序的,往數組中添加數據時不用進行比較和移動數據,所以往無序數組裡面添加數據很快.無論是添加第一個數據還是第一萬個數據所需的時間是相同的,效率為O(1).

    至於查找和刪除速度就沒有那麼快了,以數組中有一萬個數據項為例,最少需要比較1次,最多則需要比較一萬次,平均下來需要比較5000次,即N/2次比較,N代表數據量,大O表示法中常數可以忽略,所以效率為O(N).

    結論:

    1. 插入很快,因為總是將數據插入到數組的空餘位置.
    2. 查找和刪除很慢,假設數組的長度為N,那麼平均的查找/刪除的比較次數為N/2,並且還需要移動數據.

    1.2 有序數組

    無序數組中存放的數據是無序的,有序數組裡面存放的數據則是有序的(有可能是升序有可能是降序).

    因為有序數組中的數據是按升序/降序排列的,所以插入的時候需要進行排序並且移動數據項,所有有序數組的插入速度比無序數組慢. 效率為O(N).

    刪除速度和無序數組一樣慢 效率為O(N).

    有序數組的查找速度要比無序數組快,這是因為使用了一個叫做二分查找的算法.

    二分查找: 二分查找也稱折半查找(Binary Search),它是一種效率較高的查找方法。但是,折半查找要求線性表必須採用順序存儲結構,而且表中元素按關鍵字有序排列.

    有一個關於二分查找的形象類比 -> 猜數遊戲

    假設要在0-100之間猜一個數,那麼你第一個要猜的数字就是100的一半50的時候,你的朋友會告訴你這個数字比要猜的数字是大還是小,如果比数字大,你接下來要猜的数字就是50的一半25,你的朋友說比這個数字要大,那麼你下面要猜的数字就是25-50中間的那個數37,以此類推…

    使用二分查找可極大的提高查找的效率,假設一個有序數組有十億個數據,那麼查找到所需的数字,最多只需比較30次.

    有序數組使用二分查找的效率為O(logN).有序數組也可以通過二分查找來新增和刪除數據以提高效率,但是依然需要在新增/刪除后移動數據項,所以效率依然會有影響.

    總結:

    1. 有序數組的查找速度比無序數組高,效率為O(logN)
    2. 有序數組的刪除和新增速度很慢,效率為O(N)

    1.3 數組總結

    數組雖然簡單易用,但是數組有兩個致命的缺點:

    1. 數組存儲的數量有限,創建的過大浪費資源,創建的過小溢出
    2. 數組的效率比其他數據結構低
    • 無序數組插入效率為O(1)時間,但是查找花費O(N)時間
    • 有序數組查找花費O(logN)時間,插入花費O(N)時間
    • 刪除需要移動平均半數的數據項,所以刪除都是O(N)的時間

    2. 鏈表

    數組一經創建大小就固定住了,無法修改,鏈表在這方面做出了改善,只要內存夠用就可以無限制的擴大.

    鏈表是繼數組之後應用最廣泛的數據結構.

    2.1 鏈表的特點

    鏈表為什麼叫鏈表呢? 因為它保存數據的方式就像一條鎖鏈

    鏈表保存數據的方式很像上面的這一條鎖鏈,每一塊鎖鏈就是一個鏈節點,鏈節點保存着自己的數據同時通過自己的next()方法指向下一個鏈節點. 鏈表通過鏈節點不斷地調用next()方法就可以遍歷鏈表中的所有數據.

    在鏈表中,每個數據項都被包含在”鏈節點”(link)中,一個鏈結點是某個類的對象,這個類可以叫做Link.因為一個鏈表中有許多類似的鏈結點,所以有必要用一個不同於鏈表的類來表達鏈結點.

    每個Link對象中都包含一個對下一個鏈結點引用的字段(通常叫做next).

    鏈表本身的對象中有一個字段指向對第一個鏈結點的引用.

    數據與鏈表查找數據的區別: 在數組中查找數據就像在一個大倉庫裏面一樣,一號房間沒有,我們去二號房間,二號房間沒有我們去三號房間,以此類推.. 按照地址找完所有房間就可以了.

    而在鏈表中查找數據就像單線彙報的地下工作者,你是孤狼你想要彙報點情報給你的頂級上司毒蜂,但是你必須先報告給你的接頭人豬剛鬣,豬剛鬣在報告給它的單線接頭人土行孫,最後由土行孫報告給毒蜂.只能一個找一個,這樣最終完成任務.

    2.2 Java代碼

    鏈節點類:

    
    /**
     * @author liuboren
     * @Title: 鏈節點
     * @Description:
     * @date 2019/11/20 19:30
     */
    public class Link {
        //  保存的數據
        public int data;
    
        // 指向的下一個鏈節點
        public Link nextLink;
    
        public Link(int data) {
            this.data = data;
        }
    
        public int getData() {
            return data;
        }
    
        public void setData(int data) {
            this.data = data;
        }
    
        public Link getNextLink() {
            return nextLink;
        }
    
        public void setNextLink(Link nextLink) {
            this.nextLink = nextLink;
        }
    }
    

    鏈表類

    
    /**
     * @author liuboren
     * @Title: 鏈表類
     * @Description:
     * @date 2019/11/20 19:31
     */
    public class LinkList {
        private Link first;
    
        public LinkList() {
            first = null;
        }
    
        // 新增鏈節點方法
        public void insertFirst(int data) {
            Link link = new Link(data);
            link.setNextLink(first);
            first = link;
        }
    }
    

    在新增節點的時候,新增的link的next方法指向原來的first節點,並將鏈表類的first指向新增的節點.

    2.4 其他鏈表

    剛剛介紹的鏈表是單向鏈表,只能從后往前遍歷,其他的鏈表還有雙端鏈表、雙向鏈表、有序鏈表.

    再簡單介紹一下雙端鏈表吧.

    雙端鏈表就是在單向鏈表的基礎上,新增一個成員變量指向鏈表的最後一個對象.

    雙端鏈表代碼:

    /**
     * @author liuboren
     * @Title: 鏈表類
     * @Description:
     * @date 2019/11/20 19:31
     */
    public class LinkList {
        private Link first;
        private Link last;
    
        public LinkList() {
            first = null;
        }
    
        public boolean isEmpty() {
            return first == null;
        }
    
        // 新增鏈節點方法
        public void insertFirst(int data) {
            Link newLink = new Link(data);
            newLink.setNextLink(first);
            if (isEmpty()) {
                last = newLink;
            }
            first = newLink;
    
        }
    }
    

    雙向鏈表則是可以從first和last兩個方向進行遍歷,有序鏈表的數據都是按照關鍵字的順序排列的,本文不再展開了.

    2.5 鏈表的效率

    鏈表的效率:

    • 表頭插入和刪除速度都很快,花費O(1)的時間.
    • 平均起來,查找&刪除&插入在制定鏈節點後面都需要搜索一半的鏈節點需要O(N)次比較,雖然數組也需要O(N)次比較,但是鏈表讓然要快一些,因為不需要移動數據(只需要改變他們的引用)

    3. 總結

    鏈表解決了數組大小不能擴展的問題,但是鏈表自身依然存在一些問題(在鏈表的鏈節點後面查找&刪除&插入的效率不高),那麼有沒有一種數據結構即擁有二者的優點又改善了二者的缺點呢,答案是肯定的,下篇博客將為您介紹這種優秀的數據結構,敬請期待.

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

    ※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※帶您來看台北網站建置台北網頁設計,各種案例分享

    小三通物流營運型態?

    ※快速運回,大陸空運推薦?

  • 大話字符串逆序

    窗外的大廈,桌子上的水杯,手中的筆。

    面試官:“先來一點基礎的吧,用Java寫一個方法,入參是一個字符串,返回逆序后的字符串。”

    我暗想確實很基礎,於是便寫下:

    public static String reverse(String str) {
        StringBuffer sb = new StringBuffer(str);
        return sb.reverse().toString();
    }

    歡迎關注微信公眾號:萬貓學社,每周一分享Java技術乾貨。

    面試官看了看,說:“寫的很好,用StringBuffer的reverse方法。如果你來實現其中算法,你會怎麼寫?”

    我直接說:“從最後一個字符開始,一直向前添加字符就可以了。”重新寫了一個遍代碼:

    public static String reverse(String str) {
        char[] chars = str.toCharArray();
        StringBuilder sb = new StringBuilder();
        for (int i = chars.length - 1; i >= 0; i--) {
            sb.append(chars[i]);
        }
        return sb.toString();
    }

    歡迎關注微信公眾號:萬貓學社,每周一分享Java技術乾貨。

    面試官看了看,說:“寫的很好,逆序的功能完成了。不過再想想,有什麼可以優化的地方?”

    我想了想,說:“好像沒有什麼可以優化的?”

    面試官提示了一句:“比如,採用首尾替換的方式呢?是不是可以減少時間複雜度?”

    我恍然大悟,說:“的確是,我再改一下。”又重新寫了一個遍代碼:

    public static String reverse(String str) {
        char[] chars = str.toCharArray();
        int n = chars.length - 1;
        for (int i = 0; i <= n / 2; i++) {
            int j = n - i;
            char temp = chars[i];
            chars[i] = chars[j];
            chars[j] = temp;
        }
        return new String(chars);
    }

    歡迎關注微信公眾號:萬貓學社,每周一分享Java技術乾貨。

    面試官又看了看,說:“寫的很好,就是這個思想。不過再想想,有什麼可以優化的地方?”

    我左思右想一番,說:“應該沒有吧。”

    面試官說:“確定沒有了嘛?”

    我肯定地回答:“確定沒有了。”

    面試官:“好吧,這個問題先到這。”

    我有點不服氣,搶着問到:“您說說,還有什麼可以優化的地方?”

    面試官微笑了一下,說:“我認為還有兩個地方可以優化。”

    “第一,for循環的布爾表達式里不應該放除2的計算,否則每次循環都會計算一次。”

    “第二,除2的計算可以用右移一位代替,這樣效率更高。”

    面試官在我寫的代碼上改了幾筆,就變成了:

    public static String reverse(String str) {
        char[] chars = str.toCharArray();
        int n = chars.length - 1;
        for (int i = (n - 1) >> 1; i >= 0; i--) {
            int j = n - i;
            char temp = chars[i];
            chars[i] = chars[j];
            chars[j] = temp;
        }
        return new String(chars);
    }

    歡迎關注微信公眾號:萬貓學社,每周一分享Java技術乾貨。

    我茅塞頓開,這次面試真的是學到了。

    本故事純屬虛構,如有雷同實屬巧合。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

    ※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

    台灣寄大陸海運貨物規則及重量限制?

    大陸寄台灣海運費用試算一覽表

  • Nebula 架構剖析系列(二)圖數據庫的查詢引擎設計

    Nebula 架構剖析系列(二)圖數據庫的查詢引擎設計

    摘要

    上文(存儲篇)說到數據庫重要的兩部分為存儲和計算,本篇內容為你解讀圖數據庫 Nebula 在查詢引擎 Query Engine 方面的設計實踐。

    在 Nebula 中,Query Engine 是用來處理 Nebula 查詢語言語句(nGQL)。本篇文章將帶你了解 Nebula Query Engine 的架構。

    上圖為查詢引擎的架構圖,如果你對 SQL 的執行引擎比較熟悉,那麼對上圖一定不會陌生。Nebula 的 Query Engine 架構圖和現代 SQL 的執行引擎類似,只是在查詢語言解析器和具體的執行計劃有所區別。

    Session Manager

    Nebula 權限管理採用基於角色的權限控制(Role Based Access Control)。客戶端第一次連接到 Query Engine 時需作認證,當認證成功之後 Query Engine 會創建一個新 session,並將該 session ID 返回給客戶端。所有的 session 統一由 Session Manger 管理。session 會記錄當前 graph space 信息及對該 space 的權限。此外,session 還會記錄一些會話相關的配置信息,並臨時保存同一 session 內的跨多個請求的一些信息。

    客戶端連接結束之後 session 會關閉,或者如果長時間沒通信會切為空閑狀態。這個空閑時長是可以配置的。
    客戶端的每個請求都必須帶上此 session ID,否則 Query Engine 會拒絕此請求。

    Storage Engine 不管理 session,Query Engine 在訪問存儲引擎時,會帶上 session 信息。

    Parser

    Query Engine 解析來自客戶端的 nGQL 語句,分析器(parser)主要基於著名的 flex / bison 工具集。字典文件(lexicon)和語法規則(grammar)在 Nebula 源代碼的 src/parser  目錄下。設計上,nGQL 的語法非常接近 SQL,目的是降低學習成本。 圖數據庫目前沒有統一的查詢語言國際標準,一旦 ISO/IEC 的圖查詢語言(GQL)委員會發布 GQL 國際標準,nGQL 會儘快去實現兼容。
    Parser 構建產出的抽象語法樹(Abstrac Syntax Tree,簡稱 AST)會交給下一模塊:Execution Planner。

    Execution Planner

    執行計劃器(Execution Planner)負責將抽象樹 AST 解析成一系列執行動作 action(可執行計劃)。action 為最小可執行單元。例如,典型的 action 可以是獲取某個節點的所有鄰節點,或者獲得某條邊的屬性,或基於特定過濾條件篩選節點或邊。當抽象樹 AST 被轉換成執行計劃時,所有 ID 信息會被抽取出來以便執行計劃的復用。這些 ID 信息會放置在當前請求 context 中,context 也會保存變量和中間結果。

    Optimization

    經由 Execution Planner 產生的執行計劃會交給執行優化框架 Optimization,優化框架中註冊有多個 Optimizer。Optimizer 會依次被調用對執行計劃進行優化,這樣每個 Optimizer都有機會修改(優化)執行計劃。最後,優化過的執行計劃可能和原始執行計劃完全不一樣,但是優化后的執行結果必須和原始執行計劃的結果一樣的。

    Execution

    Query Engine 最後一步是去執行優化后的執行計劃,這步是執行框架(Execution Framework)完成的。執行層的每個執行器一次只處理一個執行計劃,計劃中的 action 會挨個一一執行。執行器也會一些有針對性的局部優化,比如:決定是否併發執行。針對不同的 action所需數據和信息,執行器需要經由 meta service 與storage engine的客戶端與他們通信。

    最後,如果你想嘗試編譯一下 Nebula 源代碼可參考如下方式:

    有問題請在 GitHub(GitHub 地址:) 或者微信公眾號上留言,也可以添加 Nebula 小助手微信號:NebulaGraphbot 為好友反饋問題~

    推薦閱讀

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

    網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

    ※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

    大陸寄台灣空運注意事項

    大陸海運台灣交貨時間多久?

  • TCP time_wait close_wait問題(可能是全網最清楚的例子)

    TCP time_wait close_wait問題(可能是全網最清楚的例子)

    背景

    公司群里,運維發現一個問題,task服務報錯(如下)

    The stream or file \"/data/logs/adn_task/offer_service.log\" could not be opened:
    failed to open stream: Too many open files

    測試老大看到了,根據經驗就推測是應該是文件句柄使用完了,應該有TCP連接很多沒釋放,果真發現是很多CLOSE_WAIT的狀態

    簡單認知

    短鏈接,一次鏈接就會佔用一個端口,一個端口就是一個文件描述符;
    文件描述符 又稱 句柄,linux系統最大的句柄數是65535,可以通過ulimit -a 查看

    三次握手

    TCP建立連接需要經過三次握手;
    通俗版本:
    A: 你好,你能聽見我說話嗎?
    B: 能聽到,你能聽到我說話嗎?
    A:我也能聽到,我們開始通信吧

    專業版本:
    建立TCP連接時,需要客戶端和服務器共發送3個包。

    • 第一次:客戶端發送初始序號x和syn=1請求標誌
    • 第二次:服務器發送請求標誌syn,發送確認標誌ACK,發送自己的序號seq=y,發送客戶端的確認序號ack=x+1
    • 第三次:客戶端發送ACK確認號,發送自己的序號seq=x+1,發送對方的確認號ack=y+1

    四次揮手

    TCP連接斷開需要經過四次揮手;
    通俗版本:
    前提A和B在通話
    A:好的,我的話就說完了(FIN);
    B:哦哦,我知道你說完啦(ACK),我還有說兩句哈;A: (沒說話,一直聽着)
    B:哦了,我也說完了(FIN)
    A:好的,我也知道你說玩了(ACK),掛電話吧

    專業版本:

    • 第一次揮手:客戶端發出釋放FIN=1,自己序列號seq=u,進入FIN-WAIT-1狀態
    • 第二次揮手:服務器收到客戶端的后,發出ACK=1確認標誌和客戶端的確認號ack=u+1,自己的序列號seq=v,進入CLOSE-WAIT狀態
    • 第三次揮手:客戶端收到服務器確認結果后,進入FIN-WAIT-2狀態。此時服務器發送釋放FIN=1信號,確認標誌ACK=1,確認序號ack=u+1,自己序號seq=w,服務器進入LAST-ACK(最後確認態)
    • 第四次揮手:客戶端收到回復后,發送確認ACK=1,ack=w+1,自己的seq=u+1,客戶端進入TIME-WAIT(時間等待)。客戶端經過2個最長報文段壽命后,客戶端CLOSE;服務器收到確認后,立刻進入CLOSE狀態。

    狀態流轉圖

    實際例子

    建立連接

    linux上起了一個redis服務

    本地起的6379端口

    還是同一台機器上,通過python腳本連接該redis服務:

    此時網絡連接如下:

    關注這兩個網絡連接,第一個是redis-server的,第二是python腳本的,此時都是ESTABLISHED狀態,表示這兩個進程建立了連接

    TIME_WAIT情況

    現在斷掉python

    之前的python的那個連接,是TIME_WAIT狀態
    客戶端(主動方)主動斷開,進入TIME_WAIT狀態,服務端(被動方)進去CLOSE狀態,就是沒有显示了

    等待2MSL(1分鐘)后,如下:

    TIME_WAIT狀態的連接也消失了,TIME_WAIT回收機制,系統ing過一段時間會回收,資源重利用

    CLOSE_WAIT情況

    先建立連接,如下:

    關掉redis服務,service redis stop

    之前的redis-server的45370端口連接 進入了FIN_WAIT2狀態,而python端(被動關閉方)就進去了CLOSE_WAIT狀態

    等待30s后,在看連接

    只有python的那條CLOSE_WAIT

    再次操作python端的腳本,再次get

    關於6379端口(redis端口)的網絡連接都沒有了

    TCP參數設置

    如何快速回收TIME_WAIT和FIN_WAIT
    /etc/sysctl.conf 包含以下配置項
    net.ipv4.tcp_timestamps = 1
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_fin_timeout = 30
    root權限 執行/sbin/sysctl -p使之生效

    經驗之談

    個人經驗,不一定對,如有錯誤,請指正

    1. 當出現了CLOSE_WAIT大概率是業務代碼問題,代碼中沒有處理服務異常的情況,如上面的例子,python再次請求redis的時候,發現redis掛了,就會主動幹掉CLOSE_WAIT狀態
    2. 出現大量TIME_WAIT的情況,一般是服務端沒有及時回收端口,linux內核參數需要調整優化

    參考資料

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※專營大陸空運台灣貨物推薦

    台灣空運大陸一條龍服務

  • 用雲開發快速製作客戶業務需求收集小程序丨實戰

    用雲開發快速製作客戶業務需求收集小程序丨實戰

    一、導語

    ​ 如何省去企業上門(現場)搜集客戶需求的環節,節約企業人力和時間成本,將客戶的業務定製需求直接上傳至雲數據庫?雲開發為我們提供了這個便利!

    二、需求背景

    ​ 作為一名XX公司IT萌萌新,這段時間對小程序開發一直有非常濃厚的興趣,並且感慨於“雲開發·不止於快”的境界。近期工作中,剛好碰見業務部門的一個需求,目的是節約上門跟客戶收集業務定製資料的時間,以往是每變更一次,就需要上門一次,碰見地域較遠的,費時費力,且往往要求幾天內完成上線,時間非常緊迫。因此,結合一直以來對雲開發的各種優勢的了解,我說服公司領導通過小程序·雲開發來實現。

    下面是其中一項業務定製界面的展示:
    (1)業務對業務流程有簡單說明;
    (2)相關業務介紹;
    (3)不同客戶輸入個性化需求;
    (4)雲存儲後台實現需求表單的收集。

    ​ 得力於雲開發提供的API和WeUI庫的便利,本項目在我在極短的時間內就實現了比較理想的效果 。接下來,我就從本項目入手,講講我是如何依靠小程序·雲開發將想法快速實現的,其實我也是剛入門沒多久,只是想分享一下自身在學習小程序開發項目中的一些知識點和體會,代碼可能略為粗糙,邏輯也有待優化,歡迎大家在評論區多多交流。

    三、開發過程

    1、組件

    主要使用了官方WeUI擴展能力的一些組件庫來實現主要功能。

    核心的WeUI庫主要有 Msg、Picker、圖片的Upload等(以快為目的,節省自己寫CSS樣式的時間,也方便0基礎的同學上手,這裏又體會到了小程序開發的便捷)。

    2、實現代碼

    本次雲開發包括雲數據庫雲存儲兩大功能:

    (1)雲數據庫

    雲數據庫的主要就是搜集客戶提交上來的表單信息,包括客戶的聯繫方式和選擇的業務類型等,並存儲在雲數據庫中,方便業務經理搜集需求。

    我們來看簡單的實現過程:

    首先是表單,用到了 form 表單組件以及它的 bindsubmit 方法,在 wxml 中放置 form 表單:

    <form bindsubmit="formSubmit">
        <view class="form">
          <view class="section">
            <picker bindchange="bindPickerGsd" mode="selector" value="{{indexGsd}}" range="{{arrayGsd}}">
              <view class="picker">歸屬縣市</view>
              <view class="picker-content" >{{arrayGsd[indexGsd]?arrayGsd[indexGsd]:"(必填項) 請下拉選擇歸屬地"}}</view> 
            </picker>
          </view>    
          <!---中間部分詳見代碼--->
        </view>
    
        <view class="footer">
          <button class="dz-btn" formType="submit" loading="{{formStatus.submitting}}" disabled="{{formStatus.submitting}}" bindtap="openSuccess">提交</button>
        </view>
      </form>

    表單中除了普通的文本輸入,增加有下拉列表的實現(畢竟客戶有時候是比較懶的)。

    來看一下具體代碼:

    bindPickerGsd: function (e) {    
      console.log('歸屬地已選擇,攜帶值為', e.detail.value)
      console.log('歸屬地選擇:', this.data.arrayGsd[e.detail.value])    
      this.setData({
         indexGsd: e.detail.value     
       })   
       this.data.formData.home_county = this.data.arrayGsd[e.detail.value]
    },

    最後表單上傳到雲數據庫:

      // 表單提交
      formSubmit: function (e) {
        var minlength = '';
        var maxlength = '';
        console.log("表單內容",e)
        var that = this;
        var formData = e.detail.value;
        var result = this.wxValidate.formCheckAll(formData);
        
        console.log("表單提交formData", formData);
        console.log("表單提交result", result)
        wx.showLoading({
          title: '發布中...',
        })
        const db = wx.cloud.database()
        db.collection('groupdata').add({
          data: {
            time: getApp().getNowFormatDate(),
            home_county: this.data.formData.home_county,
            group_name: formData.group_name,
            contact_name: formData.contact_name,
            msisdn: formData.msisdn,
            product_name: this.data.formData.product_name,
            word: formData.word,
          },
          success: res => {
            wx.hideLoading()
            console.log('發布成功', res)
    
          },
          fail: err => {
            wx.hideLoading()
            wx.showToast({
              icon: 'none',
              title: '網絡不給力....'
            })
            console.error('發布失敗', err)
          }
        })
      },
    (2)雲存儲

    ​ 因為業務的定製需要填單客戶所在單位的授權證明材料,因此需要提單人(使用人)上傳證明文件,因此增加了使用雲存儲的功能。

    核心代碼:

        promiseArr.push(new Promise((reslove,reject)=>{
            wx.cloud.uploadFile({
                cloudPath: "groupdata/" + group_name + "/" + app.getNowFormatDate() +suffix,
                filePath:filePath
            }).then(res=>{
                console.log("授權文件上傳成功")          
                })
                reslove()
                }).catch(err=>{
                console.log("授權文件上傳失敗",err)
        })
    
        因為涉及到不同頁面的數據傳遞,即將表單頁面的group_name作為雲存儲的文件夾用於存儲該客戶在表單中上傳的圖片,因此還需要用到getCurrentPages()來進行頁面間的數據傳遞 
    
        var pages = getCurrentPages();
        var prePage = pages[pages.length - 2];//pages.length就是該集合長度 -2就是上一個活動的頁面,也即是跳過來的頁面
        var group_name = prePage.data.formData.group_name.value//取上頁data里的group_name數據用於標識授權文件所存儲文件夾的名稱

    3、待進一步優化

    ​ 基於時間關係,本次版本僅對需求進行了簡單實現,作為公司一個可靠的項目,還需要關注”客戶隱私”、“數據安全”,以及更人性化的服務。比如:

    (1)提單人確認和認證過程

    可靠性:增加驗證碼驗證(防止他人冒名登記),以及公司受理業務有個客戶本人提交憑證。

    (2)訂閱消息

    受理成功后,可以給客戶進行處理結果的反饋,增強感知。

    (3)人工客服

    進行在線諮詢等。

    四、總結

    ​ 在本次項目開發中,我深刻體會到了雲開發的“快”,特別是雲數據庫的增刪查改功能非常方便。雲開發提供的種種便利,讓我在有新創意的時候,可以迅速採用小程序雲開發快速實現,省時省力,還能免費使用騰訊雲服務器,推薦大家嘗試!

    源碼地址

    如果你想要了解更多關於雲開發CloudBase相關的技術故事/技術實戰經驗,請掃碼關注【騰訊云云開發】公眾號~

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

    ※試算大陸海運運費!

  • SpringBoot 源碼解析 (六)—– Spring Boot的核心能力 – 內置Servlet容器源碼分析(Tomcat)

    SpringBoot 源碼解析 (六)—– Spring Boot的核心能力 – 內置Servlet容器源碼分析(Tomcat)

    Spring Boot默認使用Tomcat作為嵌入式的Servlet容器,只要引入了spring-boot-start-web依賴,則默認是用Tomcat作為Servlet容器:

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    Servlet容器的使用

    默認servlet容器

    我們看看spring-boot-starter-web這個starter中有什麼

    核心就是引入了tomcat和SpringMvc,我們先來看tomcat

    Spring Boot默認支持Tomcat,Jetty,和Undertow作為底層容器。如圖:

    而Spring Boot默認使用Tomcat,一旦引入spring-boot-starter-web模塊,就默認使用Tomcat容器。

    切換servlet容器

    那如果我么想切換其他Servlet容器呢,只需如下兩步:

    • 將tomcat依賴移除掉
    • 引入其他Servlet容器依賴

    引入jetty:

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <!--移除spring-boot-starter-web中的tomcat-->
                <artifactId>spring-boot-starter-tomcat</artifactId>
                <groupId>org.springframework.boot</groupId>
            </exclusion>
        </exclusions>
    </dependency>
    
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <!--引入jetty-->
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>

    Servlet容器自動配置原理

    EmbeddedServletContainerAutoConfiguration

    其中
    EmbeddedServletContainerAutoConfiguration是嵌入式Servlet容器的自動配置類,該類在
    spring-boot-autoconfigure.jar中的web模塊可以找到。

    我們可以看到EmbeddedServletContainerAutoConfiguration被配置在spring.factories中,看過我前面文章的朋友應該知道SpringBoot自動配置的原理,這裏將EmbeddedServletContainerAutoConfiguration配置類加入到IOC容器中,接着我們來具體看看這個配置類:

    @AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
    @Configuration
    @ConditionalOnWebApplication// 在Web環境下才會起作用
    @Import(BeanPostProcessorsRegistrar.class)// 會Import一個內部類BeanPostProcessorsRegistrar
    public class EmbeddedServletContainerAutoConfiguration {
    
        @Configuration
        // Tomcat類和Servlet類必須在classloader中存在 // 文章開頭我們已經導入了web的starter,其中包含tomcat和SpringMvc // 那麼classPath下會存在Tomcat.class和Servlet.class
        @ConditionalOnClass({ Servlet.class, Tomcat.class }) // 當前Spring容器中不存在EmbeddedServletContainerFactory類型的實例
        @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT) public static class EmbeddedTomcat {
    
            @Bean
            public TomcatEmbeddedServletContainerFactory tomcatEmbeddedServletContainerFactory() {
                // 上述條件註解成立的話就會構造TomcatEmbeddedServletContainerFactory這個EmbeddedServletContainerFactory
                return new TomcatEmbeddedServletContainerFactory();
            }
        }
        
        @Configuration
        @ConditionalOnClass({ Servlet.class, Server.class, Loader.class,
                WebAppContext.class })
        @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)
        public static class EmbeddedJetty {
    
            @Bean
            public JettyEmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory() {
                return new JettyEmbeddedServletContainerFactory();
            }
    
        }
        
        @Configuration
        @ConditionalOnClass({ Servlet.class, Undertow.class, SslClientAuthMode.class })
        @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)
        public static class EmbeddedUndertow {
    
            @Bean
            public UndertowEmbeddedServletContainerFactory undertowEmbeddedServletContainerFactory() {
                return new UndertowEmbeddedServletContainerFactory();
            }
    
        }
        
        //other code...
    }

    在這個自動配置類中配置了三個容器工廠的Bean,分別是:

    • TomcatEmbeddedServletContainerFactory

    • JettyEmbeddedServletContainerFactory

    • UndertowEmbeddedServletContainerFactory

    這裏以大家熟悉的Tomcat為例,首先Spring Boot會判斷當前環境中是否引入了Servlet和Tomcat依賴,並且當前容器中沒有自定義的
    EmbeddedServletContainerFactory的情況下,則創建Tomcat容器工廠。其他Servlet容器工廠也是同樣的道理。

    EmbeddedServletContainerFactory

    • 嵌入式Servlet容器工廠
    public interface EmbeddedServletContainerFactory {
    
        EmbeddedServletContainer getEmbeddedServletContainer( ServletContextInitializer... initializers);
    }

    內部只有一個方法,用於獲取嵌入式的Servlet容器。

    該工廠接口主要有三個實現類,分別對應三種嵌入式Servlet容器的工廠類,如圖所示:

    TomcatEmbeddedServletContainerFactory

    以Tomcat容器工廠TomcatEmbeddedServletContainerFactory類為例:

    public class TomcatEmbeddedServletContainerFactory extends AbstractEmbeddedServletContainerFactory implements ResourceLoaderAware {
        
        //other code...
        
        @Override
        public EmbeddedServletContainer getEmbeddedServletContainer( ServletContextInitializer... initializers) {
            //創建一個Tomcat
            Tomcat tomcat = new Tomcat(); //配置Tomcat的基本環節
            File baseDir = (this.baseDirectory != null ? this.baseDirectory: createTempDir("tomcat"));
            tomcat.setBaseDir(baseDir.getAbsolutePath());
            Connector connector = new Connector(this.protocol);
           tomcat.getService().addConnector(connector);
            customizeConnector(connector);
          tomcat.setConnector(connector); tomcat.getHost().setAutoDeploy(false);
            configureEngine(tomcat.getEngine());
            for (Connector additionalConnector : this.additionalTomcatConnectors) {
                tomcat.getService().addConnector(additionalConnector);
            }
            prepareContext(tomcat.getHost(), initializers);
            
            //包裝tomcat對象,返回一個嵌入式Tomcat容器,內部會啟動該tomcat容器
            return getTomcatEmbeddedServletContainer(tomcat);
        }
    }

    首先會創建一個Tomcat的對象,並設置一些屬性配置,最後調用getTomcatEmbeddedServletContainer(tomcat)方法,內部會啟動tomcat,我們來看看:

    protected TomcatEmbeddedServletContainer getTomcatEmbeddedServletContainer(
        Tomcat tomcat) {
        return new TomcatEmbeddedServletContainer(tomcat, getPort() >= 0);
    }

    該函數很簡單,就是來創建Tomcat容器並返回。看看TomcatEmbeddedServletContainer類:

    public class TomcatEmbeddedServletContainer implements EmbeddedServletContainer {
    
        public TomcatEmbeddedServletContainer(Tomcat tomcat, boolean autoStart) {
            Assert.notNull(tomcat, "Tomcat Server must not be null");
            this.tomcat = tomcat;
            this.autoStart = autoStart;
            
            //初始化嵌入式Tomcat容器,並啟動Tomcat
     initialize();
        }
        
        private void initialize() throws EmbeddedServletContainerException {
            TomcatEmbeddedServletContainer.logger
                    .info("Tomcat initialized with port(s): " + getPortsDescription(false));
            synchronized (this.monitor) {
                try {
                    addInstanceIdToEngineName();
                    try {
                        final Context context = findContext();
                        context.addLifecycleListener(new LifecycleListener() {
    
                            @Override
                            public void lifecycleEvent(LifecycleEvent event) {
                                if (context.equals(event.getSource())
                                        && Lifecycle.START_EVENT.equals(event.getType())) {
                                    // Remove service connectors so that protocol
                                    // binding doesn't happen when the service is
                                    // started.
                                    removeServiceConnectors();
                                }
                            }
    
                        });
    
                        // Start the server to trigger initialization listeners
                        //啟動tomcat
                        this.tomcat.start(); // We can re-throw failure exception directly in the main thread
                        rethrowDeferredStartupExceptions();
    
                        try {
                            ContextBindings.bindClassLoader(context, getNamingToken(context),
                                    getClass().getClassLoader());
                        }
                        catch (NamingException ex) {
                            // Naming is not enabled. Continue
                        }
    
                        // Unlike Jetty, all Tomcat threads are daemon threads. We create a
                        // blocking non-daemon to stop immediate shutdown
                        startDaemonAwaitThread();
                    }
                    catch (Exception ex) {
                        containerCounter.decrementAndGet();
                        throw ex;
                    }
                }
                catch (Exception ex) {
                    stopSilently();
                    throw new EmbeddedServletContainerException(
                            "Unable to start embedded Tomcat", ex);
                }
            }
        }
    }

    到這裏就啟動了嵌入式的Servlet容器,其他容器類似。

    Servlet容器啟動原理

    SpringBoot啟動過程

    我們回顧一下前面講解的SpringBoot啟動過程,也就是run方法:

    public ConfigurableApplicationContext run(String... args) {
        // 計時工具
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
    
        ConfigurableApplicationContext context = null;
        Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
    
        configureHeadlessProperty();
    
        // 第一步:獲取並啟動監聽器
        SpringApplicationRunListeners listeners = getRunListeners(args);
        listeners.starting();
        
        try {
            ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
    
            // 第二步:根據SpringApplicationRunListeners以及參數來準備環境
            ConfigurableEnvironment environment = prepareEnvironment(listeners,applicationArguments);
            configureIgnoreBeanInfo(environment);
    
            // 準備Banner打印器 - 就是啟動Spring Boot的時候打印在console上的ASCII藝術字體
            Banner printedBanner = printBanner(environment);
    
            // 第三步:創建Spring容器
            context = createApplicationContext();
    
            exceptionReporters = getSpringFactoriesInstances(
                    SpringBootExceptionReporter.class,
                    new Class[] { ConfigurableApplicationContext.class }, context);
    
            // 第四步:Spring容器前置處理
            prepareContext(context, environment, listeners, applicationArguments,printedBanner);
    
            // 第五步:刷新容器
     refreshContext(context);
    
         // 第六步:Spring容器後置處理
            afterRefresh(context, applicationArguments);
    
          // 第七步:發出結束執行的事件
            listeners.started(context);
            // 第八步:執行Runners
            this.callRunners(context, applicationArguments);
            stopWatch.stop();
            // 返回容器
            return context;
        }
        catch (Throwable ex) {
            handleRunFailure(context, listeners, exceptionReporters, ex);
            throw new IllegalStateException(ex);
        }
    }

    我們回顧一下第三步:創建Spring容器

    public static final String DEFAULT_CONTEXT_CLASS = "org.springframework.context."
                + "annotation.AnnotationConfigApplicationContext";
    
    public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework."
                + "boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext";
    
    protected ConfigurableApplicationContext createApplicationContext() {
        Class<?> contextClass = this.applicationContextClass;
        if (contextClass == null) {
            try {
                //根據應用環境,創建不同的IOC容器
                contextClass = Class.forName(this.webEnvironment ? DEFAULT_WEB_CONTEXT_CLASS : DEFAULT_CONTEXT_CLASS);
            }
        }
        return (ConfigurableApplicationContext) BeanUtils.instantiate(contextClass);
    }

    創建IOC容器,如果是web應用,則創建
    AnnotationConfigEmbeddedWebApplicationContext的IOC容器;如果不是,則創建AnnotationConfigApplicationContext的IOC容器;很明顯我們創建的容器是AnnotationConfigEmbeddedWebApplicationContext
    接着我們來看看
    第五步,刷新容器
    refreshContext(context);

    private void refreshContext(ConfigurableApplicationContext context) {
        refresh(context);
    }
    
    protected void refresh(ApplicationContext applicationContext) {
        Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
        //調用容器的refresh()方法刷新容器
     ((AbstractApplicationContext) applicationContext).refresh();
    }

    容器刷新過程

    調用抽象父類AbstractApplicationContext的refresh()方法;

    AbstractApplicationContext

     1 public void refresh() throws BeansException, IllegalStateException {
     2     synchronized (this.startupShutdownMonitor) {
     3         /**
     4          * 刷新上下文環境
     5          */
     6         prepareRefresh();
     7 
     8         /**
     9          * 初始化BeanFactory,解析XML,相當於之前的XmlBeanFactory的操作,
    10          */
    11         ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
    12 
    13         /**
    14          * 為上下文準備BeanFactory,即對BeanFactory的各種功能進行填充,如常用的註解@Autowired @Qualifier等
    15          * 添加ApplicationContextAwareProcessor處理器
    16          * 在依賴注入忽略實現*Aware的接口,如EnvironmentAware、ApplicationEventPublisherAware等
    17          * 註冊依賴,如一個bean的屬性中含有ApplicationEventPublisher(beanFactory),則會將beanFactory的實例注入進去
    18          */
    19         prepareBeanFactory(beanFactory);
    20 
    21         try {
    22             /**
    23              * 提供子類覆蓋的額外處理,即子類處理自定義的BeanFactoryPostProcess
    24              */
    25             postProcessBeanFactory(beanFactory);
    26 
    27             /**
    28              * 激活各種BeanFactory處理器,包括BeanDefinitionRegistryBeanFactoryPostProcessor和普通的BeanFactoryPostProcessor
    29              * 執行對應的postProcessBeanDefinitionRegistry方法 和  postProcessBeanFactory方法
    30              */
    31             invokeBeanFactoryPostProcessors(beanFactory);
    32 
    33             /**
    34              * 註冊攔截Bean創建的Bean處理器,即註冊BeanPostProcessor,不是BeanFactoryPostProcessor,注意兩者的區別
    35              * 注意,這裏僅僅是註冊,並不會執行對應的方法,將在bean的實例化時執行對應的方法
    36              */
    37             registerBeanPostProcessors(beanFactory);
    38 
    39             /**
    40              * 初始化上下文中的資源文件,如國際化文件的處理等
    41              */
    42             initMessageSource();
    43 
    44             /**
    45              * 初始化上下文事件廣播器,並放入applicatioEventMulticaster,如ApplicationEventPublisher
    46              */
    47             initApplicationEventMulticaster();
    48 
    49             /**
    50  * 給子類擴展初始化其他Bean 51              */
    52  onRefresh(); 53 
    54             /**
    55              * 在所有bean中查找listener bean,然後註冊到廣播器中
    56              */
    57             registerListeners();
    58 
    59             /**
    60              * 設置轉換器
    61              * 註冊一個默認的屬性值解析器
    62              * 凍結所有的bean定義,說明註冊的bean定義將不能被修改或進一步的處理
    63              * 初始化剩餘的非惰性的bean,即初始化非延遲加載的bean
    64              */
    65             finishBeanFactoryInitialization(beanFactory);
    66 
    67             /**
    68              * 通過spring的事件發布機制發布ContextRefreshedEvent事件,以保證對應的監聽器做進一步的處理
    69              * 即對那種在spring啟動后需要處理的一些類,這些類實現了ApplicationListener<ContextRefreshedEvent>,
    70              * 這裏就是要觸發這些類的執行(執行onApplicationEvent方法)
    71              * spring的內置Event有ContextClosedEvent、ContextRefreshedEvent、ContextStartedEvent、ContextStoppedEvent、RequestHandleEvent
    72              * 完成初始化,通知生命周期處理器lifeCycleProcessor刷新過程,同時發出ContextRefreshEvent通知其他人
    73              */
    74             finishRefresh();
    75         }
    76 
    77         finally {
    78     
    79             resetCommonCaches();
    80         }
    81     }
    82 }

    我們看第52行的方法:

    protected void onRefresh() throws BeansException {
    
    }

    很明顯抽象父類AbstractApplicationContext中的onRefresh是一個空方法,並且使用protected修飾,也就是其子類可以重寫onRefresh方法,那我們看看其子類AnnotationConfigEmbeddedWebApplicationContext中的onRefresh方法是如何重寫的,AnnotationConfigEmbeddedWebApplicationContext又繼承EmbeddedWebApplicationContext,如下:

    public class AnnotationConfigEmbeddedWebApplicationContext extends EmbeddedWebApplicationContext {

    那我們看看其父類EmbeddedWebApplicationContext 是如何重寫onRefresh方法的:

    EmbeddedWebApplicationContext

    @Override
    protected void onRefresh() {
        super.onRefresh();
        try {
            //核心方法:會獲取嵌入式的Servlet容器工廠,並通過工廠來獲取Servlet容器
     createEmbeddedServletContainer();
        }
        catch (Throwable ex) {
            throw new ApplicationContextException("Unable to start embedded container", ex);
        }
    }

    在createEmbeddedServletContainer方法中會獲取嵌入式的Servlet容器工廠,並通過工廠來獲取Servlet容器:

     1 private void createEmbeddedServletContainer() {
     2     EmbeddedServletContainer localContainer = this.embeddedServletContainer;
     3     ServletContext localServletContext = getServletContext();
     4     if (localContainer == null && localServletContext == null) {
     5         //先獲取嵌入式Servlet容器工廠
     6         EmbeddedServletContainerFactory containerFactory = getEmbeddedServletContainerFactory();  7         //根據容器工廠來獲取對應的嵌入式Servlet容器
     8         this.embeddedServletContainer = containerFactory.getEmbeddedServletContainer(getSelfInitializer());  9     }
    10     else if (localServletContext != null) {
    11         try {
    12             getSelfInitializer().onStartup(localServletContext);
    13         }
    14         catch (ServletException ex) {
    15             throw new ApplicationContextException("Cannot initialize servlet context",ex);
    16         }
    17     }
    18     initPropertySources();
    19 }

    關鍵代碼在第6和第8行,先獲取Servlet容器工廠,然後根據容器工廠來獲取對應的嵌入式Servlet容器

    獲取Servlet容器工廠

    protected EmbeddedServletContainerFactory getEmbeddedServletContainerFactory() {
        //從Spring的IOC容器中獲取EmbeddedServletContainerFactory.class類型的Bean
        String[] beanNames = getBeanFactory().getBeanNamesForType(EmbeddedServletContainerFactory.class); //調用getBean實例化EmbeddedServletContainerFactory.class
        return getBeanFactory().getBean(beanNames[0], EmbeddedServletContainerFactory.class);
    }

    我們看到先從Spring的IOC容器中獲取EmbeddedServletContainerFactory.class類型的Bean,然後調用getBean實例化EmbeddedServletContainerFactory.class,大家還記得我們第一節Servlet容器自動配置類EmbeddedServletContainerAutoConfiguration中注入Spring容器的對象是什麼嗎?當我們引入spring-boot-starter-web這個啟動器后,會注入TomcatEmbeddedServletContainerFactory這個對象到Spring容器中,所以這裏獲取到的Servlet容器工廠是TomcatEmbeddedServletContainerFactory,然後調用

    TomcatEmbeddedServletContainerFactory的getEmbeddedServletContainer方法獲取Servlet容器,並且啟動Tomcat,大家可以看看文章開頭的getEmbeddedServletContainer方法。

    大家看一下第8行代碼獲取Servlet容器方法的參數getSelfInitializer(),這是個啥?我們點進去看看

    private ServletContextInitializer getSelfInitializer() {
        //創建一個ServletContextInitializer對象,並重寫onStartup方法,很明顯是一個回調方法
        return new ServletContextInitializer() { public void onStartup(ServletContext servletContext) throws ServletException { EmbeddedWebApplicationContext.this.selfInitialize(servletContext); } };
    }

    創建一個ServletContextInitializer對象,並重寫onStartup方法,很明顯是一個回調方法,這裏給大家留一點疑問:

    • ServletContextInitializer對象創建過程是怎樣的?
    • onStartup是何時調用的?
    • onStartup方法的作用是什麼?

    ServletContextInitializer是 Servlet 容器初始化的時候,提供的初始化接口。這裏涉及到Servlet、Filter實例的註冊,我們留在下一篇具體講

     

     

     

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

    ※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

    ※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

    ※專營大陸快遞台灣服務

    台灣快遞大陸的貨運公司有哪些呢?

  • 技術人如何利用 github+Jekyll ,搭建一個獨立免費的技術博客

    技術人如何利用 github+Jekyll ,搭建一個獨立免費的技術博客

    上次有人留言說,技術博客是程序員的標配,但據我所知絕大部分技術同學到現在仍然沒有自己的技術博客。原因有很多,有的是懶的寫,有的是怕寫不好,還有的是一直想憋個大招,幻想做到完美再發出來,結果一直胎死腹中。但其實更多程序員是不知道如何去搭建一個博客,其實如今搭建一個個人技術博客非常簡單,其中最簡單搭建方式莫屬使用 GitHub Pages + Jekyll 了,我的博客就是使用這種技術。

    GitHub Pages

    Github Pages 是面向用戶、組織和項目開放的公共靜態頁面搭建託管服務,站點可以被免費託管在 Github 上,你可以選擇使用 Github Pages 默認提供的域名 github.io 或者自定義域名來發布站點。Github Pages 支持 自動利用 Jekyll 生成站點,也同樣支持純 HTML 文檔,將你的 Jekyll 站點託管在 Github Pages 上是一個不錯的選擇。

    使用 Github Pages 搭建博客有以下幾個優點:

    • 完全免費,其中服務器、流量、域名什麼的都管,完全零費用搭建一個技術博客
    • 寫博客就是提交代碼,讓寫作和編程的體驗保持一致
    • 支持綁定自己的域名
    • 提供流行的網頁主題模板

    缺點也是有的:

    • 不支持動態內容,博客必須都是靜態網頁,一般會使用 Jekyll 來構建內容。
    • 博客不能被百度索引,因 Github 和百度有過節,所以 Github 就把百度給屏蔽了。
    • 倉庫空間不大於1G
    • 每個月的流量不超過100G
    • 每小時更新不超過 10 次

    Github Pages 使用 Jekyll 來構建內容,那麼 Jekyll 是什麼呢?

    Jekyll 介紹

    Jekyll 是一個簡單的博客形態的靜態站點生產機器。它有一個模版目錄,其中包含原始文本格式的文檔,通過一個轉換器(如 Markdown)和我們的 Liquid 渲染器轉化成一個完整的可發布的靜態網站,你可以發布在任何你喜愛的服務器上。Jekyll 也可以運行在 GitHub Page 上,也就是說,你可以使用 GitHub 的服務來搭建你的項目頁面、博客或者網站,而且是完全免費的。

    但如果我們只是在 GitHub 上面使用的話,到不需要知道 Jekyll 的語法,一般 Github 會自動將我們寫的 Markdown 文件轉換成靜態頁面。使用 Jekyll 需要使用 Markdown 語法來寫你的文章,不過 Markdown 語法非常簡單,做為程序員來講基本上兩三天就掌握了,大家也可以參考這篇文章:。

    給大家分享一些 Jekyll 主題,這個網站下有很多 主題,大家可以根據自己的愛好去選擇博客主題。

    我的個人博客

    我的博客經過了三個階段,第一個階段,完全依託於使用 GitHub Pages 來構建;第二個階段,將博客託管於國外的一個服務商;第三個階段,服務器遷移回到國內、域名備案。之前也寫過幾篇關於技術博客的文章,如下:

    使用 Github Pages + Jekyll 構建一個技術博客很簡單,基本上步驟就是網上找一個自己喜歡的主題,直接 Fork 到自己的 Github ,然後在刪掉原博客中的內容,在上傳自己的文章即可,以我自己的博客為例。

    我的博客最初使用的是,但這個主題已經盡兩年多都沒有更新了。因此後期我在這個主題的基礎上做了一些改動,其中有依賴組件的更新,結合個人情況對個別頁面進行了改版,就成為了現在的樣子:

    使用這個主題的原因是,我比較喜歡簡潔大氣的風格,並且此博客主題對代碼展示支持良好。

    快速構建一個博客

    以我的博客為例,介紹如何最快搭建一個博客。這也是我博客經歷的第一個階段。

    1、首先打開地址,點擊 Fork 按鈕將代碼複製一份到自己的倉庫。

    過上一分鐘,你的 github 倉庫發現一個 ityouknow.github.io 項目。

    2、刪除 CNAME 文件

    刪除項目中的 CNAME 文件,CNAME 是定製域名的時候使用的內容,如果不使用定製域名會存在衝突。

    3、設置 GitHub Pages

    點擊 Settings 按鈕打開設置頁面,頁面往下拉到 GitHub Pages 相關設置,在 Source 下面的複選框中選擇 master branch ,然後點擊旁邊的 Save 按鈕保存設置。

    4、重命名項目

    點擊 Settings 按鈕打開設置頁面,重命名項目名稱為:github_username.github.io。

    github_username 是你的 github 登錄用戶名

    5、重命名之後,再次回到 Settings > GitHub Pages 頁面

    會發現存在這樣一個地址:

    這個時候,你訪問此地址已經可以看到博客的首頁,但是點擊文章的時鏈接跳轉地址不對,這是因為少配置了一個文件。

    6、配置 _config.yml

    打開項目目錄下的 _config.yml 文件,修改以下配置:

    repository: github_username/github_username.github.io
    github_url: https://github.com/github_username
    url: https://github_username.github.io

    這時候在訪問地址: https://github_username.github.io,就會發現博客就已經構建完成了。剩下的事情就是去項目的 _posts 目錄下刪除掉我的文章,然後按照 Jekyll 的語法就寫自己的文章就好了。

    github_username 為你的 github id。

    自定義域名

    雖然通過地址https://github_username.github.io可以正常訪問博客,但是技術小夥伴們肯定有人想使用自己的域名訪問博客,這樣的需求 GitHub Pages 也是支持的。

    首先需要設置域名解析,將域名的地址指向自己的 github 博客地址。這裏以萬網的域名配置為例,選擇需要設置的域名點擊解析,在域名解析頁面添加以下兩條記錄

    紅框內,需要填寫自己github_username值。

    然後重新打開項目的 Settings > GitHub Pages 頁面,Custom domain 下的輸入框輸入剛才設置的域名:xxx.com,點擊保存即可。

    重新配置 _config.yml

    打開項目目錄下的 _config.yml 文件,修改以下配置:

    url: http://www.xxx.com

    等待一分鐘之後,瀏覽器訪問地址:www.xxx.com 即可訪問博客。

    自定義 DIY 博客

    一般同學到上面這一步也就完成了,基本滿足了 80% 技術同學的需求。但還是有一些同學們有更高的追求,比如說使用 Github Pages 雖然簡單方便,但是不能被百度檢索白白流失了大量的流量,還有一個原因有些時候,博客網絡訪問穩定性不是很高。

    當時我在國外有幾個虛擬機,本來用作它用,後來在上面安裝了一個 Nginx 作為靜態頁面的服務器。首先我在本機(win10)安裝了 Jekyll 環境,將 Github 上的博客代碼下載下來之後,在本機編譯成靜態的 Html ,然後手動上傳到服務的 Nginx 目錄下;然後將域名指向虛擬機。

    非常不建議大家實踐以上這段內容,win10 上面安裝 Jekyll 環境是一段慘痛的經歷。

    就這樣很麻煩的步驟我用了幾個月後,實在是受不了了,一方面因為服務器在國外,有時候仍然不穩定(可能因為服務器安裝了代理),另一方面我需要使用一些功能,使用這些功能的前提是網站需要備案,那段時間騰訊雲在做活動,就把博客又從國外搬了回來,順便重新優化了一下流程。

    仍然把博客託管在 Github 上面,每次提交完代碼后,在騰訊雲上面執行一個腳本,這個腳本會自動從 Github 拉取最新更新的文件,並自動生產靜態的 Html 文件推送到 Nginx 目錄,域名重新指向這台服務器。可以在 Github 上面設置一些鈎子,當提交代碼的時候自動觸髮腳本,也可以定時觸髮腳本來發布文章。

    腳本內容如下:

    cd /usr/local/ityouknow.github.io
    git pull http://github.com/ityouknow/ityouknow.github.io.git
    jekyll build --destination=/usr/share/nginx/html

    執行此腳本的前提是安裝好 git\jekyll 環境,這個網上有很多案例,這裏就不再多描述了。
    關於 Jekyll 環境搭建和使用可以參考這裏:

    自動化部署

    這两天看到,我也按照他的步驟實踐了一番,很好用,所以把自動化部署這段寫補上。

    配置 Webhook

    在開發過程中的 Webhook,是一種通過通常的 callback,去增加或者改變 Web page或者 Web app 行為的方法。這些 Callback 可以由第三方用戶和開發者維持當前,修改,管理,而這些使用者與網站或者應用的原始開發沒有關聯。Webhook 這個詞是由 Jeff Lindsay 在 2007 年在計算機科學 hook 項目第一次提出的。

    用大白話講就是,代碼倉庫在收到代碼提交的時候,會自動觸發一個 url 類型的通知,你可以根據這個通知去做一些事情,比如提交了代碼就自動去部署項目。

    我們的自動部署博客也是利用了這個機制,Github 自帶了 Webhook 功能,我們直接配置即可使用。

    在 Github 倉庫的項目界面,比如本博客項目 https://github.com/ityouknow/ityouknow.github.io,點擊 Setting->Webhooks->Add Webhook,在添加 Webhooks 的配置信息,我的配置信息如下:

    Payload URL: http://www.ityouknow.com/deploy
    Content type: application/json
    Secret: 123456

    如下圖:

    服務器接受推送

    我們需要在博客的服務器上面建立一個服務,來接收 Github 提交代碼后的推送,從而來觸發部署的腳本。 Github 上有一個開源項目可以做這個事情 。

    這個開源項目目的很單純,就是負責接收 Github 推送過來的通知,然後執行部署腳本,不過他是使用 NodeJs 來開發的,所以我們先需要在 Centos 上面按照 Node 環境。

    centos7 安裝 Node 環境

    首先添加源

    sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm
    
    //yum安裝node.js
    yum install -y nodejs

    然後在安裝 github-webhook-handler

    npm install -g github-webhook-handler     #安裝 github-webhook-handler
    #如果沒有安裝成功,可以選擇法2來安裝
    npm install -g cnpm --registry=http://r.cnpmjs.org
    cnpm install -g github-webhook-handler

    安裝成功之後,我們需要添加一個腳本。進入到安裝目錄下:

    cd  /usr/lib/node_modules/github-webhook-handler

    新建 deploy.js

    vi deploy.js

    腳本內容如下:

    var http = require('http')
    var createHandler = require('github-webhook-handler')
    var handler = createHandler({ path: '/deploy', secret: 'ityouknow' }) //監聽請求路徑,和Github 配置的密碼
     
    function run_cmd(cmd, args, callback) {
      var spawn = require('child_process').spawn;
      var child = spawn(cmd, args);
      var resp = "";
     
      child.stdout.on('data', function(buffer) { resp += buffer.toString(); });
      child.stdout.on('end', function() { callback (resp) });
    }
     
    http.createServer(function (req, res) {
      handler(req, res, function (err) {
        res.statusCode = 404
        res.end('no such location')
      })
    }).listen(3006)//監聽的端口
     
    handler.on('error', function (err) {
      console.error('Error:', err.message)
    })
     
    handler.on('push', function (event) {
      console.log('Received a push event for %s to %s',
        event.payload.repository.name,
        event.payload.ref);
      run_cmd('sh', ['/usr/local/depoly.sh'], function(text){ console.log(text) });//成功后,執行的腳本。
    })

    腳本的作業就是啟動一個監聽端口來接收請求,接收到請求后執行部署腳本,腳本內容的關鍵點已經標註上註釋。

    部署博客的腳本如下:depoly.sh

    echo `date`
    cd /usr/local/ityouknow.github.io
    echo start pull from github 
    git pull http://github.com/ityouknow/ityouknow.github.io.git
    echo start build..
    jekyll build --destination=/usr/share/nginx/html

    就是拉取代碼,進行部署而已。

    這個腳本的啟動需要藉助 Node 中的一個管理 forever 。forever 可以看做是一個 nodejs 的守護進程,能夠啟動,停止,重啟我們的 app 應用。

    不過我們的先安裝 forever,然後需要使用 forever 來啟動 deploy.js 的服務,執行命令如下:

    npm install forever -g   #安裝
    $ forever start deploy.js          #啟動
    $ forever stop deploy.js           #關閉
    $ forever start -l forever.log -o out.log -e err.log deploy.js   #輸出日誌和錯誤
    /root/node-v8.12.0-linux-x64/lib/node_modules/forever/bin/forever start -l forever.log -o out.log -e err.log deploy.js
    
    如果報錯:
    /root/node-v8.12.0-linux-x64/lib/node_modules/forever/bin/forever start -a -l forever.log -o out.log -e err.log deploy.js

    同時一般情況下,我們不會對外保留很多端口,所以需要通過博客的地址來轉發,需要在 Nginx 上面添加一個轉發配置,用來監聽的 /deploy 請求轉發到 nodejs 服務上,配置代碼如下:

    location = /deploy {
         proxy_pass http://127.0.0.1:3006/deploy;
    }

    這樣我們整個自動化部署就完了,每次提交代碼時,Github 會發送 Webhook 給地址http://www.ityouknow.com/deploy,Nginx 將 /deploy 地址轉發給 Nodejs 端口為 3306 的服務,最後通過 github-webhook-handler 來執行部署腳本,已到達自動部署的目的。

    以後只需要我們提交代碼到 Github ,就會自動觸發博客的自動化部署。

    可能會出現的問題

    有一些小夥伴反饋在克隆博客的時候出現了一些問題,在這裏集中回復一下。

    1、克隆博客后格式丟失

    這是很多讀者反饋的第一個問題,因為我的博客 css 和 圖片是放到另外一個域名下的:www.itmind.net ,因此這塊大家克隆過去需要改成本地的。

    主要涉及的文件 ityouknow.github.io\_includes 目錄下 head.html 和 footer.html 兩個文件夾,將文件中的 http://www.ityouknow.com/xxx/xxx 改為相對路徑/xxx/xxx即可。

    2、留言功能丟失

    這裏就需要大家修改一下 _config.yml 中 gitalk 的配置信息。具體如何操作大家可以參考這篇文章 。註冊完之後,需要在 _config.yml 配置以下信息:

    gitalk:
        owner: ityouknow
        repo: blog-comments
        clientID: 61bfc53d957e74e78f8f
        clientSecret: 31c61e66cdcc9ada8db2267ee779d0bdafac434c

    將這裏改成你註冊好的信息

    3、博客

    博客現在還缺檢索功能,下一頁和上一頁功能、系列文章優化查看的功能,大家克隆後有完善功能的,也請幫忙留意,共同把這個博客完善的更好。

    最後,大家可以在這篇文章下留下你的個人博客地址,方便同行們觀賞、交流、學習。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

    ※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

    ※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

    台灣海運大陸貨務運送流程

    兩岸物流進出口一站式服務