整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
帽在最近刚刚推出了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小时内与您取得联系。
