跳到主要內容

小菜成長之路，警惕淪為 API 調用俠

小菜(化名)在某互聯網公司擔任運維工程師，負責公司後台業務的運維保障工作。由於自己編程經驗不多，平時有不少工作需要開發協助。


聽說 Python 很火，能快速開發一些運維腳本，小菜也加入 Python 大軍學起來。 Python 語言確實簡單，小菜很快就上手了，覺得自己應對運維開發工作已經綽綽有餘，便不再深入研究。


背景


這天老闆給小菜派了一個數據採集任務，要實時統計服務器 TCP 連接數。需求背景是這樣的：開發同事需要知道服務的連接數以及不同狀態連接的比例，以便判斷服務狀態。


因此，小菜需要開發一個腳本，定期採集並報告 TCP 連接數，提交數據格式定為 json ：


{
   "LISTEN": 4,
   "ESTABLISHED": 100,
   "TIME_WAIT": 10
 }

作為運維工程師，小菜當然知道怎麼查看系統 TCP 連接。
Linux 系統中有兩個命令可以辦到， netstat 和 ss ：


$ netstat -nat
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 tcp        0      0 127.0.0.1:8388          0.0.0.0:*               LISTEN
 tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN
 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
 tcp        0      0 192.168.56.3:22         192.168.56.1:54983      ESTABLISHED
 tcp6       0      0 :::22                   :::*                    LISTEN
 

$ ss -nat
 State                    Recv-Q                    Send-Q                                         Local Address:Port                                         Peer Address:Port
 LISTEN                   0                         128                                                127.0.0.1:8388                                              0.0.0.0:*
 LISTEN                   0                         128                                            127.0.0.53%lo:53                                                0.0.0.0:*
 LISTEN                   0                         128                                                  0.0.0.0:22                                                0.0.0.0:*
 ESTAB                    0                         0                                               192.168.56.3:22                                           192.168.56.1:54983
 LISTEN                   0                         128                                                     [::]:22                                                   [::]:*

小菜還知道 ss 命令比 netstat 命令要快，但至於為什麼，小菜就不知道了。


小菜很快找到老闆，提出了自己的解決方案：寫一個 Python 程序，調用 ss 命令採集 TCP 連接信息，然後再逐條統計。


老闆告訴小菜，線上服務器很多都是最小化安裝，並不能保證每台機器上都有 ss 或者 netstat 命令。


老闆還告訴小菜，程序開發要學會 站在巨人的肩膀上 。動手寫代碼前，先調研一番，看是否有現成的解決方案。 切忌重複造輪子 ，浪費時間不說，可能代碼質量還差，效果也不好。


最後老闆給小菜指了條明路，讓他回去再看看 psutil 。 psutil 是一個 Python 第三方包，用於採集系統性能數據，包括： CPU 、內存、磁盤、網卡以及進程等等。臨走前，老闆還叮囑小菜，完成工作后花點時間研究下這個庫。


psutil 方案


小菜搜索 psutil 發現，原來有這麼順手的第三方庫，喜出望外！他立馬裝好 psutil ，準備開干：


$ pip install psutil

導入 psutil 后，一個函數調用就可以拿到系統所有連接，連接信息非常豐富：


>>> import psutil
 >>> for conn in psutil.net_connections('tcp'):
 ...     print(conn)
 ...
 sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='192.168.56.3', port=22), raddr=addr(ip='192.168.56.1', port=54983), status='ESTABLISHED', pid=None)
 sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='LISTEN', pid=None)
 sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='0.0.0.0', port=22), raddr=(), status='LISTEN', pid=None)
 sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='LISTEN', pid=None)
 sconn(fd=-1, family=<AddressFamily.AF_INET6: 10>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='::', port=22), raddr=(), status='LISTEN', pid=None)

小菜很滿意，感覺不用花多少時間就可搞定數據採集需求了，準時下班有望！噼里啪啦，很快小菜就寫下這段代碼：


import psutil
 from collections import defaultdict
 
 # 遍歷每個連接，按連接狀態累加
 stats = defaultdict(int)
 for conn in psutil.net_connections('tcp'):
     stats[conn.status] += 1
 
 # 遍歷每種狀態，輸出連接數
 for status, count in stats.items():
     print(status, count)

小菜接着在服務器上測試這段代碼，功能完全正常：


ESTABLISHED 1
 LISTEN 4

