BTC为何重要

Posted 2023-04-11 密密码码

价值投资的程式化观点通常会导致较低的会计倍数，但在我们追求以低于其内在价值的价格进行资产交易时，我们会尝试对“价值”进行更广泛的定义。我们的方法是一种概率方法，这意味着我们试图考虑未来可能影响资产价值的各种潜在状态。然后，我们确定资产在少数代表性情景下的价值，将每个情景的价值乘以我们认为它可能发生的概率，然后将这些值相加得到“价值的集中趋势”。我们对比特币的思考过程是我们概率价值方法的一个代表性例子，尽管该资产可能不会触及更多传统价值投资者的雷达屏幕。所以，我们先简单介绍一下比特币，然后再谈一个估值框架。

比特币是一种没有中央权威的电子点对点货币。开发人员社区管理管理货币的协议，他们还处理交易以换取额外的比特币单位。这些交易的记录是比特币的技术突破，也是它与传统货币最根本的区别——开发者社区维护着一个名为“区块链”的开放式账本，它跟踪自比特币诞生以来的所有交易。开放式账本与交易数据的复杂性相结合，使得比特币相对于某人的信用卡成为一种非常安全的支付方式，信用卡依赖于一组简单的数字来进行许多交易。与Visa (V)和其他支付网络相比，比特币的最大优势之一是万事达卡 (MA)是最低交易费用。虽然其他支付网络通常收取约 3% 和 0.15 美元中​​的较大者，但比特币的交易费用往往是交易中可忽略不计的一部分，如果有的话。较低的交易费用不仅使买卖双方能够以对双方都有利的价格进行交易，而且还可以在与低价、低利润商品和服务的 0.15 美元附加费不兼容的市场中实现小额支付。比特币的另一个独特方面是它的固定供应量。虽然目前有 1460 万比特币在流通，但总供应量限制为 2100 万。固定的供应和民主化的权威防止任何一个政权为了自己的利益而改变系统；事实上，每个参与者也被激励以最大化比特币的价值。

我们使用上述背景作为估值案例的起点。该系统的技术突破、安全性、低交易成本和去中心化特性都意味着没有人知道该系统可能变得多么有价值。但是，如果采用率增长，其作为支付系统的总价值也应该增长。考虑到分母的供应有限，以比特币的市值衡量的系统价值不断增长应该意味着比特币的价值不断增长。

我们认为，如果比特币流行起来，它可能会有巨大的上涨空间，但我们承认，众多障碍意味着实验更有可能失败。尽管如此，如果采用继续增长并且货币蓬勃发展，考虑比特币的价值仍然很重要。比特币最大的梦想是实现黄金的价值存储地位。这个类比显然存在问题，因为比特币不能被制成珠宝（另一方面，你不能用金锭购买商品和服务，而你可以用比特币购买）。据世界黄金协会称，自诞生之日起，已开采的黄金不到 175,000 吨。以每金衡盎司 1,133 美元的现货价格计算，这意味着曾经开采的所有黄金的总价值为 6.4 万亿美元。如果比特币在 2100 万枚硬币的基础上实现了这一资本化，那么每枚硬币的价值约为 314,000 美元，即当前价格 230 美元的 1,365 倍。尽管如此，我们承认这是一个延伸且极不可能的可能性，因此我们假设它发生的可能性为 0.25%。比特币的另一个奇妙结果将是取代 Visa、MasterCard 和 American Express 等收费较高的处理器，这些处理器如今的总市值接近 3.5 亿美元。如果比特币能够捕捉到这一价值，那么一个比特币的价值将接近 17,000 美元。这仍然不太可能，但比黄金的价值储备地位更有可能。让我们假设发生这种情况的几率为 2.5%。这使我们有 97.25% 的可能性认为比特币是失败的并且一文不值。然而，使用上述假设，

另一个比较点也可能表明该货币被严重低估了。所有未偿比特币的总价值为 $3.4B，这使加密货币的存量介于斐济元 ($3.1B) 和海地古德 ($3.5B) 1的总货币供应量之间。比特币比这两种货币中的任何一种都具有更大的潜力，尽管比特币的流动性更高，买卖价差更小，但其价值却相似。

