主頁 > 軟體設計 > 區塊鏈共識機制技術一——POW(作業量證明)共識機制

區塊鏈共識機制技術一——POW(作業量證明)共識機制

2020-10-13 14:39:23 軟體設計

什么是共識機制

所謂“共識機制”,是通過特殊節點的投票,在很短的時間內完成對交易的驗證和確認;對一筆交易,如果利益不相干的若干個節點能夠達成共識,我們就可以認為全網對此也能夠達成共識,

區塊鏈作為一個去中心化的分布式賬本系統,然而在實際運行中,怎么解決因為去中心化后,保證整個系統能有效運行,各個節點誠實記賬,在沒有所謂的中心的情況下,互相不信任的個體之間就交易的合法性達成共識的共識機制,

共識機制的目標

區塊鏈作為一種按時間順序存盤資料的資料結構,可支持不同的共識機制,共識機制是區塊鏈技術的重要組件,區塊鏈共識機制的目標是使所有的誠實節點保存一致的區塊鏈視圖,同時滿足兩個性質:
1)一致性,所有誠實節點保存的區塊鏈的前綴部分完全相同,
2)有效性,由某誠實節點發布的資訊終將被其他所有誠實節點記錄在自己的區塊鏈中,

為什么需要共識機制?

在分布式系統中,各個不同的主機通過異步通信方式組成網路集群,為了保證每個主機達成一致的狀態共識,就需要在主機之間進行狀態復制,異步系統中,可能會出現各樣的問題,例如主機出現故障無法通信,或者新能下降,而網路也可能發生擁堵延遲,類似的種種故障有可能會發生錯誤資訊在系統內傳播,因此需要在默認不可靠的異步網路中定義容錯協議,以確保各主機達成安全可靠的狀態共識,所以,利用區塊鏈構造基于互聯網的去中心化賬本,需要解決的首要問題是如何實作不同賬本節點上的賬本資料的一致性和正確性,

這就需要借鑒已有的在分布式系統中實作狀態共識的演算法,確定網路中選擇記賬節點的機制,以及如何保障賬本資料在全網中形成正確、一致的共識,

如何評價一個共識機制的優劣:

  1. 安全性:能否有效防止二次支付,私自挖礦
  2. 擴展性:當系統成員和待確認交易數量增加時,所帶來的系統負載和網路通信量的變化,通常以網路吞吐量來衡量
  3. 性能效率:每秒可以處理的交易數量
  4. 資源消耗:達成共識程序中,所要消耗的CPU、記憶體等計算資源

區塊鏈分類

在開始進行共識機制梳理前,首先需要對目前的區塊鏈進行一個簡單的了解,目前市面上根據共識演算法及應用場景把區塊鏈分為三類:公有鏈、聯盟鏈和私有鏈,

公有鏈,是一個完全開放的分布式系統,公有鏈中的節點可以很自由的加入或者退出,不需要嚴格的驗證和審核,比如位元幣、以太坊、EOS等,共識機制在公有鏈中不僅需要考慮網路中存在故障節點,還需要考慮作惡節點,并確保最終一致性,

聯盟鏈,是一個相對開放的分布式系統,對于聯盟鏈,每個新加入的節點都是需要驗證和審核的,比如Fabric、BCOS等,聯盟鏈一般應用于企業之間,對安全和資料的一致性要求較高,所以共識機制在聯盟鏈中不僅需要考慮網路中存在故障節點,還需要考慮作惡節點,同時除過確保最終一致性外,還需要確保強一致性,

私有鏈,是一個封閉的分布式系統,由于私有鏈是一個內部系統,所以不需要考慮新節點的加入和退出,也不需要考慮作惡節點,私有鏈的共識演算法還是傳統分布式系統里的共識演算法,比如zookeeper的zab協議,就是類paxos演算法的一種,只考慮因為系統或者網路原因導致的故障節點,資料一致性要求根據系統的要求而定,

共識機制有哪些?