小菜將數據採集腳本提交，並按既定節奏逐步發布到生產服務器上。開發同事很快就看到小菜採集的數據，都誇小菜能力不錯，需求完成得很及時。小菜也很高興，感覺 Python 沒白學。如果用其他語言開發，說不定現在還在加班加點呢！Life is short, use Python! 果然沒錯！


小菜愈發自信，早就把老闆的話拋到腦後了。 psutil 這個庫這麼好上手，有啥好深入研究的？


內存悲劇


突然有一天，其他同事緊急告訴小菜，他開發的採集腳本佔用很多內存， CPU 也跑到了 100% ，已經開始影響線上服務了。小菜還沉浸在成功的喜悅中，收到這個反饋如同晴天霹靂，有點举手無措。


業務同事告訴小菜，受影響的機器系統連接數非常大，質疑小菜是不是腳本存在性能問題。小菜覺得很背，腳本只是調用 psutil 並統計數據，怎麼就攤上性能故障？腳本影響線上服務，小菜壓力很大，但不知道如何是好，只能跑去找老闆尋求幫助。


老闆要小菜第一時間停止數據採集，降低影響。復盤故障時，老闆很敏銳地問小菜，是不是用容器保存所有連接了？小菜自己並沒有，但是 psutil 這麼做了：


>>> psutil.net_connections()
 [sconn(fd=-1, family=<AddressFamily.AF_INET6: 10>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='::', port=22), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='0.0.0.0', port=22), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='10.0.2.15', port=68), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='192.168.56.3', port=22), raddr=addr(ip='192.168.56.1', port=54983), status='ESTABLISHED', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='LISTEN', pid=None)]

psutil 將採集到的所有 TCP 連接放在一個列表裡返回。如果服務器上有十萬個 TCP 連接，那麼列表裡將有十萬個連接對象。難怪採集腳本吃了那麼多內存！


老闆告訴小菜，可以用生成器加以解決。與列表不同，生成器逐個返回數據，因此不會佔用太多內存。Python2 中 range 和 xrange 函數的區別也是一樣的道理。


小菜從 pstuil  fork 了一個分支，並將 net_connections 函數改造成 生成器 ：


def net_connections():
     while True:
         if done:
             break
 
         # 解析一個TCP連接
         conn = xxx
 
         yield conn

代碼上線后，採集腳本內存佔用量果然下降了！ 生成器 將統計算法的空間複雜度由原來的 O(n) 優化為 O(1) 。經過這次教訓，小菜不敢再盲目自信了，他決定抽時間好好看看 psutil 的源碼。


源碼體會


深入學習源碼后，小菜發現原來 psutil 採集 TCP 連接數的秘笈是：從 /proc/net/tcp 以及 /proc/net/tcp6 讀取連接信息。


由此，他還進一步了解到 procfs ，這是一個偽文件系統，將內核空間信息以文件方式暴露到用戶空間。 /proc/net/tcp 文件則是提供內核 TCP 連接信息：


$ cat /proc/net/tcp
   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
    0: 0100007F:20C4 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534        0 18183 1 0000000000000000 100 0 0 10 0
    1: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000   101        0 16624 1 0000000000000000 100 0 0 10 0
    2: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 18967 1 0000000000000000 100 0 0 10 0
    3: 0338A8C0:0016 0138A8C0:D6C7 01 00000000:00000000 02:00023B11 00000000     0        0 22284 4 0000000000000000 20 13 23 10 20

小菜還注意到，連接信息看起來像個自定義類對象，但其實是一個 nametuple ：


# psutil.net_connections()
 sconn = namedtuple('sconn', ['fd', 'family', 'type', 'laddr', 'raddr',
                              'status', 'pid'])

小菜一開始並不知道作者為啥要這麼做。後來，小菜開始研究 Python 源碼，學習了 Python 類機制后他恍然大悟。


Python 自定義類的每個實例對象均需要一個 dict 來保存對象屬性，這也就是對象的 屬性空間 。


如果用自定義類來實現，每個連接都需要創建一個字典，而字典又是 散列表 實現的。如果系統存在成千上萬的連接，開銷可想而知。


小菜將學到的知識總結起來：對於 數量大 而 屬性固定 的實體，沒有必要用自定義類來實現，用 nametuple 更合適，開銷更小。由此，小菜不經由衷佩服 psutil 的作者。


CPU悲劇


後來小菜又收到業務反饋，採集腳本在高併發的服務器上， CPU 使用率很高，需要再優化一下。


小菜回憶 psutil 源碼，很快就找到了性能瓶頸處： psutil 將連接信息所有字段都解析了，而採集腳本只需要其中的 狀態 字段而已。


