研究實證!在牛屁股畫假眼睛 能嚇退打獵的獅子

摘錄自2020年8月13日聯合新聞網報導

一項最新研究發現,在牛屁股畫上假眼睛,能有效降低遭獅子或獵豹等掠食動物襲擊的風險。每日郵報與Phys.org報導,這項研究為期四年,由澳洲和波札那的學術與保育單位共同執行,地點選在家畜與掠食動物並存的歐卡萬哥三角洲(Okavango Delta)地區。

研究人員與當地農民合作,對14個最近遭受獅子攻擊的牛群進行塗漆。牛群被分成3組。一組在牛屁股畫上假眼,另外一組畫上簡單的叉號,最後一組保持原狀。結果發現,畫上假眼的牛完全沒事,有4頭畫叉與15頭保持原狀的牛被殺。

研究論文認為,許多生物靠著視覺訊號避免被補食,如蛾、蝴蝶、軟體動物和鳥類等,「研究期間進行塗漆的牲口,可靠著假的視覺器官嚇阻獅子和獵豹等伏擊掠食動物發動攻擊。」

研究人員已經印製英文與札那文的文宣手冊,也承認塗假眼仍有侷限,但波札那保育團體人員告訴南非媒體,「在保護區的邊界,農民與野生動物的衝突可能非常激烈,與野生動物共存讓部分社區承擔巨大的代價」,「我們希望這個簡單、低成本方法能減少部分農夫的負擔。」

※ 本文與 行政院農業委員會 林務局   合作刊登

土地利用
國際新聞
波札那
經濟動物
野生動物和農業共存
與野共生案例故事

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

【其他文章推薦】

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

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

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

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

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

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

格陵蘭冰融已難挽回 全球海平面恐升6公尺

摘錄自2020年08月16日中央通訊社格陵蘭報導

新研究顯示,格陵蘭(Greenland)冰層可能已經融化到無法挽回的地步,無論全球以多快的速度降低溫室氣體排放,冰層仍可能繼續融化。如果格陵蘭的冰全部融化,全球海平面平均將上升6公尺。

路透社報導,科學家研究橫跨北極234個冰川截至2018年的34年數據發現,年降雪量已經不足以補充冰川在夏季融化而流失的雪和冰。冰川融化已造成全球海平面每年平均上升1公釐。如果格陵蘭的冰全部融化,足以淹沒全球許多沿海城市,不過這個過程將花上數十年。

過去30年來,北極暖化的速度比起全球其他區域至少快兩倍,此現象被稱為「北極放大」效應,而極地海冰在今年7月創下40年來最低點。科學家表示,全球仍能透過降低碳排來減緩氣候變遷,即使格陵蘭難再累積覆蓋其200萬平方公里的冰層,遏制全球氣溫上升也能放慢冰層流失的速度。

氣候變遷
國際新聞
格陵蘭
冰川融化
海平面上升

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

溫室效應越來越嚴重 《魔戒》名場景將不復存在

摘錄自2020年8月16日自由時報報導

隨著地球的溫室效應越來越嚴重,世界各地的冰川都出現融化危機,其中包括曾在知名奇幻電影《魔戒》及《哈比人》電影中出現的紐西蘭南阿爾卑斯山(Southern Alps)的冰川,未來《魔戒》中的「迷霧山脈」可能美景不再。

綜合外媒報導,英國利茲大學(University of Leeds)紐西蘭國家水與大氣研究所(NIWA)合作,研究人員發現,南阿爾卑斯山的冰川自從小冰河時期結束以來,消失速度已增快2倍,而且近幾十年中,冰川在小冰河時期保有的體積已經融化近77%,其中1978年至2019年間就消失了17%;研究人員強調,全球冰川融化的嚴重性,不僅使依賴冰川融化供水、水力發電與灌溉農田的當地居民未來無水可用,全球高山冰川與冰蓋融化,也造成海平面上升25%。

研究人員認為,南阿爾卑斯山的冰川的「用水高峰(Peak Water)」或稱冰川融化所供應水資源已超過臨界點,未來可用水將越來越少,必須制定計畫以維護當地的水資源供應。

氣候變遷
國際新聞
紐西蘭
溫室效應
冰川融化
阿爾卑斯山

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

【其他文章推薦】

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

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

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

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

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

強風助長 希臘科孚島森林野火延燒

摘錄自2020年8月17日中央社報導

希臘不少有錢人置產的科孚島(Corfu)一座松樹林今(17日)發生大火,強風助長下,火勢在東北沿岸持續延燒。

法新社報導,野火爆發點鄰近艾米提斯區(Erimitis)樹木林立的海濱城鎮阿吉歐史芬尼(Agios Stefanos),而當地名聲最顯赫的居民莫過於羅斯契德(Rothschild)家族及阿涅利(Agnelli)家族。

希臘當局表示,消防人員出動12輛消防車,並在飛機支援下力阻野火在這個英國媒體譽為「海上肯辛頓」(Kensington-on-sea)的地區蔓延。

希臘夏季溫度動輒超過攝氏30度,時常傳出野火。2018年7月,雅典東北濱海度假城鎮瑪蒂(Mati)的一場火勢造成102人喪生,為希臘近代史最嚴重火災。

土地利用
國際新聞
希臘
森林野火

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

【其他文章推薦】

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

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

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

※超省錢租車方案

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

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

百公里時速「火龍捲」襲擊北加州 美西迎70年來最嚴重熱浪

摘錄自2020年8月17日東森新聞報導

美國國家氣象局(National Weather Service)15日針對北加州發布龍捲風警報,而且這次是稀有的火龍捲警報,由加州洛亞爾頓的野火火源的高溫引起熱空氣與濃煙上升變成「火積雲」(pyrocumulonimbus),形成時速近100公里的火龍捲。

駭人的火龍捲15日在內華達州邊境被發現,是當空氣中的漩渦亂流因為高熱及風向造成的湍流結合而形成,在旋風內有火焰。當這些渦旋空氣繼續收緊至類似龍捲風的結構時,可以吸入燃燒中的碎塊雜物及可燃氣體,從而使旋風點起火焰。龍捲風的存在可以幫助野火更快地傳播。

美國西部各州面臨70年來最嚴重的熱浪侵襲,超過800萬人收到政府的高溫警報,沙加緬度甚至預計達到攝氏43度。加州14日甚至因為溫度過高,電網不堪負荷,導致全州陷入停電。

氣候變遷
國際新聞
美國
熱浪
野火
龍捲風

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

