一、中心极限定理的基本概念

中心极限定理是说：
样本的平均值约等于总体的平均值。
不管总体是什么分布，任意一个总体的样本平均值都会围绕在总体的整体平均值周围，并且呈正态分布。

接下来，我们用通俗易懂的话来解读这个定理。

 

假设有一个群体，如我们之前提到的清华毕业的人，我们对这类人群的收入感兴趣。怎么知道这群人的收入呢？我会做这样4步：

第1步：随机抽取1个样本，求该样本的平均值。

例如我们抽取了100名毕业于清华的人，然后对这些人的收入求平均值。

该样里的100名清华的人，这里的100就是该样本的大小。

有一个经验是，样本大小必须达到30，中心极限定理才能保证成立。

 

第2步：我将第1步样本抽取的工作重复再三，不断地从毕业的人中随机抽取100个人，例如我抽取了5个样本，并计算出每个样本的平均值，那么5个样本，就会有5个平均值。

这里的5个样本，就是指样本数量是5。

 

第3步：根据中心极限定理，这些样本平均值中的绝大部分都极为接近总体的平均收入。有一些会稍高一点，有一些会稍低一点，只有极少数的样本平均值大大高于或低于群体平均值。

第4步：中心极限定理告诉我们，不论所研究的群体是怎样分布的，这些样本平均值会在总体平均值周围呈现一个正态分布。

二、中心定理的应用案例

根据《2017年中国家庭财富调查报告》调查数据显示，2016年我国家庭人均财富大约为16.9万元（169077元）

（其中，房产净值是家庭财富最重要的组成部分。在全国家庭的人均财富中，房产净值的占比为65.99%）

现在假设我们随机抽样1000个中国家庭并询问他们的年收入。

根据已知的这些信息，从中心极限定理出发，你能得出什么信息？

下面我们一起来用中心极限定理进行推理。

 

1）根据中心极限定理，我们可以得出的第1个结论是：用样本来估计总体。

任何一个样本的平均值将会约等于其所在总体的平均值。

例如你久居大城市，过年回老家，大街上遇到了邻居大妈，虽然20年没见你，邻居大妈还是一眼认出你了，这不是隔壁老王家的孩子嘛，长的真带劲。

这里，你爸妈就是总体，你就是你爸妈的样本，和你爸妈长的相似。

同样的，一个正确抽取的家庭样本应该能够反映中国所有家庭的情况，里面会包含收入高的公司高管，也会包括普通的员工，快递小哥、警察以及其他人，这些人出现的频率与他们在人口构成中的占比相关。

因此，我们能够推测，这个包含1000个中国家庭代表性样本的家庭财富的平均值约等于总体的平均值。

 

2） 样本平均值呈正态分布

在这个例子中，样本平均值将会围绕着群体平均值（也就是16.9万元）形成一条正态分布曲线。记住，群体本身的分布形态并不重要，中国家庭收入的分布曲线并非正态分布，但样本平均值的分布曲线却是正态分布。

如果我们连续抽取100次包含1000个家庭的样本，并将它们的平均值的出现频率在坐标轴上标出，那么我们基本可以确定在总体平均值周围将会呈现正态分布。

取样次数越多，结果就越接近正态分布；而且样本大小越大，分布就越接近正态分布。

现在我们已经可以用样本来估计出总体平均值。现在我想用样本来估计出总体的标准差，该怎么办呢？

我们已经知道，一个数据集的标准差是数值与平均值的偏离程度。

当你选择一个样本后，相比总体，你拥有数据的数量是变少了，因此，与总体中的数值偏离平均值的程度相比，样本中很有可能把较为极端的数值排除在外，这样使得数值更有可能以更紧密的方式聚集在均值周围。

也就是说，样本的标准差要小于总体标准差。

所以，为了更好的用样本估计总体的标准差，统计学家就将标准差的公式做了像下面图中公式中这样的改造。

3）如何用样本估计总体？

现在我们已经可以用样本来估计出总体平均值。现在我想用样本来估计出总体的标准差，该怎么办呢？

我们已经知道，一个数据集的标准差是数值与平均值的偏离程度。

当你选择一个样本后，相比总体，你拥有数据的数量是变少了，因此，与总体中的数值偏离平均值的程度相比，样本中很有可能把较为极端的数值排除在外，这样使得数值更有可能以更紧密的方式聚集在均值周围。

也就是说，样本的标准差要小于总体标准差。

所以，为了更好的用样本估计总体的标准差，统计学家就将标准差的公式做了像下面图中公式中这样的改造。

 

即原来的标准差公式是除以n，为了用样本估计总体标准差，现在是除以n-1。这样就是的标准略大。一般用字幕s表示用样本估计出的总体标准差。

很多书上都会把除以n-1的标准差叫做样本标准差，其实会给人造成误解。其实这个样本标准差的目的是用于估计总体标准差。

你可能会疑惑，那我什么时候标准差除以n还是n-1呢？

那就要看你使用标准差的目的是什么。

如果你只是想计算一个数据集的标准差，那么就除以n，例如你有100个毕业与清华人的收入，只是想了解这100个人构成的数据集的波动大小，那你就用除以n的标准差公式。

如果你想把这100个人当成一个样本，用这个样本来估计出总体（所有毕业与清华人的收入）的标准差，那么就除以n-1的标准差公式。

 

我们在看下什么是标准误差？

标准差是用来衡量数据集的波动大小。比如毕业于清华大学所有人的收入分布。

标准误差其实也是标准差，只不过它是所有样本平均值的标准差。

结合我刚才给的图片中的例子就更容易理解了。

如果我从毕业于清华大学中抽取100个人作为样本1，然后我计算出标准差。那么这个标准差就是用来描述这100个人组成的数据集的波动大小。

我连续刚才重复抽取样本的动作，最后抽取出2个样本，每个样本都有100个人。对每个样本计算平均值，这样就有2个平均值。

这2个平均值其实组成了1个新的数据集，就是所有的“样本平均值”。然后对这2个平均值数据计算出标准差。就是标准误差。

你看，标准误差其实也是标准差，只不过它的计算对象是所有的“样本平均值”。所以，标准误差是用来衡量总体样本平均值的波动大小。

其实，计算标准误差有个简单的公式。下面图片我们一起看下。

标准误差SE等于总体标准差除以n的开方。但是我们不知道总体标准差怎么办。其实前面我们已经讲了可以用样本来估计出总体标准差的公式s。

 

根据中心极限定理，我们知道样本平均值是呈正态分布的，那么我们便可以通过这里图片中的样本平均值概率图来获得推理所需的“超能力”。

看到这个图是不是很熟悉，这个图其实就是前面我们讲过的正态分布概率图，只不过这里的横轴是样本平均值的大小，纵轴是该平均值出现的概率。这里是标准误差。

在前面介绍正态分布的时候，我们已经知道了正态分布的一个奇特超能力，应用到样本正态分布上，那就是：

1）有68%的样本平均值会在总体平均值一个标准误差的范围之内

数值范围（总体平均值-1个标准误差，总体平均值+1个标准误差）

2）有95%的样本平均值会在总体平均值的两个标准误差的范围之内

（总体平均值-2个标准误差，总体平均值+2个标准误差）

3）有99.7%的样本平均值会在总体平均值3个标准误差的范围之内。

（总体平均值-3个标准误差，总体平均值+3个标准误差）

 

假如某个样本的平均值减去总体的平均值，大于3个标准误差。根据99.7%的样本平均值会处于总体平均值3个标准误差的范围内，因此我们可以得出该样本不属于总体。

 

中心极限定理也就是这么两句话：

1）任何一个样本的平均值将会约等于其所在总体的平均值。

2）不管总体是什么分布，任意一个总体的样本平均值都会围绕在总体的平均值周围，并且呈正态分布。

 

三、中心极限定理的应用场景