跟老闆商量后，小菜決定自行讀取 procfs 來實現採集腳本，只解析狀態字段，避免不必要的計算開銷。


procfs 方案


直接讀取 /proc/net/tcp ，可以得到完整的 TCP 連接信息：


>>> with open('/proc/net/tcp') as f:
 ...     for line in f:
 ...         print(line.rstrip())
 ...
   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
    0: 0100007F:20C4 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534        0 18183 1 0000000000000000 100 0 0 10 0
    1: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000   101        0 16624 1 0000000000000000 100 0 0 10 0
    2: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 18967 1 0000000000000000 100 0 0 10 0
    3: 0338A8C0:0016 0138A8C0:D6C7 01 00000000:00000000 02:0007169E 00000000     0        0 22284 3 0000000000000000 20 20 33 10 20

其中， IP 、端口、狀態等字段都是以十六進制編碼的。例如， st 列表示狀態，狀態碼 0A 表示 LISTEN 。很快小菜就寫下這段代碼：


from collections import defaultdict
 
 stat_names = {
     '0A': 'LISTEN',
     '01': 'ESTABLISHED',
     # ...
 }
 
 # 遍歷每個連接，按連接狀態累加
 stats = defaultdict(int)
 
 with open('/proc/net/tcp') as f:
     # 跳過表頭行
     f.readline()
 
     for line in f:
         st = line.strip().split()[3]
         stats[st] += 1
 
 for st, count in stats.items():
     print(stat_names[st], count)

現在，小菜寫代碼比之前講究多了。在統計連接數時，他並不急於將狀態碼解析成名字，而是按原樣統計。等統計完成，他再一次性轉換，這樣狀態碼轉換開銷便降到最低： O(1)  而不是 O(n) 。


這次改進符合業務同事預期，但小菜決定好好做一遍性能測試，不打無準備之仗。他找業務同事要了一個連接數最大的 /proc/net/tcp 樣本，拉到本地測試。測試結果還算符合預期，採集腳本能夠扛住十萬連接採集壓力。


性能測試中，小菜發現了一個比較奇怪的問題。同樣的連接規模，把 /proc/net/tcp 拉到本地跑比直接在服務器上跑要快，而本地電腦性能肯定比不上服務器。


他百思不得其解，又去找老闆幫忙。老闆很快指出到其中的區別，將 /proc/net/tcp 拉到本地就成為普通 磁盤文件 ，而 procfs 是內核映射出來的 偽文件 ，並不是磁盤文件。


他讓小菜研究一下 Python 文件 IO 以及內核 IO 子系統在處理這兩種文件時有什麼區別，還讓小菜特別留意 IO 緩衝區大小。


IO緩衝


小菜打開一個普通的磁盤文件，發現 Python 選的默認緩衝區大小是 4K (讀緩存對象頭 152 字節)：


>>> f = open('test.py')
 >>> f.buffer.__sizeof__()
 4248

但是如果打開的是 procfs 文件， Python 選的緩衝區卻只有 1K ，相差了 4 倍呢！


>>> f = open('/proc/net/tcp')
 >>> f.buffer.__sizeof__()
 1176

因此，理論上 Python 默認讀取 procfs 發生的上下文切換次數是普通磁盤文件的 4 倍，怪不得會慢。


雖然小菜還不知道這種現象背後的原因，但是他已經知道怎麼進行優化了。隨即他決定將緩衝區設置為 1M 以上，盡量避免 IO 上下文切換，以空間換時間：


with open('/proc/net/tcp', buffering=1*1024*1024) as f:
     # ...

經過這次優化，採集腳本在大部分服務器上運行良好，基本可以高枕無憂了。而小菜也意識到 編程語言 以及 操作系統 等底層基礎知識的重要性，他開始制定學習計劃補全計算機基礎知識。


netlink 方案


後來負載均衡團隊找到小菜，他們也想統計服務器上的連接信息。由於負載均衡服務器作為入口轉發流量，連接數規模特別大，達到幾十萬，將近百萬的規模。小菜決定好好進行性能測試，再視情況上線。


測試結果並不樂觀，採集腳本要跑幾十秒鐘才完成， CPU 跑到 100% 。小菜再次調高 IO 緩衝區，但效果不明顯。小菜又測試了 ss 命令，發現 ss 命令要快很多。由於之前嘗到了閱讀源碼的甜頭，小菜很想到 ss 源碼中尋找秘密。


