十萬同時在線用戶,需要多少內存?——Newbe.Claptrap 框架水平擴展實驗

Newbe.Claptrap 項目是筆者正在構建以反應式、Actor模式和事件溯源為理論基礎的一套服務端開發框架。本篇我們將來了解一下框架在水平擴展方面的能力。

前情提要

時隔許久,今日我們再次見面。首先介紹一下過往的項目情況:

第一次接觸本框架的讀者,可以先點擊此處閱讀本框架相關的基礎理論和工作原理。

日前,我們也編寫了一些預熱文章和工具,讀者可以通過以下鏈接進行了解:

  • 談反應式編程在服務端中的應用,數據庫操作優化,從 20 秒到 0.5 秒
  • docker-mcr 助您全速下載 dotnet 鏡像
  • Newbe.Claptrap 項目周報 1 – 還沒輪影,先用輪跑

今日主題

今天,我們來做一套實驗預演,來驗證 Newbe.Claptrap 框架,如何通過水平擴展的形式來適應逐漸增長的同時在線用戶數。

由於此次實驗涉及的內容很多,因此筆者將內容進行了歸類,讀者可以按照自己的興趣閱讀相關的章節:

  • 業務需求說明
  • 調用時序關係
  • 物理結構設計
  • 實際測試數據
  • 源碼構建說明
  • 常見問題解答

業務需求說明

先看看今天要實現的業務場景:

  • 用戶通過 API 登錄後生成一個 JWT token
  • 用戶調用 API 時驗證 JWT token 的有效性
  • 沒有使用常規的 JWS 公私鑰方式進行 JWT token 頒發,而是為每個用戶單獨使用 secret 進行哈希驗證
  • 驗證看不同的在線用戶需要消耗的內存情況
  • 用戶登錄到生成 token 所消耗時間不得超過 200 ms
  • tokn 的驗證耗時不得超過 10 ms

吹牛先打草稿

筆者沒有搜索到於 “在線用戶數” 直接相關的理論定義,因此,為了避免各位的理解存在差異。筆者先按照自己的理解來點明:在線用戶數到底意味着什麼樣的技術要求?

未在線用戶若上線,不應該受到已在線用戶數的影響

如果一個用戶登錄上線需要消耗 100 ms。那麼不論當前在線的用戶數是十人還是百萬人。這個登錄上線所消耗的時間都不會明顯的超過 100 ms。

當然,有限的物理硬件肯定會使得,當在線用戶數超過一個閾值(例如兩百萬)時,新用戶登錄上線會變慢甚至出錯。

但是,增加物理機器就能提高這個閾值,我們就可以認為水平擴展設計是成功的。

對於任意一個已在線用戶,得到的系統性能反饋應當相同

例如已在線的用戶查詢自己的訂單詳情,需要消耗 100 ms。那麼當前任何一個用戶進行訂單查詢的平均消耗都應該穩定在 100 ms。

當然,這裏需要排除類似於 “搶購” 這種高集中性能問題。此處主要還是討論日常穩定的容量增加。(我們以後會另外討論 “搶購” 這種問題)

具體一點可以這樣理解。假設我們做的是一個雲筆記產品。

那麼,如果增加物理機器就能增加同時使用雲筆記產品的用戶數,而且不犧牲任何一個用戶的性能體驗,我們就認為水平擴展設計是成功的。

在此次的實驗中,若用戶已經登錄,則驗證 JWT 有效性的時長大約為 0.5 ms。

調用時序關係

簡要說明:

  1. 客戶端發起登錄請求將會逐層傳達到 UserGrain 中
  2. UserGrain 將會在內部激活一個 Claptrap 來進行維持 UserGrain 中的狀態數據。包括用戶名、密碼和用於 JWT 簽名的 Secret。
  3. 隨後的生成 JWT 生成和驗證都將直接使用 UserGrain 中的數據。由於 UserGrain 中的數據是在一段時間內是 “緩存” 在內存中的。所以之後的 JWT 生成和驗證將非常快速。實測約為 0.5 ms。

物理結構設計

如上圖所示,便是此次進行測試的物理組件:

名稱 說明
WebAPI 公開給外部調用 WebAPI 接口。提供登錄和驗證 token 的接口。
Orleans Cluster 託管 Grain 的核心進程.
Orleans Gateway 於 Orleans Cluster 基本相同,但是 WebAPI 只能與 Gateway 進行通信
Orleans Dashboard 於 Orleans Gateway 基本相同,但增加了 Dashboard 的展示,以查看整個 Orleans 集群的情況
Consul 用於 Orleans 集群的集群發現和維護
Claptrap DB 用於保存 Newbe.Claptrap 框架的事件和狀態數據
Influx DB & Grafana 用於監控 Newbe.Claptrap 相關的性能指標數據

此次實驗的 Orleans 集群節點的數量實際上是 Cluster + Gateway + Dashboard 的總數。以上的劃分實際上是由於功能設定的不同而進行的區分。

此次測試 “水平擴展” 特性的物理節點主要是 Orleans Cluster 和 Orleans Gateway 兩個部分。將會分別測試以下這些情況的內存使用情況。

Orleans Dashboard Orleans Gateway Orleans Cluster
1 0 0
1 1 1
1 3 5

此次實驗採用的是 Windows Docker Desktop 結合 WSL 2 進行的部署測試。

以上的物理結構實際上是按照最為此次實驗最為複雜的情況設計的。實際上,如果業務場景足夠簡單,該物理結構可以進行裁剪。詳細可以查看下文 “常見問題解答” 中的說明。

實際測試數據

以下,分別對不同的集群規模和用戶數量進行測試

0 Gateway 0 Cluster

默認情況下,剛剛啟動 Dashboard 節點時,通過 portainer 可以查看 container 佔用的內存約為 200 MB 左右,如下圖所示:

通過測試控制台,向 WebAPI 發出 30,000 次請求。每批 100 個請求,分批發送。

經過約兩分鐘的等待后,再次查看內存情況,約為 9.2 GB,如下圖所示:

因此,我們簡單的估算每個在線用戶需要消耗的內存情況約為 (9.2*1024-200)/30000 = 0.3 MB。

另外,可以查看一些輔助數據:

CPU 使用情況

網絡吞吐量

Orleans Dashboard 情況。左上角的 TOTAL ACTIVATIONS 中 30,000 即表示當前內存中存在的 UserGrain 數量,另外的 3 個為 Dashboard 使用的 Grain。

Grafana 中查看 Newbe.Claptrap 的事件平均處理時長約為 100-600 ms。此次測試的主要是內存情況,處理時長的採集時間為 30s 一次,因此樣本數並不多。關於處理時長我們將在後續的文章中進行詳細測試。

Grafana 中查看 Newbe.Claptrap 的事件的保存花費的平均時長約為 50-200 ms。事件的保存時長是事件處理的主要部分。

Grafana 中查看 Newbe.Claptrap 的事件已處理總數。一種登錄了三萬次,因此事件總數也是三萬。

1 Gateway 1 Cluster

接下來,我們測試額外增加兩個節點進行測試。

還是再提一下,Orleans 集群節點的數量實際上是 Cluster + Gateway + Dashboard 的總數。因此,對比上一個測試,該測試的節點數為 3。

測試得到的內存使用情況如下:

用戶數 節點平均內存 內存總佔用
10000 1.8 GB 1.8*3 = 5.4 GB
20000 3.3 GB 3.3*3 = 9.9 GB
30000 4.9 GB 4.9*3 = 14.7 GB

那麼,以三萬用戶為例,平均每個用戶佔用的內存約為 (14.7*1024-200*3)/30000 = 0.48 MB

為什麼節點數增加了,平均消耗內存上升了呢?筆者推測,沒有進行過驗證:節點增加,實際上節點之間的通訊還需要消耗額外的內存,因此平均來說有所增加。

3 Gateway 5 Cluster

我們再次增加節點。總結點數為 1 (dashboard) + 3 (cluster) + 5 (gateway) = 9 節點

測試得到的內存使用情況如下:

用戶數 節點平均內存 內存總佔用
20000 1.6 GB 3.3*9 = 14.4 GB
30000 2 GB 4.9*9 = 18 GB

那麼,以三萬用戶為例,平均每個用戶佔用的內存約為 (18*1024-200*9)/30000 = 0.55 MB

十萬用戶究竟要多少內存?

以上所有的測試都是以三萬為用戶數進行的測試,這是一個特殊的数字。因為繼續增加用戶數的話,內存將會超出測試機的內存余量。(求贊助兩條 16G)

如果繼續增加用戶數,將會開始使用操作系統的虛擬內存。雖然可以運行,但是運行效率會降低。原來登錄可能只需要 100 ms。使用到虛擬內存的用戶則需要 2 s。

因此,速度降低的情況下,在驗證需要多少內存意義可能不大。

但是,這不意味着不能夠繼續登錄,以下便是 1+1+1 的情況下,十萬用戶全部登錄后的情況。(有十萬用戶同時在線,加點內存吧,不差錢了。)

源碼構建說明

此次測試的代碼均可以在文末的樣例代碼庫中找到。為了方便讀者自行實驗,主要採用的是 docker-compose 進行構建和部署。

因此對於測試機的唯一環境需求就是要正確的安裝好 Docker Desktop 。

可以從以下任一地址獲取最新的樣例代碼:

  • https://github.com/newbe36524/Newbe.Claptrap.Examples
  • https://gitee.com/yks/Newbe.Claptrap.Examples

快速啟動

使用控制台進入 src/Newbe.Claptrap.Auth/LocalCluster 文件夾。運行以下命令便可以在本地啟動所有的組件:

1
docker-compose up -d

途中需要拉取一些託管於 Dockerhub 上的公共鏡像,請確保本地已經正確配置了相關的加速器,以便您可以快速構建。可以參看這篇文檔進行設置

成功啟動之後可以通過 docker ps 查看到所有的組件。

