分類
發燒車訊

小師妹學JavaIO之:文件系統和WatchService

目錄

  • 簡介
  • 監控的痛點
  • WatchService和文件系統
  • WatchSerice的使用和實現本質
  • 總結

簡介

小師妹這次遇到了監控文件變化的問題,F師兄給小師妹介紹了JDK7 nio中引入的WatchService,沒想到又順道普及了一下文件系統的概念,萬萬沒想到。

監控的痛點

小師妹:F師兄最近你有沒有感覺到呼吸有點困難,后領有點涼颼颼的,說話有點不順暢的那種?

沒有啊小師妹,你是不是秋衣穿反了?

小師妹:不是的F師兄,我講的是心裏的感覺,那種莫須有的壓力,還有一絲悸動纏繞在心。

別繞彎子了小師妹,是不是又遇到問題了。

更多精彩內容且看:

  • 區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
  • Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
  • Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
  • java程序員從小工到專家成神之路(2020版)-持續更新中,附詳細文章教程

更多內容請訪問www.flydean.com

小師妹:還是F師兄懂我,這不上次的Properties文件用得非常上手,每次修改Properties文件都要重啟java應用程序,真的是很痛苦。有沒有什麼其他的辦法呢?

辦法當然有,最基礎的辦法就是開一個線程定時去監控屬性文件的最後修改時間,如果修改了就重新加載,這樣不就行了。

小師妹:寫線程啊,這麼麻煩,有沒有什麼更簡單的辦法呢?

就知道你要這樣問,還好我準備的比較充分,今天給你介紹一個JDK7在nio中引入的類WatchService。

WatchService和文件系統

WatchService是JDK7在nio中引入的接口:

監控的服務叫做WatchService,被監控的對象叫做Watchable:

WatchKey register(WatchService watcher,
                      WatchEvent.Kind<?>[] events,
                      WatchEvent.Modifier... modifiers)
        throws IOException;
WatchKey register(WatchService watcher, WatchEvent.Kind<?>... events)
        throws IOException;

Watchable通過register將該對象的WatchEvent註冊到WatchService上。從此只要有WatchEvent發生在Watchable對象上,就會通知WatchService。

WatchEvent有四種類型:

  1. ENTRY_CREATE 目標被創建
  2. ENTRY_DELETE 目標被刪除
  3. ENTRY_MODIFY 目標被修改
  4. OVERFLOW 一個特殊的Event,表示Event被放棄或者丟失

register返回的WatchKey就是監聽到的WatchEvent的集合。

現在來看WatchService的4個方法:

  1. close 關閉watchService
  2. poll 獲取下一個watchKey,如果沒有則返回null
  3. 帶時間參數的poll 在等待的一定時間內獲取下一個watchKey
  4. take 獲取下一個watchKey,如果沒有則一直等待

小師妹:F師兄,那怎麼才能構建一個WatchService呢?

上次文章中說的文件系統,小師妹還記得吧,FileSystem中就有一個獲取WatchService的方法:

public abstract WatchService newWatchService() throws IOException;

我們看下FileSystem的結構圖:

在我的mac系統上,FileSystem可以分為三大類,UnixFileSystem,JrtFileSystem和ZipFileSystem。我猜在windows上面應該還有對應的windows相關的文件系統。小師妹你要是有興趣可以去看一下。

小師妹:UnixFileSystem用來處理Unix下面的文件,ZipFileSystem用來處理zip文件。那JrtFileSystem是用來做什麼的?

哎呀,這就又要扯遠了,為什麼每次問問題都要扯到天邊….

從前當JDK還是9的時候,做了一個非常大的改動叫做模塊化JPMS(Java Platform Module System),這個Jrt就是為了給模塊化系統用的,我們來舉個例子:

public void useJRTFileSystem(){
        String resource = "java/lang/Object.class";
        URL url = ClassLoader.getSystemResource(resource);
        log.info("{}",url);
    }

上面一段代碼我們獲取到了Object這個class的url,我們看下如果是在JDK8中,輸出是什麼:

jar:file:/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre/lib/rt.jar!/java/lang/Object.class

輸出結果是jar:file表示這個Object class是放在jar文件中的,後面是jar文件的路徑。

如果是在JDK9之後:

jrt:/java.base/java/lang/Object.class

結果是jrt開頭的,java.base是模塊的名字,後面是Object的路徑。看起來是不是比傳統的jar路徑更加簡潔明了。

有了文件系統,我們就可以在獲取系統默認的文件系統的同時,獲取到相應的WatchService:

WatchService watchService = FileSystems.getDefault().newWatchService();

WatchSerice的使用和實現本質

小師妹:F師兄,WatchSerice是咋實現的呀?這麼神奇,為我們省了這麼多工作。

其實JDK提供了這麼多類的目的就是為了不讓我們重複造輪子,之前跟你講監控文件的最簡單辦法就是開一個獨立的線程來監控文件變化嗎?其實…..WatchService就是這樣做的!

PollingWatchService() {
        // TBD: Make the number of threads configurable
        scheduledExecutor = Executors
            .newSingleThreadScheduledExecutor(new ThreadFactory() {
                 @Override
                 public Thread newThread(Runnable r) {
                     Thread t = new Thread(null, r, "FileSystemWatcher", 0, false);
                     t.setDaemon(true);
                     return t;
                 }});
    }

上面的方法就是生成WatchService的方法,小師妹看到沒有,它的本質就是開啟了一個daemon的線程,用來接收監控任務。

下面看下怎麼把一個文件註冊到WatchService上面:

private void startWatcher(String dirPath, String file) throws IOException {
        WatchService watchService = FileSystems.getDefault().newWatchService();
        Path path = Paths.get(dirPath);
        path.register(watchService, ENTRY_MODIFY);

        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            try {
                watchService.close();
            } catch (IOException e) {
                log.error(e.getMessage());
            }
        }));

        WatchKey key = null;
        while (true) {
            try {
                key = watchService.take();
                for (WatchEvent<?> event : key.pollEvents()) {
                    if (event.context().toString().equals(fileName)) {
                        loadConfig(dirPath + file);
                    }
                }
                boolean reset = key.reset();
                if (!reset) {
                    log.info("該文件無法重置");
                    break;
                }
            } catch (Exception e) {
                log.error(e.getMessage());
            }
        }
    }

上面的關鍵方法就是path.register,其中Path是一個Watchable對象。

然後使用watchService.take來獲取生成的WatchEvent,最後根據WatchEvent來處理文件。

總結

道生一,一生二,二生三,三生萬物。一個簡簡單單的功能其實背後隱藏着…道德經,哦,不對,背後隱藏着道的哲學。

本文的例子https://github.com/ddean2009/learn-java-io-nio

本文作者:flydean程序那些事

本文鏈接:http://www.flydean.com/java-io-file-watchservice/

本文來源:flydean的博客

歡迎關注我的公眾號:程序那些事,更多精彩等着您!

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

【其他文章推薦】

※回頭車貨運收費標準

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

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

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

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

分類
發燒車訊

500萬一台的勞斯萊斯SUV要來了 有什麼吸引土豪的新配方?

少於四百萬的話,對於這個級別的SUV來說,可能都算得上是便宜的了。

現在市面上售價最昂貴的SUV車型是賓利添越,398-480萬的售價可謂之天價,如此高昂的售價不僅僅是普通人可望不可及,也會讓眾多傳統意義上的豪華品牌SUV在賓利添越面前顯得黯然失色。

而玩豪華玩奢侈的汽車品牌不僅僅只有賓利一家,汽車業界著名的奢華品牌勞斯萊斯近日公布了兩張路試諜照,而主角正是可能成為勞斯萊斯旗下首款SUV車型,——項目代號Cullinan。

首先要說明的是,Culinan並不是該款SUV正式的名稱,而是勞斯萊斯品牌開發SUV車型項目的代號,該款車型具體名稱暫時不得而知。

從諜照中可以看出,儘管車身上覆蓋著厚重的偽裝,但是前臉是類似現在勞斯萊斯家族式設計,依然是靈感源自帕提農神廟的直瀑式進氣格柵,其他細節處設計暫未公布,但是不妨來看看國外媒體所曝光的渲染圖。

這些圖片僅僅是假想圖,真實程度並不高,但我們不妨可以做一個猜想,在賓利添越配備6.0T W12渦輪增壓發動機的前提下,作為與賓利添越抗衡的一款奢華級SUV,勞斯萊斯SUV也將會匹配一款12缸數的渦輪增壓引擎。

【賓利添越的W12發動機】

而賓利添越作為一款奢華級的SUV,在道路適應性方面同樣有着出色的性能表現,如此,也可以確定勞斯萊斯SUV將會在全球多種地區、多種複雜路況下對其進行嚴苛性較強的測試,以致力於生產出一款性能卓越的車型。

全文總結:無論是勞斯萊斯SUV還是賓利添越,用四五百萬去買一台汽車對於普羅大眾來說終究不太現實,但是作為愛車人士,看看熱鬧過過眼癮也是不錯的選擇,根據目前公布的路試諜照推測,如果進度正常,這款SUV將有可能在2018年左右發布,至於售價嘛……少於四百萬的話,對於這個級別的SUV來說,可能都算得上是便宜的了……本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※回頭車貨運收費標準

台中搬家公司費用怎麼算?

分類
發燒車訊

手把手帶你入門numpy,從此數據處理不再慌【四】

本文始發於個人公眾號:TechFlow,原創不易,求個關注

今天是numpy專題的第四篇文章,numpy中的數組重塑與三元表達式。

首先我們來看數組重塑,所謂的重塑本質上就是改變數組的shape。在保證數組當中所有元素不變的前提下,變更數組形狀的操作。比如常用的操作主要有兩個,一個是轉置,另外一個是reshape。

轉置與reshape

轉置操作很簡單,它對應線性代數當中的轉置矩陣這個概念,也就是說它的功能就是將一個矩陣進行轉置

轉置矩陣的定義是將一個矩陣的橫行寫為轉置矩陣的縱列,把縱列寫成轉置矩陣的橫行。這個定義的是二維的矩陣,本質上來說,轉置操作其實是將一個矩陣沿着矩陣的大對角線進行翻轉。翻轉之後,顯然這個矩陣的各個維度都會發生變化。

其中二維的矩陣最直觀,一個4 x 3的矩陣,轉置之後得到的是3 x 4的矩陣。如果維度更多呢?如果是3 x 2 x 4的矩陣轉置之後會得到什麼?

很簡單,得到的會是4 x 2 x 3的矩陣。我們都知道,如果我們把一個矩陣各個維度的大小寫在一起,會得到一個元組(tuple),這個元組稱為矩陣的shape,我實在是不知道該怎麼翻譯這個單詞,但是我覺得叫做形狀不太妥當,所以就保留了英文原文。轉置之後,矩陣的shape會整個翻轉。比如(3, 2, 4)會變成(4, 2, 3)。

我們可以來看一個例子,會更加的直觀。首先我們先看最簡單的二維矩陣:

這是隨機出來的一個3 x 4的二維矩陣,在numpy當中,有兩種方式獲取一個矩陣或者是數組的轉置。第一種方式是通過在數組的變量名之後加上.T操作符,第二種方式是調用numpy中的transpose函數,這兩種方式是一樣的。我個人比較傾向於前者,寫起來比較簡單。

我們可以看到轉置之後新的矩陣的第一列其實是原矩陣的第一行,第一行是原矩陣的第一列。可以看成是原矩陣按照從左上角到右下角的一條無形的線翻轉之後的結果。

理解了轉置之後,我們再來看reshape操作。其實我們從這個單詞上也能大概猜到它的意思,reshape也就是再次shape的意思,本意是根據我們想要的shape重新組裝矩陣當中的元素

我們來看一個例子吧,首先,我們通過arange方法來獲取一個一維的數組:

因為是1維的,所以我們去看它的shape也只有一維。假設我們不喜歡這樣的一維數組,而想把它變成3 x 4或者是6 x 2的格式,這時候使用reshape就會很方便。

本質上來說reshape操作其實就是按照順序從矩陣當中獲取元素,然後按照我們制定的shape填充出一個新的矩陣的操作。這個應該不難理解, 它也是非常常用的重塑操作,通過reshape和轉置,我們可以很方便地操作矩陣的大小,根據我們的需要作出改變。

三元表達式

在許多編程語言當中我們經常會用到三元表達式,三元表達式其實本質就是if-else語句,只是我們用特殊的方法將它簡寫。

比如說在C++當中,我們可以把if condition A else B簡寫成:condition ? A : B。Python同樣支持三元表達式,不過對C++的三元表達式做了一些改動,在Python當中三元表達式寫成:A if condition else B。相對來說更加直觀一些,我們經常會在數組初始化的時候用到三元表達式。

比如,我們可能會這樣生成一個數組:

arr = [1 if condition else 0 for _ in range(10)]

我們通過條件來判斷了每一位是1還是0來生成了一個數組,簡化了代碼。在numpy當中同樣繼承了這個用法,我們一樣可以使用三元表達式,不過numpy將它封裝進了where函數當中,我們是通過調用一個方法來實現三元表達式的功能。我們來看下具體的用法,假設我們有兩個數組:

我們還有一個bool型的數組c,我們希望根據c數組選擇從a數組或者是b數組當中獲取數據。我們可以使用where寫成這樣:

在這個例子當中,c數組中的1和0分別表示True和False。當我們調用np.where的時候,numpy會自動根據c數組當中的值去選擇從a數組還是b數組當中獲取數據。相當於我們執行了這麼一段代碼:

[x if c else y for c, x, y in zip(c, a, b)]