由於項目時間較緊，老闆提醒小菜先用 strace 命令追蹤 ss 命令的系統調用，便可快速獲悉 ss 的實現方式。老闆演示了 strace 命令的用法，很快就找到了 ss 的秘密 —— Netlink ：


$ strace ss -nat
 ...
 socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_SOCK_DIAG) = 3
 ...

Netlink 套接字是 Linux 提供通訊機制，可用於內核與進程間、進程與進程間通訊。 Netlink 下的 sock_diag 子系統，提供了一種從內核獲取套接字信息的新方式。


與 procfs 不同，sock_diag 採用網絡通訊的方式，內核作為服務端接收客戶端進程查詢請求，並以二進制數據包響應查詢結果，效率更高。


這就是 ss 比 netstat 更快的原因， ss 採用 Netlink 機制，而 netstat 採用 procfs 機制。


很不幸 Python 並沒有提供 Netlink API ，一般人可能又要干著急了。好在小菜先前有意識地研究了部分 Python 源碼，對 Python 的運行機制有所了解。


他知道可以用 C 寫一個 Python 擴展模塊，在 C 語言中調用原生系統調用。


編寫 Python C 擴展模塊可不簡單，對編程功底要求很高，必須全面掌握 Python 運行機制，特別是對象內存管理。


一朝不慎可能導致程序異常退出、內存泄露等棘手問題。好在小菜已經不是當年的小菜了，他經受住了考驗。


小菜的擴展模塊上線后，效果非常好，頂住了百萬級連接的採集壓力。


一個看似簡單得不能再簡單的數據採集需求，背後涉及的知識可真不少，沒有一定的水平還真搞不定。好在小菜成長很快，他最終還是徹底地解決了性能問題，找回了久違的信心。


內核模塊方案


雖然性能問題已經徹底解決，小菜還是沒有將其淡忘。


他時常想：如果可以將統計邏輯放在內核空間做，就不用在內核和進程之間傳遞大量連接信息了，效率應該是最高的！受限於當時的知識水平，小菜還沒有能力實現這個設想。


後來小菜在研究 Linux 內核時，發現可以用內核模塊來擴展內核的功能，結合 procfs 的工作原理，他找到了技術方案！他順着 /proc/net/tcp 在內核中的實現源碼，依樣畫葫蘆寫了這個內核模塊：


#include <linux/module.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <net/tcp.h>
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Xiaocai");
 MODULE_DESCRIPTION("TCP state statistics");
 MODULE_VERSION("1.0");
 
 // 狀態名列表
 static char *state_names[] = {
     NULL,
     "ESTABLISHED",
     "SYN_SENT",
     "SYN_RECV",
     "FIN_WAIT1",
     "FIN_WAIT2",
     "TIME_WAIT",
     "CLOSE",
     "CLOSE_WAIT",
     "LAST_ACK",
     "LISTEN",
     "CLOSING",
     NULL
 };
 
 
 static void stat_sock_list(struct hlist_nulls_head *head, spinlock_t *lock,
     unsigned int state_counters[])
 {
     // 套接字節點指針(用於遍歷)
     struct sock *sk;
     struct hlist_nulls_node *node;
 
     // 鏈表為空直接返回
     if (hlist_nulls_empty(head)) {
         return;
     }
 
     // 自旋鎖鎖定
     spin_lock_bh(lock);
 
     // 遍歷套接字鏈表
     sk = sk_nulls_head(head);
     sk_nulls_for_each_from(sk, node) {
         if (sk->sk_state < TCP_MAX_STATES) {
             // 自增狀態計數器
             state_counters[sk->sk_state]++;
         }
     }
 
     // 自旋鎖解鎖
     spin_unlock_bh(lock);
 }
 
 
 static int tcpstat_seq_show(struct seq_file *seq, void *v)
 {
     // 狀態計數器
     unsigned int state_counters[TCP_MAX_STATES] = { 0 };
     unsigned int state;
 
     // TCP套接字哈希槽序號
     unsigned int bucket;
 
     // 先遍歷Listen狀態
     for (bucket = 0; bucket < INET_LHTABLE_SIZE; bucket++) {
         struct inet_listen_hashbucket *ilb;
 
         // 哈希槽
         ilb = &tcp_hashinfo.listening_hash[bucket];
 
         // 遍歷鏈表並統計
         stat_sock_list(&ilb->head, &ilb->lock, state_counters);
     }
 
     // 遍歷其他狀態
     for (bucket = 0; bucket < tcp_hashinfo.ehash_mask; bucket++) {
         struct inet_ehash_bucket *ilb;
         spinlock_t *lock;
 
         // 哈希槽鏈表
         ilb = &tcp_hashinfo.ehash[bucket];
         // 保護鎖
         lock = inet_ehash_lockp(&tcp_hashinfo, bucket);
 
         // 遍歷鏈表並統計
         stat_sock_list(&ilb->chain, lock, state_counters);
     }
 
     // 遍歷狀態輸出統計值
     for (state = TCP_ESTABLISHED; state < TCP_MAX_STATES; state++) {
         seq_printf(seq, "%-12s: %d\n", state_names[state], state_counters[state]);
     }
 
     return 0;
 }
 
 
 static int tcpstat_seq_open(struct inode *inode, struct file *file)
 {
     return single_open(file, tcpstat_seq_show, NULL);
 }
 
 
 static const struct file_operations tcpstat_file_ops = {
     .owner   = THIS_MODULE,
     .open    = tcpstat_seq_open,
     .read    = seq_read,
     .llseek  = seq_lseek,
     .release = single_release
 };
 
 
 static __init int tcpstat_init(void)
 {
     proc_create("tcpstat", 0, NULL, &tcpstat_file_ops);
     return 0;
 }
 
 
 static __exit void tcpstat_exit(void)
 {
     remove_proc_entry("tcpstat", NULL);
 }
 
 module_init(tcpstat_init);
 module_exit(tcpstat_exit);