【其他文章推薦】

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

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

※超省錢租車方案

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

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

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

越南貓肉市場猖獗 估百萬貓遭吃下肚

摘錄自2020年8月18日公視報導

根據國際動保團體的最新調查,過去只在越南北部較為普遍的貓肉餐廳,現在已經擴展到全國各地,每年大約會吃掉100萬隻貓,而越南政府從1998年以來的吃貓肉禁令,已經在今年1月廢除,動保團體擔心情況將會雪上加霜。

越南人在二戰後民不聊生,經常抓貓狗充飢,雖然政府在1998年曾明令禁止,但民間吃貓肉的風氣仍舊存在。有老一輩的越南人認為,月初吃貓會獲得好運,避免遭遇不幸,還有的認為經常吃貓肉可以像貓一樣敏捷;而有的餐廳將貓肉稱作老虎寶寶,或小老虎之類的,讓人相信吃了可以強身壯陽。

今年1月間越南政府廢除吃貓禁令後,動保團體發現,越南各地貓肉餐廳頓時多了起來,遍及會安、胡志明市等地,而距離河內兩個小時車程的太平省,就是貓隻屠宰場的大本營,整個屠宰過程極不人道。

在揭發業者抓捕屠殺貓隻的殘忍行徑後,動保團體希望越南民眾別再吃貓肉。

生物多樣性
國際新聞
越南

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

「氣候倡議者」賀錦麗出任拜登副手 智庫:絕對有利氣候外交

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

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

【其他文章推薦】

※超省錢租車方案

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

※回頭車貨運收費標準

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

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

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

第 9 篇:實現分類、標籤、歸檔日期接口

作者:HelloGitHub-追夢人物

我們的博客有一個側邊欄功能,分別列出博客文章的分類列表、標籤列表、歸檔時間列表,通過點擊側邊欄對應的條目,還可以進入相應的頁面。例如點擊某個分類,博客將跳轉到該分類下全部文章列表頁面。這些數據的展示都需要開發對應的接口,以便前端調用獲取數據。

分類列表、標籤列表實現比較簡單,我們這裏給出接口的設計規範,大家可以使用前幾篇教程中學到的知識點輕鬆實現(具體實現可參考 GtiHub 上的源代碼)。

分類列表接口: /categories/

標籤列表接口:/tags/

歸檔日期列表的接口實現稍微複雜一點,因為我們需要從已有文章中歸納文章發表日期。事實上,我們在上一部教程 HelloDjango – Django博客教程(第二版)的 頁面側邊欄:使用自定義模板標籤 已經講解了如何獲取歸檔日期列表,只是當時返回的歸檔日期列表直接用於模板的渲染,而這裏我們需要將歸檔日期列表序列化后通過 API 接口返回。

具體來說,獲取博客文章發表時間歸檔列表的方法是調用查詢集(QuerySet)的 dates 方法,提取記錄中的日期。核心代碼就一句:

Post.objects.dates('created_time', 'month', order='DESC')

這裏 Post.objects.dates 方法會返回一個列表,列表中的元素為每一篇文章(Post)的創建日期(已去重),日期都是 Python 的 date 對象,精確到月份,降序排列。

有了返回的歸檔日期列表,接下來就實現相應的 API 接口視圖函數:

blog/views.py

from rest_framework import mixins, status, viewsets
from rest_framework.decorators import action
from rest_framework.serializers import DateField

class PostViewSet(
    mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet
):
	# ...

    @action(
        methods=["GET"], detail=False, url_path="archive/dates", url_name="archive-date"
    )
    def list_archive_dates(self, request, *args, **kwargs):
        dates = Post.objects.dates("created_time", "month", order="DESC")
        date_field = DateField()
        data = [date_field.to_representation(date) for date in dates]
        return Response(data=data, status=status.HTTP_200_OK)

注意這裏我們涉及到了幾個以前沒有詳細講解過的用法。

一是 action 裝飾器,它用來裝飾一個視圖集中的方法,被裝飾的方法會被 django-rest-framework 的路由自動註冊為一個 API 接口。

回顧一下我們之前在使用視圖集 viewset 時提到過 action(動作)的概念,django-rest-framework 預定義了幾個標準的動作,分別為 list 獲取資源列表,retrieve 獲取單個資源、update 和 partial_update 更新資源、destroy 刪除資源,這些 action 具體的實現方法,分別由 mixins 模塊中的混入類提供。例如 用類視圖實現首頁 API 中我們介紹過 mixins.ListModelMixin,這個混入類提供了 list 動作對應的標準實現,即 list 方法。視圖集中所有以上提及的以標準動作命名的方法,都會被 django-rest-framework 的路由自動註冊為標準的 API 接口。

django-rest-framework 默認只能識別標準命名的視圖集方法並將其註冊為 API,但我們可以添加更多非標準的 action,而為了讓 django-rest-framework 能夠識別這些方法,就需要使用 action 裝飾器進行裝飾。

其實我們可以簡單地將 action 裝飾的方法看作是一個視圖函數的實現,因此可以看到方法傳入的第一個參數為 request 請求對象,函數體就是這個視圖函數需要執行的邏輯,顯然,方法最終必須要返回一個 HTTP 響應對象。

action 裝飾器通常用於在視圖集中添加額外的接口實現。例如這裏我們已有了 PostViewSet 視圖集,標準的 list 實現了獲取文章資源列表的邏輯。我們想添加一個獲取文章歸檔日期列表的接口,因此添加了一個 list_archive_dates 方法,並使用 action 進行裝飾。通常如果要在視圖集中添加額外的接口實現,可以使用如下的模板代碼:

@action(
    methods=["allowed http method name"], 
    detail=False or True, 
    url_path="url/path", 
    url_name="url name"
)
def method_name(self, request, *args, **kwargs):
    # 接口邏輯的具體實現,返回一個 Response

通常 action 裝飾器以下 4 個參數都會設置:

methods:一個列表,指定訪問這個接口時允許的 HTTP 方法(GET、POST、PUT、PATCH、DELETE)

detail:True 或者 False。設置為 True,自動註冊的接口 URL 中會添加一個 pk 路徑參數(請看下面的示例),否則不會。

url_path:自動註冊的接口 URL。

url_name:接口名,主要用於通過接口名字反解對應的 URL。

當然,我們還可以在 action 中設置所有 ViewSet 類所支持的類屬性,例如 serializer_classpagination_classpermission_classes 等,用於覆蓋類視圖中設置的屬性值。