雖然兩者的運行結果是一樣的,但是顯然使用循環的方法計算耗時更長,而使用numpy的向量做法運算速度更快。除此之外,numpy的where方法還支持高維的數組,但是循環的方法不行。並且where還有一些更高級的用法,比如說我們傳入的第二個和第三個參數,可以不是數組而是一個標量。比如我們可以指定當c中的元素是True的時候填入1,否則填入-1:

甚至我們還可以將標量和向量結合起來使用:

並且這裏的數組c也可以替換成邏輯運算:

總結

今天的文章主要介紹了Numpy當中的reshape、轉置以及where的用法,這些也是numpy的基礎用法,尤其是轉置、reshape,幾乎是處理數據必用的方法。所以想要從事Python機器學習或者是人工智能的小夥伴,numpy的這些用法是一定要會的。

本文當中介紹的只是numpy的一些固定套路,但其實numpy很多的用法是可以組合的,一些看似平淡無奇的用法組合在一起之後會有神奇的效果。這一點光看書或者是資料是很難窮盡的,所以如果你已經學會了這些api的基本使用,接下來最應該做的是去讀一些大牛的源碼,看看大牛們是如何運用這些工具的,相信一定還會有新的收貨。

文章就到這裏,如果喜歡本文,可以的話,請點個關注

本文使用 mdnice 排版

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

分類
發燒車訊

WinUI 3 試玩報告

1. 什麼是 WinUI 3

在微軟 Build 2020 開發者大會上,WinUI 團隊宣布可公開預覽的 WinUI 3 Preview 1,它讓開發人員可以在 Win32 中使用 WinUI。WinUI 3 Preview 1 包含新的 VisualStudio 項目模板,可以創建面向 .NET 5 的 C# 和 C++/Win32 項目。從技術上講,WinUI 3 將 UWP 的 XAML、Composition 和 Input 層分離,並通過NuGet將它們獨立分發給針對Windows 10 版本 1803 及更高版本的 Win32 應用。

WinUI 3 適用於 Win32 和 UWP,這篇文章主要討論 Win32 的情況。

2. 理解 WinUI 3

以前我們總是抱怨 WPF 多年都不提供新的主題,不提供新的控件,性能又沒提升。現在微軟索性把什麼都是新的 WinUI 3 提供給桌面開發,沒 WPF 什麼事了。

簡單來說,UWP 的開發體驗不好(關於這個話題真是一言難盡),而且出了 Bug 還必須等待下半年的 Windows 更新進行修復,但微軟的開發人員專心給 UWP 的 UI 層加各種功能;.NET Core 更新很快,但很少人有興趣有動力給陳舊的 WPF 的 UI 層進行大幅度的改進。於是 WinUI 將 UWP 的 UI 層從 Windows SDK 的其它部分分離,並將從 Windows 轉移到 Nuget。現在建一個 C++ 或 C#(.NET 5) 程序,再從 Nuget 上裝個 WinUI 3 的包套個 UI 層,一個基於 Fluent Design,觸摸友好,性能無與倫比的應用程序就誕生了。

上圖列舉了 WinUI 3 和其他平台對比的部分特性,除此之外 WinUI 3 還有很多好處,例如開源、更新更快、更新不與系統版本綁定等,更詳細的內容還是看微軟自己怎麼宣傳吧:

WinUI – The modern native UI platform of Windows.

不過要用上 WinUI 3 還要等一年半載。下面是微軟給出的發布路線圖,目前我們也只能用 Preview 版嘗嘗鮮。

3. 試玩WinUI 3

要試玩 WinUI 3 首先要有 Windows 10 1803 以上版本的電腦(WinUI 3 最低支持1803),然後還需要使用 Visual Studio 2019 16.7 以上版本(目前只能安裝預覽版)。安裝 Visual Studio 時要把以下工作負載全都選上:

  • .NET 桌面開發
  • 通用 Windows 平台開發
  • 使用 C++ 的桌面開發
  • 適用於通用 Windows 平台負載的 C++(V142) 通用 Windows 平台工具可選組件

當然 .NET 5.0 也要裝上。

然後在 https://aka.ms/winui3/previewdownload 下載並安裝 WinUI 3 Project Templates 擴展,這樣才可以在 Visual Studio 創建 WinUI 的項目。

可選 C++ 或 C# ,這裏我選擇了 C# 的“Blank App, Packaged
(WinUI in Desktop)”項目,並選擇了對應的 Windows 平台:

項目創建后 Visual Studio 生成了兩個項目。第一個包含應用的代碼,代碼結構基本和 UWP 一樣,只是少了用於打包應用的 Package.appxmanifest 和一些圖片。從依賴項里可以看到項目已經安裝了 Microsoft.WinUI 3 的包。從項目屬性里可以看到這就是個 .NET 5 的項目。

Visual Studio 生成的第二個項目是一個 Windows 應用程序打包項目,該項目經配置后可將應用生成為適合部署的 MSIX 程序包。 也就是說 UWP 項目中用於打包的部分被獨立出來了。這個項目還應該是解決方案的啟動項目。運行這個項目后創建的應用會添加到開始菜單中,這點也和UWP一樣。

到這裏為止都和預期的一樣,我之後還嘗試了將 UWP 應用移植到 WinUI ,基本上只需要將 Windows.UI 命名空間改為 Microsoft.UI就可以了,XAML 和 C# 代碼完全不用變。只可惜目前 WinUI 還很簡陋,Win2D、Community Toolkit 等微軟自己發布的 UWP 包都還沒有 WinUI 版本。而且沒有設計視圖,XAML 視圖也沒有智能感知,現在想要用 WinUI做些什麼有趣的項目會很困難。不過從目前的移植難度上來看,將來正式發布后應該可以完整地將 UWP 的 UI 的開發經驗運用在 WinUI 上。

4. 和 WPF 及 UWP 進行對比

既然 WinUI 3 開發模式和 WPF 及 UWP 都很像,我當然對它們之間的對比很感興趣。

命名

首先說說命名,“WinUI” 光這個名字就 Win 了。 “UWP” 太高雅,我敢打賭國內有些 UWP 的開發(例如我)都不能好好地把 UWP 的全稱拼出來;“WPF” 好些,但 WPF 的含義也讓人很疑惑。而 Windows UI 簡稱 WinUI ,意義和發音都很清晰明確。不過這三個都比很多人都不會讀的 “Xamarin” 強多了。

可是有了 WinUI 3 ,就會有人問“那 WinUI 2 呢?”WinUI 2是一個 UWP 的控件庫,當然的只能用在 UWP 上。這就很尷尬了,WinUI 的 3 和 2 根本不是同一個概念,實在很容易讓人混淆,說不定以後會把後綴的 3 去掉(我這篇文章就常常懶得理寫這個3)。而且 UWP 中代碼的命名空間以 Windows.UI 開頭,在 WinUI 3 中則 Microsoft.UI ,按着 Office 365 改名為 Microsoft 365、Bind Ads 改名為 Microsoft Advertising 這些經驗,該不會以後 WinUI 可能改名為 Microsoft UI ,簡稱 MiUI 吧?

權限

權限方面是 WinUI 的一個亮點,因為它本質上就是個 Win32 程序,可以放開手腳隨便來。相對的 UWP 有很嚴格的權限限制,開發 UWP 時常常會感到綁手綁腳。例如下面這段代碼,大部分 WPF 開發者都難以想象只是最小化 UWP 程序而已,它就不能好好運行了:

int count = 0;
DispatcherTimer timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromSeconds(1);
timer.Tick += (s, e) =>
  {
      myButton.Content = count++;
  };
timer.Start();

UWP 的生命周期如上圖,當 UWP 處於 background 運行或 suspended 狀態時應用基本處於暫停狀態,也也不會處理UI功能。我明白這是 UWP 為了省電、安全等原因才這樣設計,但對開發人員來說真的太不方便。而 WinUI 應用基本上就是個 Win32 應用,目前看來不會有這些坑。

開發體驗

說起開發體驗,WPF 好歹還算正常,Visual Studio 的設計視圖運行正常,編譯起來也快。UWP 編譯很慢,設計視圖經常出問題,Blend 也時好時壞把設計師都氣跑了。就算完全按着官方的文檔完成一個 UWP App,甚至一行代碼都不改,發布到商店后還是有可能崩潰。而對於應用商店,真是千言萬語彙聚成一個草花頭。

現在 WinUI 的 XAML 視圖連智能感知都沒有,也沒有設計視圖,實在沒法談開發體驗。很難猜測正式發布的時候會怎麼樣,希望至少和WPF保持一致吧。

性能

WPF 總是給人“慢”的印象,除了因為在它剛出來的時候(10年前)電腦性能不夠導致留下了刻板印象,還有一個主要原因是:它真的很慢。

UWP 的 XAML 有很優秀的性能表現,除此之外為了照顧已經不存在的 Windows Phone 的貧弱性能,很多控件模版都經過精心設計並大幅簡化。

為了驗證 WinUI 的性能我寫了下面這些代碼,然後分別移植到 WPF .Net Framework 4.8、WPF .NET 5、UWP、WinUI(WPF 和 UWP/WinUI 的代碼稍微有一點不同):

for (int i = 0; i < 50; i++)
{
    var rectangle = new Rectangle
    {
        Height = 500,
        Width = 500,
        Opacity = ((double)i + 40) / 100d,
        RadiusX = 108,
        RadiusY = 98,
        StrokeThickness = 3,
        Stroke = new SolidColorBrush(Color.FromArgb(255, 75, 75, (byte)(i * 250d / 50d))),
        RenderTransformOrigin = new Point(0.5, 0.5)
    };
    Root.Children.Add(rectangle);
    var angle = i * 360d / 50d;
    var transform = new RotateTransform
    {
        Angle = angle
    };

    rectangle.RenderTransform = transform;

    var storyboard = new Storyboard();
    storyboard.Children.Add(new DoubleAnimation { Duration = TimeSpan.FromSeconds(1), From = angle, To = angle + 360 });
    Storyboard.SetTarget(storyboard, transform);
    Storyboard.SetTargetProperty(storyboard, "Angle");
    storyboard.RepeatBehavior = RepeatBehavior.Forever;
    storyboard.Begin();
}

上面這段代碼是讓50個矩形旋轉,十分考驗 WPF 的性能。結果可以說出乎意料。

CPU 內存 GPU
WPF .NET Framework 4.8 12 60 76
WPF .NET 5.0 12 85 72
UWP 3 28 36
WinUI 5 65 95

我的環境是 i7-6820HQ 及集成顯卡。WPF 平台佔用 70 多%的 GPU,這我大致能猜到。UWP 十分流暢,GPU 只佔用 WPF 的一半,CPU 和 內存都有出色表現,不過我還以為會更低的。

WinUI 這個濃眉大眼的我真的萬萬沒想到,不僅掉幀明顯,還佔用了幾乎 100% GPU,也就是說它連這麼簡單的代碼都跑不起來。()順便一提,將測試代碼中旋轉的矩形減少為10個,WPF 的程序佔用 32% GPU,而 WinUI 佔用 70 多%。)

從上面的數據基本可以說明,WinUI 離設計目標還十分遙遠,畢竟是預覽版,還有一年半載可以慢慢優化。

5. 結語

總的來說微軟雄心勃勃,可是現在拿出來的 WinUI 預覽版還差得太遠,功能未完善,性能不及預期。我覺得大致方向沒錯,WinUI 對 C++、WPF、UWP 開發者都是個新的工具新的機遇,可以關注一下。

6. Q & A

Windows 7 怎麼辦?

按微軟公布的路線圖,再包括跳票等因素,等 WinUI 真正可用時 Windows 7 已停止更新很久,到時 Windows 7 的佔有率可能已經下降到開發者不會關心的程度。

基於 .NET Core 的 Wpf 還是 WinUI?

假使不想花精力將現有項目遷移到 WinUI,或者對來自 UWP 的 WinUI 沒信心,又或者舍不得 Windows 7 的用戶,並且對觸摸沒需求,當然可以繼續選用 WPF,基於 .NET Core 的 WPF 會是個很好的選擇。

MAUI 還是 WinUI ?

MAUI 還在很遙遠的將來(2021年11月),我沒試玩過,所以不好評價。如果有跨平台需求當然只能選 MAUI,如果 WinUI 團隊技高一籌實現了 MAUI 難以企及的超高性能,那就選 WinUI。不過 MAUI 這個名字太過普通/普遍,可能會被逼着改名吧。

那 UWP 呢?

權限受限的 UWP 可以說是人畜無害,對用戶來說可能也是個不錯的選擇。而且 UWP 還支持 Xbox 和 Hololens 等平台,目前看來還是有它的市場。

Winforms 呢?

人只有忘卻了過去,才能好好活着。

WinUI 有未來嗎?

我做了好多年 Silverlight 開發,買了5、6部 Windows Phone 手機,寫了幾十篇 UWP 文章,根據我豐富的經驗,我可以肯定 WinUI 是有未來的。

8. 參考

WinUI – The modern native UI platform of Windows.

Introducing WinUI 3 Preview 1 – Windows Developer Blog

Get started with WinUI 3 for desktop apps Microsoft Docs

GitHub – microsoft_microsoft-ui-xaml

Windows UI Library Roadmap

WinUI 3.0_ The future of Windows controls

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

【其他文章推薦】

※回頭車貨運收費標準

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

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

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

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

分類
發燒車訊

你真的了解EF嗎?關於EntityFramework的優化

接上一篇文章。現在寫程序,做項目不是說功能做完就完事了,在平常的開發過程中對於性能的考慮也是極其重要的。

關於ef的那些事,今天就來說說吧。首先必須得知道.net ef在程序中的五種狀態變化過程與原理。

主要來說說查詢部分的性能優化,在所有查詢中,客戶端查詢出來的數據一般來說是不需要進行跟蹤的。也就是說查詢只是給用戶看,不做其他任何操作。對於基於B/S模式的項目網站開發,應該是無狀態的,也就是ef中的遊離態(Unchanged)(個人理解)。如果是C/S可能還需要進行其他連接的狀態。通俗的說,在開發過程不用去檢測某一個屬性或者類是否被修改或者刪除。