1）在没有办法得到总体全部数据的情况下，我们可以用样本来估计总体

如果我们掌握了某个正确抽取样本的平均值和标准差，就能对估计出总体的平均值和标准差。

举个例子，如果你是北京西城区的领导，想要对西城区里的各个学校进行教学质量考核。

同时，你并不相信各个学校的的统考成绩，因此就有必要对每所学校进行抽样测试，也就是随机抽取100名学生参加一场类似统考的测验。

作为主管教育的领导，你觉得仅参考100名学生的成绩就对整所学校的教学质量做出判断是可行的吗？

答案是可行的。中心极限定理告诉我们，一个正确抽取的样本不会与其所代表的群体产生较大差异。也就是说，样本结果（随机抽取的100名学生的考试成绩）能够很好地体现整个群体的情况（某所学校全体学生的测试表现）。

当然，这也是民意测验的运行机制所在。通过一套完善的样本抽取方案所选取的1200名美国人能够在很大程度上告诉我们整个国家的人民此刻正在想什么。

 

2）根据总体的平均值和标准差，判断某个样本是否属于总体

如果我们掌握了某个总体的具体信息，以及某个样本的数据，就能推理出该样本是否就是该群体的样本之一。

通过中心极限定理的正态分布，我们就能计算出某个样本属于总体的概率是多少。如果概率非常低，那么我们就能自信满满地说该样本不属于该群体。

 

 

 

 

 

内容简介

在这本实用指南中，作者解释了为什么去中心化应用（dapp）将比现在最流行的 Web 应用得到更广泛的使用以及实现更多盈利，展示了如何使用现有工具来创建可用的 dapp 及其市场，并研究了目前两个成功的 dapp 案例。读者将了解到区块链的加密存储台账、scarce-asset 模型和点对点技术如何提供比当前软件模型更灵活、更具激励性的结构。

• 了解使去中心化数据、财富、身份标识、计算和带宽成为可能的分布式系统技术有何优势
• 利用 Go 语言、去中心化架构、去中心化消息应用和点对点数据存储构建“另一个 Twitter”
• 理解 OpenBazaar 的去中心化市场及其支持交易的结构
• 探索去中心化众筹项目 Lighthouse 如何超越 Kickstarter 和 Indiegogo 等对手
• 深入讨论直接连接乘客和司机的 P2P 共享租车应用 La'Zooz

作者简介

Siraj Raval，dapp 开发人员、 企业家。他是开发人员众筹平台 Havi 的创始人，开发过包括 Meetup 在内的几个 iOS 应用，还做了很多开源方面的工作。除了程序员，Siraj 还是一位旅行家、音乐家、后现代主义者和潜水员。

本书内容

前言

排版约定

本书使用下列排版约定。

• 等宽字体（constant width）

  表示广义上的计算机编码，包括变量或函数名、数据库、数据类型、环境变量、语句和关键字。

• 等宽粗体（constant width bold）

  表示应该由用户按照字面输入的命令或其他文本。

• 等宽斜体（constant width italic）

  表示应该由用户替换或取决于上下文的值。

代码示例

补充材料（包括代码示例、练习题等）可以从 https://github.com/oreillymedia/decentralized_applications 下载。

本书旨在帮助你做好工作。一般来说，你可以在程序和文档中使用本书的代码。除非你使用了很大一部分代码，否则无须联系我们获取许可。例如，使用来自本书的几段代码编写一个程序不需要许可。销售和分发 O'Reilly 书中用例的光盘需要许可。通过引用本书用例和代码来回答问题不需要许可。把本书中的大量用例代码并入你的产品文档需要许可。