以上是 action 用法的一個基本介紹,現在來分析一下 list_archive_dates 這個 action 來加深理解。

methods 參數指定接口需要通過 GET 方法訪問,detail 為 Falseurl_path 設置為 archive/dates,因此最終自動生成的接口路由就是 /posts/archive/dates/。如果我們設置 detail 為 True,那麼生成的接口路由就是 /posts/<int:pk>/archive/dates/,生成的 URL 中就會多一個 pk 路徑參數。

list_archive_dates 具體的實現邏輯中,以下幾點需要注意:

一是獨立使用序列化字段(Field)。之前序列化字段都是在序列化器(Serializer)裏面使用的,因為通常來說接口需要序列化一個對象的多個字段。而這個接口中只需要序列化一個時間字段(類型為 Python 標準庫中的 datetime.date),所以沒必要單獨定義一個序列化器了,直接拿 django-rest-framework 提供的用於序列化時間類型的 DateField 就可以了。用法也很簡單,實例化序列化字段,調用其 to_representation 方法,將需要序列化的值傳入即可(其實序列化器在序列對象的多個字段時,內部也是分別調用對應序列化字段的 to_representation 方法)。

我們通過列表推導式生成一個序列化后的歸檔日期列表,這個列表是可被序列化的。接着我們在接口返回一個 ResponseResponse 將序列化后的結果包裝返回(保存在 data 屬性中),django-rest-framework 會進一步幫我們把這個 Response 中包含的數據解析為合適的格式(例如 JSON)。

status=status.HTTP_200_OK 指定這個接口返回的狀態碼,HTTP_200_OK 是一個預定義的常數,即 200。django-rest-framework 將常用 HTTP 請求的狀態碼常數預定義 status 模塊里,使用預定義的變量而不是直接使用数字的好處一是增強代碼可讀性,二是減少硬編碼。

由於 PostViewSet 視圖集已經通過 django-rest-framework 的路由進行了註冊,因此 list_archive_dates 也會被連帶着自動註冊為一個接口。啟動開發服務器,訪問 /posts/archive/dates/,就可以看到返回的文章歸檔日期列表。

![文章歸檔日期返回結果](https://blog-1253812787.cos.ap-chengdu.myqcloud.com/

.png)

注意到紅框圈出部分,django-rest-framework API 交互後台會識別到額外定義的 action 並將它們展示出來,點擊就可以進入到相應的 API 頁面。

現在,側邊欄所需要的數據接口就開發完成了,接下來實現返回某一分類、標籤或者歸檔日期下的文章列表接口。

在 使用視圖集簡化代碼 我們開發了獲取全部文章的接口。事實上,分類、標籤或者歸檔日期文章列表的 API,本質上還是返回一個文章列表資源,只不過比首頁 API 返回的文章列表資源多了個“過濾”,只過濾出了指定的部分文章而已。對於這樣的場景,我們可以在請求 API 時加上查詢參數,django-rest-framework 解析查詢參數,然後從全部文章列表中過濾出查詢所指定的文章列表再返回。

這在 RESTful API 的設計中肯定是會遇到的,因此第三方庫 django-filter 幫我們實現了上述所說的查詢過濾功能,而且和 django-rest-framework 有很好的集成,我們可以在 django-rest-framework 中非常方便地使用 django-filter。

既然要使用它,當然是先安裝它(已安裝跳過):pipenv install django-filter

接着我們來配置 PostViewSet,為其設置用於過濾返回結果集的一些屬性,代碼如下:

from django_filters.rest_framework import DjangoFilterBackend
from .filters import PostFilter

class PostViewSet(
    mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet
):
    # ...
    filter_backends = [DjangoFilterBackend]
    filterset_class = PostFilter

非常的簡單,僅僅設置了 filter_backendsfilterset_class 兩個屬性。其中 filter_backends 設置為 DjangoFilterBackend,這樣 API 在返回結果時, django-rest-framework 會調用設置的 backend(這裡是 DjangoFilterBackend) 的 filter 方法對 get_queryset 方法返回的結果進行進一步的過濾,而 DjangoFilterBackend 會依據 filterset_class(這裡是 PostFilter)中定義的過濾規則來過濾查詢結果集。

當然 PostFilter 還沒有定義,我們來定義它。首先在 blog 應用下創建一個 filters.py 文件,用於存放自定義 filter 的代碼,PostFilter 代碼如下:

from django_filters import rest_framework as drf_filters

from .models import Post


class PostFilter(drf_filters.FilterSet):
    created_year = drf_filters.NumberFilter(
        field_name="created_time", lookup_expr="year"
    )
    created_month = drf_filters.NumberFilter(
        field_name="created_time", lookup_expr="month"
    )

    class Meta:
        model = Post
        fields = ["category", "tags", "created_year", "created_month"]

PostFilter 的定義和序列化器 Serializer 非常類似。

categorytags 兩個過濾字段因為是 Post 模型中定義的字段,因此 django-filter 可以自動推斷其過濾規則,只需要在 Meta.fields 中聲明即可。

歸檔日期下的文章列表,我們設計的接口傳遞 2 個查詢參數:年份和月份。由於這兩個字段在 Post 中沒有定義,Post 記錄時間的字段為 created_time,因此我們需要显示地定義查詢規則,定義的規則是:

查詢參數名 = 查詢參數值的類型(查詢的模型字段,查詢表達式)

例如示例中定義的 created_year 查詢參數,查詢參數值的類型為 number,即数字,查詢的模型字段為 created_time,查詢表達式是 year。當用戶傳遞 created_year 查詢參數時,django-filter 實際上會將以上定義的規則翻譯為如下的 ORM 查詢語句:

Post.objects.filter(created_time__year=created_year傳遞的值)

現在回到 API 交互後台,先進到 /post/ 接口下,默認返回了全部文章列表。可以看到右上角多了個過濾器(紅框圈出部分)。

點擊會彈出過濾參數輸入的交互面板,在這裏可以交互式地輸入查詢過濾參數的值。

例如選擇如下的過濾參數,得到查詢的 URL 為:

http://127.0.0.1:10000/api/posts/?category=1&tags=1&created_year=2020&created_month=1

這條查詢返回創建於 2020 年 1 月,id 為 1 的分類下,id 為 1 的標籤下的全部文章。

通過不同的查詢參數組合,就可以得到不同的文章資源列表了。

關注公眾號加入交流群

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

【其他文章推薦】

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

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

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

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

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

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