例如:

AsNoTracking:它的作用就是在查詢的過程中不被緩存,也就是不被保留,查出來就完事了,這樣的狀態就變成了Detached遊離態

//AsNoTracking:它的性能比ToList快大約4.8倍,不被緩存的數據。
var item=db.Book.AsNoTracking().First(m=>m.Id==1);
Console.WriteLine(db.Entry(item).State); //輸出Detached(遊離態)

去掉AsNoTracking

var item=db.Book.First(m=>m.Id==1);
Console.WriteLine(db.Entry(item).State); //輸出UnChanged(持久態)

也就是加上AsNoTracking做出來的查詢操作,就和數據庫斷絕了關係(個人理解)這樣對性能也是一個極好的優化。

然後來說說在項目中對ef整體框架優化的使用。

C#是一門面向對象的語言無外乎就是封裝、繼承、多態。。。類可以繼承類,同樣接口也可以繼承接口。面向對象的思想就是每張表都應該有一個父類,只寫一遍,其他類繼承就好了不用重複去寫。

建立一個空白的解決方案,添加一個名為BaseEntity的類,你可以把它看做是所有類的基礎類(父類)。

重點來說說這個BaseEntity為什麼要作為基礎類,它的用意何在。

先看看裏面的寫了些什麼吧!

以前用int或者long作為主鍵自增長的數據類型,這樣後期數據非常龐大的時候可能會無法預估難免可能會出現重複的數據,這個時候對於整個系統來說就無法保障了。

Guid給我做出了一個計算,它是32位的数字加字母的組合,而且是特別長的不會重複的自增數,可以這樣去理解。

DateTime就是每條數據的創建時間,IsRemove就是作為數據邏輯刪除的標識,也就是說,每個類(表)都會存在這三個字段屬性。你可以通過DateTime對沒張表進行排序的操作。

using System;
namespace Book.Models
{
    public class BaseEntity
    {
        public Guid Id { get; set; }=Guid.NewGuid(); //計算32位,字母加数字,特別長的,不重複的,自增數
        public DateTime DateTime { get; set; }=DateTime.Now;    //每條數據的創建時間
        public bool IsRemove { get; set; }  //偽刪除的標識
    }
}

創建BookType類

using System.ComponentModel.DataAnnotations;

namespace Book.Models
{
    public class BookType:BaseEntity
    {
        [StringLength(20)]
        public string Name { get; set; }
    }
}

創建Book類

using System.ComponentModel.DataAnnotations;

namespace Book.Models
{
    public class Book:BaseEntity
    {
        [StringLength(50),Required]
        public string Name { get; set; }
        public decimal Price { get; set; }
    }
}

這兩個類都會繼承BaseEntity

在App.Config裏面寫上你自己的數據庫連接字符串

這樣的目的就是去生成數據庫,只做生成數據庫的操作。這裏只是在Models層寫了一次,在後期加上表示層還有在寫一遍!

接下來就是去通過指令遷移到數據庫,操作有三步:

  1. 啟動遷移:enable-migrations
  2. 添加遷移:add-migration ‘參數’
  3. 更新數據庫:update-database(如果你需要添加或者修改某個字段屬性,只需要進行第二步和第三步的操作即可!)

記住默認項目要選擇你的Models,如果是多個項目(我這裡是只有一個)就必須要把Models設為啟動項目,不然遷移指令可能不會起到作用

這樣就表示你的數據庫遷移的工作已經完成了,你可以在數據庫進行查看

 接下來的工作就是準備分層的工作,什麼是分層?怎麼分?好處是什麼?

我的理解:聽某一個大佬說,代碼是一層一層寫的不是一行一行寫的。個人覺得拿捏了。原諒我沒去百度。。。

一直覺得對於面向對象的思想,一直覺得自己才疏學淺,學的只是皮毛,真是非常的慚愧。

剛好借這個機會來通過分層一起來學習學習。三層,在之前的學習中對於三層也只是找到表示層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。

個人覺得,這樣確實是解耦了,但是,並沒有將業務邏輯層的“業務邏輯”這一詞的功能發揮到極致,就只是簡單的從UI層get一下BLL層,BLL層簡單的get一下DAL層。。。(個人覺得並沒有解什麼耦。。。來自菜鳥的思考)

那我們可不可以封一個接口層,通過面向對象的繼承來去調整一下呢?

首先得明確接口是可以繼承接口的!

創建一個數據接口層IDAL,結構如下:引用Models層

 為什麼寫這個接口呢?原因很簡單,就是將增刪改查等操作進行一個封裝,並且這不是普通的增刪改查,看代碼:

你可以把它看做是增刪改查的基礎接口,這個接口是一個泛型(比如你的商品表,用戶表等等…),它必須得基礎BaseEntity,並且這個T必須繼承與BaseEntity,也就是必須是BaseEntity的派生類。

關於IQueryable的好處註釋以寫!

這四個方法就是增刪改查,就算你有幾百張表,應該也只要寫一次增刪改查的操作就ok(也是來自菜鳥理解)

using System;
using System.Linq;
using Book.Models;

namespace IDAL
{
    //接口封裝增刪改查的方法它,是個泛型,並且要給一個約束,這個T必須是BaseEntity的派生類也就是子類,別的不行
    public interface IBaseService<T> where T:BaseEntity
    {
        void Add(T t);
        void Edit(T t);
        void Remove(Guid id);
        T GetOne(Guid id); //查詢某一個對象
        //IQueryable得到的是一個集合,它不會立刻給你去生成Sql語句,直到你需要拿到指定的某個結果后,再去給你生成Sql語句,比如根據條件,分頁,排序等操作獲得的集合數據
        IQueryable<T> GetAll();
    }
}

既然有了接口,那麼肯定是要實現這個接口才能調用裏面的增刪改查的四個方法吧!既然如此,那麼就再寫一個DAL類庫,去實現這個接口層。

結構如下:引用EF以及Models和IDAL層,並且寫一個BaseService類去實現IBaseService接口裡面的方法

BaseService代碼如下:

using IDAL;
using System;
using System.Linq;
using Book.Models;

namespace DAL
{
    public class BaseService<T> : IBaseService<T> where T:BaseEntity    //指明這個T是誰,就是繼承BaseEntity的類
    {
        public void Add(T t)
        {
            throw new NotImplementedException();
        }

        public void Edit(T t)
        {
            throw new NotImplementedException();
        }

        public IQueryable<T> GetAll()
        {
            throw new NotImplementedException();
        }

        public T GetOne(Guid id)
        {
            throw new NotImplementedException();
        }

        public void Remove(Guid id)
        {
            throw new NotImplementedException();
        }
    }
}

前面的 IBaseService<T>就是你實現的是哪個接口,後面的Where就是告訴這個接口要實現的T(泛型已經指定了是繼承BaseEntity的派生類)是誰。。。

可能這裏的Where作用還需要去理解一下,個人理解就是約束、條件之類的作用。

怎麼寫方法?代碼如下:

using IDAL;
using System;
using System.Data.Entity;
using System.Linq;
using Book.Models;

namespace DAL
{
    public class BaseService<T> : IBaseService<T> where T:BaseEntity,new()    //指明這個T是誰,就是繼承BaseEntity的類
    {
        private BookContext _db=new BookContext();
        public void Add(T t)
        {
            //db.Books.Add(t);
            _db.Set<T>().Add(t); //Set<>就是返回一個DbSet實例,為什麼是T ,作用就是動態的訪問,無論是Book還是BookTypes,你給我什麼我就用T接就好了
            _db.SaveChanges();
        }

        public void Edit(T t)
        {
            _db.Entry(t).State = EntityState.Modified;   //直接通過主題去作修改
            _db.SaveChanges();
        }

        public IQueryable<T> GetAll()
        {
            return _db.Set<T>().Where(m => !m.IsRemove).AsNoTracking(); //脫離持久態,變為遊離態,並且過濾掉了已被刪除的數據
        }

        public T GetOne(Guid id)
        {
            return GetAll().First(m => m.Id == id); //直接通過GetAll在通過id查到你想要的數據
        }

        public void Remove(Guid id)
        {
            var t=new T()
            {
                Id = id
            };  //這裡是偽刪除,T不能直接new,也是給個約束條件 new()即可,代表它有構造函數
            _db.Entry(t).State = EntityState.Unchanged; //也是根據狀態去刪除 
            t.IsRemove = true;
            _db.SaveChanges();
        }
    }
}

這些增刪改查方法寫完后,就要去繼承了。原理實際上和BaseEntity差不多

既然增刪改查的方法都寫好了,那麼怎麼去才能調用到它呢?這個時候為什麼還需要去寫IBook和IBookType呢?。首先我們在之前是寫了IBaseService這個接口並且寫了對應的增刪改查方法,但是具體的實現是在DAL層所有,這兩個接口只需要繼承對應的IBaseService就好了,具體實現也是在DAL層,至於DAL層怎麼去寫,請看下面的內容。

這個時候泛型 T就其作用了,我們可以去寫對應的接口繼承IBaseService就好了。。

 代碼如下:

IBookService:

namespace IDAL
{
    public interface IBook:IBaseService<Book.Models.Book>
    {
        
    }
}

IBookTypeService:

using Book.Models;

namespace IDAL
{
    public interface IBookTypeService:IBaseService<BookType>
    {
        
    }
}

DAL層結構:

為什麼還要繼承BaseService?首先BaseService具體實現了繼承IBaseService的方法,所以,我們只需要繼承一下就可以調用到BaseService的增刪改查的方法了!

BookService代碼:

using Book.Models;
using IDAL;

namespace DAL
{
    public class BookService:BaseService<Book.Models.Book>, IBookService
    {
        
    }
}

BookTypeService代碼:

using Book.Models;
using IDAL;

namespace DAL
{
    public class BookTypeService:BaseService<BookType>,IBookTypeService
    {
        
    }
}

以上操作完成后,我們只需要實例化DAL層的Service方法就可以調用在UI層增刪改查了。

寫到這裏只是最最基礎的底層,如果還要完善需要進一步的改善改善。。。

如果有錯誤的地方請提出來,本人也是學生,大家都是抱着學習的心態去記錄和鞏固自己的知識點。。。。。

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

【其他文章推薦】

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

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

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

※超省錢租車方案

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

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

※回頭車貨運收費標準

分類
發燒車訊

容器技術之Docker私有鏡像倉庫harbor

  前文我們聊到了docker的私有鏡像倉庫docker-distribution的搭建和簡單的使用,回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13058338.html;從前文的搭建和使用過程來看,docker-distribution搭建的倉庫非常簡陋,它甚至連一個用戶認證都沒有,更別提多用戶;今天我們來介紹另外一款docker倉庫工具harbor;harbor這款工具相對docker-distribution來講功能上豐富了許多;它支持多租戶,可擴展的API和web ui ,支持跨多個harbor實例的鏡像複製,支持身份集成和基於角色的訪問控制等等特徵;接下來我們來安裝看看harbor吧;

  首先我們要去官網下載安裝器,目前最新版本是2.0;下載地址https://github.com/goharbor/harbor/releases/tag/v2.0.0;harbor的安裝器有在線和離線兩個版本,在線包通常較小,適用於網絡環境較好地環境中使用,離線包是所有的安裝文件和腳本等等打包在一起的;

  1、上傳已經下載好的安裝器到服務器

  2、解壓安裝器,並進入到解壓后的目錄中

[root@docker_node01 ~]# tar xf harbor-offline-installer-v2.0.0.tgz -C /usr/local/
[root@docker_node01 ~]# ls /usr/local/
bin  etc  games  harbor  include  lib  lib64  libexec  sbin  share  src
[root@docker_node01 ~]# cd /usr/local/harbor/
[root@docker_node01 harbor]# ls
common.sh  harbor.v2.0.0.tar.gz  harbor.yml.tmpl  install.sh  LICENSE  prepare
[root@docker_node01 harbor]# 

  3、編輯harbor.yml.tmpl文件,更改必要的配置

  提示:以上我只修改了hostname的值,後面的我都是用默認值;有關這個配置文件的說明,可參考官方文檔說明去配置;這裏需要注意一點使用https需要自己手動的去申請證書,沒有證書文件harbor是不能夠正常安裝的;

  4、把harbor.yml.tmpl重命名為harbor.yml

[root@docker_node01 harbor]# ls
common.sh  harbor.v2.0.0.tar.gz  harbor.yml.tmpl  install.sh  LICENSE  prepare
[root@docker_node01 harbor]# mv harbor.yml.tmpl harbor.yml
[root@docker_node01 harbor]#

  5、運行install.sh

  提示:如果運行install.sh腳本出現以上錯誤,我們需要先安裝好docker-compose;

  6、安裝docker-compose

[root@docker_node01 harbor]# yum install docker-compose -y
Loaded plugins: fastestmirror
base                                                                                                                                                | 3.6 kB  00:00:00     
docker-ce-stable                                                                                                                                    | 3.5 kB  00:00:00     
epel                                                                                                                                                | 4.7 kB  00:00:00     
extras                                                                                                                                              | 2.9 kB  00:00:00     
updates                                                                                                                                             | 2.9 kB  00:00:00     
(1/3): updates/7/x86_64/primary_db                                                                                                                  | 2.1 MB  00:00:00     
(2/3): epel/x86_64/updateinfo                                                                                                                       | 1.0 MB  00:00:01     
(3/3): epel/x86_64/primary_db                                                                                                                       | 6.8 MB  00:00:03     
Loading mirror speeds from cached hostfile
 * base: mirrors.aliyun.com
 * extras: mirrors.aliyun.com
 * updates: mirror.bit.edu.cn