我们很希望但不强求注明信息来源。一条信息来源通常包括书名、作者、出版社和 ISBN。例如：“Decentralized Applications by Siraj Raval (O'Reilly). Copyright 2016 Siraj Raval, 978-1-4919-2454-9”。

如果你感到对示例代码的使用超出了正当引用或者这里给出的许可范围，请随时通过 permissions@oreilly.com 联系我们。

Safari^®在线图书

Safari Books Online（http://www.safaribooksonline.com）是应运而生的数字图书馆。它同时以图书和视频的形式出版世界顶级技术和商务作家的专业作品。技术专家、软件开发人员、Web 设计师、商务人士和创意专家等，在开展调研、解决问题、学习和认证培训时，都将 Safari Books Online 视作获取资料的首选渠道。

对于组织团体、政府机构和个人，Safari Books Online 提供各种产品组合和灵活的定价策略。用户可通过一个功能完备的数据库检索系统访问 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 以及其他几十家出版社的上千种图书、培训视频和正式出版之前的书稿。要了解 Safari Books Online 的更多信息，我们网上见。

联系我们

请把对本书的评价和问题发给出版社。

美国：

　　O'Reilly Media, Inc.

　　1005 Gravenstein Highway North

　　Sebastopol, CA 95472

中国：

　　北京市西城区西直门南大街 2 号成铭大厦 C 座 807 室（100035）

　　奥莱利技术咨询（北京）有限公司

O'Reilly 的每一本书都有专属网页，你可以在那里找到本书的相关信息，包括勘误表、示例以及其他信息。本书的网站地址是：

　　http://shop.oreilly.com/product/0636920039334.do

对于本书的评论和技术性问题，请发送电子邮件到：

　　bookquestions@oreilly.com

要了解更多 O'Reilly 图书、培训课程、会议和新闻的信息，请访问以下网站：

　　http://www.oreilly.com

我们在 Facebook 的地址如下：http://facebook.com/oreilly

请关注我们的 Twitter 动态：http://twitter.com/oreillymedia

我们的 YouTube 视频地址如下：http://www.youtube.com/oreillymedia

第1章 什么是去中心化应用

有一种用于构建可伸缩、盈利性大型应用的新模型已经崭露头角。比特币以其加密存储台账、稀缺资产模型和对等网络技术开辟了一条新路，为这种称作去中心化应用（decentralized application，简称为 dapp）的新型软件提供了构建基础。虽然 dapp 刚刚得到媒体的关注，但我相信，终有一天它的应用范围会变得更加广泛，并将远远超过目前最流行的 Web 应用。它更灵活、更透明、更分散、更有弹性。与当前的软件模型相比，它的结构有更好的激励性。如果你想了解并亲自创建这样的应用，这是第一本能为你提供帮助的书。

1.1　预备知识：什么是比特币

在深入介绍 dapp 之前，我们先来聊聊比特币 {1[在中国，比特币、以太币等“虚拟货币”不具有与货币等同的法律地位，不能在市场上流通使用。本书内容仅代表作者个人观点。——编者注]} 和 Web。在过去 10 年间，我们亲眼目睹了 Web 以数量级计的急剧增长。随着与互联网连接的设备逐渐遍及全球，互联网用户的数量达到了数十亿。乍一看，互联网协议套件有着良好的通信标准：链路层将一些数据放在电线上；网络层对数据进行路由；传输层将数据持久化；应用层以应用的形式提供数据抽象。这 4 个协议层在数据交换上的合作天衣无缝，但可惜它们交换的不是价值。对于价值交换而言，比特币充当了这 4 层之上的第 5 个协议层。

我们现在确实已经有了在 Web 上进行支付的方法，但问题是，它们无一例外地跟效率低下的遗留系统搅在一起，比如在互联网出现之前设计的自动清算所系统（automated clearing house，ACH）。这些传统的支付系统需要依赖集中式的清算系统，因此慢得让人难以忍受。机器不应该为了清算一笔支付等上好几天。它们在持续不断地相互通信，应该有能力将数十亿的小额支付发送给对方，以计量电力和存储空间等资源，并且无须负担高额的中间商交易费用。比特币解决了这个问题。

随着比特币的出现，即时、去中心化、匿名的价值转移终于变成了现实。神秘的比特币缔造者，那个自称中本聪（Satoshi Nakamoto）的人，有效地解决了困扰密码研究几十年的拜占庭将军问题。这里引用定义拜占庭将军问题的论文（Lamport，1982）：“（假设）拜占庭军队的一些将军率队在敌人的城市周围安营扎寨。他们相互之间只能依靠信使通信，而且必须在作战计划上达成一致。然而，他们中间可能会有一个或几个想要迷惑其他人的叛徒。那么我们要解决的问题是，找到一种算法来确保忠诚的将军能达成一致意见。”在比特币中达成去中心化的共识，意味着任何一方都无须信任参与信息分享的其他各方，也无须通过一个中央权威来分享信息，其中包括以价值交易形态存在的信息。

比特币和其他“加密货币”将有助于定义互联网的第 5 层协议，让机器像传递数据那样快速有效地传递价值。比特币是很有用的在线价值传递工具，但它最有价值的贡献是其革新性的底层技术：区块链（blockchain）。这一技术首次将去中心化共识变成了现实。

区块链是对发生在比特币网络中的所有交易进行大规模复制的数据库。它采用了一种称为工作量证明（proof-of-work）的共识机制，以此来防止在网络中出现双重消费（double-spending）。双重消费问题困扰了密码研究学者几十年，指的是坏人可以对第一次交易予以否认，从而达到将同一笔资金重复使用两次的目的。

工作量证明解决这一问题靠的是在网络中引入挖矿机（miner），用其硬件进行加密证明。挖矿机是验证交易的比特币网络节点，会通过自己的区块链历史来检查交易。区块链历史包含所有曾发生在网络中的交易，是一条带有时间戳的记录。从理论上讲，区块链历史可以修改，但因为有工作量证明，还需要使用网络上的大部分计算力进行验证。因为目前比特币网络所拥有的计算力已经远超世界上所有超级计算机的计算力总和，所以攻破比特币网络极其困难。

从电力消耗和计算负载角度来看，工作量证明需要付出高昂的代价，但它是目前已知能够阻止女巫攻击（Sybil attack）的唯一机制。女巫攻击是指坏人在网络中宣称拥有多个身份，并获取他们不应有的资源来进行攻击。一次成功的女巫攻击极有可能导致比特币完全贬值，因为人们将不再相信它的稳定性。虽然工作量证明代价高昂，但到目前为止，它是唯一经过大规模验证的有效机制。

我们拥有了这样一个称作区块链的新工具，它是一个大规模复制交易数据库，能阻挡女巫攻击。区块链让我们第一次无须使用中心服务器就能达成去中心化共识。你可能想知道这有什么用，也确实应该知道。接下来，我要用很大的篇幅帮你考虑所有的可能性，以及实现它们的方法。不过眼下的重点是让你明白，有众多数据结构能帮你创建出可以盈利的去中心化应用，这只是其中的一种。

1.2　什么是去中心化应用

大多数人熟悉“应用”（application）这个术语是因为它与软件有关。应用软件是指定义了明确目标的软件。目前使用中的应用软件多达数百万，而绝大多数 Web 应用软件都采用集中式的服务器 - 客户端模型。另外有一些是分布式的，还有很少一部分新的应用是去中心化的。图 1-1 直观地展示出了这三种软件模型。

图 1-1：应用软件的三种类型

集中式系统是目前最流行的应用软件模型。集中式系统直接控制各个单元的操作，并且信息流源自一个中心。所有单元都要直接依靠中心点来发送和接收信息，以及接受命令。Facebook、Amazon、Google 和其他主流互联网服务用的都是这个模型。我们将这些巨型服务称为“服务栈”。这些服务栈很有用，因为它们为我们提供了有价值的服务。不过它们也有巨大的缺陷，我会在第 2 章展开讨论。

那么，去中心化和分布式有什么区别呢？

分布式意味着计算不是在一个节点上，而是分布到多个节点上完成的。去中心化的意思则是，任何一个节点都不会对其他节点的工作指手画脚。很多像 Google 这样的服务栈都在内部采用分布式架构，以加快计算速度，降低数据延迟。也就是说，集中式系统同时也可以是分布式的。

那么，去中心化系统可以是分布式的吗？

可以。比特币就是分布式的，因为它盖有时间戳的公共账目（区块链）就是驻留在多个计算机上的。同时它也是去中心化的，因为如果某个节点失效了，整个网络还可以照常运转。也就是说，任何使用区块链和其他端到端工具的应用都可以是分布式的去中心化系统。

那为什么本书不叫作《分布式的去中心化应用》呢？

集中式系统也可以是分布式的。能够达成去中心化共识的应用软件才是真正的革新成果。

那么，有去中心化共识是成为去中心化应用的唯一要求吗？

dapp 领域是一片刚刚开始开垦的沃土，有很多聪明人正在用新的模型进行各种尝试。对于究竟什么是 dapp，不同的开发人员有不同的看法。一些人认为只要没有能导致整个系统失效的中心点就够了，但也有人觉得还要加上其他要求。本书的重点是讨论能够盈利的 dapp，即能让开发人员和用户赚钱的 dapp。之所以关注盈利，是因为利润为成功、健壮、可持续发展的 dapp 奠定了基石。开发人员构建应用，用户保持忠诚，以及矿工维护区块链，都是靠激励措施维持的。接下来介绍所有能够盈利的 dapp 都应该具备的 4 个特性。

1.2.1　特性1：开源

去中心化的闭源应用要求用户相信该应用的去中心化程度确如核心开发人员所说，并且用户不会通过一个中心源来访问自己的数据。因此，闭源应用会让用户望而却步，不敢使用。尤其对于那些会收取、持有或转移用户资金的应用，闭源更让人排斥。尽管确实可以推出一款闭源的去中心化应用，但从一开始就会面临艰难的局面，而且用户会更加青睐开源的竞争对手。将 dapp 开源会改变它的商业行为结构，因此互联网才会变成共同点，而不是孤岛链（见图 1-2）。

图 1-2：闭源商业计划与开源商业计划的对比

所有应用都能开源，但为什么不这样做呢？

如果研究一下传统的商业模型，就会发现它们全都要求所销售的产品或服务要超过竞争对手。如果把产品开源，竞争对手就能窃取你的工作成果，改头换面后当成他们自己的产品销售。

那么，是什么原因促使开发人员把希望从中盈利的应用开源呢？

从让开源 dapp 的创建者盈利这个角度来看，比特币树立了一个很好的榜样。中本聪保留了最初的一部分比特币，然后让其他人使用其余的部分。因为有数量上的限制，并且比特币网络的工作量证明机制为社会提供了巨大的价值，所以比特币的价值开始增长，从而为中本聪创造了财富。通过开源吸引开发人员为其做出贡献，该应用达成了网络自行完善所需的透明性，并赢得了用户的信任，最终使得比特币在现实世界中有了价值。开源 dapp 能让它赢得潜在用户的信任。任何人都可以从你的 dapp 创建分支，但他们挖不走你的开发团队。用户希望让最合适的人，通常也就是最初的那些开发者，来维护 dapp。

1.2.2　特性2：“内部货币”

在 dapp 圈，总会有人问怎么靠它赚钱。集中式应用的传统赚钱模式包括交易手续费、广告收入、推荐佣金、访问用户数据的权力以及订阅服务。如果把 dapp 开源，该怎么赚钱呢？你可能想通过程序自动产生交易手续费，并把这笔钱转到开发者的账户上去，但是可能会有人创建应用的分支，把你的佣金拿走，所以这样是不行的。嵌入广告、订阅服务以及其他任何集中式商业模型所采用的方法都是不可行的。

开源的 dapp 开发者要怎么赚钱呢？

答案是用稀缺令牌，即 App 币，来分配网络中的稀缺资源。用户如果想用这个网络，就需要 App 币。稀缺资源的所有者得到别人支付的 App 币。在比特币网络中，稀缺资源（计算力）的拥有者（矿工）直接从用户那里获取交易手续费，让他们使用自己提供的服务。因为网络的增长会引入更多用户，而 App 币的总额是固定的，所以 App 币的价值也会不断增长。我们可以把这个模型应用到所有 dapp 上。稀缺资源可以是存储空间、交易、图片、视频、文本、广告等很多东西。

这是不是意味着用户使用任何 dapp 都需要付费呢？

既是也不是。尽管区块链是需要支付才能使用的，但在 dapp 内部可以构造出不同的激励方式。可以给用户 App 币作为注册奖励，甚至可以让用户通过出售自己的数据或本地存储空间来换取 App 币。除了使用 App 币，dapp 创建者还可以通过虚拟资产赚钱，就像去中心化的 MMORPG 中的不动产一样，或者通过特殊命名空间中的领域，甚至声誉。

1.2.3　特性3：去中心化共识

在比特币之前，达成交易有效的共识总是需要或多或少地依靠一个中心来完成。如果你想完成支付，那么这条交易必须经过一个清分中心（所有的交易都要受它监测）。比特币是点对点的（P2P），也就是说各节点可以直接通话。P2P 网络不是什么新发明，BitTorrent 之类的分布式散列表（DHT）是在区块链之前发明的。如果要存储和串流去中心化的数据，DHT 非常好用；但如果想以一种去中心化的方式让所有人对用户名、状态更新、高分值等应用层面上的数据达成共识，则需要靠区块链。区块链并不会替代 DHT，但确实是其必要的补充。区块链之所以如此独特，是因为它解决了 DHT 最主要的安全问题：节点之间不需要在数据的有效性上相互信任。区块链是一个去中心化的交易数据库，并且是第一个高度防篡改的去中心化数据库。安全性是区块链的主导性设计目标之一。它是历史上第一个在组织上去中心化而在逻辑上集中的交易日志。请看表 1-1。

表1-1：比特币在组织上去中心化，在逻辑上集中

||组织上集中的|组织上去中心化的||-|-|-||逻辑上集中的|PayPal|比特币||逻辑上去中心化的|Excel|电子邮件|

区块链的革新点在于去中心化的共识。如果你的应用中有个功能是需要让所有人共同承认某个东西，就应该用区块链。以用户名系统为例，用户名 @user 在谁手里其实并不重要，真正重要的是让所有人都承认它就是那个人的。过去出现过很多去中心化协议，但都要求节点间彼此信任。区块链是不可变记录，每个节点都有一份副本，因此没有人能假装自己也是 @user。这可以用智能合约实现。

智能合约是区块链里的一段代码。当某个预先编写好的条件被触发时，智能合约就会执行相应的合约条款。你可能在想：“跟下面这个用 Stripe 的 API 所做的事相比，智能合约有什么不同之处呢？”

if (user.sendsMoney(customerID)){runContract();}func runContract(){ println('hello world');}

一个很大的区别是智能合约就在区块链之中，不是放在服务器上。它不需要第三方信任，就这个例子而言，也不需要信任 Stripe 或者服务器的主人。因此，智能合约正规的表达应该是“用经济的加密方式保证安全的代码执行”。不过要记住，并非所有的 dapp 代码都是智能合约。尽管智能合约有自己特殊的用例，但为了便于展开讨论，可以说它们一般就像模型 - 视图 - 控制器 dapp 架构中的“模型”。在讲到 dapp 的架构时，我还会进行更深入的介绍。

1.2.4　特性4：没有中心失效点

dapp 是没有办法关掉的，因为根本没有服务器。dapp 的数据是去中心化地放在其所有节点上的。每个节点都是独立的；如果一个节点失效了，其他的还能在网络上运转。要在你构建的 dapp 上实现这一功能，可以选用一款去中心化数据库系统，比如星际文件系统、BitTorrent 和一些独立的 DHT。

1.3　去中心化应用的历史

在其早期，Web 上并没有这么多的应用和服务。当时明显不像现在这样全天下所有事情都能在 Web 上完成，但那时候分布式 DIY 的感觉确实更强烈。从一开始，Web 就是非常去中心化的。HTTP 协议连接着全世界拥有计算设备和互联网连接的每一个人。在 HTTP 协议的指导方针中，有一组可信的服务器将你输入的 Web 地址转换成服务器地址。HTTPS 更进一步，加上了可信服务器和证书颁发机构这一层。人们可以架设一台个人服务器供他人连接，而每个人都拥有自己的数据。但很快，应用服务器开始起步，我们今天熟知的数据拥有权的集中式模型诞生了。为什么会这样呢？

简单来说是因为它很容易实现，从概念上和编程上来说都容易。这是最容易做到的，并且管用。个人或群组负担服务器的维护成本，并从使用服务器上软件的用户那里盈利。MySpace 和 Yahoo! 是第一批集中式应用的典型代表。最近的应用，比如 Uber 和 Airbnb，通过提供一个可信的集中式数据存储，把业务的“现实世界”部分去中心化了。他们是第一批允许各方全都参与到一项赚钱事业中的商家。这种去中心化的业务模型也为开发更多的去中心化应用做好了铺垫。

随着 HTTP 网络的不断增长，一个名叫 Bram Cohen 的开发人员引入了一种新的协议，称为 BitTorrent。Bram Cohen 创建 BitTorrent 协议的目的是解决通过 HTTP 协议下载大型媒体文件时间超长的问题，同时也是对之前 P2P 协议的一种改进，比如 Gnutella、Napster 和 Grokster。问题在于，下载大型文件所需的时间太长，并且随着 Web 的增长，能够获得的文件大小也在增长。与此同时，硬盘存储空间也在增长，连接到一起的人也越来越多，BitTorrent 把下载者同时变为上传者，从而解决了这个问题。

你想要的文件并不是放在一个数据源上，所以下载的时候是从多个数据源下载的。这个文件越受欢迎，就会有越多的用户下载它，从而也就有越多的用户上传。这就意味着，你能从更多的源头来拉取这个文件中的数据。数据源越多，下载速度越快。给种子用户的回报是更快的下载速度，而对吸血用户的惩罚就是速度上的限制。事实证明，这种“以牙还牙”的数据传输系统对于电影和电视剧之类的大型文件特别好用。

BitTorrent 不断增长，并且成为游戏和电影等所有大型文件的下载方式。事实证明，对于大型数据集来说，BitTorrent 的速度、弹性和回报机制都要优于 HTTP。

那 Web 为什么不用这种方式工作呢？

很有可能是因为 HTTP 的先发优势，它的基础设施，以及所有已经投入其中的时间和金钱。现在有些活跃的项目想要对 HTTP 网络进行升级，给它加上类似于 BitTorrent 的技术。他们很有可能会成功，因为 BitTorrent 有巨大的价值主张。BitTorrent 刚一出现，开发者就开始用这一技术创建非盈利性的去中心化应用。下面来看几个最近出现的去中心化应用。

1.3.1　PopcornTime

PopcornTime 用 BitTorrent 协议实现用户间的实时视频流，有点像使用种子的 Netflix。它是美国电影协会（MPAA）最恐怖的噩梦。没有监管者能关掉它，现在所有人都能访问到免费的电影。作为去中心化版的 Netflix，PopcornTime 证明了自己是一个好用的 dapp。创建者声称每个国家都有人下载过它，甚至包括没有互联网的两个国家。因为 PopcornTime 没有使用“内部货币”，并且不需要去中心化共识，所以没有用区块链。它仅仅通过串流电影就提供了很大的价值。

1.3.2　OpenBazaar

OpenBazaar 的目标是成为去中心化版的 eBay。没有中间商能告诉销售商什么能卖，什么不能卖，也没有中间商能决定使用服务的费用。它构建在 BitTorrent 协议之上，但问题是销售商必须架设自己的商铺。他们需要有自己的服务器并保持运行，以便用户能看到他们的商品。在理想情况下，销售商只需要把店铺数据上传到网络上，还可能需要支付一小笔费用，然后就不用管了。这就要求有一个能够激励存储挖矿机的去中心化系统，我们会在第 4 章详细介绍。OpenBazaar 使用 BitTorrent 传输数据，用比特币作为销售商之间的交易“货币”。

1.3.3　Lighthouse

我们会在第 5 章深入探讨 Lighthouse，这里先进行简要介绍。Lighthouse 是一个内嵌了一系列智能合约的比特币钱包，这些智能合约就像 Kickstarter 一样帮忙向某些项目认筹。当项目目标达成时，它就能从项目支持者的 Lighthouse 钱包中取出资金。认筹者可以随时自行撤销认筹，不需项目创建者的参与。Lighthouse 是用现有的比特币基础设施构建自己的 dapp 的好例子。它只用一个带有一些比特币智能合约的 UI 就做成了一个电子钱包。此外，它运转良好，并且吸引了比特币现有的用户群。Lighthouse 有去中心化共识，是开源的，没有中心失效点，但它没有发行自己的“货币”，而是用了比特币。它是个实用的 dapp，但不能让创建者盈利。

1.3.4　Gems

Gems 是一个社交消息应用，试图创建一个比 WhatsApp 更加公平的业务模型。Gems 发行了自己的“货币”，并且允许广告商直接向用户支付费用以访问其数据，而不是自己作为中间商盈利。这种货币称为“宝石”，是在比特币基础上创建的元币。用户吸引其他人加入网络能赚到宝石，开发人员在开发和维护这个软件时也能赚到宝石。随着 Gems 用户群的不断扩大，宝石的价值也变得越来越高。用户也像开发人员一样受到激励，通过扩大网络来赚钱。你可以把宝石看成 dapp 里的股份。Gems 还没有开源，所以用户无法检查它是否真的没有中心失效点。这是一个盈利性 App，但我觉得它难以跟满足另外三个条件的竞争对手进行竞争。

那么，有没有四个条件全都满足的独立 dapp 呢——没有中心失效点，发行自己的“内部货币”，有去中心化共识，并且是开源的？

有很多“加密货币”都是同时满足这四个条件的，但“加密货币”不是 dapp。我所说的是社交网络、拼车、搜索引擎：去中心化版的服务栈。答案是现在还没有，但是有这种可能性。目前存在这种技术，只要出现几个这样的 dapp，就会有大批开发人员走上这条路，让自己和他们的用户大赚一笔。接下来就来聊聊要用到的技术。

1.4　技术点

在讨论去中心化应用的发展历史时，我已经提到了很多技术点。比特币的区块链当然是最重要的，所以在介绍其他技术点之前，我们先深入探讨一下区块链。区块链帮助解决了拜占庭将军问题。该问题问的是：“如何在分布式节点间进行协作，从而能够在攻击者试图搞破坏的情况下达成某种共识？”工作量证明算法和区块链帮我们解决了这一问题。

在比特币被创造出来之后，去中心化共识成为了可能。工作量证明并不完美，它要消耗大量的计算力和电力。还有其他可以解决有意义问题的“加密货币”，比如 PrimeCoin，它的挖矿机用自己的计算资源寻找素数。在比特币的世界中，我们将要耗费大量的能量来维护网络，而能量应该有更好的用途，只是帮助网络维护其自身的安全太浪费了。

但问题是，工作量证明是目前为止唯一能够防范女巫攻击的系统。共识研究并没有止步于工作量证明，探索仍在继续，但现在我们最好的选择就是工作量证明。至于说有希望成为工作量证明的竞争对手的，现在有个大家伙：权益证明（proof-of-stake）。权益证明也不完美，但可以作为工作量证明的补充。

权益证明是一种共识机制，依靠计算力防止对网络中的权益进行女巫攻击。通常来说，权益是指矿工拥有的“加密货币”数额。其核心思想是，你拥有的“加密货币”越多，就越会投入更多来确保网络的稳定性，也越不可能进行 51% 攻击来创建区块链的分支。代理式权益证明在权益证明的基础上做了创新，一组 101 代理可以对区块产生者进行投票。代理式权益证明和权益证明都还在研究当中，但如果能证明其中任何一个是长期安全的，就可以将其作为工作量证明的补充，甚至完全替代工作量证明。

定义术语

为什么要使用术语 dapp ？为什么是去中心化应用？为什么不是去中心化组织、去中心化自治组织或去中心化自治企业？

对于 dapp 这个理论上可行并已得到部分实现的生态系统，“加密货币”圈里已经有很多不同的术语了。要解释我选择术语 dapp 的原因，最好的办法是看一下目前所有相关的术语，以及它们的意思。

先从 dapp 本身开始吧。

• 去中心化应用（decentralized application，DA）

  去中心化应用是本书的标题。我本来也可以有其他选择，比如 DO、DAO 或 DAC。为什么最终选用 dapp 呢？因为所有这些术语里都有“去中心化”。对于所有涉及软件的去中心化实体，去中心化应用都是其超类。

• 去中心化组织（decentralized organization，DO）

  DO 是给所有员工授权的组织。这个术语并不适用于组织所用的工具，更多的是描述其结构。组织的去中心化程度不同，并且完全去中心化也不一定是最好的方式。在传统型的组织中，有严格的层级式命令结构。

  去中心化组织会倾听员工的声音，并且权力是平均分配给每个人的。每个人都可以审查公司的活动和里程碑，它们就存放在一个去中心化存储网络中，以便达到最佳的弹性。不需要把人类当作唯一的决策者：智能合约能够在某个日期担任诸如支付者的角色。DO 也不需要基于某座城市，其成员可以遍布全球。在某些系统中（比如比特币），共谋被视为 bug。但是在去中心化组织中，共谋是一项功能。得益于 Slack 和 GitHub 等工具的发展，最近有些创业公司采用了更加去中心化的结构。

• 自动代理（automated agent，AA）

  AA 不一定是指 SkyNet 或一些通用的人工智能。自动代理至少已经存在 10 年了，无须人工干预运行的或者说自主运行的软件都是 AA。计算机病毒就是个完美的例子。开发者制作并把它广泛散发出去之后，就由它来决定进行自我复制或执行已编码的任何其他维护算法。守护程序是另外一个例子。守护程序会作为后台进程在操作系统中运行，比如电子邮件程序。自动代理有利有弊：它们确实不需要任何维护，但未经检查的的代理也可能变成人类难以控制的危险源。在第 6 章还会对其进行详细讨论。

• 去中心化自治组织（decentralized autonomous organization，DAO）

  在换成 dapp 之前，我最初其实是想用它做书名的。DAO 跟 DO 一样，只是由 AI 代替人类来做决定。协议就在去中心化的栈中，并且不会听从任何法律约束。人类不是主宰者，而是被边缘化了。AI 来做决定，DAO 自己来维护自己。但并不是由 AI 做决定的就是 DAO，它还要有自己的内部资本。

  简言之，这些都是 dapp 的子类，并且 DAO 是由 AI 控制决策的 dapp，人类靠边站。共谋不像在去中心化组织中那样被当作功能，而是 bug。比特币就是 DAO 的一个例子。

• 去中心化自治企业（decentralized autonomous corporation，DAC）

  这个有争议。一些人觉得这根本不应该是个词组，因为企业这个词是从受法律合同和层级集权控制的遗留系统中来的，而这样的系统正是我们要努力演变的起点。另一些人认为 DAC 是 DAO 的子类，将股息付给其成员。

  我支持前一种观点，因为我不喜欢企业这个词，并且如果 DAO 想要实现给人类和机器成员的派息，它可以是 DAO，而不是 DAC。

我们讨论了 dapp、DO、DAO、AA 和 DAC，每个还都举了例子。接下来再看一下图 1-3，以便了解得更清楚。

图 1-3：组织的类型（来自 Vitalik Buterin）

我很喜欢这张图，因为它把之前讨论的内容都放进了上下文中。我们还没到能够制作 AI（图中的圣杯部分）的阶段，而是在旁边那个可以开始制作 DAO 的进化阶段。

为简便起见，我们将在本书中使用术语 dapp，因为 dapp 是所有去中心化软件的超类。我将要讨论用于定义你自己的 dapp 的各种工具及方法论，然后由你来决定哪种 dapp 最适合你。

我的定义源自我对“加密货币”社区的研究。我不想给概念添加其他标签，也不想创建新的范式。实际上，我想要尽可能地简化这一领域，以便你能充分了解那些用来创作可盈利去中心化应用的工具。去中心化应用领域几乎快被各种想法搞得精疲力尽了，在看过它的优缺点后，是时候重新迭代一下了。下一波软件潮流就是 dapp，希望这本书能帮你做好加入其中的准备。

1.5　开始着手吧

希望我已经把什么是去中心化应用讲清楚了。虽然还有很多需要解释的，但你应该已经对这一领域有了大致的了解，并且掌握了跟 dapp 相关的术语和缩写。我写作这本书的目的是：首先解释什么是 dapp，为什么要构建它们，以及蓬勃发展的 dapp 生态系统看起来是什么样的；然后介绍如何使用现有工具实现你自己的 dapp；最后深入介绍 dapp 领域中的几个主要参与者。

第2章 蓬勃发展的 dapp 生态系统

第3章 创建你的第一个 dapp

第4章 OpenBazaar

第5章 Lighthouse

第6章 La'Zooz

关于封面

阅读全文: http://gitbook.cn/gitchat/geekbook/5b5e947991833538d3944ec0

注册中心简介

背景分析

在微服务中，首先需要面对的问题就是如何查找服务(软件即服务)，其次,就是如何在不同的服务之间进行通信？如何更好更方便的管理应用中的每一个服务，如何建立各个服务之间联系的纽带，由此注册中心诞生（例如淘宝网卖家提供服务，买家调用服务）。
市面上常用注册中心有Zookeeper(雅虎Apache),Eureka(Netfix),Nacos(Alibaba),Consul(Google),那他们分别都有什么特点，我们如何进行选型呢？我们主要从社区活跃度,稳定性,功能,性能等方面进行考虑即可.本次微服务的学习,我们选择Nacos,它很好的支持了阿里的双11活动,不仅可以做注册中心，还可以作为配置中心，稳定性和性能都很好。

Nacos概述

Nacos（DynamicNaming and Configuration Service）是一个应用于服务注册与发现、配置管理的平台。它孵化于阿里巴巴，成长于十年双十一的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。其官网地址如下：

https://nacos.io/zh-cn/docs/quick-start.html

构建Nacos服务

准备工作

第一：确保你电脑已配置JAVA_HOME环境变量(Nacos启动时需要)，例如：

第二：确保你的MySQL版本为5.7以上（MariaDB10.5以上)，例如