1
2
3
4
5
6
7
8
9
10
11
12
13
PS>docker ps
CONTAINER ID        IMAGE                                                                            COMMAND                  CREATED             STATUS              PORTS                                                                                                                              NAMES
66470e5393e2        registry.cn-hangzhou.aliyuncs.com/newbe36524/newbe-claptrap-auth-webapi          "dotnet Newbe.Claptr…"   4 hours ago         Up About an hour    0.0.0.0:10080->80/tcp                                                                                                              localcluster_webapi_1
3bbaf5538ab9        registry.cn-hangzhou.aliyuncs.com/newbe36524/newbe-claptrap-auth-backendserver   "dotnet Newbe.Claptr…"   4 hours ago         Up About an hour    80/tcp, 443/tcp, 0.0.0.0:19000->9000/tcp, 0.0.0.0:32785->11111/tcp, 0.0.0.0:32784->30000/tcp                                       localcluster_dashboard_1
3f60f51e4641        registry.cn-hangzhou.aliyuncs.com/newbe36524/newbe-claptrap-auth-backendserver   "dotnet Newbe.Claptr…"   4 hours ago         Up About an hour    80/tcp, 443/tcp, 9000/tcp, 0.0.0.0:32787->11111/tcp, 0.0.0.0:32786->30000/tcp                                                      localcluster_cluster_gateway_1
7d516ada2b26        registry.cn-hangzhou.aliyuncs.com/newbe36524/newbe-claptrap-auth-backendserver   "dotnet Newbe.Claptr…"   4 hours ago         Up About an hour    80/tcp, 443/tcp, 9000/tcp, 30000/tcp, 0.0.0.0:32788->11111/tcp                                                                     localcluster_cluster_core_1
fc89fcd973f9        grafana/grafana                                                                  "/run.sh"                4 hours ago         Up 6 seconds        0.0.0.0:23000->3000/tcp                                                                                                            localcluster_grafana_1
1f10ed0eb25f        postgres                                                                         "docker-entrypoint.s…"   4 hours ago         Up About an hour    0.0.0.0:32772->5432/tcp                                                                                                            localcluster_claptrap_db_1
d5d2bec74311        adminer                                                                          "entrypoint.sh docke…"   4 hours ago         Up About an hour    0.0.0.0:58080->8080/tcp                                                                                                            localcluster_adminer_1
4c4be69f2f41        bitnami/consul                                                                   "/opt/bitnami/script…"   4 hours ago         Up About an hour    8300-8301/tcp, 8500/tcp, 8301/udp, 8600/tcp, 8600/udp                                                                              localcluster_consulnode3_1
88811d3aa0d2        influxdb                                                                         "/entrypoint.sh infl…"   4 hours ago         Up 6 seconds        0.0.0.0:29086->8086/tcp                                                                                                            localcluster_influxdb_1
d31c73b62a47        bitnami/consul                                                                   "/opt/bitnami/script…"   4 hours ago         Up About an hour    8300-8301/tcp, 8500/tcp, 8301/udp, 8600/tcp, 8600/udp                                                                              localcluster_consulnode2_1
72d4273eba2c        bitnami/consul                                                                   "/opt/bitnami/script…"   4 hours ago         Up About an hour    0.0.0.0:8300-8301->8300-8301/tcp, 0.0.0.0:8500->8500/tcp, 0.0.0.0:8301->8301/udp, 0.0.0.0:8600->8600/tcp, 0.0.0.0:8600->8600/udp   localcluster_consulnode1_1

啟動完成之後,便可以通過以下鏈接來查看相關的界面

地址 說明
http://localhost:19000 Orleans Dashboard 查看 Orleans 集群中各節點的狀態
http://localhost:10080 Web API 基地址,此次使用所測試的 API 基地址
http://localhost:23000 Grafana 地址,查看 Newbe.Claptrap 相關的性能指標情況

源碼構建

使用控制台進入 src/Newbe.Claptrap.Auth 文件夾。運行以下命令便可以在本地完成代碼的構建:

1
2
./LocalCluster/pullimage.cmd
docker-compose build

pullimage.cmd 使用了筆者編寫的 docker-mcr 加速器功能。您可以通過該文檔來了解其工作原理

等待構建完畢之後,本地便生成好了相關的鏡像。接下來便可以初次嘗試在本地啟動應用:

使用控制台進入 src/Newbe.Claptrap.Auth/LocalCluster 文件夾。運行以下命令便可以啟動相關的容器:

1
docker-compose up -d

常見問題解答

文中為何沒有說明代碼和配置的細節?

本文主要為讀者展示該方案的實驗可行性,具體應該如何應用 Newbe.Claptrap 框架編寫代碼,並非本文的主旨,因此沒有提及。

當然,另外一點就是目前框架沒有最終定版,所有內容都有可能發生變化,講解代碼細節意義不大。

但可以提前說明的是:編寫非常簡單,由於本樣例的業務需求非常簡單,因此代碼內容也不多。全部都可以在示例倉庫中找到。

用 Redis 存儲 Token 也可以實現上面的需求,為什麼要選擇這個框架?

目前來說,筆者沒有十足的理由說服讀者必須使用哪種方案,此處也只是提供一種可行方案,至於實際應該選擇哪種方案,應該有讀者自己來考量,畢竟工具是否趁手還是需要試試才知道。

如果是最多 100 個在線用戶,那怎麼裁剪系統?

必要的組件只有 Orleans Dashboard 、 WebAPI 和 Claptrap Db。其他的組件全部都是非必要的。而且如果修改代碼, Orleans Dashboard 和 WebAPI 是可以合併的。

所以最小規模就是一個進程加一個數據庫。

Grafana 為什麼沒有報表?

Grafana 首次啟動之後需要手動的創建 DataSource 和導入 Dashboard.

本實驗相關的參數如下:

DataSource

  • URL: http://influxdb:8086
  • Database: metricsdatabase
  • User: claptrap
  • Password: claptrap

點擊此處獲取 Dashboard 定義文件

測試機的物理配置是什麼?

沒有專門騰內存,未開始測試前已佔用 16GB 內存。以下是測試機的身材數據(洋垃圾,3500 元左右):

處理器 英特爾 Xeon (至強) E5-2678 v3 @ 2.50GHz 12 核 24 線程
主板 HUANANZHI X99-AD3 GAMING (Wellsburg)
顯卡 Nvidia GeForce GTX 750 Ti (2 GB / Nvidia)
內存 32 GB (三星 DDR3L 1600MHz) 2013 年產 高齡內存
主硬盤 金士頓 SA400S37240G (240 GB / 固態硬盤)

如果您有更好的物理配置,相信可以得出更加優秀的數據。

即使是 0.3 MB 平均每用戶的佔用的我也覺得太高了

框架還在優化。未來會更好。

最後但是最重要!

最近作者正在構建以反應式、Actor模式和事件溯源為理論基礎的一套服務端開發框架。希望為開發者提供能夠便於開發出 “分佈式”、“可水平擴展”、“可測試性高” 的應用系統 ——Newbe.Claptrap

本篇文章是該框架的一篇技術選文,屬於技術構成的一部分。如果讀者對該內容感興趣,歡迎轉發、評論、收藏文章以及項目。您的支持是促進項目成功的關鍵。

GitHub 項目地址:https://github.com/newbe36524/Newbe.Claptrap

Gitee 項目地址:https://gitee.com/yks/Newbe.Claptrap

如果你對該項目感興趣,你可以通過 github issues 提交您的看法。

如果您無法正常訪問 github issue,您也可以發送郵件到 newbe-claptrap@googlegroups.com 來參与我們的討論。

點擊鏈接 QQ 交流【Newbe.Claptrap】:https://jq.qq.com/?_wv=1027&k=5uJGXf5。

​​​​​​​

    • 本文作者: newbe36524
    • 本文鏈接: https://www.newbe.pro/Newbe.Claptrap/How-Many-RAMs-In-Used-While-There-Are-One-Hundred-Thousand-Users-Online/
    • 版權聲明: 本博客所有文章除特別聲明外,均採用 BY-NC-SA 許可協議。轉載請註明出處!

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

【其他文章推薦】

※超省錢租車方案

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

※回頭車貨運收費標準

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

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

最通俗易懂的RSA加密解密指導

前言

RSA加密算法是一種非對稱加密算法,簡單來說,就是加密時使用一個鑰匙,解密時使用另一個鑰匙。

因為加密的鑰匙是公開的,所又稱公鑰,解密的鑰匙是不公開的,所以稱為私鑰。

密鑰

關於RSA加密有很多文章,但幾乎都只介紹了RSACryptoServiceProvider類的使用方法,如果只是走走看看,是沒問題的,但真的想使用時,就會發現,你沒有密鑰字符串。。。

下面我們從獲取密鑰字符串開始逐步學習加密。

密鑰字符串

每個安裝過VisualStudio的電腦都可以找到一個文件—makecert.exe。

我電腦的makecert.exe地址:C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert.exe

makecert.exe是用來生成證書的程序,我們可以借用該程序來獲取密鑰字符串。

 

編寫生成證書的CreateCertWithPrivateKey函數,代碼如下:

 public static bool CreateCertWithPrivateKey(string subjectName, string makecertPath)
 {
     subjectName = "CN=" + subjectName;
     string param = " -pe -ss my -n \"" + subjectName + "\" ";
     try
     {
         Process p = Process.Start(makecertPath, param);
         p.WaitForExit();
         p.Close();
     }
     catch (Exception e)
     { 
         return false;
     }
     return true;
 }

調用證書生成函數,代碼如下:

string keyName = "Kiba518.Licence";//證書的KEY 
var ret = DataCertificate.CreateCertWithPrivateKey(keyName, @"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\makecert.exe");

剛剛生成的證書還存儲在WINDOWS的證書存儲區,現在我們通過證書的Key在證書存儲區查找到證書,並將其到出(導出時需要指定密碼),導出函數代碼如下:

public static bool ExportToPfxFile(string subjectName, string pfxFileName,
    string password, bool isDelFromStore)
{
    subjectName = "CN=" + subjectName;
    X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
    store.Open(OpenFlags.ReadWrite);
    X509Certificate2Collection storecollection = (X509Certificate2Collection)store.Certificates;
    foreach (X509Certificate2 x509 in storecollection)
    {
        if (x509.Subject == subjectName)
        { 
            byte[] pfxByte = x509.Export(X509ContentType.Pfx, password);
            using (FileStream fileStream = new FileStream(pfxFileName, FileMode.Create))
            {
                // Write the data to the file, byte by byte. 
                for (int i = 0; i < pfxByte.Length; i++)
                    fileStream.WriteByte(pfxByte[i]);
                // Set the stream position to the beginning of the file. 
                fileStream.Seek(0, SeekOrigin.Begin);
                // Read and verify the data. 
                for (int i = 0; i < fileStream.Length; i++)
                {
                    if (pfxByte[i] != fileStream.ReadByte())
                    { 
                        fileStream.Close();
                        return false;
                    }
                }
                fileStream.Close();
            }
            if (isDelFromStore == true)
                store.Remove(x509);
        }
    }
    store.Close();
    store = null;
    storecollection = null;
    return true;
}

調用導出函數,代碼如下:

DataCertificate.ExportToPfxFile(keyName, "Kiba518.pfx", "123456", true);

運行完導出函數后,我們打開Debug文件夾,可以看到證書已經被成功導出了,如下圖:

證書導出后,我們就可以通過讀取證書的信息,來獲取到公鑰和私鑰了。

X509Certificate2 x509 = X509Certificate2("Kiba518.pfx", "123456", X509KeyStorageFlags.Exportable);
string publickey = x509.PublicKey.Key.ToXmlString(false);//公鑰獲取
string privatekey = x509.PrivateKey.ToXmlString(true);//私鑰獲取

公鑰私鑰如下圖所示:

加密解密

得到密鑰字符串后,我們創建RSA的加密解密函數,代碼如下:

//加密
public static string RSADecrypt(string xmlPrivateKey, string enptStr)
{
    RSACryptoServiceProvider provider = new RSACryptoServiceProvider();
    provider.FromXmlString(xmlPrivateKey);
    byte[] rgb = Convert.FromBase64String(enptStr);
    byte[] bytes = provider.Decrypt(rgb, RSAEncryptionPadding.OaepSHA1);
    return new UnicodeEncoding().GetString(bytes);
}
//解密
public static string RSAEncrypt(string xmlPublicKey, string enptStr)
{
    RSACryptoServiceProvider provider = new RSACryptoServiceProvider();
    provider.FromXmlString(xmlPublicKey);
    byte[] bytes = new UnicodeEncoding().GetBytes(enptStr);
    return Convert.ToBase64String(provider.Encrypt(bytes, RSAEncryptionPadding.OaepSHA1));
}