Resolving Dependencies
--> Running transaction check
---> Package docker-compose.noarch 0:1.18.0-4.el7 will be installed
--> Processing Dependency: python36-cached_property >= 1.2.0 for package: docker-compose-1.18.0-4.el7.noarch
--> Processing Dependency: python36-docker >= 2.6.1 for package: docker-compose-1.18.0-4.el7.noarch
……省略部分內容
Installed:
  docker-compose.noarch 0:1.18.0-4.el7                                                                                                                                     

Dependency Installed:
  python36-PyYAML.x86_64 0:3.13-1.el7                 python36-cached_property.noarch 0:1.5.1-2.el7             python36-chardet.noarch 0:3.0.4-1.el7                      
  python36-docker.noarch 0:2.6.1-3.el7                python36-docker-pycreds.noarch 0:0.2.1-2.el7              python36-dockerpty.noarch 0:0.4.1-18.el7                   
  python36-docopt.noarch 0:0.6.2-8.el7                python36-idna.noarch 0:2.7-2.el7                          python36-jsonschema.noarch 0:2.5.1-4.el7                   
  python36-pysocks.noarch 0:1.6.8-7.el7               python36-requests.noarch 0:2.14.2-2.el7                   python36-six.noarch 0:1.14.0-2.el7                         
  python36-texttable.noarch 0:1.6.2-1.el7             python36-urllib3.noarch 0:1.25.6-1.el7                    python36-websocket-client.noarch 0:0.47.0-2.el7            

Complete!
[root@docker_node01 harbor]# 

  提示:docker-compose是docker容器的單機編排工具;

  7、再運行install.sh腳本

[root@docker_node01 harbor]# ./install.sh 

[Step 0]: checking if docker is installed ...

Note: docker version: 19.03.8

[Step 1]: checking docker-compose is installed ...

Note: docker-compose version: 1.18.0

[Step 2]: loading Harbor images ...
dbaf2c918102: Loading layer [==================================================>]   34.5MB/34.5MB
1f3458bb7308: Loading layer [==================================================>]  8.435MB/8.435MB
74e91bd5ca15: Loading layer [==================================================>]  6.317MB/6.317MB
82da861dccd3: Loading layer [==================================================>]  14.61MB/14.61MB
8d62f2bfdf94: Loading layer [==================================================>]  28.25MB/28.25MB
40510e398799: Loading layer [==================================================>]  22.02kB/22.02kB
6941a908d292: Loading layer [==================================================>]  49.17MB/49.17MB
Loaded image: goharbor/notary-signer-photon:v2.0.0
bd70463b9e5a: Loading layer [==================================================>]  8.441MB/8.441MB
d3927e3c53ea: Loading layer [==================================================>]  3.584kB/3.584kB
a3b2acbb8f7d: Loading layer [==================================================>]  3.072kB/3.072kB
de14f7f144ce: Loading layer [==================================================>]   9.71MB/9.71MB
94c03f31b276: Loading layer [==================================================>]  10.53MB/10.53MB
Loaded image: goharbor/clair-adapter-photon:v2.0.0
935e17d700d1: Loading layer [==================================================>]   8.44MB/8.44MB
eef8d67e9248: Loading layer [==================================================>]   42.3MB/42.3MB
a181769f3c52: Loading layer [==================================================>]  3.072kB/3.072kB
4b801e4d76d7: Loading layer [==================================================>]  3.584kB/3.584kB
7f7c81a33722: Loading layer [==================================================>]  43.12MB/43.12MB
Loaded image: goharbor/chartmuseum-photon:v2.0.0
4076b322e7f5: Loading layer [==================================================>]  49.89MB/49.89MB
da16bbe3a170: Loading layer [==================================================>]  3.584kB/3.584kB
f8967a1d9155: Loading layer [==================================================>]  3.072kB/3.072kB
6b7eaf984fde: Loading layer [==================================================>]   2.56kB/2.56kB
4406aea83cb2: Loading layer [==================================================>]  3.072kB/3.072kB
78566a971bf2: Loading layer [==================================================>]  3.584kB/3.584kB
e4e05e2ffdad: Loading layer [==================================================>]  12.29kB/12.29kB
f3bcf1de026d: Loading layer [==================================================>]  5.632kB/5.632kB
Loaded image: goharbor/harbor-log:v2.0.0
101133a0a2e6: Loading layer [==================================================>]  8.441MB/8.441MB
40eb3ab360dd: Loading layer [==================================================>]  3.584kB/3.584kB
172ace267ace: Loading layer [==================================================>]  20.94MB/20.94MB
cb361129c579: Loading layer [==================================================>]  3.072kB/3.072kB
f0221c34f9dc: Loading layer [==================================================>]  8.721MB/8.721MB
1880cedc9407: Loading layer [==================================================>]  30.48MB/30.48MB
Loaded image: goharbor/harbor-registryctl:v2.0.0
15f399ca8b42: Loading layer [==================================================>]  8.441MB/8.441MB
182251d62618: Loading layer [==================================================>]  3.584kB/3.584kB
c72ce5e8bba9: Loading layer [==================================================>]  3.072kB/3.072kB
6cb620513867: Loading layer [==================================================>]  20.94MB/20.94MB
8f68617c13e6: Loading layer [==================================================>]  21.76MB/21.76MB
Loaded image: goharbor/registry-photon:v2.0.0
464d98f962d2: Loading layer [==================================================>]  115.2MB/115.2MB
6f577ce93b49: Loading layer [==================================================>]  12.15MB/12.15MB
468b747374fb: Loading layer [==================================================>]  3.072kB/3.072kB
c7d4e40274a2: Loading layer [==================================================>]  49.15kB/49.15kB
349c2528bf8f: Loading layer [==================================================>]  3.584kB/3.584kB
50765adb1994: Loading layer [==================================================>]  13.03MB/13.03MB
Loaded image: goharbor/clair-photon:v2.0.0
f3ae9281f64f: Loading layer [==================================================>]  16.04MB/16.04MB
79de921bba64: Loading layer [==================================================>]  28.25MB/28.25MB
a4826ccd0680: Loading layer [==================================================>]  22.02kB/22.02kB
527c0492bb8a: Loading layer [==================================================>]   50.6MB/50.6MB
Loaded image: goharbor/notary-server-photon:v2.0.0
da380ff7675f: Loading layer [==================================================>]  39.44MB/39.44MB
3e72063a3c12: Loading layer [==================================================>]  3.072kB/3.072kB
87063a362784: Loading layer [==================================================>]   59.9kB/59.9kB
12042912d563: Loading layer [==================================================>]  61.95kB/61.95kB
Loaded image: goharbor/redis-photon:v2.0.0
497d39fd8ed4: Loading layer [==================================================>]  10.28MB/10.28MB
Loaded image: goharbor/nginx-photon:v2.0.0
db89bcd4a7aa: Loading layer [==================================================>]  12.22MB/12.22MB
a3c69d8e6487: Loading layer [==================================================>]  3.072kB/3.072kB
22888c961e12: Loading layer [==================================================>]   2.56kB/2.56kB
15c04c0d67b3: Loading layer [==================================================>]   46.5MB/46.5MB
5e59e5738914: Loading layer [==================================================>]  5.632kB/5.632kB
2fb21742e876: Loading layer [==================================================>]   51.2kB/51.2kB
ebe005c22385: Loading layer [==================================================>]  47.32MB/47.32MB
e91a77a1cc5d: Loading layer [==================================================>]   2.56kB/2.56kB
Loaded image: goharbor/harbor-core:v2.0.0
c9ad3414e408: Loading layer [==================================================>]  63.57MB/63.57MB
0aea7ae12d77: Loading layer [==================================================>]  60.58MB/60.58MB
c3be2cda3349: Loading layer [==================================================>]  5.632kB/5.632kB
970c1e4372ae: Loading layer [==================================================>]  2.048kB/2.048kB
51e00ddbcdac: Loading layer [==================================================>]   2.56kB/2.56kB
27d44e884cd0: Loading layer [==================================================>]   2.56kB/2.56kB
3086c2ee0489: Loading layer [==================================================>]   2.56kB/2.56kB
efd18d9ef79c: Loading layer [==================================================>]  10.24kB/10.24kB
Loaded image: goharbor/harbor-db:v2.0.0
ad0a4ed99dd0: Loading layer [==================================================>]  12.22MB/12.22MB
50121125e459: Loading layer [==================================================>]  3.072kB/3.072kB
6d05b39a8c44: Loading layer [==================================================>]   2.56kB/2.56kB
5380ddc5210f: Loading layer [==================================================>]  35.68MB/35.68MB
e8053e60aee7: Loading layer [==================================================>]   36.5MB/36.5MB
Loaded image: goharbor/harbor-jobservice:v2.0.0
9fefe33a31db: Loading layer [==================================================>]  9.741MB/9.741MB
a52a9b417697: Loading layer [==================================================>]  3.584kB/3.584kB
9b6c54642038: Loading layer [==================================================>]  3.072kB/3.072kB
6a32c528face: Loading layer [==================================================>]  20.34MB/20.34MB
526552ecb5a3: Loading layer [==================================================>]  9.317MB/9.317MB
bc3e72205f25: Loading layer [==================================================>]  30.48MB/30.48MB
Loaded image: goharbor/trivy-adapter-photon:v2.0.0
51193d3ba093: Loading layer [==================================================>]  77.29MB/77.29MB
398b7c3413c0: Loading layer [==================================================>]  48.31MB/48.31MB
cb902b44bae6: Loading layer [==================================================>]   2.56kB/2.56kB
11d3bf655c22: Loading layer [==================================================>]  1.536kB/1.536kB
3d373d988076: Loading layer [==================================================>]  18.43kB/18.43kB
755d5115a4fd: Loading layer [==================================================>]  3.751MB/3.751MB
5d456b2e2b47: Loading layer [==================================================>]  249.3kB/249.3kB
Loaded image: goharbor/prepare:v2.0.0
2128feaae029: Loading layer [==================================================>]  10.28MB/10.28MB
c1e2c6faf4a4: Loading layer [==================================================>]  8.487MB/8.487MB
8728e424e45b: Loading layer [==================================================>]  178.7kB/178.7kB
243de4b81324: Loading layer [==================================================>]  157.2kB/157.2kB
1909dd7d54dc: Loading layer [==================================================>]  33.28kB/33.28kB
e91e103cac7d: Loading layer [==================================================>]  17.41kB/17.41kB
ef43ac036ce0: Loading layer [==================================================>]  15.36kB/15.36kB
3205feaa4e7b: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: goharbor/harbor-portal:v2.0.0


[Step 3]: preparing environment ...

[Step 4]: preparing harbor configs ...
prepare base dir is set to /usr/local/harbor
WARNING:root:WARNING: HTTP protocol is insecure. Harbor will deprecate http protocol in the future. Please make sure to upgrade to https
Clearing the configuration file: /config/log/logrotate.conf
Clearing the configuration file: /config/log/rsyslog_docker.conf
Clearing the configuration file: /config/nginx/nginx.conf
Clearing the configuration file: /config/core/env
Clearing the configuration file: /config/core/app.conf
Clearing the configuration file: /config/registry/passwd
Clearing the configuration file: /config/registry/config.yml
Clearing the configuration file: /config/registry/root.crt
Clearing the configuration file: /config/registryctl/env
Clearing the configuration file: /config/registryctl/config.yml
Clearing the configuration file: /config/db/env
Clearing the configuration file: /config/jobservice/env
Clearing the configuration file: /config/jobservice/config.yml
Generated configuration file: /config/log/logrotate.conf
Generated configuration file: /config/log/rsyslog_docker.conf
Generated configuration file: /config/nginx/nginx.conf
Generated configuration file: /config/core/env
Generated configuration file: /config/core/app.conf
Generated configuration file: /config/registry/config.yml
Generated configuration file: /config/registryctl/env
Generated configuration file: /config/registryctl/config.yml
Generated configuration file: /config/db/env
Generated configuration file: /config/jobservice/env
Creating harbor-log ... done
loaded secret from file: /data/secret/keys/secretkey
Generated configuration file: /compose_location/docker-compose.yml
Clean up the input dir

Creating harbor-db ... done
Creating harbor-core ... done
[Step 5]: starting Harbor ...
Creating nginx ... done
Creating registry ... 
Creating harbor-db ... 
Creating redis ... 
Creating harbor-portal ... 
Creating registryctl ... 
Creating harbor-core ... 
Creating harbor-jobservice ... 
Creating nginx ... 
 ----Harbor has been installed and started successfully.----
[root@docker_node01 harbor]# 

  提示:從上面的信息可以看到harbor導入了很多鏡像,然後基於各個鏡像間的關係提供配置文件,然後按照一定的依賴關係順序啟動為容器;我們用docker images 可以來看看它導入了那些鏡像