下载与安装

第一步：Nacos下载,可在浏览器直接输入如下地址：

https://github.com/alibaba/nacos/releases

第二步：选择对应版本，直接下载，如图所示：

第三步：解压Nacos（最好不要解压到中文目录下），其目录结构如下：

初始化配置

第一步：打开操作系统命令行，登陆mysql，执行课前资料中的sql脚本，不是nacos/conf目录下自带的。
例如,我们可以使用mysql自带客户端,在命令行首先登录mysql,然后执行如下指令:

source d:/nacos-mysql.sql 

执行成功以后，会创建一个nacos_config数据库，打开数据库会看到一些表，例如；

说明:在执行此文件时,要求mysql的版本大于5.7版本(MariaDB最好10.5.11),否则会出现如下错误:

第二步：打开/nacos/conf/application.properties里打开默认配置，并基于你当前环境配置要连接的数据库，连接数据库时使用的用户名和密码(假如前面有"#"要将其去掉)：

### If use MySQL as datasource:
spring.datasource.platform=mysql

### Count of DB:
db.num=1

### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root

服务启动与访问

第一步:启动Nacos服务（nacos的bin目录去通过指令启动）。

Linux/Unix/Mac启动命令(standalone代表着单机模式运行，非集群模式):

./startup.sh -m standalone