然後我們測試一下加密解密,測試函數如下。

public static void RsaTest()
{
    string myname = "my name is Kiba518!";
    Console.WriteLine($"內容:{myname}");
    string enStr = RSAEncrypt(publicKey, myname);
    Console.WriteLine($"加密字符串:{enStr}");
    string deStr = RSADecrypt(privateKey, enStr);
    Console.WriteLine($"解密字符串:{enStr}");
}

運行結果,加密解密成功,如下圖所示:

長字符分段加密

Rsa加密有字節數限制,即待加密的字符串太長,系統就會拋出異常:【System.Security.Cryptography.CryptographicException:“不正確的長度】

Rsa加密具體限制內容如下:

待加密的字節數不能超過密鑰的長度值除以 8 再減去 11(即:RSACryptoServiceProvider.KeySize / 8 – 11),而加密后得到密文的字節數,正好是密鑰的長度值除以 8(即:RSACryptoServiceProvider.KeySize / 8)。

分段加密

為解決長字符加密的異常,我們採取分段加密的方法進行字符串加密,代碼如下:

//加密
public static String SubRSAEncrypt(string xmlPublicKey, string enptStr)
{ 
    RSACryptoServiceProvider provider = new RSACryptoServiceProvider();
    provider.FromXmlString(xmlPublicKey);
    Byte[] bytes = Encoder.GetBytes(enptStr);
    int MaxBlockSize = provider.KeySize / 8 - 11;    //加密塊最大長度限制
​
    if (bytes.Length <= MaxBlockSize)
        return Convert.ToBase64String(provider.Encrypt(bytes, false));
​
    using (MemoryStream PlaiStream = new MemoryStream(bytes))
    using (MemoryStream CrypStream = new MemoryStream())
    {
        Byte[] Buffer = new Byte[MaxBlockSize];
        int BlockSize = PlaiStream.Read(Buffer, 0, MaxBlockSize);
​
        while (BlockSize > 0)
        {
            Byte[] ToEncrypt = new Byte[BlockSize];
            Array.Copy(Buffer, 0, ToEncrypt, 0, BlockSize);
​
            Byte[] Cryptograph = provider.Encrypt(ToEncrypt, false);
            CrypStream.Write(Cryptograph, 0, Cryptograph.Length);
​
            BlockSize = PlaiStream.Read(Buffer, 0, MaxBlockSize);
        }
​
        return Convert.ToBase64String(CrypStream.ToArray(), Base64FormattingOptions.None);
    } 
}
//解密
public static String SubRSADecrypt(string xmlPublicKey, string enptStr)
{ 
    RSACryptoServiceProvider provider = new RSACryptoServiceProvider();
    provider.FromXmlString(xmlPublicKey);
    Byte[] bytes = Convert.FromBase64String(enptStr);
    int MaxBlockSize = provider.KeySize / 8;    //解密塊最大長度限制
​
    if (bytes.Length <= MaxBlockSize)
        return Encoder.GetString(provider.Decrypt(bytes, false));
​
    using (MemoryStream CrypStream = new MemoryStream(bytes))
    using (MemoryStream PlaiStream = new MemoryStream())
    {
        Byte[] Buffer = new Byte[MaxBlockSize];
        int BlockSize = CrypStream.Read(Buffer, 0, MaxBlockSize);
​
        while (BlockSize > 0)
        {
            Byte[] ToDecrypt = new Byte[BlockSize];
            Array.Copy(Buffer, 0, ToDecrypt, 0, BlockSize); 
            Byte[] Plaintext = provider.Decrypt(ToDecrypt, false);
            PlaiStream.Write(Plaintext, 0, Plaintext.Length); 
            BlockSize = CrypStream.Read(Buffer, 0, MaxBlockSize);
        } 
        return Encoder.GetString(PlaiStream.ToArray());
    }
}  

編寫分段加密測試函數如下:

public static void SubRsaTest()
{
    string myname = "my name is Kiba518!my name is Kiba518!my name is Kiba518!my name is Kiba518!my name is Kiba518!my name is Kiba518!my name is Kiba518!";
    Console.WriteLine($"內容:{myname}");
    string enStr = SubRSAEncrypt(publicKey, myname);
    Console.WriteLine($"加密字符串:{enStr}");
    string deStr = SubRSADecrypt(privateKey, enStr);
    Console.WriteLine($"解密字符串:{deStr}");
}

運行結果,加密解密成功,如下圖:

關於證書

文中創建的證書—Kiba518.pfx,就是https所使用的證書,換言之,https的證書就是個Rsa加密解密文件。

當然正式的可以在互聯網中被各大網站認可的證書,是需要權威機構認證的,這個機構叫做CA,這個機構頒發的證書是.crt後綴名;而我們的pfx後綴名的證書,學名叫做個人信息交換證書。

其實它們沒有什麼區別,就是套的殼子不一樣,crt證書的殼子里多一些屬性,比如認證機構,有效期等等。但兩個證書的核心內容是一樣的,都是Rsa加密解密文件。

下面我們簡單了解下證書的導入。

導入證書

在運行窗口(window+r)輸入mmc打開microsoft管理控制台。

然後操作文件 -> 添加/刪除管理單元,選擇可用的管理單元中的證書點擊添加。

添加完管理單元,在右側控制台根節點會增加一個證書的根節點,如下圖:

然後,我們展開節點,找到【個人—證書】節點,然後【右鍵—所有任務—導入】。

然後按嚮導提示導入證書。

需要注意的是瀏覽導入證書的對話框,默認導入的是crt類型,我們需要點擊下拉菜單,選擇人信息交換選項,如下圖。

—————————————————————————————————-

到此Rsa加密解密的基本使用已經介紹完了。

代碼已經傳到Github上了,歡迎大家下載。

Github地址:https://github.com/kiba518/RsaDemo

—————————————————————————————————-

注:此文章為原創,任何形式的轉載都請聯繫作者獲得授權並註明出處!
若您覺得這篇文章還不錯,請點擊下方的【推薦】,非常感謝!

https://www.cnblogs.com/kiba/p/13141981.html

 

 

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

【其他文章推薦】

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

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

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

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

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

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

一起玩轉微服務(9)——前後端分離

前後端分離

在傳統的web應用開發中,大多數的程序員會將瀏覽器作為前後端的分界線。將瀏覽器中為用戶進行頁面展示的部分稱之為前端,而將運行在服務器,為前端提供業務邏輯和數據準備的所有代碼統稱為後端。 由於前後端分離這個概念相對來說剛出現不久,很多人都是只聞其聲,不見其形,所以可能會對它產生一些誤解,誤以為前後端分離只是一種web應用開發模式,只要在web應用的開發期進行了前後端開發工作的分工就是前後端分離。 其實前後端分離並不只是開發模式,而是web應用的一種架構模式。在開發階段,前後端工程師約定好數據交互接口,實現并行開發和測試;在運行階段前後端分離模式需要對web應用進行分離部署,前後端之前使用HTTP或者其他協議進行交互請求。 前後端分離原則,簡單來講就是前端和後端的代碼分離也就是技術上做分離。推薦的模式是最好直接採用物理分離的方式部署,進一步促使進行更徹底的分離。不要繼續以前的服務端模板技術,比如JSP ,把Java JS HTML CSS 都堆到一個頁面里,稍複雜的頁面就無法維護。

好處

這種分離模式的方式有幾個好處:

•前後端技術分離,可以由各自的專家來對各自的領域進行優化,這樣前端的用戶體驗優化效果會更好。•分離模式下,前後端交互界面更加清晰,就剩下了接口和模型,後端的接口簡潔明了,更容易維護。•前端多渠道集成場景更容易實現,後端服務無需變更,採用統一的數據和模型,可以支撐前端的web UI\ 移動App等訪問。

前後端分離意味着,前後端之間使用 JSON 來交流,兩個開發團隊之間使用 API 作為契約進行交互。從此,後台選用的技術棧不影響前台。 前後端分離並非僅僅只是前後端開發的分工,而是在開發期進行代碼存放分離、前後端開發職責分離,前後端能夠獨立進行開發測試;在運行期進行應用部署分離,前後端之間通過HTTP請求進行通訊。前後端分離的開發模式與傳統模式相比,能為我們提升開發效率、增強代碼可維護性,讓我們有規劃地打造一個前後端並重的精益開發團隊,更好地應對越來越複雜多變的Web應用開發需求。 前後端分離的核心:後台提供數據,前端負責显示。

常見的前端

AngularJS

Angular JS (Angular.JS) 是一組用來開發 Web 頁面的框架、模板以及數據綁定和豐富 UI 組件。它支持整個開發進程,提供 Web 應用的架構,無需進行手工 DOM 操作。 AngularJS 很小,只有 60K,兼容主流瀏覽器,與 jQuery 配合良好。

數據綁定可能是 AngularJS 最酷最實用的特性。它能夠幫助你避免書寫大量的初始代碼從而節約開發時間。一個典型的 Web 應用可能包含了 80% 的代碼用來處理,查詢和監聽 DOM。數據綁定使得代碼更少,你可以專註於你的應用。

傳統來說,當 Model 變化了。 開發人員需要手動處理 DOM 元素並且將屬性反映到這些變化中。這個一個雙向的過程。一方面,Model 變化驅動了 DOM 中元素變化,另一方面,DOM 元素的變化也會影響到 Model。這個在用戶互動中更加複雜,因為開發人員需要處理和解析這些互動,然後融合到一個 Model 中,並且更新 View。這是一個手動的複雜過程,當一個應用非常龐大的時候,將會是一件非常費勁的事情。

特性二:模板

在 AngularJS 中,一個模板就是一個 HTML 文件。但是 HTML 的內容擴展了,包含了很多幫助你映射 Model 到 View 的內容。

HTML 模板將會被瀏覽器解析到 DOM 中。DOM 然後成為 AngularJS 編譯器的輸入。AngularJS 將會遍歷 DOM 模板來生成一些指導,即,directive(指令)。所有的指令都負責針對 View 來設置數據綁定。

我們要理解 AuguarJS 並不把模板當做 String 來操作。輸入 AngularJS 的是 DOM 而非 string。數據綁定是 DOM 變化,不是字符串的連接或者 innerHTML 變化。使用 DOM 作為輸入,而不是字符串,是 AngularJS 區別於其它的框架的最大原因。使用 DOM 允許你擴展指令詞彙並且可以創建你自己的指令,甚至開發可重用的組件。

特性三:MVC

針對客戶端應用開發 AngularJS 吸收了傳統的 MVC 基本原則。MVC 或者 Model-View-Controll 設計模式針對不同的人可能意味不同的東西。AngularJS 並不執行傳統意義上的 MVC,更接近於 MVVM(Model-View-ViewModel)。

特性四:依賴注入(Dependency Injection,即 DI)

AngularJS 擁有內建的依賴注入子系統,可以幫助開發人員更容易的開發,理解和測試應用。

DI 允許你請求你的依賴,而不是自己找尋它們。比如,我們需要一個東西,DI 負責找創建並且提供給我們。

特性五:Directives(指令)