[root@docker_node01 harbor]# docker images
REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
goharbor/chartmuseum-photon     v2.0.0              4db8d6aa63e9        3 weeks ago         127MB
goharbor/redis-photon           v2.0.0              c89ea2e53cc0        3 weeks ago         72.2MB
goharbor/trivy-adapter-photon   v2.0.0              6122c52b7e48        3 weeks ago         103MB
goharbor/clair-adapter-photon   v2.0.0              dd2210cb7f53        3 weeks ago         62MB
goharbor/clair-photon           v2.0.0              f7c7fcc52278        3 weeks ago         171MB
goharbor/notary-server-photon   v2.0.0              983ac10ed8be        3 weeks ago         143MB
goharbor/notary-signer-photon   v2.0.0              bee1b6d75e0d        3 weeks ago         140MB
goharbor/harbor-registryctl     v2.0.0              c53c32d58d04        3 weeks ago         102MB
goharbor/registry-photon        v2.0.0              afdc1b7ada36        3 weeks ago         84.5MB
goharbor/nginx-photon           v2.0.0              17892f03e56c        3 weeks ago         43.6MB
goharbor/harbor-log             v2.0.0              5f8ff08e795c        3 weeks ago         82MB
goharbor/harbor-jobservice      v2.0.0              c68a2495bf55        3 weeks ago         116MB
goharbor/harbor-core            v2.0.0              3aa3af64baf8        3 weeks ago         138MB
goharbor/harbor-portal          v2.0.0              e0b1d3c894c4        3 weeks ago         52.4MB
goharbor/harbor-db              v2.0.0              5c76f0296cec        3 weeks ago         154MB
goharbor/prepare                v2.0.0              7266d49995ed        3 weeks ago         158MB
[root@docker_node01 harbor]# docker ps -a
CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS                   PORTS                       NAMES
909486114bab        goharbor/nginx-photon:v2.0.0         "nginx -g 'daemon of…"   2 minutes ago       Up 2 minutes (healthy)   0.0.0.0:80->8080/tcp        nginx
201af4781190        goharbor/harbor-jobservice:v2.0.0    "/harbor/entrypoint.…"   2 minutes ago       Up 2 minutes (healthy)                               harbor-jobservice
d926598a1b4b        goharbor/harbor-core:v2.0.0          "/harbor/entrypoint.…"   2 minutes ago       Up 2 minutes (healthy)                               harbor-core
b655e8bb9da3        goharbor/harbor-portal:v2.0.0        "nginx -g 'daemon of…"   2 minutes ago       Up 2 minutes (healthy)   8080/tcp                    harbor-portal
596d050acf8b        goharbor/registry-photon:v2.0.0      "/home/harbor/entryp…"   2 minutes ago       Up 2 minutes (healthy)   5000/tcp                    registry
88a6b3335d25        goharbor/harbor-registryctl:v2.0.0   "/home/harbor/start.…"   2 minutes ago       Up 2 minutes (healthy)                               registryctl
cf8db1840524        goharbor/harbor-db:v2.0.0            "/docker-entrypoint.…"   2 minutes ago       Up 2 minutes (healthy)   5432/tcp                    harbor-db
5d522f8f3c38        goharbor/redis-photon:v2.0.0         "redis-server /etc/r…"   2 minutes ago       Up 2 minutes (healthy)   6379/tcp                    redis
020fbf3571a2        goharbor/harbor-log:v2.0.0           "/bin/sh -c /usr/loc…"   2 minutes ago       Up 2 minutes (healthy)   127.0.0.1:1514->10514/tcp   harbor-log
[root@docker_node01 harbor]# 

  提示:可以看到本地倉庫中多了很多鏡像,同時也啟動了很多容器;其中名為nginx的容器把80端口暴露到數組機上了;到此harbor就安裝好了;接下來我們訪問宿主機的80端口看看是否能夠訪問到harbor

  提示:以上就是harbor的web 頁面,默認用戶名是admin密碼是Harbor12345

  登錄harbor web頁面

  提示:我們就可以基於這個web頁面來做管理了;接下來我們先創建一個用戶和項目,然後在通過docker push上傳鏡像到harbor上

  創建用戶

  提示:填寫好以上信息,點擊確定用戶就創建好了;

  創建項目

   提示:如果創建的項目是私有的,把訪問級別後面的公開對勾取消即可

  從別的docker主機上上傳鏡像到harbor

  提示:使用非https的倉庫必須要在daemon.json文件中配置insecure-registries來聲明不安全的鏡像倉庫地址;

  提示:這裏提示我們未授權;接下來我們去web管理頁面授權qiuhom是test項目的成員;

  提示:現在我們把qiuhom這個用戶設置為test這個項目的管理員,現在我們在以qiuhom的身份推鏡像到test項目中,看看是否能夠成功把進行推送到harbor上?

[root@docker_node02 ~]# docker push node01.docker-registry.io/test/nginx:1.14-alpine
The push refers to repository [node01.docker-registry.io/test/nginx]
076c58d2644f: Pushed 
b2cbae4b8c15: Pushed 
5ac9a5170bf2: Pushed 
a464c54f93a9: Pushed 
1.14-alpine: digest: sha256:a3a0c4126587884f8d3090efca87f5af075d7e7ac8308cffc09a5a082d5f4760 size: 1153
[root@docker_node02 ~]# 

  提示:這次推送鏡像沒有報錯,我們去web頁面中看看鏡像是否推送到test項目中去了?

  驗證:在harborweb界面看看是否有我們推上去的鏡像?

  用其他docker主機下載harbor上的鏡像

  提示:可以看到現在我們搭建的harbor是可以正常下載和上傳鏡像的;管理鏡像我們可以通過web頁面管理即可,我這裏就不去演示了;接下來我們再來說說在命令行用docker-compose啟動harbor和停止harbor吧

  停止harbor

  提示:用docker-compose停止harbor需要先進入到harbor目錄下,然後執行docker-compose stop 這條命令會去尋找docker-compose.yml文件,根據文件中定義的服務來停止容器;這個有點類似docker build命令,找Dockerfile文件,而docker-compose 是找docker-compose.yml;這裏還需要注意一點的是這個文件名必須是docker-compose.yml;

  啟動harbor

  提示:啟動huabor同停止harbor一樣都必須在docker-compose.yml文件所在目錄下執行docker-compose start 或docker-compose up -d ;

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

【其他文章推薦】

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

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

※超省錢租車方案

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

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

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

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

分類
發燒車訊

重學 Java 設計模式:實戰組合模式(營銷差異化人群發券,決策樹引擎搭建場景)

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

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

一、前言

小朋友才做選擇題,成年人我都要

頭幾年只要群里一問我該學哪個開發語言,哪個語言最好。群里肯定聊的特別火熱,有人支持PHP、有人喊號Java、也有C++和C#。但這幾年開始好像大家並不會真的刀槍棍棒、斧鉞鈎叉般討論了,大多數時候都是開玩笑的鬧一鬧。於此同時在整體的互聯網開發中很多時候是一些開發語言公用的,共同打造整體的生態圈。而大家選擇的方式也是更偏向於不同領域下選擇適合的架構,而不是一味地追求某個語言。這可以給很多初學編程的新人一些提議,不要刻意的覺得某個語言好,某個語言不好,只是在適合的場景下選擇最需要的。而你要選擇的那個語言可以參考招聘網站的需求量和薪資水平決定。

編程開發不是炫技

總會有人喜歡在整體的項目開發中用上點新特性,把自己新學的知識實踐試試。不能說這樣就是不好,甚至可以說這是一部分很熱愛學習的人,喜歡創新,喜歡實踐。但編程除了用上新特性外,還需要考慮整體的擴展性、可讀性、可維護、易擴展等方面的考慮。就像你家裡雇傭了一夥裝修師傅,有那麼一個小工喜歡炫技搞花活,在家的淋浴下安裝了馬桶。

即使是寫CRUD也應該有設計模式

往往很多大需求都是通過增刪改查堆出來的,今天要一個需求if一下,明天加個內容else擴展一下。日積月累需求也就越來越大,擴展和維護的成本也就越來越高。往往大部分研發是不具備產品思維和整體業務需求導向的,總以為寫好代碼完成功能即可。但這樣的不考慮擴展性的實現,很難讓後續的需求都快速迭代,久而久之就會被陷入惡性循環,每天都有bug要改。

二、開發環境

  1. JDK 1.8
  2. Idea + Maven
  3. 涉及工程三個,可以通過關注公眾號bugstack蟲洞棧,回復源碼下載獲取(打開獲取的鏈接,找到序號18)
工程 描述
itstack-demo-design-8-01 使用一坨代碼實現業務需求
itstack-demo-design-8-02 通過設計模式優化改造代碼,產生對比性從而學習

三、組合模式介紹

從上圖可以看到這有點像螺絲和螺母,通過一堆的鏈接組織出一棵結構樹。而這種通過把相似對象(也可以稱作是方法)組合成一組可被調用的結構樹對象的設計思路叫做組合模式。

這種設計方式可以讓你的服務組節點進行自由組合對外提供服務,例如你有三個原子校驗功能(A:身份證B:銀行卡C:手機號)服務並對外提供調用使用。有些調用方需要使用AB組合,有些調用方需要使用到CBA組合,還有一些可能只使用三者中的一個。那麼這個時候你就可以使用組合模式進行構建服務,對於不同類型的調用方配置不同的組織關係樹,而這個樹結構你可以配置到數據庫中也可以不斷的通過圖形界面來控制樹結構。

所以不同的設計模式用在恰當好處的場景可以讓代碼邏輯非常清晰並易於擴展,同時也可以減少團隊新增人員對項目的學習成本。

四、案例場景模擬

以上是一個非常簡化版的營銷規則決策樹,根據性別年齡來發放不同類型的優惠券,來刺激消費起到精準用戶促活的目的。

雖然一部分小夥伴可能並沒有開發過營銷場景,但你可能時時刻刻的被營銷着。比如你去經常瀏覽男性喜歡的机械鍵盤、筆記本電腦、汽車裝飾等等,那麼久給你推薦此類的優惠券刺激你消費。那麼如果你購物不多,或者錢不在自己手裡。那麼你是否打過車,有一段時間經常有小夥伴喊,為什麼同樣的距離他就10元,我就15元呢?其實這些都是被營銷的案例,一般對於不常使用軟件的小夥伴,經常會進行稍微大力度的促活,增加用戶粘性。

那麼在這裏我們就模擬一個類似的決策場景,體現出組合模式在其中起到的重要性。另外,組合模式不只是可以運用於規則決策樹,還可以做服務包裝將不同的接口進行組合配置,對外提供服務能力,減少開發成本。

五、用一坨坨代碼實現

這裏我們舉一個關於ifelse誕生的例子,介紹小姐姐與程序員‍‍之間的故事導致的事故

日期 需求 緊急程度 程序員(話外音)
星期一.早上 猿哥哥,老闆說要搞一下營銷拉拉量,給男生女生髮不同的優惠券,促活消費。 很緊急,下班就要 行吧,也不難,加下判斷就上線
星期二.下午 小哥哥,咱們上線后非常好。要讓咱們按照年輕、中年、成年,不同年齡加下判斷,準確刺激消費。 超緊急,明天就要 也不難,加就加吧
星期三.晚上 喂,小哥哥!睡了嗎!老闆說咱們這次活動很成功,可以不可以在細分下,把單身、結婚、有娃的都加上不同判斷。這樣更能刺激用戶消費。 賊緊急,最快上線。 已經意識到ifelse越來越多了
星期四.凌晨 哇!小哥哥你們太棒了,上的真快。嘻嘻!有個小請求,需要調整下年齡段,因為現在學生處對象的都比較早,有對象的更容易買某某某東西。要改下值!辛苦辛苦! 老闆,在等着呢! 一大片的值要修改,哎!這麼多ifelse
星期五.半夜 歪歪喂!巴巴,壞了,怎麼發的優惠券不對了,有客訴了,很多女生都來投訴。你快看看。老闆,他… (一頭汗),哎,值粘錯位置了! 終究還是一個人扛下了所有

1. 工程結構

itstack-demo-design-8-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── EngineController.java
  • 公司里要都是這樣的程序員絕對省下不少成本,根本不要搭建微服務,一個工程搞定所有業務!
  • 但千萬不要這麼干!酒肉穿腸過,佛祖心中留。世人若學我,如同進魔道。

2. 代碼實現

public class EngineController {

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

    public String process(final String userId, final String userSex, final int userAge) {

        logger.info("ifelse實現方式判斷用戶結果。userId:{} userSex:{} userAge:{}", userId, userSex, userAge);

        if ("man".equals(userSex)) {
            if (userAge < 25) {
                return "果實A";
            }

            if (userAge >= 25) {
                return "果實B";
            }
        }

        if ("woman".equals(userSex)) {
            if (userAge < 25) {
                return "果實C";
            }

            if (userAge >= 25) {
                return "果實D";
            }
        }

        return null;

    }

}
  • 除了我們說的擴展性和每次的維護以外,這樣的代碼實現起來是最快的。而且從樣子來看也很適合新人理解。
  • 但是我勸你別寫,寫這樣代碼不是被扣績效就是被開除。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_EngineController() {
    EngineController engineController = new EngineController();
    String process = engineController.process("Oli09pLkdjh", "man", 29);
    logger.info("測試結果:{}", process);
}
  • 這裏我們模擬了一個用戶ID,並傳輸性別:man、年齡:29,我們的預期結果是:果實B。實際對應業務就是給頭禿的程序員發一張枸杞優惠券

3.2 測試結果

22:10:12.891 [main] INFO  o.i.demo.design.EngineController - ifelse實現方式判斷用戶結果。userId:Oli09pLkdjh userSex:man userAge:29
22:10:12.898 [main] INFO  org.itstack.demo.design.test.ApiTest - 測試結果:果實B

Process finished with exit code 0
  • 從測試結果上看我們的程序運行正常並且符合預期,只不過實現上並不是我們推薦的。接下來我們會採用組合模式來優化這部分代碼。

六、組合模式重構代碼

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

接下來的重構部分代碼改動量相對來說會比較大一些,為了讓我們可以把不同類型的決策節點和最終的果實組裝成一棵可被運行的決策樹,需要做適配設計和工廠方法調用,具體會體現在定義接口以及抽象類和初始化配置決策節點(性別年齡)上。建議這部分代碼多閱讀幾次,最好實踐下。

1. 工程結構