虽然比特币的机制使我们在策略中拥有比特币成为问题，但上面的思考过程有助于解释为什么我们都个人拥有比特币。对于大多数希望将比特币添加到多元化投资组合中的投资者来说，它一文不值的可能性很高，但考虑到比特币的巨大潜力，这似乎是一个引人注目的价值主张。

云原生时代，API 网关为何如此重要？

【CSDN 编者按】API是Application Program Interface，应用程序连接接口的缩写，作为数据传输流转的重要通道，API网关更成为云原生时代的重要入口。

作者 | 温铭，Apache APISIX PMC主席       

责编 | 张红月

出品 | CSDN（ID：CSDNnews）

API 是各个不同的应用程序和系统之间互相调用和传输数据的标准方式。在很多的开发团队中都是使用 API-first 的模式，围绕着 API 来进行产品的迭代，包括测试、Mock、文档、API 网关、Dev Portal 等，这就是 API 全生命周期管理（Full Life Cycle API Management）。

API 解决的问题

在 API 出现之前，数据的传输和交换并没有标准的方式，大多数情况下是通过数据库、Excel 表格、文本，或者是 FTP，不同的系统和程序通过各种五花八门的方式来沟通。这些混乱的背后，隐藏了巨大的开发成本和安全隐患：权限控制、数据精细管控、限流限速、审计等，都只能用笨重的方式来解决。这就是计算机世界中的“巴别塔”（Tower of Babel），因此只有解决了不同语言开发的系统以及不同存储方案带来的问题，才有机会构建足够复杂的产品。

而 API 的出现，则成功地解决了巴别塔问题，开发者只需要关心其他系统对外暴露的 API 即可，无需关心底层实现和细节。

我们熟知的手机 App、网络游戏、视频直播、远程会议和 IoT 设备，都离不开终端设备与服务端的连接和数据传输，这些都是通过 API 完成的。

为什么需要 API 网关

API 网关是 API 全生命周期管理的关键基础组件，负责生产环境中 API 的配置、发布、版本回滚、安全、负载均衡等。API 网关是所有终端流量的入口，负责把终端的 API 请求路由到正确的上游服务进行处理，然后再把返回的数据返回给原始请求方，同时保证整个过程的安全、可靠和低延迟。

在最开始 API 数量不多的情况下，API 网关往往是一个由 Web Server 和上游服务两部分拼接而成的虚拟组件：由 Apache 和 NGINX 等组件完成最简单的路由转发、反向代理和和负载均衡，其他功能比如身份认证、限流限速等，则依靠上游服务自身进行实现。

但随着 API 的数量越来越多，喜欢“偷懒”的开发者们发现了一个严重的问题：他们需要在不同的上游服务中，重复实现身份认证、限流限速、日志等通用的功能，这不仅会浪费开发资源，而且一旦需要修改这部分的代码，就需要修改很多代码，这是版本管理和升级维护的噩梦。怎么办呢？聪明的开发者们很快就找到了解决方案：把这些通用的功能抽象到一个统一的组件中，把上述的两层结构改为一层结构，从上游的逻辑代码中剥离与业务无关的功能，然后增强 Apache 和 NGINX 这类组件。这就是第一代 API 网关的诞生过程。

让 API 网关承载更多非业务逻辑的功能，这就是 API 网关一直以来的进化方向。在这个过程中，前端开发者和后端开发者们，为了让产品能够更快的迭代，就对 API 网关提出了越来越多的需求，并不仅仅局限于负载均衡、反向代理、身份认证等传统功能，还在 gRPC、GraphQL、可观测性等方面提出了很多新的功能。

API 网关的作用

为了让 API 网关更灵活高效，开发者们在底层上也做了非常多创新，比如：

