relocation error: /usr/lib64/libssl.so.10: symbol private_ossl_minimum_dh_bits, version libcrypto.so
果断快速解决办法,从相同版本系统复制文件:
/usr/lib64/libssl.so.1.0.1e
覆盖马上恢复
relocation error: /usr/lib64/libssl.so.10: symbol private_ossl_minimum_dh_bits, version libcrypto.so
果断快速解决办法,从相同版本系统复制文件:
/usr/lib64/libssl.so.1.0.1e
覆盖马上恢复
cento6 下载源码升级curl到7.62.0
由于业务需要,服务器上的curl 版本太老了,有漏洞,于是抽点时间升级最新版本,确保服务器间通信安全,然后网上看了些教程,发现各不相同,最后找到一个最简单,最方便的方法,分享给大家。
wget https://curl.haxx.se/download/curl-7.62.0.tar.gz
tar -zxvf curl-7.62.0.tar.gz
cd curl-7.62.0
./configure
make && make install
curl -V
为站点和服务获得HTTP / 2的性能和安全性优势意味着进行体系结构更改,因为它颠覆了用于提高网站性能的分片等原则; 这可能就是为什么只有大约35%的网站目前使用HTTP / 2。
HTTP / 3加倍,提供非常相似的功能,但用UDP替换TCP。这一次可能需要对网络基础设施进行更根本的改变,以便利用比较差的连接和移动网络更好的性能,但对于大多数开发人员来说,这种改变将是透明的。
HTTP / 3是该协议的第三个主要版本,它包括TLS 1.3和一种称为QUIC(Quick UDP Internet Connection)的新传输协议; 根据最初由Google设计的2013协议,现在有多个贡献者和公司通过互联网工程任务组(IETF)参与其中。
放弃HTTP一直用于UDP的TCP连接并不像看起来那么奇怪。U有时会扩展为“不可靠”而不是用户数据报协议,因为它不保证消息传递或数据包顺序。但是对于今天的网络,这实际上是一个提高HTTP / 2引入的多路复用连接性能的机会。“凭借HTTP / 3,我们将在同一个旧的不可靠互联网之上构建一个新的可靠协议,” Cloudflare首席技术官John Graham-Cumming告诉New Stack。
HTTP / 2通过在同一连接上发送多个HTTP请求,允许应用程序同时处理请求,从而更好地利用网络带宽。但只有在网络运行良好时才能实现这些收益。“你可以最大限度地提高吞吐量和带宽,因为TCP可以达到它可以达到的最大速度,并且所有并行连接都能以最快的速度运行,”Graham-Cumming说。
这很好,直到网络连接出现打嗝,例如网络拥塞或移动网络上从一个小区移动到另一个小区并且数据包丢失。“TCP保证发送数据包的顺序是应用程序接收的顺序 – 所以如果你错过了,那么一切都必须停止,直到特定数据包被重新传输。如果将多个请求复用到单个TCP连接上,则所有这些请求都必须停止并等待,即使丢失的数据包可能只影响其中一个。
Graham-Cumming解释说,这种“线路阻塞问题”是TCP固有的问题,使用UDP通过允许应用程序控制数据包的重传来修复它。“它可以说’数据包丢失,但它只影响这一个数据流,而其他数据流可以继续运行’。”这使得QUIC 在恶劣的网络条件下更加强大。
HTTP / 3的连接迁移提议可以扩展在不同网络之间移动的稳健性,例如从Wi-Fi到移动宽带,这通常会因为IP地址的变化而破坏网络连接。“通过此提议,您和服务器之间的标识符将不是IP地址,而是协议本身内的标识符。这样您就可以在新网络上自动重启整个连接,这样您就可以无缝地从Wi-Fi转移到移动连接。原始互联网的一些假设是,存在相当固定的连接,我们现在正在进入一个非常移动的异构世界。“
Graham-Cumming解释说,HTTP / 3还直接集成了TLS,QUIC对数据包传输的额外控制也具有优势。“当事情通过互联网发送时,它们会被分解成数据包; 在TLS中,有一个传输数据缓冲区的概念。如果你想要真正有效率,你想要把所有这些事情排好; 这是一个请求,我将对它进行加密并通过互联网进行传输,以便一次性收到所有这些请求,并且不会分成较小的数据包,其中一些不会被延迟。如果您控制所有级别,如果您只是假设互联网是一种不可靠的发送数据包的方式,那么您可以控制发送内容的顺序,您可以控制加密它们的方式以及这些加密块如何传输。“
与HTTP服务器的初始连接将更快,因为HTTP / 3取出了通常需要建立连接的往返之一安全解释说,Mozilla首席工程师Martin Thomson是QUIC规范的编辑之一。
“使用TCP和TLS,连接设置以TCP握手开始:客户端发送SYN,服务器响应SYN + ACK,客户端使用ACK完成。然后在发送任何请求之前有一个TLS握手 – 它需要另一个类似的三个消息交换。QUIC在大多数情况下将其压缩到单个交换。一个关键特性是0-RTT,允许客户端立即发送请求; 这是TCP和TLS的一个选项,但你仍然需要等待TCP握手完成。“
集成TLS还可以提高安全性,因为身份验证和加密是由网络协议提供的,而不是像TLS这样的高级协议提供的 – 而且在HTTP / 3中内置了TLS,使用它也不是可选的。Graham-Cumming指出:“业界正试图在默认情况下保证一切安全。” 当站点使用HTTPS时,浏览器现在会在站点没有加密连接时向您发出警告,而不是显示锁定。HTTP / 3和QUIC是这个方向的另一个举措。
“更多的QUIC是加密的,”汤姆森解释道。这包括攻击者可能尝试使用的元数据。“除了一些有助于将数据包识别为QUIC数据包的比特之外,未加密的QUIC数据包的唯一部分是连接的不透明标识符。这包括TCP和TLS无法保护的内容,例如确认(’我从你那里得到5个字节’)。“
Thomson还认为加密实际上将简化部署QUIC。将新协议部署到需要更新的防火墙,路由器,NAT和其他网络设备上的复杂性阻碍了在浏览器中 创建新的,更有效的传输协议和延迟采用TLS 1.3的努力。“这是部署QUIC的可能性的一部分。互联网往往会干扰新的协议,加密将保护QUIC免受干扰。“
他坚持认为,这是UDP是一个不错的选择的另一个原因。“新的协议不能直接部署在IP之上,如TCP或UDP,因为这需要更新的互联网。考虑更换或升级每个想要使用此新协议的房屋中的每个路由器的前景。UDP在这种情况下是理想的,因为它做得很少。它非常轻巧,因此我们可以在顶部构建所有必要的部件。UDP的主要缺点是已经显示阻止或降级UDP的少量网络。在极少数情况下,我们有HTTP / 2可以依靠。“
当用户访问站点时,他们的初始连接将通过HTTP或HTTP / 2,服务器将提供HTTP / 3作为替代; 了解提供该连接的标头的浏览器将记住它以供下次访问,但较旧的浏览器和设备将继续使用旧协议。格雷厄姆 – 卡明预测说:“我们预计HTTP / 2和1.1将会存在很长时间。”
HTTP / 3可能有它的名字,但它仍在开发中; Graham-Cumming表示,情况稳定前几个月。尽管有一些HTTP / 3端点可用于测试Cloudflare等服务,但Facebook和Litespeed 已经证明了 2018年11月的HTTP / 3实现之间的互操作性,浏览器和Web服务器还没有支持HTTP / 3(Chrome的实验支持除外)对于谷歌的原始版本的QUIC)。
一旦他们这样做,服务提供商和托管公司将遵循,但可能需要更新旧的网络设备。“对于UDP的NAT遍历并不像TCP那样发达,一些家庭路由设备会假设UDP用于流媒体视频,而不是网络,”Graham-Cumming说。
Thomson说,如果你托管自己的网络服务器,你还有更多工作要做。“服务器管理员会发现QUIC需要的不仅仅是软件升级。启用UDP将需要网络和负载平衡基础架构的新支持。“网络运营商可能需要研究可以在软件中实现的更智能的第4层负载平衡解决方案,如Facebook的Katran项目。
但由于HTTP / 3旨在解决HTTP / 2的问题,因此对HTTP / 2进行的优化(如域分片的更改)将在可用时自动应用。如果是这样的话,Graham-Cumming希望它能够推动网络的发展。“我们希望的是更快的网络下载和API。它应该使互联网更加可靠和快速,并且希望对于开发者来说,我们可以获得更丰富的API和Web应用程序,因为我们可以通过这种新协议更多地依赖互联网。
https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/
确定新产品应使用何种类型的无线技术可能是一项艰巨的任务。目前不仅有大量的无线技术可用,而且它也是一个不断推出新技术的移动目标。
为了简化为您的产品选择最佳无线技术的过程,我已根据功能,数据速度和操作范围将各种无线技术组织成一个组。
本文最初发布于PredictableDesigns.com。下载他们的免费备忘单15步骤开发您的新电子硬件产品。
根据产品的预期功能,您可以相对简单地立即确定需要考虑的技术组。
例如,如果您需要两个相隔30英尺的设备来传输少量数据,那么使用任何长距离或高速无线技术都没有意义。
话虽如此,我建议您阅读整篇文章,无论您的产品具体需求如何,因为您可以大致了解所有可用的无线技术。
注意:这是一篇冗长,非常详细的文章,所以这里有一个免费的PDF版本,便于阅读和将来参考。您还将获得一个比较各种无线技术的Excel电子表格。
点对点简单地表示两个设备连接在一起以进行直接通信。通常只有两个设备可以参与对等连接。
在下一节中,我将讨论所谓的网状网络技术,它们允许许多设备互相连接。
最着名的点对点无线技术是蓝牙。将手机连接到蓝牙扬声器时,蓝牙扬声器是手机和扬声器之间的点对点无线连接。
由于相对较短的工作范围,蓝牙功耗相当低。它比WiFi消耗更少的功率,比蜂窝技术少得多,但仍远远超过蓝牙低功耗或Zigbee等技术。
每个人都知道WiFi,但很少有人听说过WiFi Direct。即使几乎所有手机和平板电脑都支持它,情况也是如此。与蓝牙一样,但与传统WiFi不同,WiFi Direct是一种点对点无线技术。
您可能已经知道,传统的WiFi设置了一个允许许多设备连接到它的接入点。但是,如果您想在没有接入点开销的情况下将数据直接从一个设备传输到另一个设备,该怎么办?这就是WiFi Direct发挥作用的地方。
WiFi Direct使用与传统WiFi相同的基本技术。它使用相同的频率并提供类似的带宽和速度。但是,它不需要接入点,允许两个设备具有类似于蓝牙的直接连接。
WiFi Direct相对于蓝牙的优势主要是传输速度更快。事实上,WiFi Direct比蓝牙快一百倍。虽然这个速度是有代价的,但价格主要是更高的功耗。
近场通信(NFC)与本文中讨论的其他无线技术根本不同。NFC使用在两个线圈之间共享的电磁场进行通信,而所有其他无线技术发射无线电波。
由于NFC通过两个电磁耦合在一起的线圈进行通信,因此工作范围仅为一英寸或两英寸。两个耦合线圈基本上形成具有空气芯的变压器。
NFC最常见的用途是非接触式支付系统。虽然支付数据当然是加密的,但NFC的极短操作范围也有助于消除附近其他人破解交易的可能性。
NFC允许使用无源NFC标签。在这种情况下,被动意味着没有电源。相反,无源标签由NFC读取器设备的电磁场供电。通信和功率传输都发生在两个耦合线圈之间。
无源标签的优点是它们简单,便宜,小巧,并且几乎无限期,因为没有电池。还提供有源标签,其中包括电池。
作为旁注,无线充电,通过将设备放置在充电垫上为设备充电,也可以利用两个耦合线圈之间的相同功率传输现象。
创建低功耗,低数据网络有四种常用技术:蓝牙低功耗,Zigbee,Z-Wave和6LoWPAN。
如果您的产品是电池供电的,并且需要在短距离内发送相对较少的数据,那么这四种技术中的一种可能是最佳解决方案。
所有这四种技术支持的关键特性称为网状网络,有时也称为多对多网络。
通常,要将数据从设备A发送到设备C,您必须在设备A和设备C之间形成直接链接。对于蓝牙和WiFi Direct等对等技术就是这种情况。
但是通过网状网络,您可以通过设备B将数据从设备A发送到设备C.数据从设备A发送到设备B,设备B然后将数据中继到设备C.这允许您创建庞大的互连设备网络可以覆盖功率极低的大面积区域。
例如,假设您有26个标记为A到Z的设备,这些设备在每个设备之间以一百英尺的距离间隔开。通常情况下,如果您想将数据从设备A一直发送到距离2500英尺远的设备Z,您需要一台功率相当大的发射机。这需要具有大电池的产品。
但是使用网状网络,您可以将数据从设备A中继到设备B,再到设备C等,直到设备Z.没有一台设备必须传输超过一百英尺的数据,因此需要的功率由每个设备都小得多。
网状网络可以打开很多非常有趣的应用程序。
蓝牙低功耗不仅仅是蓝牙经典的低能耗版本。事实上,它的应用程序与普通蓝牙完全不同。
蓝牙LE可能是我帮助开发的产品最常见的无线功能类型。它设计用于在相当不频繁的基础上传输/接收少量数据,同时消耗极低的功率。
BLE有许多应用,但最常见的一种是传输传感器数据。每分钟测量一次温度的传感器设备,或者每10分钟记录并传输其位置的GPS设备就是一些例子。
在许多情况下,蓝牙LE产品仅使用小型纽扣电池供电。如果数据不经常发送,则从纽扣电池运行的BLE设备可能具有一年或更长的电池寿命。
手机和平板电脑广泛支持蓝牙LE,使其成为将产品连接到移动应用的理想解决方案。它还支持高达1Mbps的下降传输速度(经典蓝牙可以达到2-3 Mbps)。
与本节中讨论的所有技术一样,BLE支持网状网络。实际上,它允许最多32,767个设备的网状网络!
除非您有充分的理由选择我在本节中讨论的其他技术(Zigbee,Z-Wave和6LoWPAN),否则我强烈建议您使用蓝牙LE。它是最简单的无线技术,功耗极低,是最受支持的技术。
Zigbee是另一种短距离网络技术,在许多方面类似于具有类似应用的蓝牙LE。它使用相同的2.4 GHz载波频率,功耗极低,在相似范围内运行,并提供网状网络。
实际上,Zigbee网状网络可以包含多达65,000个设备,这是蓝牙LE可以支持的两倍。但是,我还没有看到推动任何限制的应用程序。
Zigbee主要用于家庭自动化应用,如智能照明,智能恒温器和家庭能源监控。它还常用于工业自动化,智能仪表和安全系统。
Z-Wave是一种专有无线技术(由Silicon Labs于2018年收购),主要与家庭自动化市场中的Zigbee和BLE竞争。
与使用流行的2.4 GHz频段的BLE和Zigbee不同,Z-Wave使用的是低于1GHz的频段。如果您希望在全球范围内销售产品,则许多国家/地区的确切频段会有所不同,这可能会导 在美国,Z-Wave工作在908 MHz,而在欧洲,它使用868 MHz。其他国家和地区使用从865 MHz到921 MHz的所有内容。
载波频率较低有两个显着优点:增加范围和减少干扰。较低频率的无线电波进一步传播。BLE和Zigbee使用的2.4 GHz频段也用于WiFi,Bluetooth Classic甚至是微波炉,因此存在很多干扰的可能性。
Z-Wave使用的频段往往不那么拥挤。较低载波频率的缺点是较低的数据传输速度,最终比蓝牙LE慢近10倍。
Z-Wave支持最多232个设备的小型网状网络,这对大多数应用来说已经足够了。
6LoWPAN是一种奇怪命名的技术,它结合了两种不同的首字母缩略词。6指的是Internet协议(IP)版本6,而LoWPAN指的是低功耗无线个人局域网。我知道,这个名字很敏捷。
6LoWPAN基本上是Zigbee的新竞争者。主要区别在于6LoWPAN是基于IP的网络,如WiFi。与Zigbee和Z-Wave一样,6LoWPAN主要用于家庭自动化应用和智能电表。
WiFi,甚至可能比蓝牙更多,可能几乎不需要介绍。如果您的产品需要访问互联网,并且将始终在WiFi接入点附近使用,那么WiFi就是答案。由于其适度的覆盖区域,WiFi被称为局域网(LAN)技术。
WiFi快速,便宜,易于实施,具有良好的操作范围,并且可以广泛使用。至少对于移动产品而言,WiFi的最大缺点是功耗。由于功耗较高,如果您不需要WiFi提供的性能,通常最好使用其他无线技术。
如果您的产品需要访问云,但它不会始终位于WiFi接入点附近,那么您的产品可能需要蜂窝无线电进行长途通信。
您的产品所需的确切蜂窝技术类型取决于您传输数据的速度,以及产品销售地点的较小程度。
长期以来,GSM(全球移动通信系统)与GPRS(通用分组无线业务)相结合进行数据传输已成为不需要大量数据传输的产品最常用的蜂窝技术。这主要是由于GSM / GPRS硬件的广泛可用性和相对低的硬件成本。
不幸的是,这种情况即将结束。世界上大多数蜂窝运营商都在逐步淘汰GSM,因此他们可以为需要大量数据传输的4G和5G智能手机释放更多带宽。
更不幸的是,至少还没有明显的替代技术。最可能的选择是将硬件从GSM解决方案升级到LTE蜂窝技术,但随之而来的是价格大幅提升。
LTE是一种4G蜂窝技术,支持比GSM更快的数据速率。如果您的产品需要非常快速的蜂窝数据传输速度,那么LTE可能是最佳选择。
但是,如果您的产品并不真正需要这种级别的数据速度,那么您将支付您根本不需要的硬件。嵌入式GSM模块可以从中国购买,只需几美元,而LTE模块的价格可能超过20美元。LTE的运营商服务成本也将明显高于GSM。
随着物联网(IoT)设备的大量普及,这种技术选择的差距变得更加明显。不过,这个差距正在被几种不同的新无线技术所填补,我将在下一节讨论。
如果您需要长距离,低数据通信,就像许多物联网产品一样,那么您的技术选择并不像其他应用那样清晰。这种类型的网络通常被称为LPWAN或低功率广域网。
例如,如果您的产品在远程位置收集天气数据并自动将该数据上传到云,则可能需要LPWAN技术。正如我已经指出的那样,GSM或LTE蜂窝技术都不适合低数据速率应用。
还有其他无线技术可以解决这个问题,包括LoRa,NB-IoT和LTE-M。不幸的是,这些都不是广泛支持的全球标准。这使得许多产品的实施具有挑战性或不可能性,具体取决于它们的销售地点。
LoRa(长距离的缩写)可以在某些区域进行超过6英里的远距离通信,同时消耗很少的电量。它是Semtech在2012年收购的专有无线技术。
LoRa根据操作区域使用各种频带。在北美,使用915 MHz,在欧洲,频率为868 MHz。其他区域也可能使用169 MHz和433 MHz。
LoRa指的是底层技术,可以直接用于点对点通信。LoRaWAN是指上层网络协议。
如果您正在寻找低功耗,长距离,点对点的解决方案,那么LoRa是一个很好的选择。您通常可以购买比LoRaWAN模块便宜的LoRa模块。
如果您希望您的产品连接到现有的LoRaWAN网络,则需要包含网络层的更昂贵的LoRaWAN模块。不幸的是,LoRaWAN网络仅在欧洲部分地区提供,而在北美地区则不提供。这严重限制了LoRaWAN对大多数产品的实用性。
尽管LoRa的设计可以在很大范围内运行,但它并不是可以连接到移动网络的蜂窝技术。这使得它更简单,实施起来更便宜,但它的应用程序是有限的。
例如,如果您的产品需要远程访问云,那么您还需要提供LoRa网关设备以连接到Internet。网关设备连接到互联网,并与任何远程LoRa设备通信。
假设在操作范围内没有LoRa网关,LoRa不为任何单个远程设备提供远程访问云的方法。
与LoRa / LoRaWAN不同,NB-IoT是一种蜂窝技术。这意味着它更复杂,实施起来更昂贵,并且消耗更多功率。但是,它提供更高质量的蜂窝连接和直接访问互联网。
NB-IoT仅用于传输非常少量的数据。NB-IoT的最大缺点是可用性有限。目前还没有美国运营商支持它,目前它只在欧洲进行测试。但它有望在2019年的某个时候在美国推出。
这项技术现在可能无法在您的产品中实施,但在未来几年内它将变得更加实用。
如果您的产品需要具有比LoRa或NB-IoT支持的更高数据速率的远程蜂窝接入,那么LTE-M可能是您的最佳选择。
LTE-M是LTE(长期演进)Cat-M1的缩写。该技术适用于需要直接连接到4G移动网络的物联网设备。它是LTE蜂窝技术的一个子集,针对从小型电池运行的低数据速率设备进行了优化。
LTE-M在几个关键方面与标准LTE不同。 首先,实施起来更便宜,因为由于带宽更有限,可以使用更简单的芯片。
其次,它针对降低功耗进行了优化,以免快速耗尽小电池。最后,蜂窝服务成本显着降低,因为您没有使用接近标准LTE所需带宽的任何地方。
选择无线技术的关键是缩小您的要求,以便您可以专注于可行的技术。所需的工作范围,数据传输速度,功耗和成本是选择无线技术的主要标准。
当然,就像工程中的所有事情一样,你不可能拥有一切。例如,大的工作范围需要增加功耗。对于更快的数据速率也是如此。这些标准之间总会有一些让步。从来没有一个完美的解决方案。
如果您正在寻找提供长距离,低功耗,高数据速率和低成本的技术,您将永远找不到真实的解决方案。相反,我建议您优先考虑您的设计标准,并从那里开始缩小您的选择范围。
最近引起我注意的是,缺乏关于现代网络负载平衡和代理的介绍性教育材料。我心想:这怎么可能?负载平衡是构建可靠分布式系统所需的核心概念之一。当然必须有高质量的信息吗?我搜索并发现这些采摘确实很苗条。关于负载平衡和代理服务器的维基百科文章包含一些概念的概述,但不是对主题的流畅处理,特别是因为它涉及现代微服务架构。一个谷歌搜索的负载均衡主要是轮番上涨是对细节的流行语和轻重供应商的网页。
在这篇文章中,我试图通过提供对现代网络负载平衡和代理的温和介绍来纠正缺乏信息。坦率地说,这是一个可能成为整本书主题的大型话题。为了保持这篇文章(有点)博客篇幅,我尝试将一组复杂的主题提炼成一个简单的概述; 根据兴趣和反馈,我将在稍后考虑更详细的关于个别主题的后续帖子。
有一些背景知道我为什么写这个 – 我们走了!
在计算中,负载平衡改善了跨多个计算资源(例如计算机,计算机集群,网络链接,中央处理单元或磁盘驱动器)的工作负载分布。负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间,并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件,例如多层交换机或域名系统服务器进程。
以上定义适用于计算的所有方面,而不仅仅是网络。操作系统使用负载平衡来跨物理处理器调度任务,容器协调器(如Kubernetes)使用负载平衡来跨计算群集调度任务,网络负载平衡器使用负载平衡来跨可用后端调度网络任务。本文的其余部分仅涵盖网络负载平衡。
图1显示了网络负载平衡的高级概述。一些客户端正在从一些后端请求资源。负载均衡器位于客户端和后端之间,并且在高级别执行几项关键任务:
在分布式系统中正确使用负载平衡可带来以下好处:
在谈论网络负载平衡器时,术语负载平衡器和代理在业内大致可互换使用。这篇文章也将这些条款视为一般等同。(小心并非所有代理都是负载均衡器,但绝大多数代理都将负载均衡作为主要功能)。
有些人可能会争辩说,当负载均衡作为嵌入式客户端库的一部分完成时,负载均衡器实际上并不是代理。但是,我认为区别会给已经令人困惑的话题带来不必要的复杂性。负载平衡器拓扑的类型将在下面详细讨论,但是这篇文章将嵌入式负载均衡器拓扑视为代理的特殊情况; 应用程序通过嵌入式库进行代理,该库提供与应用程序进程之外的负载均衡器相同的抽象。
在讨论当今整个行业的负载平衡时,解决方案通常分为两类:L4和L7。这些类别涉及OSI模型的第4层和第7层。由于我在讨论L7负载平衡时会变得明显的原因,我认为这些是我们使用的术语是不幸的。OSI模型是负载平衡解决方案的复杂性的非常差的近似,其包括传统的第4层协议(例如TCP和UDP),但通常最终包括在各种不同OSI层的位和协议。即,如果L4 TCP负载均衡器也支持TLS终端,它现在是L7负载均衡器吗?
图2显示了传统的L4 TCP负载均衡器。在这种情况下,客户端与负载均衡器建立TCP连接。负载均衡器终止连接(即直接响应SYN),选择后端,并与后端建立新的TCP连接(即发送新的SYN)。该图的细节并不重要,将在下面专门讨论L4负载平衡的部分中详细讨论。
本节的关键点是L4负载均衡器通常仅在L4 TCP / UDP连接/会话级别运行。因此,负载均衡器大致来回抽取字节,并确保来自同一会话的字节在同一后端结束。L4负载均衡器不知道它正在混洗的字节的任何应用程序细节。字节可以是HTTP,Redis,MongoDB或任何其他应用程序协议。
L4负载平衡很简单,仍然可以广泛使用。L4负载平衡有哪些缺点需要投资L7(应用程序)负载平衡?以下面的L4特定案例为例:
在上一个场景中,选择处理客户端A的后端将处理大约3000倍的负载,然后选择后端来处理客户端B!这是一个大问题,并且通常首先会破坏负载平衡的目的。另请注意,任何多路复用,保持活动协议都会出现此问题。(多路复用意味着通过单个L4连接发送并发应用程序请求,并且保持活动意味着在没有活动请求时不关闭连接)。由于效率原因,所有现代协议都在发展为多路复用和保持活动(创建连接通常很昂贵,尤其是当使用TLS加密连接时),因此L4负载平衡器阻抗不匹配随着时间的推移变得越来越明显。此问题由L7负载平衡器修复。
图3显示了L7 HTTP / 2负载均衡器。在这种情况下,客户端与负载均衡器建立单个HTTP / 2 TCP连接。然后负载平衡器继续进行两个后端连接。当客户端向负载均衡器发送两个HTTP / 2流时,流1被发送到后端1,而流2被发送到后端2.因此,即使多路复用具有非常不同的请求负载的客户端也将在后端有效地平衡。这就是L7负载平衡对于现代协议如此重要的原因。(L7负载平衡由于其检查应用程序流量的能力而产生了大量额外的好处,但这将在下面更详细地介绍)。
正如我在上面关于L4负载平衡的部分所述,使用OSI模型来描述负载平衡功能是有问题的。原因是L7,至少如OSI模型所描述的那样,本身包含多个离散的负载平衡抽象层。例如,对于HTTP流量,请考虑以下子层:
复杂的L7负载平衡器可以提供与上述每个子层相关的特征。另一个L7负载均衡器可能只有一小部分功能将其置于L7类别中。简而言之,从功能比较的角度来看,L7负载均衡器的格局要比L4类别复杂得多。(当然,本节刚刚介绍了HTTP; Redis,Kafka,MongoDB等都是受益于L7负载平衡的L7应用协议的例子)。
在本节中,我将简要总结负载平衡器提供的高级功能。并非所有负载平衡器都提供所有功能。
服务发现是负载均衡器确定可用后端集的过程。方法多种多样,一些例子包括:
运行状况检查是负载均衡器确定后端是否可用于提供流量的过程。健康检查通常分为两类:
/healthcheck
端点的HTTP请求)向后端发送ping,并使用它来衡量运行状况。
是的,负载平衡器必须实际平衡负载!给定一组健康的后端,如何选择后端来提供连接或请求?负载平衡算法是一个活跃的研究领域,范围从简单的算法,如随机选择和循环,到考虑可变延迟和后端负载的更复杂的算法。鉴于其性能和简单性,最流行的负载平衡算法之一被称为2个最小请求负载平衡的功能。
在某些应用程序中,同一会话的请求到达相同的后端非常重要。这可能与缓存,临时复杂构造状态等有关。会话的定义各不相同,可能包括HTTP cookie,客户端连接的属性或某些其他属性。许多L7负载均衡器对粘性会话有一些支持。顺便说一句,我会注意到会话粘性本质上是脆弱的(托管会话的后端可能会死),所以在设计依赖它们的系统时要小心。
TLS的主题及其在边缘服务和保护服务到服务通信中的作用值得自己发表。话虽如此,许多L7负载均衡器进行了大量的TLS处理,包括终止,证书验证和固定,使用SNI的证书服务等。
正如我在会谈中所说的那样:“可观察性,可观察性,可观察性。”网络本质上是不可靠的,负载均衡器通常负责导出统计数据,跟踪和日志,帮助运营商找出问题所在,以便他们能够解决问题。负载平衡器的可观察性输出差异很大。最先进的负载平衡器提供丰富的输出,包括数字统计,分布式跟踪和可自定义的日志记录。我要指出,增强的可观察性不是免费的; 负载均衡器必须做额外的工作来生产它。但是,数据的好处大大超过了相对较小的性能影响。
尤其是在边缘部署拓扑(见下文),负载平衡器通常实现的各种安全功能,包括速率限制,认证和DoS缓解(例如,IP地址标记和识别,缓送等)。
需要配置负载平衡器。在大型部署中,这可能成为一项重大任务。通常,配置负载平衡器的系统称为“控制平面”,并且在其实现中变化很大。有关此主题的更多信息,请参阅我在服务网格数据平面与控制平面上的帖子。
本节刚刚介绍了负载均衡器提供的功能类型。有关L7负载平衡器的部分,请参见其他讨论。
现在我已经介绍了负载均衡器的概况,L4和L7负载均衡器之间的差异以及负载均衡器功能的摘要,我将继续讨论部署负载均衡器的各种分布式系统拓扑。(以下每种拓扑适用于L4和L7负载平衡器)。
图4中所示的中间代理拓扑可能是获得大多数读者负载平衡的最熟悉的方法。此类别包括Cisco,Juniper,F5等硬件设备; 亚马逊的ALB和NLB以及谷歌的云负载均衡器等云软件解决方案; 和纯软件自托管解决方案,如HAProxy,NGINX和Envoy。中间代理解决方案的专家是用户简单性。通常,用户通过DNS连接到负载均衡器,无需担心其他任何问题。中间代理解决方案的一个问题是代理(即使是集群)是单点故障以及扩展瓶颈。中间代理通常也是黑盒子,使操作变得困难。客户端是否存在问题?在物理网络中?在中间代理?在后端?这很难说。
边缘代理拓扑如图5所示实际上只是中间代理拓扑的一种变体,可以通过Internet访问负载均衡器。在这种情况下,负载均衡器通常必须提供额外的“API网关”功能,例如TLS终止,速率限制,身份验证和复杂的流量路由。边缘代理的优缺点与中间代理相同。需要注意的是,在面向Internet的大型分布式系统中部署专用边缘代理通常是不可避免的。客户端通常需要使用服务所有者无法控制的任意网络库通过DNS访问系统(使以下部分中描述的嵌入式客户端库或sidecar代理拓扑不能直接在客户端上运行)。另外,
为了避免中间代理拓扑中固有的单点故障和扩展问题,更复杂的基础架构已经转向通过库将负载均衡器直接嵌入到服务中,如图6所示。图书馆在支持的功能方面差异很大,但这一类中最知名且功能最丰富的一些是Finagle,Eureka / Ribbon / Hystrix和gRPC(松散地基于称为Stubby的内部Google系统)。基于库的解决方案的主要优势在于它将负载均衡器的所有功能完全分配给每个客户端,从而消除了先前描述的单点故障和扩展问题。基于库的解决方案的主要目标是,库必须以组织使用的每种语言实现。分布式架构正变得越来越“多语言”(多语言)。在这种环境下,以多种不同语言重新实现极其复杂的网络库的成本可能会变得令人望而却步。最后,在大型服务架构中部署库升级可能会非常痛苦,因此很可能会在生产中同时运行许多不同版本的库,
综上所述,上述图书馆已经成功地为那些能够限制编程语言扩散并克服库升级难度的公司提供了帮助。
嵌入式客户端库负载平衡器拓扑的变体是图7中所示的边车代理拓扑。近年来,这种拓扑结构已经被推广为“服务网格”。边车代理背后的想法是,通过跳转到不同的进程而导致轻微的延迟损失,嵌入式库方法的所有好处都可以是没有任何编程语言锁定获得。在撰写本文时,最受欢迎的边车代理负载均衡器是Envoy,NGINX,HAProxy和Linkerd。有关边车代理方法的更详细的处理,请参阅我的博客文章介绍Envoy以及我的在服务网格数据平面与控制平面上发布。
总的来说,我认为sidecar代理拓扑(服务网格)正在逐步取代所有其他拓扑以进行服务到服务通信。在流量进入服务网格之前,始终需要边缘代理拓扑。
这篇文章已经讨论了L7负载平衡器对于现代协议的优势,并将在下面进一步详细介绍L7负载平衡器功能。这是否意味着L4负载平衡器不再相关?没有!虽然在我看来L7负载平衡器最终将完全取代用于服务到服务通信的 L4负载平衡器,但L4负载平衡器在边缘仍然非常相关,因为几乎所有现代大型分布式架构都使用双层L4 / L7负载平衡架构用于互联网流量。在边缘部署中在L7负载平衡器之前放置专用L4负载平衡器的好处是:
在下面的部分中,我将介绍中/边缘代理L4负载平衡器的几种不同设计。以下设计通常不适用于客户端库和边车代理拓扑。
仍在使用的第一种L4负载平衡器是终端负载平衡器,如图8所示。这与我们在上面的L4负载平衡介绍中看到的负载均衡器相同。在这种类型的负载均衡器中,使用两个离散的TCP连接:一个在客户端和负载均衡器之间,一个在负载均衡器和后端之间。
L4终端负载平衡器仍然使用有两个原因:
第二种L4负载平衡器是直通负载平衡器,如图9所示。在这种类型的负载均衡器中,负载均衡器不会终止TCP连接。而是在连接跟踪和网络地址转换(NAT)发生后,将每个连接的数据包转发到选定的后端。首先,让我们定义连接跟踪和NAT:
使用连接跟踪和NAT,负载均衡器可以通过从客户端到后端的大多数原始TCP流量。例如,假设客户端正在与之通信,1.2.3.4:80
并且所选择的后端位于10.0.0.2:9000
。客户端TCP数据包将到达负载均衡器1.2.3.4:80
。然后,负载均衡器将交换数据包的目标IP和端口10.0.0.2:9000
。它还将交换数据包的源IP和负载均衡器的IP地址。因此,当后端响应TCP连接时,数据包将返回负载均衡器,在负载均衡器中发生连接跟踪,NAT可以反向再次发生。
为什么使用这种类型的负载平衡器代替上一节中描述的终端负载平衡器,因为它更复杂?原因如下:
直接服务器返回(DSR)负载均衡器如图10所示。DSR建立在上一节中描述的直通负载均衡器之上。DSR是一种优化,其中只有入口/请求数据包遍历负载均衡器。出口/响应数据包在负载均衡器周围直接返回客户端。执行DSR有趣的主要原因是,在许多工作负载中,响应流量使请求流量相形见绌(例如,典型的HTTP请求/响应模式)。假设10%的流量是请求流量,90%的流量是响应流量,如果DSR正在使用1/10的负载均衡器容量可以满足系统的需要。由于历史上负载平衡器非常昂贵,因此这种类型的优化会对系统成本和可靠性产生重大影响(总是更好)。DSR负载平衡器扩展了直通负载均衡器的概念,具体如下:
请注意,在直通负载均衡器和DSR负载均衡器设计中,可以通过负载均衡器和后端设置连接跟踪,NAT,GRE等多种方式。不幸的是,该主题超出了本文的范围。
到目前为止,我们一直在考虑单独设计L4负载平衡器。passthrough和DSR负载均衡器都需要在负载均衡器本身中进行一定量的连接跟踪和状态。如果负载均衡器死了怎么办?如果负载平衡器的单个实例死亡,则将切断遍历负载平衡器的所有连接。根据应用程序的不同,这可能会对应用程序性能产生重大影响。
从历史上看,L4负载平衡器是从典型供应商(Cisco,Juniper,F5等)购买的硬件设备。这些设备非常昂贵并且处理大量流量。为了避免单个负载平衡器故障切断所有连接并导致严重的应用程序中断,负载平衡器通常部署在高可用性对中,如图11所示。典型的HA负载平衡器设置具有以下设计:
上面的设置是今天仍然有多少高流量的互联网应用程序。但是,上述方法存在很大的缺点:
上一节介绍了通过HA对的L4负载均衡器容错以及该设计中固有的问题。从2000年代早期到中期,大型互联网基础设施开始设计和部署新的大规模并行L4负载平衡系统,如图12所示。这些系统的目标是:
此L4负载平衡器设计最好称为容错和通过群集和分布式一致性散列进行扩展。它的工作原理如下:
让我们看看上述设计如何减轻HA对方法的所有缺点:
通常被问到这个设计的一个问题是“边缘路由器为什么不通过ECMP直接与后端通信?为什么我们需要负载均衡器?“其原因主要是围绕DoS缓解和后端操作简便性。如果没有负载均衡器,每个后端都必须参与BGP,并且执行滚动部署的难度要大得多。
所有现代L4负载平衡系统都在朝着这种设计(或其某些变体)发展。最着名的两个例子是Google的Maglev和亚马逊的网络负载均衡器(NLB)。目前没有任何OSS负载均衡器可以实现这种设计,但是,我知道有一家公司计划在2018年向OSS发布一个。我对这个版本感到非常兴奋,因为现代L4负载均衡器是一个至关重要的部分在网络空间中缺少OSS。
确实是的。最近几年L7负载均衡器/代理开发出现了复苏。这与分布式系统中对微服务架构的持续推动非常吻合。从根本上说,当更频繁地使用时,固有故障的网络变得更难以有效地操作。此外,自动扩展,容器调度程序等的兴起意味着在静态文件中供应静态IP的日子早已不复存在。系统不仅更多地利用网络,它们变得更加动态,需要负载平衡器中的新功能。在本节中,我将简要总结现代L7负载平衡器中发展最多的领域。
现代L7负载平衡器正在为许多不同的协议添加明确的支持。负载均衡器对应用流量的了解越多,它在可观察性输出,高级负载平衡和路由等方面就可以做得越复杂。例如,在撰写本文时,Envoy明确支持L7协议解析和路由。对于HTTP / 1,HTTP2,gRPC,Redis,MongoDB和DynamoDB。未来可能会添加更多协议,包括MySQL和Kafka。
如上所述,分布式系统的日益动态的性质需要在创建动态和反应控制系统方面进行并行投资。Istio就是这种系统的一个例子。有关此主题的更多信息,请参阅我在服务网格数据平面与控制平面上的帖子。
L7负载平衡器现在通常内置支持高级负载平衡功能,如超时,重试,速率限制,断路,阴影,缓冲,基于内容的路由等。
如上面关于一般负载平衡器功能的部分所述,正在部署的越来越动态的系统变得越来越难以调试。强大的协议特定可观察性输出可能是现代L7负载平衡器提供的最重要的功能。现在,任何L7负载平衡解决方案几乎都需要输出数字统计,分布式跟踪和可自定义日志记录。
现代L7负载平衡器的用户通常希望轻松扩展它们以添加自定义功能。这可以通过编写加载到负载均衡器中的可插入过滤器来完成。许多负载平衡器也支持脚本,通常通过Lua。
我写了很多关于L4负载均衡器容错的文章。L7负载均衡器容错怎么样?通常,我们将L7负载平衡器视为可消耗和无状态的。使用商用软件可以轻松地水平缩放L7负载平衡器。此外,L7负载平衡器执行的处理和状态跟踪比L4复杂得多。尝试建立L7负载均衡器的HA配对在技术上是可行的,但这将是一项重大任务。
总的来说,在L4和L7负载均衡域中,业界正逐渐从HA配对转向通过一致散列融合的水平可扩展系统。
L7负载平衡器正在以惊人的速度发展。有关Envoy提供的示例,请参阅Envoy的架构概述。
负载平衡的未来将越来越多地将各个负载平衡器视为商品设备。在我看来,真正的创新和商业机会都在控制平面内。图13显示了全局负载平衡系统的示例。在这个例子中,发生了一些不同的事情:
全局负载均衡器将越来越能够完成任何单个负载均衡器无法独立完成的复杂事物。例如:
为了实现全局负载平衡,用作数据平面的负载平衡器必须具有复杂的动态配置功能。有关此主题的更多信息,请参阅我在Envoy的通用数据平面API以及服务网格数据平面与控制平面上的帖子。
到目前为止,这篇文章仅简要提到了硬件与软件,主要是在历史L4负载均衡器HA对的上下文中。这个领域的行业趋势是什么?
之前的推文是一种幽默的夸张,但仍然总结了很多趋势,它们是:
总而言之,这篇文章的主要内容是:
总的来说,我认为这是计算机网络的一个迷人时刻!大多数系统向OSS和软件的转变正在将迭代速度提高几个数量级。此外,随着分布式系统通过“无服务器”范例继续向动态迈进,底层网络和负载平衡系统的复杂性将需要相应增加。
增加EXT-X-MEDIA-SEQUENCE或EXT-X
-DISCONTINUITY-SEQUENCE标签的值(第6.2.2节)。
添加或删除EXT-X-STREAM-INF标签或EXT-XI-FRAME-STREAM-INF
标签(第6.2.4节)。请注意,客户端不需要
重新加载主播放列表文件,因此更改它们可能不会
立即生效。
将EXT-X-ENDLIST标记添加到播放列表(第6.2.1节)。
此外,播放列表文件可以包含EXT-X-PLAYLIST-TYPE标记
,其值为EVENT或VOD。如果标签存在且
值为EVENT,则服务器不得更改或删除任何部分
播放列表文件(尽管它可以向其添加行)。如果标签
存在且值为VOD,则播放列表文件不得更改。
播放列表中的每个媒体片段都必须应用EXTINF标记,以
指示媒体片段的持续时间。
媒体播放列表中的每个片段都具有整数不连续
序列号。
除了媒体内的时间戳之外,还可以使用不连续序列号来
跨不同的再现来同步媒体段。Pantos&May将于2014年10月16日到期[第23页]
Internet-Draft HTTP Live Streaming 2014年4月
段的不连续序列号是EXT-X
-DISCONTINUITY-SEQUENCE标记的值(如果没有,则为零)加上
URI行之前的播放列表中的EXT-X-DISCONTINUITY标记的数量
细分市场。
包含EXT-X-PLAYLIST-TYPE标记的媒体播放列表,其
值为EVENT或VOD,不得包含EXT-X-DISCONTINUITY-
SEQUENCE标记。
服务器可以
通过对其应用EXT-X-PROGRAM-DATE-TIME标记将绝对日期和时间与媒体段相关联。这
定义了(挂钟)日期和时间的信息映射
由标签指定给段中的第一媒体时间戳,
其可以用作寻找,显示或用于其他
目的的基础。如果服务器提供此映射,它应该将
EXT-X-PROGRAM-DATE-TIME
标记应用于应用了EXT-X-DISCONTINUITY标记的每个段。
如果媒体播放列表包含
演示文稿的最终媒体段,则播放列表文件必须包含EXT-X-ENDLIST
标记。
如果媒体播放列表不包含EXT-X-ENDLIST标记,则
服务器必须使新版本的播放列表文件可用,
其中包含至少一个新媒体段。它必须可用
相对于以前版本的播放列表文件
可用的时间:不早于该时间
之后的目标持续时间的一半,并且不晚于该时间
之后的目标持续时间的1.5倍。
如果服务器希望删除整个演示文稿,则必须使
播放列表文件对客户端不可用。它应该确保
播放列表文件中的所有媒体段
至少在删除时播放列表文件的持续时间内仍然可供客户端使用。
6.2.2。现场播放列表
服务器可以通过
从播放列表文件中删除媒体段来限制媒体段的可用性(第6.2.1节)。如果
要删除媒体段,播放列表文件必须只包含
一个EXT-X-MEDIA-SEQUENCE标记。对于
从播放列表文件中删除的每个媒体段,其值必须递增1 。
媒体片段必须按照
它们在播放列表中出现的顺序从播放列表文件中删除。
如果
播放列表文件的持续时间减去段的持续时间
小于目标持续时间的三倍,则服务器不得从播放列表文件中删除媒体段。
Pantos&May将于2014年10月16日到期[第24页]
Internet-Draft HTTP Live Streaming 2014年4月
当服务器从播放列表中删除媒体段时,
相应的媒体URI应该对客户端保持可用
的时间段,该时间段等于段的持续时间加上
分发的最长播放列表文件的持续时间。包含
该段的服务器。
如果服务器希望从
包含EXT-X-DISCONTINUITY标签的媒体播放列表中删除段,则播放列表必须包含
EXT-X-DISCONTINUITY-SEQUENCE标记。
如果服务器从媒体
播放列表中删除EXT-X-DISCONTINUITY标记,它必须增加EXT-X-DISCONTINUITY-的值 –
SEQUENCE标记,以便
仍然在播放列表中的段的不连续序列号保持不变。
如果服务器计划在
通过HTTP 将媒体段传递给客户端后将其删除,则应该确保HTTP响应包含
反映计划生存时间的Expires标头。
实时播放列表不得包含EXT-X-PLAYLIST-TYPE标记。
我正在尝试用ffmpeg连接3个MP4文件。我需要这是一个自动的过程,因此我选择了ffmpeg。我正在将这3个文件转换成.ts文件,然后将它们连接起来,然后尝试对连接的.ts文件进行编码。这些文件是H 264和AAC编码的,我希望尽可能保持质量不变或接近原版。
FFmpeg有三种级联方法。
ffmpeg -i opening.mkv -i episode.mkv -i ending.mkv \ -filter_complex "[0:v] [0:a] [1:v] [1:a] [2:v] [2:a] concat=n=3:v=1:a=1 [v] [a]" \ -map "[v]" -map "[a]" output.mkv
请注意,此方法执行重新编码。
$ cat mylist.txt file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'
$ ffmpeg -f concat -i mylist.txt -c copy output
Windows操作系统:
(echo file ../../../../1.mp4 & echo file ../../../../2.mp4 )>%tmp%/list.txt ffmpeg -safe 0 -f concat -i %tmp%/list.txt -c copy c:/output.mp4
ffmpeg -i "concat:input1|input2" -codec copy output
该方法不适用于许多格式,包括MP4,因为这些格式的性质以及该方法执行的简单级联。
如果有疑问,可以试试减刑演示程序。
UDP Jitter测试是以UDP报文为承载,通过记录在报文中的时间戳信息来统计时延、抖动、单向丢包的一种测试方法。Jitter(抖动时间)是指相邻两个报文的接收时间间隔减去这两个报文的发送时间间隔的差值。
如图1所示,UDP Jitter测试的过程如下:
源端(ME60A)向目的端(ME60B)发送数据包。发送时,在报文中记录时间戳t1。
目的端(ME60B)收到报文后,在报文中记录时间戳t1’。
目的端(ME60B)将收到的报文发回到源端,在报文中记录时间戳t2’。
源端(ME60A)收到报文,在报文中记录时间戳t2。
从源端接收到的信息中计算出:
数据包从源端到目的端和从目的端到源端的最大抖动时间、最小抖动时间及平均抖动时间。
从目的端到源端或从源端到目的端的最大单向延时。
从而清晰的反映出网络状况。
双向时延:RTT=(t2-t1)-(t2′- t1’)
当双向时延>用户配置的超时时间时,表示网络不畅通。此时,报文将被统计为丢包。
丢包率=丢包个数/发送报文总数
UDP Jitter测试可以测试2个方向的抖动(Jitter)值:
SD(源到目的)方向:Jitter=(t3’-t1’)-(t3-t1)
计算出来的结果,如果大于0,则统计为正向抖动值;如果小于0,则统计为负向抖动值。
DS(目的到源)方向:Jitter=(t4-t2)-(t4’-t2’)
计算出来的结果,如果大于0,则统计为正向抖动值;如果小于0,则统计为负向抖动值。
UDP Jitter测试例还支持统计单向丢包。
如图2所示,在Server(ME60B)端会统计收到报文的个数,当Client(ME60A)端口收到的报文个数与从报文中获取的Server(ME60B)端收到报文的个数不同时,会自动发起单向丢包查询,获取Server(ME60B)端接收报文的个数:
Packet Loss SD是源到目的的丢包
Packet Loss SD=Client(ME60A)端发送的报文个数-Server(ME60B)接收报文个数
Packet Loss DS是目的到源的丢包
Packet Loss DS=Server(ME60B)接收报文的个数-Client(ME60A)接收报文的个数
Client(ME60A)端收不到查询报文时,会将丢包记录到Packet Loss Unknown。
先说一下优劣势,再说一下使用场景吧
1、存储过程的优势
(1)、减少连接数
(2)、调用相对程序方比较简单,由DB管理员加,程序方只是需要传递参数即可
(3)、方便DBA查看
2.使用存储过程的劣势
(1)、程序极大耦合,业务一旦更改,需要都进行更改
(2)、牵扯到复杂计算的情况下,需要数据库进行运算,而数据库的优势是存取,循环等逻辑判断服务的情况是数据库的一个硬伤
(3)、调试困难,无法知道运行sql的情况,尤其是数据库有专门DBA的情况
(4)、主从分离的情况无法使用
(5)、无法适应数据库的切割(水平或垂直切割)。数据库切割之后,存储过程并不清楚数据存储在哪个数据库中。
3、使用场景
存储过程只是适用在php和mysql都是同一个人管理的不太进行业务变更的小网站上。稍微复杂一点的网站并不适合存储过程
28、应用程序必须捕获SQL异常的功能,并有相应处理
http://www.architecy.com/archives/456