疫情成保育契機 威尼斯潟湖重生

摘錄自2020年08月16日台灣醒報報導

疫情使威尼斯觀光停擺,在地人趁機復甦生態!義大利威尼斯潟湖曾因為人口眾多及排水污染,湖中鹽分提高,導致大量蘆葦消失,生態環境被破壞。然而,因為疫情期間人口稀少,科學家及當地農夫藉此發起潟湖復甦計劃,以運河系統引進淡水、移植海草、種植蘆葦,以恢復原有生態。

鹽沼是沿海潮間帶和陸地間的一種生態系統,海水或鹹水會規律地湧入流出該地區。據《今日泰倫加納》報導,人工的運河系統將思樂河的淡水導入潟湖。能培養豐富生態的鹽沼如今只剩下34公頃。

威尼斯福斯卡里宮大學研究員亞瑞安娜指出,潟湖的一半以上曾經是蘆葦床和鹽沼,約1萬7000公頃並擁有豐富生態,「健康的潟湖鹽分應介於0到15鹽度,但現在威尼斯的鹽度是30,已與海水相去不遠。」計劃發起人布魯薩則表示:「我們的重整計劃將從其他地方導入乾淨的淡水,來沖淡鹽分,還它原始的樣貌。」

污染治理
國際新聞
義大利
威尼斯
潟湖
武漢肺炎
動物與大環境變遷

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

【其他文章推薦】

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

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

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

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

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

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

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

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

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

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

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

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

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

【其他文章推薦】

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

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

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

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

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

德國國家科學院聲明 德國能源轉型2030:歐洲碳中和路徑

轉載自台大風險社會與政策研究中心;陳喬琪 編譯

本站聲明:網站內容來源環境資訊中心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  ?

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

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

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

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

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

Asp.Net Core入門之自定義服務註冊

談到服務註冊,首先我們先了解一下服務註冊時使用的三種方式,也代表了不同的服務生命周期

1  AddTransient
 
2  AddScoped
 
3  AddSingleton
AddSingleton生命周期最長,其生命周期範圍描述為:從應用程序啟動到應用程序結束。在第一次請求時會創建一個實例,之後的每次請求都會使用同一個實例。
AddTransient生命周期最短,在服務請求時會創建一個實例,服務請求結束生命周期即結束,之後的每一次請求都會創建不同的實例。
AddSingleton生命周期介於上述兩者之間,這裏用客戶端請求會話的概念來描述比較清晰一點,它也是在服務請求時創建實例,但是在同一個會話周期內,之後的每次請求都會使用同一個實例,直至會話結束才會創建新的實例。
 

ASP.Net Core框架支持我們以如下方式註冊我們自己的服務。

services.AddScoped<ITest, Test>();

其中第一個泛型類型(如:ITest)表示將要從容器中請求的類型(通常是一個接口)。第二個泛型類型(如:Test)表示將由容器實例化並且用於完成這些請求的具體實現類。

具體我們一起看下面的例子:

首先,我們創建一個需要實現查詢功能的服務接口ITest

   public interface ITest
    {
        Task<string> Get();
    }

然後,我們創建功能類Test實現這個接口

 1     public class Test : ITest
 2     {
 3         private readonly ILogger logger;
 4         public Test(ILogger<Test> _logger)
 5         {
 6             logger = _logger;
 7         }
 8         public Task<string> Get()
 9         {
10             logger.LogInformation("自定義服務查詢");
11             return Task.FromResult("Hello World");
12         }
13     }

最後,我們需要我們自己的服務註冊到容器中。

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddScoped<ITest, Test>();
        }

以上我們便簡單完成了自定義服務的註冊。

隨後我這裏創建了一個Controller用以使用該服務。

 1     [Route("api/[controller]")]
 2     [ApiController]
 3     public class ValuesController : ControllerBase
 4     {
 5         //聲明服務
 6         private readonly ITest service;
 7 
 8         /// <summary>
 9         /// 通過構造函數的方式注入自定義服務類
10         /// </summary>
11         /// <param name="_service"></param>
12         public ValuesController(ITest _service)
13         {
14             service = _service;
15         }
16 
17         /// <summary>
18         /// 調用服務中實現的Get方法
19         /// </summary>
20         /// <returns></returns>
21         [HttpGet]
22         public Task<string> Get()
23         {
24             return service.Get();
25         }
26      }

ASP.Net Core框架默認支持我們以構造函數的方式注入我們的服務以使用。

我想寫到這裏,大家也會有疑問,如果我們有很多service,這樣一個個註冊寫起來代碼很低效,這裏我們簡單給大家介紹一種批量註冊的方式:

