作者｜Bill Dally  翻译｜胡燕君、沈佳丽、贾川  过去十年是深度学习的“黄金十年”，它彻底改变了人类的工作和娱乐方式，并且广泛应用到医疗、教育、产品设计等各行各业，而这一切离不开计算硬件的进步，特别是GPU的革新。  深度学习技术的成功实现取决于三大要素：第一是算法。20世纪80年代甚至更早就提出了大多数深度学习算法如深度神经网络、卷积神经网络、反向传播算法和随机梯度下降等。   第二是数据集。训练神经网络的数据集必须足够大，才能使神经网络的性能优于其他技术。直至21世纪初，诸如Pascal和ImageNet等大数据集才得以现世。  第三是硬件。只有硬件发展成熟，才能将大型数据集训练大型神经网络的所需时间控制在合理的范围内。业内普遍认为：比较“合理”的训练时间大概是两周。至此，深度学习领域燃起了燎原之火。  如果把算法和数据集看作是深度学习的混合燃料，那么GPU就是点燃它们的火花，当强大的GPU可用来训练网络时，深度学习技术才变得实用。  此后，深度学习取代了其他算法，被广泛应用在图像分类、图像检测、语音识别、自然语言处理、时序分析等领域，甚至在围棋和国际象棋方面也能看到它的身影。随着深度学习潜入人类生活的方方面面，模型训练和推理对硬件的要求也越来越高。   从2012年AlexNet出现到2016年ResNet问世，图像神经网络的训练算力消耗（以petaflop/s-day为单位）增长了将近2个数量级，而从2018年的BERT到近年的GPT-3，训练算力消耗增加了近4个数量级。在此期间，得益于某些技术的进步，神经网络的训练效率明显提升，由此节省了不少算力，否则算力消耗的增长还会更夸张。  研究人员想用更大的无监督语言数据集训练更大的语言模型，然而，尽管他们已经拥有4000个节点的GPU集群，但在合理训练时间内能处理的运算还是非常有限。这就意味着，深度学习技术的发展有多快，取决于硬件发展有多快。  如今，深度学习模型不但越来越复杂，而且应用范围越来越广泛。因此，还需要持续提升深度学习的性能。  那么，深度学习硬件究竟如何继续提升？英伟达首席科学家Bill Dally无疑是回答这一问题的权威，在H100 GPU发布前，他在一次演讲中回顾了深度学习硬件的现状，并探讨摩尔定律失效的情况下持续提升性能扩展的若干方向。OneFlow社区对此进行了编译。  1  GPU架构演进史  从2012年的K20X到2020年的A100，GPU的推理性能提高到原来的317倍。这就是我们所说的“黄氏定律”，这种发展速度比“摩尔定律”快得多。   GPU的推理性能提升  但不同于“摩尔定律”，在“黄氏定律”中，GPU的性能提升不完全依赖制程技术的进步。上图用黑、绿、蓝三色分别标注了这几种GPU，分别代表它们使用了三种不同的制程技术。早期的K20X和M40使用的是28纳米制程；P100、V100和Q8000使用的是16纳米制程；A100使用的是7纳米制程。制程技术的进步大概只能让GPU的性能提高到原来的1.5或2倍。而总体317倍的性能提升绝大部分归功于GPU架构和线路设计的完善。  2012年，英伟达推出了一款Kepler架构GPU，但它并不是专为深度学习设计的。英伟达在2010年才开始接触深度学习，当时还没有考虑为深度学习量身定制GPU产品。  Kepler (2012)  Kepler的目标使用场景是图像处理和高性能运算，但主要还是用于图像处理。因此，它的特点是高浮点运算能力，它的FP32计算（单精度浮点数计算）速度达到近4 TFLOPS，内存带宽达到250 GB/s。基于Kepler出色的性能表现，英伟达也将它视为自家产品的基准线。   Pascal (2016)  后来，英伟达在2016年推出了Pascal架构，它的设计更适合深度学习。英伟达经过一些研究后发现，不少神经网络都可以用FP16（半精度浮点数计算）训练，因此Pascal架构的大部分型号都支持FP16计算。下图这款Pascal GPU的FP32计算速度可达10.6 TFLOPS，比前一款Kepler GPU高出不少，而它的FP16计算则更快，速度是FP32的两倍。  Pascal架构还支持更多复杂指令，例如FDP4，这样就可以将获取指令、解码和获取操作数的开销分摊到8个算术运算中。相较于之前的融合乘加（Fuse Multiply-Add）指令只能将开销分摊到2个算术运算，Pascal架构可以减少额外开销带来的能耗，转而将其用于数学运算。  Pascal架构还使用了HBM显存，带宽达到732 GB/s，是Kepler的3倍。之所以增加带宽，是因为内存带宽是深度学习性能提升的主要瓶颈。此外，Pascal使用了NVLink，可以连接更多机器和GPU集群，从而更好地完成大规模训练。英伟达为深度学习推出的DGX-1系统就使用了8个基于Pascal架构的GPU。   Volta (2017)  2017年，英伟达推出了适用于深度学习的Volta架构，它的设计重点之一是可以更好地分摊指令开销。Volta架构中引入了Tensor Core，用于深度学习的加速。Tensor Core可以用指令的形式与GPU连接，其中的关键指令是HMMA (Half Precision Matrix Multiply Accumulate，半精度矩阵乘积累加)，它将2个4×4 FP16矩阵相乘，然后将结果加和到一个FP32矩阵中，这种运算在深度学习中很常见。通过HMMA指令，就可以将获取指令和解码的开销通过分摊降低到原来的10%到20%。  剩下的就是负载问题。如果想要超越Tensor Core的性能，那就应该在负载上下功夫。在Volta架构中，大量的能耗和空间都被用于深度学习加速，所以即使牺牲可编程性，也不能带来太多性能提升。  Volta还升级了HBM显存，内存带宽达到900 GB/s，还使用了新版本的NVLink，可以让构建集群时的带宽增加到2倍。此外，Volta架构还引进了NVSwitch，可以连接多个GPU，理论上NVSwitch最多可以连接1024个GPU，构建一个大型共享内存机器。   Turing (2018)  2018年，英伟达推出了Turing架构。由于之前的Tensor Core大获成功，所以英伟达又顺势推出了Integer Tensor Core。因为大部分的神经网络用FP16即可训练，做推理时也不需要太高的精度和太大的动态范围，用Int8即可。所以，英伟达在Turing架构中引进了Integer Tensor Core，使性能提高到原来的2倍。  Turing架构还使用了GDDR显存，以支持那些有高带宽需求的NLP模型和推荐系统。当时有人质疑称，Turing架构的能源效率比不上市面上的其他加速器。但如果仔细计算，会发现其实Turing架构的能源效率更高，因为Turing用的是G5显存，而其他加速器用的是LPDDR内存。我认为，选择G5显存是一个正确的决定，因为它可以支持同类产品没能支持的高带宽需求的模型。  我对Turing架构深感骄傲的一点是，它还配备了支持光线追踪（Ray Tracing）的RT Core。英伟达在2013年才开始研究RT Core，在短短5年后就正式推出了RT Core。   Ampere (2020)  2020年，英伟达发布了Ampere架构，让当年发布的A100实现了性能飞跃，推理速度可达1200 Teraflops以上。Ampere架构的一大优点是，它支持稀疏性。我们发现，大部分神经网络都是可以稀疏化的，也就是说，可以对神经网络进行“剪枝”，将大量权重设置为0而不影响它的准确率。但不同神经网络的可稀疏化程度不同，这就有些棘手。比如，在保证不损失准确率的前提下，卷积神经网络的密度可以降低至30%到40%，而全连接神经网络则可降低至10%到20%。  传统观点认为，由于运算稀疏矩阵包的开销较大，所以如果密度不能降到10%以下，权衡之下不如运算密集矩阵包。我们一开始和斯坦福大学合作研究稀疏性，后来做出了很好的机器，它们在矩阵密度达到50%时也能高效运行，但要想让稀疏矩阵在电源门控（power gating）方面比密集矩阵更优越还是很困难，这是我们一直想突破的地方。最终，我们攻破难题研发出了Ampere，而秘诀就是结构化稀疏。   结构化稀疏  Ampere架构规定矩阵的每4个数值中，非零值不能超过2个，也就是通过去掉非零值对权重进行压缩。通过输入码字（code word）判断哪些权重应被保留，并用码字判断这些非零权重应该乘以哪些输入激活，然后相加，完成点乘操作。这种做法非常高效，让Ampere架构在大多数神经网络上的性能提升到原来的2倍。  此外，Ampere架构还有不少创新点，例如Ampere内置了TF32（即TensorFloat-32）格式，它结合了FP32的8位指数位和FP16的10位尾数位。Ampere还支持BFLOAT格式，BFLOAT的指数位与FP32相同，尾数位比FP32少，所以可以视为FP32的缩减版。上述的所有数据格式都支持结构化稀疏，所以无论用FP16和TF32训练，还是用Int8和Int4推理，都可以获得结构化稀疏带来的高性能。  随着Ampere在量化方面做得越来越好，它可以应用在很多神经网络上并保证高性能。Ampere有6个HBM堆栈，且HBM显存的带宽也有所升级，达到2TB/s。端到端推理时，Ampere的运算能力可达3.12 TOPS/W(Int8)和6.24 TOPS/W(Int4)。  2  GPU推理性能提升的三大因素  GPU推理性能提升的三大因素  总结深度学习过去的发展，GPU推理性能在8年内提升317倍主要归功于三大因素：  首先，最重要的是数字表示（number representation）法的发展。FP32的精度太高，导致算术运算的成本太高。后来Turing和Ampere架构支持Int8，极大提升了GPU的每瓦性能。Google发表论文公布TPU1时表示，TPU1的优势就在于它是专门为机器学习量身定制的。实际上，Google应该是在拿自家的TPU1和英伟达的Kepler进行比较（如前所述，Kepler并非专门为深度学习而设计），所以TPU1的优势归根结底可以说是Int8相较于FP32的优势。  其次，GPU支持复杂指令。Pascal架构新增了点乘指令，然后Volta、Turing和Ampere架构新增了矩阵乘积指令，让开销得到分摊。在GPU中保留可编程引擎可以带来很多好处，它可以像加速器一样高效，因为每项指令完成的任务非常多，每项指令的开销分摊几乎可以忽略不计。  最后，制程技术的进步。芯片制程从28纳米发展到如今的7纳米，为GPU性能提升作出了一定的贡献。  下列例子可以让你更好地理解开销分摊的效果：如果执行HFMA操作，“乘”和“加”2个操作合计只需1.5pJ（皮焦耳，Picojoules），然而获取指令、解码和获取操作数需要30pJ的开销，分摊下来开销就会高达2000%。   而如果执行HDP4A操作，就可以将开销分摊到8个操作，使开销下降至500%。而HMMA操作，由于绝大部分的能耗都用于负载，开销仅为22%，IMMA则更低，为16%。因此，虽然追求可编程性会增加少量开销，但采取不同的设计可带来的性能提升更加重要。  3  从单卡性能到GPU集群连接  以上谈论的都是单个GPU的性能，但训练大型语言模型显然需要多个GPU，因此还要改善GPU之间的连接方式。  我们在Pascal架构中引入NVLink，后来的Volta架构采用了NVLink 2，Ampere架构采用了NVLink 3，每一代架构的带宽都翻了一倍。此外，我们在Volta架构中推出了第一代NVSwitch，又在Ampere架构推出了第二代。通过NVLink和NVSwitch，可以构建超大型的GPU集群。另外，我们还推出了DGX box。  DGX box  2020年，英伟达收购了Mellanox，所以现在可以提供包含Switches和Interconnect在内的整套数据中心解决方案，供构建大型GPU集群之用。此外，我们还配备了DGX SuperPOD，它在AI性能记录500强名单上排行前20。以往，用户需要定制机器，现在只需要购置一台可以部署DGX SuperPOD的预配置机器，就可以获得DGX SuperPOD带来的高性能。此外，这些机器还非常适用于科学计算。  从前，用单台机器训练单个大型语言模型需要几个月之久，但通过构建GPU集群就可以大大提高训练效率，因此，优化GPU集群连接和提升单个GPU的性能同样重要。  4  深度学习加速器：新技术的试验场  接下来谈谈英伟达的加速器研发工作。英伟达把加速器视为试验新技术的载体，成功的技术最终会被应用到主流GPU中。  可以这样理解加速器：它有一个由内存层次结构输入的矩阵乘法单元，接下来要做的是让大部分的能耗用于矩阵乘法计算，而不是用于数据搬运。  为了这个目标，我们在2013左右启动了NVIDIA DLA项目，它是一款开源产品，配套非常完善，与其他深度学习加速器别无二致。但DLA有大型MAC阵列，支持2048次Int8、1024次Int16或1024次FP16操作。   DLA有两个独特之处：一是支持稀疏化。我们从容易实现的目标开始着手，所有的数据传输，包括从DMA到Unified Buffer和从Unified Buffer到MAC阵列，都只涉及非零值，通过编码决定哪些元素被留下，然后对这些元素进行解压缩，再输入MAC阵列进行运算。  DLA解压缩的方式比较巧妙，它并不向MAC阵列中输入零值，因为这会让一连串的数据都变为零。相反，它设置了单独的线路表示零值，当乘法器在任一输入中接收到该线路时，就会锁定乘法器内的数据，然后发送输出，输出的数据不会增加任何数值，这种数据门控（Data Gating）的能源效率非常高。  二是在硬件层面支持Winograd变换。要知道，如果要做卷积，例如一个m×n的卷积核，在空间域就需要n的2次方个乘法器和加法器，但如果在频域，就只需要逐点相乘。  所以大型卷积核在频域运算比在空间域运算更高效。根据卷积核大小的不同，对部分图像网络而言，Winograd变换可以带来4倍的性能提升。   EIE（2016）  2016年，我在斯坦福和我当时的学生韩松（MIT EECS助理教授、原深鉴科技联合创始人）一起研究EIE (Efficient Inference Engine)。这是对稀疏化的初步探索之一。我们在硬件层面支持CSR（Compressed Sparse Row）矩阵表示，这种做法非常高效，在密度为50%时，甚至比全密度计算还要节能。  后来发现，如果想让加速器更高效，应该构建向量单元阵列，这样每个引擎不会只执行单个乘加，而是每个循环每个PE（Processing Element）执行16×16=256个乘加。但当我们开始构建向量单元阵列时，发现很难高效实现稀疏化，于是转而采用结构化稀疏。  EIE处理标量单元时，它将指针结构储存在单独的内存中，然后通过流水阶段来处理指针结构，决定哪些数据可以相乘，继而执行乘法，将运算结果放置在合适的位置。这一整套流程运行得非常高效。  我们还发现，提高神经网络运算效率的方法除了“剪枝”实现稀疏化之外，还有量化。因此，我们决定使用码本量化（codebook quantization）。在用比特数表示的数据方面，码本量化是提升效率的最佳方法。所以我们对codebook（码本）进行了训练。  事实证明，如果你能使用反向传播来捕捉梯度下降，那就可以将反向传播运用到任何事物中。所以我们在码本中使用反向传播，训练了给定精度的最优码字集。假设码本有7个比特，那么你将得到128个码字，我们就在神经网络中找到最优的128个码字进行训练。  码本量化面临一个问题：数学运算的开销很高。因为不管码本有多大，实际数值是多少，你都需要在RAM（随机访问内存）中进行查找。实际数值必须以高精度表示，而你无法将这些码字准确地表示出来。  因此，我们在高精度数学方面花了很多精力。从压缩的角度来看，这样做的效果很好，但从数学能量（math energy）的角度来看，就显得不是很划算，所以在后续工作中我们就放弃了这项技术。   Eyeriss（2016）  Joel Emer（同时供职于英伟达和麻省理工大学）和麻省理工大学的Vivienne Sze一起构建了Eyeriss，主要解决了平铺问题，或者说是如何限制计算，以此来将数据搬运（data movement）最小化。典型的方法是使用行固定（row stationary），在行中传播权重，输出在列中激活，并最大限度地减少数据搬运消耗的能量。  SCNN（2017）  我们现在仍在进行稀疏性研究。2017年，我们为稀疏编译（神经网络的进化版）搭建了一台名为SCNN（Sparse CNNs）的机器，我们所做的是：将与处理稀疏性相关的所有复杂问题都转移到输出上。读取所有的输入激活，同时明确它们需要去往哪里，因此这里的“f宽向量”是典型的向量输入激活。我们一次会读取四个输入激活，四个权重，每个权重都需要乘以每个输入激活。这只是一个关于把结果放在哪里的问题，所以我们用f乘f计算。  在坐标计算中，我们取输入激活和权重的指数，并计算出在输出激活中需要求和结果的位置。然后在这些累加器缓冲区上做了一个数据发散（scatter_add）计算。在此之前，一切都非常有效。但事实证明，将不规则性转移到输出上不是一个好办法，因为在输出中，精度实际上是最宽泛的。当你倾向于累加，做了八位权重，八位激活，累加到了24位。在这里我们用宽位累加器（wide accumulators ）做了大量的数据搬运，效果优于做更密集一点的数据搬运。不过提升也没有想象的那么多，也许是密度单元能量的50%。  SIMBA（RC18）（2019）  我们要做的另一件事是：用现有加速器建造一个多芯片模块——SIMBA（RC18），在2018年产生了做此研究的想法，同时这款芯片也展示了很多巧妙的技术。它有一个很好的PE架构，该芯片则在其中间提供了一项非常有效的信令技术（signaling technology）。现在该架构扩展到了完整的36个芯片，其中每个芯片都有一个4x4的PE矩阵，在这个单位中，每个PE又有8个宽矢量单位，因此我们能够得到128 TOPS的运算能力，每个Op有0.1 pJ，大约相当于10 TOPS/W。从中我们学到了很多关于权衡（trade-offs）的东西。  我们意识到：构建这些PE阵列宛如建立一个非常大的设计空间（design space），关乎如何构建内存层次结构，如何调度数据等等，对此我们建立了一个叫做MAGNET的系统。   MAGNET  上图是一个于2019年发表在ICCAD（国际计算机辅助设计会议）上的设计空间探索系统，主要用于枚举其设计空间，如：每个向量单元应该有多宽，每个PE有多少向量单元，权重缓冲区有多大，累加器缓冲区有多大，激活缓冲区有多大等等。后来发现，我们需要去做另一个级别的缓存，于是添加了权重收集器和累加器收集器。  MAGNET RESULTS  通过这种额外的缓存级别，我们最终取得了成功。这表明这里的数据流是不同的，而权重固定数据流最初是由Sze和Joel来完成的。你将大部分能量投到了数据路径以外的事情上，比如投入到累积缓冲区、权重缓冲区和输入缓冲区中。但通过这些混合数据流，权重固定，局部输出固定，输出固定，局部权重固定，能够在数学运算中获得几乎三分之二的能量，并且可以减少花在这些内存阵列中的能量，从而在内存层次结构的另一个层上进行处理。这使得现在的每瓦性能达到约为20 TOPS。  VS-Quant  2021年，在MLSYS（The Conference on Machine Learning and Systems，机器学习与系统会议）会议上，我们引入了VS-Quant，以此来探索出一种在压缩比特数（这方面码本量化效果很好）和数学开销方面都很划算的量化方式。我们使用整数表示，但同时想要缩放该整数表示，以便可以表示出整数的动态范围。  但事实证明，如果你现在将其应用到整个神经网络，那么效果不会很好，因为神经网络上有很多不同的动态范围，所以VS-Quant的关键是：我们对一个相对较小的向量施加了一个单独的比例因子（scale factor），大约通过在32个权重上进行上述操作，动态范围会小得多。我们可以把这些整数放在上面，也可以对其调整优化。  也许我们没有将离群值准确地表示出来，但更好地表示出了其余数字。如此一来，我们就可以用相对低精度的权重和激活来换取较高的精度。所以我们现在有多个比例因子（scale factors ）：一个是权重因子，一个是激活因子。  Energy, Area, and Accuracy Tradeoff  我们基本上是在向量层级进行这些操作，结果如Bert-base所示。与不进行权重训练相比，我们可以通过训练在某些情况下节省20%的能量和70%的空间，上图的绿色表示基本上没有损失准确性；蓝色、橙色和红色表示准确性更高或更低。但即使在蓝色水平，准确性也相当高了。  通过VS-Quant和一些其他调整，我们在这些语言模型上进行了试运行。在语言模型上运行比在大约为120 TOPS/W的图像模型上运行要困难得多。  Accelerators  所以对于加速器，要先做一个矩阵乘法器。我们需要提出一种平铺方法，一种采用神经网络的七个嵌套循环计算方法。本质上是将其中一些循环复制到内存系统的各层，以最大限度地重复使用每层的内存层次结构，并尽量减少数据搬运。  我们还研究了稀疏性，在压缩方面很不错。它基本上增加了内存带宽和通信带宽，减少了内存和通信的能量。稀疏性发展的下一个层次是：当你有一个零值，只需单独发送一条线表示零值，而不必在每个循环中切换到8或16位。  Ampere架构可以通过使用结构化稀疏来重用乘法器，这是一种很有效的方法，只需要几个多路复用器的开销（基本上可以忽略不计）。在进行指针操作时，我们也可以重用乘法器，从中可获得2倍的性能。数值表征（number representation）非常重要。我们从EIE开始（译者注：Efficient Inference Engine，韩松博士在ISCA 2016上的论文。实现了压缩的稀疏神经网络的硬件加速。与其近似方法的ESE获得了FPGA2017的最佳论文。），试图做码本，但这使得数学上的缩放很昂贵。  最后，在加速器里试验成功的技术最终会被运用到GPU中。这是一种很好的测试方式，我们认为，GPU是一个针对特定领域硬件的平台，它的内存系统非常好，网络流畅，能够让深度学习应用运行得非常快。  5  深度学习硬件的未来  Future Directions  接下来谈谈深度学习硬件的未来。上图是一个能量流向饼状图，从中可以看到大部分都流向于数据路径，其背后有大约50%是关于数学运算，所以我们想让数学运算的能量消耗更少；剩下很多流向内存和数据搬运。其中绿色的是数据搬运，其余部分是输入缓冲区、权重缓冲区、累加缓冲区和累加收集器，占比都有不同。  我们正在研究降低数学运算的能量消耗，最好的一个办法就是将其转移到对数系统。因为在对数系统中，乘法变成了加法，而加法的耗能通常要低得多。另一个办法是转为更小的数值，这一点可以通过VS-Quant实现。通过更精确地量化，我们可以用较低的精度数从神经网络中获得同等的精度。  我们希望能将平铺做得更好，比如在某些情况下，可能会在内存层次结构中添加更多层，这样就可以降低内存能量，也可以使内存电路和通信电路的效果更好。  在Ampere架构上，我们已经在结构化稀疏的工作是一个很好的开始，但我认为我们可以通过降低密度或选择多个密度来调整激活和权重，以此做得更好。  随着研究的深入，工艺技术也会带来一些电容缩放的进展。  6  总结   2012年发布Kepler架构以来，GPU的推理性能（inference performance）每年都在翻倍增长。发展到现在，很大程度上要归功于不断更好的数字表示。本次我们谈了很多内容，比如从Kepler架构的FP32到FP16到Int8再到Int4；谈到了通过分配指令开销，使用更复杂的点积；谈到了Pascal架构，Volta架构中的半精密矩阵乘累加，Turing架构中的整数矩阵乘累加，还有Ampere架构和结构稀疏。  关于Plumbing我谈得很少，但Plumbing却非常重要。通过Plumbing来布置片上内存系统和网络，由此可以充分利用强大的Tensor Cores（张量核心）。对于Tensor Cores来说，使其在Turing架构中每秒执行一千兆的操作，并将数据输入到执行通用基准测试中，以此来安排分支存储器、片上存储器和它们之间的互连互通以及正常运行，都非常重要。  展望未来，我们准备尝试将各种新技术应用到加速器中。前面提到，我们已经就稀疏性和平铺技术进行了多次实验，并在MAGNet项目中试验了不同的平铺技术和数值表示等等。但我们仍然倍感压力，因为深度学习的进步其实取决于硬件性能的持续提升，让GPU的推理性能每年都翻一番是一项巨大的挑战。  其实我们手里的牌打得差不多了，这意味着我们必须开始研发新的技术，以下是我认为值得关注的四个方向：首先，研究新的数字表示，比如对数（Log number），以及比EasyQuant更加巧妙的量化方案；其次，继续深入研究稀疏性；然后，研究存储电路和通信电路；最后，改良现有的工艺技术。  7  答听众问  Dejan Milojicic：需要多大的矩阵卷积才能将Winograd算法转换成更高效的卷积实现？  Bill Dally：我认为，3×3的矩阵卷积就很高效。当然，卷积越大，效率越高。  Dejan Milojicic：高带宽存储器（High Bandwidth Memory, HBM）的内存带宽是如何计算的？是通过所有的GPU核同时访问内存吗？  Bill Dally：每个HBM堆栈都有一个单独的帧缓冲区，像Ampere架构有六个堆栈。我们的内存带宽是通过每个内存控制器以全带宽运行来计算的。各个GPU核之间都有一个缓存层，然后我们的片上网络的带宽是HBM带宽好几倍，所以基本上只需运行一小部分的流式多处理器就能使HBM达到饱和。  Dejan Milojicic：带有NVLink的分布式计算如何工作？谁来决定具体执行哪一个计算？在多个GPU上做scatter-gather时，哪些地方会产生开销以及会产生哪些开销？  Bill Dally：程序员会决定把数据和线程放在什么位置，而你只需在GPU上启动线程和数据以及确定它们的运行位置。采用NVLink进行连接的系统具备一大优势，那就是它是一个共享的地址空间，传输相对较小数据时的开销也相当小，所以我们在网络中采取集群通信。  通常情况下，如果你在深度学习中做数据并行，那么每个GPU都会运行相同的网络，但处理的是同一数据集的不同部分，它们会各自累积权重梯度，之后你再共享各个GPU上的梯度并累积所有梯度，然后添加到权重中。集群通信就非常擅长处理这样的工作。  Dejan Milojicic：我们到底是应该为所有应用创建通用的深度学习加速器，还是分别创建专用的加速器，比如视觉加速器或自然语言处理加速器？  Bill Dally：在不影响效率的情况下，我认为加速器当然越通用越好，英伟达的GPU在加速深度学习效率方面堪比专用加速器。真正重要的是，机器学习领域正在以惊人的速度向前发展。  几年前，大家还在使用循环神经网络处理语言，然后Transformer出现并以迅雷不及掩耳之速取代了RNN，转眼间所有人都开始使用Transformer进行自然语言处理。同样，就在几年前，每个人都在使用CNN来处理图像，虽然现在仍有不少人在使用卷积神经网络，但越来越多人开始使用Transformer来处理图像。  因此，我并不支持产品过度专用化或者为某一网络创建专用加速器，因为产品的设计周期通常需要持续好几年时间，而在此期间，人们很可能已经不再使用这种网络了。我们必须具备敏锐的眼光，及时洞察行业变化，因为它时刻都在以惊人的速度发展。  Dejan Milojicic：摩尔定律对GPU性能和内存占用有何影响？  Bill Dally：摩尔定律认为，晶体管成本会随时间逐年降低。今天，集成电路上可容纳的晶体管数量确实越来越多，芯片制程也实现了从16纳米到7纳米的飞跃，集成电路上的晶体管密度越来越大，但单个晶体管的价格却并未降低。因此，我认为摩尔定律有些过时了。  尽管如此，集成电路上能容纳更多的晶体管仍是一件好事，这样我们就能够建造更大规模的GPU。虽然大型GPU的能耗也会更高，价格也更加昂贵，但这总归是一件好事，因为我们能够构建一些从前无法构建的产品。  Dejan Milojicic：如果开发者比较重视PyTorch这样的框架，那么他们应该从硬件的进步中学习什么来让自己的深度学习模型运行更高效？  Bill Dally：这个问题很难回答。框架在抽象硬件方面做得很好，但仍然有一些影响模型运行速度的因素值得研究。我们可以尝试去做的是，当想出一项更好的技术时，比如更好的数值表示方法，可以尝试将各种不同的技术与框架相结合，看看哪种方法更加有效，这是研发工作不可或缺的环节。  Dejan Milojicic：英伟达是否正在实验新的封装方法？  Bill Dally：我们一直在对各种封装技术进行各种实验，弄清楚它们能做什么和不能做什么，以便在合适的时机将它们部署到产品。比如其中一些项目在研究多芯片模块，用焊接凸点、混合键合做芯片堆叠，其实有很多简洁的封装技术。  Dejan Milojicic：英伟达的Tensor Core和谷歌的TPU相比，谁更胜一筹？  Bill Dally：我们对谷歌最新的TPU并不了解，但他们之前推出的TPU都是专用引擎，基本上都内置了大型的乘加器阵列。  TPU独立的单元来处理非线性函数和批量归一化（batch norm）之类的事情，但我们的方法是建立一个非常通用的计算单元流式多处理器（SM），只需非常通用的指令就可以让它做任何事情，然后再用Tensor Core来加速矩阵乘法部分。因此，Tensor Core和谷歌的TPU都有类似的乘加器阵列，只是我们使用的阵列相对较小。  Dejan Milojicic：英伟达最大的对手是谁？  Bill Dally：英伟达从来不跟其他公司比较，最大的对手就是我们自己，我们也在不断地挑战自己，我认为这才是正确的态度。如果我们一味地把其他人视作竞争对手，反而放缓我们前进的脚步。不必过多关注其他人在做什么，我们真正应该关注的是哪些事情是可能实现的。我们所做的事就像在追求光速，我们更关注怎样才能做到最好，以及距离光速还有多远，这才是真正的挑战。  Dejan Milojicic：你对量子计算有何看法？量子模拟是深度学习挑战的自然延伸吗？  Bill Dally：2021年3月，我们发布了一款名为“cuQuantum”的软件开发工具包。Google之前也研制出了具有53个量子比特的计算机，并称自己实现了“量子优越性”。一些传统计算机无法完成的计算，用cuQuantum在五分钟内就能完成了。所以，如果想真正做到精准的量子算法，而不是今天的嘈杂中型量子（Noisy Intermediate-Scale Quantum，NIST）计算，GPU应该是最佳选择。  英伟达的传统GPU计算机是目前最快的量子计算机之一，阿里巴巴也在类似的经典计算中取得了不错的成绩，这恰好印证了我们的结论。我们对量子计算的看法是：英伟达不会因为这一技术领域的任何动态而感到惊讶。  实际上，我们还成立了一个研究小组来追踪量子计算领域的前沿动态，比如IBM宣布研制出了具有127个量子比特的芯片。我们也一直在跟踪量子比特数量和相干时间（coherence time）等方面的进展。  考虑到所需的量子比特数量、量子比特的准确性、噪音对量子的干扰以及量子纠错所需的开销，我认为未来五到十年内，量子计算都无法实现商用。  我最乐观的看法是，大概五年后，人们将开始进行量子化学模拟，这应该最有可能做到的。但在那之前，还有很多物理上的难题需要解决。很多人还没有意识到，量子计算机就是模拟计算机，而模拟计算机需要非常精确且易于隔离，否则任何与环境的耦合都会导致结果不一致。  Dejan Milojicic：在你看来，机器何时才能达到通用人工智能（AGI）的水平？  Bill Dally：我对这个问题的看法比较消极。试看一些比较成功的人工智能用例，例如神经网络，其实它本质上就是通用函数拟合器。神经网络可以通过观察来学习一个函数，所以它的价值还是体现在人工感知而不是人工智能。  虽然我们目前已经取得了不错的成果，但还是可以继续研究如何使用人工智能和深度学习来提高生产力，从而改善医疗、教育，给人们带来更加美好的生活。其实，我们不需要AGI来做到这些，而应该重视如何最大程度地利用现有技术。距离AGI还有很长的路要走，我们也必须弄清到底什么是AGI。 ———————————————— 版权声明：本文为CSDN博主「OneFlow深度学习框架」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/OneFlow_Official/article/details/126496148 