內核模塊編譯好並加載到內核后， procfs 文件系統提供了一個新文件 /proc/tcpstat ，內容為統計結果：


$ cat /proc/tcpstat
 ESTABLISHED : 5
 SYN_SENT    : 0
 SYN_RECV    : 0
 FIN_WAIT1   : 0
 FIN_WAIT2   : 0
 TIME_WAIT   : 1
 CLOSE       : 0
 CLOSE_WAIT  : 0
 LAST_ACK    : 0
 LISTEN      : 14
 CLOSING     : 0

當用戶程序讀取這個文件時，內核虛擬文件系統( VFS )調用小菜在內核模塊中寫的處理函數：遍歷內核 TCP 套接字完成統計並格式化統計結果。內核模塊、 VFS 以及套接字等知識超出專欄範圍，不再贅述。


小菜在服務器上試驗這個內核模塊，真的快得飛起！


經驗總結


小菜開始總結這次腳本開發工作中的經驗教訓，他列出了以下關鍵節點：



  1. 依靠 psutil 採集，沒有關注 psutil 實現導致性能問題；

  2. 用生成器代替列表返回連接信息，解決內存瓶頸；

  3. 直接讀取 procfs 文件系統，部分解決 CPU 性能瓶頸；

  4. 通過調節 IO 緩衝區大小，進一步降低 CPU 開銷；

  5. 用 Netlink 代替 procfs ，徹底解決性能問題；

  6. 實驗內核模塊思路，終極解決方案快得飛起；


這些問題節點，一個比一個深入，沒有一定功底是搞不定的。小菜從剛開始跌跌撞撞，到後來獨當一面，快速成長的關鍵在於善於在問題中總結經驗教訓：



  • 程序開發完一定要做性能測試，看能夠扛住多大的壓力；

  • 使用任何工具，需要準確理解其背後的原理，避免誤用；

  • 對編程語言以及操作系統源碼要保持好奇心；

  • 計算機基礎知識很重要，需要及時補全才能達到新高度；

  • 學會問題發散，舉一反三；


更多章節


洞悉 Python 虛擬機運行機制，探索高效程序設計之道！


到底如何才能提升我的 Python 開發水平，向更高一級的崗位邁進？ 如果你有這些問題或者疑惑，請訂閱我們的專欄，閱讀更多章節：



  • 內建對象

  • 虛擬機

  • 函數機制

  • 類機制

  • 生成器與協程

  • 內存管理機制


附錄


更多 Python 技術文章請訪問：小菜學Python，轉至 原文 可獲得最佳閱讀體驗。


訂閱更新，獲取更多學習資料，請關注 小菜學編程 ：


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

【其他文章推薦】



※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!



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



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



※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!



※教你寫出一流的銷售文案?



※超省錢租車方案



Orignal From: 小菜成長之路，警惕淪為 API 調用俠

留言

張貼留言

這個網誌中的熱門文章

掃地機器人可以隨身帶上飛機嗎?我想要拿去送給國外的朋友

