以太坊下swarm的使用

⑴ bzz是什麼幣

BZZ 幣是在一個名叫 Swarm的 平台推出的一款數字貨幣，它作為 Swarm 平台的代幣，可以作為獎勵分發給平台的各用戶，同時作為平台的代幣也能夠促進平台用戶價值支付以及自由交易上的經濟發展。 BZZ 幣是作為 Swarm 平台上的功能性強且帶有獎勵性質的幣種以及在 Swarm 的平台項目里的運用，給用戶帶來存儲獎勵，以此 以此激勵平台用戶推進 Swarm 平台項目的區塊鏈的發展。

Swarm 項目的介紹

Swarm 的主辦方是以太坊基金會及其內部成員，項目本身是由以太坊的創始人帶領著以太坊各項頂尖部門人員進行開發和研究，它使用了完整的以太坊區塊鏈技術，並具有完善協議，執行起來較為方便。 Swarm 項目的官方團隊發行了 100 萬 BZZ 幣作為測試服獎勵，為先參與到平台項目中來的平台用戶提供獎勵性質的報酬補償。若是投資者想要參與到 Swarm 空投項目中來，可以安裝一個官方團隊提供的 Bee 節點渠道。

⑵ 什麼是DApp

DApp是Decentralized Application的縮寫，中文叫分布式應用/去中心化應用，是基於區塊鏈底層開發平台建立的，比如以太坊和EOS。DApp與底層平台的關系，就好比APP與IOS和Android系統。
一個真正的DApp應用，需要同時滿足以下幾個條件：
1. 應用必須完全開源、自治，且沒有一個實體控制著該應用超51%Token。該應用必須能夠根據用戶的反饋及技術要求進行升級，且應用升級必須由大部分用戶意見達成一致之後方可進行；
2. 應用的數據必須加密後存儲在公開的區塊鏈上；
3. 應用必須擁有Token機制（可用基於相同底層區塊鏈平台的通用代幣或自行發行新幣），礦工或應用維護節點需要得到代幣獎勵；
4. 應用代幣的產生必須依據標準的加密演算法，有價值的節點可以根據該演算法獲取應用的代幣獎勵。
以最著名的以太坊的游戲——CryptoKitties（加密貓）為例，其是一款運行在以太坊的DApp，玩家可以創建、照顧、購買、喂養並出售存儲在以太坊區塊鏈中的以太貓，並且每15分鍾產出一隻小貓，而每隻貓都具有獨一無二的特性，可以通過配對等繁衍新的小貓。
該DApp並不是由一個實體所擁有，而是創建在以太坊上，永不消失，沒有人能夠搶走你的貓，沒有人能夠改變任何一隻貓的樣子（V神就是在暴雪取消術士的"生命虹吸"技能後開始走向以太坊的創立）也沒有一個實體對這個DApp有獨斷的意志。
在這個游戲發行出來之後，每個人都可以參與該游戲，並且由於以太坊的架構，所以參與者的隱私都能夠得到良好的保護。所以在未來，投資DApp有著非常值得想像的升值空間。

⑶ Swarm是什麼

Swarm 去中心化的內容存儲和分發服務，可以將它視為 CDN，通過互聯網在計算機上分發。你可以像運行以太坊節點一樣，運行 Swarm 節點並連接到 Swarm 網路上。Swarm 是以太坊項目官方的一部分，主要是由基金會開發，允許礦池存儲、帶寬和算力資源來支持基於以太坊網路的應用。此外，Swarm 主網預計在2021 年上半年上線，空投將在主網上線前結束。在主網正式上線之前，用戶需要從 qBzz 節點兌現支票來接收代幣。目前行業領先bzz技術商挖畝神算bzz節點出票率極高。每個節點保證1-3張票。

⑷ bzz能漲到10萬一枚嗎

不會的。bzz代幣在私募市場上的價格也有所上漲，一次達到50至80美元。 盡管主要的Swarm網路尚未正式啟動，但測試網路中的BZZ節點數量已超過30，000。
【拓展資料】
BZZ是什麼？
6月14日，Swarm官方消息，去中心化存儲協議Swarm於今日在CoinList上開啟公募。最近Swarm的話題熱度也已經被炒的熱火朝天，甚至超過了BTC跟以太坊近10倍。但是對於很多小白其實還不是很清楚，今天搬磚佬就跟大家簡單介紹Swarm以及其獎勵代幣BZZ。本文對很多剛接觸這個項目的小白，仔細看基本就能理解90%以上了。
其實在2015年的時候，swarm的協議就已經推出來了。Bzz幣就是Swarm的獎勵代幣。Swarm（分布式存儲和分發服務）和smart contract（智能合約），whisper（身份通訊系統）並稱為這個以太仿Web3.0的三大支柱。智能合約相信大家已經很清楚是什麼，現在以太坊非常廣泛的一個應用給一個基礎，因為有了智能合約，所以以太坊才有的生態的一個大發展。whisper是點對點之間加密傳輸。破解的一個加密的一個傳輸的一個協議。那麼swarm解決了什麼問題呢？其實swarm是以太仿上面的一個分布式存儲的一個協議。
眾所周知，以太坊生態的磅礴發展，尤其是 Defi 項目用戶數的日益增多，正面臨著由於 TPS （每秒處理速度）較低導致的擁堵和 Gas 費不斷上漲的問題。由此也引發了一場軍備競賽，以尋求可擴展的、去中心化的、安全的解決方案來降低用戶成本。那麼大量的gas費用在哪兒了呢？用在我們交易時候需燃燒掉了。那麼為什麼會有這么高？因為承載了大量的沒有必要的運算。舉個例子，一個智能合約可能已經運行結束了，可是他還佔用著主網的一些資源。就是要把這些不怎麼常用的這些合約，或者說已經冗餘的數據，歷史的數據，給主網減負存在一個分布式存儲的一個地方。可是還是要達到一個目標：可以快速的可以准確的，高效率的去訪問和調取他。所以可以理解為Swarm就是以太坊這條網路上面的存儲賽道。