重學 Java 設計模式:實戰外觀模式「基於SpringBoot開發門面模式中間件,統一控制接口白名單場景」

作者:小傅哥
博客:https://bugstack.cn

沉澱、分享、成長,讓自己和他人都能有所收穫!

一、前言

你感受到的容易,一定有人為你承擔不容易

這句話更像是描述生活的,許許多多的磕磕絆絆總有人為你提供躲雨的屋檐和避風的港灣。其實編程開發的團隊中也一樣有人只負責CRUD中的簡單調用,去使用團隊中高級程序員開發出來的核心服務和接口。這樣的編程開發對於初期剛進入程序員行業的小夥伴來說鍛煉鍛煉還是不錯的,但隨着開發的日子越來越久一直做這樣的事情就很難得到成長,也想努力的去做一些更有難度的承擔,以此來增強個人的技術能力。

沒有最好的編程語言,語言只是工具

刀槍棍棒、斧鉞鈎叉、包子油條、盒子麻花,是語言。五郎八卦棍、十二路彈腿、洪家鐵線拳,是設計。記得恭弘=叶 恭弘問里有一句台詞是:金山找:今天我北方拳術,輸給你南方拳術了。恭弘=叶 恭弘問:你錯了,不是南北拳的問題,是你的問題。所以當你編程開發寫的久了,就不會再特別在意用的語言,而是為目標服務,用最好的設計能力也就是編程的智慧做出做最完美的服務。這也就是編程人員的價值所在!

設計與反設計以及過渡設計

設計模式是解決程序中不合理、不易於擴展、不易於維護的問題,也是幹掉大部分ifelse的利器,在我們常用的框架中基本都會用到大量的設計模式來構建組件,這樣也能方便框架的升級和功能的擴展。但!如果不能合理的設計以及亂用設計模式,會導致整個編程變得更加複雜難維護,也就是我們常說的;反設計過渡設計。而這部分設計能力也是從實踐的項目中獲取的經驗,不斷的改造優化摸索出的最合理的方式,應對當前的服務體量。

二、開發環境

  1. JDK 1.8
  2. Idea + Maven
  3. SpringBoot 2.1.2.RELEASE
  4. 涉及工程三個,可以通過關注公眾號bugstack蟲洞棧,回復源碼下載獲取(打開獲取的鏈接,找到序號18)
工程 描述
itstack-demo-design-10-00 場景模擬工程;模擬一個提供接口服務的SpringBoot工程
itstack-demo-design-10-01 使用一坨代碼實現業務需求
itstack-demo-design-10-02 通過設計模式開發為中間件,包裝通用型核心邏輯

三、外觀模式介紹

外觀模式也叫門面模式,主要解決的是降低調用方的使用接口的複雜邏輯組合。這樣調用方與實際的接口提供方提供方提供了一个中間層,用於包裝邏輯提供API接口。有些時候外觀模式也被用在中間件層,對服務中的通用性複雜邏輯進行中間件層包裝,讓使用方可以只關心業務開發。

那麼這樣的模式在我們的所見產品功能中也經常遇到,就像幾年前我們註冊一個網站時候往往要添加很多信息,包括;姓名、昵稱、手機號、QQ、郵箱、住址、單身等等,但現在註冊成為一個網站的用戶只需要一步即可,無論是手機號還是微信也都提供了這樣的登錄服務。而對於服務端應用開發來說以前是提供了一個整套的接口,現在註冊的時候並沒有這些信息,那麼服務端就需要進行接口包裝,在前端調用註冊的時候服務端獲取相應的用戶信息(從各個渠道),如果獲取不到會讓用戶後續進行補全(營銷補全信息給獎勵),以此來拉動用戶的註冊量和活躍度。

四、案例場景模擬

在本案例中我們模擬一個將所有服務接口添加白名單的場景

在項目不斷壯大發展的路上,每一次發版上線都需要進行測試,而這部分測試驗證一般會進行白名單開量或者切量的方式進行驗證。那麼如果在每一個接口中都添加這樣的邏輯,就會非常麻煩且不易維護。另外這是一類具備通用邏輯的共性需求,非常適合開發成組件,以此來治理服務,讓研發人員更多的關心業務功能開發。

一般情況下對於外觀模式的使用通常是用在複雜或多個接口進行包裝統一對外提供服務上,此種使用方式也相對簡單在我們平常的業務開發中也是最常用的。你可能經常聽到把這兩個接口包裝一下,但在本例子中我們把這種設計思路放到中間件層,讓服務變得可以統一控制。

1. 場景模擬工程

itstack-demo-design-10-00
└── src
    ├── main
    │   ├── java
    │   │   └── org.itstack.demo.design
    │   │       ├── domain
    │   │       │	└── UserInfo.java
    │   │       ├── web	
    │   │       │	└── HelloWorldController.java
    │   │       └── HelloWorldApplication.java
    │   └── resources	
    │       └── application.yml	
    └── test
        └── java
            └── org.itstack.demo.test
                └── ApiTest.java
  • 這是一個SpringBootHelloWorld工程,在工程中提供了查詢用戶信息的接口HelloWorldController.queryUserInfo,為後續擴展此接口的白名單過濾做準備。

2. 場景簡述

2.1 定義基礎查詢接口

@RestController
public class HelloWorldController {

    @Value("${server.port}")
    private int port;

    /**
     * key:需要從入參取值的屬性字段,如果是對象則從對象中取值,如果是單個值則直接使用
     * returnJson:預設攔截時返回值,是返回對象的Json
     *
     * http://localhost:8080/api/queryUserInfo?userId=1001
     * http://localhost:8080/api/queryUserInfo?userId=小團團
     */
    @RequestMapping(path = "/api/queryUserInfo", method = RequestMethod.GET)
    public UserInfo queryUserInfo(@RequestParam String userId) {
        return new UserInfo("蟲蟲:" + userId, 19, "天津市南開區旮旯衚衕100號");
    }

}
  • 這裏提供了一個基本的查詢服務,通過入參userId,查詢用戶信息。後續就需要在這裏擴展白名單,只有指定用戶才可以查詢,其他用戶不能查詢。

2.2 設置Application啟動類

@SpringBootApplication
@Configuration
public class HelloWorldApplication {

    public static void main(String[] args) {
        SpringApplication.run(HelloWorldApplication.class, args);
    }

}
  • 這裡是通用的SpringBoot啟動類。需要添加的是一個配置註解@Configuration,為了後續可以讀取白名單配置。

五、用一坨坨代碼實現