1、Content-Type 的简介Content-Type即互联网媒体类型，也叫MIME类型。在互联网HTTP传输数据对象中我们会为他们打上这个Content-Type的数据格式标签，用于区分数据类型。最初Content-Type只是用于电子邮件系统，随着慢慢的使用推广，我们在HTTP中也采用了这一套规范方案。现在在HTTP协议消息头中，我们使用Content-Type来表示请求和响应中的媒体类型信息，以此用来告诉服务端如何处理请求的数据，以及告诉客户端（一般是浏览器）如何解析响应的数据，比如显示图片，解析并展示html等等。2、Content-Type的常见格式类型Content-Type格式规范是这样的（Content-Type:type/subtype ;parameter） ，其中参数如下：type：主类型，任意的字符串，如text，如果是*号代表所有；subtype：子类型，任意的字符串，如html，如果是*号代表所有，用“/”与主类型隔开；parameter：可选参数，如charset，boundary等。常见的栗子有：HTML文档标记：text/html;普通ASCII文档标记：text/html;JPEG图片标记：image/jpeg;GIF图片标记：image/gif;js文档标记：application/javascript;xml文件标记：application/xml;json字符串并且使用utf-8编码：application/json;charset:utf-8;3.常用类型简介3.1 application/x-www-form-urlencodedHTTP会将请求参数用key1=val1&key2=val2的方式进行拼接然后放到请求实体里面，需要注意的是，如果是中文或特殊字符如"/"、","、“:" 等会自动进行URL转码，并且这种类型不支持文件，一般是用于表单提交的。3.2 multipart/form-data它是一个多部分多媒体类型，首先生成了一个 boundary 用于分割不同的字段，在请求实体里每个参数以boundary开始，然后是附加信息和参数名，然后是空行，最后是参数内容。多个参数将会有多个boundary块。如果参数是文件会有特别的文件域。最后以boundary为结束标识。multipart/form-data是支持文件上传的格式的，一般用于上传文件的表单。3.3 application/json顾名思义是以JSON这种轻量级的数据格式，以“键-值”对的方式拼接数据进行传输的。使用时需要参数本身就是json格式的数据，参数会被直接放到请求实体里，不进行任何处理。服务端/客户端会按json格式解析数据，一般我们在服务端创建实体类进行接收解析。3.4 application/xml 和 text/xml与application/json类似，是传输xml格式的数据，如果使用text/xml类型会忽略xml数据里的编码格式。4、Content-Type的使用 4.1 request中的Content-Type客户端发出的Request请求中的的Content-Type设置必须要准确，如果不准确的话可能会导致请求失败。在spring中，如果接口使用了@RequestBody，spring的自动解析功能会将请求实体的内容自动转换为对应的Bean，但前提是请求的Content-Type必须设置为application/json，否正就会返回415错误（415 错误是 Unsupported media type，即不支持的媒体类型）。在使用的时候可以这样来配置：如果是一个restful接口（json格式），一般将Content-Type设置为application/json; charset=UTF-8；如果是文件上传，一般Content-Type设置为multipart/form-data如果普通表单提交，一般Content-Type设置为application/x-www-form-urlencoded4.2 response的Content-Type服务端Response响应的Content-Type也必须准确，虽然前端解析响应的数据不会根据Content-Type，并且服务端一般能自动设置准确的Content-Type，但是如果乱设置某些情况下可能会有问题，比如导出文件，打开图片等。如果在spring项目里使用@ResponseBody，spring会将响应的Content-Type设置为application/json;charset=UTF-8;，可能会导致文件无法导出，需要注意下。在使用的时候可以这样来配置：如果是文件导出，Content-Type 设置为 multipart/form-data，并且添加一个Content-Disposition设置为attachment;fileName=文件.后缀。其中Content-Disposition是Content-Type的扩展，告诉浏览器弹窗下载框，而不是直接在浏览器里展示文件。因为一般浏览器对于它能够处理的文件类型，如txt，pdf 等，它都是直接打开展示，而不是弹窗下载框。以上就是Content-Type的使用和小知识点的总结。