指令是我個人最喜歡的特性。你是不是也希望瀏覽器可以做點兒有意思的事情?那麼 AngularJS 可以做到。
指令可以用來創建自定義的標籤。它們可以用來裝飾元素或者操作 DOM 屬性。

2. React

React 是一個用於構建用戶界面的 JAVASCRIPT 庫。
React 主要用於構建UI,很多人認為 React 是 MVC 中的 V(視圖)。
React 起源於 Facebook 的內部項目,用來架設 Instagram 的網站,並於 2013 年 5 月開源。
React 擁有較高的性能,代碼邏輯非常簡單,越來越多的人已開始關注和使用它。
使用 React 可以將一些簡短、獨立的代碼片段組合成複雜的 UI 界面,這些代碼片段被稱作“組件”。

React特點

  1. 聲明式設計 −React採用聲明範式,可以輕鬆描述應用。

  2. 高效 −React通過對DOM的模擬,最大限度地減少與DOM的交互。

  3. 靈活 −React可以與已知的庫或框架很好地配合。

  4. JSX − JSX 是 JavaScript 語法的擴展。React 開發不一定使用 JSX ,但我們建議使用它。

  5. 組件 − 通過 React 構建組件,使得代碼更加容易得到復用,能夠很好的應用在大項目的開發中。

  6. 單向響應的數據流 − React 實現了單向響應的數據流,從而減少了重複代碼,這也是它為什麼比傳統數據綁定更簡單。

Vue.js

Vue.js(讀音 /vjuː/, 類似於 view) 是一套構建用戶界面的漸進式框架。

Vue 只關注視圖層, 採用自底向上增量開發的設計。

Vue 的目標是通過盡可能簡單的 API 實現響應的數據綁定和組合的視圖組件。

 

 

Kotlin

Kotlin 是一種在 Java 虛擬機上運行的靜態類型編程語言,被稱之為 Android 世界的Swift,由 JetBrains 設計開發並開源。

Kotlin 可以編譯成Java字節碼,也可以編譯成 JavaScript,方便在沒有 JVM 的設備上運行。

在Google I/O 2017中,Google 宣布 Kotlin 成為 Android 官方開發語言。

 

5. Flutter

 

Flutter 由 Google 的工程師團隊打造,用於創建高性能、跨平台的移動應用。Flutter 針對當下以及未來的移動設備進行優化,專註於 Android and iOS 低延遲的輸入和高幀率。

Flutter 可以給開發者提供簡單、高效的方式來構建和部署跨平台、高性能移動應用;給用戶提供漂亮、快速、jitter-free 的 app 體驗。

Flutter 的主要組件:

  • 一個高度優化, mobile-first 2D 渲染引擎 (保護對 text 優秀的支持 )

  • 一個 functional-reactive 框架 (可選的,你也可以引入你自己的框架)

  • 一組 Material Design 部件 (可選的,你也可以引入你自己的部件)庫 ,工具,和一個用於 Atom 的插件。

6. .Net

.NET是 Microsoft XML Web services 平台。XML Web services 允許應用程序通過 Internet 進行通訊和共享數據,而不管所採用的是哪種操作系統、設備或編程語言。Microsoft .NET 平台提供創建 XML Web services 並將這些服務集成在一起之所需。對個人用戶的好處是無縫的、吸引人的體驗。

這個不用說了,很大一部分人一直在用,而且作為master語言。但是對於微服務程序,感覺更適合於前端應用或者一些輕量級企業級的開發。

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

【其他文章推薦】

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

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

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

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

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

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

Spring Boot入門系列(十五)Spring Boot 開發環境熱部署

在實際的項目開發過中,當我們修改了某個java類文件時,需要手動重新編譯、然後重新啟動程序的,整個過程比較麻煩,特別是項目啟動慢的時候,更是影響開發效率。其實Spring Boot的項目碰到這種情況,同樣也同樣需要經歷重新編譯、重新啟動程序的過程。 只不過 Spring Boot 提供了一個spring-boot-devtools的模塊,使得 Spring Boot應用支持熱部署,無需手動重啟Spring Boot應用,,提高開發者的開發效率。接下來,聊一聊Spring Boot 開發環境熱部署。

 

一、原理

devtools 使用了兩個類加載器(ClassLoader),一個是 Base類加載器(base classloader ):加載那些不會改變的類,如:第三方Jar包等,而另一個是 Restart類加載器(restart classloader):負責加載那些正在開發的會改變的類。這樣在有代碼更改的時候,因為重啟的時候只是加載了在開發的Class類,沒有重新加載第三方的jar包,所以實現了較快的重啟時間。

devtools 監聽classpath下的文件變動(發生在保存時機),並且會立即重啟應用。從而實現類文件和屬性文件的熱部署。

 

二、快速配置

1、pom配置

引入devtools的依賴

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <!-- optional=true, 依賴不會傳遞, 該項目依賴devtools;之後依賴boot項目的項目如果想要使用devtools, 需要重新引入 -->
    <optional>true</optional>
</dependency>

注意:optional=true, 依賴不會傳遞, 該項目依賴devtools;之後依賴boot項目的項目如果想要使用devtools, 需要重新引入。

 

2、application.properties配置

在application.properties中配置devtools。

# 關閉緩存即時刷新
#spring.thymeleaf.cache=false