Windows启动命令(standalone代表着单机模式运行，非集群模式):

startup.cmd -m standalone

说明:
1)执行执行令时要么配置环境变量,要么直接在nacos/bin目录下去执行.
2)nacos启动时需要本地环境变量中配置了JAVA_HOME(对应jdk的安装目录),
3)一定要确保你连接的数据库(nacos_config)是存在的.
4)假如所有的配置都正确,还连不上，检查一下你有几个数据库(mysql,…)

第二步:访问Nacos服务。

打开浏览器，输入http://localhost:8848/nacos地址，出现如下登陆页面：

其中，默认账号密码为nacos/nacos.

服务注册与调用入门（重点）

业务描述

创建两个项目Module分别为服务提供者和服务消费者（假如已有则无需创建），两者都要注册到NacosServer中(这个server本质上就是一个web服务，端口默认为8848)，然后服务提供者可以为服务消费者提供远端调用服务(例如支付服务为服务提供方，订单服务为服务消费方)，如图所示：

生产者服务创建及注册

第一步：创建服务提供者工程(module名为sca-provider,假如已有则无需创建），继承parent工程(01-sca),其pom.xml文件内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>01-sca</artifactId>
        <groupId>com.jt</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>sca-provider</artifactId>
    <dependencies>
        <!--Web服务-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <!--服务的注册和发现(我们要讲服务注册到nacos)-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
    </dependencies>
</project>

第二步：创建并修改配置文件application.yml(或者application.properties)，实现服务注册，关键代码如下：

server:
   port: 8081
spring:
  application:
    name: sca-provider #进行服务注册必须配置服务名
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848

注意：服务名不要使用下划线(“_”),应使用横杠(“-”),这是规则。
第三步：创建启动类(假如已有则无需定义)，关键代码如下：

package com.jt;

@SpringBootApplication
public class ProviderApplication {

    public static void main(String[] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
  }

第四步：启动启动类，然后刷先nacos服务，检测是否服务注册成功，如图所示：

第五步:停掉sca-provider服务，然后不断刷新nacos服务列表，检查服务的健康状态。

消费者服务发现及调用

第一步: 在sca-provider项目中创建服务提供方对象，基于此对象对外提供服务,例如:

    package com.jt.provider.controller;
    /**定义Controller对象(这个对象在spring mvc中给他的定义是handler),
     * 基于此对象处理客户端的请求*/
    @RestController
    public class ProviderController{
        //@Value默认读取项目配置文件中配置的内容
        //8080为没有读到server.port的值时,给定的默认值
        @Value("${server.port:8080}")
        private String server;
        //http://localhost:8081/provider/echo/tedu
        @GetMapping("/provider/echo/{msg}")
        public String doRestEcho1(@PathVariable String msg){
            return server+" say hello "+msg;
        }
    }

第二步：创建服务消费者工程（module名为sca-consumer，假如已有则无需创建），继承parent工程（01-sca），其pom.xml文件内容如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>01-sca</artifactId>
        <groupId>com.jt</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>
    <artifactId>sca-consumer</artifactId>
    
   <dependencies>
    <!--Web服务-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!--服务的注册和发现(我们要讲服务注册到nacos)-->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
    </dependencies>
</project>

第三步：创建sca-consumer服务中的配置文件application.yml，关键代码如下：

server:
  port: 8090
spring:
  application:
    name: sca-consumer #服务注册时，服务名必须配置
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #从哪里去查找服务

第四步：创建消费端启动类并实现服务消费，关键代码如下：

package com.jt;
@SpringBootApplication
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class,args);
    }
}