itstack-demo-design-8-02
└── src
    ├── main
    │   └── java
    │      └── org.itstack.demo.design.domain
    │          ├── model
    │          │   ├── aggregates
    │          │   │   └── TreeRich.java
    │          │   └── vo
    │          │       ├── EngineResult.java
    │          │       ├── TreeNode.java
    │          │       ├── TreeNodeLink.java    
    │          │       └── TreeRoot.java	
    │          └── service
    │              ├── engine
    │              │   ├── impl	
    │              │   │   └── TreeEngineHandle.java	   
    │              │   ├── EngineBase.java 
    │              │   ├── EngineConfig.java       
    │              │   └── IEngine.java	
    │              └── logic
    │                  ├── impl	
    │                  │   ├── LogicFilter.java	 
    │                  │   └── LogicFilter.java	    
    │                  └── LogicFilter.java	
    └── test
         └── java
             └── org.itstack.demo.design.test
                 └── ApiTest.java

組合模式模型結構

  • 首先可以看下黑色框框的模擬指導樹結構;11112111112121122,這是一組樹結構的ID,並由節點串聯組合出一棵關係樹樹。

  • 接下來是類圖部分,左側是從LogicFilter開始定義適配的決策過濾器,BaseLogic是對接口的實現,提供最基本的通用方法。UserAgeFilterUserGenerFilter,是兩個具體的實現類用於判斷年齡性別

  • 最後則是對這顆可以被組織出來的決策樹,進行執行的引擎。同樣定義了引擎接口和基礎的配置,在配置裏面設定了需要的模式決策節點。

    • static {
           logicFilterMap = new ConcurrentHashMap<>();
           logicFilterMap.put("userAge", new UserAgeFilter());
           logicFilterMap.put("userGender", new UserGenderFilter());
      }
      
  • 接下來會對每一個類進行細緻的講解,如果感覺沒有讀懂一定是我作者的表述不夠清晰,可以添加我的微信(fustack)與我交流。

2. 代碼實現

2.1 基礎對象

包路徑 介紹
model.aggregates TreeRich 聚合對象,包含組織樹信息
model.vo EngineResult 決策返回對象信息
model.vo TreeNode 樹節點;子恭弘=叶 恭弘節點、果實節點
model.vo TreeNodeLink 樹節點鏈接鏈路
model.vo TreeRoot 樹根信息
  • 以上這部分簡單介紹,不包含邏輯只是各項必要屬性的get/set,整個源代碼可以通過關注微信公眾號:bugstack蟲洞棧,回復源碼下載打開鏈接獲取。

2.2 樹節點邏輯過濾器接口

public interface LogicFilter {

    /**
     * 邏輯決策器
     *
     * @param matterValue          決策值
     * @param treeNodeLineInfoList 決策節點
     * @return 下一個節點Id
     */
    Long filter(String matterValue, List<TreeNodeLink> treeNodeLineInfoList);

    /**
     * 獲取決策值
     *
     * @param decisionMatter 決策物料
     * @return 決策值
     */
    String matterValue(Long treeId, String userId, Map<String, String> decisionMatter);

}
  • 這一部分定義了適配的通用接口,邏輯決策器、獲取決策值,讓每一個提供決策能力的節點都必須實現此接口,保證統一性。

2.3 決策抽象類提供基礎服務

public abstract class BaseLogic implements LogicFilter {

    @Override
    public Long filter(String matterValue, List<TreeNodeLink> treeNodeLinkList) {
        for (TreeNodeLink nodeLine : treeNodeLinkList) {
            if (decisionLogic(matterValue, nodeLine)) return nodeLine.getNodeIdTo();
        }
        return 0L;
    }

    @Override
    public abstract String matterValue(Long treeId, String userId, Map<String, String> decisionMatter);

    private boolean decisionLogic(String matterValue, TreeNodeLink nodeLink) {
        switch (nodeLink.getRuleLimitType()) {
            case 1:
                return matterValue.equals(nodeLink.getRuleLimitValue());
            case 2:
                return Double.parseDouble(matterValue) > Double.parseDouble(nodeLink.getRuleLimitValue());
            case 3:
                return Double.parseDouble(matterValue) < Double.parseDouble(nodeLink.getRuleLimitValue());
            case 4:
                return Double.parseDouble(matterValue) <= Double.parseDouble(nodeLink.getRuleLimitValue());
            case 5:
                return Double.parseDouble(matterValue) >= Double.parseDouble(nodeLink.getRuleLimitValue());
            default:
                return false;
        }
    }

}
  • 在抽象方法中實現了接口方法,同時定義了基本的決策方法;1、2、3、4、5等於、小於、大於、小於等於、大於等於的判斷邏輯。
  • 同時定義了抽象方法,讓每一個實現接口的類都必須按照規則提供決策值,這個決策值用於做邏輯比對。

2.4 樹節點邏輯實現類

年齡節點

public class UserAgeFilter extends BaseLogic {

    @Override
    public String matterValue(Long treeId, String userId, Map<String, String> decisionMatter) {
        return decisionMatter.get("age");
    }

}

性別節點

public class UserGenderFilter extends BaseLogic {

    @Override
    public String matterValue(Long treeId, String userId, Map<String, String> decisionMatter) {
        return decisionMatter.get("gender");
    }

}
  • 以上兩個決策邏輯的節點獲取值的方式都非常簡單,只是獲取用戶的入參即可。實際的業務開發可以從數據庫、RPC接口、緩存運算等各種方式獲取。

2.5 決策引擎接口定義

public interface IEngine {

    EngineResult process(final Long treeId, final String userId, TreeRich treeRich, final Map<String, String> decisionMatter);

}
  • 對於使用方來說也同樣需要定義統一的接口操作,這樣的好處非常方便後續拓展出不同類型的決策引擎,也就是可以建造不同的決策工廠。

2.6 決策節點配置

public class EngineConfig {

    static Map<String, LogicFilter> logicFilterMap;

    static {
        logicFilterMap = new ConcurrentHashMap<>();
        logicFilterMap.put("userAge", new UserAgeFilter());
        logicFilterMap.put("userGender", new UserGenderFilter());
    }

    public Map<String, LogicFilter> getLogicFilterMap() {
        return logicFilterMap;
    }

    public void setLogicFilterMap(Map<String, LogicFilter> logicFilterMap) {
        this.logicFilterMap = logicFilterMap;
    }

}
  • 在這裏將可提供服務的決策節點配置到map結構中,對於這樣的map結構可以抽取到數據庫中,那麼就可以非常方便的管理。

2.7 基礎決策引擎功能

public abstract class EngineBase extends EngineConfig implements IEngine {

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

    @Override
    public abstract EngineResult process(Long treeId, String userId, TreeRich treeRich, Map<String, String> decisionMatter);

    protected TreeNode engineDecisionMaker(TreeRich treeRich, Long treeId, String userId, Map<String, String> decisionMatter) {
        TreeRoot treeRoot = treeRich.getTreeRoot();
        Map<Long, TreeNode> treeNodeMap = treeRich.getTreeNodeMap();
        // 規則樹根ID
        Long rootNodeId = treeRoot.getTreeRootNodeId();
        TreeNode treeNodeInfo = treeNodeMap.get(rootNodeId);
        //節點類型[NodeType];1子恭弘=叶 恭弘、2果實
        while (treeNodeInfo.getNodeType().equals(1)) {
            String ruleKey = treeNodeInfo.getRuleKey();
            LogicFilter logicFilter = logicFilterMap.get(ruleKey);
            String matterValue = logicFilter.matterValue(treeId, userId, decisionMatter);
            Long nextNode = logicFilter.filter(matterValue, treeNodeInfo.getTreeNodeLinkList());
            treeNodeInfo = treeNodeMap.get(nextNode);
            logger.info("決策樹引擎=>{} userId:{} treeId:{} treeNode:{} ruleKey:{} matterValue:{}", treeRoot.getTreeName(), userId, treeId, treeNodeInfo.getTreeNodeId(), ruleKey, matterValue);
        }
        return treeNodeInfo;
    }

}
  • 這裏主要提供決策樹流程的處理過程,有點像通過鏈路的關係(性別年齡)在二叉樹中尋找果實節點的過程。
  • 同時提供一個抽象方法,執行決策流程的方法供外部去做具體的實現。

2.8 決策引擎的實現

public class TreeEngineHandle extends EngineBase {

    @Override
    public EngineResult process(Long treeId, String userId, TreeRich treeRich, Map<String, String> decisionMatter) {
        // 決策流程
        TreeNode treeNode = engineDecisionMaker(treeRich, treeId, userId, decisionMatter);
        // 決策結果
        return new EngineResult(userId, treeId, treeNode.getTreeNodeId(), treeNode.getNodeValue());
    }

}
  • 這裏對於決策引擎的實現就非常簡單了,通過傳遞進來的必要信息;決策樹信息、決策物料值,來做具體的樹形結構決策。

3. 測試驗證

3.1 組裝樹關係

@Before
public void init() {
    // 節點:1
    TreeNode treeNode_01 = new TreeNode();
    treeNode_01.setTreeId(10001L);
    treeNode_01.setTreeNodeId(1L);
    treeNode_01.setNodeType(1);
    treeNode_01.setNodeValue(null);
    treeNode_01.setRuleKey("userGender");
    treeNode_01.setRuleDesc("用戶性別[男/女]");
    // 鏈接:1->11
    TreeNodeLink treeNodeLink_11 = new TreeNodeLink();
    treeNodeLink_11.setNodeIdFrom(1L);
    treeNodeLink_11.setNodeIdTo(11L);
    treeNodeLink_11.setRuleLimitType(1);
    treeNodeLink_11.setRuleLimitValue("man");
    // 鏈接:1->12
    TreeNodeLink treeNodeLink_12 = new TreeNodeLink();
    treeNodeLink_12.setNodeIdTo(1L);
    treeNodeLink_12.setNodeIdTo(12L);
    treeNodeLink_12.setRuleLimitType(1);
    treeNodeLink_12.setRuleLimitValue("woman");
    List<TreeNodeLink> treeNodeLinkList_1 = new ArrayList<>();
    treeNodeLinkList_1.add(treeNodeLink_11);
    treeNodeLinkList_1.add(treeNodeLink_12);
    treeNode_01.setTreeNodeLinkList(treeNodeLinkList_1);
    // 節點:11
    TreeNode treeNode_11 = new TreeNode();
    treeNode_11.setTreeId(10001L);
    treeNode_11.setTreeNodeId(11L);
    treeNode_11.setNodeType(1);
    treeNode_11.setNodeValue(null);
    treeNode_11.setRuleKey("userAge");
    treeNode_11.setRuleDesc("用戶年齡");
    // 鏈接:11->111
    TreeNodeLink treeNodeLink_111 = new TreeNodeLink();
    treeNodeLink_111.setNodeIdFrom(11L);
    treeNodeLink_111.setNodeIdTo(111L);
    treeNodeLink_111.setRuleLimitType(3);
    treeNodeLink_111.setRuleLimitValue("25");
    // 鏈接:11->112
    TreeNodeLink treeNodeLink_112 = new TreeNodeLink();
    treeNodeLink_112.setNodeIdFrom(11L);
    treeNodeLink_112.setNodeIdTo(112L);
    treeNodeLink_112.setRuleLimitType(5);
    treeNodeLink_112.setRuleLimitValue("25");
    List<TreeNodeLink> treeNodeLinkList_11 = new ArrayList<>();
    treeNodeLinkList_11.add(treeNodeLink_111);
    treeNodeLinkList_11.add(treeNodeLink_112);
    treeNode_11.setTreeNodeLinkList(treeNodeLinkList_11);
    // 節點:12
    TreeNode treeNode_12 = new TreeNode();
    treeNode_12.setTreeId(10001L);
    treeNode_12.setTreeNodeId(12L);
    treeNode_12.setNodeType(1);
    treeNode_12.setNodeValue(null);
    treeNode_12.setRuleKey("userAge");
    treeNode_12.setRuleDesc("用戶年齡");
    // 鏈接:12->121
    TreeNodeLink treeNodeLink_121 = new TreeNodeLink();
    treeNodeLink_121.setNodeIdFrom(12L);
    treeNodeLink_121.setNodeIdTo(121L);
    treeNodeLink_121.setRuleLimitType(3);
    treeNodeLink_121.setRuleLimitValue("25");
    // 鏈接:12->122
    TreeNodeLink treeNodeLink_122 = new TreeNodeLink();
    treeNodeLink_122.setNodeIdFrom(12L);
    treeNodeLink_122.setNodeIdTo(122L);
    treeNodeLink_122.setRuleLimitType(5);
    treeNodeLink_122.setRuleLimitValue("25");
    List<TreeNodeLink> treeNodeLinkList_12 = new ArrayList<>();
    treeNodeLinkList_12.add(treeNodeLink_121);
    treeNodeLinkList_12.add(treeNodeLink_122);
    treeNode_12.setTreeNodeLinkList(treeNodeLinkList_12);
    // 節點:111
    TreeNode treeNode_111 = new TreeNode();
    treeNode_111.setTreeId(10001L);
    treeNode_111.setTreeNodeId(111L);
    treeNode_111.setNodeType(2);
    treeNode_111.setNodeValue("果實A");
    // 節點:112
    TreeNode treeNode_112 = new TreeNode();
    treeNode_112.setTreeId(10001L);
    treeNode_112.setTreeNodeId(112L);
    treeNode_112.setNodeType(2);
    treeNode_112.setNodeValue("果實B");
    // 節點:121
    TreeNode treeNode_121 = new TreeNode();
    treeNode_121.setTreeId(10001L);
    treeNode_121.setTreeNodeId(121L);
    treeNode_121.setNodeType(2);
    treeNode_121.setNodeValue("果實C");
    // 節點:122
    TreeNode treeNode_122 = new TreeNode();
    treeNode_122.setTreeId(10001L);
    treeNode_122.setTreeNodeId(122L);
    treeNode_122.setNodeType(2);
    treeNode_122.setNodeValue("果實D");
    // 樹根
    TreeRoot treeRoot = new TreeRoot();
    treeRoot.setTreeId(10001L);
    treeRoot.setTreeRootNodeId(1L);
    treeRoot.setTreeName("規則決策樹");
    Map<Long, TreeNode> treeNodeMap = new HashMap<>();
    treeNodeMap.put(1L, treeNode_01);
    treeNodeMap.put(11L, treeNode_11);
    treeNodeMap.put(12L, treeNode_12);
    treeNodeMap.put(111L, treeNode_111);
    treeNodeMap.put(112L, treeNode_112);
    treeNodeMap.put(121L, treeNode_121);
    treeNodeMap.put(122L, treeNode_122);
    treeRich = new TreeRich(treeRoot, treeNodeMap);
}

  • 重要,這一部分是組合模式非常重要的使用,在我們已經建造好的決策樹關係下,可以創建出樹的各個節點,以及對節點間使用鏈路進行串聯。
  • 及時後續你需要做任何業務的擴展都可以在裏面添加相應的節點,並做動態化的配置。
  • 關於這部分手動組合的方式可以提取到數據庫中,那麼也就可以擴展到圖形界面的進行配置操作。