什么是前端 你看到的就是前端，前端即网站前台部分，运行在PC端，移动端等浏览器上展现给用户浏览的网页，你看到的，就是前端。前端的基础构成 HTML、JavaScript、CSS这三个是前端开发中最基本也是最必须的三个技能。前端的开发中，在页面的布局时， HTML将元素进行定义，CSS对展示的元素进行定位，再通过JavaScript实现相应的效果和交互。HTMLHTML指的是超文本标记语言 (Hyper Text Markup Language)，这个也是网页最常用的普通的语言，经历了多个版本的发展，已经发展到5.0版了，得力于W3C建立的标准和规范，已普遍升级到了XHTML，XHTML 指可扩展超文本标签语言（EXtensible HyperText Markup Language）， XHTML 于2000年的1月26日成为 W3C 标准，是更严格更纯净的 HTML 代码，XHTML 的目标是取代 HTML。XHTML 与 HTML 4.01 几乎是相同的，XHTML 是作为一种 XML 应用被重新定义的 HTML，是一个 W3C 标准。W3C 将 XHTML 定义为最新的HTML版本。所有新的浏览器都支持 XHTML。CSS级联样式表（Cascading Style Sheet）简称“CSS”，通常又称为“风格样式表（Style Sheet）”，它是用来进行网页风格设计的。比如，如果想让链接字未点击时是蓝色的，当鼠标移上去后字变成红色的且有下划线，这就是一种风格。通过设立样式表，可以统一地控制HTML中各标志的显示属性。级联样式表可以使人更能有效地控制网页外观。使用级联样式表，可以扩充精确指定网页元素位置，外观以及创建特殊效果的能力。JavaScript是一种由Netscape的LiveScript发展而来的原型化继承的面向对象的动态类型的区分大小写的客户端脚本语言，主要目的是为了解决服务器端语言，比如Perl，遗留的速度问题，为客户提供更流畅的浏览效果。当时服务端需要对数据进行验证，由于网络速度相当缓慢，只有28.8kbps，验证步骤浪费的时间太多。于是Netscape的浏览器Navigator加入了Javascript，提供了数据验证的基本功能。前端主流框架 AngularAngularJS诞生于2009年，由Misko Hevery 等人创建，是一款构建用户界面的前端框架，后为Google所收购。 AngularJS是一个应用设计框架与开发平台，用于创建高效、复杂、精致的单页面应用，通过新的属性和表达式扩展了 HTML，实现一套框架，多种平台，移动端和桌面端。 AngularJS有着诸多特性，最为核心的是：MVVM、模块化、自动化双向数据绑定、语义化标签、依赖注入等等。ReactReact 起源于 Facebook 的内部项目，因为该公司对市场上所有 JavaScript MVC 框架，都不满意，就决定自己写一套，用来架设 Instagram 的网站。React采取了一种特立独行的操作DOM的方式。它并不直接对DOM进行操作。它引入了一个叫做虚拟DOM的概念，安插在JavaScript逻辑和实际的DOM之间。这一概念提高了Web性能。在UI渲染过程中，React通过在虚拟DOM中的微操作来实对现实际DOM的局部更新。React是基于组件化的开发，页面是由若干个小组件组成的大组件。VueVue 是一套用于构建用户界面的渐进式的js框架，发布于 2014 年 2 月。与其它大型框架不同的是，Vue 被设计为可以自底向上逐层应用。Vue 的核心库只关注视图层，不仅易于上手，还便于与第三方库（如：vue-router，vue-resource，vuex）或既有项目整合。Vue渐进式框架的核心概念为：组件化，MVVM，响应式，和生命周期。 Vue将组成一个页面的HTML，CSS和JS合并到一个组件中，可以被其他组件或页面引入而重复利用。三者的相同点都是基于javascript/typescript的前端开发库，为前端开发提供高效、复用性高的开发方式都有组件和模板的开发思想各自的组件都有生命周期，不用的组件可以卸载，不占用资源都支持指令，如样式、事件等的指令三者的区别创始和发行不同：Angular是由google提供支持的，初始发行于 2016年9月；React由Facebook维护，初始发行于 2013年3月；Vue是由前google人员创建，初始发行于2014年2月应用类型不同：Angular支持开发native应用程序、SPA单页应用程序、混合应用程序和web应用程序；React支持开发SPA和移动应用程序；Vue支持开发高级SPA，开始支持native应用程序模型不同：angular基于MVC（模型-视图-控制器）架构；react和vue是基于Virtual DOM（虚拟的文档对象模型）数据流流向不同：Angular使用的是双向数据绑定，React用的是单数据流的，而Vue则支持两者。对微应用和微服务的支持不同：Angular使用的是TypeScript，因此它更适合于单页Web应用（single page web application，SPA），而非微服务。相反，React和Vue的灵活性更适合微应用和微服务的开发。对原生应用的支持不同：React Native为iOS和Android开发原生应用；Angular的NativeScript已被原生应用所采用，特别是Ionic框架已经被广泛地运用在制作混合应用等方面；Vue的Weex平台正在开发之中，尚无下一步使之成为全面跨平台的计划。框架和库：Angular 是一个框架而不是一个库，因为它提供了关于如何构建应用程序的强有力的约束，并且还提供了更多开箱即用的功能。React 和 Vue 是是一种库，可以和各种包搭配。组件之间传值方式不同：Angular 中直接的父子组件，父组件可以直接访问子组件的 public 属性和方法，也可以借助于@Input 和 @Output 进行通讯。没有直接关系的，借助于 Service 单例进行通讯；React 组件之间通过通过prop或者state来通信，不同组件之间还有Rex状态管理功能；Vue组件之间通信通过props ，以及Vuex状态管理来传值。智能云网 智能云网社区是华为专为开发者打造的“学习、开发、验证、交流”一站式支持与服务平台，该平台涵盖多领域知识。目前承载了云园区网络，云广域网络，数通网络开放可编程，超融合数据中心网络，数通网络设备开放社区共五个场景。为了响应广大开发者需求，还提供了开发者交流、API 体验中心、多媒体课件、SDK工具包、开发者工具以及远程实验室共六大工具，让开发者轻松开发。欢迎各位前来体验。《戳我了解更多》