#熱部署生效
spring.devtools.restart.enabled=true
#設置重啟的目錄
spring.devtools.restart.additional-paths=src/main/java
#classpath目錄下的WEB-INF文件夾內容修改不重啟
spring.devtools.restart.exclude=WEB-INF/**

說明:

devtools可以實現頁面熱部署,即頁面修改後會立即生效,需要將application.properties文件中配置spring.thymeleaf.cache=false。

devtools會監聽classpath下的文件變動,並且會立即重啟應用。

 

3、IDEA配置

如果idea是新安裝的或者之前就沒有配置過,發現改變代碼項目熱部署不成功。當我們修改了Java類后,IDEA默認是不自動編譯的,而spring-boot-devtools又是監測classpath下的文件發生變化才會重啟應用。

所以需要設置IDEA的自動編譯:

(1)File-Settings-Compiler-Build Project automatically

(2)ctrl + shift + alt + /,選擇Registry,勾上 Compiler autoMake allow when app running 

這樣,就可以使用devtools實現熱部署了。

 

最後

以上,就把如何配置Spring Boot 開發環境熱部署介紹完了。還是比較簡單的,大家自己去研究吧。

 

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

【其他文章推薦】

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

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

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

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

※超省錢租車方案

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

大廠需求研發流程,進去前了解一波?

點贊再看,養成習慣,微信搜索【三太子敖丙】關注這個互聯網苟且偷生的程序員。

本文 GitHub https://github.com/JavaFamily 已收錄,有一線大廠面試完整考點和系列文章。

前言

我的讀者好像學生居多,然後大家最近問的比較多的一個話題就是大廠的研發流程,都比較好奇,整個流程是怎麼操作的。

我也不多BB了,那下面就跟隨暖男的腳步,走進大廠研發流程吧。

正文

我們先看看一個產品有哪些研發流程,帥丙就用自己接觸的阿里系的研發流程舉例了,這也基本上是互聯網大廠的研發流程了,可能細節有出入,但是絕對大同小異。

我問了下字節,多多,騰訊的朋友出入不大,所以還是具有代表性。

看完流程我們就一個個點的去看看每個環節幹了些啥,我們開發同學在這個環節需要做啥,以及在每個環節的職能。

需求提出:

這個環節主要是產品爸爸給我們提需求,每個需求都是他們從用戶,或者自己絞盡腦汁想出來的,但是產品爸爸還拿不準,不能直接敲定,所以就需要我們大家(產品,UI,前端,後端,客戶端和測試)一起討論一下,看看這個需求是否合理,或者這個需求是否有意義,能否達到預期,技術實現的成本,周期等等。

一旦聊成了,他們就會進入下一個階段,聊不成他會想方設法讓你答應,然後進入下個階段,知道我為啥叫產品爸爸了吧?

需求PRD提出:

這個階段,產品爸爸會根據第一版聊下來的結果,大致出一個Demo版本的PRD,會畫出初版的原型圖,並且配上文字說明,所有涉及到的業務,還有交互細節都會羅列出來。

大致就是下圖這樣:

這個時候大家又會圍繞這一版本去開會討論,敲定細節,這個環節會久點,因為細節比較認真,邏輯也不能出錯,還有UI稿子也得敲定,這裏如果不敲定邏輯,UI提前去畫原型圖,後面假如邏輯推翻,一切重來就會浪費大量時間。

這一環節大家都會把細節問清楚,不了解的點也會去了解,測試,開發,UI我們都會在會議上提出自己的觀點,自己的意見,然後等產品反饋,最後意見一致之後,產品當天就回改出敲定版本。

UI就會按照產品爸爸的意思去作圖,接下來就是交互設計評審了。

交互設計評審:

UI會畫出客戶端,前端,H5開發所需要的UI圖,基本上就是我們看到的產品的樣子了,不過還是要敲定細節,比如按鈕合理不,或者上面數據是否在這展示,或者這裏展示的數據是否合理。

這個環節會比較快,只要UI按照之前敲定的邏輯開發,出入不會很大,一般都是小改。

但是也不乏很多,之前敲定了情況,等UI按照敲定版本出了圖,但是卻發現出圖之後有些不合理的點,比如是否應該在這裏展示GMV(銷售總額),或者是否這樣展示活動規則啥的,會有這種情況,不過是小概率事件,改動也不會特別大。

UI界面:

大家看到的這種操作界面,按鈕,圖標的各種位置和圖案,都是UI在這個階段設計好的。(我什麼都沒暗示,不用關注我的B站)

大家敲定后就進入我們開發人員的回合了。

概要設計:

概要設計,這個是大廠程序員需求下來之後基本上都會做的一步,不過看需求大小,可能很多小需求直接就詳細設計了,也有啥設計都不用做的小改動,具體需求具體分析嘛。

很多不了解的同學可能會問,需要設計什麼呢?為什麼要設計呢?

問得好,經常看我文章的都知道,技術是把雙刃劍,你用了技術之後你是不是需要列出他的優點缺點,出問題之後的解決方案,還有可能出現的問題,注意點等等。

這麼是為了讓你能有把控力,比如你這個需求接入了新技術Es**(**Elasticsearch)你什麼都不管你就是要接入它,你把他開發好了上線了,但是有啥坑你知道么?上線崩了怎麼辦?

不主動,不拒絕,不負責,這是渣男的行徑,我們需要負起責任。

這個環節你需要考慮這個需求涉及到哪些服務了,需要新增哪些接口,修改哪些接口,表有現場的還是要新建表,字段要新建么?

其實遠遠不止這些問題,這就是我們做設計的主要原因,也是大家工作裏面能成長的途徑之一,你以為大佬們的經驗是怎麼來的?

推薦工具:Xmind/ProcessOn

  • Xmind官網地址: https://www.xmind.cn
  • ProcessOn
    在線作圖地址: https://www.processon.com

ProcessOn是我使用最頻繁的工具了,我身邊也有很多小夥伴在用,也推薦大家都使用:

大家在學習,看書等等的時候做個腦圖,後面學習和複習的時候思路會很清晰,而且效率瞬間高很多,形成知識體系。

概要設計一般就是做個大概,給大家看一下我自己在設計ES相關的需求的時候的概設,比較粗糙看個大概就好了:

這個設計好了,就需要給Leader看,看理解程度,一兩次返工是有可能的,如果你像或者像敖丙一樣笨的話,是有可能會被打回N次的,這裏我得提一下,好好做設計好處大大的有,自己體會。

然後會進行一輪測試用例評審,比如你涉及哪些服務,新增了哪些接口,改了哪些接口,都是要同步出來的,至於為啥?

是因為測試會依據這個數據,評估影響範圍,方便他寫測試用例,後面會提到。

詳細設計

小夥伴又要問了啥是詳細設計呀帥丙?

傻瓜,簡單呀,見名知意嘛,概要設計是大概的設計,詳細設計是詳細的設計。

我們研發的時候整個流程往往很複雜,如果你理解不對直接就寫代碼,最後容易造成返工,延期,加班,被罵,心情差,回家吵架,離家出走,露宿街頭,饑寒交迫,被迫吃野味,然後全國。。。。

看到不做詳細設計的後果了吧,其實大家花點時間做詳細設計很有必要,你思路完全清晰了,寫代碼那就是分分鐘的事情,不是嘛?

那再看看帥丙的一個小設計吧,之前文章中大量的流程圖,時序圖都來自它,主要是這玩意還是在線的,都不用下載很方便啊。

詳細設計的工具我用的就是之前提到的在線**作圖神器:**ProcessOn https://www.processon.com

還是我自己之前設計的一些流程圖,大家可以看看:

這個環節一樣重要,這個地方如果你能想好很多細節,開發的時候效率會高很多,像我上面的一些點,基本上就是看着圖開發了。

這個環節一般上不需要Leader參与,但是如果你有疑問或者不了解的點還是要提出來的。

測試用例評審:

上面我們說過,測試會根據你的概要設計,評估你的影響範圍,你的影響點,新增和改動的接口啥的,去編寫自己的測試用例。

測試用例,主要是為了把改動點影響點都考慮到,測全一點,免得上線了影響別的現有業務,也是為了把你開發的功能可能出現的bug給排除了。

我拿個小破站的小用例大家看看,這個比較粗糙但是也有點那味了。

這個環節也會開會討論,也是細節的確定,比如他寫的是否合理,或者有什麼點沒考慮到,大家有沒有補充的。

接口定義&開發&前後端聯調

這個環節其實比較好理解,啥都敲定了,那就開發唄,開發差不多了,就得前後端聯調了。

這裡有個小細節還是想說一下,一般開發前我們都會提前定義數據類型,接口名稱,然後在公司的接口工具上給出鏈接和參數,方便前端爸爸mock數據。

他總不能等我們後端開發完了,才去開發嘛,這樣效率打折扣,所以都是後端先定義好,然後前後端并行開發的。

後端開發好,一般都是會發布到聯調環境,我們有哪些環境,聯調環境在我們所有的環境中處於哪個地位呢?

大家可以看到我列出了我們開發的所有環境。

Tip:日常環境不能由開發人員發布,是因為測試流程比較久,所以不能中斷,如果你一直發布會影響測試的效率,在發布期間他們是沒辦法幹活的,而且很多部門涉及相同的服務,你發布還會影響別人。

測試發布之前,在測試群里問問可以發某個服務么,大家覺得不影響,那麼就可以發了,懂了吧。

預發環境,也叫灰度環境,這是跟線上數據一樣的一個環境,只是只能內網訪問,一般這一步是防止很多是因為日常的數據量不夠真實,數據級別達不到線上的量級無法測出的bug。

扯遠了,聯調完了就是代碼Review了。

代碼Review:

codeReview環節,畫一下重點,這可能是整個研發流程中,讓你成長最快的一個環節,讓組員和Leader Review你的代碼,往往他們能給你很多業務上和技術上的建議和意見。

過來人的經驗你就說香不香吧,以前老大經常沒時間,但是我就是煩着他要Review,後來他說不用review了,但是我還是要組員大佬review,因為我很享受別人對我提建議的時候,這不就是成長,掃盲的好時機嘛。

提測&灰度發布&產品第一次驗收

這一階段就是把代碼都發到日常環境,然後等測試爸爸測試,這個環節開發同學如果沒BUG是比較輕鬆的,等着就好了,可以看看丙丙的文章啊,看看丙丙的B站視頻什麼的。

但是如果你BUG多,那我覺得你可能會生不如死,因為有的bug真的找很久很久的,調用鏈路又長,特別是跨服務又涉及消息隊列,或者第三方的接口什麼的。

img

總之你也不知道會出現什麼bug,我看身邊的大神也只能用經驗避免常見的吭,孰能生巧吧。

發布計劃

敲黑板,這個確實是比較重要的環節,這個環節主要是開發同學和前端同學說好一個發布時間,然後制定一個發布計劃,為啥要發布計劃呢?

我們開發一個需求,可能涉及到N個服務,這些服務是有依賴關係的,那就需要打包,比如訂單系統,依賴人員系統。優惠券系統,也依賴人員系統,然後訂單系統還依賴優惠券系統,是不是有點亂了?

我們看圖:

打包和發布順序原則上是一樣的,從沒完全依賴的服務按照順序發布到最後一個服務。

生成環境上線:

這就是神聖而莊嚴的上線環節,一般在這個環節丙丙都是要洗手洗澡,然後才點下那個神聖的發布按鈕。

一般現在都是自動化發布,界面上點點就好了,記得丙丙大學發布都是進服務器一個個kill進程,替換jar包然後重啟。

現在都是分佈式的集群,這樣發無疑會累死,我之前負責的系統有50多台機器,一般都是4台4台發布。

日誌觀察&產品第二次驗收

一般發布第一批之後不會馬上發布第二批,而是觀察錯誤日誌,看看是否正常,有時候會發現還是會出現異常情況的,那就保留錯誤日誌,然後回滾。

知道解決了再發布,順利的話就沒啥錯誤,一口氣發完了,看了下時間凌晨了,那發完差不多也得回家了。

一次發布可能涉及服務多的話,真的有可能發布這麼久,但是沒辦法,線上出問題就是掉腦袋的事情。

日誌觀察一般公司都有錯誤日誌搜集系統,或者自己登錄跳板機查看就好了。

沒問題,發完之後告訴產品大大就好了。

需求結束

至此基本上一個需求可能就結束了,其實還是很不容易的,短的需求幾天,長的需求幾個月,中間塗塗改改,BUG,技術難點都是你要面對的,不過沒啥大問題,我們技術人嘛皮實能頂。

總結

產品研發流程大家是不是覺得有點複雜,或者覺得很多點有點小題大做了,不瞞你說,剛開始我也這麼認為的,但是隨着時間的推移,你會發現有時候越是這樣規範,越是提升了效率,也提升了產品質量。

對自己設計的嚴苛也會讓你的業務能力提升,開發考慮的點也越來越廣泛,我想大佬應該都是這樣走過去的,那沒啥好說的,我們也走。

最後給大家看看我自己搞的一個項目管理模板吧,基本上能適用大部分項目了,要xmind格式的公眾號回復【項目】即可。

相關資料

準備了很多學習資料給大家https://pan.baidu.com/s/1gM4Ea11ygHuMomT2VQ2aNQ

我是敖丙,一個在互聯網苟且偷生的程序員。

你知道的越多,你不知道的越多,人才們的 【三連】 就是丙丙創作的最大動力,我們下期見!

注:如果本篇博客有任何錯誤和建議,歡迎人才們留言!

文章持續更新,可以微信搜索「 三太子敖丙 」第一時間閱讀,回復【資料】有我準備的一線大廠面試資料和簡歷模板,本文 GitHub https://github.com/JavaFamily 已經收錄,有大廠面試完整考點,歡迎Star。

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

【其他文章推薦】

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

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

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

※超省錢租車方案

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

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

Project Loom:Reactive模型和協程進行時(翻譯)

Java 15將發布Project Loom的第一個版本。我相信這將改變JVM。在這篇文章中,我想深入探討一下導致我相信這一點的原因。

首先,我們需要了解核心問題。然後,我將嘗試描述以前的技術如何解決它。之後,我們將看到Project Loom採取的方法。最後,我將推斷後者可能對生態系統產生什麼影響。

Project Loom

我們首先必須記住,很長一段時間以來,計算機只有一個內核。即使這樣,還是需要同時運行多個程序:這至少要運行兩個操作系統和適當的程序。

為了實現并行性的幻覺,它依賴於一個技巧。它運行一個程序,如果該程序沒有在特定的時間範圍內完成,它將存儲其狀態以供以後使用。然後,它運行下一個要運行的程序。有幾種算法可用來調度下一個程序:循環調度,加權循環調度等。好處是,所有這些都可以通過操作系統線程的概念很好地從開發人員中抽象出來。該操作系統通吃繁重的護理,包括存儲執行的狀態。但是,線程有兩個缺點:

  • 線程很重,因為它帶有很多狀態
  • 線程需要大量的機器資源來創建
    在所有情況下,現代OS都允許M個線程,其中M是數千個線程。現代機器是多核的,提供N個核,比M少兩個數量級。擁有多個內核(無論是物理內核還是虛擬內核)並不會從根本上改變底層機制:M遠高於N,並且OS負責從線程到內核的映射。

阻塞線程

面的模型在傳統方案中效果很好,但在網絡方案中效果不佳。假設有一個Web服務器需要響應HTTP請求。在過去不太好的時候,CGI是處理請求的一種方法。它將每個請求映射到一個流程,以便處理創建整個新流程所需的請求,並在發送響應后將其清除。

Java EE應用程序服務器極大地改善了這種情況,因為實現將線程保留在池中以供以後重用。但是,想象一下響應的生成需要時間,例如因為它需要訪問數據庫以讀取數據。在數據庫返回數據之前,線程需要等待。

這意味着線程實際上正在等待其生命周期的大部分時間。一方面,此類線程自己不使用任何CPU。另一方面,它使用其他種類的資源,尤其是內存。

同樣,太多線程是操作系統的負擔:操作系統必須在數量有限的CPU內核上平衡大量線程。這花費了寶貴的CPU周期,因此,操作系統正在與應用程序競爭CPU。

現在,併發請求的數量可以遠遠超過服務器可用的線程數量。因此,阻塞的線程浪費資源,並使服務器無響應。為了解決這個問題,可以添加更多的Web服務器來處理負載:這是水平縮放。

在大多數情況下,水平縮放就足夠了。等待阻塞線程所花費的時間是浪費的,但是沒有任何相關的費用…除非一個人的基礎架構位於’雲’中。在那種情況下,人們要為未使用的資源付費:這絕不是一個明智的主意。

單線程,反應式和Kotlin協程模型

對於開發人員來說,管理多個線程很複雜。例如,如果您一直在使用(或開發)Swing應用程序,則可能知道“灰色矩形效果”。當用戶與窗口的交互(例如單擊)啟動長時間運行的任務時,就會發生這種情況。如果將另一個窗口移到Swing窗口上,然後再移出,Swing不會重畫另一個窗口與Swing窗口相交的區域,而不會留下難看的灰色矩形。原因是長時間運行的任務是在“ 事件調度線程”上啟動的,而不是在專用線程上啟動的。而且這很容易避免,甚至不涉及在共享的可變狀態上進行同步!

為了避免這種情況,某些堆棧完全禁止開發人員使用多個線程。例如,Node.js的API僅提供一個非阻塞事件循環線程:提交的函數採用回調的形式。請注意,這不會阻止實現使用多個線程。

該反應的方法是另一種選擇,其實頗為相似。儘管它擺脫了單線程API的限制,並提供了反壓力機制,但它仍然需要非阻塞代碼。由於OS線程很昂貴,因此Reactive將它們池化,並在整個應用程序生命周期中重複使用它們。核心過程是從池中獲取空閑線程,讓其執行代碼,然後將線程釋放回池中。這就是為什麼它需要非阻塞代碼的原因:如果代碼阻塞了,那麼執行線程將不會被釋放,並且池將在某一點或另一點耗盡。

我感興趣地觀察了Reactive模型如何像篝火一樣在Spring生態系統中傳播,儘管我選擇站在一邊。恕我直言,反應式有幾個缺點:

  • 編寫(和閱讀!)反應式代碼的思維方式與編寫傳統代碼的思維方式非常不同。我願意承認改變心態只需要時間,持續時間取決於每個開發人員。
  • 儘管真正的開發人員不會調試,但我知道很多人會調試-包括我自己。由於上述線程切換的魔力,要跟蹤一段代碼及其相關的狀態並不容易。這需要足夠的工具,例如帶有相關插件的 IntelliJ IDEA 。
  • 最後,出於相同的原因,傳統的堆棧跟蹤也無濟於事。一些黑魔法可以繞開它。但是,這不是為了膽小者。有關選項的完整列表,請查看此文檔。

Kotlin語言提供了Reactive方法的替代方法:協程。簡而言之,當使用suspend關鍵字時,Kotlin編譯器會在字節碼中生成一個有限狀態機。好處是在協程塊中調用的函數看起來像是順序執行的,儘管它們是并行執行的-更確切地說,取決於確切的範圍,有可能會執行。

Project Loom和虛擬線程

Reactive模型和Kotlin協程都在客戶端代碼和JVM線程之間添加了一個額外的抽象層。框架/庫的職責是動態地將一個映射到另一個。問題的癥結在於JVM線程是OS線程的薄包裝:請記住,OS線程創建起來很昂貴,並且數量限製為數千個。

Project Loom的目標是實際上將JVM線程與OS線程解耦。
當我第一次意識到該倡議時,其想法是創建一個稱為Fiber(線程,Project Loom,您能抓住麻煩嗎?)的抽象。一個Fiber責任是讓一個操作系統線程,使其運行代碼,釋放回池,就像無棧一樣。

當前的建議有很大的不同:Fiber它沒有使用新的類,而是重新使用了Java開發人員非常熟悉的一個類- java.lang.Thread!

因此,在新的JVM版本中,某些Thread對象可能是重量級的並映射到OS線程,而另一些對象可能是虛擬線程。

Project Loom發布的後續影響

主要問題是,既然JVM API提供了對OS線程的抽象,那麼其他抽象(例如響應式和協程)又會變成什麼樣呢?我對預測不滿意,但以下是Reactive /協程背後的公司可能採取的一些態度:

  • 正面態度,他們意識到自己的框架不再帶來任何附加值,而只是重複。他們停止了開發工作,僅向現有客戶提供維護版本。他們幫助說客戶遷移到新的ThreadAPI,一些幫助可能是以付費諮詢的形式。
  • 反面態度,他們在各自的框架中投入了大量的精力之後,他們決定繼續進行,好像什麼也沒有發生。例如,Spring框架負責實際設計一個共享的Reactive API,稱為Reactive Streams,沒有Spring依賴項。當前有兩種實現,RxJava v2和Pivotal的Project Reactor。另一方面,JetBrains宣傳Kotlin的協程是并行運行代碼的最簡單方法。
  • 中間態度。這兩個框架都將繼續其生命,但是會將它們各自的基礎實現更改為使用虛擬線程。
    由於沉沒成本的謬誤,排在第一位的可能性極小:銷售和市場營銷將努力保持其“競爭優勢”-無論在他們眼中意味着什麼。儘管有些工程師出於相同的原因希望保留現有代碼,但其他一些工程師則將努力使用新的API。因此,我也不相信第二名也會發生。但是,我認為這兩個工程派之間都發揮着力量,然後它們與市場營銷/銷售之間將在#3之間找到平衡。

結論

Project Looms將現有的Thread實現方式從OS線程的映射更改為可以表示此類線程或虛擬線程的抽象。就其本身而言,這是一個有趣的舉動,它在一個平台上歷來比創新更重視向後兼容性。與其他最新的Java版本相比,此功能是真正的遊戲規則改變者。一般而言,開發人員應儘快開始熟悉它。打算學習Reactive和協程的開發人員可能應該退後一步,並評估他們是否應該學習新的ThreadAPI- 是否需要。

翻譯原文

https://blog.frankel.ch/project-loom-reactive-coroutines/

擴展閱讀

Project Loom地址: https://github.com/openjdk/loom
Project Loom現有狀態: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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

手摸手帶你理解Vue響應式原理

前言

響應式原理作為 Vue 的核心,使用數據劫持實現數據驅動視圖。在面試中是經常考查的知識點,也是面試加分項。

本文將會循序漸進的解析響應式原理的工作流程,主要以下面結構進行:

  1. 分析主要成員,了解它們有助於理解流程
  2. 將流程拆分,理解其中的作用
  3. 結合以上的點,理解整體流程

文章稍長,但部分是代碼,還請耐心觀看。為了方便理解原理,文中的代碼會進行簡化,如果可以請對照源碼學習。

主要成員

在響應式原理中,Observe、Dep、Watcher 這三個類是構成完整原理的主要成員。

  • Observe,響應式原理的入口,根據數據類型處理觀測邏輯
  • Dep,依賴收集器,屬性都會有一個Dep,方便發生變化時能夠找到對應的依賴觸發更新
  • Watcher,用於執行更新渲染,組件會擁有一個渲染Watcher,我們常說的收集依賴,就是收集 Watcher

下面來看看這些類的實現,包含哪些主要屬性和方法。

Observe:我會對數據進行觀測

溫馨提示:代碼里的序號對應代碼塊下面序號的講解

// 源碼位置:/src/core/observer/index.js
class Observe {
  constructor(data) {
    this.dep = new Dep()
    // 1
    def(data, '__ob__', this)
    if (Array.isArray(data)) {
      // 2
      protoAugment(data, arrayMethods)
      // 3
      this.observeArray(data)
    } else {
      // 4
      this.walk(data)
    }
  }
  walk(data) {
    Object.keys(data).forEach(key => {
      defineReactive(data, key, data[key])
    })
  }
  observeArray(data) {
    data.forEach(item => {
      observe(item)
    })
  }
}
  1. 為觀測的屬性添加 __ob__ 屬性,它的值等於 this,即當前 Observe 的實例
  2. 為數組添加重寫的數組方法,比如:push、unshift、splice 等方法,重寫目的是在調用這些方法時,進行更新渲染
  3. 觀測數組內的數據,observe 內部會調用 new Observe,形成遞歸觀測
  4. 觀測對象數據,defineReactive 為數據定義 get 和 set ,即數據劫持

Dep:我會為數據收集依賴

// 源碼位置:/src/core/observer/dep.js
let id = 0
class Dep{
  constructor() {
    this.id = ++id // dep 唯一標識
    this.subs = [] // 存儲 Watcher
  }
  // 1
  depend() {
    Dep.target.addDep(this)
  }
  // 2
  addSub(watcher) {
    this.subs.push(watcher)
  }
  // 3
  notify() {
    this.subs.forEach(watcher => watcher.update())
  }
}

// 4
Dep.target = null

export function pushTarget(watcher) {
  Dep.target = watcher
} 

export function popTarget(){
  Dep.target = null
}

export default Dep
  1. 數據收集依賴的主要方法,Dep.target 是一個 watcher 實例
  2. 添加 watcher 到數組中,也就是添加依賴
  3. 屬性在變化時會調用 notify 方法,通知每一個依賴進行更新
  4. Dep.target 用來記錄 watcher 實例,是全局唯一的,主要作用是為了在收集依賴的過程中找到相應的 watcher

pushTarget 和 popTarget 這兩個方法顯而易見是用來設置 Dep.target的。Dep.target 也是一個關鍵點,這個概念可能初次查看源碼會有些難以理解,在後面的流程中,會詳細講解它的作用,需要注意這部分的內容。

Watcher:我會觸發視圖更新

// 源碼位置:/src/core/observer/watcher.js
let id = 0
export class Watcher {
  constructor(vm, exprOrFn, cb, options){
    this.id = ++id  // watcher 唯一標識
    this.vm = vm
    this.cb = cb
    this.options = options
    // 1
    this.getter = exprOrFn
    this.deps = []
    this.depIds = new Set()

    this.get()
  }
  run() {
    this.get()
  }
  get() {
    pushTarget(this)
    this.getter()
    popTarget(this)
  }
  // 2
  addDep(dep) {
    // 防止重複添加 dep
    if (!this.depIds.has(dep.id)) {
      this.depIds.add(dep.id)
      this.deps.push(dep)
      dep.addSub(this)
    }
  }
  // 3
  update() {
    queueWatcher(this)
  }
}
  1. this.getter 存儲的是更新視圖的函數
  2. watcher 存儲 dep,同時 dep 也存儲 watcher,進行雙向記錄
  3. 觸發更新,queueWatcher 是為了進行異步更新,異步更新會調用 run 方法進行更新頁面

響應式原理流程

對於以上這些成員具有的功能,我們都有大概的了解。下面結合它們,來看看這些功能是如何在響應式原理流程中工作的。

數據觀測

數據在初始化時會通過 observe 方法來調用 Observe

// 源碼位置:/src/core/observer/index.js
export function observe(data) {
  // 1
  if (!isObject(data)) {
    return
  }
  let ob;
  // 2
  if (data.hasOwnProperty('__ob__') && data.__ob__ instanceof Observe) {
    ob = data.__ob__
  } else {
    // 3
    ob = new Observe(data)
  }
  return ob
}

在初始化時,observe 拿到的 data 就是我們在 data 函數內返回的對象。

  1. observe 函數只對 object 類型數據進行觀測
  2. 觀測過的數據都會被添加上 __ob__ 屬性,通過判斷該屬性是否存在,防止重複觀測
  3. 創建 Observe 實例,開始處理觀測邏輯

對象觀測

進入 Observe 內部,由於初始化的數據是一個對象,所以會調用 walk 方法:

walk(data) {
  Object.keys(data).forEach(key => {
    defineReactive(data, key, data[key])
  })
}

defineReactive 方法內部使用 Object.defineProperty 對數據進行劫持,是實現響應式原理最核心的地方。

function defineReactive(obj, key, value) {
  // 1
  let childOb = observe(value)
  // 2
  const dep = new Dep()
  Object.defineProperty(obj, key, {
    get() {
      if (Dep.target) {
        // 3
        dep.depend()
        if (childOb) {
          childOb.dep.depend()
        }
      }
      return value
    },
    set(newVal) {
      if (newVal === value) {
        return
      }
      value = newVal
      // 4
      childOb = observe(newVal)
      // 5
      dep.notify()
      return value
    }
  })
}
  1. 由於值可能是對象類型,這裏需要調用 observe 進行遞歸觀測
  2. 這裏的 dep 就是上面講到的每一個屬性都會有一個 dep,它是作為一個閉包的存在,負責收集依賴和通知更新
  3. 在初始化時,Dep.target 是組件的渲染 watcher,這裏 dep.depend 收集的依賴就是這個 watcher,childOb.dep.depend 主要是為數組收集依賴
  4. 設置的新值可能是對象類型,需要對新值進行觀測
  5. 值發生改變,dep.notify 通知 watcher 更新,這是我們改變數據后能夠實時更新頁面的觸發點

通過 Object.defineProperty 對屬性定義后,屬性的獲取觸發 get 回調,屬性的設置觸發 set 回調,實現響應式更新。

通過上面的邏輯,也能得出為什麼 Vue3.0 要使用 Proxy 代替 Object.defineProperty 了。Object.defineProperty 只能對單個屬性進行定義,如果屬性是對象類型,還需要遞歸去觀測,會很消耗性能。而 Proxy 是代理整個對象,只要屬性發生變化就會觸發回調。

數組觀測

對於數組類型觀測,會調用 observeArray 方法:

observeArray(data) {
  data.forEach(item => {
    observe(item)
  })
}

與對象不同,它執行 observe 對數組內的對象類型進行觀測,並沒有對數組的每一項進行 Object.defineProperty 的定義,也就是說數組內的項是沒有 dep 的。

所以,我們通過數組索引對項進行修改時,是不會觸發更新的。但可以通過 this.$set 來修改觸發更新。那麼問題來了,為什麼 Vue 要這樣設計?

結合實際場景,數組中通常會存放多項數據,比如列表數據。這樣觀測起來會消耗性能。還有一點原因,一般修改數組元素很少會直接通過索引將整個元素替換掉。例如:

export default {
    data() {
        return {
            list: [
                {id: 1, name: 'Jack'},
                {id: 2, name: 'Mike'}
            ]
        }
    },
    cretaed() {
        // 如果想要修改 name 的值,一般是這樣使用
        this.list[0].name = 'JOJO'
        // 而不是以下這樣
        // this.list[0] = {id:1, name: 'JOJO'}
        // 當然你可以這樣更新
        // this.$set(this.list, '0', {id:1, name: 'JOJO'})
    }
}

數組方法重寫

當數組元素新增或刪除,視圖會隨之更新。這並不是理所當然的,而是 Vue 內部重寫了數組的方法,調用這些方法時,數組會更新檢測,觸發視圖更新。這些方法包括:

  • push()
  • pop()
  • shift()
  • unshift()
  • splice()
  • sort()
  • reverse()

回到 Observe 的類中,當觀測的數據類型為數組時,會調用 protoAugment 方法。

if (Array.isArray(data)) {
  protoAugment(data, arrayMethods)
  // 觀察數組
  this.observeArray(data)
} else {
  // 觀察對象
  this.walk(data)
}

這個方法里把數組原型替換為 arrayMethods ,當調用改變數組的方法時,優先使用重寫后的方法。

function protoAugment(data, arrayMethods) {
  data.__proto__ = arrayMethods
}

接下來看看 arrayMethods 是如何實現的:

// 源碼位置:/src/core/observer/array.js
// 1
let arrayProto = Array.prototype
// 2
export let arrayMethods = Object.create(arrayProto)

let methods = [
  'push',
  'pop',
  'shift',
  'unshift',
  'reverse',
  'sort',
  'splice'
]

methods.forEach(method => {
  arrayMethods[method] = function(...args) {
    // 3
    let res = arrayProto[method].apply(this, args)
    let ob = this.__ob__
    let inserted = ''
    switch(method){
      case 'push':
      case 'unshift':
        inserted = args
        break;
      case 'splice':
        inserted = args.slice(2)
        break;
    }
    // 4
    inserted && ob.observeArray(inserted)
    // 5
    ob.dep.notify()
    return res
  }
})
  1. 將數組的原型保存起來,因為重寫的數組方法里,還是需要調用原生數組方法的
  2. arrayMethods 是一個對象,用於保存重寫的方法,這裏使用 Object.create(arrayProto) 創建對象是為了使用者在調用非重寫方法時,能夠繼承使用原生的方法
  3. 調用原生方法,存儲返回值,用於設置重寫函數的返回值
  4. inserted 存儲新增的值,若 inserted 存在,對新值進行觀測
  5. ob.dep.notify 觸發視圖更新

依賴收集

依賴收集是視圖更新的前提,也是響應式原理中至關重要的環節。

偽代碼流程

為了方便理解,這裏寫一段偽代碼,大概了解依賴收集的流程:

// data 數據
let data = {
    name: 'joe'
}

// 渲染watcher
let watcher = {
    run() {
        dep.tagret = watcher
        document.write(data.name)
    }
}

// dep
let dep = [] // 存儲依賴 
dep.tagret = null // 記錄 watcher

// 數據劫持
let oldValue = data.name
Object.defineProperty(data, 'name', {
   get(){
       // 收集依賴
       dep.push(dep.tagret)
       return oldValue
   },
   set(newVal){
       oldValue = newVal
       dep.forEach(watcher => {
           watcher.run()
       })
       
   }
})

初始化:

  1. 首先會對 name 屬性定義 get 和 set
  2. 然後初始化會執行一次 watcher.run 渲染頁面
  3. 這時候獲取 data.name,觸發 get 函數收集依賴。

更新:

修改 data.name,觸發 set 函數,調用 run 更新視圖。

真正流程

下面來看看真正的依賴收集流程是如何進行的。

function defineReactive(obj, key, value) {
  let childOb = observe(value)
  const dep = new Dep()
  Object.defineProperty(obj, key, {
    get() {
      if (Dep.target) {
        dep.depend() // 收集依賴
        if (childOb) {
          childOb.dep.depend()
        }
      }
      return value
    },
    set(newVal) {
      if (newVal === value) {
        return
      }
      value = newVal
      childOb = observe(newVal)
      dep.notify()
      return value
    }
  })
}

首先初始化數據,調用 defineReactive 函數對數據進行劫持。

export class Watcher {
  constructor(vm, exprOrFn, cb, options){
    this.getter = exprOrFn
    this.get()
  }
  get() {
    pushTarget(this)
    this.getter()
    popTarget(this)
  }
}

初始化將 watcher 掛載到 Dep.target,this.getter 開始渲染頁面。渲染頁面需要對數據取值,觸發 get 回調,dep.depend 收集依賴。

class Dep{
  constructor() {
    this.id = id++
    this.subs = []
  }
  depend() {
    Dep.target.addDep(this)
  }
}

Dep.target 為 watcher,調用 addDep 方法,並傳入 dep 實例。

export class Watcher {
  constructor(vm, exprOrFn, cb, options){
    this.deps = []
    this.depIds = new Set()
  }
  addDep(dep) {
    if (!this.depIds.has(dep.id)) {
      this.depIds.add(dep.id)
      this.deps.push(dep)
      dep.addSub(this)
    }
  }
}

addDep 中添加完 dep 后,調用 dep.addSub 並傳入當前 watcher 實例。

class Dep{
  constructor() {
    this.id = id++
    this.subs = []
  }
  addSub(watcher) {
    this.subs.push(watcher)
  }
}

將傳入的 watcher 收集起來,至此依賴收集流程完畢。

補充一點,通常頁面上會綁定很多屬性變量,渲染會對屬性取值,此時每個屬性收集的依賴都是同一個 watcher,即組件的渲染 watcher。

數組的依賴收集

methods.forEach(method => {
  arrayMethods[method] = function(...args) {
    let res = arrayProto[method].apply(this, args)
    let ob = this.__ob__
    let inserted = ''
    switch(method){
      case 'push':
      case 'unshift':
        inserted = args
        break;
      case 'splice':
        inserted = args.slice(2)
        break;
    }
    // 對新增的值觀測
    inserted && ob.observeArray(inserted)
    // 更新視圖
    ob.dep.notify()
    return res
  }
})

還記得重寫的方法里,會調用 ob.dep.notify 更新視圖,__ob__ 是我們在 Observe 為觀測數據定義的標識,值為 Observe 實例。那麼 ob.dep 的依賴是在哪裡收集的?

function defineReactive(obj, key, value) {
  // 1
  let childOb = observe(value)
  const dep = new Dep()
  Object.defineProperty(obj, key, {
    get() {
      if (Dep.target) {
        dep.depend()
        // 2
        if (childOb) {
          childOb.dep.depend()
        }
      }
      return value
    },
    set(newVal) {
      if (newVal === value) {
        return
      }
      value = newVal
      childOb = observe(newVal)
      dep.notify()
      return value
    }
  })
}
  1. observe 函數返回值為 Observe 實例
  2. childOb.dep.depend 執行,為 Observe 實例的 dep 添加依賴

所以在數組更新時,ob.dep 內已經收集到依賴了。

整體流程

下面捋一遍初始化流程和更新流程,如果你是初次看源碼,不知道從哪裡看起,也可以參照以下的順序。由於源碼實現比較多,下面展示的源碼會稍微刪減一些代碼

初始化流程

入口文件:

// 源碼位置:/src/core/instance/index.js
import { initMixin } from './init'
import { stateMixin } from './state'
import { renderMixin } from './render'
import { eventsMixin } from './events'
import { lifecycleMixin } from './lifecycle'
import { warn } from '../util/index'

function Vue (options) {
  this._init(options)
}

initMixin(Vue)
stateMixin(Vue)
eventsMixin(Vue)
lifecycleMixin(Vue)
renderMixin(Vue)

export default Vue

_init:

// 源碼位置:/src/core/instance/init.js
export function initMixin (Vue: Class<Component>) {
  Vue.prototype._init = function (options?: Object) {
    const vm: Component = this
    // a uid
    vm._uid = uid++

    // merge options
    if (options && options._isComponent) {
      // optimize internal component instantiation
      // since dynamic options merging is pretty slow, and none of the
      // internal component options needs special treatment.
      initInternalComponent(vm, options)
    } else {
      // mergeOptions 對 mixin 選項和傳入的 options 選項進行合併
      // 這裏的 $options 可以理解為 new Vue 時傳入的對象
      vm.$options = mergeOptions(
        resolveConstructorOptions(vm.constructor),
        options || {},
        vm
      )
    }

    // expose real self
    vm._self = vm
    initLifecycle(vm)
    initEvents(vm)
    initRender(vm)
    callHook(vm, 'beforeCreate')
    initInjections(vm) // resolve injections before data/props
    // 初始化數據
    initState(vm)
    initProvide(vm) // resolve provide after data/props
    callHook(vm, 'created')

    if (vm.$options.el) {
      // 初始化渲染頁面 掛載組件
      vm.$mount(vm.$options.el)
    }
  }
}

上面主要關注兩個函數,initState 初始化數據,vm.$mount(vm.$options.el) 初始化渲染頁面。

先進入 initState:

// 源碼位置:/src/core/instance/state.js 
export function initState (vm: Component) {
  vm._watchers = []
  const opts = vm.$options
  if (opts.props) initProps(vm, opts.props)
  if (opts.methods) initMethods(vm, opts.methods)
  if (opts.data) {
    // data 初始化
    initData(vm)
  } else {
    observe(vm._data = {}, true /* asRootData */)
  }
  if (opts.computed) initComputed(vm, opts.computed)
  if (opts.watch && opts.watch !== nativeWatch) {
    initWatch(vm, opts.watch)
  }
}