3.2 編寫測試類

@Test
public void test_tree() {
    logger.info("決策樹組合結構信息:\r\n" + JSON.toJSONString(treeRich));
    
    IEngine treeEngineHandle = new TreeEngineHandle();
    Map<String, String> decisionMatter = new HashMap<>();
    decisionMatter.put("gender", "man");
    decisionMatter.put("age", "29");
    
    EngineResult result = treeEngineHandle.process(10001L, "Oli09pLkdjh", treeRich, decisionMatter);
    
    logger.info("測試結果:{}", JSON.toJSONString(result));
}
  • 在這裏提供了調用的通過組織模式創建出來的流程決策樹,調用的時候傳入了決策樹的ID,那麼如果是業務開發中就可以方便的解耦決策樹與業務的綁定關係,按需傳入決策樹ID即可。
  • 此外入參我們還提供了需要處理;(man)、年齡(29歲),的參數信息。

3.3 測試結果

23:35:05.711 [main] INFO  o.i.d.d.d.service.engine.EngineBase - 決策樹引擎=>規則決策樹 userId:Oli09pLkdjh treeId:10001 treeNode:11 ruleKey:userGender matterValue:man
23:35:05.712 [main] INFO  o.i.d.d.d.service.engine.EngineBase - 決策樹引擎=>規則決策樹 userId:Oli09pLkdjh treeId:10001 treeNode:112 ruleKey:userAge matterValue:29
23:35:05.715 [main] INFO  org.itstack.demo.design.test.ApiTest - 測試結果:{"nodeId":112,"nodeValue":"果實B","success":true,"treeId":10001,"userId":"Oli09pLkdjh"}

Process finished with exit code 0
  • 從測試結果上看這與我們使用ifelse是一樣的,但是目前這與的組合模式設計下,就非常方便後續的拓展和修改。
  • 整體的組織關係框架以及調用決策流程已經搭建完成,如果閱讀到此沒有完全理解,可以下載代碼觀察結構並運行調試。

七、總結

  • 從以上的決策樹場景來看,組合模式的主要解決的是一系列簡單邏輯節點或者擴展的複雜邏輯節點在不同結構的組織下,對於外部的調用是仍然可以非常簡單的。
  • 這部分設計模式保證了開閉原則,無需更改模型結構你就可以提供新的邏輯節點的使用並配合組織出新的關係樹。但如果是一些功能差異化非常大的接口進行包裝就會變得比較困難,但也不是不能很好的處理,只不過需要做一些適配和特定化的開發。
  • 很多時候因為你的極致追求和稍有倔強的工匠精神,即使在面對同樣的業務需求,你能完成出最好的代碼結構和最易於擴展的技術架構。不要被遠不能給你指導提升能力的影響到放棄自己的追求!

八、推薦閱讀

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

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

※推薦台中搬家公司優質服務,可到府估價

分類
發燒車訊

.NET開發者省份分佈排名

 

什麼叫.NET開發者省份分佈排名呢? 顧名思義,這幾個詞大家都認識,.NET開發者都集中在城市,涵蓋一線城市到五線城市。排名的方法非常簡單粗暴,就是根據本公眾號(dotnet跨平台)的省份訂閱讀者數量排名的微信大數據分析。

本號從2015年初的三位數訂閱到現在五位數的訂閱,目前總數6.2w,增長一直平緩從未有過暴增,這显示了傳播和反饋的自主選擇,目前每天還在增長。同時我注意到一個現象:由於公眾號內容都是.NET Core相關的,對.NET 不感興趣的人,壓根就讀不下去。

從訂閱年齡看,高達99%的人落在18歲到60歲的區間且分佈正態,這正是我國勞動人口的年齡, 25歲以下只有20%,所以訂閱並不是以大學生為主,這也反映了現在高校中.NET 的教學比較少或者還是以.NET Framework的老舊內容;60歲以上極少,而所謂的“大專家”群體落在這個區間。

從地域分佈看,訂閱讀者分佈在300多個地級市,幾乎完整覆蓋全國。我的微信好友還不到5000個,遠遠達不到這個廣度,因此傳播是自發形成的。

排名中也提供了海外訂閱的比例。我們從中可以看到海外華人佔比3.22%,按人口比例還是很突出的,有大量的.NET開發到北美打拚,那邊的.NET環境要比國內好很多

這些數據都是藉助於微信的大數據,其實後台是根據註冊IP判斷地址的,會有少量遷移但不影響結果。這裏的6萬樣本相對於程序員群體來說,聚焦於.NET開發領域這個數據根據統計學原理,差異的顯著性已經足夠,具體我不展開了。

下面我們來看下主要省份排名:

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

【其他文章推薦】

※超省錢租車方案

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

※回頭車貨運收費標準

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

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

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

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

分類
發燒車訊

熬夜之作:一文帶你了解Cat分佈式監控

Cat 是什麼?

CAT(Central Application Tracking)是基於 Java 開發的實時應用監控平台,包括實時應用監控,業務監控。

CAT 作為服務端項目基礎組件,提供了 Java, C/C++, Node.js, Python, Go 等多語言客戶端,已經在美團點評的基礎架構中間件框架(MVC 框架,RPC 框架,數據庫框架,緩存框架等,消息隊列,配置系統等)深度集成,為美團點評各業務線提供系統豐富的性能指標、健康狀況、實時告警等。

CAT 很大的優勢是它是一個實時系統,CAT 大部分系統是分鐘級統計,但是從數據生成到服務端處理結束是秒級別,秒級定義是 48 分鐘 40 秒,基本上看到 48 分鐘 38 秒數據,整體報表的統計粒度是分鐘級;第二個優勢,監控數據是全量統計,客戶端預計算;鏈路數據是採樣計算。

Github: https://github.com/dianping/cat

Cat 功能亮點

  • 實時處理:信息的價值會隨時間銳減,尤其是事故處理過程中
  • 全量數據:全量採集指標數據,便於深度分析故障案例
  • 高可用:故障的還原與問題定位,需要高可用監控來支撐
  • 故障容忍:故障不影響業務正常運轉、對業務透明
  • 高吞吐:海量監控數據的收集,需要高吞吐能力做保證
  • 可擴展:支持分佈式、跨 IDC 部署,橫向擴展的監控系統

為什麼要用 Cat?

場景一:用戶反饋 App 無法下單,用戶反饋無法支付,用戶反饋商品無法搜索等問題

場景一的問題在於當系統出現問題后,第一反饋的總是用戶。我們需要做的是什麼,是在出問題后研發第一時間知曉,而不是讓用戶來告訴我們出問題了。

Cat 可以出故障后提供秒級別的異常告警機制,不用再等用戶來反饋問題了。

場景二:出故障后如何快速定位問題

一般傳統的方式當出現問題后,我們就會去服務器上看看服務是否還存活。如果存活就會看看日誌是否有異常信息。

在 Cat 後台的首頁,會展示各個系統的運行情況,如果有異常,則會大片飄紅,非常明顯。最直接的方式還是直接查看 Problem 報表,這裡會為我們展示直接的異常信息,快速定位問題。

場景三:用戶反饋訂單列表要 10 幾秒才展示,用戶反饋下單一直在轉圈圈

場景三屬於優化相關,對於研發來說,優化是一個長期的過程,沒有最好只有更好。優化除了需要有對應的方案,最重要的是要對症下藥。

所謂的對症下藥也就是在優化之前,你得先知道哪裡比較慢。RPC 調用慢?數據庫查詢慢?緩存更新慢?

Cat 可以提供詳細的性能數據,95 線,99 線等。更細粒度的就是可以看到某個請求或者某個業務方法的所有耗時邏輯,前提是你做了埋點操作。

Cat 報表

Cat 目前有五種報表,每種都有特定的應用場景,下面我們來具體聊聊這些報表的作用。

Transaction 報表

適用於監控一段代碼運行情況,比如:運行次數、QPS、錯誤次數、失敗率、響應時間統計(平均影響時間、Tp 分位值)等等場景。

埋點方式:

public void shopService() {
    Transaction transaction = Cat.newTransaction("ShopService", "Service");
    try {
        service();
        transaction.setStatus(Transaction.SUCCESS);
    } catch (Exception e) {
        transaction.setStatus(e); // catch 到異常,設置狀態,代表此請求失敗
        Cat.logError(e); // 將異常上報到cat上
        // 也可以選擇向上拋出: throw e;
    } finally {
        transaction.complete();
    }
}

可以在基礎框架中對 Rpc, 數據庫等框架進行埋點,這樣就可以通過 Cat 來監控這些組件了。

業務中需要埋點也可以使用 Cat 的 Transaction,比如下單,支付等核心功能,通常我們對 URL 進行埋點就可以了,也就包含了具體的業務流程。

Event 報表

適用於監控一段代碼運行次數,比如記錄程序中一個事件記錄了多少次,錯誤了多少次。Event 報表的整體結構與 Transaction 報表幾乎一樣,只缺少響應時間的統計。

埋點方式:

 Cat.logEvent("Func", "Func1");

Problem 報表

Problem 記錄整個項目在運行過程中出現的問題,包括一些異常、錯誤、訪問較長的行為。

如果有人反饋你的接口報 500 錯誤了,你進 Cat 后就直接可以去 Problem 報表了,錯誤信息就在 Problem 中。

Problem 報表不需要手動埋點,我們只需要在項目中集成日誌的 LogAppender 就可以將所有 error 異常記錄,下面的段落中會講解如何整合 LogAppender。

Heartbeat 報表

Heartbeat 報表是 CAT 客戶端,以一分鐘為周期,定期向服務端彙報當前運行時候的一些狀態。

系統指標有系統的負載信息,內存使用情況,磁盤使用情況等。

JVM 指標有 GC 相關信息,線程相關信息。

Business 報表

Business 報表對應着業務指標,比如訂單指標。與 Transaction、Event、Problem 不同,Business 更偏向於宏觀上的指標,另外三者偏向於微觀代碼的執行情況。

這個報表我也沒怎麼用過,用的多的還是前面幾個。

Cat 在 Kitty Cloud 中的應用

Kitty Cloud 的基礎組件是 Kitty,Kitty 裏面對需要的一些框架都進行了一層包裝,比如擴展,增加 Cat 埋點之類的功能。

Cat 的集成

Kitty 中對 Cat 封裝了一層,在使用的時候直接依賴 kitty-spring-cloud-starter-cat 即可整合 Cat 到項目中。

 <dependency>
       <groupId>com.cxytiandi</groupId>
       <artifactId>kitty-spring-cloud-starter-cat</artifactId>
       <version>Kitty Version</version>
 </dependency>

然後在 application 配置文件中配置 Cat 的服務端地址信息,多個英文逗號分隔:

cat.servers=47.105.66.210

在項目的 resources 目錄下創建 META-INF 目錄,然後在 META-INF 中創建 app.properties 文件配置 app.name。此名稱是在 Cat 後台显示的應用名

app.name=kitty-cloud-comment-provider

最後需要配置一下 Cat 的 LogAppender,這樣應用在記錄 error 級別的日誌時,Cat 可以及時進行異常告警操作。

在 logback.xml 增加下面的配置:

 <appender name="CatAppender" class="com.dianping.cat.logback.CatLogbackAppender"></appender>
 <root level="INFO">
     <appender-ref ref="CatAppender" />
 </root>

更詳細的內容請移步 Cat 的 Github 主頁進行查看。

MVC 框架埋點

基於 Spring Boot 做 Web 應用開發,我們最常用到的一個 Starter 包就是 spring-boot-starter-web。

如果你使用了 Kitty 來構建微服務的框架,那麼就不再需要直接依賴 spring-boot-starter-web。而是需要依賴 Kitty 中的 kitty-spring-cloud-starter-web。

kitty-spring-cloud-starter-web 在 spring-boot-starter-web 的基礎上進行了封裝,會對請求的 Url 進行 Cat 埋點,會對一些通用信息進行接收透傳,會對 RestTemplate 的調用進行 Cat 埋點。

在項目中依賴 kitty-spring-cloud-starter-web:

<dependency>
      <groupId>com.cxytiandi</groupId>
      <artifactId>kitty-spring-cloud-starter-web</artifactId>
      <version>Kitty Version</version>
</dependency>

啟動項目,然後訪問你的 REST API。可以在 Cat 的控制台看到 URL 的監控信息。

點擊 URL 進去可以看到具體的 URL 信息。

再進一步可以看到整個 URL 的信息,比如數據庫的查詢,緩存的操作,Http 的調用等。後端同學在優化性能的時候就直接從 URL 下手可以將整個請求的鏈路耗時的情況都分析清楚。