说明：未按升级要求进行软件包升级，会导致升级失败，恢复出厂设置也没用，只能后台手动配置.一、检查小站 /home/data 目录下是否有ies目录没有下载附件的ies文件 解压到 /home/data 目录下。然后执行第二步，手动安装升级系统。升级完重启后web虽然可以打开，但密码登不了，需要执行第三步，重置小站，在命令行恢复下出厂设置。二、手动安装系统，安装流程如下：1.安装7-zip软件：用来解压和压缩下载的hpm包。在自己的PC机上百度搜索下载一个。2.下载软件包：https://www.hiascend.com/hardware/firmware-drivers?tag=community3.在本地将hpm软件包解压到最终的文件列表，需要连续提取3次如下图；4.将最终的软件列表重新打包成 .zip包并上传到500小站的：/var/run目录5.解压.zip软件包，并移动解压的所有文件至/run目录6.把原始压缩包删除：7.另起一个新的窗口查看是否有异常报错8.在/run目录找到upgrade.sh脚本并给予可执行权限后运行：大概2-3分钟chmod 777 upgrade.sh./upgrade.sh 31 /run -f9.看到成功提示，reboot重启10确认是否升级成功三、shell下重置小站示例1：不保留IP地址进行远程恢复出厂设置。Euler:~ # ies_tool restore_factory Warning: you has't restored any IP address.IP address will be set to default after restore factory. The system will be restored to factory settings, including the user name, password and so on.Are you sure want to continue? Y/N示例2：保留IP地址进行远程恢复出厂设置。Euler:~ # ies_tool restore_factory -e eth0The system will be restored to factory settings, including the user name, password and so on.Are you sure want to continue? Y/N四、异常处理A、升级中间件失败1.需要切换到 /opt/middleware/ 目录下，将AtlasEdge文件删除，然后重新运行升级命令B、web页面无法打开1.检查nginx是否正常启动，有标记进程及为服务正常，正常如下图：异常为：2.若未正常启动，运行启动命令：systemctl restart platform-app ,同时查看massage日志，看看是否有下图提示的权限错误：3.切换到/opt/middleware/目录下，给MindXOM文件755权限后重新启动服务，输出正常图片后web功能可正常使用。

