整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
帽在最近剛剛推出了OpenShift Local 2.0，業內公認openshift是目前最好的k8s發行版之一。我們可以通過OpenShift Local在本地快速體驗一下當下最優秀的容器開發體驗。
Red Hat OpenShift Local（以前稱為 Red Hat CodeReady Containers）允許您在本地計算機上運行 OpenShift 以簡化設置和測試。它在本地模擬云開發環境，并提供開發基于容器的應用程序所需的所有工具。
Red Hat OpenShift Local 和常規的 OpenShift 容器平臺安裝，具有以下顯著差異：
Red Hat OpenShift Local 的OpenShift 容器平臺集群是短暫的，不適用于生產用途。
紅帽 OpenShift Local 沒有支持升級到較新 OpenShift 容器平臺版本的路徑。升級 OpenShift 容器平臺版本可能會導致難以重現的問題。
它使用一個節點，該節點同時充當控制平面和工作節點。
默認情況下，它禁用群集監控operater。這會導致 Web 控制臺的相應部分無法正常工作。因為Red Hat OpenShift Local是設計為臺式機、筆記本電腦上運行的，監控太吃資源了。
OpenShift 容器平臺群集在稱為實例的虛擬機中運行。這可能會導致其他差異，尤其是外部網絡。
紅帽 OpenShift Local 提供的 OpenShift 容器平臺集群還包括以下不可自定義的集群設置:
1使用 *.crc.testing 域。
2用于內部群集通信的地址范圍。
群集使用 172 地址范圍。例如，當代理在同一地址空間中運行時，這可能會導致問題。
從 2.0 版本開始，OpenShift Local 可以處理單獨的machine bundles。紅帽添加了 Podman，以便在出色的單機本地 OpenShift 體驗之上實現纖薄的容器運行時和最少的下載。
OpenShift Local 2.0 包括2個預先的設置模式。如圖所示，您可以選擇默認的 OpenShift bundles，或者如果要從更集中的容器運行時開始，可以選擇 Podman 選項。這意味著您可以從專注于單個容器（或僅幾個）開始，并使用更小的開發設置。然后，您可以在準備就緒時通過啟用 OpenShift bundles來轉向編排容器。（很明顯，這是對著docker desktop來的）。
OpenShift Local 2.0 中可用的選項
如果您的機器沒有足夠的性能本地運行Podman或OpenShift，您可以嘗試其他替代方案，例如紅帽托管的Red Hat OpenShift開發人員沙盒https://developers.redhat.com/developer-sandbox（無限次免費申請，30天有效期，但是由于國內屏蔽海外短信，需要發郵件激活。）
在以前的版本中，命令行工具的下載中包含安裝了OpenShift的虛擬機的捆綁包，這增加了下載量，但改善了啟動體驗。現在，捆綁包已完全解耦，但在首次創建計算機時會延遲下載。這允許較小的捆綁包，例如Podman的捆綁包，以及未來的各種替代捆綁包。
請務必為 GitHub 項目頁面（https://github.com/code-ready/crc）添加書簽，并返回查看有關可用捆綁包的更多更新，以及對創建自己的捆綁包的支持。
紅帽希望提供一個即將推出的版本，該版本與Apple向M1（ARM）架構的遷移兼容。紅帽的目標是通過采用 Podman 上游進行容器運行時開發，然后擴展到 MicroShift，當然還有對 OpenShift 的持續支持，為開發人員提供無縫體驗。紅帽還希望繼續與最終用戶使用桌面容器解決方案提高工作效率所需的內容保持一致。
請留意上游與Podman周圍努力的更多一致性。在這里，紅帽將尋求調整虛擬化技術、安裝和用戶界面組件，以提供上游容器化技術的良好體驗。
準備好試一試了嗎？請訪問紅帽的紅帽 OpenShift 本地產品頁面，獲取下載鏈接和更多詳細信息，立即開始使用！
對于一般的開發者來說，podman模式直接對標傳統的docker desktop。輕量級的部署幾個容器用podman模式已經足夠。而openshift模式則比docker desktop自帶的kubernetes模式強得太多太多了。如果你的電腦有24G內存以上的話，推薦試試
下面是windows部署步驟：
先決條件
OpenShift Local 2.0 需要以下最少的系統資源來運行 Red Hat OpenShift：
4 個虛擬 CPU （vCPU）
9 GB 內存
35 GB 存儲空間
您還需要主機操作系統的本機虛擬機管理程序。OpenShift Local 2.0目前支持libvirt for Linux，HyperKit for macOS和Hyper-V for Windows。
而對于podman選項，需求是
2個虛擬 CPU （vCPU）
2GB 內存
在 Microsoft Windows 上，Red Hat OpenShift Local 需要 Windows 10 Fall Creators Update（版本 1709）或更高版本。Red Hat OpenShift Local 不適用于早期版本的 Microsoft Windows。不支持 Microsoft Windows 10 Home Edition。
一、注冊紅帽開發者賬戶
https://developers.redhat.com/about
如果有紅帽賬戶，可以直接登錄，然后再點擊加入，沒有紅帽賬戶的話，點擊join now后會自動進入紅帽賬戶創建流程。
二、安裝OpenShift Local 2.0流程（Windows）
首先訪問https://cloud.redhat.com/openshift/create/local
安裝步驟請參考文檔，首先下載OpenShift Local 2.0，然后安裝
在這里我們選擇openshift。
然后粘貼上面的pull secret，用來從紅帽倉庫拉鏡像。此文件對于OKD也有效。
會自動安裝啟用hyper-v。對電腦性能會有一定影響（約5-8%）。我們后期可以編輯windows啟動選項，讓windows以禁用hyper-v模式啟動。
由于windows啟用hyper-v需要重啟，繼續配置可能會報錯。（我是又重啟了一次電腦，圖形下配置成功）
我們也可在管理員命令下，用crc setup 配置環境，會比較清楚。
2.1 openshift 模式
Red Hat OpenShift Local重大改進其中之一是系統托盤已重寫為Electron應用程序，以允許跨不同操作系統的一致性和功能。這提供了桌面系統托盤訪問，因此您可以輕松獲取計算機運行的狀態、啟動和停止、刪除、跟蹤日志、打開 OpenShift 控制臺、更改配置以及獲取版本信息。
運行之后可以方便的copy登錄命令
我們同樣可以在這里配置openshift的內存和存儲
在hyper-v管理器里可以看到，至少是16G內存才能讓openshift跑的比較順。而要是跑程序的話，24G內存應該是及格線。（我原來16G內存的老mac確實是跑不動了）
我們可以在普通命令行 輸入
crc console --credentials 得到密碼
同樣，在窗口了敲
crc oc-env | Invoke-Expression
得到openshift command line interface的環境，而鍵入下面命令是在命令行以開發者身份登錄openshift
oc login -u developer https://api.crc.testing:6443
通過web瀏覽器我們可以登錄到openshift local
我們可以通過切換到開發者視圖，新建一個項目，也就是k8s里的namespace
新建項目后，我們可以看到紅帽為我們提供的多種部署容器的方式，以及示例、教程。
另外切換到管理員視圖，我們還可以看到紅帽和第三方廠商及社區提供的一些Operators，通過這些Operator，我們可以輕松的部署、管理各種中間件和存儲，安全等工具。
2.2 podman 模式
而我們使用podman模式，實際上體驗和dockers desktop類似
我們創建好環境后，在托盤菜單上點擊open Console
我們可以看到如下界面
我們可以通過鏡像以圖形化的方式創建容器
也可以以熟悉的docker命令的方式創建、管理容器，只不過命令從docker變成了podman。
綜上您可以看到，如果您想簡單的體驗容器開發，可以使用podman模式。對系統資源占用也小。可以繼續使用熟悉的docker 命令。而當您的程序使用的容器增加，或者需要開發微服務，需要使用k8s來進行容器編排時，那么openshift local模式可以幫助您更快的建立起本地開發環境，另外openshift是兼容kubectl命令的，您只需要在openshift local復制出密鑰，即可通過熟悉的kubectl來使用命令行管理openshift。
后面是紅帽基于openshift的一個入門教程。主要內容是在openshift部署一個基于JAVA的前后端程序。由于是本機部署。部分涉及拉取github代碼的步驟可能會失敗。僅供參考
http://wangmt2000.gitee.io/openshift-starter-guides/rhs-openshift-starter-guides/4.8/index.html
者：小不點啊
來源：www.cnblogs.com/leeSmall/p/9356535.html
一、Nginx Rewrite 規則
Rewrite規則含義就是某個URL重寫成特定的URL（類似于Redirect），從某種意義上說為了美觀或者對搜索引擎友好，提高收錄量及排名等。
語法：
rewrite <regex> <replacement> [flag]
關鍵字 || 正則 || 替代內容 || flag標記
Rewrite規則的flag標記主要有以下幾種：
last和break用來實現URL重寫，瀏覽器地址欄URL地址不變
a) 例如用戶訪問www.dbspread.com，想直接跳轉到網站下面的某個頁面，www.dbspread.com/new.index.html如何來實現呢？我們可以使用Nginx Rewrite 來實現這個需求，具體如下：在server中加入如下語句即可：
效果圖如下：
rewrite ^/$ http://www.dbspread.com/new.index.html permanent;
對應如下語法：
rewrite <regex> <replacement> [flag];
關鍵字 正則 替代內容 flag標記正則表達式說明：
*代表前面0或更多個字符 +代表前面1或更多個字符
？代表前面0或1個字符 ^代表字符串的開始位置
$代表字符串結束的位置 。為通配符，代表任何字符b)例如多個域名跳轉到同一個域名，nginx rewrite規則寫法如下：
格式：
rewrite <regex> <replacement> [flag];
關鍵字 || 正則 || 替代內容 || flag標記
說明：
比如http://www.dbspread.com/download/av123.rmvb 這個視頻下載地址被其他網站引用，比如在www.test.com的index.html引用download/av123.rmvb就叫盜鏈，我們要禁止這種引用就叫做防盜鏈
在nginx的nginx.conf的server里面配置如下代碼
三、Nginx 動靜分離
Nginx動靜分離是讓動態網站里的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以后，我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路。
1). WEB項目開發時要注意，將靜態資源盡量放在一個static文件夾2). 將static靜態資源文件夾放到Nginx可以取到的位置3). 頁面要建立全局變量路徑，方便修改路徑4). 修改nginx.conf的location， 匹配靜態資源請求
body {
margin: 10px 20px;
text-align: center;
font-family: Arial, sans-serif;
background-color: red;
}4.4 在nginx的nginx.conf中server節點新增靜態資源分離的配置
對于Nginx基礎配置，推薦之前的：后端實踐：Nginx日志配置（超詳細）
4.5 訪問頁面查看效果
Keepalived軟件起初是專為LVS負載均衡軟件設計的，用來管理并監控LVS集群系統中各個服務節點的狀態，后來又加入了可以實現高可用的VRRP (Virtual Router Redundancy Protocol ,虛擬路由器冗余協議）功能。因此，Keepalived除了能夠管理LVS軟件外，還可以作為其他服務（例如：Nginx、Haproxy、MySQL等）的高可用解決方案軟件
管理LVS負載均衡軟件實現LVS集群節點的健康檢查作為系統網絡服務的高可用性（failover）
Keepalived高可用服務之間的故障切換轉移，是通過 VRRP 來實現的。在 Keepalived服務正常工作時，主 Master節點會不斷地向備節點發送（多播的方式）心跳消息，用以告訴備Backup節點自己還活著，當主 Master節點發生故障時，就無法發送心跳消息，備節點也就因此無法繼續檢測到來自主 Master節點的心跳了，于是調用自身的接管程序，接管主Master節點的 IP資源及服務。而當主 Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。
說明：keepalived的主從切換和redis的主從切換是不一樣的，keepalived的主節點掛了以后，從節點變為主節點，之前的主節點恢復以后繼續做主節點。redis的主節點掛了以后，重新恢復以后變為從節點
說明：
虛擬ip(VIP):192.168.152.200，對外提供服務的ip，也可稱作浮動ip192.168.152.130：nginx + keepalived master 主192.168.152.129：nginx + keepalived backup 從192.168.152.129：tomcat-8080192.168.152.129：tomcat-8081
環境準備：
centos6、jdk
虛擬ip(VIP):192.168.152.200，對外提供服務的ip，也可稱作浮動ip
192.168.152.130：nginx + keepalived master 主
192.168.152.129：nginx + keepalived backup 從
192.168.152.129：tomcat-8080
192.168.152.129：tomcat-8081
nginx和tomcat的環境準備請查看我的前一篇關于nginx的文章
注：192.168.152.129（keepalived從節點） 與 192.168.152.130（keepalived主節點）先安裝好nginx + keepalived
下載壓縮包：
wget www.keepalived.org/software/keepalived-1.3.5.tar.gz
解壓縮：
tar -zxvf keepalived-1.3.5.tar.gz
進入解壓縮以后的文件目錄：
cd keepalived-1.3.5
編譯安裝：./configure --prefix=/usr/local/keepalived系統提示警告 *** WARNING - this build will not support IPVS with IPv6. Please install libnl/libnl-3 dev libraries to support IPv6 with IPVS.yum -y install libnl libnl-devel再次執行./configure --prefix=/usr/local/keepalived系統提示錯誤 configure: error: libnfnetlink headers missingyum install -y libnfnetlink-devel再次執行./configure --prefix=/usr/local/keepalived
make && make install
到此keepalived安裝完成，但是接下來還有最關鍵的一步，如果這一步沒有做后面啟動keepalived的時候會報找不到配置文件的錯誤
Configuration file '/etc/keepalived/keepalived.conf' is not a regular non-executable file
安裝完成后，進入安裝目錄的etc目錄下，將keepalived相應的配置文件拷貝到系統相應的目錄當中。keepalived啟動時會從/etc/keepalived目錄下查找keepalived.conf配置文件
mkdir /etc/keepalived
cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived
5.3 修改keepalived從節點192.168.152.129的/etc/keepalived/keepalived.conf配置文件
5.4 檢查nginx是否啟動的shell腳本
/usr/local/src/check_nginx_pid.sh
#!/bin/bash
#檢測nginx是否啟動了
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then #如果nginx沒有啟動就啟動nginx
/usr/local/nginx/sbin/nginx #重啟nginx
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then #nginx重啟失敗，則停掉keepalived服務，進行VIP轉移
killall keepalived
fi
fi5.5 192.168.152.130（keepalived主節點）和 192.168.152.129（keepalived從節點）的nginx的配置文件nginx.conf
user root root; #使用什么用戶啟動NGINX 在運行時使用哪個用戶哪個組
worker_processes 4; #啟動進程數，一般是1或8個，根據你的電腦CPU數，一般8個
worker_cpu_affinity 00000001 00000010 00000100 00001000; #CPU邏輯數——把每個進程分別綁在CPU上面，為每個進程分配一個CPU
#pid /usr/local/nginx/logs/nginx.pid
worker_rlimit_nofile 102400; #一個進程打開的最大文件數目，與NGINX并發連接有關系
#工作模式及連接數上限
events
{
use epoll; #多路復用IO 基于LINUX2.6以上內核，可以大大提高NGINX的性能 uname -a查看內核版本號
worker_connections 102400; #單個worker process最大連接數,其中NGINX最大連接數＝連接數*進程數,一般1GB內存的機器上可以打開的最大數大約是10萬左右
multi_accept on; #盡可能多的接受請求，默認是關閉狀態
}
#處理http請求的一個應用配置段
http
{
#引用mime.types,這個類型定義了很多，當web服務器收到靜態的資源文件請求時，依據請求文件的后綴名在服務器的MIME配置文件中找到對應的MIME #Type，根據MIMETYPE設置并response響應類型（Content-type）
include mime.types;
default_type application/octet-stream; #定義的數據流，有的時候默認類型可以指定為text,這跟我們的網頁發布還是資源下載是有關系的
fastcgi_intercept_errors on; #表示接收fastcgi輸出的http 1.0 response code
charset utf-8;
server_names_hash_bucket_size 128; #保存服務器名字的hash表
#用來緩存請求頭信息的，容量4K，如果header頭信息請求超過了，nginx會直接返回400錯誤，先根據client_header_buffer_size配置的值分配一個buffer，如果##分配的buffer無法容納request_line/request_header，那么就會##再次根據large_client_header_buffers配置的參數分配large_buffer，如果large_buffer還是無#法容納，那么就會返回414（處理request_line）/400（處理request_header）錯誤。
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
client_max_body_size 300m; #允許客戶端請求的最大單文件字節數 上傳文件時根據需求設置這個參數
#指定NGINX是否調用這個函數來輸出文件，對于普通的文件我們必須設置為ON，如果NGINX專門做為一個下載端的話可以關掉，好處是降低磁盤與網絡的IO處理數及#系統的UPTIME
sendfile on;
#autoindex on;開啟目錄列表訪問，適合下載服務器
tcp_nopush on; #防止網絡阻塞
#非常重要，根據實際情況設置值，超時時間，客戶端到服務端的連接持續有效時間，60秒內可避免重新建立連接，時間也不能設太長，太長的話，若請求數10000##，都占用連接會把服務托死
keepalive_timeout 60;
tcp_nodelay on; #提高數據的實時響應性
client_body_buffer_size 512k; #緩沖區代理緩沖用戶端請求的最大字節數（請求多）
proxy_connect_timeout 5; #nginx跟后端服務器連接超時時間（代理連接超時）
proxy_read_timeout 60; #連接成功后，后端服務器響應時間(代理接收超時)
proxy_send_timeout 5; #后端服務器數據回傳時間(代理發送超時)
proxy_buffer_size 16k; #設置代理服務器（nginx）保存用戶頭信息的緩沖區大小
proxy_buffers 4 64k; #proxy_buffers緩沖區，網頁平均在32k以下的話，這樣設置
proxy_busy_buffers_size 128k; #高負荷下緩沖大小
proxy_temp_file_write_size 128k; #設定緩存文件夾大小，大于這個值，將從upstream服務器傳
gzip on; #NGINX可以壓縮靜態資源，比如我的靜態資源有10M，壓縮后只有2M，那么瀏覽器下載的就少了
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2; #壓縮級別大小,最小1,最大9.值越小,壓縮后比例越小,CPU處理更快,為1時,原10M壓縮完后8M,但設為9時,壓縮完可能只有2M了。一般設置為2
gzip_types text/plain application/x-javascript text/css application/xml; #壓縮類型:text,js css xml 都會被壓縮
gzip_vary on; #作用是在http響應中增加一行目的是改變反向代理服務器的緩存策略
#日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' #ip 遠程用戶 當地時間 請求URL
'$status $body_bytes_sent "$http_referer" ' #狀態 發送的大小 響應的頭
'"$http_user_agent" $request_time'; #客戶端使用的瀏覽器 頁面響應的時間
#動態轉發
upstream web1 {
#每個請求按訪問ip的hash結果分配,這樣每個訪客固定訪問一個后端服務器,可以解決session的問題。配置了ip_hash就沒有負載均衡的效果了，每次訪問的都是同一個tomcat
#ip_hash;
#轉發的后端的tomcat服務器,weight表示轉發的權重,越大轉發的次數越多,機器性能不一樣配置的weight值不一樣
server 192.168.152.129:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.152.129:8081 weight=1 max_fails=2 fail_timeout=30s;
}
upstream web2 {
server 192.168.152.129:8090 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.152.129:8091 weight=1 max_fails=2 fail_timeout=30s;
}
server {
listen 80; #監聽80端口
server_name www.dbspread.com; #域名
#rewrite規則
index index.jsp index.html index.htm;
root /usr/local/nginx/html; #定義服務器的默認網站根目錄位置
#重定向
if ($host != 'www.dbspread.com' ){
rewrite ^/(.*)$ http://www.dbspread.com/$1 permanent;
}
#防盜鏈
location ~* \.(rmvb|jpg|png|swf|flv)$ { #rmvb|jpg|png|swf|flv表示對rmvb|jpg|png|swf|flv后綴的文件實行防盜鏈
valid_referers none blocked www.dbspread.com; #表示對www.dbspread.com此域名開通白名單，比如在www.test.com的index.html引用download/av123.rmvb,無效
root html/b;
if ($invalid_referer) { #如果請求不是從www.dbspread.com白名單發出來的請求，直接重定向到403.html這個頁面或者返回403
#rewrite ^/ http://www.dbspread.com/403.html;
return 403;
}
}
#監聽完成以后通過斜桿(/)攔截請求轉發到后端的tomcat服務器
location /
{
#如果后端的服務器返回502、504、執行超時等錯誤，自動將請求轉發到upstream負載均衡池中的另一臺服務器，實現故障轉移。
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_set_header Host $host; #獲取客戶端的主機名存到變量Host里面,從而讓tomcat取到客戶端機器的信息
proxy_set_header X-Real-IP $remote_addr; #獲取客戶端的主機名存到變量X-Real-IP里面,從而讓tomcat取到客戶端機器的信息
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#rewrite ^/$ http://www.dbspread.com/new.index.html permanent;#用戶訪問www.dbspread.com，想直接跳轉到網站下面的某個頁面:www.dbspread.com/new.index.html
proxy_pass http://web1; #跳轉到對應的應用web1
}
# location ~ .*\.(php|jsp|cgi|shtml)?$ #動態分離 ~匹配 以.*結尾（以PHP JSP結尾走這段）
# {
# proxy_set_header Host $host;
# proxy_set_header X-Real-IP $remote_addr;
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_pass http://jvm_web2;
# }
#靜態分離 ~匹配 以.*結尾（以html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css結尾走這段），當然不是越久越好，如果有10000個用戶在線，都保存幾個月，系統托跨
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
{
root /var/local/static; #靜態資源存放在nginx的安裝機器上
#proxy_pass http://www.static.com; #靜態資源也可存放在遠程服務器上
expires 30d;
}
#日志級別有[debug|info|notice|warn|error|crit] error_log 級別分為 debug, info, notice, warn, error, crit 默認為crit, 生產環境用error
#crit 記錄的日志最少,而debug記錄的日志最多
access_log /usr/local/logs/web2/access.log main;
error_log /usr/local/logs/web2/error.log crit;
}
}到這一步環境準備已完成，相關的配置也修改完成，下面我們來查看效果
5.6 配置hosts域名映射
192.168.152.200 www.dbspread.com注意：這里192.168.152.200 是keepalived里面virtual_ipaddress配置的虛擬ip
virtual_ipaddress {
192.168.152.200 # 定義虛擬ip(VIP)，可多設，每行一個
}到這一步環境準備已完成，相關的配置也修改完成，下面我們來查看效果
5.7 分別啟動192.168.152.129的兩個tomcat
5.8 分別啟動192.168.152.130（keepalived主節點）和
192.168.152.129（keepalived從節點）的keepalived的
啟動命令：
/usr/local/keepalived/sbin/keepalived
可以看到keepalived和nginx都啟動了
在瀏覽器輸入www.dpspread.com域名訪問
可以看到從節點變為主節點了
在瀏覽器輸入地址www.dpspread.com訪問，可以看到訪問正常
可以看到主節點重新啟動以后變為主節點了
之前變為主節點的從節點又變回從節點了
果說論壇近期最火的設備，PNA家的nBridge+無疑會是眾人的首選，nBridge+「事件」最初原因何起九段也沒有詳細爬文，但最終的結果對于發燒友來說一定是件好事。也正是因為這一事件，九段對于nBridge+這臺設備突然有了濃厚的興趣，加之手中正好有dCS bridge等等幾臺同類型產品，遂于近日入手一臺，對比把玩多有感悟，利用年末小閑暇亂寫幾句。
不知道喜歡音樂的你是從何時開始聆聽串流音樂的？在九段身邊的很多「老」燒友現在還是不聽的，因為他們覺得串流太復雜總是弄不清細節，還有「香爐」太多，不能很好的把控最終的聲音。
但九段自己是聽串流音樂的，而且聽了好多年。早些年，串流音樂還不盛行，數字播放器仍停留在簡單的外掛硬盤或抓軌再播放等簡單功能上，九段在那個時候就開始接觸數字播放產品。后來，九段購入了iPhone 4手機，我開始透過Apple Airport Express做無線播放，還記得設定完成后，第一次透過手機選曲、播放，那種感覺真的好棒，直至今天依然記憶猶新。
不過，那個時候九段與身邊的「老」音響迷們一樣，認為這種數字串流播放根本就是花拳繡腿，與實體唱片相比根本不在一個量級。因為之后的好多年時間，我在自家系統上依然堅持聆聽實體唱盤，而串流播放只是一個點綴。
直到一日，Apple推出了Apple Music，偶然的機會九段訂閱了一年的服務，這才算是一入「泥潭」再無回身可能。雖然當時的Apple Music國區資源還不夠豐富，好在它的資料庫成長速度驚人，大廠名篇基本都有涉獵，實在找不到的還可以換到美區去緩存下來。對于一名傳統唱盤用家，Apple Music的全新使用感受真的太具吸引力。不足之處，Apple Music的資源多為256kbps的AAC，音質非常欠奉，隨身路上聆聽是可以接受的，但回到家中安靜聆聽卻是很難讓人「安坐」。
很快，一類叫做Roon Ready的器材出現了，配合Roon軟件使用，這簡直就是為音樂發燒友量身定做的產品，從此一用成癮，就此幾乎徹底拋棄iRiver與iTunes。利用Roon的整合功能，九段輕松的把Tidal、Qubuz的服務加入Roon。即使在一些并不高班的Roon Ready設備下，Tidal、Qubuz上的這些音樂資源，哪怕是普通的16bit/44.1kHz的音樂也有著非常優異的聽感。當然，最讓人興奮的還是你一下擁有了成千上萬首頂級品質的音樂曲庫，而且它還在不斷的更新中。這種全新的、超越以往實體唱片可以給予的美妙感受也是促使九段開始研究并入手高級「Bridge」的最大動力。
拿今天要講的PNA nBridge+為例，簡單來說它就是一部連接音樂與硬件DAC解碼的「橋梁」。嚴格來說，這座「橋梁」是專門為數字音樂串流來服務的，包括本地數字音樂以及網路上的串流資源。比如，PNA nBridge+內置了Roon、UPnP以及HQ Player三種主流APP來實現對網上及網內數字音樂的管理、傳輸與播放。
我們只需要將PNA nBridge+插上網線聯入家中的局域網，通過手機瀏覽器APP輸入pna.local網址就可以進入機器的設置界面，然后整個機器的所有操作均可以在這個「簡單」的界面里完成。具體的操作與控制方式我就不在此做過多介紹了，如果有興趣了解的小伙伴可以參考一下耳機俱樂部小白版主與長弓版主的使用分享（http://www.headphoneclub.com/thread-729073-1-5.html；http://www.headphoneclub.com/thread-732691-1-5.html）。
做完以上，我們就可以把PNA nBridge+后面通過USB、RCA同軸、AES甚至I2S等數字信號線連接到自己的DAC解碼器上開始正常使用了。自此你已經可以完全擺脫實體唱片的束縛，不再需要費心調試播放參數，更換碟片，購置唱片架。。。。。。坐在自己的系統前，掏出手機，輕輕點動手指，美妙的音符就飄進了耳中。
九段在使用PNA nBridge+的這段時間里發現其在設計上有一些高明之處，首先是軟件方面。PNA的控制是由登陸自己內置的網頁來實現的，不同于一些品牌產品必須安裝獨立的控制APP，不管是iOS用戶還是Android用戶，都無需擔心適配。同時，不管是用Roon集成Tidal、Qubuz來聆聽網路串流音樂，還是使用各種免費UPnP軟件來播放局域網內電腦、NAS上的本地音樂，甚至直接把硬盤/U盤插入PNA nBridge+直接播放，PNA nBridge+在軟件上都是全面支持的。
然后是硬件方面，這也是PNA最大的優勢部分。雖然PNA是一家新晉品牌，但它的研發團隊卻在業內擁有相當的名氣。PNA的核心設計師脫身于華為網絡設備研發部門，同時也是港灣科技的開創團隊成員之一。港灣科技是一家脫胎于華為的創業公司，曾經創造了中國網絡公司三年銷售額超過十億元人民幣的奇跡。這家公司當年掌控了路由器核心芯片自主研發能力，因為成長速度過快甚至嚴重威脅到了業界龍頭華為的江湖地位，所以其在創立第六個年頭被華為動用100億現金「殺死」。以上，這些硬實力在PNA nBridge+的設計上體現的淋漓盡致。
比如大家最為關心的信號隔離方面，PNA nBridge+使用內置的6節松下18650電池采用3并2串的方式為機器的內網部分供電，而線性電源則負責機器的外網線路供電及電池充電，做到了最大限度的隔離內外網路的串擾以及市電雜訊對于機器內部信號的影響。同時，機器內部采用獨立模塊安裝，數字、網路、供電以及模擬部分全部采用獨立位置封閉安裝，有效避免了各系統間的信號二次干擾。除此，PNA還使用了多層電路板來優化傳輸線路間的干擾問題，并通過取消無線功能、顯示器以及小型繼電器等明顯擁有干擾的功能與配件的使用，從而讓PNA nBridge+的信號純度得到了最佳的優化，這么徹底的信號隔離設計在業界是罕見的。
還有一點設計非常方便，也是九段最愛的功能，那就是PNA nBridge+支持I2S數字輸出。而熟悉I2S數字輸出的小伙伴一定非常清楚這種同步前端ARM，高質量傳輸的源頭數字信號質量是明顯好過AES/EBU等數字接口的，但它也有一個非常「惱人」的問題就是I2S接口接線定義并不統一，每一家品牌都有所不同，所以以往這種接口多只能用于統一品牌的兩臺數字設備間的傳輸，比如dCS、Accuphase、Esoteric等等。但是，PNA nBridge+這次通過軟硬件配合實現了I2S接口定義的靈活設置，用戶通過網頁控制界面可以方便的把PNA nBridge+的I2S接口定義為Gustard、PS Audio、W4S、Holo Audio、L.K.S、Rockna、Denafrip等等主流DAC廠商標準，從而使這些DAC都可以享受PNA nBridge+的I2S高質量數字信號。
九段多年來把玩過不下十臺數字音源，各種檔次類型的產品都有，它們之間最大的差異就是聲音的「模擬」味。這里的「模擬」味與「數字」聲相對，并非指老LP、電子管機器發出的那種信噪比不高的聲音，而是指沒有「鋒利」高頻毛刺、清瘦聲音骨架以及干薄低頻的聲音。尤其是低頻部分，有重量且兼顧解析的低音被老燒友稱為「權威」的低頻，九段一直認為這是判別一臺音響設備檔次高與低的最直觀標準。這次，PNA nBridge+的表現如何呢？
九段以Alice Sara Ott彈奏、Thomas Hengelbrock指揮慕尼黑愛樂的老柴第一鋼琴協奏曲為例。第一樂章開始，作曲家寫下一個辨識度極高的樂曲類型，由法國號起首的四個下行音符響起，然后接上一聲樂團齊奏，繼而是鋼琴以固定三組和弦的上行加入，就此揭開樂曲序幕。這個雄壯的序幕，PNA nBridge+給予音樂十足的勁力，輕松超過九段的NAIM CDX2 CD唱機的聽感。現場的那種沖擊感與恢弘都是非常出眾的，聽鋼琴一直向下的獨奏，重壓和弦下琴弦震動的質地，這些畫面實在寫實，而且和弦帶有十足的重量感與權威感，說服力充足。Alice雖然是一介女子，但彈到這里絲毫不讓須眉，那勁道委實攝人。第二主題情緒漸緩，Alice指下的鋼琴更佳柔美，不僅跟樂團對話，自己雙手也以不同聲部對話著，音樂的層次就這樣展開。木管悠然的唱和，弦樂緩緩輕語，這里的樂器質感非常突出。PNA nBridge+不僅能發揮前面雄渾開朗的齊唱，還能詮釋這里委婉而柔美的氣質。而且，不管是鋼琴張力十足地以和弦直探低音，或是低音弦樂用以襯底的弄弦聲浪，聽起來皆是實實在在，很有存在感的。
再舉一張人聲演唱為例，Sarah Vaughan在1985年的巴黎現場演唱會。「Wave」一曲中，Sarah的聲腔多變，音色多端，加上她善用拉長音來制造尾音的多重變化，加上音量起伏，單是她的歌聲，就夠精彩的了。三重奏輕柔地相伴，大多時候，貝斯、鼓組和鋼琴都在扮演節奏的角色，但鋼琴時而會跳出來轉成合音或對唱。PNA nBridge+讓Sarah的歌聲聽起來特別有血有肉，卻不因添附的厚度和溫度以致失去活潑性，反倒因此讓我們更聚焦在Sarah的歌聲上。PNA nBridge+讓她的歌聲從一個漆黑的舞臺上，以探照燈照射出天后的身影。那時候Sarah已經年過六旬，但歌聲卻顯出成熟老練，那些轉音、抖音、滑音的技巧都堪稱完美，歌唱之間，顯出十足的自信。聽完「Wave」之后，再去聽全然清唱的「Summertime」，就能了解那個舞臺和探照燈的比喻了，也就能認識到年逾花甲的天后那讓后輩汗顏的歌唱實力。
PNA nBridge+的聲音有別于大部分九段聽過的數字音源產品，它擁有非常可觀的素質，但它對于素質的表達并不是傳統數字音源常用的方式，PNA nBridge+不刺激不追求極限更沒有一耳朵越級PK的能力，但它在播放高水準數字音樂時給出了明顯好過同價位傳統CD轉盤的素質，同時還保留了優秀實體唱片的聽感，一種「實在」、「真實」的聽感。尤其是在中低頻部分完全聽不出任何的「數字」味道，我想這也是很多「老燒友」抵觸數字音源的最主要原因。
對于這臺最新版本的PNA nBridge+，九段準備長期留用下去，如果正好你也準備選購一臺類似的頂級數字音源，不妨可以了解試聽下這臺機器，我想它一定可以改變你對于數字音源的一些認知。
我是九段，咱們下期再見！「完」
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