常見的共識就機制包括:POW(作業量證明機制)、POS(權益證明機制)、POW+POS(混合共識機制)、DPOS(股份授權證明)等等,另外還有Pool驗證池、Ripple瑞波共識協議、PBFT(使用拜占庭容錯演算法)等等,今天先介紹POW共識機制,

POW作業量證明共識機制

一、前言

PoW(Proof of Work),即作業量證明,聞名于位元幣,俗稱"挖礦”,PoW是指系統為達到某一目標而設定的度量方法,簡單理解就是一份證明,用來確認你做過一定量的作業,監測作業的整個程序通常是極為低效的,而通過對作業的結果進行認證來證明完成了相應的作業量,則是一種非常高效的方式,PoW是按勞分配,算力決定一起,誰的算力多誰記賬的概率就越大,可理解為力量型比較,以下內容基于位元幣的PoW機制,

作業量證明(PoW)通過計算一個數值( nonce ),使得拼揍上交易資料后內容的Hash值滿足規定的上限,在節點成功找到滿足的Hash值之后,會馬上對全網進行廣播打包區塊,網路的節點收到廣播打包區塊,會立刻對其進行驗證,

如何才能創建一個新區塊呢?通過解決一個問題:即找到一個nonce值,使得新區塊頭的哈希值小于某個指定的值,即區塊頭結構中的“難度目標”,

如果驗證通過,則表明已經有節點成功解迷,自己就不再競爭當前區塊打包,而是選擇接受這個區塊,記錄到自己的賬本中,然后進行下一個區塊的競爭猜謎,網路中只有最快解謎的區塊,才會添加的賬本中,其他的節點進行復制,這樣就保證了整個賬本的唯一性,

假如節點有任何的作弊行為,都會導致網路的節點驗證不通過,直接丟棄其打包的區塊,這個區塊就無法記錄到總賬本中,作弊的節點耗費的成本就白費了,因此在巨大的挖礦成本下,也使得礦工自覺自愿的遵守位元幣系統的共識協議,也就確保了整個系統的安全,

在了解pow共識機制前,我們先了解下位元幣區塊的結構,下圖是位元幣區塊的結構圖:
在這里插入圖片描述
從圖上可知,位元幣的結構分為區塊頭和區塊體,其中區塊頭細分為:
父區塊頭哈希值:前一區塊的哈希值,使用SHA256(SHA256(父區塊頭))計算,占32位元組
版本:區塊版本號,表示本區塊遵守的驗證規則,占4位元組
時間戳:該區塊產生的近似時間,精確到秒的UNIX時間戳,必須嚴格大于前11個區塊時間的中值,同時全節點也會拒絕那些超出自己2個小時時間戳的區塊,占4位元組
難度:該區塊作業量證明演算法的難度目標,已經使用特定演算法編碼,占4位元組
亂數(Nonce):為了找到滿足難度目標所設定的亂數,為了解決32位亂數在算力飛升的情況下不夠用的問題,規定時間戳和coinbase交易資訊均可更改,以此擴展nonce的位數,占4位元組
Merkle根:該區塊中交易的Merkle樹根的哈希值,同樣采用SHA256(SHA256())計算,占32位元組

如此,細心的同學會發現,區塊頭總共占了80位元組,

區塊體除了籌幣交易記錄(由一棵Merkle二叉樹組成)外,還有一個交易計數,

位元幣的任何一個節點,想生成一個新的區塊,必須使用自己節點擁有的算力解算出pow問題,因此,我們先了解下pow作業量證明的三要素,

二、POW作業量證明的三要素

作業機制
為了使區塊鏈交易資料記錄在區塊鏈上并在一定時間內達到一致(共識),PoW提供了一種思路,即所有區塊鏈的網路節點參與者進行競爭記賬,所謂競爭記賬是指,如果想生成一個新的區塊并寫入區塊鏈,必須解出位元幣網路出的作業量證明謎題,誰先解出答案,誰就獲得記賬權利,然后開始記賬并將將解出的答案和交易記錄廣播給其他節點進行驗證,自己則開始下一輪挖礦,如果區塊的交易被其他節點參與者驗證有效并且謎題的答案正確,就意味著這個答案是可信的,新的節點將被寫入驗證者的節點區塊鏈,同時驗證者進入下一輪的競爭挖礦,