• 功能插件化。随着 API 网关上承载的功能越来越多，如何让这些功能之间更好的隔离以及让二次开发变得更加简单？插件，是完美的解决方案。因此，现在主流的 API 网关均采用插件来实现各种功能，比如在 Apache APISIX 中叫做 Plugins，在 Envoy 中则称之为 Filters，它们的含义是相同的。插件化可以让网关的开发者不再关心底层实现，用较少的开发资源就可以实现一个新的功能。

• 数据面和控制面的分离。在第一代 API 网关的实现中，数据面和控制面是在同一个进程中实现的，这样足够简单，但也带来了很大的安全隐患。由于数据面是直接对外提供服务的，如果被黑客入侵，就有机会获取到控制面的数据（比如 SSL 证书）和控制权，造成更大的破坏。因此，现在大部分的开源 API 网关，都是将两者分别部署的，中间通过关系型数据库或者 etcd 来进行配置的管理和同步。

以 Apache APISIX 为例，下面的架构图，诠释了以上两个创新：

云原生时代下的挑战

过去十年，IT 领域最大的技术变革就是云原生。诞生于 2013 年的 Docker 拉开了云原生的帷幕，从此裸金属、虚拟机开始被容器所替代，单体架构开始被微服务所替代。但是云原生并不是简单的技术革命，其背后的推动力主要来自互联网产品的快速发展和激烈竞争，云原生相关的技术生逢其时，迅速流行并替代了之前的很多技术组件和方案。

具体到 API 网关在云原生中的挑战，主要来自以下两个方面：

单体架构到微服务的转型

在微服务架构逐渐被开发者认可和落地后，该架构释放了巨大的技术红利：每个微服务可以按照自己的节奏进行升级和发布，不需要担心与其他服务的耦合。产品的迭代因此变得敏捷，每天都可以进行几十次甚至几百次的发布。

但与此同时，微服务的发展也带来了一些副作用，比如：

• API 和微服务的数量从最初的几十个，增长到几千个，甚至几万个；

• 出现故障时如何快速定位是哪一个 API 引起的？

• 如何保证 API 的安全？

• 如何做到服务熔断和服务降级？

API 网关无法独立解决安全性、可观察性、灰度发布等问题。它需要与 Prometheus、Zipkin、Skywalking、Datadog、Okta 等众多开源项目和 SaaS 服务合作，为企业提供更好的解决方案。

动态和集群化管理

容器和 Kubernetes 的普及，让动态成为所有云原生基础组件的标准特性。在 Kubernetes 的环境中，容器在不断的生成和销毁，弹性伸缩成为一个必选项而不是可选项。

想象一个场景：一家互联网电商公司做了一次促销，大量的用户在一个小时内涌入，促销结束后就会离开。对于传统架构的公司来说，他们需要事先采购一批物理服务器，来应对这些高峰时候的 API 流量；但是对于云原生架构的公司来说，就可以随时使用公有云上的弹性资源，根据 API 请求的数量，自动的调整网络、计算、数据库等资源的规模即可。那么伴随着容器弹性伸缩而来的技术挑战如下：

• 上游服务不断更换 IP 地址和端口;

• IP 黑白名单的频繁更新;

• 服务健康的及时检测和异常处理;

• API 的频繁发布;

• 服务注册和发现的及时性;

• SSL 证书的热更新和自动轮转。

想要解决上述这些挑战，均需要依赖于动态。以 NGINX 为代表的第一代 API 网关，动态能力是非常弱的。因为 NGINX 是本地静态配置文件驱动的，所以变更任何配置都需要重启 NGINX 服务才能生效，这在云原生时代是不能被企业接受的。这就是第一代 API 网关的技术痛点之一。

在中国，有一家类似微软 Office 365 的 SaaS 办公软件公司 -- WPS，他们有数百台物理机在运行着 Apache APISIX，有近万核 CPU 在处理来自客户端的 API 请求，每天处理数百亿次 API 请求。

在这个超大规模的 API 网关环境下，开发者不可能去逐个修改每一个 API 网关的配置然后 Reload，他们希望有一个统一的控制台来操作整个集群。可惜的是，第一代 API 网关诞生的年代，并没有这么大的实例规模，也就没有考虑集群管理的需求。