⑸ docker裡面swarm是什麼

Swarm 實現分布式數據存儲的概念早在 2015 年初就提出來了。由以太坊創始人 Vitalik Buterin，Gavin Wood 和 Jeffrey Wilcke 推動，Swarm 的協議標簽 bzz 和 shh 都是 Vitalik 創造的。所以 Swarm 可以說是以太坊項目官方的一部分，主要是由以太坊基金會開發，允許礦池存儲、帶寬和算力資源來支持基於以太坊網路的應用。

⑹ 【swarm】Docker跨主機網路：overlay

Docker早期版本中，是不支持跨主機通信網路驅動的，也就是說明如果容器部署在不同的節點上面，只能通過暴露埠到宿主機上，再通過宿主機之間進行通信。隨著docker swarm集群的推廣，docker也有了自家的跨主機通信網路驅動，名叫overlay，overlay網路模型是swarm集群容器間通信的載體，將服務加入到同一個網段上的overlay網路上，服務與服務之間就能夠通信。

使用埠映射 ：直接把容器的服務埠映射到主機上，主機直接通過映射出來的埠通信。

把容器放到主機所在的網段 ：修改 docker 的 ip 分配網段和主機一致，還要修改主機的網路結構。

第三方項目 ：flannel，weave 或者 pipework 等，這些方案一般都是通過 SDN 搭建 overlay 網路達到容器通信的。

 docker swarm， 這是 docker 開發的容器集群管理工具，和 docker API 兼容性很好。

注意： docker overlay 網路可以單獨使用，不是必須和 swarm 綁定在一起的。這里使用 swarm，是因為它的簡單易用，並且更容易說明問題。

overlay網路模型在docker集群節點間的加入了一層虛擬網路，它有獨立的虛擬網段，意味著docker容器發送的內容，會先發送到虛擬子網，再由虛擬子網包裝為宿主機的真實網址進行發送。

這也意味著在overlay網路模型上，docker不會暴露埠給宿主機，所有有關網路的事情都交給overlay去處理了，這樣的好處就是在同一台伺服器，不會引起埠沖突（例如啟動兩個不同的容器，監聽的埠相同），理解這點非常重要。

在早期使用docker進行微服務部署時，你肯定干過將docker容器所在宿主機的ip作為注冊地址，因為如果你將容器內的ip作為注冊地址，其他服務將不可訪問你的服務，只有一條路，就是將宿主機的ip掛在容器內部處理，或者在容器內部添加ip地址環境變數來處理。

當使用docker swarm進行集群服務部署時，這個問題自然也就隨之解決了，當服務已加入到overlay網路中，服務容器內會獲得一個overlay網路的一個地址。

bbo默認會拿eth0的ip作為注冊地址，因此服務只需要將docker容器的ip地址作為注冊地址就行了，只要服務與服務之間在同一個ovelay網段下，就可以進行通信。

提供者和消費者同時部署了2個實例，在相同overlay網段下，相互之間是可通信的。

服務的埠會交給overlay網路去處理。在Overlay網路下，即使該節點並沒有部署指定服務，也會監聽該服務的埠，docker通過這個特性實現了訪問任意一個節點+服務對應埠，就可以訪問服務，而且還具備負載均衡特性。

基於該特性，把服務的網關加入集群後，無需關心網關被分配在哪個節點上，只需要在集群再上一層nginx層配置若干個節點ip+網關服務埠，就可實現雙層負載均衡，即nginx訪問網關時的負載均衡，訪問集群時的負載均衡。

如果此時你正在搭建docker swarm集群，我建議你把網關項目同時加入到集群中，再通過nginx做雙層負載均衡。

編排文件有個不太靈活的地方， 初次使用它來創建swarm集群的人可能會犯一些錯誤：

1.如果你沒有指定網路，它會給你默認創建一個網路，如：stackname_default

2.假如兩個stack棧分別屬於不同的overlay網路，那麼不同stack棧的服務是不可以進行通信的