這道題關鍵的三個要素是作業量證明函式、區塊及難度值,作業量證明函式是這道題的計算方法,區塊決定了這道題的輸入資料,難度值決定了這道題的所需要的計算量,
1、作業量證明函式
在位元幣中使用的是SHA256演算法函式,是密碼哈希函式家族中輸出值為256位的哈希演算法,

2、 區塊
區塊頭在前言中已經做詳細介紹,這里我們就介紹下區塊體的 Merkle樹演算法:
在這里插入圖片描述
如上圖所示,首先對4個交易記錄L1–L4,分別計算hash(L1)–hash(L4),然后計算hash0=hash0-0+hash0-1和hash1=hash1-0+hash1-1,最后計算出根節點的hash值top hash,

3、難度值
關于難度值,我們直接看公式:
新難度值=舊難度值*(過去2016個區塊花費時長/20160分鐘)
tips:難度值是隨網路變動的,目的是為了在不同的網路環境下,確保每10分鐘能生成一個塊,
新難度值決議:撇開舊難度值,按位元幣理想情況每10分鐘出塊的速度,過去2016個塊的總花費接近20160分鐘,這樣,這個值永遠趨近于1,

目標值=最大目標值/難度值
目標值決議:最大目標值為一個固定數,若過去2016個區塊花費時長少于20160分,那么這個系數會小,目標值將會被調大些,反之,目標值會被調小,因此,位元幣的難度和出塊速度將成反比例適當調整出塊速度,

那如何計算呢?SHA256(SHA256(Block_Header)),即只需要對區塊頭進行兩次SHA256運算即可,得到的值和目標值進行比較,小于目標值即可,

區塊頭中有一個重要的東西叫MerkleRoot的hash值,這個東西的意義在于:為了使區塊頭能體現區塊所包含的所有交易,在區塊的構造程序中,需要將該區塊要包含的交易串列,通過Merkle Tree演算法生成Merkle Root Hash,并以此作為交易串列的摘要存到區塊頭中,

至此,我們發現區塊頭中除過nonce以外,其余的資料都是明確的,解題的核心就在于不停的調整nonce的值,對區塊頭進行雙重SHA256運算,

介紹完pow作業量證明的三要素后,我們就可以講解下作業量證明的流程,

三、POW作業量證明流程

在這里插入圖片描述
從流程圖中看出,pow作業量證明的流程主要經歷三步:

1.生成Merkle根哈希
??生成Merkle根哈希在第二章節中的第2要素中已經有講解,即節點自己生成一筆籌幣交易,并且與其他所有即將打包的交易通過Merkle樹演算法生成Merkle根哈希,所以為什么說區塊是作業量證明的三要素之一,

2.組裝區塊頭
??區塊頭將被作為計算出作業量證明輸出的一個輸入引數,因此第一步計算出來的Merkle根哈希和區塊頭的其他組成部分組裝成區塊頭,這也就是為什么我們在前言中大費周章的去提前講解位元幣的區塊頭,

3.計算出作業量證明的輸出
??下面我們直接通過公式和一些偽代碼去理解作業量證明的輸出:

?? i. 作業量證明的輸出=SHA256(SHA256(區塊頭))

?? ii. if(作業量證明的輸出<目標值),證明作業量完成

??iii.if(作業量證明的輸出>=目標值),變更亂數,遞回i的邏輯,繼續與目標值比對,
??注:目標值的計算見第二章節的要素3的難度值,

上面的流程圖及決議即pow作業量證明的整個程序,

四、POW共識記賬

前面三部分中講解的是單節點作業量證明流程,有了這個計算流程,我們就得將其使用起來,在位元幣平臺中,中本聰就是運用的pow作業量證明來使全網節點達到51%及以上的共識記賬,以下將介紹pow作業量證明共識是如何記賬的?

首先,客戶端產生新的交易,向全網廣播