function initData (vm: Component) {
  let data = vm.$options.data
  // data 為函數時,執行 data 函數,取出返回值
  data = vm._data = typeof data === 'function'
    ? getData(data, vm)
    : data || {}
  // proxy data on instance
  const keys = Object.keys(data)
  const props = vm.$options.props
  const methods = vm.$options.methods
  let i = keys.length
  while (i--) {
    const key = keys[i]
    if (props && hasOwn(props, key)) {
      process.env.NODE_ENV !== 'production' && warn(
        `The data property "${key}" is already declared as a prop. ` +
        `Use prop default value instead.`,
        vm
      )
    } else if (!isReserved(key)) {
      proxy(vm, `_data`, key)
    }
  }
  // observe data
  // 這裏就開始走觀測數據的邏輯了
  observe(data, true /* asRootData */)
}

observe 內部流程在上面已經講過,這裏再簡單過一遍:

  1. new Observe 觀測數據
  2. defineReactive 對數據進行劫持

initState 邏輯執行完畢,回到開頭,接下來執行 vm.$mount(vm.$options.el) 渲染頁面:

$mount:

// 源碼位置:/src/platforms/web/runtime/index.js 
Vue.prototype.$mount = function (
  el?: string | Element,
  hydrating?: boolean
): Component {
  el = el && inBrowser ? query(el) : undefined
  return mountComponent(this, el, hydrating)
}