没文档也要扒源码让 ShardingSphere 支持 openGauss SCRAM 前端认证本人有幸参与了 openGauss 众智计划《ShardingSphere 对接 openGauss》，让我学习到了很多与 openGauss 数据库协议、安全等方面的知识。本文主要记录如何在没有协议文档的情况下，根据 openGauss JDBC Driver 源码，让 ShardingSphere openGauss Proxy 支持 openGauss 的 SCRAM SHA-256 前端认证机制。前言目标：让 ShardingSphere openGauss Proxy 支持以 SCRAM SHA-256 机制验证 openGauss 客户端的身份。最近在做一个和 ShardingSphere Proxy openGauss 前端认证方式相关的 issue ShardingSphere openGauss Proxy supports sha256 authentication method #13995。PostgreSQL 有一种前端认证方式是 MD5 Password。客户端根据服务端提供的 salt 对密码进行 MD5 加密并发送，完成认证过程。但 MD5 安全性比较有限，openGauss 前端认证推荐并默认使用 SHA-256。虽然说是 SHA-256 认证，听起来就是与 PostgreSQL 的 MD5 认证大同小异，只是摘要的长度不一样，后来做起来才发现完全不是这样。openGauss 用的是 SCRAM，其中的哈希算法可以使用 SHA-256 或者国密算法。在做这个 issue 之前，我不了解 SCRAM，其他安全相关知识也了解不深，实现过程也是费了一些心思。环境准备openGauss 数据库与客户端本文所使用的 openGauss 数据库及 gsql 均使用 Docker Image enmotech/opengauss:2.1.0openGauss JDBC Driver 使用 org.opengauss:opengauss-jdbc:2.0.1-compatibility<dependency> <groupId>org.opengauss</groupId> <artifactId>opengauss-jdbc</artifactId> <version>2.0.1-compatibility</version> </dependency>openGauss 服务端配置enmotech/opengauss:2.1.0 默认使用了 MD5 认证方式，需要修改各项配置为 sha256 并新建用户。postgresql.conf 需要配置：password_encryption_type = 2pg_hba.conf 需要配置：host all all 0.0.0.0/0 sha256配置完成后需要重启或执行 gs_ctl reload 生效。最后创建一个新用户：CREATE USER wuweijie PASSWORD 'Wuweijie@123';没有文档？去扒一下客户端源码看看是怎么做的。确定 SHA-256 认证方式的枚举值可能是一般的用户与开发者不会关心数据库协议，openGauss 的文档中没有包含对协议细节的说明，包括本次要做的 SCRAM SHA-256 前端认证，openGauss 文档说明了如何配置，但没有说明如何实现。没有文档怎么办？就像之前实现 openGauss 批量协议一样，看一下客户端是怎么做的。 private static final int AUTH_REQ_MD5 = 5; // 省略部分代码... private static final int AUTH_REQ_SHA256 = 10;PostgreSQL MD5 认证方式的枚举值为 5，openGauss 所增加的 SHA-256 认证方式枚举值为 10。确定 Auth Request 数据包的内容openGauss JDBC Driver 认证相关关键逻辑节选及本文注释说明： case AUTH_REQ_SHA256: { // 省略部分代码... byte[] digest; int passwordStoredMethod = pgStream.receiveInteger4(); // 省略部分代码... if (passwordStoredMethod == PLAIN_PASSWORD || passwordStoredMethod == SHA256_PASSWORD) { String random64code = pgStream.receiveString(64); String token = pgStream.receiveString(8); byte[] result = null; // 由于 openGauss 最新的客户端都使用 3.51 的协议版本，以下分支只需关心最后的 else if (this.protocolVerion < PROTOCOL_VERSION_350) { // 省略部分代码... } else if (this.protocolVerion == PROTOCOL_VERSION_350) { // 省略部分代码... } else { // 本次实现只看本分支 int server_iteration = pgStream.receiveInteger4(); result = MD5Digest.RFC5802Algorithm(password, random64code, token, server_iteration); } if (result == null) // 省略部分代码... pgStream.sendChar('p'); pgStream.sendInteger4(4 + result.length + 1); pgStream.send(result); pgStream.sendChar(0); pgStream.flush(); break; } else if (passwordStoredMethod == MD5_PASSWORD) { // 省略部分代码... } else { // 省略部分代码... } // 省略部分代码... }代码中的方法 RFC5802Algorithm 也就是 SCRAM。大致明确 Auth Request 数据包的结构综上，如果要把 ShardingSphere Proxy 伪装成 openGauss 数据库服务端进行 SCRAM SHA-256 认证，需要发送的数据包长这样：Byte1('R') 表明这个消息是个认证请求。 Int32(88) 消息内容的长度（以字节为单位），包括长度自身，不包括消息类型。 Int32(10) 表明使用的认证方式为 SHA-256。 Int32(2) 表明用户的密码存储方式使用的是 SHA-256。 Byte64 random64code 长度为 64 的字符串，含义暂时不清楚，根据命名猜测类似 salt，参与 SCRAM 计算。 Byte8 token 长度为 8 的字符串，参与 SCRAM 计算。 Int32 server_iteration 一个整数，参与 SCRAM 计算。从客户端接收到的数据包长这样：Byte1('p') 表明这个消息是个认证响应。 Int32 消息内容的长度（以字节为单位），包括长度自身，不包括消息类型。 String 一个以 '\0' 结尾的字符串。Wireshark 抓包观察从源码层面了解了数据包的格式后，通过 Wireshark 抓包偷窥 openGauss 客户端与数据库的交互过程。当数据库收到客户端发送的 Startup 消息后，给客户端响应了一个类型为 R 的消息，要求客户端按照协议完成身份认证。以下为服务端发送给客户端的数据：因为 Wireshark 只支持解析 PostgreSQL 协议，openGauss 特有的消息在 Wireshake 里体现为 Malformed Packet。下图中数据包的结构用不同颜色的方框标注，可以看出数据的结构跟前面明确的数据包结构一致。（看不清可以点开大图）再看以下客户端返回的信息，根据之前明确的数据包结构，客户端的认证消息里面只有一个字符串，所以客户端发送的是一个长度为 64 的字符串。（69 - 长度字段本身 4 - '\0' 结尾字符）实现过程创建对应的消息定义Proxy 发送给客户端的认证请求节选：OpenGaussAuthenticationSha256Packet.javapublic final class OpenGaussAuthenticationSha256Packet implements PostgreSQLIdentifierPacket { private static final int AUTH_REQ_SHA256 = 10; private static final int PASSWORD_STORED_METHOD_SHA256 = 2; private final byte[] random64Code; private final byte[] token; private final int serverIteration; @Override public void write(final PostgreSQLPacketPayload payload) { payload.writeInt4(AUTH_REQ_SHA256); payload.writeInt4(PASSWORD_STORED_METHOD_SHA256); payload.writeBytes(random64Code); payload.writeBytes(token); payload.writeInt4(serverIteration); } @Override public PostgreSQLIdentifierTag getIdentifier() { return PostgreSQLMessagePacketType.AUTHENTICATION_REQUEST; } }客户端发送给 Proxy 的认证响应直接复用了 PostgreSQLPasswordMessagePacket.java，代码节选：public final class PostgreSQLPasswordMessagePacket implements PostgreSQLIdentifierPacket { private final String digest; public PostgreSQLPasswordMessagePacket(final PostgreSQLPacketPayload payload) { payload.readInt4(); digest = payload.readStringNul(); } @Override public void write(final PostgreSQLPacketPayload payload) {} @Override public PostgreSQLIdentifierTag getIdentifier() { return PostgreSQLMessagePacketType.PASSWORD_MESSAGE; } }实现校验逻辑首次实现校验逻辑的时候，我还不了解 SCRAM 的逻辑，于是我就按照 MD5 认证方式的实现方式去做。实现思路：把客户端对密码的处理方式在 Proxy 重现一遍，最后把客户端发送的认证数据和 Proxy 内计算产生的结果对比。Proxy 在认证请求里需要给客户端发送两个字符串 random64code 和 token，那就随机生成；整数 server_iteration 看到代码里在协议 3.50 里写死 2048，那此处就取 2048：public OpenGaussAuthenticationEngine() { random64Code = RandomStringUtils.randomAlphanumeric(64); token = RandomStringUtils.randomAlphanumeric(8); serverIteration = 2048; }初步验证写了一段简单的程序验证：（5433 是 openGauss，55433 是 ShardingSphere Proxy openGauss）//try (Connection connection = DriverManager.getConnection("jdbc:opengauss://127.0.0.1:5433/postgres", "u3", "Wuweijie@123")) { try (Connection connection = DriverManager.getConnection("jdbc:opengauss://127.0.0.1:55433/freedom", "wuweijie", "Wuweijie@123")) { try (PreparedStatement preparedStatement = connection.prepareStatement("show all variables")) { try (ResultSet resultSet = preparedStatement.executeQuery()) { while (resultSet.next()) { System.out.println(resultSet.getString(1) + " -> " + resultSet.getString(2)); } } } }部分输出：sql_show -> true sql_simple -> false能够正常连接 ShardingSphere Proxy openGauss 并通过认证，于是就形成了这个 PR：Add SHA256 authentication for openGauss Proxy #14002无意间发现问题第二天想着当时只用了 openGauss JDBC Driver 验证，要不试试 gsql：wuweijie@wuweijie-ubuntu /home/wuweijie % docker run --rm -i -t --network host enmotech/opengauss:2.1.0 gsql -h 127.0.0.1 -Uwuweijie -W'Wuweijie@123' -p 55433 freedom gsql: FATAL: password authentication failed for user "wuweijie"结果发现认证失败！以同样的方式直连 openGauss 却没有问题，可能是我的实现方式有问题。但是 openGauss 在协议方面没有文档，我也不知道应该怎么做。问了一下 openGauss 的专家，得到一个参考文档：openGauss支持国密SM3和SM4算法除了哈希算法不一样，SCRAM 的机制是一样的。这时候我才进一步了解 SCRAM 这种机制。调整 Proxy 校验逻辑后面我根据以下参考资料调整了 Proxy 的校验逻辑。以上图片来源于：之前的变量名对应关系如下：random64code -> salttoken -> nonce调整后的逻辑大致如下：private static boolean isPasswordRight(final ShardingSphereUser user, final Object[] args) { String h3HexString = (String) args[0]; String salt = (String) args[1]; String nonce = (String) args[2]; int serverIteration = (int) args[3]; byte[] serverStoredKey = calculatedStoredKey(user.getPassword(), salt, serverIteration); byte[] h3 = hexStringToBytes(h3HexString); byte[] h2 = calculateH2(user.getPassword(), salt, nonce, serverIteration); byte[] clientCalculatedStoredKey = sha256(xor(h3, h2)); return Arrays.equals(clientCalculatedStoredKey, serverStoredKey); }再次验证实现完了，使用之前的 Java 代码验证 openGauss JDBC Driver 能够通过认证。再用 gsql 验证，居然还是报错：wuweijie@wuweijie-ubuntu /home/wuweijie % docker run --rm -i -t --network host enmotech/opengauss:2.1.0 gsql -h 127.0.0.1 -Uwuweijie -W'Wuweijie@123' -p 55433 freedom gsql: FATAL: password authentication failed for user "wuweijie"又试了一下 2.0.0 的版本，同样报错：wuweijie@wuweijie-ubuntu /home/wuweijie % docker run --rm -i -t --network host enmotech/opengauss:2.0.0 gsql -h 127.0.0.1 -Uwuweijie -W'Wuweijie@123' -p 55433 freedom gsql: FATAL: password authentication failed for user "wuweijie"再次 Review 并修改看逻辑没看出什么问题，再次观察 Wireshake 窃听到的 openGauss 数据库发送给客户端的数据包：发现我之前遗漏了细节：在数据包的 random64code 和 token 参数部分，数据值的字符只有 [a-f0-9]，而我用的随机字符串生成方法是 [A-Za-z0-9]。random64Code = RandomStringUtils.randomAlphanumeric(64); token = RandomStringUtils.randomAlphanumeric(8);调整随机字符串生成方法并重命名变量：saltHexString = generateRandomHexString(64); nonceHexString = generateRandomHexString(8); private String generateRandomHexString(final int length) { ThreadLocalRandom random = ThreadLocalRandom.current(); StringBuilder result = new StringBuilder(length); for (int i = 0; i < result.capacity(); i++) { result.append(Integer.toString(random.nextInt(0x10), 0x10)); } return result.toString();再次验证。最终验证gsql 输出结果：[~] docker run --rm -i -t --network host enmotech/opengauss:2.1.0 gsql -h 127.0.0.1 -Uwuweijie -W'Huawei@123' -p 55433 freedom gsql ((openGauss 2.1.0 build 590b0f8e) compiled at 2021-09-30 14:29:04 commit 0 last mr ) Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. freedom=> show all variables; variable_name | variable_value ---------------------------------------+---------------- sql_show | true sql_simple | false kernel_executor_size | 0 省略部分输出 transaction_type | LOCAL (20 rows)用之前的代码验证 openGauss JDBC Driver，部分输出：sql_show -> true sql_simple -> false两种客户端都能完成认证，于是再提一个 PR。Refactor openGauss frontend SCRAM SHA-256 authentication #14073完成！回顾如果一开始能够正确生成随即字符串，第一个 PR 的做法应该也是能够达到身份认证的目的的，但这不符合 SCRAM 的做法。本次众智计划，让我学习到了很多与 openGauss 数据库协议、安全等方面的知识。后续再做类似的事情的时候，一定要先了解清楚相关知识，比如本次的 SCRAM。不明确字段含义的时候，一定要多观察特征、细节转载自:https://bbs.huaweicloud.com/forum/thread-194427-1-1.html