第五步:在sca-consumer启动类中添加如下方法,用于创建RestTemplate对象.

@Bean
public RestTemplate restTemplate(){//基于此对象实现远端服务调用
    return new RestTemplate();
}

第六步:定义sca-consumer服务的消费端Controller,在此对象方法内部实现远端服务调用

package com.jt.consumer.controller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;


/**
 * 定义服务消费端Controller,在这个Controller对象
 * 的方法中实现对远端服务sca-provider的调用
 */
@RestController
public class ConsumerController {
    /**
     * 从spring容器获取一个RestTemplate对象,
     * 基于此对象实现远端服务调用
     */
    @Autowired
    private RestTemplate restTemplate;
    /**
     * 在此方法中通过一个RestTemplate对象调用远端sca-provider中的服务
     * @return
     * 访问此方法的url: http://localhost:8090/consumer/doRestEcho1
     */
    @GetMapping("/consumer/doRestEcho1")
    public String doRestEcho01(){
        //1.定义要调用的远端服务的url
        String url="http://localhost:8081/provider/echo/8090";
        //2.基于restTemplate对象中的相关方法进行服务调用
        return restTemplate.getForObject(url, String.class);
    }

}

第七步：启动消费者服务，并在浏览器输入http://localhost:8090/consumer/doRestEcho1地址进行访问测试。

