bridge

JDBC 有四种驱动类型，分别是： JDBC-ODBC 桥（JDBC-ODBC bridge driver plus ODBC driver） 本地 API 驱动（Native-API partly Java driver） 网络协议驱动（JDBC-Net pure Java driver） 本地协议驱动（Native-protocol pure Java driver） 1. JDBC-ODBC 桥 从名称之中就可以知道，这种驱动是 JDBC 在 ODBC 已有的功能上做了一层适配工作，即搭桥（Bridge）。 这种驱动完全依赖 ODBC 的实现，JDBC 只是做了一层封装工作。 JDBC-ODBC 桥最主要的功能，是支持 Java 访问 Access 这种伪关系型数据库。 JDBC-ODBC 桥最大的优点在于：ODBC 的代码在天然的在许多使用数据库的客户端上有，所以这种驱动的安装十分便捷。 但是，JDBC-ODBC 桥有以下两个主要的缺点： 由于对 ODBC 的依赖，导致支持的功能有限，性能不佳，扩展能力很弱。 不适合在并发访问数据库的情况下使用。 在 Java8 的实现中，已经删除了 JDBC-ODBC 桥这种驱动方式。 2. 本地 API 驱动 这种驱动方式，相当于 JDBC 完全使用了 ODBC 的工作方式。 在这种驱动中，JDBC调用转换为对 DBMS 的客户端

问题现象 创建一个nginx pod，并配置了service访问，service后端指向pod。 进入pod中使用service ip 或者service 域名，无法访问。 一开始以为是环境配置或者k8s版本（1.9）的问题，在其他1.13的kubernetes环境下也试了，还是同样的问题。 环境配置 使用的cni插件是flannel，但不是容器化安装，也不是标准化的通过kubelet指定cni plugin（--cni-bin-dir,--cni-conf-dir参数），而是通过dockerd 提供的 -bip 参数指定容器的子网，而这个值是从 /run/flannel/subnet.env (flannel会将获取到的子网写入到该文件) 排查过程 1、首先尝试通过pod ip尝试是否可访问，已验证是可通的。 2、尝试对docker0网桥进行抓包 tcpdump -i docker0 神奇的在这里，再次尝试通过service 访问是居然可以通，发现只要tcpdump断开就不行了。 到这里的时候有点觉得诡异了 在pod内通过service访问的时候网络的流向应该是 pod内部访问service->docker0网桥->宿主机的iptables规则->docker0网桥->pod内部 查阅了相关资料后，看到kubelet有个 --hairpin-mod 参数： 文档说明：

nps内网穿透_实现Windows桌面远程访问 nps 简介 nps 是是一款轻量且功能强大的内网穿透工具，支持 tcp 、 udp 协议的流量转发，能够实现远程访问局域网资源、远程桌面（ Windows ）等功能。除此之外， nps 还支持内网 http 代理、内网 socks5 代理、 p2p 等。支持 Web 图形化管理方式并集成多用户模式。 点击前往 nps 项目网页 准备工作 1. 首先，要安装 nps 必须要有一台静态公网 IP 的服务器，这里，使用的是 阿里云的轻量级应用服务器 (CentOS7.3) ； 2. 内网设备（ Windows10 专业版台式机一台）； 3. 下载对应操作系统最新版本 ( 服务端、客户端 ) 的 nps ，下载地址： https://github.com/cnlh/nps/releases 安装服务端 登录服务器 使用 ssh 工具进行登录。 Windows 系统中可以使用 PuTTY[ 官网下载 | 百度网盘下载 （ yez0 ） ] 或 WinScp[ 官网下载 | 百度网盘下载 （ nyk7 ） ] 进行 ssh 连接，苹果电脑可直接在终端中输入命令进行登录。这里使用的则是 xshell 进行命令终端工具（商业软件） [ 官网下载 | 百度网盘下载 （ 3jk9 ） ] 下载服务端 ssh 连接成功之后