這裏我們創建了一個批量註冊服務派生類:

 1 public static class ServiceExtensions
 2     {
 3         /// <summary>
 4         /// 批量註冊程序集下的服務類
 5         /// </summary>
 6         /// <param name="services"></param>
 7         public static IServiceCollection AddBatchServices(this IServiceCollection services)
 8         {
 9             //根據指定程序集名稱獲取待註冊服務
10             var batchServices = GetConfigureClass("WebApiApplication");
11             foreach (var type in batchServices)
12             {
13                 type.Value.ToList().ForEach(i =>
14                 {
15                     //註冊服務類
16                     services.AddScoped(i, type.Key);
17                 });
18             }
19             return services;
20         }
21 
22         /// <summary>
23         /// 根據程序集名稱獲取自定義服務
24         /// </summary>
25         /// <param name="assembly"></param>
26         /// <returns></returns>
27         public static Dictionary<Type, Type[]> GetConfigureClass(string assembly)
28         {
29             Dictionary<Type, Type[]> dic = new Dictionary<Type, Type[]>();
30             if (!string.IsNullOrEmpty(assembly))
31             {
32                 //獲取程序集對應的類型
33                 Assembly dll = Assembly.LoadFrom(assembly);
34                 List<Type> lstType = dll.GetTypes().ToList();
35                 lstType.ForEach(x =>
36                 {
37                     //篩選滿足條件的服務類
38                     if (x.IsClass && x.GetInterfaces().Length > 0)
39                     {
40                         dic.Add(x, x.GetInterfaces());
41                     }
42                 });
43             }
44             return dic;
45         }
46    }

然後我們ConfigureServices方法中註冊:

        public void ConfigureServices(IServiceCollection services)
        {
            //批量註冊
            services.AddBatchServices();
        }

對於批量註冊,ASP.Net Core允許我們更換默認的IOC容器,感興趣的同學可以試試AutoFac容器支持的程序集掃描式註冊。

註冊我們自己的服務,往往在項目開發過程中是必要的,希望以上簡單的分享能給需要的小夥伴們帶來一點收貨。

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

【其他文章推薦】

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

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

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

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

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

以太坊節點發現協議

本檔前部分翻譯自以太坊定義的節點發現協議(版本4),後半部分給出了源碼實現的大致流程,以幫助理解。

以太坊節點信息的存儲採用的是Kademlia分佈式哈希表。理解節點發現協議主要是理解分佈式哈希表的原理,再加上定義的節點間通信的報文格式,節點ID的定義,距離的計算,加在一起就是以太坊的節點發現協議了。以太坊不同語言版本代碼實現上具體細節可能不同但大致流程思想是相同的。

第一部分——節點發現協議定義

節點ID

每個節點都有一個secp256k1橢圓曲線密碼學ID。節點的公鑰作為標識或節點ID。節點之間的距離為公鑰按位異或或者是公鑰的哈希值按位異或。計算公式如下:

distance(n₁, n₂) = keccak256(n₁) XOR keccak256(n₂)

節點表

節點表在節點發現協議中用於保存鄰節點信息。鄰節點被存在一個包含有K桶的路由表中。協議中\(k=16\),即每個K桶至多含有16個節點條目。每項按時間排序——最新發現更新的節點放在前,其他在後。

每當一個新節點\(N_1\)被發現,就可以插入相應的桶中。如果桶中少於\(k\)個條目,\(N_1\)可添加到桶中第一個條目。如果桶中已含有\(k\)項,桶中最早發現的節點\(N_2\),需要通過發送ping包重新檢測其有效性。如果沒有收到來自\(N_2\)的回復則認為該節點已失效(下線),從路由表中移除並將\(N_1\)添加到桶的前部。

以太坊文檔中Node Table一節有部分內容錯誤, For each 0 ≤ i < 256, every node keeps a k-bucket for nodes of distance between 2i and 2i+1 from itself. ,應該是\([2^i,2^{i+1})\) 。建議閱讀論文Kademlia——A Peer-to-peer Information System Based on the XOR Metric。

端點驗證

為了預防流量放大攻擊,必須驗證查詢的發送者是否參与了發現協議。如果數據包的發送者在過去12小時內發送了具有匹配ping哈希的有效pong響應,則認為該數據包的發送者已經過驗證。

遞歸查找