Mybatis 埋點

Kitty 中 Mybatis 是用的 Mybatis Plus, 主要是對數據庫相關操作的 SQL 進行了 Cat 埋點,可以很方便的查看 SQL 的耗時情況。

依賴 kitty-spring-cloud-starter-mybatis:

 <dependency>
     <groupId>com.cxytiandi</groupId>
     <artifactId>kitty-spring-cloud-starter-mybatis</artifactId>
     <version>Kitty Version</version>
 </dependency>

其他的使用方式還是跟 Mybatis Plus 一樣,具體參考 Mybatis Plus 文檔:https://mp.baomidou.com

只要涉及到數據庫的操作,都會在 Cat 中進行數據的展示。

點擊 SQL 進去還可以看到是哪個 Mapper 的操作。

再進一步就可以看到具體的 SQL 語句和消耗的時間。

有了這些數據,後端研發同學就可以對相關的 SQL 進行優化了。

Redis 埋點

如果需要使用 Spring Data Redis 的話,直接集成 kitty-spring-cloud-starter-redis 就可以,kitty-spring-cloud-starter-redis 中對 Redis 的命令進行了埋點,可以在 Cat 上直觀的查看對應的命令和消耗的時間。

添加對應的 Maven 依賴:

<dependency>
     <groupId>com.cxytiandi</groupId>
     <artifactId>kitty-spring-cloud-starter-redis</artifactId>
     <version>Kitty Version</version>
 </dependency>

直接使用 StringRedisTemplate:

@Autowired
private StringRedisTemplate stringRedisTemplate;
 
stringRedisTemplate.opsForValue().set("name", "yinjihuan");

Cat 中可以看到 Redis 信息。

點擊 Redis 進去可以看到有哪些命令。

再進去可以看到命令的詳細信息,比如操作的 key 和消耗的時間。

MongoDB 埋點

Kitty 中對 Spring Data Mongodb 做了封裝,只對 MongoTemplate 做了埋點。使用時需要依賴 kitty-spring-cloud-starter-mongodb。

<dependency>
    <groupId>com.cxytiandi</groupId>
    <artifactId>kitty-spring-cloud-starter-mongodb</artifactId>
    <version>Kitty Version</version>
</dependency>

在發生 Mongo 的操作后,Cat 上就可以看到相關的數據了。

點進去就可以看到是 MongoTemplate 的哪個方法發生了調用。

再進一步就可以看到具體的 Mongo 參數和消耗的時間。

還有 Dubbo, Feign,Jetcache,ElasticSearch 等框架的埋點就不細講了,感興趣的可以移步 Github 查看代碼。

Cat 使用小技巧

埋點工具類

如果要對業務方法進行監控,我們一般會用 Transaction 功能,將業務邏輯包含在 Transaction 裏面,就能監控這個業務的耗時信息。

埋點的方式也是通過 Cat.newTransaction 來進行,具體可以參考上面 Transaction 介紹時給出的埋點示列。

像這種埋點的方式最好是有一個統一的工具類去做,將埋點的細節封裝起來。

public class CatTransactionManager {
    public static <T> T newTransaction(Supplier<T> function, String type, String name, Map<String, Object> data) {
        Transaction transaction = Cat.newTransaction(type, name);
        if (data != null && !data.isEmpty()) {
            data.forEach(transaction::addData);
        }
        try {
            T result = function.get();
            transaction.setStatus(Message.SUCCESS);
            return result;
        } catch (Exception e) {
            Cat.logError(e);
            if (e.getMessage() != null) {
                Cat.logEvent(type + "_" + name + "_Error", e.getMessage());
            }
            transaction.setStatus(e);
            throw e;
        } finally {
            transaction.complete();
        }
    }
}

工具類使用:

public SearchResponse search(SearchRequest searchRequest, RequestOptions options) {
    Map<String, Object> catData = new HashMap<>(1);
    catData.put(ElasticSearchConstant.SEARCH_REQUEST, searchRequest.toString());
    return CatTransactionManager.newTransaction(() -> {
        try {
            return restHighLevelClient.search(searchRequest, options);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }, ElasticSearchConstant.ES_CAT_TYPE, ElasticSearchConstant.SEARCH, catData);
}

通過使用工具類,不再需要每個監控的地方都是設置 Transaction 是否 complete,是否成功這些信息了。

註解埋點

為了讓 Transaction 使用更方便,我們可以自定義註解來做這個事情。比如需要監控下單,支付等核心業務方法,那麼就可以使用自定義的 Transaction 註解加在方法上,然後通過 AOP 去統一做監控。

定義註解:

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface CatTransaction {
    /**
     * 類型, 默認為Method
     * @return
     */
    String type() default "";
    /**
     * 名稱, 默認為類名.方法名
     * @return
     */
    String name() default "";
    /**
     * 是否保存參數信息到Cat
     * @return
     */
    boolean isSaveParamToCat() default true;
}

定義切面:

@Aspect
public class CatTransactionAspect {
    @Around("@annotation(catTransaction)")
    public Object aroundAdvice(ProceedingJoinPoint joinpoint, CatTransaction catTransaction) throws Throwable {
        String type = catTransaction.type();
        if (StringUtils.isEmpty(type)){
            type = CatConstantsExt.METHOD;
        }
        String name = catTransaction.name();
        if (StringUtils.isEmpty(name)){
            name = joinpoint.getSignature().getDeclaringType().getSimpleName() + "." + joinpoint.getSignature().getName();
        }
        Map<String, Object> data = new HashMap<>(1);
        if (catTransaction.isSaveParamToCat()) {
            Object[] args = joinpoint.getArgs();
            if (args != null) {
                data.put("params", JsonUtils.toJson(args));
            }
        }
        return CatTransactionManager.newTransaction(() -> {
            try {
                return joinpoint.proceed();
            } catch (Throwable throwable) {
               throw new RuntimeException(throwable);
            }
        }, type, name, data);
    }

}

註解使用:

@CatTransaction
@Override
public Page<ArticleIndexBO> searchArticleIndex(ArticleIndexSearchParam param) {
}

你可能關心的幾個問題

Cat 能做鏈路跟蹤嗎?

Cat 主要是一個實時監控系統,並不是一個標準的全鏈路系統,主要是 Cat 的 logview 在異步線程等等一些場景下,不太合適,Cat 本身模型並不適合這個。Cat 的 Github 上有說明:在美團點評內部,有 mtrace 專門做全鏈路分析。

但是如果在 Mvc,遠程調用等這些框架中做好了數據的無縫傳輸,Cat 也可以充當一個鏈路跟蹤的系統,基本的場景足夠了。

Cat 也可以構建遠程消息樹,可以看到請求經過了哪些服務,每個服務的耗時等信息。只不過服務之間的依賴關係圖在 Cat 中沒有。

下圖請求從網關進行請求轉發到 articles 上面,然後 articles 裏面調用了 users 的接口。

Cat 跟 Skywalking 哪個好用?

Skywalking 也是一款非常優秀的 APM 框架,我還沒用過,不過看過一些文檔,功能點挺全的 ,界面也挺好看。最大的優勢是不用像 Cat 一樣需要埋點,使用字節碼增強的方式來對應用進行監控。

之所以列出這個小標題是因為如果大家還沒有用的話肯定會糾結要選擇落地哪個去做監控。我個人認為這兩個都可以,可以自己先弄個簡單的版本體驗體驗,結合你想要的功能點來評估落地哪個。

用 Cat 的話最好有一套基礎框架,在基礎框架中埋好點,這樣才能在 Cat 中詳細的显示各種信息來幫助我們快速定位問題和優化性能。

感興趣的 Star 下唄:https://github.com/yinjihuan/kitty-cloud

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

分類
發燒車訊

上位機開發之西門子PLC-S7通信實踐

 

寫在前面:

就目前而言,在中國的工控市場上,西門子仍然佔了很大的份額,因此對於上位機開發而言,經常會存在需要與西門子PLC進行通信的情況。然後對於西門子PLC來說,通信方式有很多,下面簡單列舉一下:

 

(1)  S7通信:PLC作為服務器,上位機作為客戶端

(2)  開放式TCP通信:PLC作為服務器,上位機作為客戶端

(3)  開放式TCP通信:PLC作為客戶端,上位機作為服務器

(4)   ModbusTCP通信:PLC作為服務器,上位機作為客戶端

(5)   ModbusTCP通信:PLC作為客戶端,上位機作為服務器

(6)   ModbusRTU通信:PLC作為主站,上位機作為從站

(7)   ModbusRTU通信:PLC作為從站,上位機作為主站

(8)   Simatic Net OPCDA通信

(9)   Simatic Net OPCUA通信

(10) KepServer OPCDA通信

(11) KepServer OPCUA通信

由於篇幅有限,這次僅以西門子S7通信為例,說明下如何基於S7通信協議實現與西門子PLC之間的通信。

 

1. PLC軟件安裝及配置

目前西門子PLC主要使用的軟件包括STEP7-MicroWIN SMART、SIMATIC STEP7以及TIA Portal。TIA Portal已經完全兼容STEP 7,因此以後應該是STEP 7-MicroWIN SMART作為小型PLC的編程軟件,TIA作為中大型PLC的編程軟件,這裏主要以博途為例進行說明:

如果大家需要軟件的,可以關注左上方公眾號,或者搜索微信公眾號:dotNet工控上位機,關注后發送關鍵詞:200SMART編程軟件即可獲取STEP 7-MicroWIN SMART V2.5軟件,發送關鍵詞:博圖V15即可獲取TIA V15.1編程軟件。

軟件安裝完成后,PLC的配置也很簡單,如果大家手頭沒有實際的PLC,也可以通過仿真的方式搭建PLC環境,具體可以參考文章:戳↓

基於S7-PLCSIM Advanced搭建S7通信仿真環境

 

無論使用何種方式,以下兩個地方需要進行配置一下:

PLC配置一:需要將PLC的允許來自遠程對象的PUT/GET通信訪問勾選。

PLC配置二:對於DB塊的訪問,需要取消勾選優化訪問。

 

2. 通信平台測試

(1)完成以上配置后,就可以通過自己開發的喜科堂通信測試平台軟件進行測試,導航欄中選擇西門子PLC,然後輸入正確的IP地址,在CPU類型中選擇自己的CPU類型:

圖表 1新閣通信測試平台

 

(1)輸入完成之後,點擊建立連接,建立連接之後,日誌欄會有連接成功提示。

(2)在讀寫測試中,輸入相應的變量地址及變量類型,即可實現相關變量的通信讀寫及測試。

圖表 2新閣通信測試平台測試

 

3. 項目級別應用

通信測試平台僅僅只是用於測試通信是否正常,實現正常的單變量數據讀取和寫入。但是如果是項目級別開發,還需要有一套更完善的通信架構,這裏我採用的是自主開發的上位機通信配置一體化軟件(簡稱CMS配置軟件)。

(1)通過PLC設備右擊選擇西門子PLC,在打開的窗體中設置好相關參數:

設備名稱:根據實際情況填寫(無特殊字符即可)

設備備註:根據實際情況填寫(無特殊字符即可)

IP地址:根據實際PLC的IP地址填寫

機架號、插槽號:根據實際PLC的情況填寫

PLC類型:根據實際PLC的情況填寫

連接超時:PLC連接時的超時時間,默認是2000ms

容錯次數:判斷連接故障的容錯次數,默認為1,即表示某次讀取出錯,即判斷連接故障,根據實際情況可以適當放大

重連周期:通信過程中,出現斷線時,重連的周期,默認是5000ms

圖表 3創建PLC

 

(2)在PLC設備下,右擊添加通信組,根據需要填寫相應的存儲區及起始地址及長度:

圖表 4添加通信組

 

(3)通信組下面,根據實際情況配置相應的變量,輸入開始地址及變量類型即可,變量地址會自動變換,這裏可以輸入比例係數及偏移量,用於做線性變換使用:

圖表 5添加變量

 

(4)對於變量配置,左下角會有一個報警歸檔配置,主要用於配置該變量的報警類型、歸檔方式及設定限制:

圖表 6報警歸檔配置

 

(5)完成上述配置后,可以點擊保存配置,再點擊啟動運行,即可實現實時通信:

圖表 7實時通信

 

(6)同時可以通過另存為,存儲為一個配置文件的形式,再基於配置dll,可以通過快速方式實現配置解析及通信數據解析,這樣整個項目的通信框架即可搭建完成。

 

4. 整體總結

本文主要針對西門子PLC的通信配置、通信配置及項目應用做了較為詳細的描述,希望可以給一些想要去開發西門子PLC項目的同學一些幫助。這樣的一套思路同樣適用於其他品牌的PLC,我們旨在節約大家開發項目中在通信方面的時間,而將更多的精力投放在項目工藝開發中。

 

寫在後面:

很多小夥伴想要CMSPro軟件來進行學習,因此綜合考慮,現提供CMSPro軟件試用版供大家學習使用,試用版功能方面可能會存在部分刪減,但是可以滿足大部分小夥伴的學習需求,目前僅針對本公眾號粉絲,具體獲取方式,通過關注本公眾號:dotNet工控上位機,發送關鍵詞:CMSPro試用,即可獲取。同時我們的通信庫xktComm.dll也提供試用版,大家可以通過nuget搜索xktComm,安裝使用,最後祝大家工作生活愉快。

 

更多精彩內容:

(點擊即可閱讀)

西門子PLC上位機軟件開發歷程

上位機C#通過TCP/IP和庫卡機器人通訊

上位機C#通過OPCUA和西門子PLC通信

基於C#實現本地數據上傳至雲服務器

上位機開發之三菱Q系列PLC通信實踐

 

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

【其他文章推薦】

※回頭車貨運收費標準

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

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

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

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!