標籤: 新北清潔

  • 三文搞懂學會Docker容器技術(下)

    三文搞懂學會Docker容器技術(下)

    接着上面一篇:三文搞懂學會Docker容器技術(上)

                             三文搞懂學會Docker容器技術(中)

    7,Docker容器目錄掛載

      7.1 簡介

    容器目錄掛載:

    我們可以在創建容器的時候,將宿主機的目錄與容器內的目錄進行映射,這樣我們就可以實現宿主機和容器目錄的雙向數據自動同步;

      7.2 作用

    前面學過cp命令來實現數據傳遞,這種方式比較麻煩;

    我們通過容器目錄掛載,能夠輕鬆實現代碼上傳,配置修改,日誌同步等需求;

      7.3 實現

    語法:

    docker run -it -v  /宿主機目錄:/容器目錄 鏡像名

    多目錄掛載

    docker run -it -v /宿主機目錄:/容器目錄 -v /宿主機目錄2:/容器目錄2  鏡像名

    注意:

    如果你同步的是多級目錄,可能會出現權限不足的提示;

    這是因為Centos7中的安全模塊selinux把權限禁掉了,我們需要添加  –privileged=true 來解決掛載的目錄沒有權限的問題;

      7.4 掛載目錄只讀

    docker run -it -v  /宿主機目錄:/容器目錄:ro 鏡像名

     

    8,Docker遷移與備份

      8.1 概述

    我們開發的時候,經常自定義鏡像,然後commit提交成鏡像到本地倉庫,但是我們發布到客戶服務器的時候,可以用前面講得搞到hub官方,或者阿里雲,但是有些機密性的項目,是禁止公網存儲的,所以我們只能通過docker鏡像備份和遷移實現;

      8.2 實現

    備份鏡像:

    docker save -o 備份鏡像的名稱  源鏡像名稱:tag版本

     docker save -o mytomcat7.1.tar java1234/tomcat7:7.1

     

    恢復鏡像:

    docker load -i 鏡像文件

    docker load -i mytomcat7.1.tar

     

    9,DockerFile詳解

      9.1 DockerFile簡介

    Dockerfile是由一系列命令和參數構成的腳本,這些命令應用於操作系統(centos或者Ubuntu)基礎鏡像並最終創建的一個新鏡像;

    我們前面講過的用手工的方式,修改配置文件,或者添加,刪除文件目錄的方式,來構建一種新鏡像;這種手工方式麻煩,容易出錯,而且不能復用;

    我們這裏講Dockerfile,用腳本方式來構建自動化,可復用的,高效率的創建鏡像方式,是企業級開發的首選方式;

     

    再軟件系統開發生命周期中,採用Dockerfile來構建鏡像;

    1、對於開發人員:可以為開發團隊提供一個完全一致的開發環境;

    2、對於測試人員:可以直接拿開發時所構建的鏡像或者通過Dockerfile文件構建一個新的鏡像開始工作;

    3、對於運維人員:在部署時,可以實現應用的無縫移植。

      9.2 DockerFile常用指令

    FROM image_name:tag 定義了使用哪個基礎鏡像啟動構建流程
    MAINTAINER user_info 聲明鏡像維護者信息
    LABEL key value 鏡像描述元信息(可以寫多條)
    ENV key value 設置環境變量(可以寫多條)
    RUN command 構建鏡像時需要運行的命令(可以寫多條)
    WORKDIR path_dir 設置終端默認登錄進來的工作目錄
    EXPOSE port 當前容器對外暴露出的端口
    ADD source_dir/file dest_dir/file 將宿主機的文件複製到容器內,如果是一個壓縮文件,將會在複製后自動解壓
    COPY source_dir/file dest_dir/file 和ADD相似,但是如果有壓縮文件是不能解壓
    VOLUME 創建一個可以從本地主機或其他容器掛載的掛載點,一般用來存放數據庫和需要保持的數據等
    CMD 指定容器啟動時要運行的命令,假如有多個CMD,最後一個生效
    ENTRYPOINT 指定容器啟動時要運行的命令
    ONBUILD 當構建一個被繼承的Dockerfile時運行的命令,父鏡像在被子鏡像繼承後父鏡像的onbuild被觸發。可以把ONBUID理解為一個觸發器。

     

    10,Docker私有倉庫

      10.1 簡介

    Docker私有倉庫主要是企業內部用來存放鏡像的倉庫,相對官方倉庫以及阿里雲倉庫,具有更高的保密安全級別;

      10.2 私有倉庫搭建

    第一步:拉取私有倉庫鏡像 (私有倉庫程序本身就是一個鏡像)

    docker pull registry

    第二步:啟動私有倉庫容器

    docker run -di –name=myRegistry -p 5000:5000 registry

    第三步:測試

    http://192.168.1.112:5000/v2/_catalog

    看到這個 說明啟動OK。因為倉庫里還沒有鏡像,所以就是空的;

    第四步:etc/docker 修改daemon.json,讓docker信任私有倉庫地址

    “insecure-registries”: [“192.168.1.112:5000”]

     

    第五步:修改配置后重啟docker;

     systemctl restart docker

      10.3 私有倉庫測試

    第一步:標記此鏡像為私有倉庫的鏡像

    docker tag tomcat:7 192.168.1.112:5000/mytomcat7

    第二步:上傳鏡像到私有倉庫

    docker push 192.168.1.112:5000/mytomcat7

    此時私有倉庫里已經有了這個鏡像;

    第三步:刪除192.168.1.112:5000/mytomcat7本地倉庫鏡像

    docker rmi -f 192.168.1.112:5000/mytomcat7

    第四步:從私有倉庫拉取192.168.1.112:5000/mytomcat7鏡像,並運行;

    docker run -it -p 8080:8080 192.168.1.112:5000/mytomcat7

    第五步:瀏覽器運行 http://192.168.1.112:8080測試

     

    ——————————————————————————————————————————

    作者: java1234_小鋒

    出處:https://www.cnblogs.com/java688/p/13174647.html

    版權:本站使用「CC BY 4.0」創作共享協議,轉載請在文章明顯位置註明作者及出處。

    ——————————————————————————————————————————

     

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

    【其他文章推薦】

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

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

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

    南投搬家公司費用需注意的眉眉角角,別等搬了再說!

    新北清潔公司,居家、辦公、裝潢細清專業服務

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

  • lin-cms-dotnetcore功能模塊的設計

    lin-cms-dotnetcore功能模塊的設計

    lin-cms-dotnetcore功能模塊的設計

    先來回答以下問題。可拉到最下面查看預覽圖。

    1.什麼是cms?

    Content Management System,內容管理系統。

    2.dotnetcore是什麼?

    .NET Core,是由Microsoft開發,目前在.NET Foundation(一個非營利的開源組織)下進行管理,採用寬鬆的MIT協議,可構建各種軟件,包括Web應用程序、移動應用程序、桌面應用程序、雲服務、微服務、API、遊戲和物聯網應用程序。

    3.lin-cms 是什麼?

    Lin-CMS 是林間有風團隊經過大量項目實踐所提煉出的一套內容管理系統框架。Lin-CMS 可以有效的幫助開發者提高 CMS 的開發效率,

    Lin的定位在於實現一套 CMS的解決方案,管理系統的基礎框架,提供了不同的後端,不同的前端實現,後端也支持不同的數據庫,是一套前後端完整的解決方案

    目前官方團隊維護 lin-cms-vue,lin-cms-spring-boot,lin-cms-koa,lin-cms-flask 社區維護了 lin-cms-tp5,lin-cms-react,lin-cms-dotnetcore,即已支持vue,react二種前端框架,java,nodejs,python,php,c#等五種後端語言。

    lin-cms-vue(官方)

    • https://github.com/TaleLin/lin-cms-vue
    • Vue+ElementUI構建的CMS開發框架,
    • 林間有風團隊經過大量項目實踐所提煉出的一套內容管理系統框架
    • 內置了 CMS 中最為常見的需求:用戶管理、權限管理、日誌系統等

    lin-cms-koa(官方)

    • python
    • https://github.com/TaleLin/lin-cms-koa
    • 使用Node.JS KOA構建的CMS開發框架

    lin-cms-flask(官方)

    • node.js
    • https://github.com/TaleLin/lin-cms-flask
    • A simple and practical CMS implememted by flask

    lin-cms-spring-boot(官方)

    • java
    • https://github.com/TaleLin/lin-cms-spring-boot
    • 基於SpringBoot的CMS/DMS/管理系統開發框架

    lin-cms-tp5(社區)

    • php 被官方fork。
    • https://github.com/TaleLin/lin-cms-tp5
    • A simple and practical CMS implememted by ThinkPHP 5.1

    lin-cms-react(社區)

    • https://github.com/Bongkai/lin-cms-react
    • React+Antd構建的CMS開發框架

    lin-cms-dotnetcore(社區)

    • C#
    • A simple and practical CMS implemented by .NET Core 3.1 一個簡單實用、基於.NET Core
    • https://github.com/luoyunchong/lin-cms-dotnetcore
    • .NET Core 3.1實現的CMS;前後端分離、Docker部署、OAtuh2授權登錄、自動化部署DevOps、GitHub Action同步至Gitee

    4.lin-cms-dotnetcore有哪些特點?

    基於.NET Core3.1實現的LIN-CMS-VUE後端API,並增加了博客模塊。目前實現簡約的權限管理系統、基礎字典項管理、隨筆專欄,評論點贊、關注用戶、技術頻道(標籤分類)、消息通知,標籤等仿掘金模塊。

    功能模塊的設計

    基礎權限模塊

    • 用戶信息:郵件、用戶名(唯一)、昵稱、頭像、分組、是否激活、手機號、是否是Admin、個性簽名
      • [x] 註冊/登錄
      • [x] 上傳頭像
      • [x] 修改個人密碼
      • [x] 用戶基本信息修改
      • [x] 用戶增刪改,配置分組
    • 綁定第三方賬號
      • [x] GitHub登錄
      • [x] QQ 登錄
      • [ ] Gitee登錄
    • 分組信息:是否靜態分組(無法刪除,無法修改分組編碼)、名稱可以修改
      • [x] 分組增刪改
      • [x] 分組配置權限
    • 文件管理
      • [x] 本地文件上傳
      • [x] 七牛雲存儲
      • [x] 文件去重,秒傳
    • 系統日誌:請求方法、路徑、http返回碼、時間、用戶昵稱、用戶id、訪問哪個權限、 日誌信息
      • [x] 記錄系統請求的日誌
      • [ ] 異常日誌
    • 設置管理:name(鍵),value(值),provider_name(提供名),provider_key(提供者值)
      • [x] 設置新增修改刪除
      • [x] 所有設置

    比如存某用戶選擇的是markdown還是富文本。

    name="Article.Editor",
    value="markdown" 或 "富文本",
    provider_name為"User",
    provider_key為用戶Id
    

    或存儲七牛雲的某一個配置

    name="Qiniu.AK",
    value="asfadsfadf23rft66S4XM2GIK7FxfqefauYkcAyNGDAc" ,
    provider_name為"Qiniu"或自己定義的字符串
    provider_key為空
    

    cms 管理員維護模塊

    • [x] 標籤管理:名稱、圖片,是否啟用/禁用,排序、文章數量、用戶關注數量。
      • [x] 標籤增刪改
      • [x] 標籤列表,禁用
      • [x] 校正文章數量
    • [x] 技術頻道:封面圖、名稱、是否啟用/禁用、排序、編碼、備註描述、下屬標籤.一個技術頻道對應多個標籤
      • [x] 技術頻道增刪改
      • [x] 列表、禁用
    • [x] 隨筆管理:
      • [x] 審核隨筆/拉黑
      • [x] 管理員刪除隨筆
    • [x] 評論管理
      • [x] 後台審核通過/拉黑
      • [x] 管理員刪除評論
    • [x] 字典類別管理:編碼,名稱,排序
      • [x] 增刪改查
    • [x] 字典管理::編碼,名稱,排序,類別:如隨筆類型(原創、轉載、翻譯)
      • [x] 增刪改查

    cms 用戶端模塊

    • 技術頻道
      • [x] 首頁展示技術頻道
      • [x] 選擇技術頻道后,可再根據標籤查詢文章
    • 分類專欄管理:發布隨筆時可選擇單個分類。
      • [x] 分類增刪改(隨筆數量、圖片、名稱、排序)
      • [x] 分類列表,僅查看、編輯自己創建的分類專欄
    • 標籤:統計每個標籤下多少個文章、多少人關注
      • [x] 標籤列表
      • [x] 無限加載
      • [x] 最新/最熱 根據標籤名稱模糊查詢
      • [x] 已關注的標籤
      • [x] 熱門標籤
    • 隨筆
      • [x] 支持markdown,增刪改(僅自己的隨筆),修正分類專欄中的隨筆數量
      • [x] 支持富文本編輯隨筆
      • [x] 列表無限加載,按標籤查詢隨筆
      • [x] 點贊隨筆
      • 隨筆詳情頁
        • [x] 支持目錄導航(滾動時,固定至頂部位置),展示字數統計、預計閱讀時長;
        • [x] 作者介紹:頭像,昵稱,簽名,隨筆數;
        • [x] 展示文章類型:原創、轉載、翻譯
        • [ ] 相關文章
        • [ ] 推薦文章
    • 評論
      • [ ] 用戶關閉評論時,無法對隨筆進行評論
      • [ ] 評論隨筆(內容支持超鏈接、emoji)
      • [x] 刪除自己的評論
      • [x] 點贊評論
      • [x] 回複評論
    • 關注
      • [x] 關注/取消關注用戶
      • [x] 關注/取消關註標簽
      • [x] 我關注的用戶發隨筆
    • 個人主頁
      • 隨筆
        • [x] 用戶專欄分類展示
        • [x] 最新發布的隨筆
      • 關注
        • [x] 關注的用戶
        • [x] 粉絲
        • [x] 關注的標籤
    • 設置
      • 個人主頁設置
        • [x] 個人資料更新
      • 安全設置
        • [x] 密碼修改:快速登錄的賬號,初次設置時可留空
      • 博客設置
        • [x] 編輯器設置,(可切換markdown/富文本)
        • [x] 代碼風格配置(tango、native、monokai、github、solarized-light、vs)
    • 消息
      • [x] 評論:點贊評論、評論隨筆、回複評論
      • [x] 喜歡和贊:點贊隨筆、點贊評論
      • [x] 關注,誰誰關注了你

    腦圖分享

    http://naotu.baidu.com/file/6532431a2e1f0c37c93c5ffd1dd5b49c?token=87690a9bc64fbae1

    分組

    分為三種

    id  name        info
    1	Admin	    系統管理員
    2	CmsAdmin	內容管理員
    3	User	    普通用戶
    

    審計日誌

    大多數表存在如下8個字段,用於記錄行的變化狀態,is_deleted為軟刪除,執行刪除操作時,將其狀態置為true,默認實體類繼承 FullAduitEntity 即可擁有以下8個字段。該設計參考ABP中的實現。FullAduitEntity為泛型,默認id為long類型,FullAduitEntity<Guid>,即可改變主鍵類型,默認LinUser表主鍵long,保持create_user_id,delete_user_id,update_user_id都與LinUser的主鍵相同

    
    id	                bigint
    create_user_id  	bigint
    create_time	        datetime
    is_deleted	        bit
    delete_user_id  	bigint
    delete_time	        datetime
    update_user_id	    bigint
    update_time	        datetime
    
    
    

    相關技術

    • 數據庫相關:ORM:FreeSql+DataBase:MySQL5.6
    • ASP.NET Core3.1+WebAPI+RESTful
    • 簡化對象映射:AutoMapper
    • 身份認證框架:IdentityServer4
    • Json Web令牌:JWT
    • 文檔API:Swagger(Swashbuckle.AspNetCore)
    • 序列化:Newtonsoft.Json
    • 測試框架:Xunit
    • 日誌 Serilog
    • 依賴注入服務AutoFac
    • 通用擴展方法 Z.ExtensionMethods
    • 雲存儲:七牛雲 MQiniu.Core
    • 分佈式事務、EventBus:DotNeteCore.CAP
    • GitHub第三方授權登錄AspNet.Security.OAuth.GitHub
    • QQ第三方授權登錄AspNet.Security.OAuth.QQ
    • Docker
    • Azure DevOps
    • 健康檢查AspNetCore.HealthChecks.UI.Client
    • GitHub Action同步至Gitee

    分層結構(Layers)

    • framework
      • IGeekfan.CAP.MySql:為CAP實現了配合FreeSql的事務一致性擴展
    • identityserver4
      • LinCms.IdentityServer4:使用id4授權登錄
    • src
      • LinCms.Web:接口API(ASP.NET Core)
      • LinCms.Application:應用服務
      • LinCms.Application.Contracts:DTO,數據傳輸對象,應用服務接口
      • LinCms.Infrastructure:基礎設施,數據庫持久性的操作
      • LinCms.Core:該應用的核心,實體類,通用操作類,AOP擴展,分頁對象,基礎依賴對象接口,時間擴展方法,當前用戶信息,異常類,值對象
      • LinCms.Plugins 使用單項目實現某個業務的擴展,不需要主要項目結構,可暫時忽略。
    • test
      • LinCms.Test:對倉儲,應用服務或工具類進行測試

    功能特性

    • [x] Azure Devops CI/CD構建
    • [x] GitHub Action實現 GitHub Gitee代碼同步
    • [x] .Net Core結合AspNetCoreRateLimit實現限流
    • [x] 方法級別權限控制
    • 社交賬號管理:支持多種第三社交賬號登錄,不干涉原用戶數據,實現第三方賬號管理
    • 多語言
    • [x] 全局敏感詞處理
    • 日誌記錄,方便線上排查錯誤
    • [ ] 支持多種數據庫,並測試,
      • [x] Mysql
      • [ ] Postgresql
      • [ ] Sql Server
      • [ ] SQlite

    產品設計-評論模塊的設計

    下面我們來設計一個評論模塊,需要注意的是,一個評論模塊也有不同的方式。從展示形式,排序規則,按鈕功能設計,操作等方式都有詳細的分析設計,大家可以參考who shi pm 中的文章http://www.woshipm.com/pd/3548139.html,這裏主要講解下展式方式中的主題式的應用。

    1.主題式

    相信很多人都刷過抖音,他的評論主題式的強化版。

    特點為前三個是熱門評論(喜歡最多的評論),將評論分為二級,第一級採用時間倒序,第二級按照時間正序,有助於理解上下文關係。

    可以總結為如下功能點

    用戶操作:

    • [x] 評論隨筆(內容支持超鏈接、emoji)
    • [x] 點贊評論/取消點贊
    • [x] 回複評論
    • [x] 刪除自己的評論

    運營操作:

    • [x] 審核通過/拉黑評論
    • [x] 刪除任何評論
    • [x] 拉黑后的显示邏輯。(保留當前區塊、显示內容為:該評論因違規被拉黑)
    • 刪除:(如果是二級評論,直接軟刪除,如果是一級評論,軟刪除子評論和當前評論-需要提前提醒用戶)

    交互設計

    • 評論的字數長度(500)、emoji。
    • 點贊交互-動畫、消息通知/推送
    • 評論區域元素,需要有明確可點擊的區域,會跳轉到哪個地方。

    優化

    • 精選或者叫置頂評論
    • 該文章是否開放評論功能。
    • 熱門評論(點贊最多的評論)
    • 標註哪些評論是作者,標準哪些評論被用戶點贊。
    • @邏輯,emoji,舉報等

    2 平鋪式

    特點是不區分子父節點關係,比如現在博客園(大多數的主題),微信朋友圈,github。
    不過博客園,github,回復時,可選擇引用回復,方便用戶理解上下文關係。

    3.蓋樓式

    這種方式有點這種感覺 》>-,即.net core中間件請求方式。當回復越來越多時,显示的效果就越誇張。一層套一層的显示上下文的關係。下圖是網易新聞的評論效果。

    排行榜見解

    排行榜從心理學上分析,主要從四個方面影響着您:尋找權威 、參与比較 、關注主流 、自我確認。

    如何設計一個簡單的排行榜呢。。

    在一個博客隨筆中,我們設計一個3天、七天(周榜)、30天(月榜)、全部的榜單。以瀏覽量(權重1)、點贊量(20)、評論量(30)。權重可自己定義。

    1.默認取最新的隨筆

    前台傳create_time時,使用如下sql

    select * from `blog_article` order by create_time desc;
    

    2.傳排序方式為最近n天的熱榜時。

    參數:THREE_DAYS_HOTTEST(三天)、WEEKLY_HOTTEST(七天)、MONTHLY_HOTTEST(一個月)、HOTTEST(全部)

    mysql 查詢當前日期時間前三天數據

    select date_sub(now() ,interval 3 day);
    

    根據權重查詢

    select * from `blog_article` a 
    where a.`create_time`>(select date_sub(now() ,interval 3 day))
    order by (a.`view_hits` + a.`likes_quantity` * 20 + a.`comment_quantity` * 30) DESC, a.`create_time` DESC
    
    

    更多參考

    • 評論區如何設計?
    • 萬字長文深度分析:產品排行榜的設計和玩法
    • 想知道誰是你的最佳用戶?基於Redis實現排行榜周期榜與最近N期榜

    lin-cms 開源地址分享

    • 後端接口 https://github.com/luoyunchong/lin-cms-dotnetcore
    • 管理後台UI https://github.com/luoyunchong/lin-cms-vue
    • 前端UIhttps://github.com/luoyunchong/lin-cms-vvlog

    Demo

    • 用戶端 lin-cms-vvlog https://vvlog.baimocore.cn

      • 普通用戶:710277267@qq.com
      • 密碼:123qwe
    • 管理員 lin-cms-vue https://cms.baimocore.cn/

      • 管理員: admin
      • 密碼:123qwe

    預覽圖

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

    【其他文章推薦】

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

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

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※幫你省時又省力,新北清潔一流服務好口碑

    ※別再煩惱如何寫文案,掌握八大原則!

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 邊緣計算告訴你們公司空調怎麼開最省錢

    邊緣計算告訴你們公司空調怎麼開最省錢

    據統計,現代城市人的生活與工作同樓宇息息相關,超過80%的時間都是在城市樓宇中度過,樓宇智能毋庸置疑是影響深遠的關鍵研究課題。

    近年來,隨着邊緣計算技術的崛起,邊緣智能相關的場景應用拓展也成為科技公司爭相展現技術創新和商業價值的路徑,各種邊緣AI的解決方案亦應運而生,如華為雲智能邊緣平台IEF,一站式端雲協同多模態AI開發平台HiLens。據統計,現代城市人的生活與工作同樓宇息息相關,超過80%的時間都是在城市樓宇中度過,樓宇智能毋庸置疑是影響深遠的關鍵研究課題。本文將圍繞樓宇智能其中最重要的課題之一中央空調能效預測與管理來展開,目前,該課題面臨最大的瓶頸是:現有的大多數能效預測與管理方法僅限於雲端單任務,無法支撐中央空調能效模型在邊緣隱含的大量複雜場景上的能力。

    眾所周知,暖通空調系統(包括供暖,通風和空調)主導着商業建築的用電量。對暖通空調系統的現有研究表明,準確量化冷水機組的能效比(數值越大越節能)非常重要,近期提出的數據驅動的能效比預測可以被應用到雲上。但是,由於不同園區擁有不同型號的空調或不同種類的傳感器,導致不同邊緣各個項目在特徵、模型等方面區別很大,在小樣本情況下很難用一個通用模型適應所有的項目。

    近年來,華為雲邊緣雲創新lab與來自香港理工大學、IBM研究院、華中科技大學、同濟大學、深圳大學等知名校企研究團隊密切合作並持續開展技術研究,以邊緣樓宇智能領域場景為依託,希望逐步解決現實中隱含大量複雜場景的邊緣智能問題。有興趣的讀者歡迎關注2018到2020間年發表的多任務學習、多任務調度和多任務應用等歷史工作:

    通用算法:多任務遷移與邊緣調度

    基於元數據的多任務遷移關係發現

    Zheng, Z., Wang Y., Dai Q., Zheng H., Wang, D. “Metadata-driven task relation discovery for multi-task learning.” In Proceedings of IJCAI (CCF-A), 2019.

    在這篇論文中有一個多任務的實際應用案例,不同邊緣智能項目採用不同設備使得邊緣側模型不同,從而可以應用於多任務設定。這篇論文的亮點是引入元數據,元數據是數據集的描述信息,在複雜系統中用於日常系統運作,蘊含專家信息。基於元數據提取任務屬性,本論文設計了元數據任務屬性與樣本任務屬性層次結合的多任務通用AI算法(圖1)。相關論文專家評審也認為該技術在應用實踐中显示了實用價值,對機器學習項目真正落地具備重要意義,將成為當今大型組織感興趣的技術。

    圖1 顏色代表不同聚類簇,数字代表不同設備型號。基於樣本屬性的方法容易導致負遷移(同一簇中混淆不同型號設備模型,左圖),而基於元數據的方法可以避免負遷移(右圖)。

    多任務遷移學習的邊緣任務分配系統與實現

    Zheng, Z., Chen, Q., Hu, C., Wang, D., & Liu, F. “On-edge Multi-task Transfer Learning: Model and Practice with Data-driven Task Allocation.” In Proceedings of IEEE TPDS (CCF-A), 2019.

    Chen, Q., Zheng, Z., Hu, C., Wang, D., & Liu, F. “Data-driven task allocation for multi-task transfer learning on the edge. ” In Proceedings of IEEE ICDCS (CCF-B), 2019.

    多任務遷移學習是解決邊緣上樣本不足的典型做法。而目前邊緣上的任務分配調度工作通常假設不同的多個任務是同等重要的,導致資源分配在任務層面不夠高效。為了提升系統性能與服務質量,我們發現不同任務對決策的重要性是一個亟需衡量的重要指標。我們證明了基於重要性的任務分配是NP-complete的背包問題變種,並且在多變的邊緣場景下該複雜問題的解需要被頻繁地重新計算。因此我們提出一個用於解決該邊緣計算問題的AI驅動算法,並且在實際多變的邊緣場景中進行算法測試(圖2),與SOTA算法相比該算法能減少3倍以上的處理時間和近50%的能源消耗。

    圖2 根據邊緣場景動態進行任務分配調度

    邊緣應用:樓宇智能

    基於多任務的冷機負荷控制

    Zheng, Z., Chen, Q., Fan, C., Guan, N., Vishwanath, A., Wang, D., & Liu, F. “Data Driven Chiller Sequencing for Reducing HVAC Electricity Consumption in Commercial Buildings.” In Proceedings of ACM e-Energy, 2018. Best Paper Award.

    Zheng, Z., Chen, Q., Fan, C., Guan, N., Vishwanath, A., Wang, D., & Liu, F. “An Edge Based Data-Driven Chiller Sequencing Framework for HVAC Electricity Consumption Reduction in Commercial Buildings.” IEEE Transactions on Sustainable Computing, 2019.

    多任務可以應用於樓宇節能中。冷機是樓宇中的耗能大戶。冷機能效預測與管理,預測冷機負荷決策的能效比並優化冷機負荷決策,一直是樓宇智能最重要的研究問題之一。本研究觀測到,在冷機決策能效預測中,不同邊緣項目的設備型號和工況不同會導致最終需求的模型不同。這種情況下僅採用雲端單一模型的做法容易導致精度下降和決策失誤。本工作研發了一種邊雲協同的多任務冷機負荷決策框架(圖3),在利用現有端邊節點且不部署額外硬件的情況下,較當前工業界方法節能30%以上。

    圖3 邊雲協同的冷機負荷決策框架

    基於多任務的空調舒適度預測

    Zheng, Z., Dai Y., Wang D., “DUET: Towards a Portable Thermal Comfort Model.” In Proceedings of ACM BuildSys (Core rank A), 2019.

    Yang, L., Zheng, Z., Sun, J., Wang, D., & Li, X. A domain-assisted data driven model for thermal comfort prediction in buildings. In Proceedings of ACM e-Energy. 2018.

    空調舒適度預測是樓宇智能歷史長河中重要的研究課題之一。目前的舒適度預估方法通常要求額外的傳感器或者用戶反饋等人工干預,這使得規模化本身成為難題。基於機器學習方法的空調舒適度預測已被證明可以減少額外的人工干預。但在不同邊緣場景下,樓宇製冷類型、安裝傳感器類別等因素會使得雲上單一通用模型出現嚴重錯誤。本研究提出了一種多任務的方法進行空調舒適度的預測,在精度上較機理模型和單任務模型分別提升39%和31%。

    邊緣自適應任務定義

    基於以上項目,讀者可以了解到基於多任務的邊緣智能算法、系統與應用。值得注意的是,在使用多任務之前,首先需要回答任務如何定義和劃分的問題,如確定在一個應用內不同項目所需機器學習模型的數量以及各個模型的應用範圍。該方法目前通常只能由數據科學家和領域專家人工進行干預,自動化程度低,難以規模化複製。因此,邊緣自動定義機器學習任務是一個懸而未決但又重要的難題。

    為了在邊緣各種場景自適應地定義機器學習預測任務,華為雲邊緣雲創新Lab近日發表了研究論文《MELODY: Adaptive Task Definition of COP Prediction with Metadata for HVAC Control and Electricity Saving》。該研究提出了一種包含任務定義的多任務預測框架(MELODY),其中任務定義能夠自適應地定義並學習複數能效比預測任務。

    MELODY是第一個根據各種邊緣場景自適應定義能效比預測任務的方法。本研究工作為尋求自動有效的邊緣機器學習方法的研究人員和應用開發人員提供了一種有吸引力的機制,特別適用於對於元數據多樣化但數據樣本不足的複雜系統。MELODY的關鍵思想是使用元數據動態劃分多個任務,論文提出了元數據的數學定義以及提取元數據的2種來源和方法。

    該團隊在實際應用中評估該方案的性能:基於2個大型工業園區中的8座建築物中9台冷機進行4個月實驗。實驗結果表明,MELODY解決方案優於最新的能效比預測方法,並且能夠為兩個園區每月節省252 MWh的電量,較當前建築中冷水機的運行方式節省了35%以上的能源。

    MELODY論文已獲ACM e-Energy 2020接收:

    Zimu Zheng,Daqi Xie,Jie Pu,Feng Wang. MELODY: Adaptive Task Definition of COP Prediction with Metadata for HVAC Control and Electricity Saving. ACM e-Energy 2020. Australia.

    ACM e-Energy 屬於ACM EIG-Energy Interest Group、計算機與能源交叉的旗艦會議。

    1、論文接受率23.2%,歷年接受率在20%左右;

    2、與CCF-A的Ubicomp; CCF-B的ECAI、TKDD H5-index相同;

    3、55位評審程序委員會成員中包括Andrew A. Chien、Klara Nahrstedt、Prashant Shenoy等8位ACM/IEEE Fellow(約15%);

    4、評審程序委員會成員來自IBM研究院、伊利諾伊大學香檳分校、劍橋大學、華盛頓大學、普渡大學、馬薩諸塞大學阿默斯特分校、西蒙菲沙大學、南洋理工大學、清華大學、香港理工大學等國際知名校企;

    5、與CCF-A的STOC、ISCA、PLDI;CCF-B的IWQos、SIG Metric、COLT、HPDC、ICS、LCTES、SPAA等同屬ACM Federated Computing Research Conference (FCRC)系列的13個會議中,ACM FCRC頂會系列由Google、微軟、IBM、華為、arm、Xilinx等國際知名企業贊助。

    能效比預測

    基於冷機的暖通空調系統通常用於商業建築中,消耗的電力占建築物總用電量的40%至70%,這種消耗量主要由暖通空調系統的消耗量決定。商業建築物支付的電費(其中大部分歸於暖通空調系統)通常位於組織運營支出的前三名。這種趨勢給設施管理者帶來了巨大的壓力,他們需要通過減少與暖通空調系統相關的電力消耗來提高建築的能源利用效率。

    暖通空調的主要消耗來自冷機(見圖4)。典型的冷機負荷控制的有效性在很大程度上取決於冷機運行時的性能,即在不同的冷負荷條件下的能效比。能效比是衡量冷機能效的指標,指的是在單位輸入功率消耗下的輸出冷量。能效比通常大於1,值越大,意味着效率越高。在實踐中,設施管理人員通常在冷機部署到建築物期間,在首次測試和調試冷水機組時衡量能效比的初始信息,並用該初始信息來執行冷機負荷控制。初始信息測試時通常將冷量負荷視為唯一參數。然而,這些初始信息無法捕獲實際參數的影響,並且已被近期研究證明是不精確的。

    圖4 冷機示意圖

    本研究以能效比預測問題作為個例研究。能效比高度依賴於多種因素,例如工況、冷量需求、設備老化、天氣等。為了在冷水機組中捕獲這些因素,現有工作已經提出採用數據驅動方法。能效比預測問題可以看做是在訓練階段學習一種被稱為模型的“公式”,該公式在推理階段能夠輸出具有給定特徵的能效比。

    自適應任務定義

    現有方法通常假定預測任務的配置,比如同一應用下的預測模型的數量和預測模型的應用範圍,是由數據科學家或領域專家定義和固定的。下文比較三種被廣泛接受的設定:單任務設定、多任務設定和專家輔助的多任務設定。

    單任務設定

    一個最典型的、被廣泛接受的預測任務配置方法是基於固定的單任務設定:這意味着將所有數據集作為一個整體合併在一起,並訓練單個預測模型。研究人員可以使用任何機器學習算法(例如SVM、神經網絡、Boosting等)來學習這種模型,並在任何場景下的推理階段都應用訓練出的這單個模型。

    單任務設定假設對於同一應用下不同項目內不同的數據集,單個模型應足以描述所選特徵和能效比之間的關係。但是,這種假設可能並不總是成立。

    比方說有兩個園區採用了兩種類型的冷水機:園區H使用了特靈CVHG1100冷水機和園區J使用了開利W3C100冷水機,那麼應根據冷水機的型號調整在特徵和能效比之間的熱力學模型。邊緣用戶往往也期待看到應用到兩個邊緣項目的模型有所不同:即使兩種冷水機輸入相同的水溫等特徵值,輸出的能效比也應不同。但如果將兩個數據集合併在一起並訓練同一個能效比模型,通常很難在沒有人工干預的情況下確保這一點。

    論文作者過去的研究還表明,除了不同邊緣項目採用冷機型號不同可能導致模型不同外,可能導致模型不同的例子還包括:不同項目採用的工況和參數配置不同、不同項目採用的傳感器種類不同、不同季節採用特徵不同等(篇幅原因不再贅述,感興趣的讀者可以參考文章開頭提及的研究團隊歷史工作)。不同邊緣場景訓練出的模型應用範圍可能是迥乎不同的。所以對於不同的場景都採用單任務設定並非總是最佳選擇,這可能在實踐中引發重大錯誤,尤其是某些邊緣智能項目中訓練樣本的大小不足以在大量特徵中自動將場景彼此區分的情況。

    多任務設定

    但目前預測任務的配置,例如所需模型的數量以及模型的應用範圍,仍然是一個開放性問題。為了深入研究此問題,該團隊進一步驗證多任務設定而非單任務設定,也即觀察多個模型在多個測試集上的性能。在一個實際建築物中,使用了從冷機1到冷機5的訓練數據集訓練了5個模型(以下稱為M1 – M5)。然後在另外5個測試數據集(T1 – T5)的不同場景中測試了5個模型的性能。實驗及其結果分別如圖5-1、5-2所示。

    圖5-1 複數冷機訓練模型在不同冷機測試集下的實驗示意圖

    圖5-2 複數冷機訓練模型在不同冷機測試集下的預測準確率和樣本採集時間對比結果

    觀察結果显示,

    1)精度

    儘管是基於不同的數據集進行訓練,但是冷機1的模型在冷機2和冷機3的測試集上效果很好,而在冷機4和冷機5的測試集上卻導致嚴重錯誤。對於冷機2到冷機5的模型可以看到類似的觀察結果。這是因為冷機1到冷機3來自同一種冷機型號,而冷機4和冷機5是另一種型號。

    2)樣本採集時間

    如果按冷機來劃分任務,每個冷機任務至少需要81天的樣本。但如果按照型號劃分為2個任務,每個型號任務僅需30天的樣本。這是因為每個型號任務包含多台冷機採集的數據。

    根據上述精度和樣本採集時間的結果,與其考慮5個冷機從而定義5個冷機任務,在這個數據集下不如考慮2個型號(冷機1-3和冷機4-5)從而定義2個型號任務,在上述例子中可以降低63%左右的樣本採集時間,同時提升近10%的精度。

    專家輔助的多任務設定

    實際上,不僅冷機型號,隨時間變化的環境(例如,天氣條件)和工況(例如,供水溫度)也可以導致能效比模型的變化。藉助領域專家的知識,可以在構建的環境中定義固定的任務,並將這些固定的任務應用於不同的建築中。

    例如,基於建築環境研究中的領域專業知識,該團隊最近一項工作在三座建築物中根據工況給出了固定的50個任務,用於多任務冷機能效比預測;該團隊最近另外一項工作根據季節和製冷類型在160座建築物中給出了固定的4個任務,以進行多任務熱舒適性預測。

    但是,所需模型的數量及其應用範圍可以根據不同的邊緣項目場景而變化,而領域專家的配置很難跟隨不同邊緣項目動態擴展。例如,在一個建築物的少量數據集中,最好有3個任務,即訓練3種不同的模型進行能效比預測。但是在另一個包含1000座建築物的大型數據集中,最好有75個任務。在邊緣場景手動定義要預測的機器學習任務通常會導致成本過高或準確性降低,尤其是當任務隨項目和時間而動態變化時。因此,有必要針對不同場景自適應地定義任務。

    MELODY

    本研究工作旨在解決自適應任務定義問題,也即不同場景下自動化定義不同的任務,例如,在不同場景中確定需要使用的模型數量以及模型的應用範圍等。該團隊遇到三個主要挑戰,並提出了使用自適應任務定義方法的多任務預測框架(MELODY)。

    挑戰1:當前項目的目標未知,而且通常更糟糕的是,可能的任務候選集也未知。

    MELODY通過提出任務挖掘解決了第一個挑戰。它基於諸如任務森林等新穎結構和算法來自適應地定義任務,參見圖6。這使得MELODY可規模化到眾多建築和環境的能效比預測。

    圖6 任務森林的例子:數據表示模型訓練樣本,屬性表示模型應用範圍;節點表示子任務,包括數據、屬性和模型(若有);森林的每個根節點,也即每棵樹的頂點,表示各個子任務合併成的一個任務。對任務森林初始化和維護等具體實現和算法複雜度等證明,有興趣的讀者可以閱讀論文附錄。

    挑戰2:標誌能效比模型應用範圍的屬性未知,同時此類屬性的來源也在研究中。

    MELODY通過使用元數據作為任務屬性的來源來解決第二個挑戰。

    元數據由領域專家定義,用於建築管理系統的日常控制。例如,傳感器的名稱和建築物的類型是元數據。在MELODY框架中,該團隊提出了從數據庫的兩個來源中提取兩種元數據的方法。

    元數據包含潛在領域信息,藉助這些信息,能夠自適應地提取具有領域知識的任務,併為自動和強大的任務定義打開了方便之門,如圖7所示。

    圖7 基於元數據提取的任務定義(具體實現請參見論文)

    挑戰3:任務組合數量隨屬性數量指數增長;因此,冷機樣本不足以為所有組合訓練模型。

    MELODY通過利用多任務遷移學習克服了第三個挑戰。在多任務優化中,學習任務可以使用來自其他不同任務的知識,從而減少數據量的需求。

    多任務評估

    本研究工作通過將其應用於實際數據來評估方案的性能,在2個大型工業園區中的8座建築物中9台冷機進行4個月時間的實驗。園區情況可參見圖8。

    圖8 2個大型工業園區中的8座建築物及其冷機信息

    表1 任務定義輸出結果

    表1显示了通過任務定義算法挖掘出的任務的總體信息,在Park J和Park H中發現了兩組不同的任務集合。觀察显示不同項目模型的數量和使用模型時的場景都不同。藉助五分鐘的間隔數據,可以在Park J中挖掘出33個任務,這些任務模型的應用範圍主要根據冷機額定功率和平均濕度的來判斷。藉助一小時的時間間隔數據,Park H中僅有2個任務,應用範圍需要通過額定功率和額定製冷量來判斷。可以發現每個任務中的樣本量很小。 對於總共35個任務,有13個任務的樣本數少於100,其餘22個任務的樣本數少於1000。

    研究比較了幾種應用於冷機能效預測的典型方法:

    (1)工業界當前方法:初始配置文件(IP)利用安裝時測量的初始配置文件來估算未來的能效比,是目前工業界正在使用的方法。

    (2)學術界常用方法:單任務學習(STL)通過將來自每個數據集的所有任務的數據匯總在一起來學習一個模型;

    (3)近期研究工作:關於數據源的獨立多任務學習(IMTL),它獨立於數據源學習每個任務。例如,針對9個冷機固定9個任務,而無需在任務之間共享任何樣本或知識;

    (4)近期研究工作:具有領域知識的多任務學習(MTL),它學習具有由領域知識定義的任務聚類。例如,固定的50個任務,其中10個負載比和5個冷機。

    表2 各方法錯誤率提升

    表2結果显示,MELODY的任務定義可以比STL(單任務方法)有所提升。 但是,不正確的任務定義(即IMTL和MTL)對比單任務方法未能有所提升。這主要是因為與在不同數據集中(如MELODY)使用自適應任務的方法相比,IMTL和MTL在劃分任務後會生成較小的數據集,這導致部分任務內缺乏訓練樣本。當任務數量隨着屬性數目和時間推移而增加時,效果變得更差,因為任務遷移關係變得越來越複雜。在這種情況下,任務之間共享知識變得更具挑戰性,並容易導致一種被稱為負遷移的影響,也即從不相關的源域到目標域共享知識而導致的錯誤。可以看到,MELODY能解決相關問題,從而使得結果優於最新的能效比預測方法,將能效比預測誤差率降低了18.18-61.70%,最終能夠在兩個園區上每月節省252 MWh的電量,與當前建築中冷水機的運行方式相比節省了36.75%以上的能源。

    本文作者:鄭博士,華為雲邊緣雲創新Lab高級研究工程師,畢業於香港理工大學,主要研究方向是邊緣智能及AIoT。發表國際相關領域頂級會議及期刊 (TPDS、 IJCAI、 ICDCS、CIKM、TOSN、TIST等) 論文十餘篇,多次獲得最佳會議論文獎項,多次獲得關鍵技術突破、高價值專利和新服務孵化等華為傑出貢獻獎項。

    華為雲邊緣雲創新Lab:願景是探索端邊雲協同關鍵技術,構建無所不在的、極致體驗的智能邊緣雲。聯合工業夥伴和學術機構,共同致力於研究邊緣雲創新技術、孵化邊緣雲創新應用、構建邊緣雲繁榮生態。研究方向包括大規模智能邊緣雲平台、邊雲協同AI、端邊雲協同渲染與視頻加速。目前已孵化上線華為邊緣計算平台IEF,並貢獻首個基於Kubernetes的雲原生邊緣計算平台KubeEdge,獲尖峰開源技術創新獎、最佳智能邊緣計算技術創新平台等多項獎項;孵化的業內首個邊雲協同增量學習工作流即將上線華為雲HiLens服務、IEF服務;學術上近2年已發表7篇邊雲協同AI、雲原生邊緣計算相關頂會論文,獲多項最佳論文和優秀論文獎項。

     

    點擊關注,第一時間了解華為雲新鮮技術~

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

    【其他文章推薦】

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

    新北清潔公司,居家、辦公、裝潢細清專業服務

    ※別再煩惱如何寫文案,掌握八大原則!

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

    ※超省錢租車方案

    FB行銷專家,教你從零開始的技巧

  • Jmeter系列(26)- 詳解 JSON 提取器

    Jmeter系列(26)- 詳解 JSON 提取器

    如果你想從頭學習Jmeter,可以看看這個系列的文章哦

    https://www.cnblogs.com/poloyy/category/1746599.html

     

    為什麼要用 JSON 提取器

    • JSON 是目前大多數接口響應內容的數據格式
    • 在接口測試中,不同接口之間可能會有數據依賴,在 Jmeter 中可以通過後置處理器來提取接口的響應內容
    • JSON 提取器是其中一個可以用來提取響應內容的元件

     

    JSON 提取器的應用場景

    1. 提取某個特定的值
    2. 提取多個值
    3. 按條件取值
    4. 提取值組成的列表

     

    JSON 提取器

    我們通過實際栗子去講述理論知識點

     

    JSON 提取器界面介紹

     

    字段含義

     

    字段 結果
    Apply to 應用範圍,選默認的 main sample only 就行了
    Names of created variables
    • 接收提取值的變量名
    • 多個變量用 ; 分隔
    • 必傳
    JSON Path expression
    • json path 表達式,用來提取某個值
    • 多個表達式用 ; 分隔
    • 必傳
    Match No.(0 for Random)
    • 取第幾個值,多個值用 ; 分隔
    • 0:隨機,默認
    • -1:所有
    • 1:第一個值
    • 非必傳
    Compute concatenation var(suffix_ALL)
    • 如果匹配到多個值,則將它們都連接起來,不同值之間用 , 分隔
    • 變量會自動命名為 <variable name>_ALL 
    Default Values
    • 缺省值,匹配不到值的時候取該值,可寫error
    • 多個值用 ; 分隔
    • 非必傳

     

    入門栗子 

    栗子的前提

    這個栗子,我都會以這個地址的接口來完成 JSON 提取器的實戰慄子,大家可以註冊個賬號玩一玩哦

    http://api.yesapi.cn/docs.php?keyword=%E4%BC%9A%E5%91%98&channel=api

     

    測試計劃樹結構

    下面多個栗子都以這個測試計劃為基礎哦

     

    提取某個特定的值的栗子

    登錄接口響應

    登錄是執行其他接口的前置接口,所以要獲取用戶登錄后的 token、uuid

     

    提取 token

    相對路徑的方式

     

    提取 uuid

    絕對路徑的方式

     

    其他接口調用 token、uuid

     

    知識點

    • 提取某個特定值的方式有兩種:絕對路徑、相對路徑
    • 提其他接口可以通過 ${var} 這種格式,來獲取提取到的值

     

    綜合栗子

    • 上面講的是使用 JSON 提取器時的一個流程
    • 在實際項目中,接口的響應內容肯定是非常複雜的,而我們需要提取的值也是多樣化的,需要通過各種實戰慄子來講述清晰

     

    JSON 字符串

    這也是某個接口返回的響應內容,後面的栗子也是以這個 JSON 字符串為基礎來提取各種值

    感興趣也可以自己玩一玩:http://api.yesapi.cn/docs-api-App.User.GetList.html

    {
        "ret": 200,
        "msg": "V2.5.1 YesApi App.User.GetList",
        "data": {
            "total": 3,
            "err_msg": "",
            "err_code": 0,
            "users": [
                {
                    "role": "user",
                    "status_desc": "正常",
                    "reg_time": "2020-06-22 15:19:51",
                    "role_desc": "普通會員",
                    "ext_info": {
                        "yesapi_nickname": "",
                        "yesapi_points": 0
                    },
                    "uuid": "6D5EDCB459F0917A98106E07D5438C58",
                    "username": "fangjieyaossb",
                    "status": 0
                },
                {
                    "role": "user",
                    "status_desc": "正常",
                    "reg_time": "2020-06-22 14:27:17",
                    "role_desc": "普通會員",
                    "ext_info": {
                        "yesapi_nickname": "",
                        "yesapi_points": 0
                    },
                    "uuid": "0164DC0680F84DCE40D3DD4A36640ECA",
                    "username": "fangjieyaossa",
                    "status": 0
                },
                {
                    "role": "admin",
                    "status_desc": "正常",
                    "reg_time": "2020-03-23 22:48:32",
                    "role_desc": "管理員",
                    "ext_info": {
                        "yesapi_nickname": "",
                        "yesapi_points": 0
                    },
                    "uuid": "079BF6BB82AFCFC7084F96AECAF0519F",
                    "username": "fangjieyaoss",
                    "status": 0
                }
            ]
        }
    }

     

    提取單個值

    Jsonpath 結果
    $.data.total 2
    $..total 2
    $..users[0].role user
    $..uuid 079BF6BB82AFCFC7084F96AECAF0519F
    $.data.users[0].ext_info.yesapi_points 0

     

    重點

    • 如果匹配到多個值(像 $..uuid ),也只能提取到一個值
    • 如果想提取匹配到的所有 uuid,可以設置為 -1,結果如下圖

    還會告訴你匹配了多少個值 ${uuid_matchNr} ,記住,調用變量時,不再是 ${uuid} 而是 ${uuid_1} 、 ${uuid_2} 

     

    利用切片提取單個值

    和 Python  切片一樣的原理

    Jsonpath 結果
    $..users[2] 第三個 users
    $..users[-2] 倒數第二個users
    $..users[0,1] 前面兩個users
    $..users[:2] 第一、二個users
    $..users[1:2] 第二個users
    $..users[-2:] 倒數兩個users
    $..users[1:] 第二個開始的所有users

     

    提取多個值

    • 四種寫法類似,選一種方法自己熟記即可
    • 重點:提取多個值,提取器的 Match No. 必須填 -1

     

    $.data.users[*].role

    提取所有 role 字段值

    [*] 表示取數組的所有元素

     

    $..users..role_desc

    提取所有 role_desc 字段值

     

    $..reg_time

    提取所有 reg_time 字段值

     

    $..[*].username

    提取所有 username 字段值

     

    按條件提取值

    有時候只需要提取某個特定條件下的參數值

     

    語法格式

    [?(expression)]

     

    栗子

    Jsonpath 結果
    $..users[?(@.uuid)] 提取 users 裡面包含 uuid 字段的記錄
    $..users[?(@.reg_time > ‘2020-06-01’)] 提取 reg_time 字段大於 2020-06-01 的記錄
    $..users[?(@.role_desc =~ /.*會員.*?/i)] 提取 role_desc 字段包含會員的記錄
    $..users[?(@.status == 0)] 提取 status 字段等於 0 的記錄

     

    @

    代表當前節點,像上面的四個栗子,@代表 users 這個列表字段

     

    =~

    • 後面跟正則表達式,如果想提取包含指定字符的值,可以使用此正則: /.*指定字符串.*?/i 
    •  i  代表大小寫不敏感

     

    提取數據指定字段的值的栗子

    提取 users 第一條記錄的 uuid、username 字段的值

    $..users[0].['uuid','username']

     

    測試結果

    new_1={"uuid":"6D5EDCB459F0917A98106E07D5438C58","username":"luojunjiessb"}

     

    勾選 Compute concatenation var 的栗子

    JSON 提取器

     

    測試結果

    uuid_1=6D5EDCB459F0917A98106E07D5438C58
    uuid_2=0164DC0680F84DCE40D3DD4A36640ECA
    uuid_3=079BF6BB82AFCFC7084F96AECAF0519F
    uuid_ALL=6D5EDCB459F0917A98106E07D5438C58,0164DC0680F84DCE40D3DD4A36640ECA,079BF6BB82AFCFC7084F96AECAF0519F
    uuid_matchNr=3

     

    一個 JSON 提取器有多個 Jsonpath 的栗子

    JSON 提取器

     

    測試結果

    uuid1_1=6D5EDCB459F0917A98106E07D5438C58
    uuid1_2=0164DC0680F84DCE40D3DD4A36640ECA
    uuid1_3=079BF6BB82AFCFC7084F96AECAF0519F
    uuid1_matchNr=3
    uuid2_1=6D5EDCB459F0917A98106E07D5438C58
    uuid2_2=0164DC0680F84DCE40D3DD4A36640ECA
    uuid2_3=079BF6BB82AFCFC7084F96AECAF0519F
    uuid2_matchNr=3

     

    知識點

    • 如果有多個 Jsonpath 的時候,每個字段都必填值,且字段值的數量要一致(像上圖,每個字段都填了兩個值)
    • 勾不勾 Compute concatenation var 都行
    • 字段值數量不一致則無法提取值

     

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

    【其他文章推薦】

    新北清潔公司,居家、辦公、裝潢細清專業服務

    ※別再煩惱如何寫文案,掌握八大原則!

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

    ※超省錢租車方案

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

    網頁設計最專業,超強功能平台可客製化

  • mysql定時備份任務

    mysql定時備份任務

    簡介

    在生產環境上,為了避免數據的丟失,通常情況下都會定時的對數據庫進行備份。而Linux的crontab指令則可以幫助我們實現對數據庫定時進行備份。首先我們來簡單了解crontab指令,如果你會了請跳到下一個內容mysql備份
    本文章的mysql數據庫是安裝在docker容器當中,以此為例進行講解。沒有安裝到docker容器當中也可以參照參照。

    contab定時任務

    使用crontab -e來編寫我們的定時任務。

    0 5 * * 1 [command]
    

    前面的5個数字分別代表分、時、日、月、周,後面的 command為你的執行命令。
    假如你需要在每天晚上8點整執行定時任務,那麼可以這麼寫

    0 8 * * * [command]
    

    擴展:
    crontab -l 可以查看自己的定時任務
    crontab -r 刪除當前用戶的所有定時任務

    mysql備份

    快速上手

    這裏我的mysql數據庫是docker容器。假如你需要在每天晚上8點整執行定時任務,那麼可以這麼寫。
    首先執行命令crontab -e

    0 8 * * * docker exec mysql_container mysqldump -uroot -proot_password database_name > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql
    

    mysql_container 為你的數據庫容器名
    mysqldump 是mysql數據庫導出數據的指令
    -u 填寫root賬號
    -p 填寫root密碼
    database_name 需要備份的數據庫名
    /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql 備份文件,後面是文件名的格式

    如果你沒什麼要求,單純的只是想要備份,那麼上面那個命令就可以幫你進行定時備份。

    小坑: mysql備份的時候我使用了docker exec -it mysqldump ... 這樣的命令去做bash腳本,因為-i參數是有互動的意思,導致在crontab中執行定時任務的時候,沒有輸出數據到sql文件當中。所以使用crontab定時的對docker容器進行備份命令的時候不要添加-i參數。

    crontab優化

    我不建議直接在crontab -e裏面寫要執行的命令,任務多了就把這個文件寫的亂七八招了。
    建議把數據庫備份的命令寫成一個bash腳本。在crontab這裏調用就好了
    如:建立一個/var/backups/mysql/mysqldump.sh文件,內容如下

    docker exec mysql_container mysqldump -uroot -pmypassword database_name > /var/backups/mysql/$(date +%Y%m%d_%H%M%S).sql
    

    然後把文件改為當前用戶可執行的:

    chmod 711 /var/backups/mysql/mysqldump.sh
    

    執行crontab -e 命令修改成如下:

    0 20 * * * /var/backups/mysql/mysqldump.sh
    

    那麼這樣就比較規範了。

    mysql備份優化

    因為sql文件比較大,所以一般情況下都會對sql文件進行壓縮,不然的話磁盤佔用就太大了。
    假設你做了上面這一步 crontab優化,我們可以把mysqldump.sh腳本改成下面這樣:

    export mysqldump_date=$(date +%Y%m%d_%H%M%S) && \
    docker exec mysql_container mysqldump -uroot -pmypassword database_name> /var/backups/mysql/$mysqldump_date.sql && \
    gzip /var/backups/mysql/$mysqldump_date.sql
    find /var/backups/mysql/ -name "*.sql" -mtime +15 -exec rm -f {} \;
    

    export 在系統中自定義了個變量mysqldump_date,給備份和壓縮命令使用
    gzip 為壓縮命令,默認壓縮了之後會把源文件刪除,壓縮成.gz文件
    find ... 這行命令的意思為,查詢 /var/backups/mysql/目錄下,創建時間15天之前(-mtime +15),文件名後綴為.sql的所有文件 執行刪除命令-exec rm -f {} \;。總的意思就是:mysql的備份文件只保留15天之內的。15天之前的都刪除掉。

    數據恢復

    若一不小心你執行drop database,穩住,淡定。我們首先要創建數據庫被刪除的數據庫。

    >mysql create database database_name;
    

    然後恢復最近備份的數據。恢復備份的命令:

    docker exec -i mysql_container mysql -uroot -proot_password database_name < /var/backups/mysql/20200619_120012.sql
    

    雖然恢復了備份文件的數據,但是備份時間點之後的數據我們卻沒有恢復回來。
    如:晚上8點進行定時備份,但是卻在晚上9點drop database,那麼晚上8點到晚上9點這一個小時之內的數據卻沒有備份到。這時候就要使用binlog日誌了。

    binlog日誌

    binlog 是mysql的一個歸檔日誌,記錄的數據修改的邏輯,如:給 ID = 3 的這一行的 money 字段 + 1。
    首先登錄mysql后查詢當前有多少個binlog文件:

    > mysql show binary logs;
    +---------------+-----------+-----------+
    | Log_name      | File_size | Encrypted |
    +---------------+-----------+-----------+
    | binlog.000001 |       729 | No        |
    | binlog.000002 |      1749 | No        |
    | binlog.000003 |      1087 | No        |
    +---------------+-----------+-----------+
    

    查看當前正在寫入的binlog

    mysql> show master status\G;
    

    生成新的binlog文件,mysql的後續操作都會寫入到新的binlog文件當中,一般在恢複數據都時候都會先執行這個命令。

    mysql> flush logs
    

    查看binlog日誌

    mysql> show binlog events in 'binlog.000003';
    

    小知識點:初始化mysql容器時,添加參數--binlog-rows-query-log-events=ON。或者到容器當中修改/etc/mysql/my.cnf文件,添加參數binlog_rows_query_log_events=ON,然後重啟mysql容器。這樣可以把原始的SQL添加到binlog文件當中。

    恢複數據

    拿回上面例子的這段話。

    晚上8點進行定時備份,但是卻在晚上9點drop database,那麼晚上8點到晚上9點這一個小時之內的數據卻沒有備份到。。

    首先進入到mysql容器后,切換到/var/lib/mysql目錄下,查看binlog文件的創建日期

    cd /var/lib/mysql
    ls -l
    ...
    -rw-r----- 1 mysql mysql      729 Jun 19 15:54  binlog.000001
    -rw-r----- 1 mysql mysql     1749 Jun 19 18:45  binlog.000002
    -rw-r----- 1 mysql mysql     1087 Jun 19 20:58  binlog.000003
    ...
    

    從文件日期可以看出:當天時間為2020-06-21,binlog.000002文件的最後更新時間是 18:45 分,那麼晚上8點的備份肯定包含了binlog.000002的數據;
    binlog.000003的最後更新日期為 20:58 分,那麼我們需要恢復的數據 = 晚上8點的全量備份 + binlog.000003的 20:00 – 執行drop database命令時間前的數據。

    恢復命令格式:

    mysqlbinlog [options] file | mysql -uroot -proot_password database_name
    

    mysqlbinlog常用參數:

    –start-datetime 開始時間,格式 2020-06-19 18:00:00
    –stop-datetime 結束時間,格式同上
    –start-positon 開始位置,(需要查看binlog文件)
    –stop-position 結束位置,同上

    恢復備份數據和binlog數據前建議先登錄mysql后執行flush logs生成新的binlog日誌,這樣可以專註需要恢複數據的binlog文件。
    首先我們需要查看binlog日誌,在哪個位置進行了drop database操作:

    mysql> show binlog events in 'binlog.000003';
    +---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------+
    | Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                                                                                                        |
    +---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------+
    | binlog.000003 |   4 | Format_desc    |         1 |         125 | Server ver: 8.0.20, Binlog ver: 4                                                                                                           |
    | binlog.000003 | 125 | Previous_gtids |         1 |         156 |                                                                                                                                             |
    | binlog.000003 | 156 | Anonymous_Gtid |         1 |         235 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                                                                        |
    | binlog.000003 | 235 | Query          |         1 |         318 | BEGIN                                                                                                                                       |
    | binlog.000003 | 318 | Rows_query     |         1 |         479 | # INSERT INTO `product_category` SET `name` = '床上用品' , `create_time` = 1592707634 , `update_time` = 1592707634 , `lock_version` = 0      |
    | binlog.000003 | 479 | Table_map      |         1 |         559 | table_id: 139 (hotel_server.product_category)                                                                                               |
    | binlog.000003 | 559 | Write_rows     |         1 |         629 | table_id: 139 flags: STMT_END_F                                                                                                             |
    | binlog.000003 | 629 | Xid            |         1 |         660 | COMMIT /* xid=2021 */                                                                                                                       |
    | binlog.000004 | 660 | Anonymous_Gtid |         1 |         739 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                                                                                        |
    | binlog.000004 | 739 | Query          |         1 |         822 | drop database hotel_server /* xid=26 */                                                                                                     |
    +---------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------------------------------------------------------------------------------+
    

    根據上面的日誌,我們可以看到,在End_log_pos = 822 的位置執行了drop database操作,那麼使用binlog恢復的範圍就在2020-06-19 20:00:00 – 660 的位置。為什麼是660?因為drop database的上一個事務的提交是660的位置,命令如下:

    mysqlbinlog --start-datetime=2020-06-19 20:00:00 --stop-position=660 /var/lib/mysql/binlog.000003 | mysql -uroot -proot_password datbase_name
    

    如果你的範圍包括了822的位置,那麼就會幫你執行drop database命令了。不信你試試?
    執行完上面的命令,你的數據就會恢復到drop database前啦!開不開心,激不激動!

    總結

    因為mysql定時備份是在生產環境上必須的任務。是很常用的。所以我就迫不及待的寫博客。當然也很感謝我同事的幫助。這篇文章已經寫了三天了,因為我也是在不斷地試錯,不斷的更新文章。避免把錯誤的知識點寫出來。如果幫到你了,關注我一波唄!謝謝。

    個人博客網址: https://colablog.cn/

    如果我的文章幫助到您,可以關注我的微信公眾號,第一時間分享文章給您

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

    【其他文章推薦】

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

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

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    新北清潔公司,居家、辦公、裝潢細清專業服務

    ※推薦評價好的iphone維修中心

  • 快速打造屬於你的接口自動化測試框架

    快速打造屬於你的接口自動化測試框架

    1 接口測試

    接口測試是對系統或組件之間的接口進行測試,主要是校驗數據的交換,傳遞和控制管理過程,以及相互邏輯依賴關係。
    接口自動化相對於UI自動化來說,屬於更底層的測試,這樣帶來的好處就是測試收益更大,且維護成本相對來說較低,是我們進行自動化測試的首選

    2 框架選型

    目前接口自動化的框架比較多,比如jmeter,就可以集接口自動化和性能測試於一體,該工具編寫用例效率不高;還有我們常用的postman,結合newman也可以實現接口自動化;Python+unittest+requests+HTMLTestRunner 是目前比較主流的測試框架,對python有一定的編碼要求;
    本期我們選擇robotframework(文中後續統一簡稱為RF)這一個比較老牌的測試框架進行介紹,RF是一個完全基於 關鍵字 測試驅動的框架,它即能夠基於它的一定規則,導入你需要的測試庫(例如:其集成了selenium的測試庫,即可以理解為操作控件的測試底層庫),然後基於這些測試庫,你能應用TXT形式編寫自己的關鍵字(支持python和java語言,這些關鍵字即你的庫組成),之後,再編寫(測試用例由測試關鍵字組成)進行測試;他支持移動端、UI自動化和接口自動化的測試

    3 環境搭建

    • python的安裝:目前選取的python3以上的版本,RF的運行依賴python
    • robotframework:參考https://www.jianshu.com/p/9dcb4242b8f2
    • jenkins:用於調度RF的用例執行環境
    • gitlab:代碼倉庫

    4 需求

    4.1 需求內容
    接口內容:實現一個下單,並檢查訂單狀態是否正常的場景;該需求涉及到如下三個接口

    • 下單接口
    • 訂單結果查詢接口
    • 下單必須帶上認證標識,生成token的接口

    環境覆蓋:需要支持能在多套環境運行,比如測試和預發布環境
    系統集成:需要能夠集成在CICD中,實現版本更新后的自動檢測

    4.2 用例設計
    4.2.1 用例設計,根據業務場景設計測試用例,方便後續實現

    4.2.2 測試數據構造,預置不同環境的測試數據,供實現調用

    5 整體實現架構

    接口測試實現層:在RF,通過引用默認關鍵字 RequestsLibrary (實現http請求)和通過python自定義關鍵字來完成用例實現的需求;
    jenkins調度:在jenkins上配置一個job,設置好RF用例執行的服務器和發送給服務器相關的RF執行的指令,並且在jenkins中配置好測試報告模板,這樣用例便可以通過jenkins完成執行併發送測試結果給項目干係人;
    生成用例執行的API:上圖中藍色部分,就是為了將jenkins的job生成一個可訪問api接口,方便被測項目的CICD集成;
    集成到被測系統CICD流程:將上面步驟中封裝的API配置在被測應用的__gitlab-ci.yml__中,完成整個接口自動化的閉環

    6 RF用例實現

    6.1 引用的內置關鍵字

    • RequestsLibrary 構造http的請求,get|post等請求
    getRequests
    # get請求的入參
        [Arguments]    ${url_domain}    ${getbody}    ${geturl}    ${getToken}
        Create session    postmain    ${url_domain}
    # 定義header的內容
        ${head}    createdictionary    content-type=application/json    Authorization=${getToken}    MerchantId=${s_merchant_id}
    # get請求
        ${addr}    getRequest    postmain    ${geturl}    params=${getbody}    headers=${head}
    # 請求狀態碼斷言
        Should Be Equal As Strings    ${addr.status_code}    200
        ${response_get_data}    To Json    ${addr.content}
    # 返回http_get請求結果
        Set Test Variable    ${response_get_data}	 
        Delete All Sessions
    

    6.2 自定義關鍵字

    • getEnvDomain 用於從自定義的configs.ini文件獲取對應環境的微服務的請求域名
      configs.ini的內容
    # 獲取configs.ini的內容
    import configparser
    def getEnv(path,env):
        config = configparser.ConfigParser()
        config.read(path)
        passport = config[env]['passport']
        stock=config[env]['stock']
        finance=config[env]['finance']
        SUP = config[env]['SUP']
        publicApi = config[env]['publicApi']
        publicOrder = config[env]['publicOrder']
        data_dict={'passport':passport,'stock':stock,'finance':finance,'SUP':SUP,'publicApi':publicApi,'publicOrder':publicOrder}
        return data_dict
    
    • excelTodict 用戶將excel中的內容作為字典返回
    import xlrd
    
    '''
    通用獲取excel數據
    @:param path excel文件路徑
    @:param sheet_name excel文件裏面sheet的名稱 如:Sheet1
    @:env 環境,是IT還是PRE
    '''
    def getExcelDate(path, sheet_name,env):
        bk = xlrd.open_workbook(path)
        sh = bk.sheet_by_name(sheet_name)
        row_num = sh.nrows
        data_list = []
        for i in range(1, row_num):
            row_data = sh.row_values(i)
            data = {}
            for index, key in enumerate(sh.row_values(0)):
                data[key] = row_data[index]
            data_list.append(data)
        data_list1 = []
        for x in data_list:
            #print('這是'+str(x))
            if(x.get('env')==env):
                data_list1.append(x)
        return data_list1
    
    • getToken 提供接口下單的授權token
    *** Keywords ***
    # 根據傳入的clientid、secret生成對應的token
    getToken
        [Arguments]    ${client_id}    ${client_secret}    ${url_domain}
        Create session    postmain    ${url_domain}
        ${auth}    createdictionary    grant_type=client_credentials    client_id=${client_id}    client_secret=${client_secret}
        ${header}    createdictionary    content-type=application/x-www-form-urlencoded
        ${addr}    postRequest    postmain    /oauth/token    data=${auth}    headers=${header}
        Should Be Equal As Strings    ${addr.status_code}    200
        ${responsedata}    To Json    ${addr.content}
        ${access}    Get From Dictionary    ${responsedata}    access_token
        ${token}    set variable    bearer ${access}
        Set Test Variable    ${token}
        Delete All Sessions
    
    • getAllDate 獲取該用例下的所有數據
    getAllData
        [Arguments]    ${row_no}
        getEnvDomain
        getBalance    ${row_no}
        getStockNum    ${row_no}
        getSupProPrice    ${row_no}
        getProPrice    ${row_no}
        Set Test Variable    ${publicOrderUrl}
        Set Test Variable    ${FPbalance}
        Set Test Variable    ${Pbalance}
        Set Test Variable    ${Sbalance}
        Set Test Variable    ${Jbalance}
        Set Test Variable    ${Cardnum}
        Set Test Variable    ${sprice}
        Set Test Variable    ${price}
        Set Test Variable    ${j_merchant_id}
        Set Test Variable    ${s_merchant_id}
        Set Test Variable    ${stock_id}
        Set Test Variable    ${p_product_id}
        Set Test Variable    ${s_product_id}
    
    
    • 實現demo
    *** Settings ***
    Test Template
    Resource          引用所有資源.txt
    
    *** Test Cases ***
    *** Settings ***
    Test Template
    Resource          引用所有資源.txt
    
    *** Test Cases ***
    01 下單卡密直儲商品
        [Tags]    order
        LOG    ---------------------獲取下單前的數量、餘額------------------------------------------
        getAllData    0
        ${Cardnum1}    set variable    ${Cardnum}
        ${FPbalance1}    set variable    ${FPbalance}
        ${Pbalance1}    set variable    ${Pbalance}
        ${Sbalance1}    set variable    ${Sbalance}
        ${Jbalance1}    set variable    ${Jbalance}
        ${CustomerOrderNo1}    Evaluate    random.randint(1000000, 9999999)    random
        ${Time}    Get Time
        log    ------------------------下單操作-------------------------------------------------------
        getToken    100xxxx    295dab07a9xxxx9780be0eb95xxxx   ${casUrl}
        ${input_cs}    create dictionary    memberId=${j_merchant_id}    clientId=1xxx079    userId=string    shopType=string    customerOrderNo=${CustomerOrderNo1}
        ...    productId=${p_product_id}    buyNum=1    chargeAccount=otest888888    notifyUrl=string    chargeIp=string    chargePassword=string
        ...    chargeGameName=string    chargeGameRole=string    chargeGameRegion=string    chargeGameSrv=string    chargeType=string    remainingNumber=0
        ...    contactTel=string    contactQQ=string    customerPrice=0    poundage=0    batchNumber=    originalOrderId=string
        ...    shopName=string    appointSupProductId=0    stemFromSubOrderId=123456    externalBizId=456789
        postRequests    ${publicOrderUrl}    ${input_cs}    /api/Order    ${token}
        ${data}    get from dictionary    ${responsedata}    data
        ${orderid}    get from dictionary    ${data}    id
        sleep    6
        ${getdata}    create dictionary    Id=${orderid}    PageIndex=1    PageSize=1
        getRequests    ${publicOrderUrl}    ${getdata}    /api/Order/GetList    ${token}
        ${datalist}    get from dictionary    ${response_get_data}    data
        ${data}    get from dictionary    ${datalist}    list
        ${dict}    set variable    ${data}[0]
        ${orderOuterStatus}    get from dictionary    ${dict}    orderOuterStatus
        LOG    ---------------------獲取下單后的數量、餘額----------------------------------------------
        getAllData    0
        ${Cardnum2}    set variable    ${Cardnum}
        ${FPbalance2}    set variable    ${FPbalance}
        ${Pbalance2}    set variable    ${Pbalance}
        ${Sbalance2}    set variable    ${Sbalance}
        ${Jbalance2}    set variable    ${Jbalance}
        ${sprice}    set variable    ${sprice}
        ${price}    set variable    ${price}
        log    ------------------斷言-----------------------------------------------------------------
        ${Cardnum3}    Evaluate    ${Cardnum1}
        ${Jbalance3}    Evaluate    ${Jbalance1}
        ${Sbalance3}    Evaluate    ${Sbalance1}
        ${Pbalance3}    Evaluate    ${Pbalance1}
        should be true    ${orderOuterStatus}==90
        should be true    ${Cardnum3}==${Cardnum2}
        should be true    ${Jbalance3}==${Jbalance2}
        should be true    ${Sbalance3}==${Sbalance2}
        should be true    ${Pbalance3}==${Pbalance2}
    
    

    7 集成到CICD流程

    7.1 jenkins配置job
    通過jenkins的參數化構建,定義it和pre兩套環境

    jenkins發送RF執行的命令

    7.2 封裝的jenkins_job的執行接口地址
    通過python的flask框架,根據測試和pre兩套環境包一層jenkins的job執行接口

    __author__ = 'paul'
    
    # !/usr/bin/env python
    # -*- coding: utf-8 -*-
    from flask import Flask, abort, request, jsonify
    import jenkins
    
    server = jenkins.Jenkins('http://10.0.1.xxx:80', username='xxx', password='fuluxxxx')
    
    app = Flask(__name__)
    
    tasks = []
    
    # it的測試集合http請求接口
    @app.route('/test/it', methods=['get'])
    def robot_Test_It():
        server.build_job('CI_FuluOrder', {'environment': 'IT'})
        return jsonify({'result': 'success'})
    
    # pre的測試集合http請求接口
    @app.route('/test/pre', methods=['get'])
    def robot_Test_Pre():
        server.build_job('CI_FuluOrder', {'environment': 'PRE'})
        return jsonify({'result': 'success'})
    
    if __name__ == "__main__":
        # 將host設置為0.0.0.0,則外網用戶也可以訪問到這個服務
        app.run(host="0.0.0.0", port=80, debug=True)
    
    

    7.3 將上述flask封裝的接口打包成鏡像
    根據dockerfile生成鏡像

    FROM python:3.6
    WORKDIR /app
    EXPOSE 80
    COPY .	.
    RUN pip install -r requirements.txt 
    ENTRYPOINT ["python","robotTestApi.py"]
    
    

    7.4 將鏡像部署到kubernetes,對外提供服務
    供觸發測試執行的調用入口 ,這部分封裝的接口部署在本地的k8s集群下ordermiddle

    IT: http://ordermiddle.xxx.cn/test/it
    pre:http://ordermiddle.xxx.cn/test/pre

    7.5 被測項目的CICD集成接口自動化測試
    gitlab目前採取直接對CICD腳本加入測試步驟,在部署到容器30秒后(考慮到容器在K8S啟動時間)調用測試接口

    7.6 發送測試報告

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
    【其他文章推薦】

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

    台北網頁設計公司這麼多該如何選擇?

    ※智慧手機時代的來臨,RWD網頁設計為架站首選

    ※評比南投搬家公司費用收費行情懶人包大公開

    ※幫你省時又省力,新北清潔一流服務好口碑

    ※回頭車貨運收費標準

  • 美國迪士尼致力環保 將停用一次用塑膠吸管

    摘錄自2018年7月27日蘋果日報美國報導

    美國娛樂巨頭華特迪士尼公司( Walt Disney Company)昨天(26日)宣示,明年中期以前,迪士尼樂園等將停止使用一次性塑膠吸管。鑑於塑料垃圾造成的海洋污染日益嚴重,為保護地球環境,歐美正在推廣相同的措施。

    迪士尼指出,此舉將可每年減少1.75億根以上的吸管、1.3億根攪拌棒,強調本次嘗試是迪士尼履行環保責任的一環。

    共同社則報導,據與迪士尼方面簽訂許可協議的東方樂園公司稱,由於位於千葉縣浦安市的東京迪士尼度假區,運營母體不同,因此不受此次華特迪士尼公司決定的影響。然而該公司也指,「正在研究減少塑料廢棄物」。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

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

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

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    新北清潔公司,居家、辦公、裝潢細清專業服務

    ※推薦評價好的iphone維修中心

  • 葡西法三國簽署能源互聯協議 法國將關閉所有煤電廠

    摘錄自2018年7月28日新華社報導

    葡萄牙、西班牙和法國27日在葡萄牙首都里斯本舉行的第二屆能源互聯峰會上正式簽署了三國能源互聯協議。

    根據協議,西葡兩國同歐洲的能源互聯水平到2020年達到10%,2030年達到15%。此外,歐盟委員會將投資5.7億歐元在西班牙以北的比斯開灣建造一個用於連接西班牙、葡萄牙和法國的電力互聯項目。

    葡萄牙總理科斯塔、西班牙首相桑切斯和法國總統馬克宏在會後舉行了聯合記者會。馬克宏表示,最晚到2022年,法國將關閉所有煤電廠。

    科斯塔說,葡萄牙計劃到2020年使清潔能源占比超過60%,葡萄牙在逐步減少煤電行業投入的同時尋求清潔能源出口。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

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

    台北網頁設計公司這麼多該如何選擇?

    ※智慧手機時代的來臨,RWD網頁設計為架站首選

    ※評比南投搬家公司費用收費行情懶人包大公開

    ※幫你省時又省力,新北清潔一流服務好口碑

    ※回頭車貨運收費標準

  • 季節變化間顯現 科學家找到人為暖化的「指紋」

    環境資訊中心綜合外電;姜唯 編譯;林大利 審校

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

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

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

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

    南投搬家公司費用需注意的眉眉角角,別等搬了再說!

    新北清潔公司,居家、辦公、裝潢細清專業服務

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

  • 卡爾大火極具破壞性 加州史上第9大

    摘錄自2018年7月31日中央社加州報導

    美國加州北部野火「卡爾大火」(Carr Fire)已奪走至少六條人命,在今夏極度乾燥的美西地區數十起火災中災情最嚴重,森林防火廳官員表示,據信這是加州史上第九大破壞性大火。

    美聯社報導,加州森林防火廳(CalFire)發言人麥克林(Scott Mclean)表示,這場大火目前據信是加州史上第九大破壞性大火,燒毀至少818棟房屋和311棟附屬建築物,並造成165棟房屋受損。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

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

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

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※幫你省時又省力,新北清潔一流服務好口碑

    ※別再煩惱如何寫文案,掌握八大原則!

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!