一次查找會找到\(k\)個距離目標節點最近的節點。節點查找發起后先選取\(a\)個距離目標節點最近的已知節點。隨後同時向這些節點發送FindNode包。其中,\(a\)是一個參數,通常可設為3。發起者繼續向先前查詢到的節點發送FindNode,如此不斷進行遞歸。對獲知的\(k\)個離目標節點最近的節點,選取\(a\)個尚未查詢過的節點向其發送FindNode。無法快速響應的節點將被排除在外,除非他們做出響應。

如果一輪FindNode查詢失敗,即沒有返回任何一個比目前節點中更近的節點,那麼將會繼續向\(k\)個最近節點未被查詢過的節點中發送FindNode

報文協議

節點發現協議報文都是UDP報文,報文中最大的是1280字節。

packet = packet-header || packet-data

數據包頭部:

packet-header = hash || signature || packet-type
hash = keccak256(signature || packet-type || packet-data)
signature = sign(packet-type || packet-data)

當在同一UDP端口上運行多個協議時,hash可使分組格式可識別。除此並無其他目的。每個包都由節點公鑰來簽名,簽名是一個編碼長度為65字節數組,簽名值r,s,簽名驗證值v

消息類型packet-type占單字節。包有效數據在消息類型後面。數據包頭部之後的數據用RLP進行編碼。根據EIP-8,實現應忽略列表中的任何其他元素以及列表后的任何額外數據。

Ping Packet (0x01)

packet-data = [version, from, to, expiration]
version = 4
from = [sender-ip, sender-udp-port, sender-tcp-port]
to = [recipient-ip, recipient-udp-port, 0]packet-data = [ver

expiration字段是UNIX時間戳,如果一個數據包的時戳過期了可能會無法處理。收到ping數據包后,接收節點應回復pong數據包。並可考慮將發送節點添加到節點表中。

如果在過去12小時內未與發送方進行任何通信,則除了pong之外還應發送ping以驗證對端節點。

Pong Packet (0x02)

packet-data = [to, ping-hash, expiration]

Pong是ping的響應。ping-hash須與相應的ping包hash一致。實現時應該忽略那些不含有ping包hash的pong包。

FindNode Packet (0x03)

packet-data = [target, expiration]

FindNode包用於請求距離目的節點近的節點。目標節點ID是一個65字節長度的secp256k1橢圓曲線公鑰。當接收到FindNode,接收端需要回復在本地節點表中距離請求目的節點最近的16個節點。

為了對抗流量放大攻擊,只有被驗證過的FindNode發送者才會被回復鄰節點信息。

Neighbors Packet (0x04)

packet-data = [nodes, expiration]
nodes = [[ip, udp-port, tcp-port, node-id], ... ]

FindNode包的響應。

存在的問題及建議

凡含有expiration字段的數據包都是用於防止數據重放的。因為是絕對時間戳,節點時鐘必要要十分準確以正確驗證時戳的有效性。自從2016年協議發布後起,已經接收到無數的因為用戶的時鐘不準確造成的錯誤報告。

端點驗證是不嚴密是因為FindNode的發送方永遠法確定接收端十分接收到足夠的pong。Geth按如下方式處理:如果在最近12小時內未與收件人進行通信,請通過發送ping啟動該過程。等待來自另一方的ping,回復它然後發送FindNode

第二部分——節點發現協議代碼實現流程
流程圖

節點如何加入到對應的K桶

計算節點之間的距離很簡單,直接按位異或后的值即為兩節點之間的距離值,但節點應該加入那個K桶呢?可以公鑰哈希值按位異或后最高位的值(例如: 異或值0000 ... 0000 0101,則桶距離為3 ),則將節點放入第3個桶中。

為什麼?

主要是要理解二叉樹的拆分過程:
對每一個節點,都可以按照自己的視角對整個二叉樹進行拆分。拆分的規則是:先從根節點開始,把不包含自己的那個子樹拆分出來;然後在剩下的子樹再拆分不包含自己的下一層子樹;以此類推,直到最後只剩下自己。

拆分的最後一個K桶(距離自己最近的那個K桶),只有最後1位不同,異或值為0000 ... 0000 0001,最高位為1,第一個K桶;拆分的倒數第二個K桶,異或值為0000 ... 0000 001x,最高位為2,第二個K桶;依此類推……

在具體實現細節上,以太坊節點節點公鑰是512位,計算距離時的ID是取節點公鑰的哈希,值為256位。所以節點路由表由256個K桶組成,每個K桶最多16個節點。

參考文檔:
Node Discovery Protocol v4
聊聊分佈式散列表(DHT)的原理——以 Kademlia(Kad) 和 Chord 為例
Kademlia——A Peer-to-peer Information System Based on the XOR Metric

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

【其他文章推薦】

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

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

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

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

※回頭車貨運收費標準