mountComponent:

// 源碼位置:/src/core/instance/lifecycle.js
export function mountComponent (
  vm: Component,
  el: ?Element,
  hydrating?: boolean
): Component {
  vm.$el = el
  callHook(vm, 'beforeMount')

  let updateComponent
  /* istanbul ignore if */
  if (process.env.NODE_ENV !== 'production' && config.performance && mark) {
    updateComponent = () => {
      const name = vm._name
      const id = vm._uid
      const startTag = `vue-perf-start:${id}`
      const endTag = `vue-perf-end:${id}`

      mark(startTag)
      const vnode = vm._render()
      mark(endTag)
      measure(`vue ${name} render`, startTag, endTag)

      mark(startTag)
      vm._update(vnode, hydrating)
      mark(endTag)
      measure(`vue ${name} patch`, startTag, endTag)
    }
  } else {
    // 數據改變時  會調用此方法
    updateComponent = () => {
      // vm._render() 返回 vnode,這裏面會就對 data 數據進行取值
      // vm._update 將 vnode 轉為真實dom,渲染到頁面上
      vm._update(vm._render(), hydrating)
    }
  }
  
  // 執行 Watcher,這個就是上面所說的渲染wacther 
  new Watcher(vm, updateComponent, noop, {
    before () {
      if (vm._isMounted && !vm._isDestroyed) {
        callHook(vm, 'beforeUpdate')
      }
    }
  }, true /* isRenderWatcher */)
  hydrating = false

  // manually mounted instance, call mounted on self
  // mounted is called for render-created child components in its inserted hook
  if (vm.$vnode == null) {
    vm._isMounted = true
    callHook(vm, 'mounted')
  }
  return vm
}