AP、路由、中继、桥接、客户端模式之间的区别 在TP-Link迷你无线路由器上一般有AP(接入点)模式、Router(无线路由)模式、Repeater（中继）模式、Bridge（桥接）模式、 Client（客户端）模式；但很多用户都不清楚这几种模式的之间的区别，下面将对这几种模式进行详细的介绍。 注意：有的型号的TP-Link 迷你无线路由器上只有AP(接入点)模式、Router(无线路由)模式、Repeater（中继）模式这3种模式。 一、AP(接入点)模式 AP(接入点)模式下，只需要把一根可以上网的网线插在192.168.1.253路由器上，无需任何配置就可以上网了；但需要注意这时候 192.168.1.253路由器上的无线网络未加密，建议设置一个无线密码。 在此模式下，该设备相当于一台无线HUB，可实现无线之间、无线到有线、无线到广域网络的访问。最常见的能够提供无线客户端的接入，例如：无线网卡接入等。 具体设置步骤：该产品出厂默认是AP模式，用网线将设备与宽带接口连接，搜索该设备的无线信号进行连接，把无线IP地址改为自动获取即可（一般情况下，宽带路由器提供分配IP地址功能，DHCP）。 多数单纯性无线AP本身不具备路由功能，包括DNS、DHCP、Firewall在内的服务器功能都必须有独立的路由或是计算机来完成。目前大多数的无线AP都支持多用户（30-100台电脑）接入

DOCKER的内置OVERLAY网络 内置跨主机的网络通信一直是Docker备受期待的功能，在1.9版本之前，社区中就已经有许多第三方的工具或方法尝试解决这个问题，例如Macvlan、Pipework、Flannel、Weave等。 虽然这些方案在实现细节上存在很多差异，但其思路无非分为两种： 二层VLAN网络和Overlay网络 简单来说，二层VLAN网络解决跨主机通信的思路是把原先的网络架构改造为互通的大二层网络，通过特定网络设备直接路由，实现容器点到点的之间通信。这种方案在传输效率上比Overlay网络占优，然而它也存在一些固有的问题。 这种方法需要二层网络设备支持，通用性和灵活性不如后者。 由于通常交换机可用的VLAN数量都在4000个左右，这会对容器集群规模造成限制，远远不能满足公有云或大型私有云的部署需求； 大型数据中心部署VLAN，会导致任何一个VLAN的广播数据会在整个数据中心内泛滥，大量消耗网络带宽，带来维护的困难。 相比之下， Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。这样不但能够充分利用成熟的IP路由协议进程数据分发；而且在Overlay技术中采用扩展的隔离标识位数，能够突破VLAN的4000数量限制支持高达16M的用户，并在必要时可将广播流量转化为组播流量，避免广播数据泛滥。

动手实践虚拟网络 - 每天5分钟玩转 OpenStack（10） - CloudMan - 博客园 https://www.cnblogs.com/CloudMan6/p/5296573.html linux中KVM桥接网卡br0 - mergerly的专栏 - CSDN博客 https://blog.csdn.net/mergerly/article/details/38422833 libvirt kvm 虚拟机上网 - Bridge桥接 - 东东东 陈煜东的博客 https://www.chenyudong.com/archives/libvirt-kvm-bridge-network.html linux下brctl配置网桥 - ilinux_one - 博客园 https://www.cnblogs.com/ilinuxer/p/6629323.html How To Setup Bridge (br0) Network on Ubuntu Linux 14.04 and 16.04 LTS - nixCraft https://www.cyberciti.biz/faq/how-to-create-bridge-interface-ubuntu-linux/ Linux 网桥配置命令：brctl - 百度文库 https://wenku.baidu.com/view

首先获取当前环境是ios还是Android var u = navigator.userAgent; var isAndroid = u.indexOf('Android') > -1 || u.indexOf('Adr') > -1; // android终端 var isiOS = !!u.match(/\(i[^;]+;( U;)? CPU.+Mac OS X/); // ios终端 对ios和Android 不同环境下做处理 modal.setupWebViewJavascriptBridge = function (callback) { if (isAndroid) { if (window.WebViewJavascriptBridge) { callback(WebViewJavascriptBridge) } else { document.addEventListener( 'WebViewJavascriptBridgeReady', function (event) { if (window.onWebViewJavascriptBridgeReady) window.onWebViewJavascriptBridgeReady(window.__bridge = WebViewJavascriptBridge); callback