小节面试分析

• 为什么要将服务注册到nacos?(为了更好的查找这些服务)
• 在Nacos中服务提供者是如何向Nacos注册中心(Registry)续约的？(5秒心跳)
• 对于Nacos服务来讲它是如何判定服务实例的状态？(检测心跳包，15,30)
• 服务消费方是如何调用服务提供方的服务的？(RestTemplate)

服务负载均衡设计及实现（重点）

业务描述

一个服务实例可以处理请求是有限的,假如服务实例的并发访问比较大,我们会启动多个服务实例,让这些服务实例采用一定策略均衡(轮询,权重,随机,hash等)的处理并发请求,在Nacos中服务的负载均衡(Nacos客户端负载均衡)是如何应用的?

LoadBalancerClient应用

LoadBalancerClient对象可以从nacos中基于服务名获取服务实例，然后在工程中基于特点算法实现负载均衡方式的调用，案例实现如下：

第一步:修改ConsumerController类,注入LoadBalancerClient对象,并添加doRestEcho2方法,然后进行服务访问.

  @Autowired
  private LoadBalancerClient loadBalancerClient;
  
  @Value("${spring.application.name:8090}")
  private String appName;
   
  @GetMapping("/consumer/doRestEcho02")
 public String doRestEcho02(){
     ServiceInstance serviceInstance = loadBalancerClient.choose("sca-provider");
     String url = String.format("http://%s:%s/provider/echo/%s",serviceInstance.getHost(),serviceInstance.getPort(),appName);
     System.out.println("request url:"+url);
     return restTemplate.getForObject(url, String.class);
     }
 }

第二步：打开Idea服务启动配置，如图所示：

第三步：修改并发运行选项(假如没有找到这个选项我们需要通过搜索引擎基于组合查询的方法,去找到对应的解决方案,例如搜索 idea allow parallel run)，如图所示：

第四步：修改sca-provider的配置文件端口，分别以8081，8082端口方式进行启动。

server:
  port: 8082
spring:
  application:
    name: sca-provider
  cloud:
    nacos:
      server-addr: localhost:8848

第五步：启动成功以后，访问nacos的服务列表，检测服务是否成功注册，如图所示：

第六步：启动sca-consumer项目模块，打开浏览器对consumer服务进行访问，访问时不断刷新，检测页面数据变化。

说明，这里多个实例并发提供服务的方式为负载均衡，这里的负载均衡实现默认是因为Nacos集成了Ribbon来实现的，Ribbon配合RestTemplate，可以非常容易的实现服务之间的访问。Ribbon是Spring Cloud核心组件之一，它提供的最重要的功能就是客户端的负载均衡(客户端可以采用一定算法,例如轮询访问，访问服务端实例信息)，这个功能可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡方式的服务调用。

@LoadBalanced

当使用RestTemplate进行远程服务调用时，假如需要负载均衡,还可以在RestTemplate对象构建时，使用@LoadBalanced对构建RestTemplate的方法进行修饰，例如在ConsumerApplication中构建名字为loadBalancedRestTemplate的RestTemplate对象：

@Bean
@LoadBalanced
public RestTemplate loadBalancedRestTemplate(){
    return new RestTemplate();
}

在需要RestTemplate实现负载均衡调用的地方进行依赖注入.例如在ConsumerController类中添加loadBalancedRestTemplate属性

@Autowired
private RestTemplate loadBalancedRestTemplate;

接下来，可以在对应的服务端调用方的方法内，基于RestTemplate借助服务名进行服务调用， 例如：

@GetMapping("/consumer/doRestEcho3")
public String doRestEcho03(){
    String url=String.format("http://%s/provider/echo/%s","sca-provider",appName);
    //向服务提供方发起http请求,获取响应数据
    return loadBalancedRestTemplate.getForObject(
            url,//要请求的服务的地址
            String.class);//String.class为请求服务的响应结果类型
}

RestTemplate在发送请求的时候会被LoadBalancerInterceptor拦截，它的作用就是用于RestTemplate的负载均衡，LoadBalancerInterceptor将负载均衡的核心逻辑交给了loadBalancer，核心代码如下所示(了解):

public ClientHttpResponse intercept(final HttpRequest request, 
    final byte[] body, final ClientHttpRequestExecution execution) throws IOException {
	final URI originalUri = request.getURI();
	String serviceName = originalUri.getHost();
	return this.loadBalancer.execute(serviceName, 
    requestFactory.createRequest(request, body, execution));
}

@LoadBalanced注解是属于Spring，而不是Ribbon的，Spring在初始化容器的时候，如果检测到Bean被@LoadBalanced注解，Spring会为其设置LoadBalancerInterceptor的拦截器。

Ribbon负载均衡策略(了解)

基于Ribbon方式的负载均衡，Netflix默认提供了七种负载均衡策略，对于SpringCloud Alibaba解决方案中又提供了NacosRule策略，默认的负载均衡策略是轮训策略。如图所示：

当系统提供的负载均衡策略不能满足我们需求时，我们还可以基于IRule接口自己定义策略.

小节面试分析

• @Bean注解的作用?(一般用于配置类内部,描述相关方法,用于告诉spring此方法的返回值要交给spring管理,bean的名字默认为方法名,假如需要指定名字可以@Bean(“bean的名字”),最多的应用场景是整合第三方的资源-对象)
• @Autowired注解的作用?(此注解用于描述属性,构造方法,set方法等,用于告诉spring框架,按找一定的规则为属性进行DI操作,默认按属性,方法参数类型查找对应的对象,假如只找到一个,则直接注入,类型多个时还会按照属性名或方法参数名进行值的注入,假如名字也不同,就出报错.)
• Nacos中的负责均衡底层是如何实现的?(通过Ribbon实现,Ribbon中定义了一些负载均衡算法,然后基于这些算法从服务实例中获取一个实例为消费方法提供服务)
• Ribbon 是什么？(Netflix公司提供的负载均衡客户端,一般应用于服务的消费方法)
• Ribbon 可以解决什么问题? (基于负载均衡策略进行服务调用, 所有策略都会实现IRule接口)
• Ribbon 内置的负载策略都有哪些?(8种,可以通过查看IRule接口的实现类进行分析)
• @LoadBalanced的作用是什么？(描述RestTemplate对象,用于告诉Spring框架，在使用RestTempalte进行服务调用时，这个调用过程会被一个拦截器进行拦截,然后在拦截器内部,启动负载均衡策略。)
• 我们可以自己定义负载均衡策略吗？(可以，基于IRule接口进行策略定义,也可以参考NacosRule进行实现)