Watcher:

// 源碼位置:/src/core/observer/watcher.js 
let uid = 0

export default class Watcher {
  constructor(vm, exprOrFn, cb, options){
    this.id = ++id
    this.vm = vm
    this.cb = cb
    this.options = options
    // exprOrFn 就是上面傳入的 updateComponent
    this.getter = exprOrFn

    this.deps = []
    this.depIds = new Set()

    this.get()
  }
  get() {
    // 1. pushTarget 將當前 watcher 記錄到 Dep.target,Dep.target 是全局唯一的
    pushTarget(this)
    let value
    const vm = this.vm
    try {
    // 2. 調用 this.getter 相當於會執行 vm._render 函數,對實例上的屬性取值,
    //由此觸發 Object.defineProperty 的 get 方法,在 get 方法內進行依賴收集(dep.depend),這裏依賴收集就需要用到 Dep.target
      value = this.getter.call(vm, vm)
    } catch (e) {
      if (this.user) {
        handleError(e, vm, `getter for watcher "${this.expression}"`)
      } else {
        throw e
      }
    } finally {
      // "touch" every property so they are all tracked as
      // dependencies for deep watching
      if (this.deep) {
        traverse(value)
      }
      // 3. popTarget 將 Dep.target 置空
      popTarget()
      this.cleanupDeps()
    }
    return value
  }
}

至此初始化流程完畢,初始化流程的主要工作是數據劫持、渲染頁面和收集依賴。

更新流程

數據發生變化,觸發 set ,執行 dep.notify

// 源碼位置:/src/core/observer/dep.js 
let uid = 0

/**
 * A dep is an observable that can have multiple
 * directives subscribing to it.
 */
export default class Dep {
  static target: ?Watcher;
  id: number;
  subs: Array<Watcher>;

  constructor () {
    this.id = uid++
    this.subs = []
  }

  addSub (sub: Watcher) {
    this.subs.push(sub)
  }

  removeSub (sub: Watcher) {
    remove(this.subs, sub)
  }

  depend () {
    if (Dep.target) {
      Dep.target.addDep(this)
    }
  }

  notify () {
    // stabilize the subscriber list first
    const subs = this.subs.slice()
    if (process.env.NODE_ENV !== 'production' && !config.async) {
      // subs aren't sorted in scheduler if not running async
      // we need to sort them now to make sure they fire in correct
      // order
      subs.sort((a, b) => a.id - b.id)
    }
    for (let i = 0, l = subs.length; i < l; i++) {
      // 執行 watcher 的 update 方法
      subs[i].update()
    }
  }
}

wathcer.update:

// 源碼位置:/src/core/observer/watcher.js 
/**
 * Subscriber interface.
 * Will be called when a dependency changes.
 */
update () {
  /* istanbul ignore else */
  if (this.lazy) {  // 計算屬性更新
    this.dirty = true
  } else if (this.sync) {  // 同步更新
    this.run()
  } else {
    // 一般的數據都會進行異步更新
    queueWatcher(this)
  }
}

queueWatcher:

// 源碼位置:/src/core/observer/scheduler.js

// 用於存儲 watcher
const queue: Array<Watcher> = []
// 用於 watcher 去重
let has: { [key: number]: ?true } = {}
/**
 * Flush both queues and run the watchers.
 */
function flushSchedulerQueue () {
  let watcher, id

  // 對 watcher 排序
  queue.sort((a, b) => a.id - b.id)

  // do not cache length because more watchers might be pushed
  // as we run existing watchers
  for (index = 0; index < queue.length; index++) {
    watcher = queue[index]
    id = watcher.id
    has[id] = null
    // run方法更新視圖
    watcher.run()
  }
}
/**
 * Push a watcher into the watcher queue.
 * Jobs with duplicate IDs will be skipped unless it's
 * pushed when the queue is being flushed.
 */
export function queueWatcher (watcher: Watcher) {
  const id = watcher.id
  if (has[id] == null) {
    has[id] = true
    // watcher 加入數組
    queue.push(watcher)
    // 異步更新
    nextTick(flushSchedulerQueue)
  }
}

nextTick:

// 源碼位置:/src/core/util/next-tick.js

const callbacks = []
let pending = false

function flushCallbacks () {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  // 遍歷回調函數執行
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

let timerFunc

if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  timerFunc = () => {
    p.then(flushCallbacks)
  }
}

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  // 將回調函數加入數組
  callbacks.push(() => {
    if (cb) {
      cb.call(ctx)
    }
  })
  if (!pending) {
    pending = true
    // 遍歷回調函數執行
    timerFunc()
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

這一步是為了使用微任務將回調函數異步執行,也就是上面的p.then。最終,會調用 watcher.run 更新頁面。

至此更新流程完畢。

寫在最後

如果沒有接觸過源碼的同學,我相信看完可能還是會有點懵的,這很正常。建議對照源碼再自己多看幾遍就能知道流程了。對於有基礎的同學就當做是複習了。

想要變強,學會看源碼是必經之路。在這過程中,不僅能學習框架的設計思想,還能培養自己的邏輯思維。萬事開頭難,遲早都要邁出這一步,不如就從今天開始。

簡化后的代碼我已放在 github,有需要的可以看看。

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

【其他文章推薦】

※超省錢租車方案

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

※回頭車貨運收費標準

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

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

三星和半導體工人組織就白血病爭議達成妥協

摘錄自2018年月日[媒體名稱][地點]報導

韓聯社報導,三星電子、半導體工人健康與人權守護組織(簡稱半導體工人組織)及調解委員會24日上午舉行「第二次重啟調解及仲裁方式協議簽字儀式」,三星和半導體工人組織承諾今後無條件接受調解委提出的方案。

調解委將於8-9月製定調解方案,在9月底到10月初發表第二次調解最終方案,三星電子爭取在10月內對半導體工人組織的受害者提供賠償。

2007年,在三星電子半導體生產線工作的黃某因患急性白血病不幸身亡。此後,白血病等疾病是否與三星半導體工廠有關引起了爭議。

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

【其他文章推薦】

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

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

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

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

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

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

日本熱浪強襲已釀80死 當局考慮延長暑假

摘錄自2018年7月24日中央通訊社台北報導

熱浪侵襲日本2週,造成至少80人死亡,數千人送急診。官員今天(24日)表示,部分地區溫度飆破攝氏40度,呼籲民眾留在室內。

日本政府表示,可能出錢幫公立學校裝冷氣,以及延長暑假。日本許多學生本週開始放暑假,東京多數學校有冷氣,但鄉下卻很少。

日本電力交易所數據顯示,民眾打開冷氣,也讓電價攀至五年新高。

日本總務省消防廳數字顯示,愈來愈多人因高溫喪命,截至7月22日為止當週,有65人死亡,而先前一週為12人死亡,再往前一週則僅3人死亡。

日本共同社報導,昨(23日)至少有13人因高溫喪命。

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

【其他文章推薦】

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

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

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

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

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

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

野火滅村奪74命 雅典同時燃15場森林火 希臘總理:很奇怪

摘錄自2018年7月25日東森新聞台北報導

希臘首都雅典近日高溫達到40℃,野火23日下午起失控焚燒,強風助長下蔓延燒至林地和村落,死亡人數超過74人,至少有187人受傷,甚至有「滅村」情形。這是十年來發生最嚴重的森林大火,當局已經進入緊急狀態,忙著撤離居民和遊客。

希臘總理齊普拉斯(Alexis Tsipras)24日宣布為期三天的全國性哀悼:「這個國家正面臨一場無法用言語形容的悲劇。」希臘同時也呼籲歐盟能提供國際援助,目前當局已布署直升機降水下來,提供民眾逃難的時間。

齊普拉斯與政府官員也派了幾架由美國政府提供的無人駕駛飛機追查任何可疑的行動,他們認為雅典的東、北、西方等地區同時發生15場森林大火是一件很奇怪的事情,也不知道是什麼原因點燃野火。

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

【其他文章推薦】

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

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

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

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

※超省錢租車方案

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