需求: 在原生App里打开webview, 嵌入H5. 在H5中点击某个元素, 触发与native app交互, 又跳回到app中. 同理, 在app中完成某项操作后, 获得某个参数, 根据这个状态刷新页面. 框架: Vue. JavaScript原生的写法已经调通了, 并且与native端的已经联调通过. 所以这里是把它们迁移到Vue框架的写法. 这里要区分iOS系统和Android系统. iOS系统 在这里与iOS开发的同事协商后, 决定使用 WebViewJavascriptBridge 来开发. 前端不需要放入任何js插件. 只需要准备一下这段内容. bridge.js function setupWebViewJavascriptBridge(callback) { if (window.WebViewJavascriptBridge) { return callback(window.WebViewJavascriptBridge) } if (window.WVJBCallbacks) { returnwindow.WVJBCallbacks.push(callback) } window.WVJBCallbacks = [callback] let WVJBIframe = document.createElement('iframe') WVJBIframe

一、简介 在前面两篇文章中已经介绍了Native与JavaScript交互的几种方式，依次是JavaScriptCore框架、UI组件UIWebView、WebKit框架，这几种方式都是苹果公司提供的，除了UIWebView在IOS8之后被苹果淘汰了外，其他基本都能很好地满足开发者的使用。作为一个技术人员，每个人心里都有造轮子的想法，可能有时觉得原生的API使用起来感觉还是不够方便，就对苹果原生的API再进行一层封装，这不WebViewJavascriptBridge这个轮子出来了。WebViewJavascriptBridge的star和fork量还是比较高的，仔细看看WebViewJavascriptBridge类文件相当简单，使用起来也很方便，很受开发者欢迎，它的原理还是利用WKWebView或者UIWebView的相关API，通过bridge桥梁来实现OC与JS互相注册和调用。大致结构图如下： 可以看出：OC调用JS，JS需要注册函数； JS调用OC，OC需要注册函数。 二、分析 了解基本原理结构图后，再来看看框架中的类以及它们的作用定义，如下： WebViewJavascriptBridge_JS ：Javascript环境的Bridge初始化和处理。负责接收OC发给Javascript的消息，并且把Javascript环境的消息发送给OC。

假如 需要设计这样一个业务场景：某公司管理系统登录账户有 销售员工、研发员工 用户，现系统规划 考勤系统、薪资系统 需要针对三种员工做不业务逻辑 。该系统有两个维度方面的变化，一个是员工的变化，即可以是销售员工，可以是研发员工；另一个是业务维度的变化，即考勤系统和薪资系统的变化，针对这一系统设计，我尝试从单继承结构到使用桥接模式来尝试感受桥接模式带来的好处。 1.单继承结构设计 对于 以员工为抽象父类进行设计，类图如下： 简单 的单继承结构，虽然可以满足初期的业务需求，但是假如这时候，需要再添加一类员工：财务员工，这时候就需要在与销售和研发员工同层类中增加一个新的员工类继承抽象员工类，并且在此基础上，还需要再增加两个子类：财务员工考勤、财务员工绩效，增加一类员工，我一共增加了三个新的类。由此可见，单继承结构，会随着业务需求的增长，类的数量剧烈增长，容易引起类爆炸。此外，如果业务类增加，比如增加一个薪资管理系统，那么就需要再每类型员工下再增加一个子类：xx员工薪资管理。再有，如果考勤系统方法发生了变化，那么，就需要去修改每个xx员工考勤系统下的相关方法，这样显然违背了 开放-封闭原则 ，使得维护难度大大提升。 造成单继承结构的该管理系统维护困难的原因，在于业务逻辑和员工之间的 紧耦合 ，单一的分支结构中，既处理业务逻辑，也体现员工分类，显然，这也违背了 单一职能原则