大多数物联网产品在设计上并不安全。事实上，它们是最近网络犯罪激增的主要原因。一份报告显示，2019 年上半年发生了29 亿起网络事件。研究人员特别指出物联网 (IoT) 的扩散以及 Windows SMB 是主要原因。通过芯片到云物联网的去中心化技术可能是这些问题的答案。物联网在消费者和商业技术层面带来了几乎无数的改进机会。个人用途包括智能家居和智能汽车，物联网为工业环境中的众多网络物理系统提供监督，并以前所未有的方式促进数据移动。围绕物联网的猖獗网络安全问题导致一些技术专家呼吁采用不同类型的架构。芯片到云物联网看起来是一种很有前途的方式，可以为所有人构建更安全、更有用和去中心化的技术。当前的物联网安全出了什么问题？到 2030 年，全球可能有500 亿台联网设备，其中包括智能手机、个人电脑、传感器以及工业世界车辆和机器车队中的嵌入式逻辑控制器。这些设备中的每一个都是一个互联网节点，其中任何一个都可能是网络安全链中的薄弱环节。当前构建物联网设备的方法，从根本上来说不安全，有几个原因：物联网设备通常缺乏运行板载安全工具的处理能力。物联网设备的采用者经常无法更改出厂默认密码，黑客很容易猜到。物联网是一种相对不成熟的技术，没有经验的用户很容易错误配置网络和设置。尽管计算能力有限，物联网设备仍然可能感染恶意软件。尽管联网机器和设备具有提高企业规划和维护响应能力的所有潜力，但它们可以为设施内部网和企业网络提供一个无人看管的后门。如果它们没有正确构建和部署更是如此，这就是为什么 IT 专家经常细分网络以将 IoT 设备与组织的其他业务或访客流量隔离并隐藏起来。然而，这仍然没有解决物联网的根本缺陷问题。人们需要重新思考物联网产品中的芯片如何与互联网以及彼此之间进行通信，以带来更强大的物联网安全性。芯片到云是去中心化的物联网芯片到云架构提供了一种创建与物联网云平台直接连接的安全、低能耗设备网络的方法。各地的组织都发现他们必须转向云优先的技术堆栈，但到目前为止，构建这种基础设施的集体努力是浪费的、低效的和不安全的。IT 专业人员保护物联网设备的传统途径是基于防火墙和其他不托管在机器本身上的安全产品，这是芯片到云架构试图解决的根本弱点。物联网设备的主要弱点之一是它们缺乏计算能力和板载安全措施，使用芯片到云物联网安全构建的产品比其前身更强大、更安全，同时保持节能，这归功于以下几个特点：板载加密引擎随机数发生器足够的随机存取存储器 (RAM)这些芯片组特性赋予了额外的安全优势，由于每个物联网节点的密码学唯一性，黑客要欺骗其身份并劫持其访问更广泛的业务网络变得更加困难。如果物联网的前身是 Web 2.0 的一部分，那么芯片到云物联网是迈向 Web 3.0 或只是“Web3”的决定性一步。活跃于这一新兴领域的技术人员表示，这些设计原则将把权力平衡转移回数据移动的受益者，物联网设备的消费者或价值创造者，而不是集中的供应商。在边缘收集的数据也可以在那里处理和使用。芯片到云通过消除边缘节点和准备对信息采取行动的逻辑程序之间的流量停止，使其比以往更快。“设计安全”一词适用于芯片到云的物联网架构。新一代工具旨在为新旧设备提供增值数据移动功能，就像当前的物联网一样。但是，芯片到云芯片组始终与云连接。这将大大提高资产可用性，并使节点、部门或设施之间的数字通信速度更快。从芯片到云如何去中心化物联网?本质上，它最分散的是安全协议。传统的物联网涉及在现有的、否则不受保护的连接设备云上放置防火墙和其他第三方保护，想象一把伞保护着一个 12 口之家。现在，想象一下，同一个 12 口之家，但每个成员在倾盆大雨时都有自己的雨伞，这是芯片到云的物联网。每个设备都拥有一个强大的、单独保护的芯片组，使其成为比普通物联网设备更强大的链中的一环。芯片到云是分散技术，因为每个节点直接向云控制器或分析程序报告，而不是向中介报告，这代表了事物安全方面的另一个胜利，以及一种减少数据包在接收者之间移动时的延迟和丢失的方法。芯片到云之后会发生什么？最近的全球事件正在广泛地看到对云技术和特别是芯片到云架构的大量投资。公司和组织需要数据来支持他们的客户关系门户、企业规划工具和机器维护平台，而物联网可以提供这些。然而，即使使用芯片到云技术，物联网也不够安全。组织需要为每项新的 IT 投资制定详细的设备管理协议、专注于安全警戒和培训的文化，以及明智地选择技术合作伙伴的专业知识。向 Web 3.0 的过渡将从这里继续，随着时间的推移，芯片到云可能会加入并与其他 Web 3.0 技术（如区块链）相结合，以进一步增强其实用性和安全稳健性。看看世界上真正的价值创造者如何使用这些强大的新工具，这一切都将会很有趣。