基于Feign的远程服务调用（重点）

背景分析

服务消费方基于rest方式请求服务提供方的服务时，一种直接的方式就是自己拼接url，拼接参数然后实现服务调用，但每次服务调用都需要这样拼接，代码量复杂且不易维护，此时Feign诞生。

Feign是什么

Feign 是一种声明式Web服务客户端，底层封装了对Rest技术的应用,通过Feign可以简化服务消费方对远程服务提供方法的调用实现。如图所示：

Feign 最早是由 Netflix 公司进行维护的，后来 Netflix 不再对其进行维护，最终 Feign 由一些社区进行维护，更名为 OpenFeign。

Feign应用实践（掌握）

第一步：在服务消费方，添加项目依赖(SpringCloud团队基于OpenFeign研发了starter)，代码如下：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

第二步：在启动类上添加@EnableFeignClients注解，代码如下：

@EnableFeignClients
@SpringBootApplication
public class ConsumerApplication {…}

第三步：定义Http请求API，基于此API借助OpenFeign访问远端服务，代码如下：

package com.jt.consumer.service;
@FeignClient(name="sca-provider")//sca-provider为服务提供者名称
public interface RemoteProviderService{
    @GetMapping("/provider/echo/{string}")//前提是远端需要有这个服务
    public String echoMessage(@PathVariable("string") String string);
}

其中，@FeignClient描述的接口底层会为其创建实现类。

第四步：创建FeignConsumerController中并添加feign访问，代码如下：

package com.jt.consumer.controller;
@RestController
@RequestMapping("/consumer/ ")
public class FeignConsumerController {
    @Autowired
    private RemoteProviderService remoteProviderService;
    /**基于feign方式的服务调用*/
    @GetMapping("/echo/{msg}")
    public String doFeignEcho(@PathVariable  String msg){
        //基于feign方式进行远端服务调用(前提是服务必须存在)
        return remoteProviderService.echoMessage(msg);
    }
}

第五步：启动消费者服务，在浏览器中直接通过feign客户端进行访问，如图所示（反复刷新检测其响应结果）：

说明，feign方式的远程服务调用，底层会自动基于ribbon组件实现负载均衡。

Feign配置进阶实践

一个服务提供方通常会提供很多资源服务,服务消费方基于同一个服务提供方写了很多服务调用接口,此时假如没有指定contextId,服务
启动就会失败,例如，假如在服务消费方再添加一个如下接口,消费方启动时就会启动失败,例如:

 @FeignClient(name="sca-provider")
 public interface RemoteOtherService {
     @GetMapping("/doSomeThing")
     public String doSomeThing();
}

其启动异常如下：

The bean 'optimization-user.FeignClientSpecification', defined in null, could not be registered. A bean with that name has already been defined in null and overriding is disabled.

此时我们需要为远程调用服务接口指定一个contextId,作为远程调用服务的唯一标识（这个标识是Bean对象的名字）即可,例如:

@FeignClient(name="sca-provider",contextId="remoteProviderService")//sca-provider为服务提供者名称
interface RemoteProviderService{
    @GetMapping("/provider/echo/{string}")//前提是远端需要有这个服务
    public String echoMessage(@PathVariable("string") String string);
}

还有,当我们在进行远程服务调用时,假如调用的服务突然不可用了或者调用过程超时了,怎么办呢?一般服务消费端会给出具体的容错方案,例如，在Feign应用中通过FallbackFactory接口的实现类进行默认的相关处理，例如:

第一步:定义FallbackFactory接口的实现,代码如下:

package com.jt.service.factory;
/**
 * 基于此对象处理RemoteProviderService接口调用时出现的服务中断,超时等问题
 */
@Component
public class ProviderFallbackFactory implements FallbackFactory<RemoteProviderService> {
    /**
     * 此方法会在RemoteProviderService接口服务调用时,出现了异常后执行.
     * @param throwable 用于接收异常
     */
    @Override
    public RemoteProviderService create(Throwable throwable) {
        return (msg)->{
                return "服务维护中,稍等片刻再访问";
        };
    }
}

第二步:在Feign访问接口中应用FallbackFactory对象,例如:

@FeignClient(name = "sca-provider", contextId = "remoteProviderService",
             fallbackFactory = ProviderFallbackFactory.class)//sca-provider为nacos中的服务名
public interface RemoteProviderService {
    @GetMapping("/provider/echo/{msg}")
    public String echoMsg(@PathVariable String msg);
}

第三步:在配置文件application.yml中添加如下配置,启动feign方式调用时的服务中断处理机制.

feign:  
  hystrix:
    enabled: true #默认值为false

第四步:在服务提供方对应的调用方法中添加Thread.sleep(5000)模拟耗时操作,然后启动服务进行访问测试.

Feign 调用过程分析（了解）

Feign应用过程分析（底层逻辑先了解）：
1)通过 @EnableFeignCleints 注解告诉springcloud,启动 Feign Starter 组件。
2) Feign Starter 会在项目启动过程中注册全局配置，扫描包下所由@FeignClient注解描述的接口，然后由系统底层创建接口实现类(JDK代理类)，并构建类的对象，然后交给spring管理(注册 IOC 容器)。
3) Feign接口被调用时，底层代理对象会将接口中的请求信息通过编码器创建 Request对象，基于此对象进行远程过程调用。
4) Feign客户端请求对象会经Ribbon进行负载均衡，挑选出一个健康的 Server 实例（instance）。
5) Feign客户端会携带 Request 调用远端服务并返回一个响应。
6) Feign客户端对象对Response信息进行解析然后返回客户端。

小节面试分析

• 为什么使用feign?(基于Feign可以更加友好的实现服务调用，简化服务消费方对服务提供方方法的调用)。
• @FeignClient注解的作用是什么？(告诉Feign Starter，在项目启动时，为此注解描述的接口创建实现类-代理类)
• Feign方式的调用，底层负载均衡是如何实现的？(Ribbon)
• @EnableFeignCleints 注解的作用是什么？（描述配置类，例如启动类）

总结(Summary)

重难点分析

• 何为注册中心？(用于记录服务信息的一个web服务，例如淘宝平台，滴滴平台，美团外卖平台，……)
• 注册中心的核心对象？(服务提供方，服务消费方，注册中心-Registry)
• 市面上常用注册中心？(Google-Consul,Alibaba-Nacos,…)
• Nacos安装、启动、服务的注册、发现机制以及实现过程
• 服务调用时RestTemplate对象的应用。
• 基于Feign方式的服务调用及基本原理？

FAQ分析

• Nacos是什么，提供了什么特性(服务的注册、发现、配置)？
• 你为什么会选择Nacos?（活跃度、稳定、性能、学习成本）
• Nacos的官网？(nacos.io)
• Nacos在github的源码？(github.com/alibaba/nacos)
• Nacos在windows环境下安装?(解压即可使用)
• Nacos在windows中的的初步配置？(application.properties访问数据库的数据源)
• Nacos服务注册的基本过程？（服务启动时发送web请求）
• Nacos服务消费的基本过程？（服务启动时获取服务实例，然后调用服务）
• Nacos服务负载均衡逻辑及设计实现？(Ribbon)
• 注册中心的核心数据是什么？（服务的名字和它对应的网络地址）
• 注册中心中心核心数据的存取为什么会采用读写锁?(底层安全和性能)
• Nacos健康检查的方式？(基于心跳包机制进行实现)
• Nacos是如何保证高可用的?(重试，本地缓存、集群)
• RestTemplate的基本作用是什么？
• Feign是什么，它的应用是怎样的，feign应用过程中的代理对象是如何创建的（JDK）？
• Feign方式的调用过程，其负载均衡是如何实现？(Ribbon)

Bug分析

• 404
• 400
• 405
• 500
• ………