第二,每個節點收到請求,將交易納入區塊中

第三,每個節點通過第三章中描述的pow作業量證明

第四,當某個節點找到了證明,向全網廣播

第五,當且僅當該區塊的交易是有效的且在之前中未存在的,其他節點才認同該區塊的有效性

第六,接受該區塊且在該區塊的末尾制造新的區塊

大概時序圖如下:
在這里插入圖片描述

五、POW的優缺點

通過上面的描述,PoW優點很明顯:

  1. 完全去中心化(任何人都可以加入);
  2. 節點自由進出,容易實作;
  3. 破壞系統花費的成本巨大;

關于破壞系統成本巨大可以分兩層意思理解:

  1. 在指定時間內,給定一個難度,找到答案的概率唯一地由所有參與者能夠迭代哈希的速度決定,與之前的歷史無關,與資料無關,只跟算力有關,
  2. 掌握51%的算力對系統進行攻擊所付出的代價遠遠大于作為一個系統的維護者和誠實參與者所得到的,

缺點也相當明顯:

  1. 對節點的性能網路環境要求高;
  2. 浪費資源;
  3. 每秒鐘最多只能做七筆交易,效率低下;
  4. 礦場的出現違背了去中心的初衷;
  5. 不能確保最終一致性;
  6. 位元幣產量每4年減半,利益驅動性降低導致曠工數量減少從而導致位元幣網路癱瘓,

六、網路攻擊和鏈分叉

1)網路攻擊
假定一個惡意節點試圖雙花之前的已花費的交易,攻擊者需要重做包含這個交易的區塊,以及這個區塊之后的所有的區塊,創建一個比目前誠實區塊鏈更長的區塊鏈,只有網路中的大多數節點都轉向攻擊者創建的區塊鏈,攻擊者的攻擊才算成功了,由于每一個區塊都包含了之前的所有區塊的交易資訊,所以隨著塊高的增加,之前的區塊都會被再次確認一次,確認超過6次,可以理解為無法被修改,

考慮交易T包含在區塊b1中,每個后續區塊b2,b3,b4,……bn會降低交易T被修改的可能性,因為修改這些后續的區塊需要更多的算力,中本聰用概率理論證明,六個區塊后攻擊者追趕上最長鏈的可能性降低到0.0002428%,在過4個或更多區塊后這個可能行會降到0.0000012%,每新增一個區塊bn,攻擊的可能性就會以指數形式下降,很快整個攻擊的可能性就會低到可以忽略的程度,

2)鏈分叉
所謂的鏈分叉,主要是由于在計算hash時,每個人拿到的區塊內容是不同的,導致算出的區塊結果也不同,但都是正確結果,于是,區塊鏈在這個時刻,出現了兩個都滿足要求的不同區塊,那曠工怎么辦呢?由于距離遠近、網路等原因,不同曠工看到這兩個區塊的先后順序是不一樣的,通常情況下,曠工會把自己先看到的區塊鏈復制過來,然后接著在這個區塊上開始新的挖礦作業,于是就出現了鏈分叉,

PoW解決方案:
從分叉的區塊起,由于不同的礦工跟從了不同的區塊,在分叉出來的兩條不同鏈上,算力是有差別的,由于解題能力和礦工的算力成正比,因此兩條鏈的增長速度也是不一樣的,在一段時間之后,總有一條鏈的長度要超過另一條,當礦工發現全網有一條更長的鏈時,他就會拋棄他當前的鏈,把新的更長的鏈全部復制回來,在這條鏈的基礎上繼續挖礦,所有礦工都這樣操作,這條鏈就成為了主鏈,分叉出來被拋棄掉的鏈就消失了,

能夠讓區塊鏈保證唯一性的前提是:所有礦工都遵從同樣的機制,當曠工遵從不同的機制時,就會出現硬分叉,這種分叉會導致資產增加,且兩條鏈同時存在,比如BBC,

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/170923.html

標籤:其他

上一篇:Docker-Compose安裝

下一篇:億和論幣:10.12BTC ETH區間震蕩過久 后市必大波動

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more