摘抄实验手册1，安装eclipse，并配置tomcat参考链接：https://blog.csdn.net/zeroheitao/article/details/1089707132，创建web工程双击实验桌面Eclipse图标打开Eclipse。点击File->New->Dynamic Web Project,如下图所示设置一个项目名称，如“test”点击“Finish”，如下图所示完成后项目结构如下图：鼠标点击“webapp”目录后点击鼠标右键创建一个JSP File文件，并命名为“index.jsp”，如下图所示：点击“Finish”完成创建。在页面输入一些文字并保存（Ctrl+s）如下图所示：点击下方“Servers”窗口，鼠标右键“Tomcat v9.0…”选择“Add and Remove...”如下图所示：在弹出框选择“test”点击“Add”添加，然后点击“Finish”，如下图所示：点击启动Tomcat，如下图所示：启动完成若没有自动弹出浏览器页面，可以切换至浏览器新建一个页面，在地址栏输入：localhost:8080/test/index.jsp ,运行项目成功访问页面。访问成功，说明项目创建成功，可打包使用。3，打包项目鼠标右键“test”项目，选择“Export”->“WAR file”，如下图所示：在弹出的窗口点击“Browse…”这里选择打包后项目保存路径，选择保存到实验桌面，如下图所示：点击选择“Desktop”后，点击“OK”，选择路径完成点击“Finish”完成项目打包。说明：请按照手册填写项目名称及打包保存路径，名称或路径不一致该步骤检测不成功。4，创建鲲鹏云服务ECS（略）5，部署web项目使用工具将war包上传到服务器中（这里我使用moba）连接服务器：ssh root@EIP登陆成功，执行以下命令切换到“/usr/local/src ”目录下：cd /usr/local/src执行以下命令，获取Tomcat软件包。wget https://sandbox-experiment-resource-north-4.obs.cn-north-4.myhuaweicloud.com/kunpeng-web/apache-tomcat-9.0.33.tar.gz tar -zxvf apache-tomcat-9.0.33.tar.gz输入以下命令，复制软件包到部署目录下cp /root/test.war /usr/local/src/apache-tomcat-9.0.33/webapps/输入以下命令启动Tomcat：sh /usr/local/src/apache-tomcat-9.0.33/bin/startup.sh切换至浏览器输入地址 EIP:8080/test/index.jsp 并访问，访问成功

华为云官网2022-05-05日已发布Web UI SDK的第一个商用版本，也有不少客户有需求使用Web UI SDK，下面总结一下近期客户集成过程中咨询到问题：1：集成Web UI SDK不能创建会议嘛？对浏览器有要求吗？      Web UI SDK当前只支持Windows端的chrome浏览器和MAC端的Safari浏览器加入会议，不能在浏览器创建会议，会议创建可以在portal上进行；2：Web UI SDK支持接入微信小程序吗      不支持；3：集成Web UI SDK，web端入会报错11084016:join cms room fail              11084016这个报错，是企业没开通WebRTC入会；如需开通请联系您企业对接的SA，由SA进行申请开通；      （另注：网络研讨会不需要，普通会议要开权限；要在开通权限之后重新创建会议，加入会议 验证是否正常）4：WebSDK加入会议，网页端摄像头打不开，打开麦克风别人听不到声音；       可能的原因：由于浏览器安全策略限制，仅支持通过https://域名的方式访问，或者直接在本地搭建服务器，通过localhost:端口访问，否则无法获取摄像头及麦克风的权限。5：用华为云会议的 web sdk加入了会议，共享屏幕共享不了；控制台提示[client] [publishImpl fail, errMsg = TypeError: Cannot set properties of undefined (setting 'id')]      可能原因：浏览器103版本以上，需要升级webrtc-sdk到1.0.7版本；      此处提供下Web UI SDK   1.0.7版本 下载链接：https://esdk.obs.cn-north-1.myhuaweicloud.com/huaweimeeting/hwmsdk-webrtc-1.0.7.zip 

【功能模块】【鲲鹏代码迁移工具】》【安装】【操作步骤&问题现象】1、下载的是Porting-advisor_2.5.RC1_linux-Kunpeng.tar.gz2、按照鲲鹏代码迁移工具，“安装”页面提示，执行install web（使用的是root账户）。3、遇到输入password提示，但未提示输入谁的密码，尝试多次依然失败（使用 Porting-advisor_2.3.0_linux-Kunpeng.tar.gz  包安装遇到同样问题失败）4、比较奇怪的是可以成功安装cmd。【截图信息】【日志信息】（可选，上传日志内容或者附件）

[作者按] Solv 研究组的系列文章 《Web3 国际市场危机分析》已经发表了三篇。这一系列的文章，主要是从美元稳定币的创造、流动和配置的视角来分析本轮 Web3 国际市场危机的一些深层原因。我收到一些读者的评论，认为部分内容比较专业，对基础要求较高，尤其是涉及到货币经济的一些行文表述，让一部分读者理解起来吃力。实际上为了能够让大部分读者能够理解，我们在写作中已经尽量采用文字来描述问题和阐述观点，避免使用更加专业的工具。这样看来，授人以鱼不如授人以渔，我们可能应该给读者一些学习建议，或者补充一些基础知识，这对于那些对 Web3 感兴趣的读者，可能是有帮助的。为此，我计划发表三篇短文，第一篇介绍学习 Web3 的一些基础知识，第二篇介绍资产负债表在 Web3 和 DeFi 分析当中的一些应用，第三篇推荐几本书。希望这些文章能帮助读者在 Web3 的学习中少走弯路。这几篇文章与 Solv 研究组的危机系列分析文章并行发表，先到先发，不拘于特定次序。Web3 是经济、金融、法律、机制设计等经济社会学科与 IT、数学、密码学等数字信息科技交叉整合的新领域，它如此之新，以至于不仅没有出现权威学者，甚至连一个基本知识体系都没有梳理出来，人们连该学什么都不知道。大多数从业者不具备相关基础知识和基本观念，一边不着边际胡思乱想，一边赤手空拳乱打乱撞，导致很多肤浅荒谬的观念流行，搞出很多从根子上就是虚妄的项目。结果，一个好端端的未来数字科技，闻上去跟神拳教大师兄气味相仿。另一方面，大多数学富五车的学者则居高临下，先入为主，生搬硬套一些来自传统世界的理论和模型，极少有人愿意躬身入局，亲自耕耘这野蛮而充满活力的新大陆，因此对于现实缺乏基本的解释能力，更谈不上预测和引领趋势。可以说，Web3 现在完全是一片理论的蛮荒之地。在这种情况下，如果我跳出来提出一个 Web3 和数字资产的“知识体系”或者“学习路径”，那肯定是自不量力、别有用心了，读者大可以把我当成贩卖大力丸的江湖骗子叱责之。但是，以我七年以来的区块链和 Web3 学习从业经验和所见所闻，在读了上百本书、研究跟踪了几十个项目，并且在海外亲自创业实践的经历，如果说功夫没有全然白花、还稍有点心得的话，倒是可以总结几点，比如：整天去分析某个数字资产或者某个 NFT 为什么会火，试图总结其“基本面”规律，把握财富密码，是全然徒劳，而且通常是适得其反，乃插标卖首之学；各种交易秘籍、技术分析、历史模型，基本都是见光死，意义参考上一条。即使存在有效的技术分析模型，也不会放出来让你看到，能让你看到的肯定是无效的；一些投资理念、投资哲学的东西，似乎有帮助，又说不出具体有什么帮助，读之若有所思，用之则无从下手；大数据分析和数据可视化当然是各行各业都离不了的基本工具，Web3 也不例外，但人工智能、机器学习这些高级技术，对于预测 Web3 市场意义极其有限，却经常能给你虚假的自信，引导你做出错误决策；经济学的思维方式是有用的，帮助我们从市场经济的基本原理来理解和看待 Web3，判断总体发展趋势，但专业经济学者花费最多时间讲授和研究的那些宏观微观模型，则绝大多数毫无用处；奥地利学派的自由主义经济思想、货币和商业周期理论和对于理解 Web3 的价值主张以及行业中的市场周期颇有帮助，但其中也包含了大量艰深复杂而关系不大的思辨；新制度经济学有价值，里面很多理论对于我们理解网络协作、自治组织、合约关系等 Web3 的重要话题很有帮助；金融学中，资产组合理论在思维上是很有启发的，实践当中则难以应用；对于 DeFi 的读者来说，基本金融工具和衍生品的知识非常有用，但是那些估值模型、定价理论以及随机微分方程的各种公式，至少在现在这个阶段没有什么用处。不过，能够气定神闲地随口说出 “Alpha收益”、“Beta 收益”、“systematic risk”、“idiosyncratic risk”、CAPM 和 APT 模型，对于社交确有好处，国内外皆然。至于更高级的术语，多说则无益有害；如果亲自搞 Web3 创业，懂一点公司金融和财务报表是有必要的，尽管大多数 Web3 创业公司都没有严格的财务报表制度，但是这个知识技能确有价值，而且大概率将来能用上；在互联网时代发展起来的信息经济学，比如网络效应导致的自然垄断，结合经济学基础知识学习，对于理解行业格局，制定发展战略，非常有帮助；博弈论，理论上应该是本行业最有用的学问之一，不过实际上，博弈论现有的结论和工具远远解决不了 Web3 的真实问题，可以说相差甚远。学习博弈论的主要价值可能也是在社交中使用“囚徒困境”、“纳什均衡”等术语的时候更加自信。以上这些，主要还是我自己的主观感受，也并不十分有把握，读者参考一下就好，如果反对，我也无意争论。下面才是重点。有四门学问，我可以保证对于学习和理解数字资产和 Web3 确实有帮助，我自己学了以后受益确凿，推荐给朋友和同事以后，也反馈良好，基本上没有人说是白花功夫，故我可以非常自信地列举如下：第一，智能合约开发部署的基本知识和技能。若要真正理解区块链，懂一点智能合约开发、部署、触发执行等等基础知识，是必要的。反过来说，如果你真的懂了智能合约，也就具备了区块链的基础知识了。所以很多人要学习区块链，看一大堆理论书籍，可能总还是觉得隔着一层。这种情况下，如果有一点编程基础，倒不如直接学习智能合约技术，当心一剑，戳个通透，省得在旁边绕圈圈。第二，系统思考。也就是基于系统论的观点，通过反馈回路、存量流量的分析，定性地认识系统的运动规则，加深理解，增强洞察力。这是一种非常通用的认识方法，自然对 Web3 也管用。不过，系统思考历史上是系统动力学的一部分，但系统动力学对于 Web3 来说则过犹不及，希望对复杂系统的发展变化进行数学建模和精确仿真。对于 Web3 这么复杂的社会经济系统来说，实用性不高，误导性不低。因此，只需要了解系统思考就足够了，不必深入系统动力学。第三，货币和金融发展史，以及围绕货币的政治经济学议题。这一部分侧重于从货币的角度来看待各个国家的经济发展，以及全球政经格局演化，最近十多年来是全球中文圈的显学，相关图书资料可谓汗牛充栋，有不少书籍写得通俗生动，其中当然也有一些哗众取宠、煽风点火，近乎志怪演义，但诚意之作也不少，需要留心鉴别，交叉验证。读史使人智慧，Web3 本身也是货币金融体系发展到新阶段，与数字科技结合的产物，未来也必将被写入到历史当中，因此了解货币和金融是如何一路走过来的，对于理解 Web3 非常有益处。这种好处，未必是你能够直接拿出来当成工具使用，而是潜移默化地开阔你的视野，深化你的思考，特别是能够给你很多参考模型和故事，帮助你在面对选择和需要决策的时候更加明智。第四，中央银行学、金融市场与金融机构。这可能是对于理解和应用 Web3、DeFi 和通证经济最为有用的单一学科，通常是货币经济学的一部分，比如这个领域的一部名著就是米什金的《货币、银行和金融市场经济学》，光看书名就知道是一门大学问，包含不少内容，广而言之就是从“钱”的流动角度来看现实世界的经济运行。不过其中的内容对于学习 Web3 来说有远近之分，比如商业银行相关的理论跟 Web3 就没有什么关系，因为像商业银行那样通过信贷创造流动性的方式，恐怕在可见的未来都不会见容于 Web3 世界。货币理论、特别是宏观经济学中涉及到货币需求量的几个模型，乍一听好像很有价值，其实只具有认识上的参考意义，实践当中完全用不上，找一本经济学入门书看看相关章节即可。真正特别实用的部分，就是中央银行货币政策及工具，以及金融市场与金融机构。这一部分主要探讨中央银行、商业银行和其他非银金融机构如何基于市场机制相互配合，把货币从银行系统这个心脏中创造出来，然后再通过各种金融工具在市场上泵送给经济各部门，并调节优化，达成一系列政策目标。这些知识对于 Web3 行业运行机制的理解、周期的判断，以及具体到 Web3 通证经济机制的设计，都有非常直接的参考价值，因此我建议在这个方向上投入较多的时间。我对几个朋友和同事都给出了这样的建议，他们当中能够塌下心来认真学习一段时间的人，很快对于整个 Web3 和数字资产的认识就会得到一个升级。我的主要建议就是这样。不过另一方面，也得提醒一下，所有前面提到的种种，全都是传统的知识，没有一个是为 Web3 创建的学问，更没有一个能“保送”你成为 Web3 高手。如何将这些旧酒装到 Web3 这个新瓶里，这正是你自己要去解决的问题。不过，另一方面，这也是机遇所在。另外，如果要研究 Web3 的某一个具体的应用分支，比如游戏、电商、交易，肯定还有很多更专业东西需要掌握。但是依我看来，今天学习 Web3 的人，普遍缺少的是经济、货币、金融方面的正确认识，而不是其他，因此在上面的推荐中我重点覆盖了相关内容。缺少认识，却勇于创新，读得太少，想得太多，胆子太大，这是很多 DeFi 和 Web3 项目崩溃的一个主观原因。希望本文能帮助有心的读者稍探路径，在学习 Web3 时少走弯路，多些分寸。《Web3 国际市场危机分析》系列文章：市场危机分析｜其一：DeFi 伪创新导致市场失灵市场危机分析｜其二：Crypto 市场的美元化流动性视角中 CeFi 的功与过————————————————版权声明：本文为CSDN博主「myan」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/myan/article/details/125795577