一般對於此種場景最簡單的做法就是直接修改代碼

累加if塊幾乎是實現需求最快也是最慢的方式,是修改當前內容很快,是如果同類的內容幾百個也都需要如此修改擴展和維護會越來越慢。

1. 工程結構

itstack-demo-design-10-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── HelloWorldController.java
  • 以上的實現是模擬一個Api接口類,在裏面添加白名單功能,但類似此類的接口會有很多都需要修改,所以這也是不推薦使用此種方式的重要原因。

2. 代碼實現

public class HelloWorldController {

    public UserInfo queryUserInfo(@RequestParam String userId) {

        // 做白名單攔截
        List<String> userList = new ArrayList<String>();
        userList.add("1001");
        userList.add("aaaa");
        userList.add("ccc");
        if (!userList.contains(userId)) {
            return new UserInfo("1111", "非白名單可訪問用戶攔截!");
        }

        return new UserInfo("蟲蟲:" + userId, 19, "天津市南開區旮旯衚衕100號");
    }

}
  • 在這裏白名單的代碼佔據了一大塊,但它又不是業務中的邏輯,而是因為我們上線過程中需要做的開量前測試驗證。
  • 如果你日常對待此類需求經常是這樣開發,那麼可以按照此設計模式進行優化你的處理方式,讓後續的擴展和摘除更加容易。

六、外觀模式重構代碼

接下來使用外觀器模式來進行代碼優化,也算是一次很小的重構。

這次重構的核心是使用外觀模式也可以說門面模式,結合SpringBoot中的自定義starter中間件開發的方式,統一處理所有需要白名單的地方。

後續接下來的實現中,會涉及的知識;

  1. SpringBoot的starter中間件開發方式。
  2. 面向切面編程和自定義註解的使用。
  3. 外部自定義配置信息的透傳,SpringBoot與Spring不同,對於此類方式獲取白名單配置存在差異。

1. 工程結構

itstack-demo-design-10-02
└── src
    ├── main
    │   ├── java
    │   │   └── org.itstack.demo.design.door
    │   │       ├── annotation
    │   │       │	└── DoDoor.java	
    │   │       ├── config
    │   │       │	├── StarterAutoConfigure.java
    │   │       │	├── StarterService.java
    │   │       │	└── StarterServiceProperties.java
    │   │       └── DoJoinPoint.java
    │   └── resources	
    │       └── META_INF
    │           └── spring.factories
    └── test
        └── java
            └── org.itstack.demo.test
                └── ApiTest.java

門面模式模型結構

  • 以上是外觀模式的中間件實現思路,右側是為了獲取配置文件,左側是對於切面的處理。
  • 門面模式可以是對接口的包裝提供出接口服務,也可以是對邏輯的包裝通過自定義註解對接口提供服務能力。

2. 代碼實現

2.1 配置服務類

public class StarterService {

    private String userStr;

    public StarterService(String userStr) {
        this.userStr = userStr;
    }

    public String[] split(String separatorChar) {
        return StringUtils.split(this.userStr, separatorChar);
    }

}
  • 以上類的內容較簡單隻是為了獲取配置信息。

2.2 配置類註解定義

@ConfigurationProperties("itstack.door")
public class StarterServiceProperties {

    private String userStr;

    public String getUserStr() {
        return userStr;
    }

    public void setUserStr(String userStr) {
        this.userStr = userStr;
    }

}
  • 用於定義好後續在 application.yml 中添加 itstack.door 的配置信息。

2.3 自定義配置類信息獲取

@Configuration
@ConditionalOnClass(StarterService.class)
@EnableConfigurationProperties(StarterServiceProperties.class)
public class StarterAutoConfigure {

    @Autowired
    private StarterServiceProperties properties;

    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnProperty(prefix = "itstack.door", value = "enabled", havingValue = "true")
    StarterService starterService() {
        return new StarterService(properties.getUserStr());
    }

}
  • 以上代碼是對配置的獲取操作,主要是對註解的定義;@Configuration@ConditionalOnClass@EnableConfigurationProperties,這一部分主要是與SpringBoot的結合使用。

2.4 切面註解定義

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface DoDoor {

    String key() default "";

    String returnJson() default "";

}
  • 定義了外觀模式門面註解,後續就是此註解添加到需要擴展白名單的方法上。
  • 這裏提供了兩個入參,key:獲取某個字段例如用戶ID、returnJson:確定白名單攔截后返回的具體內容。

2.5 白名單切面邏輯

@Aspect
@Component
public class DoJoinPoint {

    private Logger logger = LoggerFactory.getLogger(DoJoinPoint.class);

    @Autowired
    private StarterService starterService;

    @Pointcut("@annotation(org.itstack.demo.design.door.annotation.DoDoor)")
    public void aopPoint() {
    }

    @Around("aopPoint()")
    public Object doRouter(ProceedingJoinPoint jp) throws Throwable {
        //獲取內容
        Method method = getMethod(jp);
        DoDoor door = method.getAnnotation(DoDoor.class);
        //獲取字段值
        String keyValue = getFiledValue(door.key(), jp.getArgs());
        logger.info("itstack door handler method:{} value:{}", method.getName(), keyValue);
        if (null == keyValue || "".equals(keyValue)) return jp.proceed();
        //配置內容
        String[] split = starterService.split(",");
        //白名單過濾
        for (String str : split) {
            if (keyValue.equals(str)) {
                return jp.proceed();
            }
        }
        //攔截
        return returnObject(door, method);
    }

    private Method getMethod(JoinPoint jp) throws NoSuchMethodException {
        Signature sig = jp.getSignature();
        MethodSignature methodSignature = (MethodSignature) sig;
        return getClass(jp).getMethod(methodSignature.getName(), methodSignature.getParameterTypes());
    }

    private Class<? extends Object> getClass(JoinPoint jp) throws NoSuchMethodException {
        return jp.getTarget().getClass();
    }

    //返回對象
    private Object returnObject(DoDoor doGate, Method method) throws IllegalAccessException, InstantiationException {
        Class<?> returnType = method.getReturnType();
        String returnJson = doGate.returnJson();
        if ("".equals(returnJson)) {
            return returnType.newInstance();
        }
        return JSON.parseObject(returnJson, returnType);
    }