下一代 API 网关的发展

上述挑战和痛点，逐渐催生了新一代的 API 网关。

和第一代 API 网关不同的是，云原生时代诞生的下一代 API 网关是在开源社区的驱动下快速成长的。借助社区和众多开源贡献者的力量，这些 API 网关有机会形成一个正向的迭代和进化：

• 更快速的收集一线开发者及用户的需求和痛点

• 在开源项目中尝试解决这些问题

• 开源项目变得更加好用，吸引更多开发者使用

于是，我们看到下一代 API 网关突破了传统网关的负载均衡和反向代理的定位，而是承担起了 API 和流量的连接、调度、过滤、分析、协议转换、治理、集成等更多的职责。

支持更低成本的二次开发

同时，让开发者能够以更低的成本进行二次开发，也成为了下一代 API 网关的亮点。集成是 API 网关的重要功能之一，对于下游是协议解析和各种协议的转换，包括 GraphQL、gRPC、Dubbo 等；对于上游是集成 Okta、Keycloak、Datadog、Prometheus 等身份认证、可观测性服务，以及公司内部的认证、日志、审计等服务。API 网关不可能覆盖集成过程中所有的组件，这时候不可避免地需要开发者通过插件的方式进行二次开发，来满足自己的业务需求。不同的 API 网关提供了不同的二次开发的编程语言和开发方式，Apache APISIX 和 Kong 都可以使用 Lua 来编写原生插件，Envoy 是使用 C++ 编写原生插件。同时，Apache APISIX 还可以使用 Go、Python、Node、Java 和 Wasm 来编写插件，这些主流的开发语言已经可以覆盖绝大部分开发者了。

开发者不必去学习 Lua 和 C++，就可以使用自己熟悉的编程语言在下一代 API 网关上进行开发，这让基础组件的开发变得更加简单。开源和易于二次开发，是下一代的 API 网关最重要的特点，它把更多的选择权留给了开发者自身，同时，开发者也可以更加放心的在多云、混合云的环境下使用 API 网关，不用担心被云供应商锁定。

基于双十一的 API 网关流量处理场景

这里，我们用一个具体的例子来解释下现代 API 网关的作用。

在双十一时，电商都会有各种各样的商品促销活动，这段时间的 API 请求量是平时的几十倍。让我们先来看下如果没有 API 网关将会是怎样的技术架构：

可以看到，在 Order 和 Payment 服务中，身份认证和日志记录功能是重复的。一个电商的服务，一般会有数千个不同的服务组成，这时候就会有大量的代码和功能是重复开发的。

下面是增加了 API 网关之后的架构图：

 

从上图可以看到，我们在 API 网关层统一了公共的服务，后端服务只需要关心自身业务，为弹性伸缩提供了更多可能。

当促销开始时，客户端大量 API 请求涌入 API 网关的时候，后端服务需要进行快速的弹性伸缩，为了保障关键业务不受突发流量的影响，我们需要在 API 网关上识别恶意爬虫并实现限流限速、服务降级和熔断。此时，我们可以暂时关闭部分服务，比如商品评价、快递查询等。

但是库存信息、购买功能、支付功能等核心业务是绝对不能出现故障的，因此我们需要通过 K8s 来管理容器服务，再生成更多的服务副本来保证它的正常运行。此时 API 网关需要将客户端的 API 请求路由到新生成的副本服务，并且自动移除出现故障的服务，如下图所示。

总结

API 网关并不是一个新的基础中间件，而是在产品快速迭代和技术架构的变迁中，变得越来越重要。而下一代云原生 API 网关的出现则解决了企业用户在集群管理，动态，生态，可观测性以及安全性等方面的痛点。

API 网关不仅可以处理 API 的流量，也可以来处理 Kubernetes Ingress 和服务网格的流量，进一步降低开发者的学习成本，帮助企业更好的统一管理流量。

— 推荐阅读 —