以证件号码（既有纯数字字符串，也有数字字母混合的字符串）为例，通过js代码获取数据对象executeScript后（方法可参考[executeScript]快速完成网页数据的填充/JS脚本操作网页的方法分享/js/），通过assign赋予明确的数据类型为string，而不是让RPA自动识别数据类型，避免后续运行eval表达式、字符串子串截取时出现数据类型不匹配。

导入证书是原因是应为浏览器需要和软终端进行wss链接，改链接需要用到证书。但是有个问题就是需要手动在浏览器导入根证书。有没有办法做到不需要手动导入证书到浏览器。菜鸟一枚。恳请大佬们给与帮助。非常感谢

        我十分荣幸能够参加openLooKeng Web UI增强项目，这是我接触的第一个项目，在这个项目中我学到了很多东西，成长了很多，也收获了很多。在做项目的过程中，不仅强化了我的写代码能力，也接触到了前沿的技术和理念。       openLooKeng Web UI增强项目主要包括以下业务：openLooKeng审计日志功能增强 openLooKeng SQL历史记录查询功能增强SQLEditor支持自动联想支持常用sql语句的收藏前端异常标记显示数据源       在刚开始接手这个项目的时候，我手足无措，不知道从哪里入手。同时，对于第一次做项目的我而言，openLooKeng项目的代码量绝对可以用“庞大”这个词来形容了。仅仅是阅读并理解前端的主要代码都耗费了将近一周的时间，并一度陷入焦虑，怀疑自己到底能不能把这个项目要求的功能完整实现。这个时候，我感受到了团队的力量。一个人的力量毕竟有限，不论是智力，能力还是精力，都有所不能及的地方，集一个团队的力量，发挥整个团队的作用，这样就能解决更多的问题，战胜更多的困难。学长给予了我很多指导和帮助，并且让我有了信心。在他的帮助下，我更快地进入到了工作状态，提高了工作效率。       通过参加华为openLooKeng  Web UI增强项目，让我对前端开发有了更进一步的认知以及更深入的学习，并且让我对React框架更加熟悉，对JavaScript语言有了更深层次的了解，对前后端交互认识的更加透彻。同时，也让我认识到，在整个项目周期，计划显得格外的重要，只有进行详细的计划，我们才能各施其职，各尽其责，也才有紧迫感，并要求自己抓紧时间完成当天的任务。这样就不会畏首畏尾，也不至于不知道下一步该干什么，不会遗漏掉太多东西。当然，就算制定了一个计划，如果没有按照那个计划来，或者拖沓松懈，有今天不能完成明天做的思想，总觉得有的是时间，把大量的任务往后压，就达不到预期的效果。此时，组长的带头作用以及监督作用就很有必要，严格按照计划执行，是计划行之有效的强有力保证。       从一开始的手足无措到后面独立完成自己对应的任务，可以清晰地看到我的成长，同时也离不开老师的教诲与学长的指导，我非常感恩参加openLooKeng Web UI增强项目的这一段经历，“逼”着我迈出了舒适圈，尝试自己涉足未深但即将踏入的领域，给我带来了很多收获，同时也让我认识到了自己很多的不足。如果以后有机会，我愿意更多地参加华为的项目，在提升自己的同时，也能为祖国的发展贡献出自己的绵薄之力！华中科技大学——杨劲帆指导老师：甘早斌

非常荣幸可以参加 openLooKeng Web UI增强项目的开发，在此项目中跟着学校老师和华为团队学到很多的东西。在项目中不仅学习到了前沿的技术，还锻炼了我的学习能力和动手能力。从项目初期，到项目经过了一段时间之后，对项目有了整体的把握，对各环节有了更清晰的认识与规划。这对我来说是一个全新的领域。于是从零开始一步步搭建环境，编码开发，集成测试。在此过程中，除了克服自己负责区域的困难之外，对于有需要和衔接的问题，还与小组成员一起在一次次的磨合中找出了解决方案，有妥协，有商量，分阶段对成果进行总结，分析，改进，及时调整研究方向的偏差，尽力保证项目质量。通过参加这次 openLooKeng Web UI增强项目的开发，我们都有了很多收获。首先是对这种项目的进一步认识。在 openLooKeng Web UI增强项目中强调的是自主性、探索性、实践性和协作性，强调项目实施过程中在创新思维和创新实践方面的收获，重在参与过程中充分发挥主观能动性，运用所学的知识，使自己得到锻炼和提高。回想自己参加openLooKeng Web UI增强项目的经历，从开始对项目内容的理解认识到项目计划的讨论和确定，从对项目的整体把握到寻找突破点，并制定详细的项目方案和进程，以及项目当中重要的实践环节，整个openLooKeng Web UI增强项目的过程中我不仅学到了许多我所感兴趣的、觉得有用的东西，更重要的是自己的思维能力、团队协作能力、实践能力都得到了提高，而且也学到了坚持不懈、善于思考、积极总结的可贵精神。这次的项目对我来说是个很好的体验，感谢学校老师和华为团队。参与此项目即提升了自己的能力，又为祖国的伟大复兴贡献了自己的力量。华中科技大学---孙锐指导老师：甘早斌

       我非常荣幸参加了鲲鹏openLooKeng集群管理平台项目的方案设计。我从需求分析，方案调研，方案设计，系统开发、测试、部署以及文档编写等环节中受益良多，与华为团队的合作也让我体会到了一个优秀公司对于项目开发的严谨与求真。       我们的任务是开发一套管理平台，供方便的集群部署功能和集群管理功能，降低用户搭建openLooKeng集群的难度。在指导老师的带领下，对项目需求分析和相关集群管理平台的功能调研，我们主要从三个方面进行评估方案设计：      1. 平台搭建的简易度       通过上面openLooKeng的需求分析和相关集群管理平台的功能参考，对比发现CDH、Ambari在配置主机的时候都相对复杂，用户需要登录物理服务器去进行配置。       我们对集群管理平台的设计理念是简化用户实际操作服务器的步骤。同时考虑对openLooKeng平台不熟悉的用户能有更好的体感，平台需增加引导安装功能，帮助用户快速完成openLooKeng管理平台的搭建。openLooKeng搭建的业务流程设计为：添加主机-->创建集群（选择已添加的运行主机、选择角色）-->属性配置-->完成安装。相应页面设计如下：• 添加主机：• 新建集群：• 属性配置：       2. 页面布局       对比相关集群管理平台的页面布局及风格：       1）CDH、Ambari对于主机和集群的监控展示较为丰富，rainbond的页面布局和风格更加简洁和美观。       2）可视化监控方面，Ambari的监控看板更加灵活。      openLooKeng集群管理平台可进行参考设计如下： 数据看板:        • 主机监控：        • 集群监控：        • 实例监控：         3. 用户体验         openLooKeng集群管理平台对于用户而言必须操作方便，我们将复杂的代码编写转变成web页面操作，设计的页面简洁而功能灵活丰富，其主要功能操作页面如下：         • 属性配置          coordinator=1个时的基础配置            coordinator>=2个，进入基础配置&HA配置（基础配置下方多出两项配置：状态存储、文件系统）。          • 版本升级：分为在线、离线两种方式。          集群/实例在线升级：           集群/实例离线升级：          • 集群/实例功能操作：启动、停止、升级、卸载、重启功能，还可以查看实例列表，对单个或多个实例进行关闭、重启、升级、卸载、配置的操作。          在【集群概览】页面点击“访问地址”路径进入集群使用平台，对实例监控运行情况或功能操作：         • 主机（实例）的伸缩           添加主机：          日志下载：           对主机实例的功能操作:           好的方案设计是团队所有成员共同努力、相互协作的成果。在项目开发过程中我们特别感谢华为涂盛霞团队老师们的辛苦付出，老师们积极、严谨、友好沟通的态度，是我们学习的标杆！苏州旺满信息科技有限公司-旺满鲲鹏openLookeng团队-王海琴指导老师：王满海