3.如果你指定一個網路，沒有寫name屬性的，那麼它會在你指定的網路名字前面加個stackname

4.如果該網路已存在，在部署時還會報錯，不會智能將該stack服務地加入該網路中

為防止overlay的網路會跟其它網路有沖突，更嚴謹的做法是自定義overlay網段：

# cat  create_docker_gwbridge.sh

#################################################

#!/bin/bash

docker_bip: "172.17.0.1/16"

gwbridge_subnet: "172.18.0.0/16"

gwbridge_gateway: "172.18.0.1"

docker network create \

  --driver=bridge \

  --subnet="${gwbridge_subnet}" \

  --gateway="${gwbridge_gateway}" \

  --opt "com.docker.network.bridge.name"="docker_gwbridge" \

  --opt "com.docker.network.bridge.enable_icc"="false" \

  --opt "com.docker.network.bridge.enable_ip_masquerade"="true" \

  docker_gwbridge

#################################################

在編排文件的networks上配置defualt屬性，在defualt屬性下面添加external屬性，在其下面填寫剛剛生成的網路的名稱。

這么做的好處是可以靈活地將不同stack服務棧加入到相同網路下，也可避免上面提到的幾個坑。

Swarm有Service的概念。

一個Service是指使用相同鏡像、同時運行的多個容器，多個容器同時一起對外提供服務，多個容器之間負載均衡。每個Service會有一個浮動IP（VIP），各個容器還有自己的物理IP。

創建基於Swarm的Overlay網路，將Service掛載到此網路上。然後Service中的各個容器便可以通過Service名稱（同時也是一個DNS名稱）和IP地址實現網路互通。

同一個Service內，多個容器之間的負載均衡有兩種方案：

由於docker原生的overlay網路使用的是標準的vxlan協議，使用的埠也是標準的vxlan埠（UDP 4789）。

各個雲環境，如阿里雲，騰訊雲，也都是使用的vxlan，所以會有沖突，UDP 4789網路是被佔用的。

目前也沒有找到變通的辦法，docker目前為止還不支持自定義vxlan埠。

docker swarm 集群及多主機overlay網路測試

http://www.huilog.com/?p=1038

docker 跨主機網路：overlay 簡介

https://cizixs.com/2016/06/13/docker-overlay-network

Docker Overlay網路的一些總結

https://objcoding.com/2019/02/21/docker-swarm-networks

Swarm使用原生的overlay網路

https://www.cnblogs.com/bigberg/p/8779302.html

Docker 三劍客之 Docker Swarm（基於 overlay 組網通信）

https://www.cnblogs.com/xishuai/p/docker-swarm-overlay.html

⑺ docker swarm網路模式

docker swarm 網路模式

swarm service的路由辦法通常有兩種，VIP和DSN

這是預設情況設置，當用戶創建service的時候，這個service會被分配一個VIP，然後每一個具體的container都有一個獨立的IP，ingress會負責從VIP到各個container之間的路由。

舉例來說：

並且看到了它的屬性。

創建兩個service：

nslookup查看域名解析：

從這個例子我們可以看到：

我們再進入container看看：

每一個container有兩塊網卡：
eth0: 10.0.1.3 這就是我們前面看到的service container IP地址，是屬於網路my-network的。
eth1: 172.18.0.4，這是另一個網路地址；是誰的呢, 是網路docker_gwbridge。(另外bridge網路使用的是172.17網段)
也就是說每一個container屬於兩個網路，my-network和docker_gwbridge，分別用來service路由，和連接主機網路。

補充一點網卡eth1: 172.18.0.4，對應的網關地址是172.18.0.1，那個這個網關地址172.18.0.1是誰呢，它就是主機網路上的docker_gwbridge，在主機上運行ifconfig可以看到：

bridge網路的網段地址從172.17.X.X/16開始，第一個內置的docker0使用了172.17.X.X，後面每新增一個bridge網路就新增一個網地址，172.18.X.X, 172.19.X.X，。。。

至此兩個bridge網路都比較清楚了。

另外如果發布service的時候指定了主機埠映射，那麼container裡面會有三塊網卡分別屬於：

做一個總結：

發布service的時候：

注意swarm VIP使用的一個限制：

也就是說無法做到同一個client過來的請求保持路由到同一個container去。

適合使用自己的DSN Load-Balance演算法，例如HAProxy。

創建使用DSN輪詢的service。

由參數--endpoint-mode決定。

先看一下兩個container的ip 地址：

兩個contaienr的ip 地址分別是：

再看DSN解析結果：

每次運行ping解析出的IP地址在兩個container之間輪換，也就沒有虛IP概念了，而且swarm自動實現了DSN輪詢的功能。

再看一個nslookup結果：

可見nslookup直接把兩個container的地址都解析出來，說明一個域名(service name)對映有兩個IP地址。對照前面使用VIP的，一個service name只對映一個IP地址，就是VIP地址，而不管具體有多少個container實例。