掃地機器人如果要隨身戴上飛機需要滿足兩個條件： 一個是掃地機器人連同你的隨身行李，整體的體積和重量要符合上機條件，這個具體每家航空公司都不同，可以諮詢，簡單的說就是隨身行李不要超寬超重。 還有一個就是由於掃地機器人內置了鋰電池，所以內置電池的容量要符合相關規定，每個掃地機器人電池容量都不同，具體自行查詢。 根據民航的相關安全要求，凡帶有鋰電池的電子設備均不可以托運，但符合重量要求，尺寸要求以及電量要求的鋰電池及其設備是可以帶上飛機的。 《鋰電池航空運輸規範》中內含鋰離子電池的設備電池額定能量不應超過100Wh的規定，符合國標GB31241-2014，並通過UN38.3航空運輸認證等國際安全標準，所以可以帶上飛機。但是不能托運，只能隨身攜帶。 掃地機器人     掃地機器人     掃地機器人吸塵器 http://www.greenh3y.com/?p=400 Orignal From: 掃地機器人可以隨身帶上飛機嗎?我想要拿去送給國外的朋友
張貼留言
閱讀完整內容

不滿國際規範斷財路 非洲多國擬退野生動保公約

摘錄自2019年09月01日中央通訊社非洲報導 非洲南部多國揚言退出「瀕臨絕種野生動植物國際貿易公約」，因為公約多數成員拒絕放寬象牙與犀牛角交易，並且幾乎全面禁止將野生捕獲的大象送到動物園。 這個公約嚴格規範全球野生動物交易，包括限制象牙與犀牛角交易。 本週在日內瓦召開修訂「瀕臨絕種野生動植物國際貿易公約」（CITES）的會議期間，由於區域集團非南開發共同體（SADC）的多項提案遭否決，這個集團與公約的關係惡化。 全球大象數量最多的區域波札那、納米比亞與辛巴威要求販售取自自然死亡、充公與汰除的大象象牙，這項提議被居多數的101票否決。 40多年前制訂的CITES規範約3萬6000種動植物交易，並設計有助於遏止非法交易和制裁違規國家的機制。 不過有16個成員國的非南開發共同體部分會員批評CITES對非洲國家的問題視若無睹。 坦尚尼亞環境部長西蒙巴徹恩（George Simbachawene）於日內瓦召開的會議中表示：「結果無法採取進步、公平、包容與基於科學的的保育策略。」 他說：「該是認真重新考慮我們加入CITES是否有任何實質益處的時候了。」 本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理 【搬家相關資訊指南】 台中搬家 , 彰化搬家 , 南投搬家 前需注意的眉眉角角，別等搬了再說! 避免吃悶虧無故遭抬價! 台中搬家公司 免費估價,有契約讓您安心有保障! 評比 彰化搬家公司費用 , 南投搬家公司費用 收費行情懶人包大公開 彰化搬家費用 , 南投搬家費用 ,距離,噸數怎麼算?達人教你簡易估價知識! Orignal From: 不滿國際規範斷財路 非洲多國擬退野生動保公約
張貼留言
閱讀完整內容

全球第一國 帛琉立法禁用、禁售防曬乳

摘錄自2018年11月2日蘋果日報帛琉報導 為了保護珊瑚礁生態，帛琉政府昨（1）日表示已立法嚴禁販售並使用防曬乳，此法將於2020年1月1日起正式生效。帛琉也成為全球首個全面禁止防曬乳的國家。 帛琉國會上周通過此法案，全面禁止使用和販售含有10種有害化學物質的防曬乳，違者將被處以1000美元（約3萬783元台幣）罰款。若遊客被發現私帶防曬乳入境，也會遭到沒收。帛琉總統雷蒙傑索（Tommy Remengesau）說：「沒收（防曬乳）已經足夠讓人不進行商業使用，而這也是很聰明的一招，一方面教育觀光客，又不會把他們嚇跑。」 根據官方說法，帛琉的熱門潛水點每小時會有4艘載著觀光客的船隻造訪，他們身上的防曬乳化學物質相當可觀。總統府發言人說：「帛琉各潛水和浮潛地點每天都有好幾加崙的防曬乳入海。我們只是盡力要防止環境遭受污染。」 本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理 【其他文章推薦】 ※ 台中搬家 , 彰化搬家 , 南投搬家 前需注意的眉眉角角，別等搬了再說! ※在找尋 搬家 公司嗎? ※搬家不受騙不被宰 桃園搬家公司 , 桃園市搬家公司 公開報價讓你比價不吃虧! Orignal From: 全球第一國 帛琉立法禁用、禁售防曬乳
張貼留言
閱讀完整內容