    //獲取屬性值
    private String getFiledValue(String filed, Object[] args) {
        String filedValue = null;
        for (Object arg : args) {
            try {
                if (null == filedValue || "".equals(filedValue)) {
                    filedValue = BeanUtils.getProperty(arg, filed);
                } else {
                    break;
                }
            } catch (Exception e) {
                if (args.length == 1) {
                    return args[0].toString();
                }
            }
        }
        return filedValue;
    }

}
  • 這裏包括的內容較多,核心邏輯主要是;Object doRouter(ProceedingJoinPoint jp),接下來我們分別介紹。

@Pointcut(“@annotation(org.itstack.demo.design.door.annotation.DoDoor)”)

定義切面,這裏採用的是註解路徑,也就是所有的加入這個註解的方法都會被切面進行管理。

getFiledValue

獲取指定key也就是獲取入參中的某個屬性,這裏主要是獲取用戶ID,通過ID進行攔截校驗。

returnObject

返回攔截后的轉換對象,也就是說當非白名單用戶訪問時則返回一些提示信息。

doRouter

切面核心邏輯,這一部分主要是判斷當前訪問的用戶ID是否白名單用戶,如果是則放行jp.proceed();,否則返回自定義的攔截提示信息。

3. 測試驗證

這裏的測試我們會在工程:itstack-demo-design-10-00中進行操作,通過引入jar包,配置註解的方式進行驗證。

3.1 引入中間件POM配置

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>itstack-demo-design-10-02</artifactId>
</dependency>
  • 打包中間件工程,給外部提供jar包服務

3.2 配置application.yml

# 自定義中間件配置
itstack:
  door:
    enabled: true
    userStr: 1001,aaaa,ccc #白名單用戶ID,多個逗號隔開
  • 這裏主要是加入了白名單的開關和白名單的用戶ID,逗號隔開。

3.3 在Controller中添加自定義註解

/**
 * http://localhost:8080/api/queryUserInfo?userId=1001
 * http://localhost:8080/api/queryUserInfo?userId=小團團
 */
@DoDoor(key = "userId", returnJson = "{\"code\":\"1111\",\"info\":\"非白名單可訪問用戶攔截!\"}")
@RequestMapping(path = "/api/queryUserInfo", method = RequestMethod.GET)
public UserInfo queryUserInfo(@RequestParam String userId) {
    return new UserInfo("蟲蟲:" + userId, 19, "天津市南開區旮旯衚衕100號");
}
  • 這裏核心的內容主要是自定義的註解的添加@DoDoor,也就是我們的外觀模式中間件化實現。
  • key:需要從入參取值的屬性字段,如果是對象則從對象中取值,如果是單個值則直接使用。
  • returnJson:預設攔截時返回值,是返回對象的Json。

3.4 啟動SpringBoot

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.1.2.RELEASE)

2020-06-11 23:56:55.451  WARN 65228 --- [           main] ion$DefaultTemplateResolverConfiguration : Cannot find template location: classpath:/templates/ (please add some templates or check your Thymeleaf configuration)
2020-06-11 23:56:55.531  INFO 65228 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-06-11 23:56:55.533  INFO 65228 --- [           main] o.i.demo.design.HelloWorldApplication    : Started HelloWorldApplication in 1.688 seconds (JVM running for 2.934)
  • 啟動正常,SpringBoot已經啟動可以對外提供服務。

3.5 訪問接口接口測試

白名單用戶訪問

http://localhost:8080/api/queryUserInfo?userId=1001

{"code":"0000","info":"success","name":"蟲蟲:1001","age":19,"address":"天津市南開區旮旯衚衕100號"}
  • 此時的測試結果正常,可以拿到接口數據。

非白名單用戶訪問

http://localhost:8080/api/queryUserInfo?userId=小團團

{"code":"1111","info":"非白名單可訪問用戶攔截!","name":null,"age":null,"address":null}
  • 這次我們把userId換成小團團,此時返回的信息已經是被攔截的信息。而這個攔截信息正式我們自定義註解中的信息:@DoDoor(key = "userId", returnJson = "{\"code\":\"1111\",\"info\":\"非白名單可訪問用戶攔截!\"}")

七、總結

  • 以上我們通過中間件的方式實現外觀模式,這樣的設計可以很好的增強代碼的隔離性,以及復用性,不僅使用上非常靈活也降低了每一個系統都開發這樣的服務帶來的風險。
  • 可能目前你看這隻是非常簡單的白名單控制,是否需要這樣的處理。但往往一個小小的開始會影響着後續無限的擴展,實際的業務開發往往也要複雜的很多,不可能如此簡單。因而使用設計模式來讓代碼結構更加乾淨整潔。
  • 很多時候不是設計模式沒有用,而是自己編程開發經驗不足導致即使學了設計模式也很難駕馭。畢竟這些知識都是經過一些實際操作提煉出來的精華,但如果你可以按照本系列文章中的案例方式進行學習實操,還是可以增強這部分設計能力的。

八、推薦閱讀

  • 1. 重學 Java 設計模式:實戰工廠方法模式(多種類型商品發獎場景)
  • 2. 重學 Java 設計模式:實戰抽象工廠模式(替換Redis雙集群升級場景)
  • 3. 重學 Java 設計模式:實戰建造者模式(裝修物料組合套餐選配場景)
  • 4. 重學 Java 設計模式:實戰原型模式(多套試每人題目和答案亂序場景)
  • 5. 重學 Java 設計模式:實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
  • 6. 重學 Java 設計模式:實戰組合模式(營銷差異化人群發券,決策樹引擎搭建場景)

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

Jmeter(九) – 從入門到精通 – JMeter邏輯控制器 – 上篇(詳解教程)

1.簡介

Jmeter官網對邏輯控制器的解釋是:“Logic Controllers determine the order in which Samplers are processed.”。

意思是說,邏輯控制器可以控制採樣器(samplers)的執行順序。由此可知,控制器需要和採樣器一起使用,否則控制器就沒有什麼意義了。放在控制器下面的所有的採樣器都會當做一個整體,執行時也會一起被執行。

JMeter邏輯控制器可以對元件的執行邏輯進行控制,除僅一次控制器外,其他可以嵌套別的種類的邏輯控制器。

2.邏輯控制器分類

JMeter中的Logic Controller分為兩類:
(1)控制測試計劃執行過程中節點的邏輯執行順序,如:Loop Controller、If Controller等;
(2)對測試計劃中的腳本進行分組、方便JMeter統計執行結果以及進行腳本的運行時控制等,如:Throughput Controller、Transaction Controller。

3.預覽邏輯控制器家族

首先我們來看一下JMeter的邏輯控制器,路徑:線程組(用戶)->添加->邏輯控制器(Logic Controller);我們可以清楚地看到JMeter5中共有17個邏輯控制器,如下圖所示:

如果上圖您看得不是很清楚的話,宏哥總結了一個思維導圖,關於JMeter5的邏輯控制器類型,如下圖所示: 

 通過以上的了解,我們對邏輯控制器有了一個大致的了解和認識。下面宏哥就給小夥伴或則童鞋們分享講解一些通常在工作中會用到的邏輯控制器。 

4.常用邏輯控制器詳解

  這一小節,宏哥就由上而下地詳細地講解一下常用的邏輯控制器。由於時間關係,宏哥將這部分分為上、中、下三個部分講解。

4.1if Controller

在實際工作中,當使用Jmeter進行接口測試或者性能測試時,有時需要根據不同條件做不同的操作,為了解決這個問題,Jmeter提供了IF控制器。顧名思義,IF控制器實現了代碼中IF的功能,通過判斷表達式的True/False來判定是否執行相應的操作。通過條件判斷下邊的節點執行不執行。

1、我們先來看看這個if Controller長得是啥樣子,路徑:線程組 > 添加 > 邏輯控制器 > 如果 (if) 控制器,如下圖所示:

2、關鍵參數說明如下:

Name:名稱,可以隨意設置,甚至為空;

Comments:註釋,可隨意設置,可以為空。

Expression (must evaluate to true or false) :表達式(值必須是true或false),也就是說,在右邊文本框中輸入的條件值必須是true 或 false,(默認情況下)

Interpret Condition as Variable Expression?:默認勾選項,將條件解釋為變量表達式(需要使用__jexl3 or __groovy 表達式)

Evaluate for all children?:條件作用於每個子項(具體理解宏哥會在後邊實戰篇列舉例子說明),判斷條件是否針對所有子節點,默認不勾選,只在if Controller的入口處判斷一次。

注意:敲黑板!!!敲腦殼啦!!!

1、文本框上的黃色感嘆號,就是提示你,建議採用__jexl3 or __groovy 表達式,以提高性能,也就是默認的方式。

2、if 控制器 只能作用於其下的子項

4.1.1默認用法

1、默認用法,就是採用__jexl3 or __groovy 表達式if 控制器下有一個 訪問北京宏哥的博客園首頁的取樣器,只有if條件滿足時,才會執行該取樣器。採用默認方式,將條件’北京宏哥’==’北京宏哥’,放入 __jexl3表達式中。如下圖所示:

 2、如果不知道表達式如何使用,可使用Jmeter 的函數助手,函數助手圖標 > 選擇_jexl3 > 在值的輸入框輸入’北京宏哥’==’北京宏哥’  > 點擊‘生成’ > 全選Ctrl+C複製 > Ctrl+V粘貼到表達式處 如下圖所示:

3、配置好以後,運行JMeter,選擇HTML,然後查看結果樹,如下圖所示:

4.1.2直接輸入條件

1、直接輸入只需要去掉 “Interpret Condition as Variable Expression?” 前面複選框,直接輸入條件: ‘北京宏哥’==’北京宏哥’ 。訪問北京宏哥的博客園的首頁的取樣器將被執行。如下圖所示:

2、配置好以後,運行JMeter,選擇HTML,然後查看結果樹,如下圖所示:

4.13條件中使用變量

我們在日常工作中在很多的測試場景下,需要根據用戶變量或者上一個取樣器的返回值來進行條件判斷,從而決定是否需要執行某一個的取樣器。

1、首先我們新增一個用戶變量:北京宏哥。條件:北京宏哥 的值為 宏哥 的時候,才執行訪問北京宏哥博客園的首頁的取樣器。如下圖所示:

用戶變量及配置,如下圖所示:

2、IF Controller及配置,或者可以用表達式:${__jexl3(‘${北京宏哥}’==’宏哥’ ,)}。如下圖所示: 

4.1.4Evaluate for all children? 的用法

1、宏哥在上面的小節中講解和分享了在條件中如何使用變量,我們假設一種測試場景:如果 if 控制器下的取樣器執行后,改變了該變量的值,if 控制器下 其後的取樣器還會被繼續執行嗎?跟隨宏哥一起來看看下面的列子:

2、改變“北京宏哥”變量的值為“北京宏哥”,如下圖所示:

3、JMeter執行過程的邏輯分析:

(1) if 控制器下 有 3 個取樣器,變量 北京宏哥 的初始值為 宏哥,if 控制器的條件為:${__jexl3(“${北京宏哥}”==”宏哥”,)}

(2)開始執行的時候滿足條件,那麼按理說應該執行 訪問博客園首頁訪問北京宏哥的博客園首頁訪問宏哥的JMeter系列文章 3個取樣器,

(3)但是 訪問北京宏哥的博客園首頁 執行后,將 北京宏哥 的值變了 北京宏哥,已經不能滿足 “${北京宏哥}”==”宏哥” 條件。

(4)所以 訪問宏哥的JMeter系列文章 這個取樣器不會被執行。

4、運行JMeter,查看結果樹,對比運行結果和宏哥分析的一致,如下圖所示:

5、如果這個時候,去掉  Evaluate for all children? 的勾選,會發生什麼呢,大家可以自己動手試試。修改後記得點擊“保存”。下邊是宏哥的執行結果,如下下圖所示:

另外,如果時字符串必須要用引號,變量都認為是字符串的形式,如:${__jexl3(“${北京宏哥}”==”宏哥”,)}。

4.2Transaction Controller

  事務響應時間是我們衡量業務性能的主要指標,事務控制器可以把其他節點下的取樣器執行消耗時間累加在一起,便於統計。同時對每一個取樣器的執行時間進行統計。
  如果事務控制器下的取樣器有多個,只有當所有的取樣器都運行成功,整個事務控制器定義的事物才算成功。
  用於將Test Plan中的特定部分組織成一個Transaction,JMeter中Transaction的作用在於,可以針對Transaction統計其響應時間、吞吐量等。比如說,一個用戶操作可能需要多個Sampler來模擬,此時使用Transaction Controller,可以更準確地得到該用戶操作的性能指標,如響應時間等。這個時間包含該控制器範圍內的所有處理時間,而不僅僅是採樣器的。

這個就非常有用了。我們前面有提到過事務的概念,有時候我們不關心單個請求的響應時間,而是關心一組相關請求的整體響應時間,怎麼來統計呢?就需要藉助事務這個概念,把這組請求,放到一個事務控制器下面。

1、我們先來看看這個Transaction Controller長得是啥樣子,路徑:線程組 > 添加 > 邏輯控制器 > 事務控制器,如下圖所示:

2、關鍵參數說明如下:

Name:名稱,可以隨意設置,甚至為空;

Comments:註釋,可隨意設置,可以為空;

generate parent sample:選擇是否生成一個父取樣器;

include duration of timer and pre-post processors in generated samle:是否包含定時器,選擇將在取樣器前與后加上延時。(宏哥建議大家不要勾選,否則統計就比較麻煩了,還需要你扣除延時)

4.2.1generate parent sample用法

1、宏哥列舉一個測試場景:我們需要了解 訪問博客園首頁  訪問北京宏哥的博客園首頁這兩個請求的單個請求的響應時間,那麼就來看看如下實例。

(1)單個請求,那麼不勾選generate parent sample,如下圖所示:

2、運行JMeter,查看聚合報告的單個請求的響應時間,如下圖所示:

1、宏哥列舉一個測試場景:我們需要了解 訪問博客園首頁  訪問北京宏哥的博客園首頁這兩個請求作為一組請求的響應時間,那麼就來看看如下實例。

(1)一組請求,那麼勾選generate parent sample,如下圖所示:

2、運行JMeter,查看聚合報告的一組請求的響應時間,如下圖所示:

4.3Loop Controller

循環控制器可以控制在其節點下的元件的執行次數,可以是具體数字,也可以是變量。

1、我們先來看看這個Loop Controller長得是啥樣子,默認循環一次。路徑:線程組 > 添加 > 邏輯控制器 > 循環控制器,如下圖所示:

2、關鍵參數說明如下:

Name:名稱,可以隨意設置,甚至為空;

Comments:註釋,可隨意設置,可以為空;

Forever:勾選上這一項表示一直循環下去。

注意:敲黑板,敲腦殼!!! 

如果同時設置了線程組的循環次數和循環控制器的循環次數,那循環控制器的子節點運行的次數為兩個數值相乘的結果。

4.3.1Thread Group和循環控制器的區別

1、現在宏哥準備兩個請求,設置線程組1個線程,5次loop,下邊有一個請求:訪問北京宏哥的博客園首頁  一個Loop Controller(設置2次loop),下邊有一個請求:訪問博客園首頁  

(1)線程組,如下圖所示:

(2)循環控制器,如下圖所示:

 

2、運行JMeter,查看結果樹,為了清楚地看出結果,宏哥將第一個請求故意配置成失敗的;如下圖所示:

從上邊的結果可以看出:

(1)如果同時設置了線程組的循環次數和循環控制器的循環次數,那循環控制器的子節點運行的次數為兩個數值相乘的結果。

(2)運行順序是:先執行線程組裡的循環,再執行循環控制器里的循環。

4.4While Controller

While條件控制器,其節點下的元件將一直運行直到While 條件為false。

1、我們先來看看這個While Controller長得是啥樣子,默認循環一次。路徑:線程組 > 添加 > 邏輯控制器 > While控制器,如下圖所示:

2、關鍵參數說明如下:

Name:名稱,可以隨意設置,甚至為空;

Comments:註釋,可隨意設置,可以為空;

Condition:接受變量表達式與變量。條件為 Flase 的時候,才會跳出 While 循環,否則一直執行 While 控制器下的元件。

3、While控制器提供三個常量

(1)Blank:當循環中最後一個取樣器失敗后停止

(2)LAST:當循換前有取樣器失敗,不進入循環

(3)Otherwise:當判斷條件為false時,停止循環

4.4.1Blank

1、不填(空):當 While 控制器下最後一個樣例執行失敗后 跳出循環,如下圖所示:

2、運行JMeter,查看結果樹,(你可以通過鼠標拖動最後失敗的取樣器,移動到第一個或者第二個位置的時候,運行JMeter后,會發現在一直運行);如下圖所示:

4.4.2LAST

LAST :當 While 控制器下最後一個樣例執行失敗后 跳出循環,如果 While 控制器 前一個樣例執行失敗,則不會進入While循環,也就是不會執行While控制器下的樣例。

1、取樣器樹還是上邊的位置和順序。這次我們在While控制器表達式處填寫:LAST,如下圖所示:

2、運行JMeter,查看結果樹,(你可以通過鼠標拖動最後失敗的取樣器,移動到第一個或者第二個位置的時候,運行JMeter后,會發現在一直運行);細心的你可以發現循環只跑一遍,與不填 的結果是一樣的如下圖所示:

3、但是輸入LAST的時候,還會出現一個結果,那就是:如果While 控制器 的前一個樣例執行失敗,則不會進入While 控制器

在While 控制器 前面 添加兩個取樣器:取樣器1 訪問百度,取樣器2 訪問北京宏哥 使取樣器2 訪問北京宏哥 執行失敗。取樣器2必須在While控制器前邊且執行失敗。如下圖所示:

 4、運行JMeter,查看結果樹,執行結果發現,取樣器1、取樣器2 執行了,但沒有進入While 控制器,如下圖所示:

4.4.3Otherwise

自定義條件:值為True 或 False的函數/變量/屬性 表達式;類似前邊講解的IF控制器,宏哥這裏就照貓畫虎的舉個例子。

1、用戶自定義變量,變量名:北京宏哥,變量值:true,如下圖所示:

2、While控制器配置,取到變量的值:${北京宏哥},填寫到表達式的地方,如下圖所示: 

3、JMeter執行過程的邏輯分析:

(1)北京宏哥用戶(線程組)下 有 1 個用戶自定義變量,變量 北京宏哥 的值為 true,While控制器的條件為:${北京宏哥} 取到的值始終是 true

(2)所以一旦開始執行始終滿足條件,那麼按理說就應該一直執行 訪問博客園首頁 、訪問北京宏哥的博客園首頁訪問宏哥的JMeter系列文章 3個取樣器,

4、運行JMeter,查看結果樹,(運行JMeter后,會發現在一直運行),對比一下,與宏哥的分析是不是高度一致哈;如下圖所示:

5.小結

 好了,今天關於邏輯控制器的上篇就講解到這裏,這一篇主要介紹了 IF控制器Transaction ControllerLoop ControllerWhile控制器

 

您的肯定就是我進步的動力。如果你感覺還不錯,就請鼓勵一下吧!記得隨手點波  推薦  不要忘記哦!!!

別忘了點 推薦 留下您來過的痕迹

 

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

【其他文章推薦】

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

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

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

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

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