防火墙扫盲     之前在没学网络的时候，认为防火墙真的是可以防火的墙。10多年前还有不少人问，防火墙多少钱一个平方。     但现在大家都知道，防火墙是用来防黑客的，是内部网络和外部网络的分界，是用来保护内部服务器和网络的，是一种信息安全防护系统。 图片来源：https://www.tunnelsup.com/what-is-a-firewall/     防火墙有几个最重要的特征：     1. 部署在内部网络和外部网络之间。这个和建筑上的防火墙真的很类似，也是叫Firewall的原因。     2. 提供基于状态的安全防护。这个描述很专业，也最恰当的描述了防火墙的本质。最开始的防火墙是基于路由器的访问控制列表ACL实现的包过滤防火墙，之后逐步发展和演进为基于状态的防火墙。所谓的状态浅显的讲就是说防火墙会维护一个源IP，目的IP，源端口，目的端口，协议的五元组的连接状态，只有在防火墙上建立起来连接会话状态的报文才会会放行，否则一律丢弃。这是一种很强的防御能力。     防火墙一般情况下是一个安全加固的产品，没有防火墙业务也可以跑起来。就像是小区没有门禁和保安其实也不影响小区的正常使用，但也意味着坏人可以随意的进出，安全风险很大。所以一般上一些规模的用户都会考虑部署防火墙。 NAT网关的防火墙功能     在VPC网络中，有一个企业级的产品叫NAT网关，这个NAT网关中有两个重要的功能一个是SNAT，一个是DNAT。SNAT其实就是一个基于状态的安全防护功能，可以当一个简易的防火墙使用。     当部署完NAT网关后，外部设备3如果想主动访问内部服务器1的话，在NAT网关上会把外部设备3的访问请求拒绝掉，把报文丢弃。因为外部设备3的公网IP 3.3.3.3在NAT网关的SNAT状态表中不存在。     但内部服务器1可以主动访问外部设备2，当内部服务器1对外访问的第一个报文到达NAT网关时，NAT网关会记录下会话状态。假设内部服务器1通过80端口访问外部服务器2的80端口，此时NAT会把五元组信息记录下来并保持状态信息。之后如果外部服务器2以80端口，访问内部服务器1的80端口，此时NAT网关会接受访问请求，并将报文转发到内部服务器。但如果外部服务器2以8080端口访问内部服务器1的80端口时，此时这个访问请求也会被丢弃，因为在SNAT状态表中没有对应五元组的状态连接信息。     上面的描述就是典型的基于状态的安全防护功能，不允许外部的用户或设备主动访问内部的服务器。只允许内部服务器主动访问外部服务器后并建立起连接状态后，外部服务器才能和内部服务器通信。     所以NAT网关在使用中是可以当一个功能简单的防火墙使用的，可以把后端的服务器隐藏到NAT网关后面，不会被黑客扫描到，也不会轻易的被黑客攻击。 最佳实践     举个最佳实践的例子，很多部署在云上的在线支付系统都会调用支付宝的支付接口。而在线支付系统的安全性一般要求是特别高的，不能轻易的被黑客扫描到，不能轻易的被黑客攻击。在这种场景下，用户会选择在VPC网络中部署NAT网关。当前在线支付系统有调用支付宝支付接口的需求时，会通过NAT网关出公网。此时NAT网关会记录调用请求的状态信息。NAT会检查收到的IP报文，只有IP报文的源IP，源端口号，目的IP，目的端口号，协议类型这五元组信息和SNAT状态表中的连接信息相匹配时。NAT网关才会将报文转发到内部支付系统，否则接收到的报文一律丢弃。    

     主持人：下面一个演讲的嘉宾是何铮是立方体的CEO，他们做的一个产品是基于路由器的一个企业管理系统，下面有请他来给我们做介绍。 何铮：大家好，刚才刘总说的，从兴趣到生意，我这块牵涉的是企业管理，一般来讲智能路由都是个人设备或者家居设备，我们做企业管理。我先说一下，因为我本人是之前在用友这个团队，一直做企业管理。从我本人自己团队做这个产品，实际上是从商业到兴趣，我们二十几岁的时候做开发，做企业的管理软件，你说那个能有兴趣吗？那都不是我们的兴趣，那只是完成一个工作，做做做毕竟做了这么长，我们也要去延续它。 在一个偶然的机会，就遇到了葫芦娃，就不知道怎么遇到他，他就搞这些硬件通信，我这个过程就和他有一些交集，因为他在搞这一块。但我在一个偶然的机会里面发现了OpenWrt路由器，是不是我们可以在上面弄一些跟企业有关的东西，这个稍微又会有一点兴趣，至少是一个实体，是一个路由器，至少这些东西我们都从个人开发的角度可以去了解。在经过了一年多的研发东西做出来了，今天第一是想给大家展示一下我们自己的产品，第二个也是大概讲一下我们在企业管理里面，我们的智能路由器可以做到什么。 首先第一个，什么是智能路由器；因为都在想这个事情，大家看PPT，为什么放这个猴子呢？主要的意思就是我本身是属于企业管理这个领域的，就一只鸡跑到一群鸭子里面去了，这个领域是不一样的领域。像罗未说的一样，比如这个OpenWrt开了很多可视系统，所以就放了一个猴子，就是做什么的都有，但是整个来讲就是OpenWrt这个事。 什么是智能路由器呢？我的理解，它不是说上面开发了很多功能就叫智能路由器，因为从硬件还有各个方面，它以前也可以做的，只是我们现在突然有了这么一个产业而已。 从我的角度来讲，最重要的是数据，当然是企业这个角度，因为都知道，智能路由器其实就是入口，这些大牛们都去占入口，在企业里面也是这样子，你把这个数据的入口抓住了，也许我们就认为是一个智能路由器了。 所以我觉得支持云端的路由器才是真正的智能路由器，因为有了云端的大数据，有了很多云端的支持，你这个设备才能真正发挥一个很大的作用。我们在企业这个环境里面，看到有几个特点，是可以符合企业应用。 第一个，它是基于网络的设备，至少在我们一个企业里面，它是必备的一个设备，而且我们传统的企业里面会放很多联网设备，每个都有自己的IP级，有网络管理员去配，每个服务器提供不同的功能，比如说有的CRM、有的OA或者什么IM，其实在一个小企业的环境里面，这样的一个部署也是有难度的。在座可能都是搞这一块的，都不存在这种难度，但是在很多中小企业，其实这一块都是有难度的。 第二点嵌入式的设备它可以24小时工作，以前我是做Java的，那就比较痛苦的就是你做了很多，我们很多客户你卖他一套软件几万块钱十几万觉得很牛逼，你做一个PC上都是在那儿跑完了还装一些游戏搞得你的东西完全被别的东西干扰，而且一会儿死机和你没关系，那我搞一个嵌入式的路由器你总不能这样吧？ 这时，我觉得这是一个很好的机会，日常维护也很简单你搞定重启就搞定了。所以就是这样看的觉得这个事可行然后我们做了一套系统，其实这套系统从通信领域叫UCC就是统一通信协作系统里面包含了基本网络路由还有电话的交换系统VOIP还有一套管理软件，我们觉得企业也是需要一个简单的未来，特别是中小企业它不需要太复杂的一个环境，我们这套系统简单来说的话就这么几块一个是企业管理、通信、移动化和网络基本上是我刚才说的那几个部分，设备是这个样子，那个手是我们同事的手自己照的，等一下大家可以到那边参观一下。它上面的功能有WIFI的考勤，我们把考勤用WIFI的特性来做，因为考勤系统就是为了防止别人代打，你必须到现场这不就是WIFI你必须连着，但是不针对技术人员，要做一些手脚是可以。 基本的企业是可以移动外勤，但是这块就是我们在手机端做的APP你到外面去拜访客户的时候你的老大说你不能到处跑，你得定一个位拍一个图片，全放在这个设备上老大天天在那里看，然后有些客户管理、文档、通讯录、电话短信还有基本的网络。 等一下大家可以到这边来看，我这边先演示电话的部分，其实也没有什么演示的，打通就是演示了。我们这个手机上可以装自己的APP然后我们把这个APP打开，这个没有办法看，就是拨号电话，然后我们那儿放了两部真实的电话机接在我们的路由上面，然后一部电话机是801、802我们就是有一个分机，比如我这边播801然后就响了。这就是电话，假如两个手机都是装了APP我们再尝试一下，响了就接一下然后把视频打开，你的手机、IPAD、话机有可视的。 嘉宾：这个跟你们路由器有关系吗？ 何铮：有关系，都是他弄的。 嘉宾：最大能支持多少？ 何铮：我们针对20人以内的小企业环境，这个演示大概就是这个意思其实在里面可以做很多的应用，因为我们其实是有一套管理页面的，但是客户打电话进来的时候就弹屏，谁之前下过什么订单服务他，就小企业这个是一部分还有移动办公的，手机上有APP就是手机上玩这些东西，这个是有这些功能。 最后一点说一下实现的技术策略，这块其实主要是策略方面，因为他本身和底层开发关系不是特别大，主要的就是我们在这个OpenWrt路由器上面提供一套应用开发的环境，对我们来讲就是Web可以运行的环境，有时候Web服务器也是一个服务器文件存储方式。然后大概的一个意思就是Web服务器我们可以放一些APP简单的东西。数据库可以做一些嵌入式的数据库，其实我们在里面真正在做的这个时候不是简单的把应用环境放进去就可以做一套这么简单，因为我们的这个所谓企业管理里面的数据相对复杂一些，关系复杂一些，可能在策略上就不能是传统的关系数据库，你可能有一些技术或者甚至自己要去做一些数据存储的方案，那么这个就是我们自己做的这个要做一些策略的方案，那么最后文件存储外置U盘，这个U盘里面就可以存储我们的数据，选择一些寿命长的数据跟U盘的这个方案，当然也可以用移动U盘独立供电的，然后我们的Root权限要规划好，因为这个有的数据是频繁的更新的有的数据是比较慢的，所以这个是一些策略上的问题。第二个部分就是把我们的电话系统弄进去，就是这个也是一个开源的电话系统，这个当然在做的过程中有很多细节你要去核实，因为他这个细的问题保留一些最简化的部分，第二个我们就可以去调动，不要把这个事搞这么复杂，以前做Java的时候搞很复杂，你把下面几百行没有什么错误，所以从商业到数据。这块搞好以后还有一个在极小的环境里面开发策略，因为我们要7620里面的内存61兆。 嘉宾：你只有30兆？ 何铮：我只有30兆，但现在反应的情况20人的企业用得非常快，比一般的OV还快，所以这个大概是策略问题，因为我们在Web编程这块可以尽量有到客户端的资源，你界面可以做得很炫，实际上很多压力在客户端，尽量要用一些外部维护。 还有一点每个企业时间的方法要不断的测试，用很多种自己创造的方法去测，找到一个最优化的方法再去真正的放到产品里面去这就是刚才说的。 还有一个是我们的核心，就是刚才只是我们说的一个基本实验的策略，其实最重要的核心我们在路由器上开发了一套工作流引擎和表单引擎，其实这两个组合在一起就可以实现一个大部分的小企业的应用，因为其实大部分的企业管理软件无外乎就是设计一张表根据客户的需求弄进去，然后拿出来根据客户的要求展现出来，那么这块我们就用工作流和表单引擎在完成，这两个部分很显然不能用传统的模式数据库的做法，所以需要把数据的活动状态分类，有些很惰性，有的数据很慢的变化，有的数据变化很快，然后采用不同的文件存储的方式来获取，然后采用一些调度的模式，在不同的环境里面去调度，如果调不过来了就重启一下就是这个模式，用户感觉不到，然后我们还会更多的使用客户端的缓存，把数据同步就行。 最后一点再采用一些我们再采用一些所见即所得的模式，什么意思？就是我们做很多Web开发的时候是根据想要的一个数据表单，完了我设计一套数据库，其实这个表单和数据库之间还要翻译一下再进去，你拿出来翻译一下才能用户看到的样子，其实这个是一个消耗性能最大的部分，我们基本上采用的是你看到的样子和存下来的样子一模一样，甚至我就存成了一个文件下次再打开就是它，我不需要中间再去弄一个东西，大概是这个意思就是用很多方法，有这个兴趣你去做这个事情就有了这个动力，因为没有人在这个上面去想开发一个企业管理，在这个条件下我们就做出了这样的一个产品谢谢大家。 这个界面就是我们访问了路由器的界面实际上就是这个管理系统，第一个屏就是工作的动态，公司内部的动态分享里面有图可以放一些调查文件这些，那红的考勤就是我们单位人全迟到了，天天放在那儿反正我们也不罚钱，就每天看这个就行，然后上面通知公告，然后整个功能模块一个是上面的工作中心，然后新建有，现在你可以转过去，企业来讲就自己去创立自己业务的东西。这个表单就完了流程就这么多，这个东西怎么做谁来干这个事，可以指定一些具体的人到具体的岗位。提交单他真正按照这个跑的，很多人在手机上审批干这个事，然后短信通讯我们接了一个短信网关全国全网的，你只要给你交钱你想谁给发短信就发，但是不能乱发。然后电话中心就是我们那个人都接呼叫呼出的记录，然后你的通话的语音和录音你可以下载，最关键的是你可以听你下属的语音。然后联络中心你比如说点一个客户，这个就是我们一个简单的客户界面，你可以随便加电话、里面的人然后有地图在那儿可以加一个标签，最下面是一个地图，最下面表单的位置因为我数据是空的，这个客户曾经给我下过一个订单或者投诉的投诉单，他打电话的时候这个界面会跳出来并且会显示在那里，然后和他交流。你点一下外勤百度地图，就你们想象一下是这样的，其中那个总经理就是我刚坐在那儿我签到的位置就会显示地图在这个位置，如果在多个结点的话就会有路线。就这么一个用法，大概就是这么一个系统还有手机端也是一样的APP的。 嘉宾：20以上的？ 何铮：那个一年换了，这个我们在研发新的，因为我们下一步还有一些方案。 嘉宾：那结点呢？ 何铮：可以结点，就看怎么用，有些企业比如说50人的企业可能有更好的方案给他，但是如果说是一个很大的公司，我们遇到这种客户它的公司很大，然后他是想一步一步来用，他先是一个功能给他一台，不是云端，有一个云端的控制器，可以把这台里面的应用数据交换到那一台里面去再一个形成相对比较大的网络使用环境。 嘉宾：你语音采用什么接口？ 何铮：就是USB口，自己接的。 嘉宾：电话能打外线吗？ 何铮：可以，我打谁的。 嘉宾：10086。 嘉宾：通过网络走的还是走界面的？ 何铮：打完就出，我播了一个1860006的号码。这个就是播外线的，大家可以看到我们那个设备后面没有接电话线的，所以现在这个模式直接走协议的服务商，当然如果是企业内部的如果有电话线的话肯定要插另外一个网，一个小网端再接到我的视频上。 嘉宾：现在运营商AMI实际上已经开放了？ 何铮：对。 嘉宾：通过移动和中国电信现在已经有服务了针对企业。 何铮：对。 嘉宾：现在我们通过光纤上网，到家里有光端机，光端机有一个电话口的，他那个电话口实际上跑的TCVIP协议，没有这VOIP的技术，他是真实的那个电话也没有的。 何铮：等下有问题下来交流，我们今天就到这里。        本文作者：阿波罗 本文转自雷锋网禁止二次转载，原文链接

传统支付系统面临的挑战 随着近年来移动支付的兴起 ，如条码支付、声波支付、NFC近场支付等，随之还产生了聚合支付把多种支付方式聚合在一起，方便人们的使用，移动支付已经渗透到我们生活的每一个角落，不带钱包出门已经没有任何阻碍。 这就给传统的支付系统提出了新的挑战，用户量激增，系统容量和性能跟不上了。传统的架构往往以IOE技术为主，采用scale up方式以更强的硬件提升系统性能和容量，扩容成本将是巨大的。 支付机构是持牌机构，都有受到监管，对系统稳定性有强要求，传统架构下往往都会用冷备的方式来进行容灾，意味着又要投入一倍的成本。由于数据库主备复制的延时，必须等到数据同步完成才可以切换，容灾切换时间长，进行分布式改造已经刻不容缓。 分布式架构有着海量、成本、稳定、速度的优势，其核心思想是“解决一切单点”，单点容易出故障、性能有瓶颈，那么就拆分成多个点。垂直拆分能更清晰化模块划分，区分治理，水平切分能解决大数据量性能瓶颈问题，分布式改造主要是将这两者结合起来对传统架构进行改造。 分布式改造之垂直拆分 垂直拆分就是将原来一个整体的系统按业务模块拆分成多个系统。系统内部数据是自包含的，不会与别的系统共用数据库，系统与系统之间的交互通过暴露和调用服务来实现。那么如何按照业务来拆分呢？ 为了方便理解，首先我们来看一下一笔支付过程是如何进行的： 图：简化的支付路径图（注：该图来自蚂蚁金服内部） 商户发起收单请求，经过API网关，调到产品层的“在线收单”产品 调用收银台选择支付方式，也可能直接进入支付环节，创建交易流水 进行支付处理，通过金融交换从银行扣客户帐，记录帐务流水，入商户帐，记录账务流水 对交易按照费率进行收费，记录收费的帐务流水。此时会异步触发营销和风控策略 日终会异步进行会计记帐（也有同步记会计帐的）、业会核对、清结算和对帐处理 那么从这个过程我们就可以大概推演出支付系统的一般应用架构： 图：支付系统的应用架构 那么如何进行垂直拆分呢？刚刚我们推演的应用架构派上用场了。 什么是应用架构：应用架构定义一个大型软件系统由哪些应用子系统构成，以及应用之间如何分工和合作。好的应用架构抽象合理、协作有序、易于扩展、能够复用。有了这个应用架构，我们可以非常清晰的根据应用架构划分的子系统来拆分。 从架构上来说，分为四层： 图：支付系统的分层 渠道层：商户和客户的交易请求的入口。一般会划分以下系统：商户网站、用户网站、无线接入、API网关。 产品层：通过基础服务层提供的服务组装成具体业务场景功能，对客户、商户运营等人员提供服务。一般会把服务商户的功能划分为商户域，服务C端用户的划分为用户域。可以按照这两个域拆分成两个子系统，也可以更进一步根据不同产品特性再拆分，比如商户域中的收单产品、虚拟产品、垂直行业产品。 公共服务层：将各个产品都需要使用的些服务抽像成公共服务。一般会划分：收银台、交易支付、计费等系统。比如说产品层可以通过组装各种交易类型和收费规则形成不同的产品。 基础业务层：支付系统的核心，资金和客户信息的处理都在这里。一般会划分三大子系统：帐务核心、会计核心、会员核心。 其它支撑系统： 网关：负责与银行、银联等金融机构进行资金交换，与外部合作伙伴接入，如渠道拓展商、行业客户等。一般划分：银行接入网关和合作伙伴接入网关。 运营支撑：贯穿于四个层的是运营支撑域：一般会划分运营支撑、安全、风控、营销子系统。 垂直拆分本质上是服务化改造，除了上面的讲的按业务拆分，还需要一套分布式服务框架的支撑。 分布式改造之水平拆分 前面讲的垂直拆分只是把系统按业务模块划分到不同的子系统，数据库也分到了不同系统，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。简单的说就是做分库分表。 在做分库分表之前我们需对数据模型进行分类，分为“流水型数据”、“状态型数据”和“配置型数据”。 流水型数据：像流水一样不断增长的数据，各条数据间是独立的。如支付订单、交易流水、帐务流水（入帐/出帐）、会计流水等。 状态型数据：代表一个对象当前的状态的数据。如会员信息、客户信息、帐户信息、会计帐。 为什么有会员信息还有客户信息？会员往往是注册在支付平台的用户，一个人可以注册多个会员，但是一个自然人只可能有一个客户信息，一个会员通过实名认证后就关联上了客户信息。无论一个客户注册多少个会员，实名认证后都只有一个客户信息。 配置型数据：系统中用作为配置的数据。如产品、手续费率、分支机构信息、支付路由规则、会计科目等。 流水型数据会不断产生，且各条数据间是独立的，天然适合进行分库分表。 状态型数据读写比相当，每一次写操作必须基于前一个正确的状态，可以评估一下数据量的大小，数据量如果大或者要实现单元化架构，也需要进行分库分表，提高并发处理能力，同时方便隔离故障影响。如果使用mysql数据库，单表最好不要超过五百万条记录。 配置型数据，读多写少，强依赖读，弱依赖写，不要求严格的读一致性，且配置型数据一般数据量不会很大，不需要进行分库分表设计。但是业务处理中往往又需要用到，传统架构的老系统可能使用了一些关联表操作，关联到了配置数据，分库后其它数据与配置不在一个库，不能进行关联表操作，由于配置型数据不要求严格的读一致性的特点，可以将配置型数据加载到分布式缓存里，如redis、memcached，由业务代码来做“join”。 那么分库分表按照什么规则来拆分呢？通常我们不会按实体id进行hash取模的方式来拆分。因为我们希望同一个用户的数据能够在同一个数据库中，尽量避免产生分布式事务。那么业界普遍的做法是通过用户维度来进行拆分。由于不同的实体id的值不同，且不能保证每个实体和请求中都包含用户id，所以简单的用实体id或用户id进行hash取模将不能保证同一个用户的数据都落在同一个分片。 我们的做法是在用户创建的时候给该用户随机或一定规则（如地区）生成一个两位的分片号00~99（两位意味着可以分成百库百表，通常够用了），那么在生成与该用户相关的所有实体的id的时候都约定把这个分片号拼接到这个id中。那么在分布式数据访问框架中进行路由选择时就可以取id中的分片号进行路由，而不依赖于用户id。且在排查问题的时候也非常方便定位数据的存储位置。 下面是一个参考的id生成规则示例： 所以数据水平拆分除了需要一个强大的分库分表数据访问中间件，还需要一个分布式序列生成器。当然这个生成器也可以是集成在分库分表数据访问中间件中的一个功能。 那么如果一笔交易涉及多个用户按谁的id来拆分呢？比如一笔转账或支付，涉及转出方/转入方或支付方/收款商户。这种情况我们一般按资金转出方来拆分。 分布式改造后带来了哪些问题，如何应对 1. 分布式事务产生 由于按用户维度进行了分库分表，可能存在跨数据库的事务，比如说转账交易中转出方和转入方的账户不在同一个数据库中，这就产生了分布式事务。通常我们不会用XA协议来解决，因为XA协议锁资源性能太差，通常是通过TCC柔性事务来解决。 2. 跨表查询如何解决？ 由于分库分表后，不能进行跨库的连表查询，原来的一些很常见的查询操作变得很麻烦。对于不是以用户为维度的汇总查询也非常麻烦。比如说支付交易流水是按发起方用户（支付方）进行拆分的，用户需要查询自己的账单很容易。但是商户要查询账单就比较麻烦了，要去所有的库里遍历、汇总、分页。也非常耗系统资源。所以一般会做一些数据冗余，比如说蚂蚁内部是专门做了一个账单系统，通过消息队列异步将用户的交易流水同步过来，T+1跑批再按商户维度进行拆分，并生成商户账单。查询帐单都从帐单系统中查询。 还可以通过异构索引来查询和做OLAP分析，异构索引就是将数据同步到ElasticSearch，利用ES的强大索引能力来做查询和分析，为了使业务更容易使用，可以利用数据访问代理层来屏蔽底层是路由到数据库还是路由到ES。 3. 如何进行数据同步？ 企业都有做大数据分析的需求，需要将数据同步大数据平台，如hadoop，分库分表之后，数据同步会比较复杂，毕竟之前是单表同步到 hadoop比较简单，但是100张表同步到hadoop里会复杂一些。 我们需要有一套数据模型管理平台，数据模型、分库分表规则等由这个平台来管理，当需要使用数据的时候通过（应用/逻辑表）维度订阅数据即可，不用单独订阅物理表。不仅是数据同步，凡是有业务需要用到各种数据，都可以通过这个平台来订阅，帮助企业数据业务快速发展。 4.分库分表后批处理任务怎么处理？ 批处理任务，比如有日终对账、清算、生成账单等，原来在一个数据库中的时候，由一个应用Server去数据库中捞取流水就可以了。但是分库分表后流水都落在很多库里，一个Server去每个库里遍历显然不是一个很好的办法，且不能充分利用机器资源，提高批处理效率，甚至由于处理的数据量太大在日终低峰期内根本无法完成任务。 前面提到各条流水数据之间没有关联的，完全可以并发的进行处理，每个Server捞取一个分片的数据进行处理。那么就需要有一个很好的调度系统来协调，可以采用三层调度的方式。 图：三层调度示意图 第一层split：把任务按照分片规则拆分成多个Load任务，并发送到集群中的Server去执行。 第二层load：每个load任务捞取一个分片的数据，逐条创建execute任务，并发送到集群中的Server去执行。注意：捞取数据要进行流量控制以免数据量太大把集群打满。 第三层execute：执行具体的一条数据的逻辑。 三层架构并不是说一定都需要三层，可以根据业务逻辑来定制只有两层也可以。 5. 如何进行数据扩容？ 通常我们会采用“预分配”的方式来做，即一开始我们就按一个比较长期的容量来规划分片数，比如百库百表，但实际上一开始并没有这么大的量，所以实际只有两个数据库Server，在这两个Server上分别建50个schema，逻辑上扔然是100个分库，物理上只有2个数据库Server，当容量不够的时候，为了保证数据的均衡，我们通常会采用成倍扩容的方式，再加两台数据库Server，然后分别迁移25个schema到这两个数据库Server上，数据也搬过来，由于数据同步有延时，全量数据同步完成后，两边的schema都禁写，待增量数据同步完成后打开新的schema写，会产生短暂的部分用户交易失败，重试一下即可，在低峰期做迁移，产生小范围失败一般是可以接受的。由于逻辑分片数没有变化，扩容成本比较低。我们通常不会用改变分片规则的方式来扩容，因为改变分片规则需要进行数据重新分布，成本和风险巨大。 6. 如何进行容灾？ 同城容灾：通常可以同城多机房部署应用，数据库只有一个机房处于Active状态，所有机房的应用都连这个机房的数据库，另一个机房的数据库为备库，进行主备复制，当备机房发生灾难时业务不会中断，但业务会跌一半，当主机房发生灾难时，数据库切换备库，会有短暂的业务中断。 异地冷备：应用也是异地多机房部署，由于异地网络延时不可忽略，异地备机房是处于standby状态，正常是没有流量的，冷备机房采用数据库主备同步的方式同步数据，这种方式灾备切换时间长，成本投入高。 异地多活：应用采用异地多机房单元化部署架构，每个机房的应用都是可以提供服务的，单元内是自包含部署全量应用，每个单元服务多个分片的用户，单元化架构可以参考《素描单元化》。由于异地网络延时是不可忽略的，数据层的容灾方案也是分“流水型”、“状态型”、“配置型”数据采用不同的容灾策略。具体可参考《分布式系统数据层设计模式》。 7. 如何更好的排查和分析问题？ 分布式改造后整个系统架构已经是服务化了，原来通常可以通过查本地日志来定位问题。但现在一个交易由若干个系统协同完成，我们需要一套分布式链路跟踪系统或APM（应用性能管理）系统来协助我们看清整个系统的全貌，分析排查问题。那么如何进行分布式链路跟踪呢？可以通过opentracing标准对整个分布式架构中的中间件和应用进行埋点或自动植入探针实现。 总结 分布式架构有着海量、成本、稳定、速度的优势，但它也不是银弹，分布式改造是一个非常复杂的工程，需要熟悉业务，设计出整个系统的业务架构，按照业务架构来进行垂直拆分。需要熟悉数据模型，区分“流水型”、“状态型”、“配置型”数据，根据不同类型数据的特点将它他按用户维度进行拆分。 熟悉分布式中间件的运用，分布式中间件在整个分布式架构中起着至关重要的作用，将技术构架与业务结合起来。整个改造需要公司内部下定决心，All in的方式进行。蚂蚁金服通过十五年五代金融级架构的演进，多年双11的考验，形成了一套业界领先的金融级分布式架构。 — END — < 粉丝福利时间 > 恭喜以下用户您获得『蚂蚁金服科技』粉丝福利：云栖2050门票一张 xyzlab、空、Limo、覔亖甴、Joe-姜忠坷、纯、成崽儿、圣爱、魔方、Monte、山在北国、dk、Mystery、莫那·鲁道、德 立、0.0、成东青、欲 乱 人 心 、笑吧、軍軍軍军  请获奖的用户添加蚂蚁小助手微信号：Ant-Techfin01，或扫描下方二维码 回复“2050门票”然后领取您专属的兑换码 购票官网：https://www.yunqi2050.org/#/index 非常感谢大家对蚂蚁金服技术的支持和关注！ 如有问题，我们将随时为您答疑解惑 后续小蚂蚁会努力给您带来更多福利哦~

原创声明：本文系作者原创，谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。 传统支付系统面临的挑战 随着近年来移动支付的兴起 ，如条码支付、声波支付、NFC 近场支付等，随之还产生了聚合支付把多种支付方式聚合在一起，方便人们的使用，移动支付已经渗透到我们生活的每一个角落，不带钱包出门已经没有任何阻碍。这就给传统的支付系统提出了新的挑战，用户量激增，系统容量和性能跟不上了，传统的架构往往以 IOE 技术为主，采用 scale up 方式以更强的硬件提升系统性能和容量，扩容成本将是巨大的。支付机构是持牌机构都是受监管的，对系统稳定性有强要求，传统架构下往往都会用冷备的方式来进行容灾，意味着又要投入一倍的成本，由于数据库主备复制的延时，必须等到数据同步完成才可以切换，容灾切换时间长。进行分布式改造已经刻不容缓。 更多关于传统架构与分布式架构对比请参考《集中式架构与分布式架构比较》 分布式架构在容量、性能、稳定性、成本方面都具有巨大的优势。在高可用方面，核心思想之一是“解决一切单点”，单点容易出现故障，性能方面也可能成为瓶颈，因此需要将单点改造拆分成多个点。垂直拆分能更清晰化模块划分，区分治理，水平切分能解决大数据量性能瓶颈问题，分布式改造主要是将这两者结合起来，对传统架构进行全面的改造。 分布式改造之垂直拆分 垂直拆分就是将原来一个整体的系统按业务模块拆分成多个系统，系统内部数据是自包含的，不会与别的系统共用数据库，系统与系统之间的交互通过暴露和调用服务来实现。那么如何按照业务来拆分呢？ 为了方便理解，首先我们来看一下一笔支付过程是如何进行的： 商户发起收单请求，经过 API 网关，调到产品层的“在线收单”产品 调用收银台选择支付方式，也可能直接进入支付环节，创建交易流水 进行支付处理，通过金融交换从银行扣客户帐，记录帐务流水，入商户帐，记录账务流水 对交易按照费率进行收费，记录收费的帐务流水。此时会异步触发营销和风控策略 日终会异步进行会计记帐（也有同步记会计帐的）、业会核对、清结算和对帐处理 从这个过程可以大概推演出支付系统的一般应用架构： 图：支付系统的应用架构 应用架构定义一个大型软件系统由哪些应用子系统构成，以及应用之间是如何分工和协作的。好的应用架构抽象合理、协作有序、易于扩展、能够复用。有了这个应用架构，我们就可以非常清晰的根据应用架构划分的子系统来进行垂直拆分。 从架构上来说，分为四层： 图：支付系统的分层 渠道层：商户和客户的交易请求的入口。一般会划分以下系统：商户网站、用户网站、无线接入、API 网关。 产品层：通过基础服务层提供的服务组装成具体业务场景功能，对客户、商户运营等人员提供服务。一般会把服务商户的功能划分为商户域，服务 C 端用户的划分为用户域。可以按照这两个域拆分成两个子系统，也可以更进一步根据不同产品特性再拆分，比如商户域中的收单产品、虚拟产品、垂直行业产品。 公共服务层：将各个产品都需要使用的些服务抽像成公共服务。一般会划分：收银台、交易支付、计费等系统。比如说产品层可以通过组装各种交易类型和收费规则形成不同的产品。 基础业务层：支付系统的核心，资金和客户信息的处理都在这里。一般会划分三大子系统：帐务核心、会计核心、会员核心。 其它支撑系统： 网关：负责与银行、银联等金融机构进行资金交换，与外部合作伙伴接入，如渠道拓展商、行业客户等。一般划分：银行接入网关和合作伙伴接入网关。 运营支撑：贯穿于四个层的是运营支撑域：一般会划分运营支撑、安全、风控、营销子系统。 垂直拆分本质上是服务化改造，除了上面讲的按业务拆分，还需要一套分布式服务框架的支撑。 分布式改造之水平拆分 前面讲的垂直拆分只是把系统按业务模块划分到不同的子系统，数据库也分到了不同系统，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。简单的说就是做分库分表。 在做分库分表之前我们需对数据模型进行分类，分为“流水型数据”、“状态型数据”和“配置型数据”。 流水型数据：像流水一样不断增长的数据，各条数据间是独立的。如支付订单、交易流水、帐务流水（入帐/出帐）、会计流水等。 状态型数据：代表一个对象当前的状态的数据。如会员信息、客户信息、帐户信息、会计帐。 为什么有会员信息还有客户信息？会员往往是注册在支付平台的用户，一个人可以注册多个会员，但是一个自然人只可能有一个客户信息，一个会员通过实名认证后就关联上了客户信息。无论一个客户注册多少个会员，实名认证后都只有一个客户信息。 配置型数据：系统中用作为配置的数据。如产品、手续费率、分支机构信息、支付路由规则、会计科目等。 流水型数据会不断产生，且各条数据间是独立的，天然适合进行分库分表。 状态型数据读写比相当，每一次写操作必须基于前一个正确的状态，可以评估一下数据量的大小，数据量如果大或者要实现单元化架构，也需要进行分库分表，提高并发处理能力，同时方便隔离故障影响。 配置型数据，读多写少，强依赖读，弱依赖写，不要求严格的读一致性，且配置型数据一般数据量不会很大，不需要进行分库分表设计。但是业务处理中往往又需要用到，传统架构的老系统可能使用了一些关联表操作，关联到了配置数据，分库后其它数据与配置不在一个库，不能进行关联表操作，由于配置型数据不要求严格的读一致性的特点，可以将配置型数据加载到分布式缓存里，由业务代码来做“join”。 那么分库分表按照什么规则来拆分呢？通常不会按实体 id 进行 hash 取模的方式来拆分。因为希望同一个用户的数据能够在同一个数据库中，尽量避免产生分布式事务。业界普遍的做法是通过用户维度来进行拆分。由于不同实体 id 的值不同，且不能保证每个实体和请求中都包含用户 id，所以简单的用实体 id 或用户 id 进行 hash 取模将不能保证同一个用户的数据都落在同一个分片。 一种推荐做法是，在用户创建的时候给该用户随机或一定规则（如地区）生成一个两位的分片号 00~99（两位意味着可以分成百库百表，通常够用了），那么在生成与该用户相关的所有实体的 id 的时候，都约定把这个分片号拼接到这个 id 中。在分布式数据访问框架中进行路由选择时，就可以取 id 中的分片号进行路由，而不依赖于用户 id。且在排查问题的时候也非常方便定位数据的存储位置。 下面是一个参考的 id 生成规则示例： 所以数据水平拆分除了需要一个强大的分库分表数据访问中间件，还需要一个分布式序列生成器。当然这个生成器也可以是集成在分库分表数据访问中间件中的一个功能。 那么如果一笔交易涉及多个用户按谁的 id 来拆分呢？比如一笔转账或支付，涉及转出方/转入方或支付方/收款商户。这种情况一般可以按资金转出方来拆分。 分布式改造后带来的问题如何应对 分布式事务产生 由于按用户维度进行了分库分表，可能存在跨数据库的事务，比如说，转账交易中转出方和转入方的账户不在同一个数据库中，这就产生了分布式事务。通常不会用 XA 协议来解决，因为 XA 协议锁资源性能太差，通常是通过 TCC 柔性事务来解决。具体可以参见进阶阅读《分布式事务综述》。 跨表查询如何解决 由于分库分表后，不能进行跨库的连表查询，原来的一些很常见的查询操作变得很麻烦。对于不是以用户为维度的汇总查询也非常麻烦。比如说支付交易流水是按发起方用户（支付方）进行拆分的，用户需要查询自己的账单很容易。但是商户要查询账单就比较麻烦了，要去所有的库里遍历、汇总、分页。也非常耗系统资源。所以一般会做一些数据冗余，例如专门实现一个账单系统，通过消息队列异步将用户的交易流水同步过来，T+1 跑批再按商户维度进行拆分，并生成商户账单。查询帐单都从帐单系统中查询。 还可以通过异构索引来查询和做 OLAP 分析，异构索引就是将数据同步到 ElasticSearch，利用 ES 的强大索引能力来做查询和分析，为了使业务更容易使用，可以利用数据访问代理层来屏蔽底层是路由到数据库还是路由到 ES。 如何进行数据同步 企业都有做大数据分析的需求，需要将数据同步大数据平台，如 Hadoop。分库分表之后，数据同步会比较复杂，毕竟之前是单表同步到 Hadoop 比较简单，但是 100 张表同步到 Hadoop 里会复杂一些。这时就需要设计一套专门的数据模型管理平台，数据模型、分库分表规则等由这个平台来管理，当需要使用数据的时候通过（应用/逻辑表）维度订阅数据即可，不用单独订阅物理表。不仅是数据同步，凡是有业务需要用到各种数据，都可以通过这个平台来订阅，帮助企业数据业务快速发展。 分库分表后批处理任务怎么处理 批处理任务，比如有日终对账、清算、生成账单等，原来在一个数据库中的时候，由一个应用 Server 去数据库中捞取流水就可以了。但是分库分表后流水都落在很多库里，一个 Server 去每个库里遍历显然不是一个很好的办法，且不能充分利用机器资源，提高批处理效率，甚至由于处理的数据量太大在日终低峰期内根本无法完成任务。 前面提到各条流水数据之间没有关联的，完全可以并发的进行处理，每个 Server 捞取一个分片的数据进行处理。那么就需要有一个很好的调度系统来协调，可以采用三层调度的方式。 图：三层调度示意图 第一层 split：把任务按照分片规则拆分成多个 Load 任务，并发送到集群中的 Server 去执行。 第二层 load：每个 load 任务捞取一个分片的数据，逐条创建 execute 任务，并发送到集群中的 Server 去执行。注意：捞取数据要进行流量控制以免数据量太大把集群打满。 第三层 execute：执行具体的一条数据的逻辑。 三层架构并不是说一定都需要三层，可以根据业务逻辑来定制只有两层也可以。 如何进行数据扩容 通常可以采用“预分配”的方式来做，即一开始就按一个比较长期的容量来规划分片数，比如百库百表。但实际上一开始并没有这么大的量，所以实际只有两个数据库 Server，在这两个 Server 上分别建 50 个 schema，逻辑上仍然是 100 个分库，物理上只有 2 个数据库 Server。当容量不够的时候，为了保证数据的均衡，通常会采用成倍扩容的方式，再加两台数据库 Server，然后分别迁移 25 个 schema 到这两个数据库 Server 上，数据也搬过来。由于数据同步有延时，全量数据同步完成后，两边的 schema 都禁写，待增量数据同步完成后打开新的 schema 写，会产生短暂的部分用户交易失败，重试一下即可，在低峰期做迁移，产生小范围失败一般是可以接受的。由于逻辑分片数没有变化，扩容成本比较低。通常不会用改变分片规则的方式来扩容，因为改变分片规则需要进行数据重新分布，成本和风险巨大。 如何进行容灾 同城容灾：通常可以同城多机房部署应用，数据库只有一个机房处于 Active 状态，所有机房的应用都连这个机房的数据库，另一个机房的数据库为备库，进行主备复制，当备机房发生灾难时业务不会中断，但业务会跌一半，当主机房发生灾难时，数据库切换备库，会有短暂的业务中断。 异地冷备：应用也是异地多机房部署，由于异地网络延时不可忽略，异地备机房是处于 standby 状态，正常是没有流量的，冷备机房采用数据库主备同步的方式同步数据，这种方式灾备切换时间长，成本投入高。 异地多活：应用采用异地多机房单元化部署架构，每个机房的应用都是可以提供服务的，单元内是自包含部署全量应用，每个单元服务多个分片的用户，单元化架构可以参考《素描单元化》。由于异地网络延时是不可忽略的，数据层的容灾方案也是分“流水型”、“状态型”、“配置型”数据采用不同的容灾策略。具体可参考《分布式系统数据层设计模式》。 如何更好的排查和分析问题 分布式改造后整个系统架构已经是服务化了，原来通常可以通过查本地日志来定位问题。但现在一个交易由若干个系统协同完成，我们需要一套分布式链路跟踪系统或 APM（应用性能管理）系统来协助我们看清整个系统的全貌，分析排查问题。那么如何进行分布式链路跟踪呢？可以通过 OpenTracing 标准对整个分布式架构中的中间件和应用进行埋点或自动植入探针实现。 总 结 分布式架构有着海量、成本、稳定、速度的优势，但它也不是银弹，分布式改造是一个较为复杂的工程，既需要熟悉业务，能够设计出整个系统的业务架构，按照业务架构来进行垂直拆分，又需要熟悉数据模型，区分“流水型”、“状态型”、“配置型”数据，根据不同类型数据的特点将它他按用户维度进行拆分，还需要熟悉分布式中间件的运用。分布式中间件在整个分布式架构中起着至关重要的作用，将技术构架与业务结合起来。蚂蚁金服通过多年金融级架构的演进，经过多年双十一大促的验证，已经形成了一套业界领先的金融级分布式架构，请参考《金融级分布式交易的技术路径》。

【说明】这是发表在《程序员》电子刊10月B架构专题文章 网页链接：http://www.csdn.net/article/2015-10-31/2826093 摘要：互联网+和物联网由于发展的侧重点不同，在做架构设计上肯定有所不同。而以中小项目为主的物联网项目，其实更看重的，一是系统稳定可靠，能保证系统长期稳定的运行。本文主要介绍工业级物联网项目的架构设计及实施。 前言 早在1999年就已经有了“物联网”这个概念，但是直到十年之后的2009年，IBM提出“智慧地球”的概念，才推动很多国家把物联网研究和发展提升到战略层面。但是比较遗憾的是，直到现在的2015年，我国的物联网的发展依然主要靠政府项目来拉动，所以现在的发展似乎前景越来越不明朗。 政府似乎意识到这是个问题，在一些互联网公司的倡导和推动下，提出了“互联网+”的概念。虽然“互联网+”和“物联网”都是以网为主，但是发展的侧重有了本质区别。“互联网+”是以互联网为主，外围智能模块和传感器为辅，构建互联生态。而“物联网”却是以互联网为基础，重点在传感器数据采集，设备控制，远程监控为主。 但是现在很多互联网公司，做的是“互联网+“的事，却以”物联网“的名义来宣传。所以现在的人越来越搞不清”物联网“的真实定位了。 我一直认为从技术角度来看，所谓“物联网“就是传统工控网的一个外延。传统的工业现场，考虑到生产安全，都是内部网络。另外实施和维护的代价相对较高。而在互联网和移动互联网越来越完善的今天，在各个领域都有了远程测控的要求。比如目前比较典型的农业大棚监控、森林防火监控、鱼塘监测和养殖管理等等。 “互联网+”和“物联网”由于发展的侧重点不同，在做架构设计上肯定有所不同。“互联网+“的项目，其实更看重的是用户数，通信数据流量，这是衡量一个”互联网+“项目成功的标志，当然这是也是那些做云平台为主的互联网公司最看重的，用户数和通信数据流量正是他们的利益点所在。 而以中小项目为主的“物联网”项目，其实更看重的，一是系统稳定可靠，能保证系统长期稳定的运行，因为有些监控点往往部署在人迹罕至的地方，系统的可靠性成为关键。二就是系统便于开发和维护，因为基于不同行业，不同工艺需求的，很难开发出像民用领域的通用产品，需要根据现场实际调整相关的业务逻辑和监控画面，所以是否易于开发很关键。当然维护更为重要，因为偏工业级的“物联网”项目一般设计至少是三年或更长的生命周期，所以项目维护难以避免，甚至系统还会根据现场工艺的变更进行变化，易于维护是“物联网“项目一个不可或缺的要素。 由以上的说明，我们可以很清晰地了解，从技术角度来讲，做“互联网+”和“物联网”项目的架构设计是有很大的不同，本篇文章主要介绍工业级“物联网”项目的架构设计及实施。 工业级物联网的概念和特色 由于笔者曾经在传统工控领域工作7年之久，所以理解“物联网”更多是从工控的角度来考虑。所谓的工业级物联网，不是工业领域的物联网，而是具备工业领域的特色的物联网项目，比如农、林、牧和渔业等领域的相关项目。和工业领域的项目不同，没有那么庞大和要求严格，采集和监控的数据也相对较少，对设备、及实施和维护的成本比较敏感，并且一般要求远程监控。但是相同的要求是，设备要稳定可靠，便于根据工艺要求调整控制策略，方便升级、扩展，易于维护。 传统工控项目，一般相对庞大，环节多，开发和实施周期都比较久，当然项目的费用也是相对高昂的。往往一个实施工控项目的公司，一年能做十几个这样的项目就已经很繁忙了。而在物联网时代，由于互联网和移动互联网基础设施比较完善，云服务公司也是层出不穷，可以花最少的代价，相对快速的完成一些项目。 由于开发和实施的代价大大降低，所以可做的领域被大大拓宽了，形成了一个良性循环，做的越多，越可靠，也越便宜。越便宜，可做的项目也越来越多。 工业级物联网项目架构设计思想 了解了工业级的物联网项目的一些特色，所以架构设计方面就有了方向和思路。我们先从技术角度分析，当前一个典型的物联网项目，从组成上来讲，至少有三部分：一是设备端，二是云端（主要指公有云），三是监控端。 1. 设备端架构设计 设备端主要负责数据采集，工艺逻辑执行及控制。 无论底层的设备数量有多少，通信协议有多复杂，考虑到项目安全等等因素，往往和云端通信，汇集在一个设备上，这样的设备的角色往往是物联网网关，除了专门负责和云端进行通信外，有时候也会对原始数据进行一定的处理，执行一些业务逻辑相关的代码。 和云端通信有很多协议可选，常见的有基于HTTP协议的Get或Put方法，从服务器获取一些设置及状态，及向服务器推送采集到的数据。但是对数据量相对比较大，实时性要求高的，往往是直接的Socket TCP/UDP通信，这样传输的代价相对较低，但是对编程设计方面要求比较高。 由以上分析，从功能层面上分，设备端架构一般可分三层，一是数据采集&控制输出层；二是工艺流程执行层；三是数据上传&命令接收通信层。 2. 云端架构设计 云端一般包含三部分：Web前台+ Web后台+中间件； 作为工业级的物联网项目，Web前台一般会显示这几部分内容，一是工艺画面，和现场实际的设备和工艺流程一一对应，画面可以实时反映工业现场运行的情况。二是各种数据报表、曲线数据的保存、查询和打印等。三是运行日志，保存各种运行情况，以备查询。四是显示系统诊断信息，便于系统出现问题的时候，及时判断问题所在。 Web后台相对复杂一些，一般完成三部分内容的工作，如果是设备端基于HTTP协议通信，往往需要处理Get和Put请求。由于前台有实时画面，所以Web后台有时候也需要向前台界面传输实时数据，目前有些实时数据是通过Web Socket协议进行传输，也可以由专门的程序来处理。还有一部分功能比较重要，就是要建立设备数据和各种报表，曲线，日志的对应关系，以便于适用尽可能多的现场。 在工业级物联网项目中，一般中间件必不可少，其主要功能就是负责和现场设备进行通信，获取数据或发送相关控制指令。此外还有一个比较重要的功能，由于中间件程序一般是作为系统的一个服务程序或普通应用程序，生命周期较长，可以长时间连续运行，可以处理一些相对复杂的业务逻辑、数据换算及数据转储。 3. 监控端架构设计 监控端一般包含PC、手机或平板监控。 对一般项目而言，也许通过Web前台就可以掌控一切了，但是在移动互联网的时代，如果对应的手机或平板上没有对应的APP，那这个项目就感觉有了一个很大的缺憾。有了手机或平板APP，就可以身在任何地方，都可以相对方便的监控现场。 从功能上划分，架构可以相对简单的分为两层，一就是UI界面显示及操作层，二就是数据通信层，实现和服务器信息交互。 4. 小结 如果抛开其他一切因素，仅从技术角度来讲，实现以上三个大环节的功能，用什么系统平台，任何开发语言都可以完成其预定的功能。但是所谓的架构设计，不仅仅从功能角度来设计整个的系统平台，更多还要考虑其可靠性，扩展性，维护性等几个方面。 作为工业级的物联网项目，大都是面向工、农、牧、渔等具体行业，每种行业虽然从技术角度而言有很多类似的部分，但是从工艺流程角度又有很大的区别，所以针对具体的项目，进行代码调整及相关功能的扩展及二次开发必不可少。但是面向一线的工程师往往技术水平及能力相对比较低，能否快速编写出可靠、健壮的代码显的非常重要，毕竟每个项目现场实施时间是有限的，但是同时项目要求也是比较高的。 另外一个物联网项目，包含了嵌入式设备的开发、Web前后台的开发、服务程序开发还有手机和平板程序开发，每一项从技术平台上来说各种各样，比如嵌入式设备，有微软体系的Windows CE/XPE/.NET Micro Framework,有linux体系的嵌入式linux/uclinux等等，还有uCOSII/FreeRTOS/mbed OS等等实时嵌入式操作系统，其开发工具，系统架构各不相同，各有特色。手机和平板目前至少也有三种开发类型，一种是iOS开发，一种是安卓开发和windows 10 UWP通用程序开发等等。另外Web开发就更多了，这里就不一一举例了。 所以如果在整体架构设计中，每种部分都选用不同的技术路线，那么每一种技术路线，意味着都要有一个团队去开发，并且开发完毕后，还需要上下进行沟通，以便于把整个项目有机地联系在一起。 开发完毕后，更多的还有维护工作，不仅是开发团队的维护，更为重要的是现场维护，除了问题，如何及时定位，及时解决。针对如上问题，加上多年的现场实施和维护经验，所以我更看重统一化和组态化的架构设计，下面我就讲讲我们是如何构建物联网项目的。 物联网通用中间件平台架构设计 由于是一个物联网通用中间件开发平台，所以着眼点并不是一两个非常有行业特点的项目平台，而是面向不同行业，不同具体应用的二次开发平台，更多考虑跨行业应用的技术通用部分及同一个运行时平台支持多个项目点的功能。 下面我们就设备端、云端中间件及物联网通用平台分别进行介绍。 4.1 物联网嵌入式数据组态YFIOs架构设计 在工控领域，组态软件司空见惯。为什么很多工业项目采用组态软件，原因主要有两点，一是模块化搭积木式的设计，技术门槛低，实施速度快，非常适合工控技术人员使用；二是可靠性非常高，由于模块之间耦合性低，重用度高，并且每个模块往往在不同项目现场，实际都得到过运行考验，所以稳定性自不待言。 YFIOs的设计思想就来源于标准的组态软件，但是又具备了一些物联网时代的功能特色。 图1 YFIOs系统架构  从图1架构图上可以看出，YFIOs包含三大部分：驱动层、策略层和核心层。 底部驱动层支持大部分物理通信接口，主要功能就是和传感器（或智能模块）通信，获取相关的传感器数据及发送控制执行指令。 上部策略层除了加载执行一些系统策略（如系统通信策略）外，还可以加载用户策略，这样可以基于现场工艺流程，立即就可以进行相关的工艺控制操作，不用送到服务端，等服务端远程发出控制指令。 中间核心层是最关键的，除了启动驱动和策略引擎外，还创建了两个内存数据库。一个是IODB，主要存放点数据（如温度、湿度数据），另外一个是IOBC，主要存放块数据（如摄像头图片）。策略程序和驱动程序，完全解耦合，通过IODB和IOBC进行数据交互。 和传统组态软件（特指数据组态部分）相比，YFIOs有如下特色： 基于.NET系统进行驱动和策略开发，由于系统自带垃圾回收机制，不用担心在编写驱动和策略过程中，因内存溢出等原因导致系统当机。 传统的组态软件一般对外不提供驱动开发SDK，即使有，大都也采用C++进行开发，对开发者要求比较高。YFIOs和传统组态软件不同，驱动可以采用C#和VB.NET进行开发。且驱动有多种运行模式，不仅系统可以调用，用户策略也可以调用。还可以绑定策略事件，通过触发的方式去执行指定的策略。 YFIOs的驱动可以动态替换，如果配置了相关的连接变量，只要驱动变量接口兼容就可以替换，这大大降低了系统运行后的维护成本，外围的硬件设备可以根据需要进行替换。 YFIOs系统支持远程升级和远程调试。支持三个层面升级，YFIOs运行时升级、YFIOs驱动和策略升级和YFIOs配置升级。 针对设备端，我们也设计了基于物联网画面的组态软件YFHMI，由于这部分其实和传统的画面组态区别不是很大，所以这里限于篇幅，不再介绍了。 2. 物联网云端中间件YFCloud架构设计 云端YFCloud中间件平台，可以说是完全脱胎于嵌入式YFIOs，从图2的架构图上就可以明显看出，可以这样说，YFIOs是一个“单机版”的数据组态平台，而YFCloud是一个“网络版”数据组态平台。 YFCloud和YFIOs都可以运行策略程序和创建IODB内存数据库，不同的是YFCloud去掉了IODC内存数据库，并且驱动层简化为一种，就是TCP/IP通信接口,每一个远程设备，服务器都会分配一个Socket连接，登录成功后，才能正常通信。如果设备30秒上传数据无变化，则发送心跳信号，否则60秒无数据收到，服务器会主动关闭连接。 图2 YFCloud中间件架构  YFCloud还集成了WebSocket服务器，Web动态网页可以通过WebSocket协议和服务器进行通信。 YFCloud物联网中间件平台是以项目为最小单位来进行管理的，一个或多个项目对应一个项目模板，项目通过项目ID进行区分。由于是二次开发平台，所以YFCloud提供了一个平台级的开发接口，通过接口可以管理相关的项目模板和项目（如创建、编辑、删除、启动和停止等）。 3. 物联网通用平台架构设计 图3 物联网通用平台架构  YFIOs嵌入式数据组态运行在物联网智能网关上，直接和YFCloud进行通信（云端中间件通过导入YFIOs的上传IO表，就可以直接进行通信了）。 物联网通用平台的Web前台，目前默认具备如下功能（每个项目模板可以根据需要，进行选择所需要的功能，项目完全继承了项目模板的选择）工艺流程显示、工艺报表（日报表，统计报表）、工艺曲线显示、项目运行日志、工艺参数配置和摄像头监控等等。 物联网通用平台的Web后台，主要功能就是用户管理、角色管理（和功能匹配的角色）、项目模板管理和项目管理。限于篇幅，就不详细介绍了。 4. 小结 该平台的最大优势就是，从软到硬，全部采用了.NET平台。所以不需要太多的技术人员，就可以从上到下进行项目开发。对客户来说，由于涉及到的技术领域比较少，所以二次开发及后续平台维护也比较容易。 物联网项目案例简介 1. 家庭远程健康监控系统 这是比较早的一个案例了。设备外接血糖仪、血压计、摄像头、温湿度模块，内部集成了RFID刷卡器及3G模块。通过3G和远程服务器进行通信，用户或医生通过网页查看相关信息，其中医生还可以远程留言并发送到设备。采用组态式的架构最大的好处就是， 由于每个家庭已有的血糖仪或血压计型号不同，设备可以根据对应的传感器型号，选择不同的驱动，可远程部署驱动进行适配。 图4 远程监控检测设备连接图 2. 农业大棚监控系统 系统核心为物联网智能网关，外部连接摄像头、温湿度传感器，通过以太网、Wifi或3G路由器把相关数据推送到服务器。 客户可以通过PC、平板或手机远程监控蔬菜大棚中的作物生长情况。 图5 农业大棚手机监控图  3. 近海渔业监控系统 通过水质传感器，获取当前水质情况（Modbus RTU通信）；通过摄像头获取当前图片；通过GPS获取当前经纬度；通过GPRS模块把数据传送到远端服务器。 图6 渔业监控设备连接示意图  4. 村级污水处理监控系统 物联网智能网关通过RS485/CAN和智能终端连接在一起，智能终端采集各种数据，或控制相关设备运行。网关通过无线路由器或GPRS模块向服务器发送数据，或者接收服务器的控制指令。 Web网页可以查看现场工艺流程界面，工艺报表及设置工艺参数等等。 图7 污水监控设备连接示意图  图8 污水监控Web界面图 物联网项目开发的未来发展方向 现在国内外互联网企业巨头，瞄准的物联网领域，大都是民用领域，如智能家居、车联网等等。这些领域的特点就是量大、并且相对统一，每个客户不需要特别的定制（特别是硬件层面，区别不大，个性化最多在软件层面）。 但是在非民用领域，即使类似的项目，往往因为最终客户不同，工艺流程的差异，软硬件也会有相对大的变动。另外和民用产品不同，一是应用环境相对恶劣，二是要求24*7连续运行，对稳定可靠性要求比较高，三是要便于扩展，便于维护。 所以这类物联网项目，未来的发展方向，肯定是首先在可靠性上下工夫，满足长期使用的需求后，就是尽可能提取共用部分，让每个项目的修改量降到最低。 当然未来最有可能的发展方向就是，随着现在分工越来越细，云计算发展的越来越成熟，物联网协议标准的确立和客户技术能力的提高，未来也许是在最终客户的统一协调下，不同物联网厂商各做一部分（或软或硬），共同完成最终的项目。 （责编/ 钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，交流探讨可加微信qshuguang2008，备注姓名+公司+职位） 作者简介：刘洪峰，网名叶帆，叶帆科技创始人兼CEO，前微软（中国）.NET Micro Framework开发团队成员，微软全球最有价值专家(MVP)，CSDN十大MVB。以微软.NET MF系统为核心，研发了物联网智能网关、YFIOs和YFHMI等物联网中间件软硬件平台。 

大家好我是许振文，今天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务应用实践》，内容主要分为以下四个部分： 背景和解决框架介绍 实时大数据计算 OneData 数据接口服务 OneFun 微服务化& ServiceMesh 一、背景和解决框架介绍 1、离线数据运营和实时数据运营 首先介绍下背景，我们做游戏数据运营的时间是比较久的了，在 13 年的时候就已经在做游戏离线数据分析，并且能把数据运用到游戏的运营活动中去。 但那时候的数据有一个缺陷，就是大部分都是离线数据，比如今天产生的数据我们算完后，第二天才会把这个数据推到线上。所以数据的实时性，和对游戏用户的实时干预、实时运营效果就会非常不好。尤其是比如我今天中的奖，明天才能拿到礼包，这点是玩家很不爽的。 现在提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，所以我们从 16 年开始，整个游戏数据逐渐从离线运营转到实时运营，但同时我们在做的过程中，离线数据肯定少不了，因为离线的一些计算、累计值、数据校准都是非常有价值的。 实时方面主要是补足我们对游戏运营的体验，比如说在游戏里玩完一局或者做完一个任务后，立马就能得到相应的奖励，或者下一步的玩法指引。对用户来说，这种及时的刺激和干预，对于他们玩游戏的体验会更好。 其实不单单是游戏，其他方面也是一样的，所以我们在做这套系统的时候，就是离线+实时结合着用，但主要还是往实时方面去靠拢，未来大数据的方向也是，尽量会往实时方向去走。 2、应用场景 ■ 1）游戏内任务系统 这个场景给大家介绍一下，是游戏内的任务系统，大家都应该看过。比如第一个是吃鸡里的，每日完成几局？分享没有？还有其他一些活动都会做简历，但这种简历我们现在都是实时的，尤其是需要全盘计算或者分享到其他社区里的。以前我们在做数据运营的时候，都是任务做完回去计算，第二天才会发到奖励，而现在所有任务都可以做到实时干预。 游戏的任务系统是游戏中特别重要的环节，大家不要认为任务系统就是让大家完成任务，收大家钱，其实任务系统给了玩家很好的指引，让玩家在游戏中可以得到更好的游戏体验。 ■ 2）实时排行版 还有一个很重要的应用场景就是游戏内的排行榜，比如说王者荣耀里要上星耀、王者，其实都是用排行榜的方式。但我们这个排行榜可能会更具体一些，比如说是今天的战力排行榜，或者今天的对局排行榜，这些都是全局计算的实时排行榜。而且我们有快照的功能，比如 0 点 00 分 的时候有一个快照，就能立马给快照里的玩家发奖励。 这些是实时计算的典型应用案例，一个任务系统一个排行榜，其他的我们后面还会慢慢介绍。 3、游戏对数据的需求 再说一下为什么会有这样一个平台，其实我们最初在做数据运营的时候，是筒仓式或者手工作坊式的开发。当接到一个需求后，我们会做一个资源的评审、数据接入、大数据的编码，编码和数据开发完后，还要做线上资源的申请、发布、验证，再去开发大数据计算完成后的服务接口，然后再开发页面和线上的系统，这些都完了后再发到线上去，做线上监控，最后会有一个资源回收。 其实这种方式在很早期的时候是没有问题的，那为什么说现在不适应了？主要还是流程太长了。我们现在对游戏运营的要求非常高，比如说我们会接入数据挖掘的能力，大数据实时计算完成之后，我们还要把实时的用户画像，离线画像进行综合，接着推荐给他这个人适合哪些任务，然后指引去完成。 这种情况下，原来的做法门槛就比较高了，每一个都要单独去做，而且成本高效率低，在数据的复用性上也比较差，容易出错，而且没有办法沉淀。每一个做完之后代码回收就扔到一块，最多下次做的时候，想起来我有这个代码了可以稍微借鉴一下，但这种借鉴基本上也都是一种手工的方式。 所以我们希望能有一个平台化的方式，从项目的创建、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、效果分析、资源回收、项目结项整个综合成一站式的服务。 其实这块我们是借鉴 DevOps 的思路，就是你的开发和运营应该是一个人就可以独立完成的，有这样一个系统能够去支撑这件事。当一个服务在平台上呈现出来的时候，有可能会复用到计算的数据，比说实时的登录次数或击杀数，那这个指标在后面的服务中就可以共用。 而且有了这样一个平台之后，开发者只需主要关注他的开发逻辑就行了，其余两条运维发布和线上运营都由平台来保证。所以我们希望有一个平台化的方式，把数据计算和接口服务统一起来，通过数据的标准化和数据字典的统一，能够形成上面不同的数据应用，这个是我们的第一个目标。 其实我们现在都是这种方式了，第一是要在 DevOps 的指导思想下去做，尤其是腾讯去做的时候数据服务的量是非常大的，比如我们去年一共做了 5、6 万的营销服务，在这种情况下如果没有平台支撑，没有平台去治理和管理这些服务，单靠人的话成本非常大。 4、思路 3 个现代化，大数据应用的 DevOps。 我们的思路也是这样，三个现代化，而且把大数据应用的 DevOps 思路实现起来。 规范化：流程规范、数据开发规范和开发框架； 自动化：资源分配、发布上线、监控部署（这是 DevOps 里不可缺少的）； 一体化：数据开发、数据接口开发、测试发布、运维监控。 所以我们针对大数据的应用系统，会把它拆成这样三块，一个是大数据的开发，另外一个是数据服务接口的开发，当然接口后面就是一些页面和客户端，这些完了后这些开发还要有一个完整的开发流程支持。 这样我们就能够为各种数据应用场景提供一站式的数据开发及应用解决服务、统一的活动管理、数据指标计算开发管理和各种数据应用接口自动化生产管理的一站式的服务。 这样的系统能保障这些的事情，而且我们这里也合理拆分，不要把大数据和接口混到一块去，一定要做解耦，这是一个非常关键的地方。 5、数据服务平台整体架构 ■ 1）计算存储 这个框架大家可以看一下，我认为可以借鉴，如果你内部要去做一个数据服务平台的话，基本上思路也是这样的，底层的 Iass 可以不用管，直接用腾讯云或者阿里云或者其他云上的服务就可以了。 我们主要是做上层这一块的东西，最下面的计算存储这个部分我们内部在做系统的时候也不是 care 的，这块最好是能承包出去。现在 Iass 发展到这个程度，这些东西在云上可以直接像 MySQL 数据库或者 Redis 数据库一样购买就行了，比如 Kafka、Pulsar、Flink、Storm。 存储这块我们内部的有 TRedis、TSpider，其实就是 Redis 和 MySQL 的升级版本。基础这块我建议大家如果自己构建的话，也不需要太过于关注。 ■ 2）服务调度 系统核心主要是在中间的服务调度这个部分，它是统一的调度 API，就是上层的一些服务能发下来，然后去统一调度。另外一个就是流程的开发，我们有一个不可缺少的调度系统，这里我们使用的是 DAG 调度引擎，这样我们可以把离线任务、实时任务、实时+离线、离线+函数接口的服务能够组合起来，来完成更复杂实时数据应用场景。 比如我们现在做的实时排行榜，把实时计算任务下发到 Flink 后，同时会给 Flink 下发一个 URL，Flink 拿到 URL 后，它会把符合条件的数据都发送到 URL，这个 URL 其实就是函数服务，这些函数服务把数据，在 Redis 里做排序，最终生成一个排行榜。 再往下的这个调度器，你可以不断地去横向拓展，比如我可以做 Storm 的调度器、Flink 的调度器、Spark 的调度器等等一系列。在这块可以形成自己算法库，这个算法库可以根据场景去做，比如有些是 Flink 的 SQL 的分装，也就是把 SQL 传进来，它就能够计算和封装的 Jar 包。另外比如一些简单的数据出发、规则判断也可以去做，直接把算法库分装到这块就行。 其实这块和业务场景没有直接关系的，但算法库一定是和场景是有关系的，另外下层我们会有写文件通道，比如说一些 Jar 包的分发，这里腾讯用的是 COS，能够去做一些数据的传输和 Jar 包的提交。 还有一个命令管道，它主要针对机器，比如提交 Flink 任务的时候一定是通过命令管道，然后在一台机器去把 Jar 包拉下来，然后同时把任务提交到 Flink 集群里去。数据管道也是类似的一个作用。 ■ 3）各种管理 另外还要将一个蛮重要的内容，右边绿色这块的运营监控、集群管理、系统管理（用户权限管理，业务管理，场景管理，菜单配置管理等等），还有消息中心、帮助文档，这些都是配套的，整个系统不可缺少的。 还有一部分是组件管理，包括大数据组件管理、函数管理、服务的二进制管理都可以在这里能够做统一的管理。 数据资产，比如我们通过 Flink 或者 Storm 能够生成的数据指标，它的计算逻辑的管理都在这里面，包括我们计算出来后，把这些指标打上标签或者划后，我们也作为数据资产。 还有一个最重要的是数据表的管理，我们无论是 Flink 或 Storm，它的计算最终的落地点一定是通过一个数据表能算出来的。其他都还好，数据报表，比如每天计算多少数据，成功计算多少，每天有多少任务在跑，新增多少任务，这些都在里面可以做，包括我们版本的发布变更。 还有一个是外部管理端，这个根据业务场景去做就行了，等会演示我们管理端的时候大家就可以看到，其实我们的菜单相对来说比较简单，根据比如我们的数据接入，从源头把数据接入到 Kafka 或者 Pulsar 里去。然后数据指标基于接入的数据表，进行数据指标的计算，比如一些特性的 Jar 包，它是多张表的数据混合计算，或者是加上的表的混合计算，等等一系列通过硬场景做的一些分装。 我们最终把这些做完后，所有的大数据都是通过对外的服务 API 暴露出去的，比如最终游戏任务是否完成，用户 ID 过来后我们能看这个用户的任务是否完成，这样的一些应用场景可以直接使用 API 去操作。 这是整个流程，讲得比较细后面大家才会更清晰。 二、实时大数据计算 OneData 1、数据开发流程 这是我们整体的数据应用流程： 我们的 Game Server 先把数据上传到日志 Server（数据接入部分），日志 Server 再把数据转到 Kafka 或者 Pulsar，就是消息队列里。 接进来后是数据表，数据表是描述，基于描述的表去开发指标、数据。比如我们这里一共有三类，一类是 SQL，另外一类是我们已经分装好的框架，你可以自己去填充它的个性代码，然后就可以在线完成 Flink 程序的编写。 还有一种是自己全新的在本地把代码写好，再发到系统里去调测。之前说了在大数据计算和数据接口一定要做解耦，我们解耦的方式是存储，存储我们用 Redis。它这种做法是把 Redis 和 SSD 盘能够结合起来，然后再加上 RockDB，就是 Redis 里面它 hold 热点数据，同时它把这些数据都通过这个 RockDB 落地到 SSD 盘里去，所以它的读写性非常好，就是把整个磁盘作为数据库存储，而不像普通的 Redis 一样再大数据情况下智能把内存作为存储对象。 在大数据把数据计算存储进去后，后面的就简单了，我们提供查询的服务有两种，一种是计算的指标，点一下就可以生成接口，我们叫规则接口；然后我们另外一种，也提供特性化的存储到介质里，我可以自己去定义他的 SQL 或者查询方式，然后在数据进行加工处理，生成接口 。 还有一种方式，是我们在 Flink 和 Storm 直接把数据配置我们这边的一个函数接口，比如我刚才讲的排行榜的方式，就给一个接口，他直接在 Flink 这边处理完成之后，把数据吐到函数接口里面，函数接口对这个数据进行二次处理。 这个是整个处理方式，所以我们前面讲的就是，基于 Flink 和 Storm 构建一个全面的、托管的、可配置化的大数据处理服务。主要消费的是 Kafka 的数据，Pulsar 现在在少量的使用。 这样做就是我们把数据的开发门槛降低，不需要很多人懂 Flink 或者 Storm，他只要会 SQL 或者一些简单的逻辑函数编写，那就可以去完成大数据的开发。 2、数据计算统一 其实我们之前在做的时候，有一些优化的过程，原来每一个计算任务都是用 Jar 包去写，写完之后就是编辑、打包、开发、发布。后来我们划分了三种场景，一种是 SQL 化，就是一些我们能用 SQL 表示的我们就尽量分装成 SQL，然后有一个 Jar 包能去执行这个提交的 SQL 就可以了。 还有一种是在线的 WebIDE，是处理函数的逻辑，举例子 Storm 里可以把 blot 和 spout 暴露出来，你把这两函数写完后，再把并行度提交就可以运行。但这里我们具体实现的时候是基于 Flink 去做的。 另一个是场景化的配置，我们个性化的 Jar 包能够统一调度，根据调度逻辑去执行。 3、数据计算服务体系 这是我们整个 OneData 计算体系的过程，支持三种，一种的自研的 SQL，一种是 Flink SQL，还有是 Jar 包。 我们自研的 SQL 是怎么存储，最早是使用 Storm，但 StormSQL 的效率非常低，所以我们根据 SQL Parser 做的 SQL 的分装，我们对 SQL 自己进行解析，自己形成函数，在 SQL 提交之后，我们用这样的方式直接把它编译成 Java 的字节码，再把字节码扔到 Storm 里去计算。 Flink 这块我们也继承了这种方式，后面会讲一下两种方式有什么区别。其实我们自研 SQL 在灵活性上比 Flink SQL 要好一点。 这里是做平台化，不能说直接放一个 FlinkSQL 去跑，因为我们想要在里面统计整个业务逻辑的执行情况，比如 SQL 处理的数据量，正确的和错误的，包括一些衰减，都是要做统计。 这是基本的过程，完了后我们在上面形成的一些基本场景，比如实时统计的场景，PV，UV，用独立的 Jar 包去算就行了，配置一下表就可以去计算。另外实时指标的服务，比如杀人书，金币的积累数，游戏的场次，王者荣耀里下路走的次数，这种数据都可以作为实时指标。 还有一种是规则触发服务，表里的某个数据满足什么条件时，触发一个接口。还有通讯实时排行榜和一些定制化的服务。 ■ 1）自研 SQL 接下来说我们自研 SQL 的过程，我们早期为了避免像 Hive 一样（函数栈调用），而我们自己通过 SQL Paser 的语法抽象后，把它生成一段函数，就不需要这么多的对账调用。 这个是函数生成过程，最终生成的就是这样一段代码，它去做计算逻辑，一个函数完成，不需要函数栈的调用，这样效率就会大大提升。我们原来单核跑八万，放在现在可以跑二十多万。 整个处理的时候，我们把 SQL 编译成字节码，Flink 消费了数据后，把数据转化成 SQL 能够执行的函数，就是 roll 的方式。然后把 Roll 整个数据传到 class 里去执行，最后输出。 这种场景适合于，比如 FlinkSQL 它有状态值，我们要统计某个最大值的话，要一直把用户的最大值 hold 到内存里去。而我们自研的 SQL 呢，自己写的函数，它把数据借助第三方存储，比如刚才说的 TRedis 存储。每次只需要读取和写入数据即可，不需要做过多的内存的 hold。 当前做到状态的实时落地，就算挂掉也能立马起来接着去执行，所以超过 10G、100G 的数据计算，都不成问题，但是 FlinkSQL 如果要算的话，它的状态值就一直要 hould 到内存里去了，而且挂掉后只能用它的 check point 去恢复。 所以这是这两种 SQL 的应用场景。 ■ 2）SQL 化 另外 SQL 里我们还可以做些其他的事情。我们的数据是持久化保存在存储里的，那存储里如果是同一张表，同一个纬度，比如我们都是用 QQ，在这个纬度上我们配置了两个指标，那能不能一次算完？只消费一次把数据算完，然后存储一次。 其实这种在大数据计算里是很多的，目前在我们在做的平台化就可以，比如一个是计算登录次数，另一个是计算最高等级，这两个计算逻辑不一样，但是消费的数据表是一样的，然后聚合纬度也是一样的，聚合关键字也是一样。那这个数据就可以进行一次消费，同时把数据计算出来同时去落地，大大减少了存储和计算成本。 我们现在整个游戏里面有一万一千多个指标，就是计算出来的，存储的纬度有两千六百多，实际节省计算和存储约有 60%以上。 两个 SQL，甚至更多的 SQL，我们一张表算十几个指标很正常，原来要消费十几次现在只需要一次就可以算出来。而且这种情况对用户是无感知的。A 用户在这张表上配了指标是 A 纬度，B 用户在这张表上配了指标也是 A 纬度，那这两个用户的数据，我们在底层计算的时候就消费一次计算两次存储一次，最终拿到的数据也是一样的。 ■ 3）在线实时编程 无需搭建本地开发环境； 在线开发测试； 严格的输入输出管理； 标准化输入和输出； 一站式开发测试发布监控。 再介绍下刚才提到的在线实时编程，其实很多时候对开发者来说，搭建一个本地的 Flink 集群做开发调测也是非常麻烦的，所以我们现在就是提供一种测试环境，上层的代码都是固定的，不能修改。比如数据已经消费过来了，进行数据的加工处理，最终往存储里去塞就可以了。 通过这种方式，我们可以对简单逻辑进行分装，需要函数代码，但比 SQL 复杂，比自动的 Jar 包开发要简单一些，可以在线写代码，写完代码直接提交和测试就能完成结果的输出。而且这种的好处是，数据的上报逻辑，数据的统计逻辑，我都在这里面分装好了。只要管业务逻辑的开发就好了。 4、Flink 特性应用 时间特性：基于事件时间水印的监控，减少计算量，提高准确性； 异步化 IO：提高吞吐量，确保顺序性和一致性。 我们最早在 Storm 里做的时候，数据产生的时间和数据进到消息队列的时间，都是通过这种消息里自带的时间戳，每一个消息都是要对比的。有了 Flink 之后，有了 watermark 这个机制之后，这一部分的计算就可以减少了。 实际测试下来的效果也是比较理想的，我们原来在 Storm 里单核计算，大概是以前的 QPS，加上读写和处理性能，单核五个线程的情况下。但是 Flink 的时候我们可以到一万，还加上 Redis 存储 IO 的开销。 另一个我们原来数据想要从 Redis 里取出来，再去算最大值最小值，完了算了再写到 Redis 里，这个都是同步去写的，但是同步 IO 有一个问题就是性能不高。 所以我们现在在把它改成异步 IO，但是异步 IO 也有个特点就是整个一条数据的处理必须是同步的，必须先从 Redis 里把数据取出来，然后再把值计算完，再塞到里面去，保证塞完后再处理下一个统一的数据。 我们再做这样的一些优化。Flink 这里有些特性可以保证我们数据的一致性，而且提升效率。 5、统一大数据开发服务—服务案例 接着介绍下更多的案例，如果大家玩英雄联盟的话，那这个任务系统就是我们设计的，下次玩做这个任务的时候，你就可以想起我。还有天龙八部、CF、王者荣耀 LBS 荣耀战区（通过大数据实时计算+LBS 的数据排行）、王者荣耀的日常活动（实时数据+接口+规则计算）、有哪些好友是实时在线的，跟你匹配的。 三、数据接口服务 OneFun 1、数据应用的出口 下面介绍下函数，我们原来在做的时候也是存在着一些问题，把数据存到存储里面，如果存储直接开放出去，让别人任意去使用的话，其实对存储的压力和管理程度都是很有问题的。所以后来我们采用了一种类似于 Fass 的的解决方式。我们把存储在里面的元数据进行管理，完了之后接口再配置化的方式，你要使用我这个 DB，这个 DB 最大 QPS 多少，我就进行对比，允许你之后才能使用这个量。 比如我这个 DB 的最大 QPS 只有 10 万，你要申请 11 万，那我就给你申请不了，我就只能通知 DB 把这个 Redis 进行扩容，扩容后才给你提供使用。 所以这里面牵扯到我们的指标数据的元数据管理和接口之间的打通。 2、一体化函数执行引擎—OneFun 这个和刚才 OneData 的方式是一样的，比如这块提供了快速的函数，还有一些在线函数编程的方式的接口，你可以在上面写一点 JavaScript 或者 Golang 代码，然后就生成接口，接口里面可以直接对外提供服务，把他形成产品化的包装，在上层根据接口衍生出更多其他的一些应用系统。 3、基于 ssa 的在线 Golang 函数执行引擎 这里重点介绍下 Golang，其实我们是基于 Golang 语言本身 ssa 的特点去做的，我们有一个执行器，这个执行器已经写好的，它的作用就是可以把你写的 Golang 代码提交过来，加载到它的执行器里。 并且我们可以把我们写的代码作为函数库，积累下来然后放进去，它可以在执行的时候去调用这些函数库，而这里面写的代码语法和 Golang 是完全一样的。 同时我们在这里面执行的时候，指定了一个协程，每一个协程我们规定它的作用域，就是以沙箱机制的方式来去执行，最先实现的就是外部 context 去实现的，我们就可以实现 Web 化的 Golang 开发，这种有点像 Lua 那种脚本语言一样，你在线写完语言直接提交执行。 4、基于 V8 引擎的在线函数服务引擎 这是我们的 Javascript 的执行引擎，我们主要是做了 V8 引擎的池子，所有 Javascript 写完之后，丢到 V8 引擎上去执行，这应该大家都能够理解，如果大家玩过 JS 的可以理解这种方式，就是 V8 引擎里直接去执行。 5、一体化函数执行引擎--函数即服务 这是我们的在线函数编写过程： 右下角是我们的函数代码编写区，写完后左边的黑框是点击测试，输出可以在这里写，点击测试就会把结果输出出来，通过这种方式，我们极大地扩张了我们数据平台的开发能力。原来是本地要把 Golang 代码写完，然后调试完再发到线上环境去测试，而现在我们可以很大的规范化，比如说数据源的引入，我们就直接可以在这里去规定了，你只能引入申请过的数据源，你不能随便乱引入数据源，包括你数据源引入的时候，QPS 放大我都可以通过这种方式知道。 降低启动成本； 更快的部署流水线； 更快的开发速度； 系统安全性更高； 适应微服务架构； 自动扩展能力。 这个是我们一站式，把函数开发完后，直接提交，我们用 Prometheus + Grafana 可以里面看到实时报表。 6、案例介绍 这是一个典型的应用，Flink 里面去计算的时候，他对这个数据进行过滤，完了之后进行一个远程的 call，这个远程调用执行函数代码，大多数这种情况就是一个开发就可以完成大数据的开发和这个函数接口的开发，就可以完成这样一个活动的开发，整个活动开发的门槛就低了很多，真正实现了我们 DevOps，就是开发能够把整个流程自己走完。 四、微服务化 & ServiceMesh 1、数据应用必走之路—微服务化 上面讲的是 OneData 和 OneFun 的实现原理和机制，我们在内部是怎么去应用的，这套系统我们在游戏内部是大力推广。 这里尤其是接口这块，其实如果说要微服务化的话，大数据我们能做的也就是那样了，能够用 yarn 或者 K8S 去做资源的管控，和任务的管控，但真正去做服务治理还是在接口这块。目前我们上下接口大概是三千五百个，每周新增 50 个接口。 所以我们在做的时候也考虑到。原来我们服务是一个个开发，但是没有治理，现在我们加上服务还是一个个去开发，甚至有些服务我们会把它变成一个服务，但是我们加入了这个服务的治理。 好多人在提微服务，微服务如果没有一个平台去治理的话，将会是一种灾难。所以微服务化给我们带来便利的同时，也会给我们带来一些问题，所以在我们的场景里面，微服务是非常好的，每一个接口就可以作为一个服务，这种是天然的微服务。 2、一体化服务治理设计 但是这种微服务的治理将会是我们很大的一个问题，所以我们花了很大的精力去做了一个微服务的治理系统，从项目注册的时候，他就把项目注册的微服务中心，并且把 API 注册上来，然后在服务发布的时候，发到集群里的时候，这些服务都要主动的注册到我们的名册服务，就是 Consoul。 但注册到服务里不是作为服务路由来用的，而是到服务里后，我们在普罗米修斯这块去做它的健康检查和状态采集，只要注册上来，我立马就能感知和把状态采集过来，然后主要做实时报表和告警。 首先在服务的稳定性和健康度这块我们有一个保障，另外一个就是服务的信息注册到 Consul 里去后，我们有一个服务的网关，我们用的是 envoy，其实内部我们还把它作为 SideCar 使用，后面会介绍。 注册完了之后，envoy 会把这个所有的负载进信息加载到这块来，它去做它服务的路由，同时我们会把整个日志上报到日志中心去，包括网关的日志也会上传到日志中心去，日志中心再去做离线的报表和实时的一些报警监控， 所以这里面我们还加了一个基于 Consul 的一个配置，就是我们包括 server 的实时控制都可以通过 Consul 去配置，配置完了后立马能够 watch 到，然后去执行。 这个是基本的服务治理，但现在我们的服务治理升级了，比这个要更好一点，基本的原理是这样。 3、南北流量+东西流量的统一管控 并且我们在这里面实现了一个对 envoy 的管控，我们说是服务治理，主要是对流量的一些治理，比如贫富负载策略，路由策略，熔断，超时控制，故障注入等等一系列。 我们是通过 Consul 的配置管理，通过它能够下发到我们的 Agent，这个 Agent 再把这个数据能够通过 Istio 的接口和 K8s 的 API 能够下发到 envoy，这里面就是 API GeteWay 和 SideCar 都是 envoy，所以我们通过 Istio 对他的 XDS 的接口写入，就可以把所有的配置信息下发到这里。 这套系统能够整个去管控整个集群，南北流量和东西流量的统一管控。这套系统我们未来准备开源，现在主要是内部在使用，而且这里面我们也做了图形化的配置，所有 envoy 和 Istio 的配置我们都经过 YAML 转 Istio 再转 UI 的方式，把它图形化了，在这块能够做统一的管控。 而且我们把 Agent 开发完了之后就是多集群的支持，就是多个 K8s 集群只要加入进来，没问题可以去支持，我们管理 API GeteWay。 还有一块是 SideCar 的管理，就是 ServiceMash 里的 SideCar 管理。我们刚才说的函数接口也好，规则接口也好，是一个 server。 当然这里面还提到一个 chaos mesh 的功能，我们现在还在研究，我们准备在这套系统里把它实现了。 4、基于 ServiceMesh 的全链路流量分析 这是一个我们通过 ServiceMesh 做的分析，我们虽然可以宏观地看出来我们接口对 DB 的压力有多大，但实际上我们把流量导进来是我们对压力的监控是不够的，所以这种情况我们通过 ServiceMesh，他对出口流量和进口流量的管控，然后可以把流量进行详细的统计，统计完后可以生成一个快照，这次快照和下次快照之间的数据对比，入流量有多少的时候，对下面各个流量压力有多少。 这是整个展示图，我们有多个测试用例，这两个测试用例之间我们可以算出来对下游的压力的流量分析，后期对下游压力的分析和下游资源的扩容、缩容都有非常大的价值。 5、案例介绍 最后再介绍下我们目前用这套系统实现的一些案例，大数据的游戏回归，比如做一个游戏数据的回顾 （生涯回顾）、任务系统、排行榜。 Q & A Q1：ServiceMesh 是怎么部署的？主要用来解决什么问题？ 目前我们在使用的 ServiceMesh 技术实现是 Istio，版本是 1.3.6。这个版本还不支持物理机方式部署，所以我们是在 K8s 中部署使用，部署方式有 2 种，可以是直接使用 istioctl 命令安装，或者是生成 Yaml 文件后使用 kubectl 进行安装。 Servicemesh 的架构主要解决的问题是集群内东西流量的治理问题。同时 Servicemesh 的 Sidercar 作为协议代理服务和可以屏蔽后面的服务开发技术栈， Sidercar 后面的服务可以是各种语言开发，但是流量的管理和路由可以有统一的管控。 Q2：微服务治理架构能介绍一下吗？ 微服务治理架构在我看来可以分为两类： 服务实例的治理，这个在目前的 K8s 架构下，基本都是由 K8s 来管理了，包含了服务实例的发布，升级，阔所容，服务注册发现等等；服务流量的治理，这一个大家通常说的服务治理，目前主要是由微服务网关和服务网格两种技术来实现。服务网关实现集群内和集群外的流量治理，服务网格实现了集群内的流量治理。 Q3：开发人员主要具有什么样的技术背景？ 针对大数据开发人员，要使用我们这套系统只需要会 SQL 语句和基本统计知识就可以了。 针对应用接口开发人员，要使用我们这套系统只需要会 JavaScript 或者 Golang，会基本的正则表达式，了解 HTTP 协议，会调试 HTTP 的 API 接口就可以了。 Q4：实时计算，Flink 与 Spark 选择上有没啥建议？ Spark 在 15，16 年的时候我们也在大规模使用，也在实时计算中使用过，但是当时的版本在实时计算上还是比较弱，在 500ms 的批处理中还是会出现数据堆积，所以在实时性上会有一定的问题，Spark 擅长在数据迭代计算和算法计算中。但是如果实时性要求不高而且有算法要求的场景中 Spark 还是不错的选择。 Flink 在设计之初就是一种流失处理模型，所以在针对实时性要求较高的场景中 Flink 还是比较合适的，在我们内部测试发现 Flink 的流失计算吞吐确实要比 Storm 好很多，比 Spark 也是好很多，而且 Flink 目前的窗口机制针对实时计算中的窗口计算非常好用。所以一般实时计算或者对实时性要求较高的场景 Flink 还是比较推荐的。 Q5：游戏回放数据服务端存储场景有么？ 这种场景也是有的，游戏回放一般有 2 种方式，一种是录屏传输回放，这种成本非常高，但是简单且及时性比较好，另外一种是控制指令发回 Server，在另外的服务中去恢复当时的场景，这种方式在成本相对较小，但是使用复杂。 Q6：回放场景下客户端走什么协议将数据发送到服务端？ 一般是游戏的私有协议。 更多 Flink 技术交流可扫码加入社区钉钉大群。

网络空间安全学科规划教材点击查看第二章点击查看第三章网络防御与安全对策：原理与实践（原书第3版）Network Defense and Countermeasures: Principles and Practices, Third Edition [美]　查克·伊斯特姆 （Chuck Easttom）　著刘海燕　等译 第1章　 网络安全概述本章目标在阅读完本章并完成练习之后，你将能够完成如下任务： 识别出最常见的网络风险。 理解基本的组网技术。 使用基本的安全术语。 找到适合自己所在机构网络安全的最佳方法。 评估影响网络管理员工作的法律问题。 使用可用于网络安全的资源。 1.1　引言 在新闻中，很难发现哪一周没有发生重大安全破坏。大学网站被攻击、政府计算机被攻击、银行数据受损、健康信息被泄露—这个清单还在不断增长。而且似乎每年对这个问题的关注都在增加。在任何工业化国家中，很难找到没听说过诸如网站被黑客入侵和身份被盗之类事情的人。目前培训场所也有很多。许多大学都提供从学士层次到博士层次的信息保障（Information Assurance）学位。有大量的行业认证培训项目，包括CISSP（Certified Information Systems Security Professional，注册信息系统安全专家）、国际电子商务顾问委员会（EC Council）的CEH（Certificated Ethical Hacker，道德黑客认证）、Mile2Security、SANS（System Administration, Networking, and Security Institute，美国系统网络安全协会）认证以及美国计算机行业协会（Computing Technology Industry Association，CompTIA）的Security+。现在还有一些大学提供网络安全学位，包括远程学习的学位。尽管受到媒体的关注和有获得安全培训的机会，但仍有太多的计算机专业人员，包括数量惊人的网络管理员，对网络系统暴露的威胁类型以及哪些是最有可能发生的威胁没有清晰的认识。主流媒体关注的是最引人注目的计算机安全破坏，而不是给出最有可能的威胁场景的准确画面。本章着眼于网络面临的威胁，定义基本的安全术语，为后续章节涉及的概念奠定基础。确保你的网络完整性和安全性所需的步骤条理清晰，并在很大程度上进行了概括。当你学完本书时，你将能够识别最常见的攻击，解释攻击的机理以便阻止它们，理解如何确保数据传输的安全。 1.2　网络基础 在深入研究如何保护网络安全之前，探索一下什么是网络可能是个不错的想法。对许多读者来说，本节内容仅仅是一次复习，但对于部分读者来说可能是新的知识。无论对你来说是复习还是新的知识，在深入研究网络安全之前，对基本的组网原理有透彻的理解都是至关重要的。此外请注意，这里只是对基本网络概念的简要介绍，没有探究更多细节。网络是计算机进行通信的一种方式。在物理层，网络由所有要连接的机器和用来连接它们的设备组成。独立的机器可通过物理连接（一根5类电缆插入网络接口卡，即NIC）或通过无线方式连接起来。为了将多台机器连接在一起，每台机器必须连接到集线器或交换机，然后这些集线器/交换机再连接在一起。在更大的网络中，每个子网络通过路由器连接到其他子网络。本书中的许多攻击（包括第2章介绍的几种攻击），都是针对网络中将机器连接起来的设备（即路由器、集线器和交换机）发起的。如果你发现本章的知识不够用，那么下述资源可能会有所帮助：http://compnetworking.about.com/od/basicnetworkingconcepts/Networking_Basics_Key_Concepts_in_Computer_Networking.htm 。 1.2.1　基本网络结构 在你的网络和外部世界之间一定存在一个或几个连接点。在网络和Internet之间建立一个屏障，这通常以防火墙的形式出现。本书讨论的许多攻击都要穿越防火墙并进入网络。网络的真正核心就是通信—允许一台机器与另一台机器进行通信。然而，通信的每条通道也是一条攻击的通道。因此，理解如何保护网络的第一步，就是详细了解计算机如何通过网络进行通信。前面提到的网卡、交换机、路由器、集线器以及防火墙都是网络基本的物理部件，它们连接的方式以及通信的格式就是网络体系结构。 1.2.2　数据包 当你与网络建立连接之后（无论是物理连接还是无线连接），就可以发送数据了。第一件事就是确定你想发送到哪里。我们先讨论IPv4的地址，在本章稍后部分再看一下IPv6。所有的计算机（以及路由器）都有一个IP地址，该地址由四个0到255之间的数字组成，中间以圆点分隔，例如192.0.0.5（注意这是一个IPv4地址）。第二件事是格式化要传输的数据。所有数据最终都采用二进制形式（多个1和0组成）。这些二进制数据被放入数据包（packet）中，总长度要小于大约65 000字节。前几个字节是首部（header）。首部内容说明数据包去往哪里、来自何方、本次传输还有多少个包。实际上，数据包有多个首部，但现在我们仅把首部作为单个实体来讨论。我们将研究的一些攻击（例如，IP欺骗）会试图改变首部以提供虚假信息。其他的攻击方法则只试图截获数据包并读取其内容（从而危害数据的安全）。一个数据包可以有多个首部。事实上，大多数数据包至少有三个首部。IP首部包含源IP地址、目标IP地址以及数据包的协议等信息。TCP首部包含端口号等信息。以太网首部则包含源MAC地址和目的MAC地址等信息。如果一个数据包用传输层安全（Transport Layer Security，TLS）进行加密，那么它还将有一个TLS首部。 1.2.3　IP地址 第一个要理解的主要问题是如何将数据包送到正确的目的地。即使是一个小型网络，也存在许多计算机，它们都有可能是发送数据包的最终目的地，而Internet上有数百万台遍布全球的计算机。如何保证数据包到达正确的目的地呢？这个问题就像写封信并确保信件能到达正确的目的地一样。我们从IPv4寻址开始讨论，因为它是目前使用最普遍的，但本节也会简要讨论一下IPv6。一个IPv4地址是用圆点分隔的由4个数字组合的数字序列（例如107.22.98.198）。每个数字必须在0到255之间。可以看到，107.22.98.466就不是一个有效的地址。之所以有这个规则，是因为这些地址实际上是4个二进制数，计算机用十进制格式把它们简单地显示出来。回想一下，1字节是8位（1和0的组合），而8位二进制数转换成十进制格式后将在0到255之间。总共32位则意味着大约存在42亿个可能的IPv4地址。计算机的IP地址可以告诉你该台计算机的很多信息。地址中的第一个字节（或第一个十进制数）告诉你该机器属于哪一类网络。表1-1概括了5种网络类别。 这5种网络类别在本书后面将变得更加重要（或者，现在你应该决定在更深的层次上学习网络）。仔细观察表1-1，你可能会发现127的IP范围没有被列出来，之所以存在这种省略，是因为该范围是被保留用于测试的。不管你的机器被指定为什么IP地址，地址127.0.0.1都是指你自己正在使用的这台机器。这个地址常被称为环回地址（loopback address），常用于测试你的计算机和网卡。我们将在本章稍后的网络实用程序部分讨论它的用法。这些特定的地址分类很重要，因为它告诉你，地址的哪些部分代表网络、哪些部分代表节点。例如，在A类地址中，第一个8位的字节代表网络，其余三个表示节点。在B类地址中，前两个8位的字节代表网络，后两个表示节点。而在C类地址中，前三个8位的字节代表网络，最后一个代表节点。你还需要注意一些特殊的IP地址和IP地址范围。第一个是如前所述的127.0.0.1，即环回地址。它是引用你正在使用的机器网卡的另一种方法。另一个需要注意的问题是私有（private）IP地址。IP地址中某些特定范围被指定仅用于网络内部。这些地址不能用作公开的IP地址，但可以用作内部工作站或服务器的地址。这些IP地址包括： 10.0.0.10到10.255.255.255 172.16.0.0到172.31.255.255 192.168.0.0到192.168.255.255 网络新人有时对公有IP地址和私有IP地址的理解有些困难。我们以办公楼做个类比：在一栋办公楼内，每个办公室的编号必须是唯一的。例如，在一栋大楼里只能有一个305办公室。如果讨论305办公室，你马上就明白说的是哪个房间。但还有其他的办公楼，许多楼都有自己的305办公室。因此，你可以将私有IP地址视为办公室编号，在它们所在的网络中它们的编号必须是唯一的，但在其他网络中可能有相同的私有IP。公有IP地址更像传统的邮件地址，它们在世界范围内必须是独一无二的。当从办公室到办公室通信时，你可以使用办公室号码，但是要给另一个建筑物发信，你必须使用完整的邮件地址。这与网络是一样的，你可以使用私有IP地址在网络内部进行通信，但要与网络外部的任何计算机进行通信时，都必须使用公有IP地址。网关路由器的作用之一是执行所谓的网络地址转换（Network Address Translation，NAT）。通过NAT，路由器将发出的数据包中的私有IP地址替换为网关路由器的公有IP地址，从而可以在Internet中路由该数据包。我们已经讨论了IPv4网络地址，现在把注意力转移到划分子网上。如果你已经熟悉这个主题，那么请跳过本节。由于某种原因，这个话题往往会给学生带来很大麻烦。所以下面我们从理解概念开始。所谓划分子网（subnetting）就是简单地将网络切成更小的部分。例如，如果你拥有一个使用IP地址192.168.1.X的网络（X代表任何具体计算机的地址），那么你已经被分配了255个可能的IP地址。如果想把它分成两个单独的子网络怎么办呢？你需要做的就是划分子网。说得更专业一点，子网掩码（subnet mask）是分配给每个主机的一个32位数字，用于将32位二进制的IP地址划分为网络部分和节点部分。子网掩码不能随意指定，有特定的要求。子网掩码的第一个值必须是255，剩下的三个值可以是255、254、252、248、240、224或128。你的计算机把自己的IP地址和子网掩码通过二进制“AND”操作（二进制的“按位与”）结合起来。你可能会很奇怪，因为即使你没有划分过子网，也已经拥有了一个子网掩码。这是默认子网掩码。如果你有一个C类IP地址，那么子网掩码是255.255.255.0。如果有一个B类IP地址，那么子网掩码是255.255.0.0。而如果是A类地址，则子网掩码是255.0.0.0。现在考虑一下这些数字与二进制数的关系。十进制255转化为二进制是11111111。所以，默认情况下，你实际上仅掩住（masking）了地址中用于定义网络的那部分，而其余部分都用于定义单个节点。现在如果你想使子网中的节点数少于255，那么你需要一个类似于255.255.255.240这样的子网掩码。将240转换为二进制是11110000，这表示前三个字节以及最后一个字节的前4位定义了网络，而最后字节的后4位定义了节点。这就意味着在这个子网络上最多可以有1111（二进制）个或15（十进制）个节点。这就是划分子网的本质。划分子网这种方式，仅允许你使用某些受限的子网。另一种方式是CIDR，即无分类域间路由（Classless Inter Domain Routing，CIDR）。CIDR不是定义子网掩码，而是使用IP地址后面跟随一个斜线（/）和一个数字的方式。该数字可以是0到32之间的任何数字，这时的IP地址格式如下：192.168.1.10/24（一个基本的C类IP地址）192.168.1.10/31（一个C类 IP地址，附带子网掩码）当你使用这种方式而不是使用子网时，你有可变长子网掩码（Variable-Length Subnet Masking，VLSM），它能提供无类别区分的IP地址。这是当今定义IP地址最常用的方式。你不用担心新的IP地址是否很快就会用尽。IPv6标准已经投入使用，并且已经有了扩展使用IPv4地址的方法。IP地址分为两类：公共和私有。公有IP地址用于连接到Internet的计算机。公有IP地址必须互不相同。而私有IP地址，例如公司私有网络上的IP地址，只需在该网络中是唯一的即可。不用理会世界上是否有其他的计算机也有相同的IP地址，因为这台计算机从来不会连接到那些其他的计算机。网络管理员通常使用以10开始的私有IP地址，如10.102.230.17。其他的私有IP地址有172.16.0.0至172.31.255.255和192.168.0.0至192.168.255.255。此外还要注意，Internet服务提供商（Internet Service Provider，ISP）经常会购买一个公有IP地址池（pool），并在你登录时将它们分配给你。因此，ISP可能有1000个公有IP地址，但拥有10 000个客户。因为10 000个客户不会同时在线，ISP在客户登录时将IP地址分配给他，而在客户注销时回收IP地址。IPv6使用128位地址（而不是32位），并使用十六进制编号的方法，以避免像132.64.34.26.64.156.143.57.1.3.7.44.122.111.201.5这种长地址。十六进制地址格式类似于3FFE:B00:800:2::C的形式。这给了你2128个可用的地址（数万亿个地址），因此在可以预见的未来，不可能会耗尽IP地址。IPv6中不再划分子网。相反，它只使用CIDR。地址中的网络部分由斜线后面跟随的数字指定，这个数字表示地址中分配给网络部分的位（bit，也称为比特）数，如“/48”“/64”等。IPv6中有一个环回地址，可以写成::/128。IPv4和IPv6之间的其他区别描述如下：本地链路/机器地址。 这是IPv4自动专用IP寻址（Automatic Private IP Addressing，APIPA）的IPv6版本。如果机器配置为使用动态分配地址，但不能与DHCP服务器通信，那么它为自己分配一个通用的IP地址。其中，动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）用于动态地为网络内的主机分配IP地址。 IPv6的本地链路/机器的IP地址都以FE80::开始。因此，如果你的计算机使用这样的地址，那么意味着它不能到达DHCP服务器，故而构造了自己的通用IP地址。 本地站点/网络地址。 这是IPv4私有地址的IPv6版本。换句话说，它们是真实的IP地址，但只能在本地网络上工作，在Internet上是不能路由的。 所有的本地站点/网络的IP地址都以FE开头，并且第三个十六进制数字是C到F之间的数字，即FEC、FED、FEE或FEF。 DHCPv6使用托管地址配置标志（managed address configuration flag），即M标志。 当该标志为1时，表示设备应该使用DHCPv6获得一个有状态（stateful）的IPv6地址。 其他状态配置标志（O标志）。 当该标志设置为1时，表示设备应该使用DHCPv6来获得其他的TCP/IP配置。换句话说，它应该使用DHCP服务器来设置诸如网关及DNS服务器的IP地址之类的信息。 1.2.4　统一资源定位符 对于大多数人来说，上网的主要目的是浏览网页（但也有其他目的，比如收发电子邮件和下载文件）。如果你必须记住IP地址并输入这些地址，那么网上冲浪将是件非常麻烦的事。幸运的是，你不必这么做，你只需键入对人类而言有意义的域名，而域名被翻译成IP地址。例如，你可以输入www.chuckeasttom.com 来访问我的网站。你的计算机或ISP将你输入的名称，即统一资源定位符（Uniform Resource Locator，URL），转换为IP地址。DNS（Domain Name Service，域名服务）协议处理该转换过程，DNS协议稍后将在表1-2中与其他的协议一起介绍。因此，你输入一个对人类而言有意义的名称，但你的计算机使用相应的IP地址进行连接。如果找到该地址，浏览器将发送一个数据包（使用HTTP协议）到它的TCP 80端口。如果目标计算机有软件监听并响应这个请求，如Apache或微软的IIS（Internet Information Services，Internet信息服务）之类的Web服务器软件，那么目标计算机将响应浏览器的请求并与之建立通信。这就是查看网页的方法。如果你收到错误提示“Error 404: File Not Found”，那是因为浏览器收到了一个从Web服务器返回的包含错误代码404的数据包，表示它找不到你所请求的网页。Web服务器可以向Web浏览器发送一系列错误消息，指示不同的出错情况。电子邮件的工作方式与访问网站的方式相同。你的邮件客户端查找邮件服务器的地址，然后使用POP3（Post Office Protocol version 3，邮局协议版本3）协议检索入站的电子邮件，或使用SMTP（Simple Mail Transport Protocol，简单邮件传输协议）协议向外发送电子邮件。邮件服务器（可能位于你的ISP或你的公司里）将尝试解析发送地址。例如，如果发送一封邮件到chuckeasttom@yahoo.com，你的邮件服务器首先把邮件地址转换为yahoo.com的邮件服务器的IP地址，然后再将邮件发送给那里。请注意，尽管已经有了更新的邮件协议，但POP3仍然是最常用的协议。因特网消息访问协议IMAP（Internet Message Access Protocol，IMAP）现在用得也很广泛，它使用143端口。与POP3相比，IMAP的主要优点是它允许客户端仅把邮件首部下载到本地机器上，然后可以选择要完整下载哪些消息，这个功能对智能手机来说特别有用。 1.2.5　MAC地址 MAC地址（Media Access Control address，媒体访问控制地址）是一个很有趣的话题。注意，MAC也是指OSI模型的数据链路层的子层。MAC地址是网卡的唯一地址。世界上的每块网卡都有一个唯一的地址，用6字节的十六进制数表示。地址解析协议（Address Resolution Protocol，ARP）用于将IP地址转换为MAC地址。因此，当你输入网站地址时，DNS协议将其转换为IP地址，然后ARP协议将IP地址转换为单个网卡特定的MAC地址。 1.2.6　协议 不同的目的需要不同类型的通信。不同类型的网络通信称为协议（protocol）。协议本质上是一种约定的交流方法。事实上，该定义恰是protocol这个词在标准的、非计算机使用中的用法。每个协议都有特定的目的，并且通常在某个端口上运行（有的需要多个端口）。表1-2列出了一些重要的协议。 你可能已经注意到，这个列表并不完整，还有数百个其他的协议，但对本书来说讨论这些就足够了。所有这些协议都是TCP/IP协议族的一部分。你要明白的最重要的一点是，网络上的通信是通过数据包（packet）实现的，而这些数据包要根据当前的通信类型按照某些协议进行传送。你可能想知道什么是端口（port）。不要将这种类型的端口与计算机背后的连接接口，如串口或并口相混淆。网络术语中的端口是一个句柄、一个连接点，是一个指派给特定通信路径的数字。所有网络通信，不管使用什么端口，都通过网卡连接进入你的计算机。可以把端口看作电视的一个频道，可能只有一个电缆进入电视，但却可以观看许多频道。所以，类比一下只有一个电缆进入计算机，但可以在许多不同的端口上进行通信。至此，我们形成了关于网络的概貌：网络是由机器通过电缆互连而成的，有的机器可能接入集线器、交换机或路由器，网络使用某些协议和端口在数据包中传输二进制信息。这是对网络通信的一个很精确的刻画，尽管非常简单。 1.3　基本的网络实用程序 在IP地址和URL之后，还需要熟悉一些基本的网络实用程序。你可以在命令提示符下（Windows系统）或shell中（UNIX/Linux系统）执行一些网络实用程序。许多读者已经熟悉了Windows，因此本书将集中讨论如何在Windows命令提示符下执行命令。但必须强调的是，这些实用工具在所有操作系统中都可用。本节介绍几个基本的或常用的实用程序。 1.3.1　ipconfig 你想要做的第一件事是获取关于自己系统的信息。要完成这个任务，必须首先获得命令提示符。在Windows中，可以通过[开始/所有程序/附件]操作获得命令提示符；也可以通过[启动/运行]并输入“cmd”来获得命令提示符。在Windows 10中，可以在“搜索”框中输入“cmd”来获得命令提示符。在命令提示符下，输入ipconfig。在UNIX或Linux的shell中，也可以输入ifconfig来使用该命令。输入ipconfig（Linux中输入ifconfig）后，应该会看到类似于图1-1所示的内容。 该命令提供有关网络连接的一些信息，其中最重要的是找出自己的IP地址。该命令还显示默认网关的IP地址，它是你与外部世界的连接点。运行ipconfig命令是确定系统网络配置的第一步。本书提到的大多数命令（包括ipconfig）都有许多参数或标志，它们传递给命令从而使计算机以某种方式工作。要想弄清这些命令，你可以输入命令后跟一个空格，然后再输入连字符及问号“-？”即可。如你所见，你可以使用多个选项来找出关于计算机配置的不同细节。最常用的方法可能是使用ipconfig /all，如图1-2所示。可以看到，使用这个选项显示了更多信息。例如，ipconfig /all可以显示计算机的名称、计算机什么时间获得IP地址等。 1.3.2　ping 另一个常用的命令是ping。ping命令向一台机器发送测试数据包，或者叫作回声（echo）数据包，以查看该机器是否可到达，以及数据包到达该机器需要多长时间。图1-3展示了该命令。图中信息显示，一个32字节的回声数据包被发送到目的地并返回。其中的“TTL”表示“生存时间”（Time To Live，TTL），它的时间单位是数据包在放弃传送之前到达目的地最多经过多少中间步骤，或者是多少跳（hop）。由于Internet是一个庞大的相互连接的网络，你的数据包可能不会直接送达目的地，而是要经过数跳才能到达。与ipconfig一样，你可以输入“ping -?”来找到各种细化ping命令的方法。 1.3.3　tracert 下一个要研究的命令是tracert。这个命令有点像豪华版的ping。tracert不仅告诉你数据包是否到达目的地以及它花了多长时间，而且还告诉你所有的中间跳。同样的命令在Linux或UNIX中也存在，但它叫traceroute而不是tracert。图1-4展示了这个实用程序。使用tracert命令可以列出每个中间步骤的IP地址，以及到达该步骤所花费的时间（以毫秒为单位）。知道到达目的地所需的步骤是很重要的。如果你使用Linux，那么请使用traceroute命令而不是tracert。 1.3.4　netstat netstat是另一个很有趣的命令。它是Network Status（网络状态）的缩写。基本上，这个命令会告诉你当前计算机有什么连接。如果你看到有好几个连接，不要惊慌，因为这并不意味着你的电脑被黑客攻击。你会看到有许多私有IP地址，这表示你的网络有正在进行的内部通信。在图1-5中可以看到这一点。 当然，在使用网络通信时还有其他的实用程序也可能对你有所帮助，但上面介绍的这四个是核心的实用程序。它们（ipconfig、ping、tracert和netstat）对每个网络管理员来说绝对是必不可少的，你应该牢牢记住它们。 1.4　OSI模型 开放系统互连（Open Systems Interconnect，OSI）模型描述了网络如何通信，参见表1-3。它描述了各种协议和活动，并说明协议和活动是如何相互关联的。OSI模型分为七层，它最初是由国际标准化组织（International Organization for Standardization，ISO）在20世纪80年代开发的。 许多学习网络的学生都会记住这个模型。至少，记住七层的名字并基本理解每一层的作用。从安全的角度看，你对网络通信理解得越多，你的安全防御等级就越高。对于OSI模型，你要理解的最重要的事情是，此模型描述了一个通信的分层结构，其中每一层仅与直接在其上方或下方的层进行交流。 1.5　对安全意味着什么 本书从多个角度介绍安全，但本质上只存在三种攻击聚集点，因而也只有三种安全聚集点（注意，这里不是指攻击途径，因为存在很多攻击途径）： 数据本身：数据离开你的网络之后，数据包很容易被侦听甚至被篡改。在本书后面讨论加密和虚拟专用网时，你将学习如何保护这些数据。当数据在计算机上存储时，它也可能在静止情况下被攻击。 网络连接点：无论是路由器还是防火墙，一台计算机连接到另一台计算机之间的任何位置都是可能被攻击的位置，因此也是必须防御的位置。在考察系统的安全性时，应该首先考察连接点。 人员：人员经常会带来安全隐患。由于无知或恶意目的，或者由于简单的错误，系统上的人员都可能危及系统的安全。 当你对本书进一步学习时，不要忽视了我们的基本目标，那就是保护网络以及存储和传输数据的安全。 1.6　评估针对网络的可能威胁 在探索计算机安全话题之前，你必须首先对系统面临的威胁形成现实的评估。其中的关键词是“现实的”（realistic）。显然，人们可以想象出某个非常精细、技术高超的潜在危险。然而，作为一名网络安全专业人员，你必须将精力以及资源集中到最可能的危险上。在深入研究具体的危险之前，我们首先了解你的系统上可能面临什么类型的攻击。在这方面，针对计算机安全似乎有两种极端的态度。第一个观点认为，计算机系统几乎没有真正的危险或威胁，许多负面新闻仅仅是一种无根据的恐慌的反映。持这种态度的人通常认为，只要采取很少的安全措施就应该能确保其系统的安全。不幸的是，一些处于决策位置的人持有这种观点。这些人的普遍观点是：“如果我们的计算机/机构迄今为止没有受到攻击，那么我们一定是安全的。”这种观点常常导致被动地对待计算机安全，也就是说，人们等到事件发生后才决定解决安全问题。等到攻击发生时才解决安全问题可能为时已晚。在最好的情况下，这种安全事件可能仅对机构造成轻微的影响，比如一个紧急唤醒电话。在不太幸运的情况下，一个机构可能面临严重的或许灾难性的后果。例如，一些机构在WannaCry病毒攻击它们的系统时，没有有效的网络安全系统抵御攻击。事实上，如果系统已经打补丁，那么WannaCry攻击可以完全避免。必须避免这种对安全放任自流的方法。任何拥有这种极端并且错误观点的机构都可能在计算机安全方面几乎不投入时间和资源。他们或许有一个基本的防火墙和防病毒软件，但很可能几乎没有花费精力来确保这些东西被正确地配置或进行定期的更新。第二种观点认为，技术精湛的黑客可以随意穿越你的系统，并让你的网络瘫痪。把黑客技能想象成军事经验。找一个曾经在军队中的人并不难，但不容易碰到一个在三角洲部队或海豹6队的人。虽然军事经验相当普遍，但高水平的特种作战技能却并不常见。黑客技能也是如此。找到了解一些黑客技巧的人很容易，但找到真正熟练的黑客远没有那么轻松。实践中：现实世界中的安全每当我受邀完成一些咨询或培训任务时，都会看到许多不同的网络环境。从这些经历中，我逐渐得出这样的观点，即绝大部分机构对计算机安全都采取了非常不严谨的方法。下面是我认为的对安全采取不严谨行为的例子： 公司没有任何类型的入侵检测系统（第5章介绍） 公司没有足够的防病毒/防间谍软件（第10章介绍） 公司的备份介质不安全（第11章介绍） 公司没有打补丁的规划（第8章介绍） 这些仅仅是机构没有以适当方式处理网络安全的几个例子。在网络安全观点的另一端，一些管理人员高估了安全威胁。他们认为，存在大量非常有天赋的黑客，这些黑客都是系统迫在眉睫的威胁。事实上，许多自称黑客的人比他们自认为的懂得要少。即使是中等强度安全防范的系统，被这种技能级别的黑客所破坏的可能性也很低。这并不意味着不存在高水平的黑客。这样的人当然存在。但是，有能力攻入相对安全系统的人，必须使用相当耗时和烦琐的技术来突破系统的安全防线。这些黑客还必须权衡攻击任务的代价和收益。熟练的黑客倾向于无论在经济上还是在意识形态上都有高收益的目标系统。如果一个系统看起来没有足够的收益，熟练的黑客不太可能会花费资源来攻击它。以窃贼作一个很好的类比：高技能的窃贼确实存在，但他们通常寻求高价值目标，以小型企业和家庭为目标的窃贼通常技能都有限。对黑客而言也是如此。供参考：技能型黑客与非技能型黑客技能型黑客通常只瞄准非常具有吸引力的站点。这些站点提供有价值的信息或宣传效果。军用计算机—即使是没有机密信息的非常简单的Web服务器—也能提供很强的宣传效果。另一方面，银行通常拥有非常有价值的信息。新手黑客通常从一个低价值的、本身不太安全的系统开始。低价值系统可能没有任何有重大价值的数据或不能提供好的宣传效果，大学的Web服务器就是一个很好的例子。虽然新手黑客的技能不如老手，但数量更多。此外，金钱方面的收益并不是系统对黑客高手具有吸引力的唯一因素。如果黑客反对一个机构的意识形态立场（例如，如果一个机构出售大型运动型多用途车，而黑客认为这是糟糕的环境政策），那么他可能会把该机构的系统作为攻击目标。对计算机系统危害的这两种极端态度都是不准确的。确实存在有的人既理解计算机系统，又拥有攻击很多系统（即使不是大多数系统）安全性的技能。然而，也确实许多自称黑客的人并不像他们声称地具有那么娴熟的技能。他们从Internet上得知一些流行词，并确信自己拥有超强数字能力，但却不能对即使中等安全程度的系统进行任何攻击。你可能会认为，慎之又慎或者极度勤勉应该是合适的方法。实际上，你不需要采取极端的观点。你应该采取现实的安全观点，制定切实可行的防御策略。每个机构和IT部门都仅有有限的资源：你只有这么多的时间和金钱。如果浪费部分资源来防止不现实的威胁，那么你可能没有足够的资源用于更实际的项目。因此，对网络安全采取现实的方式是唯一切实可行的方法。你或许奇怪，为什么有些人会高估他们网络的危险。至少在部分程度上，答案可以归结于黑客社区的本质和媒体的宣传。此外，Internet上充斥着声称拥有高超黑客技能的人。实际上，像人类工作的任何领域一样，绝大多数人仅是平均水平。真正有天赋的黑客并不比真正有天赋的音乐会钢琴家更常见。想想有多少人在他们一生中的某个阶段都学过钢琴课程，可又有多少人真正成为艺术家。对计算机黑客而言也是如此。请记住，即使是那些拥有必备技能的人，也需要具有动机去花费必要的时间和精力来破坏系统。当遇到任何声称拥有网络神力的人，不要忘记上述事实。许多自称黑客的人缺乏真实技能的说法并非基于任何研究或调查。关于这个话题进行可靠的研究是不可能的，因为黑客不太可能现身并参加技能测试。我基于以下两点考虑得出了上述结论： 第一点是依据这些年我在黑客讨论组、聊天室和公告板浏览的经验。在该领域20多年的工作中，我遇到过有天赋的、技术精湛的黑客，但我遇到更多的是自称黑客但明显缺乏足够技能的人。我也常在黑客大会上演讲，包括DEFCON大会，并在黑客杂志如《2600》上发表文章。我有机会与黑客社区进行广泛的互动。 第二点是依据关于人性的一个事实，即在任何领域绝大多数人都是中等水平。想一想有那么多在健身房接受正规训练的人，成为有竞争力的健美运动员的人却凤毛麟角。在任何领域，大多数参与者都是中等水平。这并不是贬损的话，只不过是生活的一个事实。 这一说法并不意味着轻视黑客攻击的危险，那根本不是我的本意。在没有适当安全防范措施的情况下，即使一个不熟练的新手黑客也能侵入系统。即使准黑客没有成功地攻破安全措施，他仍然相当令人讨厌。此外，某些形式的攻击根本不需要太多技能。本书后面将讨论这些内容。一种更全面的观点（因此，是评估任何系统威胁等级的较好方法）是，在系统对潜在入侵者的吸引程度和系统已采取的安全措施之间进行权衡。正如你将看到的，任何系统的最大威胁并不是黑客，病毒及其他攻击要盛行得多。威胁评估是一项复杂的、需要考虑多方面因素的任务。 1.7　威胁分类 你的网络肯定面临着真实的安全威胁，这些威胁可以以多种形式表现出来。有多种方式可用来对系统的威胁进行分类。可以按照造成的损害、执行攻击所需的技能水平或者攻击背后的动机等进行分类。根据本书的目标，我们按照威胁实际做的事情对其进行分类。基于这个思路，绝大多数攻击都可以归结为如下三大类型之一： 入侵 阻塞 恶意软件 图1-6展示了这三种类型。入侵类型包括那些破坏安全措施并获得系统非授权访问的攻击。该类攻击包括任何旨在获得对系统非授权访问的尝试。这种威胁通常是黑客做的事情。第二类攻击是阻塞，包括那些旨在阻止对系统进行合法访问的攻击。阻塞攻击通常称为拒绝服务攻击（Denial of Service，DoS）。在这种类型的攻击中，攻击的目的不是实际进入你的系统，而是简单地阻止合法用户的访问。 供参考：还有什么其他攻击？第2章介绍的诸如缓冲区溢出（buffer overflow）等攻击可归结为多个威胁类型。例如，缓冲区溢出可用来关闭机器，从而成为阻塞型攻击，也可以用来突破系统的安全措施，因而成为入侵型攻击。但是，攻击一旦实现后，它将确定归属于二者中的某一个类型。第三类威胁是在系统上安装恶意软件（malware）。恶意软件是对具有恶意目的的软件的一个通用术语，它包括病毒攻击、特洛伊木马和间谍软件。由于这类攻击可能是对系统最普遍的威胁，因此我们首先来介绍它。 1.7.1　恶意软件 恶意软件可能是任何系统中最常见的威胁，包括家庭用户系统、小型网络以及大型企业的广域网。之所以如此常见，原因之一是恶意软件通常被设计成自行传播，而不需要恶意软件的创造者直接参与。这使得该种类型的攻击更容易在Internet上传播，因此攻击范围更广。恶意软件中最显而易见的例子就是计算机病毒。你可能对病毒有大概的了解。如果查阅不同的教科书，你可能会发现病毒的定义略有不同。其中的一个定义为：“通过修改其他程序，在其中加入自己可能进化了的副本，来感染其他程序的程序。”这是一个很好的定义，也是本书通篇所使用的定义。计算机病毒类似于生物病毒，既可以复制又可以传播。最常见的传播病毒的方法是使用受害者的电子邮件账号，将病毒传播到他的通讯录中的每个人。有些病毒并不实际危害系统本身，但由于病毒复制引起网络负载加大，因此它们都会造成网络减速或关闭。实践中：真实的病毒第2章和第9章将详细讨论最初的MyDoom蠕虫。MyDoom.BB病毒是2005年初开始传播的MyDoom的一个变种。这种蠕虫以java.exe或services.exe的形式出现在硬盘上。这一点对了解病毒很重要。许多病毒试图以合法的系统文件的面目出现，以防止你删除它们。自那时起，已经出现了很多种病毒，包括著名的Stuxnet（震网）、Flame（火焰）、WannaCry（永恒之蓝）等。这种特殊的蠕虫把自己发送到你的地址簿中的每个人，因此传播非常快。该蠕虫试图下载一个后门程序，从而让攻击者访问你的系统。从技术的角度来看，该蠕虫最有趣的是它如何提取电子邮件地址。该蠕虫使用了一种改进的电子邮件地址识别算法，它可以捕捉到如下电子邮件地址： chuck@nospam.domain.com chuck-at-domain-dot-com 这些地址被蠕虫转换为可用的格式。许多其他的电子邮件提取引擎都被这类电子邮件地址替换所困扰。另一种与病毒密切相关的恶意软件类型是特洛伊木马。这个术语是从古代传说中借用的。在传说中，特洛伊（Troy）城被围困了很长时间，攻击者久攻不下。他们建造了一个巨大的木马（wooden horse），有天晚上将它放在特洛伊城的城门前。第二天早晨，特洛伊城的居民看到了木马，认为这是一件礼物，于是就把木马拉进了城内。他们不知道的是，有几名士兵藏在木马里面。那天晚上，这些士兵们从木马里出来，打开了城门，让他们的同伴攻进城内。一个电子形式的木马以同样的方式工作，它们看起来是良性软件，但却在内部将病毒或其他类型的恶意软件秘密地下载到你的计算机上。简单地说，有一个诱人的礼物，你将它安装在你的电脑上，后来发现它释放了一些非你预期的东西。事实上，在非法软件中更容易发现特洛伊木马。Internet上有很多地方可以获得盗版软件。发现这样的软件实际上是特洛伊木马的一部分并不罕见。特洛伊木马和病毒是两种最常见的恶意软件形式。第三种类恶意软件是间谍软件，它正以惊人的速度增长。间谍软件是一种窥探你在电脑上所作所为的软件。它可以像cookie一样简单，cookie是一个由浏览器创建的并且存储在你硬盘上的文本文件。cookie从你访问的网站下载到你的机器上，当你在之后返回到同一网站时，网站可用它识别出你。这个文件能够让你访问页面更快速，避免频繁访问页面时必须多次输入你的信息。而为了做到这一点，就必须允许网站读取该文件，这就意味着其他网站也可以读取它。该文件保存的任何数据都可以被任何网站检索，所以，你浏览Internet的整个历史都可以被跟踪。另一种形式的间谍软件称为键盘记录器（key logger），它能记录你所有的击键。有的还能周期性地拷贝你的电脑屏幕。然后，这些数据要么被存储起来供记录器的安装者随后进行检索；要么通过电子邮件立即发回给安装者。在任何一种情况下，你在电脑上做的每件事都被记录下来给了感兴趣的人。供参考：键盘记录器尽管我们将键盘记录器定义为一个软件，但需要注意的是，确实存在基于硬件的键盘记录器。基于硬件的键盘记录器比基于软件的键盘记录器要罕见得多。因为软件键盘记录器更容易安装在目标机器上。硬件键盘记录器要求物理接触机器并安装硬件。如果要在计算机用户没有察觉的情况下安装键盘记录器，那么安装物理设备可能相当困难。软件键盘记录器可以通过特洛伊木马进行安装，攻击者与目标计算机甚至不需要在相同的城市。 1.7.2　威胁系统安全—入侵 有人可能会辩解称，任何类型的攻击都旨在破坏安全性。然而，这里的入侵是指那些实际上试图侵入系统的攻击。它们不同于简单地拒绝用户访问系统的攻击（阻塞），或者那些不聚焦于特定目标的攻击，如病毒和蠕虫（恶意软件）。入侵攻击的目的是获得特定目标系统的访问权，通常被称为黑客攻击，尽管这不是黑客自己使用的术语。黑客把这种攻击称为骇客攻击（cracking），表示未经许可侵入系统，并且通常怀有恶意目的。通过某种操作系统缺陷或任何其他手段破坏安全性的攻击都可以归结为骇客攻击。本书的后续内容会介绍一些侵入系统的具体方法。在许多情况下，这类攻击都是利用一些软件缺陷来获得对目标系统的访问。利用安全缺陷并不是侵入系统的唯一方法。事实上，有些方法在技术上更容易实现。例如，社会工程（social engineering）就是一种完全不以技术为基础的破坏系统安全性的方法。顾名思义，社会工程更多依赖于人类本性而不是技术。这是著名的黑客Kevin Mitnick最常用的攻击类型。社会工程使用标准的骗子技巧，使用户提供访问目标系统所需的信息。这种方法的工作原理相当简单。攻击者首先获得关于目标机构的初步信息，比如系统管理员的姓名，然后利用它从系统用户那里获得更多信息。例如，他可能给会计部门的某个人打电话，声称自己是公司的技术支持人员。入侵者可以使用系统管理员的姓名来证实自己说的是实话。之后他可以询问各种问题来了解系统的更多细节。精明的入侵者甚至可以获知用户名和口令。正如你所见，这种方法基于入侵者如何操纵人，而实际上与计算机技能没有什么关系。社会工程和利用软件缺陷并不是进行入侵攻击的唯一手段。无线网络的日益普及引发了新的攻击类型。最明显和最危险的活动是战争驾驶（war-driving）。这种类型的攻击是战争拨号（war-dialing）的衍生物。在战争拨号中，黑客用一台计算机按顺序拨打电话号码，直到另一台计算机响应，然后他尝试进入对方系统。战争驾驶使用了相同的概念，用于定位脆弱的无线网络。在该类攻击中，黑客简单地驾车漫游，试图定位无线网络。许多人忘记了，他们的无线网络信号通常可达100英尺（约30.48米）远，因此可以穿越墙壁。在年度黑客大会DEFCON 2003上，参赛者参加了一场战争驾驶比赛，他们在城市里四处驾驶，试图找到尽可能多的脆弱的无线网络。 1.7.3　拒绝服务 第三类攻击是阻塞（blocking）攻击，其中的一个例子是拒绝服务（Denial of Service，DoS）攻击。在这种攻击中，攻击者并不实际访问系统，而是简单地阻止合法用户访问系统。用计算机应急响应小组协调中心（Computer Emergency Response Team/ Coordination Center，CERT/CC）的话说，“拒绝服务攻击的特点是，攻击者明确地试图阻止服务的合法用户使用该服务。”这里所说的CERT是世界上第一个计算机安全事件响应小组。一种常用的阻塞攻击方法是向目标系统注入大量虚假的连接请求，使得目标系统无暇响应合法请求。DoS是一种非常常见的攻击，仅次于恶意软件。 1.8　可能的攻击 上面我们研究了各种可能的网络威胁。显然，有些威胁比其他威胁更容易发生。那么，个人和机构面临的现实危险是什么？什么是最有可能的攻击？常见的漏洞有哪些？理解现有威胁的基本原理以及它们将给用户和机构带来问题的可能性非常重要。供参考：攻击的可能性特定攻击发生的可能性取决于网络所服务机构的类型。这里给出的数据适用于大多数网络系统。显然，许多因素会影响针对特定系统攻击的可能性，包括系统的宣传效果以及系统上数据的感知价值。因此，在评估对网络的威胁时，一定要谨慎行事。对任何计算机或网络来说，最可能的威胁是计算机病毒。例如，就在2017年10月的一个月内，McAfee列出了31种活跃病毒（https://home.mcafee.com/virusinfo/virus-calendar ）。每个月都会有几种新病毒爆发。新的病毒不断被创建，而旧的病毒仍然存在。需要注意的一点是，许多人并没有像他们应该做的那样经常更新防病毒软件。这个事实的证据是，在Internet上传播的许多病毒都已经发布了应对措施，但人们根本没有应用它们。因此，即使病毒已为人所知，并且防御措施已具备，但它依然能广泛传播，原因在于许多人没有定期更新保护措施或清理自己的系统。如果所有的计算机系统和网络都定期更新安全补丁并部署病毒扫描软件，那么就会避免大量病毒的爆发，或者至少能将它们的影响降到最低。阻塞攻击已经成为除病毒外最常见的攻击形式。你在本书后面将学到，阻塞攻击比入侵攻击更容易实现，因此发生得更频繁。一名聪明的黑客可以在Internet上找到工具来帮助他发起阻塞攻击。第2章将介绍更多关于阻塞攻击和恶意软件的内容。无论计算机犯罪的本质是什么，事实就是网络犯罪很普遍。2016年开展的一项计算机犯罪调查发现，32%的机构曾遭受过网络犯罪的影响，一些机构遭受的损失超过500万美元。而只有37%的受访者有充分可行的应急事件响应计划。实践中：什么是“系统滥用”？雇主和雇员对系统滥用（misuse）的看法经常不同。工作场所的所有系统都是雇主的财产。电脑、硬盘，甚至电子邮件都是雇主的财产。美国法律一直认为，雇主有权监控雇员的网络使用，甚至是电子邮件。大多数机构都有严格禁止任何除工作目的外使用计算机设备的政策。Internet连接仅限于与工作相关的使用，而不能用于阅读网站上的头条。有些公司不介意员工在午餐期间将Internet用于个人目的。从安全的角度来看，管理员必须关注员工访问的网站。他们正在下载Flash动画吗？他们正在下载自己的屏幕保护程序吗？下载的任何东西对系统来说都是潜在的威胁。即使没有下载，也存在网站跟踪用户和他们的计算机信息的可能性。从安全角度看，机构外的人对你的网络信息掌握得越少越好。任何一条信息对黑客来说都可能有潜在的用途。正如你将在第4章学到的，许多防火墙解决方案允许管理员阻塞某些网站，这是个经常使用的功能。公司最起码应该有个非常明确的策略，确切地描述哪些活动是允许的，哪些是不允许的。策略中的任何模棱两可都可能会在以后引起问题。在第11章中，你将学习更多关于定义和实现安全策略的内容。 1.9　威胁评估 当试图评估机构的威胁等级时，管理员必须考虑许多因素。第一个因素前面已经提到过，即系统对黑客的吸引力。一些系统吸引黑客是因为其金钱价值。金融机构的系统为黑客提供了诱人的目标。其他系统吸引黑客是因为它们所支持机构的公众形象。黑客被吸引到政府系统和计算机安全网站，仅仅是因为这些系统有很好的宣传效果。如果黑客成功进入其中的一个系统，他将在黑客社区中获得名声和威望。学术机构受到黑客攻击的频率也很高。高中和大学有大量年轻的、精通电脑的学生，这种群体中黑客和潜在黑客的数量可能比一般大众高。此外，学术机构在信息安全方面的声誉不太好。第二个风险因素是系统中信息的性质。如果一个系统拥有敏感或关键的信息，那么它的安全性要求较高。诸如社会保障号、信用卡号和医疗记录等个人数据也有很高的安全要求。拥有敏感的研究数据或机密信息的系统安全要求更高。最后要考虑的因素是系统的流量。对系统进行某种远程访问的人越多，存在的安全隐患就越大。例如，有大量用户从网络外面访问电子商务系统，其中的每个连接都代表着一个危险。相反，如果系统是自包含的，没有外部连接，那么它的安全风险就会减少。综合考虑系统对黑客的吸引力、系统存储信息的性质以及与系统远程连接的数量这几个因素后，管理员可以对系统的安全需求进行完整的评估。下面的数值尺度可以为系统的安全需求提供一个基础概括。考虑了三个因素（吸引力、信息内容和安全设备）。每个因素指派一个1～10的数字。前两个加在一起，然后减去第三个数。最终得分介于-8（极低风险，高安全性）到19（极高风险，低安全性）之间；数值越小系统越安全，数值越大风险越大。对一个系统来说，最好的评级如下： 对黑客的吸引力得分为1（即，系统几乎不为人所知，在政治或意识形态方面没有任何重要性等）。 在信息内容方面得分为1（即，系统不包含机密或敏感数据）。 系统的安全性得分为10（即，系统拥有多层的、主动的安全防御系统，包括防火墙、端口阻塞、防病毒软件、IDS、防间谍软件、合适的策略、所有的工作站和服务器都得到安全加固，等等）。 其中，对吸引力的评估是非常主观的。而评估信息内容的价值或安全等级可以用很粗略但简单的度量来完成。这个系统在第12章将再次提及并进一步扩展。显然，这个评估系统不是一门精确的科学，在某种程度上取决于个人对系统的评价。然而，这种方法确实为评估系统的安全提供了一个起点，当然它不是对安全的最终结论。 1.10　理解安全术语 在计算机安全领域学习时，你必须认识到，这门学科是安全专业人员和业余黑客相互重合的领域。因此，该领域结合了来自这两个领域的术语。本书的词汇表是整个课程中非常有用的参考工具。 1.10.1　黑客术语 我们首先从黑客术语开始。请注意，这些术语不是精确的，许多定义都有争议。不存在官方的黑客词汇表，这些术语都是通过在黑客社区的使用演变而来的。很显然，研究这类术语应该从黑客（Hacker）的定义开始，这是一个在电影和新闻广播中使用的术语。大多数人用它来描述任何闯入计算机系统的人。然而，安全专业人士和黑客自己对这个术语的使用不同。在黑客社区中，黑客是一个或多个特定系统的专家，他们想更深入地了解系统。黑客认为，检查系统的缺陷是了解它的最好方法。例如，一个精通Linux操作系统、通过检查其弱点和缺陷来理解这个系统的人就是一个黑客。然而，这通常也意味着检查是否可以利用一个缺陷来获取系统的访问权。这个过程中的“利用”部分将黑客区分为三类人： 白帽黑客（White hat hackers）发现系统中的漏洞之后，会向系统的厂商报告该漏洞。例如，如果他们发现Red Hat Linux中的某个缺陷，他们就会给Red Hat公司发电子邮件（可能是匿名的），解释缺陷是什么以及如何利用它。 黑帽黑客（Black hat hackers）是通常媒体（如电影和新闻）中描述的黑客。它们在进入系统之后，目标是造成某种类型的损害。他们可能窃取数据、删除文件或破坏网站。黑帽黑客有时被称为骇客。 灰帽黑客（Gray hat hackers）通常是守法的公民，但在某些情况下会冒险从事非法活动。他们这样做可能是因为各种各样的原因。通常，灰帽黑客会出于他们认为的道德上的原因进行非法活动，比如入侵一个他们认为从事不道德活动的公司的系统。请注意，在许多教科书中都找不到这一术语，但它在黑客社区内部却是一个常用术语。 不管黑客如何看待自己，未经许可侵入任何系统都是非法的。这意味着，从技术上来说，所有的黑客，不管他们隐喻上戴着什么颜色的“帽子”，都在违反法律。然而，许多人认为，白帽黑客实际上是通过在有道德缺陷的人利用漏洞之前，发现缺陷并告知厂商来为社会提供服务的。了解各种黑客类型只是学习黑客术语的开始。回想一下，黑客是一个特定系统的专家。如果是这样，那么对于那些自称是黑客却缺乏专业知识的人，又使用什么术语呢？对一个没有经验的黑客最常用的术语是脚本小子（script kiddy）。该名字来源于这样一个事实：Internet上充斥着大量可以下载的实用程序和脚本，人们可以下载并执行一些攻击任务。那些下载这些工具而没有真正理解目标系统的人被认为是脚本小子。实际上，相当多的自称为黑客的人只不过是脚本小子。现在介绍一种特殊类型的黑客。骇客是指那些以危害系统安全为目标，而不是以了解系统为目标的人。黑帽黑客与骇客之间没有区别。这两个术语都是指破坏系统安全、在没有得到相关机构许可的情况下侵入系统、带有恶意目的的人。什么时候以及什么原因会有人允许另一团体来攻击/破解一个系统呢？最常见的原因是评估系统的脆弱性。这是黑客的另一种特殊类型—道德黑客（ethical hacker）或思匿客（sneaker）（一个很老的术语，现在不经常使用），他们是合法地攻击/破解系统以评估安全缺陷的人。1992年Robert Redford、Dan Aykroyd以及Sydney Poitier主演了一部关于这个主题的电影，名为《Sneakers》。现在，有从事这种类型工作的顾问，你甚至可以找到专门从事这种活动的公司，因为有越来越多的公司使用这种服务来评估他们的脆弱性。今天，这类人通常称为渗透测试者（penetration tester），或简单地称为pen tester。自本书发布第一版以来，这个职业已经成熟。对那些正在考虑成为渗透测试者或聘请渗透测试者的读者，本书给你一个忠告：雇佣来评估系统脆弱性的任何人都必须技术精湛并且道德高尚。这意味着在安排他的服务之前应该对其进行犯罪背景审查。你肯定不想雇佣一个被定过罪的强盗来当你的守夜人。你也不应该考虑雇佣任何有犯罪前科的人，尤其是有计算机犯罪前科的人，来作为渗透测试者或道德黑客。有些人可能会争辩说，有前科的黑客（骇客）拥有最佳的资格来评估你的系统漏洞。但事实并非如此，理由如下： 你可以找到一些既知道和理解黑客技能又从未犯过任何罪的合法安全专业人员。你可以得到评估系统所需的技能，而不必使用一个已知存在缺陷的顾问。 如果你争辩说雇用有犯罪前科的黑客意味着雇佣了有天赋的人，那么你可以推测，这个人并没有想象中那么好，因为他曾被抓住过。 最重要的是，让一个有犯罪前科的人访问你的系统，就像雇佣一个多次犯酒驾罪的人作为你的司机。在这两种情况下，你都是在惹祸，而且可能会招致重大的民事和刑事责任。此外，建议对渗透测试者的资格进行全面审查。正如一些人会谎称自己是黑客高手一样，有人会谎称自己是训练有素的渗透测试员。一个不合格的测试员可能会称赞你的系统，而实际上是因为他没有能力，不能成功地攻破你的系统。第12章将讨论评估目标系统的基本知识，以及为此目的所聘请顾问的必要资格。黑客攻击的另一个专业分支是攻入电话系统。这个子领域称为飞客攻击（phreaking）。新黑客词典（New Hackers Dictionary）实际上把飞客攻击定义为“为了不支付某种电信账单、订单、转账或其他服务，而采取恶作剧的大部分是非法的行为”（Raymond，2003）。飞客攻击需要相当丰富的电信知识，许多飞客（phreaker）都有为电话公司或其他电信企业工作的专业经验。这种类型的行为通常依赖于攻击电话系统的专门技术，而不是仅仅了解某些技术。例如，需要用某些设备攻击电话系统。电话系统往往依赖于频率。如果你有一个按键电话，你会注意到，当你按下按键时，每个按键都有不同的频率。记录和复制特定频率的机器对于飞客攻击来说常常是必不可少的。 1.10.2　安全术语 安全专业人员也有特定的术语。任何受过网络管理培训或有过网络管理经验的读者可能都已经熟悉了其中的大部分。虽然大多数黑客术语是描述活动或执行它的人（飞客攻击、思匿客等），但本书中的许多安全术语是关于设备和策略的。这相当合理，因为攻击是以攻击者和攻击方法为中心的攻击性活动，而安全是与防御屏障和防御过程相关的防御性活动。第一个也是最基本的安全设备是防火墙（firewall）。防火墙是处于网络和外部世界之间的一个屏障。有时防火墙是一个独立的服务器，有时是一台路由器，有时是在机器上运行的软件。不管它们的物理形式是什么，其目的都是一样的：过滤传入和传出网络的流量。防火墙与代理服务器（proxy server）相关，并且经常与代理服务器一起使用。代理服务器能向外界隐藏内部网络的IP地址，使网络对外表现为单一的IP地址（代理服务器自己的IP地址）。防火墙和代理服务器被添加到网络中后，可以为网络提供基本的边界安全防御。他们过滤入站和出站的网络流量，但不影响网络中的流量。有时要在防火墙上增加入侵检测系统（Intrusion Detection System，IDS）来增强防护能力。入侵检测系统监视流量，以查找可能标识具有入侵企图的可疑活动。访问控制（Access control）是另一个重要的计算机安全术语，在后面几章中你会对它特别感兴趣。访问控制是为限制资源访问所采取的所有方法的总和，包括登录过程、加密以及旨在防止未授权人员访问资源的任何方法。认证（Authentication）是访问控制的一个子集，可能是最基本的安全活动。认证是确定用户或其他系统所提供的凭证（如用户名和口令）是否被授权访问所涉及网络资源的过程。当用户以用户名和口令登录时，系统尝试验证用户名和口令。如果认证通过，则用户将被授权访问。不可否认性（Non-repudiation）是另一个计算机安全中常遇到的术语。它是指任何用来确保在计算机上执行某一动作的人不能虚假地否认他曾执行过该动作的技术。不可否认性提供用户在特定时间采取特定行动的可靠记录。简而言之，它是跟踪什么用户采取什么行动的方法。各种系统日志都提供了一种不可否认性的方法。审计（auditing）是最重要的安全活动之一，它是审阅日志、记录和程序以确定它们是否符合标准的过程。本书很多章节都涉及这一活动，在第12章会重点介绍。审计十分关键，因为检查系统是否采取了适当的安全措施是确保系统安全的唯一途径。最小权限（Least privileges）是你在向任何用户或设备分配权限时应该记住的一个概念。这个概念的含义是，你只赋予一个人完成他的工作所需的最低限度的权限。要记住这个简单却很关键的概念。你还应该记住CIA三角形（CIA triangle），即机密性（Confidentiality）、完整性（Integrity）和可用性（Availability）三个特性。所有的安全措施都应该影响这三者之中的一个或多个。例如，硬盘驱动器加密以及良好的口令有助于保护机密性。数字签名有助于确保完整性，好的备份系统或网络服务器冗余可以支持可用性。可以编写一本完整的书来介绍计算机安全术语。上面介绍的这几个术语应用很普遍，熟悉它们非常重要。本章末尾有一些练习将帮助你扩展关于计算机安全术语的知识。下面这些链接也很有帮助： 美国网络安全职业和研究术语表： https://niccs.us-cert.gov/glossary SANS安全术语表：https://www.sans.org/security-resources/glossary-of-terms/ NIST关键信息安全术语表： http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf 供参考：审计与渗透测试渗透测试者使用的测试过程实际上是一种特殊类型的审计。你可能想知道渗透测试和审计有什么区别。普通的审计与渗透测试的区别在于其方法不同。普通的审计通常包括检查法律、法规和标准的遵守情况，而渗透测试则试图攻破系统以评估其安全性。传统的审计包括查看日志、检查系统设置、确保安全符合某个特定的标准。而渗透测试者则简单地试图攻入系统。如果能成功的话，他们会记录他们是如何做的，并说明如何阻止别人做同样的事情。 1.11　选择网络安全模式 机构可以从几种网络安全模式（approach）中进行选择。特定的模式或范型（paradigm）将影响所有后续的安全决策，并为整个机构的网络安全基础设施设置基调。网络安全范型既可以按照安全措施的范围（边界、分层）来分类，也可以按照系统的主动性程度来分类。 1.11.1　边界安全模式 在边界安全（Perimeter Security）模式中，大部分的安全工作都集中在网络的边界上。这种聚焦在网络边界的工作可能包括防火墙、代理服务器、口令策略以及任何使网络非授权访问变得不太可能的技术或程序，而针对网络内部系统安全的工作极少或根本没有。在这种方法中，边界是被保护的，但边界内部的各种系统往往是很脆弱的。边界安全模式显然存在缺陷。但为什么有些公司使用它呢？预算有限的小公司或缺乏经验的网络管理员可能会使用边界安全模式。对于那些不存储敏感数据的小型机构来说，这种模式或许已经足够了，但对较大的公司却不太有效。 1.11.2　分层安全模式 分层安全（Layered Security）模式是一种不仅要保护边界的安全，而且要保护网络内部各个系统安全的模式。网络中的所有服务器、工作站、路由器和集线器都是安全的。实现该模式的一种方法是将网络划分成段，并将每个段作为单独的网络进行保护。这样，如果边界安全被突破，那么并不是所有的内部系统都会受到影响。只要条件允许，分层安全模式是首选模式。还可以用主动和/或被动的程度来评估安全模式。这可以通过度量系统的安全基础设施和策略中有多少专门用于预防措施，有多少专门用于攻击发生后对攻击的响应来实现。被动安全模式很少或没有采取措施来防止攻击。相反，动态安全模式，或称主动防御，则在攻击发生之前采取一些措施防止攻击的发生。主动防御的一个例子是使用IDS，它用于检测规避安全措施的企图。一个破坏安全的企图即使没有成功，IDS也会告诉系统管理员该企图的发生。IDS还可以用于检测入侵者使用的攻击目标系统的各种技术，甚至能在攻击发起之前警告网络管理员潜在攻击企图的存在。 1.11.3　混合安全模式 在现实世界中，网络安全很少完全采用一种模式或另一种模式。网络通常采用多种安全模式中的多种因素。上述两种分类可以结合起来，形成混合模式。一个网络可以主要是被动的，但同时也是分层的安全模式，或者主要是边界安全模式，但同时也是主动的。考虑使用笛卡儿坐标系描述计算机安全的方法，其中，x轴表示方法的被动/主动水平，y轴描绘从边界防护到分层防护的范围，这种表示有助于理解该方法。最理想的混合模式是动态的分层模式。 1.12　网络安全与法律 越来越多的法律问题影响着管理员如何管理网络安全。如果你所在机构是一家上市公司、一家政府机构，或者与它们有生意往来的机构，那么如何选择你的安全模式可能存在法律上的约束。法律约束包括影响信息如何存储或访问的任何法律。Sarbanes-Oxley（本章后面将详细讨论）就是一个例子。即使你的网络在法律上不受这些安全指南的约束，但了解影响计算机安全的各种法律，并得出可能适用你自己安全标准的想法也是有用的。在美国，影响计算机安全的、最古老的立法之一是颁布于1987年的计算机安全法案（Computer Security Act of 1987）（1987，第100届国会）。该法案要求政府机构确定敏感系统、进行计算机安全培训，并制定计算机安全计划。由于该法律要求美国联邦机构在没有规定任何标准的情况下建立安全措施，因此是一个模糊的命令。这项立法建立了制定具体标准的法律授权，为未来的指南和规则铺平了道路。也有助于定义某些术语，如根据立法中的下述论述，可以确定什么信息是“敏感的”：Sensitive information is any information, the loss, misuse, or unauthorized access to or modification of which could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under section 552a of title 5, United States Code (the Privacy Act), but which has not been specifically authorized under criteria established by an Executive order or an Act of Congress to be kept secret in the interest of national defense or foreign policy. 记住这个定义，因为不仅仅是社会保障信息（Social Security information）或病例（medical history）需要安全保护。当考虑哪些信息需要安全保护时，只需简单地问一个问题：这些信息的非授权访问或者修改会对我的机构产生不利影响吗？如果答案是“是”，那么就必须认为该信息是“敏感”的，需要安全防范措施。另一个更具体的、适用于政府系统强制安全的联邦法律是OMB Circular A-130（具体来说，是附录3）。该文件要求联邦机构建立包含特定要素的安全程序。该文件描述了制定计算机系统标准的要求以及政府机构持有记录的要求。美国大多数州都有关于计算机安全的具体法律，比如佛罗里达州的计算机犯罪法案（Computer Crimes Act of Florida）、阿拉巴马州的计算机犯罪法案（Computer Crime Act of Alabama）和奥克拉荷马州的计算机犯罪法案（Computer Crimes Act of Oklahoma）。任何负责网络安全的人都有可能参与犯罪调查。可能是对黑客攻击事件的调查，也可能是对员工滥用计算机资源的调查。无论是什么性质的犯罪引起的调查，清楚你所在州的计算机犯罪法律是非常重要的。在http://www.irongeek.com/i.php?page=computerlaws/state-hacking-laws 上列出了各州适用于计算机犯罪的法律。该列表来自高级实验室工作站（Advanced Laboratory Workstation，ALW）、美国健康研究院（National Institutes for Health，NIH）和信息技术中心（Center for Information Technology）。请记住，任何规范隐私的法律，如健康保险流通与责任法案（Health Insurance Portability and Accountability Act, HIPAA）涉及医疗记录，都对计算机安全有直接影响。如果一个系统被攻破，并且隐私法规所涵盖的数据受到损害，可能你就需要证明自己履行了保护这些数据应尽的职责。如果发现你没有采取适当的预防措施，就会导致承担民事责任。与商业网络安全相关度更高的法律是Sarbanes-Oxley，常被称为SOX（http://www.soxlaw.com/ ）。该法律规定了公开上市交易的公司如何存储和报告财务数据，其中保护这些数据的安全是很重要的一部分。显然，全面介绍这个法律已经超出了本章范围，甚至超出了本书范围。值得指出的是，网络安全除了是一门技术学科外，还必须考虑商业和法律后果。 1.13　使用安全资源 在阅读本书或进入专业世界时，你经常需要一些额外的安全资源。本节介绍一些最重要的资源，以及那些对你来说可能很有用的资源。 CERT（www.cert.org/ ）。CERT代表卡内基梅隆大学发起的计算机应急响应小组（Computer Emergency Response Team, CERT）。CERT是第一个计算机应急事件的响应队伍，目前仍然是业界最受尊敬的组织之一。任何对网络安全感兴趣的人都应该定期访问它的网站。网站上有丰富的文档，包括安全策略指南、前沿安全研究、安全警报以及其他更多内容。 微软安全技术中心（https://technet.microsoft.com/en-us/security ）。这个站点特别有用，因为有太多的计算机运行微软的操作系统。这个网站是所有微软的安全信息、工具和更新的门户。微软软件的用户应该定期访问这个网站。 F-安全公司（F-Secure Corporation, www.f-secure.com/ ）。除了其他内容之外，这个网站是一个关于病毒爆发详细信息的存储库。在这里你能找到关于特定病毒的通知和详细信息。这些信息包括病毒如何传播、识别病毒的方法以及清除特定病毒感染的具体工具。 F-安全实验室（www.f-secure.com/en/web/labs_global/home ）。 美国系统网络安全协会（www. sans.org/ ）。该网站提供计算机安全几乎所有方面的详细文档。SANS研究所还赞助了许多安全研究项目，并在其网站上发布有关这些项目的信息。 1.14　本章小结 对网络的威胁在日益增长。我们看到越来越多的黑客攻击、病毒以及其他形式的攻击。危险在增大，同时法律压力（如HIPAA和SOX）也在增大，因此网络管理员的网络安全需求在日益增长。为了满足这一需求，你必须全面理解你的网络存在的威胁，以及你可以采取的对策。这要从对网络威胁的现实评估开始。本章介绍了网络安全的基本概念、威胁的一般分类以及基本的安全术语。后续章节将详细阐述这些信息。 1.15　自测题 1.15.1　多项选择题 1.下列哪项不是威胁的三种主要类型之一？ A.拒绝服务攻击 B.计算机病毒或蠕虫 C.实际入侵系统 D.网络拍卖欺诈 2.下列哪一个是病毒最准确的定义？ A.通过电子邮件传播的任何程序 B.携带恶意负载的任何程序 C.任何自我复制的程序 D.任何可能破坏你系统的程序 3.如果一个观点过于谨慎，是否有什么理由不采取这个极端的安全观点？ A.不，没有理由不采取如此极端的观点 B.是的，这可能导致资源浪费在不太可能的威胁上 C.是的，如果你准备犯错误，那么假设几乎没有什么现实威胁 D.是的，这需要你提高安全技能，以便实施更严格的防御 4.什么是计算机病毒？ A.任何未经你的许可下载到你系统中的程序 B.任何自我复制的程序 C.任何对你的系统造成伤害的程序 D.任何可以更改Windows注册表的程序 5.下面哪个是间谍软件的最好定义？ A.任何记录击键的软件 B.任何用于收集情报的软件 C.任何监视你的系统的软件或硬件 D.任何监视你访问哪些网站的软件 6.下列哪一项是道德黑客术语的最佳定义？ A. 一个攻击系统却没被抓住的业余爱好者 B. 一个通过伪造合法口令来攻击系统的人 C. 一个为测试系统漏洞而攻击系统的人 D. 一个业余黑客 7.描述攻击电话系统的术语是什么？ A. Telco-hacking B. Hacking C. Cracking D. Phreaking 8.下列哪一个是恶意软件的最佳定义？ A. 具有恶意目的的软件 B. 自我复制的软件 C. 损害你系统的软件 D. 系统中任何未正确配置的软件 9.下列哪一项是战争驾驶的最佳定义？ A. 在攻击和搜索计算机作业时驾驶 B. 在使用无线连接进行攻击时驾驶 C. 驾车寻找可攻击的无线网络 D. 驱车并寻找黑客对手 10.下列哪一项是最基本的安全活动？ A. 安装防火墙 B. 认证用户 C. 控制对资源的访问 D. 使用病毒扫描器 11.阻塞攻击的目的是什么？ A. 在目标机器上安装病毒 B. 关闭安全措施 C. 阻止合法用户访问系统 D. 攻入目标系统 12.安全的三种模式是什么？ A. 边界、分层及混合 B. 高安全、中等安全和低安全 C. 内部、外部和混合 D. 边界、完全、无 13.入侵检测系统是如下哪项内容的例子？ A. 主动安全 B. 边界安全 C. 混合安全 D. 良好的安全实践 14.下列哪一项最有可能被归类为系统滥用？ A. 利用Web查找竞争对手的信息 B. 偶尔接收个人电子邮件 C. 用你的工作计算机做自己的（非公司的）业务 D. 午餐期间在网上购物 15.最理想的安全模式是： A. 边界和动态 B. 分层和动态 C. 边界和静态 D. 分层和静态 16.当评估一个系统的威胁时，你应该考虑哪三个因素？ A. 系统的吸引力、系统中包含的信息以及系统的流量 B. 安全团队的技术水平、系统的吸引力和系统的流量 C. 系统的流量、安全预算和安全团队的技术水平 D. 系统的吸引力、系统中包含的信息和安全预算 17.下列哪一项是不可否认性的最佳定义？ A. 不允许潜在入侵者否认他的攻击的安全属性 B. 验证哪个用户执行什么动作的过程 C. 是用户认证的另一个术语 D. 访问控制 18.以下哪些类型的隐私法律影响计算机安全？ A. 美国任何州的隐私法律 B. 美国任何适用于你所在机构的隐私法律 C. 美国任何隐私法律 D. 美国任何联邦隐私法律 19.第一个计算机应急响应小组隶属于哪所大学？ A. 普林斯顿大学 B. 卡内基梅隆大学 C. 哈佛大学 D. 耶鲁大学 20.下列哪一项是“敏感信息”的最佳定义？ A.军事或国防相关的信息 B.任何价值超过1000美元的信息 C.任何如果被未授权的人员访问就可能损害你所在机构的信息 D.任何具有货币价值并受隐私法律保护的信息 21.下列哪一项很好地定义了道德黑客与审计者之间的主要区别？ A.没有区别 B.道德黑客往往缺乏技能 C.审计者往往缺乏技能 D.道德黑客倾向于使用更多非常规的方法 1.15.2　练习题 练习1.1　本月发生了多少次病毒攻击？1.使用各种网站，确定本月报告的病毒攻击数量。你可能会发现，诸如www.f-secure.com这样的网站对找到这类信息很有帮助。 2.将这一数字与过去三个月、九个月和十二个月的病毒爆发数量进行比较。 3.病毒攻击频率是增加了还是减少了？举例来支持你的答案，并说明过去一年病毒攻击估计的变化数量。 练习1.2　特洛伊木马攻击1.使用Internet、期刊、书籍或其他资源，找到在过去九个月内发生的一次特洛伊木马攻击事件。 2.这个特洛伊木马是怎么传播的？它造成了什么损害？ 3.描述这个木马攻击，包括： 任何具体的目标 攻击肇事者是否已被逮捕和/或被起诉 关于该攻击，发布了什么类型的安全警告，给出了什么防御措施 练习1.3　计算机犯罪的近期趋势1.使用你喜欢的搜索引擎，找到关于计算机犯罪的最新调查。 2.注意哪些领域的计算机犯罪有所增加和减少。 3.描述本次调查与2002年公布的调查之间的变化。 4.这两项调查告诉你计算机犯罪的趋势是什么？ 5.哪个领域的计算机犯罪增长最快？ 练习1.4　黑客攻击术语使用New Hacker抯 Dictionary（新黑客字典），网址为：http://www.outpost9.com/reference/jargon/jargon_toc.html ，定义以下术语。然后检查Internet（网页、聊天室或电子公告牌），为每个术语找到一个用例。 daemon（守护程序） dead code（死码） dumpster diving（垃圾搜寻） leapfrog attack（跳步攻击） kluge（杂凑攻击） nuke（核弹） 练习1.5　安全专业术语使用本章中讨论的三个词汇表之一，定义下列术语： access control list（访问控制列表） adware（广告软件） authentication（认证） backdoor（后门） buffer（缓冲区） HotFix（热补丁） 1.15.3　项目题 项目1.1　了解病毒1.使用你最喜欢的搜索引擎进行搜索，找到一种在过去六个月里发布的病毒。你可以在www.f-secure.com 这类网站上找到这些信息。2.描述你选择的病毒是如何工作的，包括它使用的传播方法。3.描述该病毒造成的损害。4.该病毒有特定的目标吗？5.病毒攻击的肇事者被抓获和/或被起诉了吗？6.关于该病毒攻击发布了什么类型的安全警告？7.给出了哪些措施来防御它？8.对该病毒最恰当的描述是病毒还是蠕虫？项目1.2　安全专业利用包括Web在内的各种资源，找出计算机安全管理员工作所需的资质。你需要找出所需的具体技术、工作经验、教育水平以及任何认证。本项目可以帮你了解，业界认为的安全专业人员要理解的最重要的主题是什么。可以提供帮助的网站包括：www.computerjobs.comwww.dice.comwww.monster.com项目1.3　查找网络资源本章提供了几个很好的安全信息Web资源。现在，你应该使用Internet来确定三个你认为对安全专业人员有益、能提供可靠和有效信息的网站。解释为什么你认为它们是有效的信息来源。注意：你可能会在后续章节的练习和项目中使用这些资源，所以一定要确保你可以依赖它们所提供的数据。

  本文作者：阿里中间件-坤宇 案首语: 阿里集团技术大牛，@正明，淘宝基础核心软件研发负责人、LVS创始人、阿里云首席科学家章文嵩博士从阿里离职，去追求技术人生另一段历程，让阿里像我一样的很多热爱技术的工程师都有一丝牵动和感触。 我个人作为一个平凡的一线技术工程师，对章博士是很敬佩的(虽然他还不认识我)，国内IT业界这么多年，在底层基石技术层面有所建树，打到Linux标准内核模块层面的应该就LVS了吧，而且就广泛影响力方面，LVS在Linux逐渐取代IBM Aix, Sun Solaris,HPUX 这些Unix们的过程中，扮演了很重要一块的角色，那就是LVS是Linux Cluster的标准解决方案的核心,在我个人看来，X86-64芯片对比Power,Itanium,PA-RISC的更高性价比和Lvs Linux Cluster的方案成熟是互联网时代刚开始兴起的那个时期，在技术准备上，从Unix逐渐走向低端商用机+Linux方案的2把掘墓锄头，虽然不是唯二的2把，但是绝对是其中非常重要的2把,而很多中国人、美国人、欧洲人、日本人...的技术书籍里介绍Linux技术的书籍里，LVS必然会在里面占有一定的篇幅。另外章博士也是国内开源文化的积极的倡导者和真正践行者，我们阿里中间件之所以开源被业界广泛使用的产品(Dubbo,MetaQ,Diamond...)，究其原因，也可以说是深受章博士的影响。 在阿里中间件，我所在的团队恰好是专注在”软负载“（软件负载网络）方面，提供的产品和服务，跟负载均衡产品有很大一部分交集，在集团内，我们的产品VIPServer可以说跟LVS有一些直面的竞争，在集团内越来越多的业务逐渐从LVS迁往VIPServer上，但正因为如此，所以在负载均衡领域我们对于章博士的江湖地位和影响力才有更深刻的了解。在这个技术人目光再次聚焦在章博士身上的时候，我想借此机会将我们团队对于负载均衡产品这一块的一些思考和实践经验，总结分享给需要的人，希望帮助到正在思考这一块的技术人。 下面让我们以轻松一点的心情开始: 阿里 Load Balance 之旅 一、什么是负载均衡（Load Balance） “负载(load)”惹得祸 首先让我们从原点出发。 某一天清晨起床，你突然有了一个美妙的想法，这个想法让你兴奋不已，因为你发现了一个具有广阔市场前景的处女地，这个处女地还完全没有被开垦，这是一项新业务，这项业务能满足世界上大部分人的某个方面他们自己都不知道的潜在的需求，更妙的是，到目前为止，它还没有被任何人发现。你简直被自己的天才惊呆了，被自己的天才想法感动的内牛满面，你确信你的人生会因为这个想法而改变，宇宙也会因为你这个想法而变的大不相同，你确定这个想法的实现将能帮助你走上人生巅峰，上上个时代是比尔盖子，上个时代是拉里配齐，下个时代毫无疑问将是你，你迫不及待的想要将这项业务通过一个系统来表达和实现，于是你奋战了好几个通宵，有了下面这个能支撑这项新业务的非常牛逼的系统:   是的，你的系统已经有了第一个用户，这个用户就是你自己。接下来你将你的系统通过X信朋友圈、钉钉、各大论坛广邀各路亲朋好友试试这个系统，结果是，非常棒! 好评如潮，他们不停的拉自己的亲朋好友开始访问这个系统，因此注册、活跃用户越来越多，此时，你兴奋不已，感觉自己马上就要走上人生巅峰。 但等等，不知道哪里出了问题，你的这个新系统居然上了ccav财经频道，而且被各路媒体小报纷纷报导，瞬间所有人都想看看这个牛逼的系统，于是乎,悲剧发生了:     怎么办？怎么办？很快你想到了3个解决方案。 纵向扩展（Scale Up) 没啥好说的，也许只是服务器还不够NB，买！买！买！宇宙最好的服务器来上一台，可惜，创业刚开始，投资人的钱要花在刀刃上，比如广告营销上，比如路边扫个码啊，顺便送个内衣啊、牙刷啊什么的，服务器? 买不起! 而且看了一下宇宙上最好服务器的网卡配置，更泄气，这就不是有钱买个NB服务器就能解决的事！ 业务拆分 你仔细审视之后，发现其实你的系统的2个页面是2个不同的业务，用来满足不同的需求的，于是啊，你就想，是不是能把这2个业务分开到2个系统中去，这样用户们自然乖乖的被引导、分流到2个子系统去了，这样每个系统的压力就减少了啊。这就好比一个饭店，生意火爆，原先来吃火锅和吃大饼卷牛排的都在一起，挤不下之后，现在分成了2个店，1个是火锅店，1个是大饼卷牛排店。从某种角度来说，这种其实也是一种负载均衡，但怎么做业务拆分并且通过组织文化和人事架构去保障和适应这种业务拆分，是有很多的业务考量和业务属性在里面的，每个老板和每个行业的答案可能都是不同的，此文讨论的不在这个方向上。 横向扩展（Scale Out）和 副本(Replica) 做完上面的垂直拆分之后，可能你会发现还是不行啊，这世界上拥有独特口味的人太多，吃大饼卷牛排的人还是太多了，怎么办? 开分店吧，每个上档次的商场都开一个大饼卷牛排店，这样每个地域的人又被分流到了附近的店。这个提供一模一样服务的“分店”就是系统的副本（Replica），分布式系统中的副本(Replica)除了满足数据冗余，容灾的需要等之外，横向扩展，通过开多个分店（Replica)分流的行为,就是负载均衡,做到多副本之间分流是一个重要的目的。而这个正是本文讨论的范围所在，如下简图:   接下来, 关于如何让你的系统实现负载均衡，做到Scale Out, 你开始走上选型之路， 二、常用的负载均衡技术比较 DNS 轮询 DNS本身的机制不再赘述，这里主要看一看基于DNS的负载均衡，其大致原理很清楚，DNS系统本身支持同一个域名映射到多个ip (A记录）,例如       这样每次向DNS系统询问该域名的ip地址时（Tell Me The IP Address of niubility.com.），DNS会轮询(Round Robin)这个ip列表，每次给一个不同的ip，从而达到负载均衡的效果。 来看看这种负载均衡解决方案的优缺点 优点 易于实现 对于应用系统本身几乎没有任何侵入，配置也很简单，在某个文本里多加几行A记录就可以。尤其对于一个基于Web的系统来说更是如此，用户在浏览器里输入的URL host部分天然就是域名，所以在某个环节你必然有起码一台DNS服务器记录着这个域名对应的ip，所以可以说是基于已有域名系统(资产)就做到了负载均衡。 缺点 会话粘连 (Session Sticky) 客户端与目标系统之间一般存在会话的概念（不止是web系统的http session）, 其本质在于server端会或多或少的存一些客户端整个会话期间交互的身份识别以及数据信息，为了防止server端每次都对同一个客户端问一下，你是谁？系统会希望客户端在一个会话期间粘连在某个特定的serer上，除非这个server失败才failover到其它的server上，这种粘连特性对于server处理客户端请求处理的性能和客户端看到的数据一致性是有很大好处的。但是DNS负载均衡不能保证下一次请求会再次落在同一个server上。 DNS解析缓存和TTL带来的麻烦 dns记录的缓存以及缓存失效时间都是个问题，在无线时代，通常来自手机的访问会经过称为行业网关的代理服务器，由于代理服务器会将域名解析的结果缓存一段时间，所以所有经由这个代理服务器的访问请求就全被解析到同一台服务器上去了，因此就可能无法实现均等分配需要处理的请求了。另外在后端集群的拓扑结构(副本数、部署位置、健康状态等)发生变化之后，dns配置的变化要等到网络上所有节点的缓存失效才能反馈出来，这带来的问题起码有2个，1是在等待失效过程中，完全不可控，没有办法加快这个进程，中美切换要花10分钟，因为要等网络所有几点对某些域名的TTL失效，2是滞后，有时候这种滞后是致命的，比如仍然有部分流量打到已经挂掉的那部分服务器上。 容错 一个大型数据中心，每天都有机器坏了是很正常的事情，尤其是在虚拟化大行其道的今天，更是如此，相信你对虚拟主机又崩溃了一个，或者总是被同宿主机的猪一样的队友“挤”死这种情况一定不陌生。dns负载均衡的一大问题就在于这种情况下的容灾很麻烦，一是需要人工干预或者其他软件配合做健康监测，从dns配置中将无响应的机器或者崩溃的机器的相应的A记录删掉。一是删掉之后也要等到所有网络节点上的dns解析缓存失效，在这端时间内，很多访问系统的客户会受到影响。 数据热点 dns是在域名层面做负载均衡，如果从web系统的请求URL角度讲，不同的URL对后端server的压力强度不一样，dns负载很可能会出现所有高强度的请求全都被打到小部分服务器甚至同一台上去了的情况，这个问题的可怕性不在于风险，而在于风险完全不可控。 引入负载均衡器 如图: 客户端 -> LB -> replica1,replica2,replica3   LB负责客户端流量到后端服务集群的分发，一般LB也会负责后端所有server的健康监测，关于健康监测这一块我们在稍后一点再做具体分析。 优点 可以在LB里面做集中的分发逻辑，可以有多种分发方式，例如最常见的Round Robin, Random Robin, Weight-Based Round Robin等。 缺点 LB是单点, 这里其实是有2个问题，下面具体分解一下。 问题1: 所有流量(请求流、响应流）都要经过LB，量太大，LB这小身板扛不住啊，尤其是响应流，一般远大于请求流，为什么? 我们想想一般一个http请求报文大小和响应的报文大小的对比就明白了。   解决方案: 响应流不走LB了！   问题2: LB是单点啊，挂了，所有流量都损失了   解决方案之一(LB Active-Standby模式):   现在一些LB也会支持Active-Active模式，这里不再介绍。 •       四层LB vs 七层LB 四层LB的特点一般是在网络和网络传输层(TCP/IP)做负载均衡，而七层则是指在应用层做负载均衡。2者的区别还是比较大的，各有优缺点，四层LB对于应用侵入比较小，这一层的LB对应用的感知较少，同时应用接入基本不需要针对LB做任何的代码改造。七层负载均衡一般对应用本身的感知比较多，可以结合一些通用的业务流量负载逻辑和容灾逻辑做成很细致的负载均衡和流量导向方案，但是一般接入时，应用需要配合做相应的改造。 互联网时代流量就是钱啊，对于流量的调度的细致程度往往是四层LB难以满足的，可以说七层负载均衡的解决方案现在是百花齐放，百家争鸣，中间层负载均衡(mid-tier load balancing)正当其时。 三、健康检测，负载均衡的伴侣 对于LB或者一个LB解决方案来说，健康检测是LB固有需要一起实现的需求之一，LB要能帮助业务实现业务、服务器、容器的优雅上、下线，帮助业务实现透明的扩容、缩容等一系列很现实的功能，如下简图:     在云计算时代弹性计算(Elastic Compute Service)，按需伸缩(On-Demand Allocation)大行其道的今天，对于LB健康检测方案的灵敏度，准确性，多层次等等都提出了非常高的要求，别看健康检测这个功能貌似很简单，但是实现过程中如果有很多地方没有想到，很容易就造成系统的重大的故障，我们的一些系统在心跳检测上栽的跟头并不少，踩过很多的坑。 四、为什么我们要做VIPServer？ 在有@正明（章文嵩博士的花名）这样的技术大牛，LVS的原作者本尊坐镇的阿里，为什么阿里会再做一个负载均衡产品?其实很简单，为了解决实际的业务问题。在集团,阿里技术团队常常面临的都是世界级难题，中间件团队更是如此，我们不敢说对这些问题我们解得多好，但我们真的在踏实的认真的解这些问题，而且用我们自己特有的方式，而不是COPY国外技术栈的方式在解这些难题，其实我们很多时候也很想COPY啊，但是放眼全球相关领域确实是没得抄。言归正传，上面我们过了一遍常见的负载均衡方案之后，我们可以发现传统LB，如LVS的解决方案中并不是把所有的问题都已经解决了，我们检视一下，起码还遗留了6个问题: 1、如果过LB的请求量就大到把LB给打挂了怎么办?互联网的流量，尤其是中国互联网的流量，我们要有足够的自信啊，而且参与过春节买票的，春晚修一修抢红包的都能想象得到。 2、LB虽然可以有standby的方案或者有小规模集群能力，但如果active/standby同时挂了怎么办? 1个蛋蛋很危险，但2个蛋蛋也未必就多安全。比如在active-standby方案中，既然active撑不住请求流量，那么作为其clone的standby身上当然也不会出现任何奇迹，那么是不是LB前面还应该再架一层LB呢?能不能LB集群全挂了的情况下，不影响正常的业务? 3、请求方和目标机器之间总是要过一次LB,这在网络链路上是多了1跳，我们都知道多一跳可不光是rt的损耗那么简单，链路上从1跳到2跳，链路和连接出故障的概率也翻了一倍,这要怎么解？ 4、多机房，多区域的异地多活与容灾，国际化战略的跨国流量的容灾对于负载均衡提出的挑战怎么解，在阿里集团内部，现在断网、断电、断机房的演习如日常喝水、像办公大楼消防演习一样随意，据说要达到，马老师半夜起来上个厕所，顺便断个电的能力，这些容灾场景下业务流量的负载均衡怎么解？ 5、每次在一些如“秒杀”，“大促”等营销热点场景下，业务为了应对可以预期的流量洪峰，评估LB这一块的容量够不够、要扩多少的痛点又如何解决?LB的弹性在哪里? 6、成本。虽然LVS比一些传统硬件LB的成本已经有很大的优势，但是在一个大型互联网系统级别的流量和业务发展面前,LVS的使用成本还是太高了一点。 VIPServer就是为了解决这些实际问题而生，所以上面介绍的这些我们耳熟能详的机制全都不是VIPServer解决问题的思路。 五、VIPServer简介 VIPServer是阿里中间件团队开发的一个中间层负载均衡(mid-tier load balancing)产品，VIPServer是基于P2P模式，是一个七层负载均衡产品。VIPServer提供动态域名解析和负载均衡服务，支持很多诸如多业务单元同单元优先、同机房优先、同区域优先等一系列流量智能调度和容灾策略，支持多种健康监测协议，支持精细的权重控制，提供多级容灾体系、具有对称调用、健康阈值保护等保护功能的解决方案。是阿里负载均衡体系、域名服务体系的一个非常重要的组成部分。目前包括阿里妈妈、钉钉、搜索、AE、1688、阿里云、高德等几乎所有的业务线均在使用VIPServer，在一些重大的项目例如历年双11，支付宝春晚红包项目都发挥了重大的作用。 六、为什么短短几年VIPServer在阿里集团发展的这么快? 讲了这么多平实的技术的东西，让我们接着上面的故事往下叙述，帮助您理解VIPServer为何在发挥越来越重要的作用。我们看看上面的故事中，随着业务的发展还会发生一些什么事，遇到哪些挑战。 现在你的公司已经各方面都已经走上正轨，马上就要敲钟上市了，在业内，世界范围内已经有了广泛的社会影响力，已经成为一个新兴行业的风向标之一，很多人都盯着你，你这个公司有任何的风吹草动，新闻从业人员肾上腺激素都会往外狂飙，你的任何一个系统挂了都会影响几亿的用户，产生千万的资产损失，那么问题来了，你的系统还敢随意的挂掉么? 挂掉哪怕1分钟都是给竞争对手的一场狂欢，让自己的公关团队夙夜难眠！好，像这么牛逼的公司你觉得你开始更多的需要考虑的是什么?1个机房，全在H城?那怎么可以?!!且不说地球这么危险，地震、海啸频发，错峰用电、火灾时有发生，有时候周围的化工厂还会爆个炸啥的，有时候就是工地上的铲车看起来都那么可怕，尤其是blueshi(r)t人开的铲车尤其的可怕。好吧，看来你需要在多个城市，多个国家，多个地球上建设很多个机房。有了多个机房万事就OK了么？不，事情其实要比你想象的复杂的多，你的公司的已有应用都在一开始就支持异地容灾能力了么，做架构的都知道无状态的应用可能好一点，但是那些有状态的应用在这一块绝对是重灾区。 再从另一个视角来看这个问题，你的公司再过去的几年发展过程中会有各种的新需求，贵公司会有越来越多的新业务来满足这些新需求，而针对这些新业务当然会有更多的各种系统或者叫应用来满足和服务这些客户，但这些应用就像我们的手指头，并不是均衡的，并不是都一样长，这些系统，用户数不均衡，流量不均衡，耗费的计算资源不均衡，数据重要性、特征分布，容灾能力，跨地域部署能力等等全都不均衡。 某一天你好奇到底有多少个系统，调用链路是怎样的，他们的机房分布是怎样的?想评估一下A地的机房全挂了会影响多少系统，多少流量，产生多少资损? 于是梳理了一下，这下傻眼了，可能是这个样子的:   如果更准确一点的话，这个图其实应该是个动态的jpeg,因为每周都有系统在出生和消亡，有的应用版图在扩大，有的应用版图在缩小，而且从一定程度上来讲，这个图的变化的速度一定程度上反应了贵公司的整个系统跟随业务快速变化的能力和业务的活力，除了应用本身，数据中心每天都有物理机器在崩溃和修复，虚拟化之后更明显。 如果有这么一种负载均衡器，能在宏观上，某个切面上让所有的应用之间的调用满足如下的智能调度策略，将是一个多么美好的事情，而且最好是接入几乎不用怎么让已有的业务做代码的改造，这种改造是多么蛋疼的事情，有经验的平台架构师肯定身有体会，无需赘述。 1、同机房优先 A应用调用B应用，负载均衡器负责调度，如果B应用有跟A部署在同一个机房部署的话，就优先路由到同机房的B。 2、流量打散的容灾需求 昨天同机房的A和B玩的还好好的，但同机房的B应用说没有就没有了，有时候是凌晨睡的正香的时候没有了，手机上报警哗哗的，这时候你就想要是能流量自动打散到最近的机房就好了。 3、贵公司要的是千里之外的容灾，国际化的战略，而用户需要的是毫秒级的请求响应速度，跟随战略，这网络延迟蹭蹭的往上涨，网络质量蹭蹭的往下降，但另一个方面，现在用户的时间碎片化这么严重，毫秒级的延迟就可能导致用户失去耐心全去你的竞争对手的网站上去了，所以如何去弥合所有已有应用之间的跨机房、区域、国家的调用导致这2个方向上的裂隙? 4、你作为老板，想了一下，一个小小负载均衡器挂了，怎么可以影响到所有的业务呢？而作为有梦想的程序猿啊，出来混，系统要”稳“字当头，一个3天2头宕机的系统即使有价值也有限的很，而且很快会被更稳定的系统所替代，所以LB的server挂了还能保障业务继续运行的LB才是好的LB. 七、VIPServer并不完美 作为一个诞生刚几年的家伙，虽然发展确实很快，但它还只是个孩子，我们想说的是不光是用户这样看，其实在我们自己的眼里，它还有很多很多的不足甚至缺陷，但有正明这样的前辈在前面的孜孜不倦、追求卓越的身影，我们这些后辈怎么可以懈怠，尸位素餐，怎么可以不持续改进自己的产品，在国内技术领域的技术积累贡献自己一点微薄的力量呢！《汉书·程序猿传》有云：“今我辈程序猿，上不能匡主，下不能益民，皆可以称之为尸位素餐。” 关注了解更多技术干货:  

案首语: 阿里集团技术大牛，@正明，淘宝基础核心软件研发负责人、LVS创始人、阿里云首席科学家章文嵩博士从阿里离职，去追求技术人生另一段历程，让阿里像我一样的很多热爱技术的工程师都有一丝牵动和感触。 我个人作为一个平凡的一线技术工程师，对章博士是很敬佩的(虽然他还不认识我),国内IT业界这么多年，在底层基石技术层面有所建树，打到Linux标准内核模块层面的应该就LVS了吧，而且就广泛影响力方面，LVS在Linux逐渐取代IBM Aix, Sun Solaris,HPUX 这些Unix们的过程中，扮演了很重要一块的角色，那就是LVS是Linux Cluster的标准解决方案的核心,在我个人看来，X86-64芯片对比Power,Itanium,PA-RISC的更高性价比和Lvs Linux Cluster的方案成熟是互联网时代刚开始兴起的那个时期，在技术准备上，从Unix逐渐走向低端商用机+Linux方案的2把掘墓锄头，虽然不是唯二的2把，但是绝对是其中非常重要的2把,而很多中国人、美国人、欧洲人、日本人...的技术书籍里介绍Linux技术的书籍里，LVS必然会在里面占有一定的篇幅。另外章博士也是国内开源文化的积极的倡导者和真正践行者，我们阿里中间件之所以开源被业界广泛使用的产品(Dubbo,MetaQ,Diamond...)，究其原因，也可以说是深受章博士的影响。 在阿里中间件，我所在的团队恰好是专注在”软负载“（软件负载网络）方面，提供的产品和服务，跟负载均衡产品有很大一部分交集，在集团内，我们的产品VIPServer，可以说跟LVS有一些直面的竞争，在集团内越来越多的业务逐渐从LVS迁往VIPServer上，但正因为如此，所以在负载均衡领域我们对于章博士的江湖地位和影响力才有更深刻的了解。在这个技术人目光再次聚焦在章博士身上的时候，我想借此机会将我们团队对于负载均衡产品这一块的一些思考和实践经验，总结分享给需要的人，希望帮助到正在思考这一块的技术人。也许未来我们永远也不能像章博士这样做出广泛影响世界技术圈的产品，但是作为后辈，我们会看着前辈的身影，追寻着往这个方向一直努力下去。 下面让我们以轻松一点的心情开始: 阿里 Load Balance 之旅 什么是负载均衡（Load Balance） “负载(load)”惹得祸 首先让我们从原点出发。 某一天清晨起床，你突然有了一个美妙的想法，这个想法让你兴奋不已，因为你发现了一个具有广阔市场前景的处女地，这个处女地还完全没有被开垦，这是一项新业务，这项业务能满足世界上大部分人的某个方面他们自己都不知道的潜在的需求，更妙的是，到目前为止，它还没有被任何人发现。你简直被自己的天才惊呆了，被自己的天才想法感动的内牛满面，你确信你的人生会因为这个想法而改变，宇宙也会因为你这个想法而变的大不相同，你确定这个想法的实现将能帮助你走上人生巅峰，上上个时代是比尔盖子，上个时代是拉里配齐，下个时代毫无疑问将是你，你迫不及待的想要将这项业务通过一个系统来表达和实现，于是你奋战了好几个通宵，有了下面这个能支撑这项新业务的非常牛逼的系统: 是的，你的系统已经有了第一个用户，这个用户就是你自己。接下来你将你的系统通过X信朋友圈、钉钉、各大论坛广邀各路亲朋好友试试这个系统，结果是，非常棒! 好评如潮，他们不停的拉自己的亲朋好友开始访问这个系统，因此注册、活跃用户越来越多，此时，你兴奋不已，感觉自己马上就要走上人生巅峰。 但等等，不知道哪里出了问题，你的这个新系统居然上了ccav财经频道，而且被各路媒体小报纷纷报导，瞬间所有人都想看看这个牛逼的系统，于是乎,悲剧发生了: 怎么办？怎么办？很快你想到了3个解决方案。 纵向扩展（Scale Up) 没啥好说的，也许只是服务器还不够NB，买！买！买！宇宙最好的服务器来上一台，可惜，创业刚开始，投资人的钱要花在刀刃上，比如广泛营销上，比如路边扫个码啊，顺便送个内衣啊、牙刷啊什么的，服务器? 买不起! 而且看了一下宇宙上最好服务器的网卡配置，更泄气，这就不是有钱买个NB服务器就能解决的事！ 业务拆分 你仔细审视之后，发现其实你的系统的2个页面是2个不同的业务，用来满足不同的需求的，于是啊，你就想，是不是能把这2个业务分开到2个系统中去，这样用户们自然乖乖的被引导、分流到2个子系统去了，这样每个系统的压力就减少了啊。这就好比一个饭店，生意火爆，原先来吃火锅和吃大饼卷牛排的都在一起，挤不下之后，现在分成了2个店，1个是火锅店，1个是大饼卷牛排店。从某种角度来说，这种其实也是一种负载均衡，但怎么做业务拆分并且通过组织文化和人事架构去保障和适应这种业务拆分，是有很多的业务考量和业务属性在里面的，每个老板和每个行业的答案可能都是不同的，此文讨论的不在这个方向上。 横向扩展（Scale Out）和 副本(Replica) 做完上面的垂直拆分之后，可能你会发现还是不行啊，这世界上拥有独特口味的人太多，吃大饼卷牛排的人还是太多了，怎么办? 开分店吧，每个上档次的商场都开一个大饼卷牛排店，这样每个地域的人又被分流到了附近的店。这个提供一模一样服务的“分店”就是系统的副本（Replica），分布式系统中的副本(Replica)除了满足数据冗余，容灾的需要等之外，横向扩展，通过开多个分店（Replica)分流的行为,就是负载均衡,做到多副本之间分流是一个重要的目的。而这个正是本文讨论的范围所在，如下简图: 接下来, 关于如何让你的系统实现负载均衡，做到Scale Out, 你开始走上选型之路， 常用的负载均衡技术比较 DNS 轮询 DNS本身的机制不再赘述，这里主要看一看基于DNS的负载均衡，其大致原理很清楚，DNS系统本身支持同一个域名映射到多个ip (A记录）,例如 niubility.com. IN A 172.168.1.101 IN A 172.168.1.102 IN A 172.168.1.103 IN A 172.168.1.104 这样每次向DNS系统询问该域名的ip地址时（Tell Me The IP Address of niubility.com.），DNS会轮询(Round Robin)这个ip列表，每次给一个不同的ip，从而达到负载均衡的效果。 来看看这种负载均衡解决方案的优缺点 优点 易于实现 对于应用系统本身几乎没有任何侵入，配置也很简单，在某个文本里多加几行A记录就可以。尤其对于一个基于Web的系统来说更是如此，用户在浏览器里输入的URL host部分天然就是域名，所以在某个环节你必然有起码一台DNS服务器记录着这个域名对应的ip，所以可以说是基于已有域名系统(资产)就做到了负载均衡。 缺点 会话粘连 (Session Sticky) 客户端与目标系统之间一般存在会话的概念（不止是web系统的http session）, 其本质在于server端会或多或少的存一些客户端整个会话期间交互的身份识别以及数据信息，为了防止server端每次都对同一个客户端问一下，你是谁？系统会希望客户端在一个会话期间粘连在某个特定的serer上，除非这个server失败才failover到其它的server上，这种粘连特性对于server处理客户端请求处理的性能和客户端看到的数据一致性是有很大好处的。但是DNS负载均衡不能保证下一次请求会再次落在同一个server上。 DNS解析缓存和TTL带来的麻烦 dns记录的缓存以及缓存失效时间都是个问题，在无线时代，通常来自手机的访问会经过称为行业网关的代理服务器，由于代理服务器会将域名解析的结果缓存一段时间，所以所有经由这个代理服务器的访问请求就全被解析到同一台服务器上去了，因此就可能无法实现均等分配需要处理的请求了。另外在后端集群的拓扑结构(副本数、部署位置、健康状态等)发生变化之后，dns配置的变化要等到网络上所有节点的缓存失效才能反馈出来，这带来的问题起码有2个，1是在等待失效过程中，完全不可控，没有办法加快这个进程，中美切换要花10分钟，因为要等网络所有几点对某些域名的TTL失效，2是滞后，有时候这种滞后是致命的，比如仍然有部分流量打到已经挂掉的那部分服务器上。 容错 一个大型数据中心，每天都有机器坏了是很正常的事情，尤其是在虚拟化大行其道的今天，更是如此，相信你对虚拟主机又崩溃了一个，或者总是被同宿主机的猪一样的队友“挤”死这种情况一定不陌生。dns负载均衡的一大问题就在于这种情况下的容灾很麻烦，一是需要人工干预或者其他软件配合做健康监测，从dns配置中将无响应的机器或者崩溃的机器的相应的A记录删掉。一是删掉之后也要等到所有网络节点上的dns解析缓存失效，在这端时间内，很多访问系统的客户会受到影响。 数据热点 dns是在域名层面做负载均衡，如果从web系统的请求URL角度讲，不同的URL对后端server的压力强度不一样，dns负载很可能会出现所有高强度的请求全都被打到小部分服务器甚至同一台上去了的情况，这个问题的可怕性不在于风险，而在于风险完全不可控。 引入负载均衡器 如图: 客户端 -> LB -> replica1,replica2,replica3 LB负责客户端流量到后端服务集群的分发，一般LB也会负责后端所有server的健康监测，关于健康监测这一块我们在稍后一点再做具体分析。 优点 可以在LB里面做集中的分发逻辑，可以有多种分发方式，例如最常见的Round Robin, Random Robin, Weight-Based Round Robin等。 缺点 LB是单点, 这里其实是有2个问题，下面具体分解一下。 问题1: 所有流量(请求流、响应流）都要经过LB，量太大，LB这小身板扛不住啊，尤其是响应流，一般远大于请求流，为什么? 我们想想一般一个http请求报文大小和响应的报文大小的对比就明白了。 解决方案: 响应流不走LB了！ 问题2: LB是单点啊，挂了，所有流量都损失了 解决方案之一(LB Active-Standby模式): 现在一些LB也会支持Active-Active模式，这里不再介绍。 四层LB vs 七层LB 四层LB的特点一般是在网络和网络传输层(TCP/IP)做负载均衡，而七层则是指在应用层做负载均衡。2者的区别还是比较大的，各有优缺点，四层LB对于应用侵入比较小，这一层的LB对应用的感知较少，同时应用接入基本不需要针对LB做任何的代码改造。七层负载均衡一般对应用本身的感知比较多，可以结合一些通用的业务流量负载逻辑和容灾逻辑做成很细致的负载均衡和流量导向方案，但是一般接入时，应用需要配合做相应的改造。 互联网时代因为流量就是钱啊，所以对于流量的调度的细致程度往往是四层LB难以满足的，所以可以说七层负载均衡的解决方案现在是百花齐放，百家争鸣，中间层负载均衡(mid-tier load balancing)正当其时。 健康检测，负载均衡的伴侣 对于LB或者一个LB解决方案来说，健康检测是LB固有需要一起实现的需求之一，LB要能帮助业务实现业务、服务器、容器的优雅上、下线，帮助业务实现透明的扩容、缩容等一系列很现实的功能，如下简图: 在云计算时代弹性计算(Elastic Compute Service)，按需伸缩(On-Demand Allocation)大行其道的今天，对于LB健康检测方案的灵敏度，准确性，多层次等等都提出了非常高的要求，别看健康检测这个功能貌似很简单，但是实现过程中如果有很多地方没有想到，很容易就造成系统的重大的故障，我们的一些系统在心跳检测上栽的跟头并不少，踩过很多的坑。 为什么我们要做VIPServer？ 在有@正明（章文嵩博士的花名）这样的技术大牛，LVS的原作者本尊坐镇的阿里，为什么阿里会再做一个负载均衡产品?其实很简单，为了解决实际的业务问题。在集团,阿里技术团队常常面临的都是世界级难题，中间件团队更是如此，我们不敢吹牛逼说对这些问题我们解得多好，但我们真的在踏实的认真的解这些问题，而且用我们自己特有的方式，而不是COPY国外技术栈的方式在解这些难题，其实我们很多时候也很想COPY啊，但是放眼全球相关领域确实是没得抄。言归正传，上面我们过了一遍常见的负载均衡方案之后，我们可以发现传统LB，如LVS的解决方案中并不是把所有的问题都已经解决了，我们检视一下，起码还遗留了6个问题: 如果过LB的请求量就大到把LB给打挂了怎么办?互联网的流量，尤其是中国互联网的流量，我们要有足够的自信啊，而且参与过春节买票的，春晚修一修抢红包的都能想象得到。 LB虽然可以有standby的方案或者有小规模集群能力，但如果active/standby同时挂了怎么办? 1个蛋蛋很危险，但2个蛋蛋也未必就多安全。比如在active-standby方案中，既然active撑不住请求流量，那么作为其clone的standby身上当然也不会出现任何奇迹，那么是不是LB前面还应该再架一层LB呢?能不能LB集群全挂了的情况下，不影响正常的业务? 请求方和目标机器之间总是要过一次LB,这在网络链路上是多了1跳，我们都知道多一跳可不光是rt的损耗那么简单，链路上从1跳到2跳，链路和连接出故障的概率也翻了一倍,这要怎么解？ 多机房，多区域的异地多活与容灾，国际化战略的跨国流量的容灾对于负载均衡提出的挑战怎么解，在阿里集团内部，现在断网、断电、断机房的演习如日常喝水、像办公大楼消防演习一样随意，据说要达到，马老师半夜起来上个厕所，顺便断个电的能力，这些容灾场景下业务流量的负载均衡怎么解？ 每次在一些如“秒杀”，“大促”等营销热点场景下，业务为了应对可以预期的流量洪峰，评估LB这一块的容量够不够、要扩多少的痛点又如何解决?LB的弹性在哪里? 成本。虽然LVS比一些传统硬件LB的成本已经有很大的优势，但是在一个大型互联网系统级别的流量和业务发展面前,LVS的使用成本还是太高了一点。 VIPServer就是为了解决这些实际问题而生，所以上面介绍的这些我们耳熟能详的机制全都不是VIPServer解决问题的思路。 VIPServer简介 VIPServer是阿里中间件团队开发的一个中间层负载均衡(mid-tier load balancing)产品，VIPServer是基于P2P模式，是一个七层负载均衡产品。VIPServer提供动态域名解析和负载均衡服务，支持很多诸如多业务单元同单元优先、同机房优先、同区域优先等一系列流量智能调度和容灾策略，支持多种健康监测协议，支持精细的权重控制，提供多级容灾体系、具有对称调用、健康阈值保护等保护功能的解决方案。是阿里负载均衡体系、域名服务体系的一个非常重要的组成部分。目前阿里包括阿里妈妈、钉钉、搜索、AE、1688、阿里云、高德等几乎所有的业务线均在使用VIPServer，在一些重大的项目例如历年双11，支付宝春晚红包项目都发挥了重大的作用。 VIPServer的实现原理，限于篇幅，这里不做详细介绍。 为什么短短几年VIPServer在阿里集团发展的这么快? 讲了这么多平实的技术的东西，让我们接着上面的故事往下叙述，帮助您理解VIPServer为何在发挥越来越重要的作用。我们看看上面的故事中，随着业务的发展还会发生一些什么事，遇到哪些挑战。 现在你的公司已经各方面都已经走上正轨，马上就要敲钟上市了，在业内，世界范围内已经有了广泛的社会影响力，已经成为一个新兴行业的风向标之一，很多人都盯着你，你这个公司有任何的风吹草动，新闻从业人员肾上腺激素都会往外狂飙，你的任何一个系统挂了都会影响几亿的用户，产生千万的资产损失，那么问题来了，你的系统还敢随意的挂掉么? 挂掉哪怕1分钟都是给竞争对手的一场狂欢，让自己的公关团队夙夜难眠！好，像这么牛逼的公司你觉得你开始更多的需要考虑的是什么?1个机房，全在H城?那怎么可以?!!且不说地球这么危险，地震、海啸频发，错峰用电、火灾时有发生，有时候周围的化工厂还会爆个炸啥的，有时候就是工地上的铲车看起来都那么可怕，尤其是blueshi(r)t人开的铲车尤其的可怕。好吧，看来你需要在多个城市，多个国家，多个地球上建设很多个机房。有了多个机房万事就OK了么？不，事情其实要比你想象的复杂的多，你的公司的已有应用都在一开始就支持异地容灾能力了么，做架构的都知道无状态的应用可能好一点，但是那些有状态的应用在这一块绝对是重灾区。 再从另一个视角来看这个问题，你的公司再过去的几年发展过程中会有各种的新需求，贵公司会有越来越多的新业务来满足这些新需求，而针对这些新业务当然会有更多的各种系统或者叫应用来满足和服务这些客户，但这些应用就像我们的手指头，并不是均衡的，并不是都一样长，这些系统，用户数不均衡，流量不均衡，耗费的计算资源不均衡，数据重要性、特征分布，容灾能力，跨地域部署能力等等全都不均衡。 某一天你好奇到底有多少个系统，调用链路是怎样的，他们的机房分布是怎样的?想评估一下A地的机房全挂了会影响多少系统，多少流量，产生多少资损? 于是梳理了一下，这下傻眼了，可能是这个样子的: 如果更准确一点的话，这个图其实应该是个动态的jpeg,因为每周都有系统在出生和消亡，有的应用版图在扩大，有的应用版图在缩小，而且从一定程度上来讲，这个图的变化的速度一定程度上反应了贵公司的整个系统跟随业务快速变化的能力和业务的活力，除了应用本身，数据中心每天都有物理机器在崩溃和修复，虚拟化之后更明显。 如果有这么一种负载均衡器，能在宏观上，某个切面上让所有的应用之间的调用满足如下的智能调度策略，将是一个多么美好的事情，而且最好是接入几乎不用怎么让已有的业务做代码的改造，这种改造是多么蛋疼的事情，有经验的平台架构师肯定身有体会，无需赘述。 同机房优先 A应用调用B应用，负载均衡器负责调度，如果B应用有跟A部署在同一个机房部署的话，就优先路由到同机房的B。 流量打散的容灾需求 昨天同机房的A和B玩的还好好的，但同机房的B应用说没有就没有了，有时候是凌晨睡的正香的时候没有了，手机上报警哗哗的，这时候你就想要是能流量自动打散到最近的机房就好了。 贵公司要的是千里之外的容灾，国际化的战略，而用户需要的是毫秒级的请求响应速度，跟随战略，这网络延迟蹭蹭的往上涨，网络质量蹭蹭的往下降，但另一个方面，现在用户的时间碎片化这么严重，毫秒级的延迟就可能导致用户失去耐心全去你的竞争对手的网站上去了，所以如何去弥合所有已有应用之间的跨机房、区域、国家的调用导致这2个方向上的裂隙? 你作为老板，想了一下，一个小小负载均衡器挂了，怎么可以影响到所有的业务呢？而作为有梦想的程序猿啊，出来混，系统要”稳“字当头，一个3天2头宕机的系统即使有价值也有限的很，而且很快会被更稳定的系统所替代，所以LB的server挂了还能保障业务继续运行的LB才是好的LB. VIPServer并不完美。 作为一个诞生刚几年的家伙，虽然发展确实很快，但它还只是个孩子，我们想说的是不光是用户这样看，其实在我们自己的眼里，它还有很多很多的不足甚至缺陷，但有@正明这样的前辈在前面的孜孜不倦、追求卓越的身影，我们这些后辈怎么可以懈怠，尸位素餐，怎么可以不持续改进自己的产品，在国内技术领域的技术积累贡献自己一点微薄的力量呢！《汉书·程序猿传》有云：“今我辈程序猿，上不能匡主，下不能益民，皆可以称之为尸位素餐。“ 欢迎提出宝贵意见 最后欢迎通过各种方式联系我们，吐槽和给我们提意见，虽然人之本性是不喜欢被吐槽，我们也是，但根据我们的观察，对产品吐槽的厉害的兄弟恰恰是能给我们做产品新的灵感和有高含金量需求的人。

区块链技术指南 邹均　张海宁　唐屹　李磊　等著 图书在版编目（CIP）数据 区块链技术指南 / 邹均等著. —北京：机械工业出版社，2016.11 ISBN 978-7-111-55356-4 I. 区…　II. 邹…　III. 电子商务－支付方式－指南　IV. F713.361.3-62 中国版本图书馆CIP数据核字（2016）第268750号 区块链技术指南 出版发行：机械工业出版社（北京市西城区百万庄大街22号　邮政编码：100037） 责任编辑：高婧雅 责任校对：殷　虹 印　　刷： 版　　次：2016年11月第1版第1次印刷 开　　本：186mm×240mm　1/16 印　　张：17.75 书　　号：ISBN 978-7-111-55356-4 定　　价：69.00元 凡购本书，如有缺页、倒页、脱页，由本社发行部调换 客服热线：（010）88379426　88361066 投稿热线：（010）88379604 购书热线：（010）68326294　88379649　68995259 读者信箱：hzit@hzbook.com 版权所有 ? 侵权必究 封底无防伪标均为盗版 本书法律顾问：北京大成律师事务所　韩光/邹晓东 本书作者 邹均：中关村区块链产业联盟专家、服务合约（Service Contract）方向博士，关注与实践区块链技术与应用。擅长云计算、大数据、软件定义存储。现为海纳云CTO，曾任IBM澳洲金融行业首席软件架构师、多个云计算公司高管，是融智北京高端外国专家。在国际会议期刊发表论文20余篇，获2015年澳中校友会ICT和媒体类别杰出校友奖，区块链相关论文获2016年IEEE ICWS最佳博士论文奖。 张海宁：VMware中国研发中心云原生应用首席架构师，西蒙弗雷泽大学计算机科学硕士，多年软件全栈开发经验，Harbor企业级容器Registry开源项目负责人，Cloud Foundry中国社区最早的技术布道师之一，国内最早的iOS开发者。在VMware公司先后负责开源PaaS平台Cloud Foundry、大数据虚拟化、软件定义存储VSAN等领域的技术布道和解决方案推广。目前着重关注区块链、容器和云计算等领域的研究和开发工作。之前曾担任IBM资深软件工程师、Sun公司资深解决方案架构师等职务。 唐屹：广州大学教授、理学博士，专注于区块链安全与应用、网络信息安全、分布式计算等，为国外知名安全公司开发过椭圆曲线密码软件，获密码科技进步二等奖（省部级）。主持或参与完成多项国家级或省部级自然科学基金与人才计划等重点项目。 李磊：合肥工业大学副教授，Macquarie大学博士。擅长数据挖掘、社会计算、智能计算。获2011年澳洲最优博士论文提名，并多次担任IEEE国际会议的程序委员会委员及组织者。在社会计算和区块链等领域发表论文40余篇，被引用350余次。 刘天喜：深圳拓邦股份有限公司总经理助理，高级工程师、北京大学博士。在移动通信、集成电路、移动互联网、物联网等领域深耕多年，擅长技术产业研究、行业分析和战略规划，主导或参与中国工程院、中央网信办、工信部、国资委等十余项产业研究课题。发表学术论文10余篇。 陈晖：区块链PPk开源项目发起人和主要开发者、巴比特网站专栏作者与区块链技术版版主。对网络与通信技术有深入实践与研究，十余年的软件研发和项目管理经验。通过深度实践以比特币为代表的数字加密货币领域，率先提出“区块链+网络通信”将最大化发挥区块链革命性价值的观点，并着力以开放开源项目的形式推动区块链与网络通信领域融合的技术创新和应用发展。 曲烈：Macquarie大学博士，曾任Macquarie大学研究员、助教。从事信息安全、密码学、区块链、服务计算以及信息系统等领域的研究。多次在国际知名会议和期刊发表论文，并受邀宣讲。 郑晓明：中国电信云计算分公司工程师、Macquarie大学博士，专注于云计算、云存储、监控系统、推荐系统、模式识别等，近期研究区块链相关技术。 序一：什么是区块链 2015年是国外区块链的元年，世界许多重大组织，包括高盛、花旗银行、英国央行、美国央行等机构纷纷在区块链上面投资。大量的投资从2015年10月开始便进入了区块链，原因是在《华尔街日报》刊登一篇的文章，里面报道区块链经过了多次的实验和验证，许多金融机构证实了区块链是一个颠覆性的技术。之前华尔街日报甚至宣称，区块链是最近500年以来在金融领域最重要的突破。而这500年来有多少科技上的突破，但华尔街日报却说区块链是人类历史上在金融领域最大的突破。这可能是因为出现了一个新的货币媒介，而每一次新货币媒介出现，都会引发社会和经济上的重大改革。 2016年1月，英国首席科学家建议英国政府把区块链技术列为英国国家战略，这是区块链历史上一个重大突破，原因是基于华尔街以及金融机构对区块链的评价。但自从2016年1月以后，区块链的评价是基于科学历史悠久的英国官方的评价。从各样指标来看，英国在科学上的建树经常是排名第二，仅次于美国。而世界科学排名第二的英国甚至把区块链列为国家战略，表示区块链的重要性毋庸置疑，而且有深远的影响。能够成为国家战略必须在科学上被验证过，另外还必须带来巨大的商业价值，两者都不可缺少才能成为国家战略。笔者曾在2016年3月拜访英国首席科学家，他们认为，区块链可以在各行各业使用，带来行业公平，例如：诚实报税、政府监管、反洗钱、国家安全等。 2016年可以说是中国区块链元年，因为在2016年区块链在中国受到极大的重视。首先是1月的时候，人民银行宣布要使用数字货币。然后在30日以后，许多中国的组织单位就开始投资区块链。中国许多大学也开始研究区块链技术，大型金融机构都纷纷表态成立区块链团队来研究区块链，区块链的讨论班以及研讨会如雨后春笋一般大量涌现。 但到底什么是区块链？笔者在2015年开始研究区块链，就发现了一件事情：学生们在实验，提出来的区块链模型、算法，或者架构都是有偏差的，而且有时候偏差甚大，例如，在设计私有区块链的时候把公有区块链的全部思想搬过来。结果不像私有区块链，但也不像原来的公有区块链。另外发觉很多人对相关的算法不熟悉，所以有的时候会有一些错误的看法，例如拜占庭将军的问题是一门专门的学问，而区块链只是用了一个近似的算法，若是把两者混为一谈，就会让人感到迷惑。 再加上在讨论区块链时，有时候会有情绪化、宗教化或者政治化的言语出现，原来在数字货币领域，数字货币的先锋常带有一些政治思想，如无政府主义。再加上原来的数字货币过去有洗钱、犯罪的记录，所以在讨论时，有时候会失去焦点。这一点在英国首席科学家的报告里也有提出来，他们认为应该重视区块链，把区块链当做一门科学技术来看，而且是一门有助于经济的科学技术，而不是吹捧任何政治思想，或传递宗教概念。 笔者从今年初开始多次提出应该以系统工程角度来发展区块链技术，例如基于云计算、软件工程、数据库等系统工程技术来开发区块链，区块链不只是一个加密技术或是数字货币，而是一门系统工程。区块链不是某些特殊政治思想的乌托邦，或洗钱的工具，而是一门科学家和工程师可以研究的系统工程，而且这项技术可以成为国家战略，改变各行各业的流程以及基础设施。英国首席科学家已经做出这样的判断，英国央行也做出了类似的决定，英国政府已经派了两位部长来领导这项计划，这就是我们所期 待的。 所以我非常高兴像邹均、张海宁、唐屹、李磊、刘天喜、陈晖、曲烈、郑晓明这些年轻的学者们开始书写区块链技术，因为现在市面上有关区块链的书都是在讲解区块链的概念及应用场景，但是今天描述区块链技术的书却很少。我们希望读者能多了解区块链技术，多发展区块链技术，并且加以应用。只有我们了解区块链技术之后，才能真正理解区块链的意义，而不会随波逐流，人云亦云，并且有自己的判断，希望读者们能够认真读这本书，了解区块链技术，相信必定会大有收获。 蔡维德 美国亚利桑那州立大学荣誉教授，北航区块链实验室主任 序二：区块链——未来已来， 只是尚未流行 比特币诞生于2008年美国次贷危机的末期。在比特币白皮书，即中本聪的论文《比特币：一种点对点的电子现金系统》中，还没有“区块链”这个词，只有“区块”（Block）和“链”（Chain）。一些人为这种超越主权、不会滥发的虚拟数字货币而欢欣鼓舞，开始积极投入到挖矿、炒币中，甚至发行自己的数字货币进行筹资（ICO），俗称“币圈”。而另一些人，包括很多专家和学者，则专注于比特币底层技术，对区块链（Blockchain）技术和应用进行深入地研究，考虑能否将这个技术加以改进，运用到更多的领域中去，俗称“链圈”。 七年之后，以2015年10月美国《经济学人》杂志发表的《信任的机器》（The Trust Machine）的封面文章为标志，大家意识到，作为比特币底层技术的“链”，其价值远大于比特币本身。区块链可以让人们在没有中央权威机构监督的情况下，对彼此的互相协作建立起信心。简单来说，它是一台创造信任的机器。华尔街开始热捧区块链。Gartner发布的2016年技术炒作曲线图表明，当前区块链正处于期望的最高点，即“过度期望期”，这也意味着在未来不久的一段时间，区块链将坠入“期望幻灭期”。人们对区块链的过度期望，实际暗示着对其存在很多误解，其中最典型的有三个，因为其关键词的首字母都是D，所以笔者将其归纳为“3D误区”。 误区一——区块链是一种颠覆性（Disruptive）的新技术 首先，区块链不是一项新技术，而是一个新的技术组合。其关键技术，包括P2P动态组网、基于密码学的共享账本、共识机制（拜占庭将军问题，即一种分布式场景下的一致性问题）、智能合约等技术，都是已经有十年以上的老技术了。但是，中本聪将这些技术很巧妙地组合在一起，并在此基础上引入了完善的激励机制，用经济学原理来解决传统技术无法解决的问题。 其次，这个技术组合虽然有其独到的创新之处，但并非是颠覆性技术，是现有技术的有力补充。目前大部分人已经认同，区块链是“价值互联网”的基础协议，从这个角度看，其地位与当前“信息互联网”的HTTP协议相当，两者都是建立在TCP/IP协议之上的应用层协议，同是互联网的两大基础协议。因而，两者是互补而非颠覆的关系。 最后，这个技术组合，并未颠覆现有业务，而是引入了新的思想，去改善和改造现有业务模式，从而为大众提供更好的、普惠的服务。《华尔街日报》在2015年1月曾发表题为《比特币与数字货币的颠覆性革命》的文章，认为比特币的数字货币发行机制可能“颠覆”目前各国央行的法定货币发行模式，这算是最接近“颠覆”性的区块链案例。而实际上，比特币在经过8年多的发展后，虽然总市值发展到了100亿美元，但在全球经济活动中的比重还是微不足道。与此同时，也确实有一些国家的央行，如英国和中国，在考虑摈弃比特币的挖矿机制后，通过借鉴数字货币的一些机制，在一定范围内实现可跟踪、可追溯、数字化的法定货币。 误区二——区块链就是去中心化（Decentralized）的 首先，很多人认为Decentralized是区块链的核心特征，并将其翻译为“去中心化”。然而这个最早由国内“币圈”所做出的翻译，多少有一点主观和政治化的色彩。作为软件系统的网络架构一般有三种模式：单中心、多中心、分布式。单词Decentralized只是表明不是单中心模式，可能为多中心或弱中心，也可能是分布式的。所以在中国台湾地区，大多将Decentralized翻译为“分散式的”而不是“去中心化的”。 其次，在中本聪的整篇论文中并没有提到过Decentralized，而只有Peer-to-Peer（P2P）。在2016年6月召开的W3C区块链标准会议上，以太坊的核心开发团队EthCore就明确表示，不再使用Decentralized这个词，而是用P2P、Secure、Serverless这类纯技术性词语。 最后，The DAO事件表明，完全去中心化是不可行的。The DAO是一个基于以太坊公有链的众筹项目，它在短时间内就募集了价值1.6亿美元的数字货币，成为史上最大的众筹项目。然而由于其智能合约的漏洞，导致The DAO被黑客攻击并转移走价值6000万美元的数字货币，最后不得不黯然落幕。在挽回这个损失的过程中，原有的去中心化机制未能解决问题，最后还是通过“集中式”的方式，强制以太坊进行“硬分叉”完成交易回滚。但这也导致了以太坊社区的分裂，产生了ETH和ETC这两种同源却又不同价格的数字货币，给以太坊生态系统带来了很多负面影响。此次事件之后，很多人对区块链的“去中心化”进行了反思。前上交所总工、ChinaLedger联盟技术委员会主任白硕则认为“去中心化不是区块链的本质特征”。万向控股副董事长兼执行董事肖风则进一步阐述“区块链的核心是分布式而不是去中心”。 误区三——区块链交易存在很大的延迟（Delay） 在使用比特币进行支付时，一般需要10分钟才能完成一次支付确认。如果要保证支付交易的不可逆转，通常需要等待连续的6个数据块完全确认，这至少需要1个小时的确认时间。而我们通常使用的银行网银支付和第三方支付，通常都是秒级完成的。与之相比，使用区块链的比特币支付实在太慢。 然而，我们再考虑一下跨境支付的场景，当我们使用Swift完成一次跨境汇款时，通常需要3～5个工作日，对方才能收到相应的款项。而使用比特币进行跨境汇款，仅仅需要一个小时就能收到汇款。如此比较起来，比特币支付已经是非常快了。 为什么有两个完全不同的结论？因为，对于比特币支付来说，支付确认过程即是清算和结算的过程。如果把支付过程和清结算过程作为一个整体，来比较两类支付的延迟时间，使用区块链进行交易还是很快的。区块链交易的本质，是大幅减少了交易后的处理工作，消除了大量的人工干预过程，从而提高了交易效率。 通常我们把区块链分为公有链、私有链、联盟链三种，比特币和以太坊都属于公有链范畴。在数字货币之外的场景中，尤其是在金融领域中引入区块链技术，将面临很多问题。如何引入以及引入哪种区块链，还存在许多权衡决策方面的障碍。 第一，主流金融机构难以接纳公有链。R3发布最新研究报告，证明公有区块链不可作为金融机构解决方案。2016年Swift发布白皮书指出，当前世界主流金融机构无法接纳公有区块链。对于这些金融机构而言，需要的是一个自主可控的系统，而公有链显然做不到这点。 第二，私有链与公有链架构差异大。笔者曾仔细分析了以太坊和超级账本这两个典型区块链的模块结构，发现两者差异巨大。很多公有链的核心模块，如挖矿、PoW共识、原生货币等，在私有链环境中是完全不必要的，甚至是有害的。与此同时，公有链系统中还缺失一些诸如身份认证、权限管理等在私有链中必要的模块。以太坊创始人Vitalik也曾坦言，只有5%的以太坊程序可被金融领域使用。 第三，私有链和联盟链还很不成熟。目前，以比特币和以太坊为代表的公有链相对比较成熟，而私有链和联盟链则远远不够成熟。开源而且好用的联盟链，更是不存在。目前全球影响力最大的开源联盟链，是Linux基金会下面的超级账本（Hyperledger）项目，目前已有95个成员单位。旗下的Fabric子项目是以IBM捐献出的OpenBlockchain为主体搭建而成的，目前还处在0.6版的快速迭代过程中，到0.8将是Alpha版，而0.9则是Beta版，再经过3个RC版本之后，才会进入相对成熟的1.0版。 想要找到或研发出一个成熟稳定的、适合金融领域的联盟链底层系统，还任重道远，需要很多仁人志士的共同努力，踏踏实实地投入到区块链的基础研究中去。 在目前已出版的区块链书籍中，有很多都冠以“革命”、“重塑”、“重新定义世界”等煽动性词语作为书名，这更像是一种口号，而非切合实际的研究。我很高兴地看到，还有像邹均、张海宁、唐屹、李磊、刘天喜、陈晖、曲烈、郑晓明等这些研究者们，在踏踏实实地研究区块链底层技术，用普实的话语来介绍和普及区块链技术，让更多的人了解和接受区块链技术，实实在在地让人们了解区块链技术特征和特点，以及在现阶段环境下的不足，如何去改善这些不足等。知己知彼，方能百战不殆。世上没有“银弹”，没有哪一种技术能解决所有的问题。 希望读者们能够通过本书，深入地了解区块链技术。也只有深入了解其底层运作机制和原理，才能更好地灵活运用该技术，取得理想的效果。 未来已来，只是尚未流行，我辈仍需多努力。 张斌，联动优势科技有限公司CEO 序三：区块链——连接虚拟与现实 我们对于一种新兴的技术，往往会在短期内对它有过高的不切实际的期望；泡沫破灭后，在长期的时间轴线上，又往往会忽视它的深刻影响，这一句话，用在区块链上，再合适不过。 区块链的发明，是建立在互联网之上。其所使用的技术，像P2P、分布式存储、分布式密钥的思想，十几年前就已经存在，但是如果没有中本聪那一篇开创性的关于比特币的白皮书，所有这些强大的工具，都还只是埋藏在学术论文堆里。因为这些工具单独使用，并不能解决问题，只有中本聪，出人意料地提出了一个系统性的、可供实践的解决方案。如果他能提前十年提出这篇论文，那么比特币就可以提前十年发明出来。所以，单个技术点，并非是区块链的魅力所在，运用这些技术的全新思想，才是区块链的本质和核心。 单纯把区块链等同于一种分布式数据存储技术，就像将浏览器说成是一个网页解释器，将手机说成是一台手持电话，将云计算说成是一个服务器的集群一样，说了等于没有说，甚至比没说更糟糕，更容易造成误解。当全球的用户都打开浏览器访问网页，当街上每一个人都携带着一台能拍照、能上网、带GPS，运算性能可以发射登月火箭的智能手机，当我们所有的工作和生活数据都发生与存储在云上的时候，我们看到在浏览器、移动互联网和云计算上所承载的产业生态，跟最初的技术描述相比不知道差了多少万里。所以有人让我用一句话解释什么是区块链的时候，我往往会争取机会多说几句，争取让人更多了解一点。 从功能上说，互联网实现了信息的传播，而区块链实现了价值的转移。互联网在最开始的时候，就是以信息传输管道的模式进行的设计，TCP?/?IP协议底层并不关心上面传输的数据有什么差别——对于底层的交换机和路由器来说，一切都是0和1而已。无差别的信息传输，创造了信息复制的便捷通道，也造就了今天信息爆炸的信息社会。但是互联网虽然解决了信息传播的问题，却带来了信息权属的新问题，我们可以将一首歌曲或者电影，在几个小时内传遍全球，我们却不能知道，究竟是谁拥有这部电影的权利，是通过什么样的路径进行的传播。而区块链则可以做到，我将一个数据，发送给另外一个人之后，我自己就不再拥有这个数据的所有权，从而实现了可以利用一个虚拟的系统，来传输实际的价值。 从机制上说，如果说TCP?/?IP是机器与机器之间的通信协议，而区块链就是机器与机器之间的信任机制和合作协议。对于不需要验证真假的信息传输来说，TCP?/?IP已经足够可用，但是一旦属于不同实体的计算机，需要彼此之间进行自动化的沟通和合作的时候，问题就会变得相当复杂。现实世界公司与公司之间的合作，有律师和合同来进行条款约定，有执法机关来保障合同的实行，而在虚拟世界，计算机没有办法开设银行账户，属于不同实体的计算机，也没有办法去法院起诉对方，因此在沟通和合作的时候，一定要有一种有效的机制，来快速实现共同协作。区块链就可以起到这样一个作用，所以在区块链行业中有一句话：代码即法律（Code is the Law）。未来不管我们的生活还是工作，都会有越来越多地需要计算机参与，人类将整体进入后人工智能时代，区块链就是在为这个时代的到来进行前期的铺垫和准备。未来我们将会看到无人驾驶汽车，通过区块链协议自动缴纳过路费用；智能投资顾问自动为我们计算各种投资组合；未来最先进的金融公司，也会像现在的无人工厂一样，看不到太多工作人员，只有无数的计算机，在快速地缔结无数的智能合约，进行精确到小数点后的资产配置。 因为区块链的以上属性，区块链将会是连接虚拟世界与现实世界的最佳桥梁。在未来，区块链所连接的，不会像比特币一样是无法辨别的匿名账户和价值不定的虚拟资产，而将会是千千万万真实存在的个体和公司实体。上面所承载的资产，都将具有现实的价值和对应物，而这个虚拟的网络上发生的一切，也都会直接作用于现实世界。这一过程，需要的不仅仅是单纯的技术，还需要金融、商贸、法律、政府等各方面专家和人才凝聚在一起，来保证这一映射的有效性，也是我们一直在努力推进区块链生态系统和可信区块链概念的原因。区块链有巨大的潜力和未来，而这些潜力和未来，需要社会的共识与力量来共同推进和实现。 邓迪 太一云科技有限公司董事长兼CEO 序四：区块链——转型之擎 邹均先生在国内外企业的IT架构、云计算、大数据、IT产品创新方面有很多年的经验，邹均本人也是我多年的好朋友和同亊。这次邹均先生主写的这本区块链的书，相信一定会在IT业内，特别是在企业IT架构圈内产生巨大的反响，一定会深受广大区块链爱好者、参与者、实践者的热烈欢迎。 我和邹均先生工作背景相似，曾经从事过多年企业IT工作，从2009年开始，做云计算的创新，近年来也做金融科技的创新。从我这一年多时间的区块链的实践中，我个人看到区块链目前虽然还在发展初期，而每天区块链技术都有新的变化和突破，每天都是“山雨欲来风满楼”。但是区块链这样一个意义重大的技术，对整个IT的架构、基础协议、标准、运营、环境具有颠覆性的意义。因此我们应当充满紧迫感，应当预先了解区块链技术、商业模式和发展趋势，加强与国内外各界的合作，特别是在区块链的底层领域、区块链的平台领域和区块链的应用领域的合作，我们应当在区块链的全球协议和标准方面要占据主动。 区块链技术具有全新的理念和逻辑结构，并且它每天还处在发展变化过程中，因此区块链技术与应用在企业内不可能单打独斗，区块链的应用必须在企业架构中上着天、下着地，和企业现有的应用系统相互关联。我们不应该简单地把区块链理解为一项技术，而应当考虑它在更高的企业IT架构转型层面的作用。区块链的应用不是简单地提供一个只能追加、不能更改的分布式数据库解决方案，而是要把区块链与云计算、大数据和传统企业的系统相互关联，使得企业系统由原来的传统系统和云计算这种“双核驱动”转变为传统系统、云计算与区块链的“三核驱动”，让企业的异构系统更好地发挥协同效应，一起解决原来传统IT系统难以解决的问题，这样才能更好地发挥区块链的独特性，才能够使传统企业IT架构更好地转型。 本质上，因为区块链链与链之间具有隐私、安全、共识、自治、价值共享的特性，所以在技术层面解决了互联网上的价值传递问题。同时，区块链又具有底层开源和改变业务规则、创新业务多方共识等逻辑，因此区块链是未来整个IT架构和互联网转型的重要支撑。而企业与互联网IT架构的转型也为未来经济的转型、服务模式、信用交换和商业规则的转型提供了关键支持，因此研究和应用区块链不仅要研究技术，更要注意在互联网时代赢者通吃的规则，重要的是要研究和应用区块链带来的商业规则的改变。 以前我们的信息化，不管是企业信息化、政府信息化，还是个人信息化，实际上都侧重在机构内部的信息化。这几年随着互联网、云计算、大数据、平台经济的蓬勃兴起，现在IT正在促使企业由内部信息化转型为外部信息化，最终通过平台转型为信息化的企业，由政府信息化转型为信息化政府，由个人信息化转型为信息化个人，这些词虽然相似，但性质具有很大的不同。它们在逻辑关系、业务处理方式、信息的确权、信息的使用、组织流程的改变、企业治理结构方面有很大不同，信息化已经不再是工具、手段和渠道。这样一个信息化平台的升级，未来会使得实体经济更好虚拟化，使得虚拟经济更好地结合实体化。 实施区块链既需要具有传统IT系统的经验，也需要有互联网、云计算、大数据的实施经验，需要对整个IT系统变迁具有很强的洞察力，需要把整个IT系统协同起来，让整个IT系统互联互助，相互合作。因此，区块链系统在企业的应用，必然需要结合本地的实践，发挥原创的精神，必然还要有互联网时代产品开发的能力。而做一个好的区块链应用更需要研究共享经济理论、价值互联网和金融科技的创新与发展。这一切都需要在区块链理论与研究方面走到前列。 因此，我希望邹均先生等人写的这本区块链的书籍，会连接IT架构的过去、现在与未来，开启大家创新的热情，会对行业产生影响，同时为大家开启一扇协同企业传统系统、云计算、大数据和区块链新的大门。 黎江 北京世纪互联创新研究院院长 前言 为什么要写这本书 1900年9月8日，一场4级强度的飓风横扫德克萨斯州的加尔维斯顿。这个位于墨西哥湾的岛城，靠近德克萨斯海岸，在灾难来临前拥有37?000人口和光明的经济前景。飓风猛烈攻击了这个毫无防备的低海拔城市，给该市带来了巨大的毁坏。飓风风速为每小时225千米，毁掉了3600座建筑，使占整个城市3/4的12个街区彻底消失，死亡人数为8000～10?000人。是迄今为止，美国历史上死亡人数最多的自然灾害。 而2016年8月2日在中国华南沿海登录的“妮妲”台风，风力14级，最高风速每小时151.2千米，台风过境的广东、广西、湖南、贵州、云南5省（自治区），虽然也造成了重大经济损失，但在人员伤亡统计报告中，只有1人失踪。 这两次自然灾害的结果如此不同，归功于人类掌握了计算这个神奇工具。在妮妲形成过程中，美国、日本、中国气象监控部门就不断跟踪，通过监控数据，气象数学模型和强大的计算能力，对台风进行了准确的预报和预警。在台风到来前，有关部门做了积极准备，7.6万人得以紧急转移安置，使得损失得以降到最低。 今天，IT已经渗透到各行各业，人们已经能近距离接触无人驾驶、机器人、虚拟现实（Virtual Reality）、增强现实（Augmented Reality）等先进技术，当人们在享受IT给人们生活带来的各种便利和好处的时候，也日益感受到来自不当使用科技所带来的挑战。例如，国内日益猖獗的电信诈骗，全球范围内黑客的攻击和安全勒索，以及未来基因技术和AI（人工智能）技术给人类所带来的伦理、生活和工作方面的全方位冲击，都使得有识之士开始思考如何应对科技发展所带来的风险。 一直以来，笔者对计算技术有一种既感恩又敬畏的情结。首先感恩我们的时代，计算技术的发展使我们避过很多前人无法避过的灾难；但高速发展的计算技术必然导致机器的智能超过人类自身，因此而产生的未来不确定性也使笔者的敬畏之心油然而生。 笔者也一直有一个预感，未来可能需要针对IT，特别是与业务结合紧密的云计算和智能设备建立监管、问责的机制。笔者的意思不完全是对从事IT或智能设备的人进行监管问责，甚至要考虑对智能设备进行自动问责。这个看似荒谬的想法促使笔者选择了云计算的问责机制（Accountability in Cloud Services）作为博士研究方向。 所谓云计算的问责机制（Accountability），指的是在云计算架构中，能建立一个自动化的问责机制。该机制包括形式化的标准服务合同定义，服务合同的发布，服务合同执行的监控，合同违约方的自动发现，违约方的罚则和执行，以及合同双方争议的仲裁。举个例子来说，今天公有云的提供商，都没有提供能让电脑理解的云服务合同。合同双方的责任、义务和权利没有精确的界定；云服务提供商的服务好坏，是否遵从合同，都没有自动化的方法去检测；服务故障责任也没有办法界定；出现争议也只能靠人工去解决。而云计算的问责机制，旨在建立一个自动化的体系来让电脑自动规范电脑的行为。 可想而知，这个研究课题非常有挑战。在博士研究的过程中，笔者也走了很多弯路，一直没有找到好的解决方法，直到三年前接触到比特币，突然意识到区块链技术是提供问责机制的最理想平台。这是因为区块链技术中的防伪、防篡改、交易可追溯、数字签名和智能合约技术提供了一个公正、可问责（Accountable）、自动执行的技术平台基础。 但是区块链目前还停留在概念炒作阶段，很多关注点还停留在金融应用，特别是虚拟货币方面的应用。笔者认为，区块链未来可能最适合作智能设备的“警察”，为物联网和智能设备的自治管理提供一个基础平台。区块链技术应该推广应用到除金融外的行业，因此萌生了写这本书的念头，作为博士研究工作的一个延续。 而写这本书的另一个原因，也是深感在学习区块链技术过程中碰到的参考资料不足的痛苦，希望能整理过去的学习所得，对区块链初学者有所帮助。 从2008年中本聪发表比特币白皮书算起，区块链技术才走过短短8年的时间。虽然区块链1.0、2.0和3.0的架构理念已经提出并得到一定程度上的认可，但区块链的技术发展仍然处于初级阶段，区块链的应用还刚起步，成熟的区块链应用除了比特币系统，还寥寥无几。在这种情况下写关于区块链的书籍，其实面临一个两难境况。一是区块链的技术变化快，像个移动的靶子；可供参考的资料又少，要准确把握一个快速变化的技术非常困难，而且受限于写笔者的水平，实践经验，写出来的书难免有很多错误，弄不好会贻笑大方。而另一方面，正因为变化快，资料少，广大区块链技术爱好者又渴望能找到一本对他们学习、理解、掌握区块链架构和技术有所帮助的书。 目前在市场上的区块链书籍大致分为两类：一类是以梅兰妮·斯万（Melanie Swan）的《区块链：新经济蓝图及导读》为代表的，谈区块链对整个宏观层面所带来的革命性影响的战略性书籍；一类是以安德鲁·安东普洛斯（Andreas M. Antonpulos）的《精通比特币》，以及普林斯顿大学以阿文·拿瑞延南（Arvind?Narayanan）为首编著的《比特币和密码学技术》为代表的专注于比特币的技术性书籍。这些书籍满足了目前市场上一部分对区块链在行业中的应用有兴趣的偏业务的人士，以及对比特币技术有兴趣的偏技术的人士的需求。 在这两类书籍所覆盖的市场中，其实还有一个很大的空白。我们发现，在对整个区块链架构（包括区块链1.0、2.0和3.0）进行系统性剖析，包括对其中关键技术（密码学、共识算法）等进行系统性论述，对不同的区块链架构形式（联盟链、公共链、私有链、侧链、多链、互联链等）进行系统性介绍的书好像还没有。而这样的书对理解、普及区块链技术，推动区块链应用落地可能会有所帮助。因此，与其等待这样的书籍出现，不如自己行动，为区块链技术的推广尽绵薄之力。笔者也就自不量力，把可能被同行笑话的风险置之脑后，鼓起勇气集合几个对区块链着迷、志同道合的朋友，在条件不成熟，时间比较仓促的情况下，经过不少不眠之夜的努力，克服重重困难，特别是在机械工业出版社华章分社编辑高婧雅的大力协助下，完成了该书。 本书的缺点是显而易见的。 一是因资料匮乏、技术变化快而难免出现技术错误。因此，本书的目的，主要是抛砖引玉，欢迎读者多提宝贵意见，争取在下一版本能纠正大部分的错误，不断完善、提升本书的质量。 二是缺少应用案例。其实目前网上的应用案例也有不少，但是我们认为，如果只是拿别人在网上的案例加工修改，从深度、广度方面都经不起推敲，起不了真正案例的作用。除非由真正落地该应用案例的主要负责人来写，才能使读者有真正的收获。受限于我们的人脉圈子和条件，目前只能请到PPKpub.org开源社区组织者陈晖先生来写一个区块链在标识注册方面的应用案例。在此鸣谢陈晖先生的大力支持，将来也欢迎有更多的区块链应用的领军团队提供应用案例，在未来更新的版本中补上在应用案例方面的短板。 本书特色 1）和目前市场上主流的区块链书籍强调区块链去中心化的概念，以及对业界带来的革命性影响不同，本书主要是从技术的角度，介绍区块链的基础概念，特别是对区块链的架构进行了详细的剖析。 2）对区块链的关键技术，包括区块链架构（1.0、2.0、3.0）、密码学和共识算法等做了一个详尽的介绍。 3）提供了比特币开发指南，通过以太坊智能合约开发来帮助初学者入门。本书也用专门一章来讨论区块链的常见问题，包括对近期发生的DAO攻击事件，都有详细的分析。 4）在区块链技术落地方面，本书也提供比较典型的区块链解决方案，包括支付和标识登记方面的解决方案。 5）以独特的架构演进对IT发展的影响为切入点，给读者展示一个全新观察整个IT历史的视角，并在这个视角下探讨区块链技术在未来IT发展中的影响和地位。 本书中一些实操的例子和章节，比较适合区块链初学者和程序员，可以成为区块链入门的书；架构剖析和深入分析方面的章节，比较适合IT架构师，以及区块链技术爱好者来深入了解区块链架构特点和技术细节，对设计区块链的解决方案有所帮助；解决方案和常见问题章节有助于区块链从业人员全面了解区块链应用落地方面的情况。最后一章是从架构视角对IT发展的一些观察，仅供喜爱思考的IT从业者参考。 读者对象 区块链从业者 IT架构师 区块链应用开发人员 对区块链技术感兴趣的人员 如何阅读本书 本书分为三大部分，共11章。 第一部分介绍基础和入门，包括以下2章内容。 第1章　本书的开篇，首先介绍区块链的定义和特点，并简单介绍了区块链的主要类型，然后通过介绍购买、存储和交易比特币等实际使用场景来让读者对区块链有所体验，然后再探讨一些关于区块链的常见问题。 第2章　介绍区块链的基础概念，为后面深入介绍区块链技术做铺垫。 第二部分介绍架构和核心技术，包括以下8章内容： 第3章　详细介绍区块链1.0、2.0、3.0典型架构，同时介绍了互联链的概念和架构。 第4章　详细介绍了区块链涉及的密码学原理和典型的算法。 第5章　介绍了在区块链架构中常用的共识算法。 第6章　提供比特币开发指南，通过实际案例来帮助初学者入门。 第7章　提供以太坊上的智能合约开发指南，帮助初学者掌握智能合约的开发要领。 第8章　详细介绍HyperLedger开源项目及其架构。 第9章　讨论区块链上常见的问题，包括最近出现的The DAO攻击的源码级分析。 第10章　讨论区块链上的典型解决方案，一个是以闪电网络为主的支付方案，另一个是以标识登记为主的开源ODIN解决方案。 第三部分为回顾和展望，即第11章，主要回顾IT架构演进历史并展望未来区块链对IT发展的影响。 勘误和支持 由于笔者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。如果你有更多的宝贵意见，欢迎通过微信或邮件进行讨论。你可以通过微信joezou3986、微博@云中君3986，或者发送邮件到邮箱joezou@openstack.org.cn联系到我，期待能够得到你们的真挚反馈，在技术之路上互勉共进。 致谢 首先感谢我的作者伙伴——张海宁先生、唐屹教授、李磊教授、刘天喜博士、陈晖先生、曲烈博士和郑晓明博士。他们在工作之余，挤出宝贵时间为本书贡献了他们对区块链技术的理解和洞察。特别感谢我的大学同门师弟Henry张海宁先生在关键时刻的出手相助，为本书贡献了很多精力，他不单在内容上积极供稿，也在本书的审定、修改和校正方面下了很多工夫。唐屹教授和李磊教授也在繁忙的教学和学术研究中抽出时间来对一些区块链的基本概念和关键技术（包括密码学和共识算法）做了详尽的阐述。刘天喜博士在本书的框架规划和开篇设计上做了很大贡献。而陈晖先生的比特币开发指南对很多初学者入门有很大的帮助，他的ODIN开源项目也是区块链登记方面的一个典型解决方案。曲烈博士的智能合约开发章节给众多以太坊开发初学者提供一个易懂、易上手的应用指引。郑晓明博士也对主流代币做了比较全面的介绍。 本书作者也得到中关村区块链联盟的大力支持，在此也特别鸣谢中关村区块链产业联盟秘书长王安平先生、副秘书长范金刚先生和林大鹏先生以及联盟发展部张培部长。同时也感谢江源老师、江苑绛博士，他们的鼓励成为我坚持下来的动力。另外在写书过程中也得到澳洲富士通区块链技术架构师董仲利先生、信达证劵区块链首席专家曹寅先生、亚投行企业IT项目管理专家Allen邵以及合肥工业大学刘古刘和方辉先生的帮助，在此对他们表示感谢。 另外感谢比特币开源社区、以太坊开源社区，以及巴比特社区的各位技术专家们的博客文章，每次阅读必有所获，本书也多处引用了他们的观点和思想。 非常感谢机械工业出版社华章公司的编辑高婧雅，她的敬业精神和编辑效率令我由衷敬佩，她的反馈、建议、鼓励和帮助引导我们克服诸多困难完成全部书稿。 特别致谢 最后，因为工作和写书，牺牲了很多本该陪伴家人的时间。我要特别感谢我的母亲从小对我的培养，也要感谢我的哥哥姐姐们在儿时营造的和睦互助、求知好学的家庭环境，这对我长大以后形成对新兴技术浓厚的求知欲性格有很大影响，一直以来在我的职业生涯中都受益匪浅。更要感谢我太太Annie长期以来对我的默默支持，以及女儿Beverley，儿子Skyler对我工作的理解。 谨以此书献给我最亲爱的家人，多年以来帮助、支持我的师友们，以及众多热爱区块链技术的朋友们！ 我想和作者聊聊 如果你想和本书作者沟通，可以通过以下方式。 1）微信群“区块链技术交流群”，添加群助理微信号xiaodanmyd入群。 2）QQ群“区块链技术交流群”，群号375936045。 3）关注微信公众号“链信Chain2Trust”。 4）邹均微信号：JoeZou3986，添加请注明沟通事项。 邹均 目录 本书作者 序一：什么是区块链 序二：区块链——未来已来，只是尚未流行 序三：区块链——连接虚拟与现实 序四：区块链——转型之擎 前言 第1章　区块链和比特币初体验  / 1 1.1　区块链简介  / 1 1.1.1　区块链起源——比特币  / 1 1.1.2　区块链和区块链技术的涵义  / 2 1.1.3　区块链分类  / 2 1.1.4　区块链价值与应用  / 7 1.2　区块链体验  / 10 1.2.1　获取比特币的3种途径  / 11 1.2.2　通过交易所购买比特币  / 13 1.2.3　比特币钱包和地址  / 17 1.2.4　从交易平台提取比特币到钱包  / 20 1.2.5　比特币交易查询  / 22 1.3　本章小结  / 22 第2章　区块链基础  / 24 2.1　区块链技术  / 24 2.1.1　基本概念  / 25 2.1.2　框架与特点  / 32 2.1.3　区块链运作的核心技术   / 35 2.1.4　区块链交易流程  / 41 2.2　以太坊  / 42 2.2.1　什么是以太坊  / 42 2.2.2　以太坊技术  / 43 2.2.3　以太坊智能合约  / 48 2.2.4　以太坊的去中心化应用  / 50 2.3　基于区块链的电子货币  / 51 2.3.1　元币平台  / 51 2.3.2　代币  / 52 2.3.3　货币的未来  / 58 2.4　本章小结  / 58 第3章　区块链架构剖析  / 59 3.1　基本定义  / 59 3.2　区块链1.0架构：比特币区块链  / 61 3.2.1　比特币前端  / 63 3.2.2　比特币节点后端  / 66 3.3　区块链2.0架构：以太坊区块链  / 79 3.4　区块链3.0架构：超越货币、金融范围的区块链应用  / 87 3.5　互联链架构剖析  / 90 3.5.1　互联链背景  / 90 3.5.2　互联账本  / 91 3.5.3　互联账本协议组  / 92 3.5.4　互联账本各层协议关系  / 95 3.6　本章小结  / 96 第4章　区块链中的密码学技术  / 97 4.1　哈希算法  / 97 4.1.1　哈希函数的性质与应用  / 99 4.1.2　哈希指针链  / 101 4.2　Merkle树  / 102 4.3　公钥密码算法  / 103 4.3.1　椭圆曲线密码算法  / 104 4.3.2　secp256k1椭圆曲线  / 105 4.3.3　椭圆曲线签名与验证签名   / 106 4.4　本章小结  / 107 第5章　共识算法详解  / 109 5.1　拜占庭容错技术  / 109 5.1.1　拜占庭将军问题  / 110 5.1.2　拜占庭容错系统  / 112 5.1.3　实用的拜占庭容错系统  / 112 5.1.4　Raft协议  / 114 5.2　PoW机制  / 116 5.3　PoS机制  / 122 5.4　DPoS机制  / 123 5.5　Ripple共识算法  / 124 5.6　小蚁共识机制  / 126 5.7　本章小结  / 127 第6章　比特币应用开发指南  / 129 6.1　以虚拟机方式搭建应用开发环境  / 129 6.1.1　下载和安装Oracle VM VirtualBox  / 129 6.1.2　以虚拟机方式安装Ubuntu14.04  / 133 6.1.3　安装Node.js开发环境  / 138 6.1.4　安装Docker运行环境  / 138 6.1.5　安装和运行比特币测试网络  / 139 6.1.6　运行第一个示例程序  / 141 6.2　把握比特币“交易”数据结构  / 145 6.2.1　了解比特币的“交易”数据结构  / 145 6.2.2　交易记录的实例解析  / 146 6.2.3　运行示例程序  / 148 6.3　实战：多重签名交易  / 153 6.3.1　将ODIN标识注册到区块链上的实例解析  / 153 6.3.2　运行示例程序  / 156 6.4　本章小结  / 157 第7章　智能合约  / 158 7.1　智能合约简介  / 158 7.1.1　什么是智能合约  / 158 7.1.2　智能合约的历史  / 159 7.1.3　智能合约的优点和面临的风险  / 160 7.2　以太坊智能合约详解  / 161 7.2.1　以太坊上的账户  / 161 7.2.2　以太币和Gas  / 166 7.2.3　合约和交易  / 167 7.3　以太坊虚拟机  / 170 7.4　实例：在以太坊上开发实施智能合约  / 173 7.4.1　通过以太坊钱包部署智能合约  / 173 7.4.2　通过控制台部署智能合约  / 179 7.5　本章小结  / 183 第8章　超级账本项目  / 184 8.1　超级账本项目简介  / 184 8.1.1　项目背景  / 184 8.1.2　项目管理形式  / 185 8.1.3　项目的生命周期管理  / 186 8.1.4　项目发展状况  / 187 8.2　Fabric项目  / 187 8.2.1　项目概述  / 187 8.2.2　应用场景  / 188 8.2.3　项目架构  / 189 8.2.4　部署方式  / 191 8.2.5　交易的执行  / 192 8.3　Sawtooth Lake项目  / 193 8.3.1　项目概述  / 194 8.3.2　项目架构  / 194 8.4　本章小结  / 196 第9章　区块链常见问题  / 197 9.1　钱包的安全性问题  / 197 9.2　加密货币的交易方式  / 199 9.3　匿名性和隐私性  / 201 9.4　矿池算力集中的问题  / 203 9.5　51%攻击问题  / 205 9.6　去中心化的自治组织  / 207 9.6.1　去中心化的自治组织简介  / 207 9.6.2　The DAO项目  / 208 9.6.3　代码漏洞分析  / 210 9.6.4　解决方案  / 213 9.6.5　软分叉和硬分叉的影响  / 215 9.6.6　重放攻击   / 216 9.7　本章小结  / 219 第10章　区块链应用案例分析  / 220 10.1　闪电网络  / 220 10.1.1　闪电网络简介  / 220 10.1.2　支付通道的创建  / 221 10.1.3　支付通道的更新  / 223 10.1.4　支付网络的构建  / 223 10.1.5　支付通道的关闭  / 225 10.1.6　小结  / 226 10.2　ODIN：用区块链来替代DNS  / 226 10.2.1　ODIN简介  / 227 10.2.2　实现功能  / 228 10.2.3　主要特点  / 229 10.2.4　ODIN标识编码格式  / 229 10.2.5　ODIN标识技术规范  / 232 10.2.6　使用示例  / 233 10.2.7　开放资源  / 234 10.2.8　问题与思考  / 234 10.3　本章小结  / 236 第11章　从架构变革看IT时代的演进  / 237 11.1　架构心得  / 237 11.1.1　架构和技术的关系  / 237 11.1.2　关于计算的观察  / 238 11.1.3　架构创新的神奇力量  / 238 11.1.4　冯·诺依曼架构  / 239 11.1.5　哈佛体系架构  / 240 11.1.6　有影响力架构的特点  / 240 11.1.7　从非生物计算到非生物智能  / 241 11.2　架构创新——IT发展源源不断的动力  / 242 11.2.1　大中型机时代  / 243 11.2.2　开放时代的到来  / 243 11.2.3　客户端/服务端（CS）分布式时代  / 243 11.2.4　互联网时代  / 244 11.2.5　云计算、大数据时代  / 246 11.2.6　互联网+时代  / 250 11.2.7　区块链+时代  / 252 11.3　未来展望  / 254 第1章 区块链和比特币初体验 区块链（Blockchain）是近年来最具革命性的新兴技术之一。区块链技术发源于比特币（Bitcoin），其以去中心化方式建立信任等突出特点，对金融等诸多行业来说极具颠覆性，具有非常广阔的应用前景，受到各国政府、金融机构、科技企业、爱好者和媒体的高度关注。 在本章中，我们首先介绍区块链的定义和特点，然后通过介绍购买、存储和交易比特币等实际使用场景来体验区块链，最后再探讨一些关于区块链的常见问题。 1.1　区块链简介 2016年1月20日，中国人民银行官方网站上发表了一条题为《中国人民银行数字货币研讨会在京召开》的新闻[1]，这一消息迅速在各大主流新闻媒体和比特币、区块链爱好者社区中传播，成为推动区块链技术在国内迅速升温的“导火线”。这是自从2013年12月5日中国人民银行、工信部、银监会、证监会和保监会五部委联合发布《关于防范比特币风险的通知》[2]以来，相关首次公开对比特币底层技术——区块链技术给予了高度评价。 在我们开始区块链体验之旅之前，让我们简要介绍区块链的定义和其发展历程。 1.1.1　区块链起源——比特币 区块链的英文是Blockchain，字面意思就是（交易数据）块（Block）的链（Chain）。区块链技术首先被应用于比特币，如图1-1所示。比特币本身就是第一个，也是规模最大、应用范围最广的区块链。 图1-1　简化的比特币区块链示意图 1.1.2　区块链和区块链技术的涵义 目前，关于区块链没有统一的定义，综合来看，区块链就是基于区块链技术形成的公共数据库（或称公共账本）。其中区块链技术是指多个参与方之间基于现代密码学、分布式一致性协议、点对点网络通信技术和智能合约编程语言等形成的数据交换、处理和存储的技术组合。同时，区块链技术本身仍在不断发展和演化中。 1.1.3　区块链分类 以参与方分类，区块链可以分为：公开链（Public Blockchain）、联盟链（Consortium Blockchain）和私有链（Private Blockchain）。从链与链的关系来分，可以分为主链和侧链。而且，不同区块链还可以形成网络，网络中链与链的互联互通，产生互联链（Interchain）的概念。 1.?公共链 公共链对外公开，用户不用注册就能匿名参与，无需授权即可访问网络和区块链。节点可选择自由出入网络。公共链上的区块可以被任何人查看，任何人也可以在公共链上发送交易，还可以随时参与网络上形成共识的过程，即决定哪个区块可以加入区块链并记录当前的网络状态。公共链是真正意义上的完全去中心化的区块链，它通过密码学保证交易不可篡改，同时也利用密码学验证以及经济上的激励，在互为陌生的网络环境中建立共识，从而形成去中心化的信用机制。在公共链中的共识机制一般是工作量证明（PoW）或权益证明（PoS），用户对共识形成的影响力直接取决于他们在网络中拥有资源的占比。 公共链通常也称为非许可链（Permissionless Blockchain）。如比特币和以太坊等都是公共链。公共链一般适合于虚拟货币、面向大众的电子商务、互联网金融等B2C、C2C或C2B等应用场景。 2.?联盟链 联盟链（Consortium Blockchain）仅限于联盟成员参与，区块链上的读写权限、参与记账权限按联盟规则来制定。由40多家银行参与的区块链联盟R3[3]和Linux基金会支持的超级账本（Hyperleder）[4]项目都属于联盟链架构。联盟链是一种需要注册许可的区块链，这种区块链也称为许可链（Permissioned Blockchain）。 联盟链的共识过程由预先选好的节点控制。一般来说，它适合于机构间的交易、结算或清算等B2B场景。例如在银行间进行支付、结算、清算的系统就可以采用联盟链的形式，将各家银行的网关节点作为记账节点，当网络上有超过2/3的节点确认一个区块，该区块记录的交易将得到全网确认。联盟链可以根据应用场景来决定对公众的开放程度。由于参与共识的节点比较少，联盟链一般不采用工作量证明的挖矿机制，而是多采用权益证明或PBFT（Practical Byzantine Fault Tolerant）、RAFT等共识算法。联盟链对交易的确认时间、每秒交易数都与公共链有较大的区别，对安全和性能的要求也比公共链高。 联盟链网络由成员机构共同维护，网络接入一般通过成员机构的网关节点接入。联盟链平台应提供成员管理、认证、授权、监控、审计等安全管理功能。 2015年成立的R3联盟，旨在建立银行同业的一个联盟链，目前已经吸引了40多个成员，包括世界著名的银行（如摩根大通、高盛、瑞信、伯克莱、汇丰银行等），IT巨头（如IBM、微软）。 银行间结算是非常碎片化的流程，每个银行各自有一套账本，对账困难，有些交易有时要花几天才能校验和确认。同时，其流动性风险很高，在监管报送方面非常繁琐，也容易出现人为错误，结算成本很高。 针对这种情况，R3联盟构建了一个银行同业的联盟链以解决这些问题。利用区块链技术，银行同业间可以共享一个统一的账本，省掉对账的繁琐工作，交易可以做到接近实时的校验和确认、自动结算，同时监管者可以利用密码学的安全保证来审计不可篡改的日志记录。 R3联盟将开发Corda分布式账本来实现未来愿景。Corda的名字来源有两个，该名字前半部分听起来像accord（协议），后半部分来自于chord（弦，即圆上两点间最短的直线）的定义。这个圆就代表R3联盟中的银行机构。从目前公开的资料来看，Corda具有以下特点： 数据不一定要全局共享，只有满足合法需求的一方才能在一个协议里访问数据； Corda不用一个中心化的控制就可以编排联盟成员的工作流； Corda对联盟成员之间的每笔交易形成共识，而不是在联盟机构的系统层面形成共识； Corda的设计直接支持监管者监督和合规性监控； 交易由参与交易的机构进行验证，而不会报告与交易无关的机构； 支持不同的共识机制； 明确记录智能合约与用书面语言撰写的法律文件之间的关联； 采用工业标准的工具来构建Corda平台； 不设虚拟货币。 Corda平台注重互操作性和渐进部署，不会将保密信息发布给第三方。一个机构可以和对手机构看到一组协议，并可以保证对手机构看到的是同样内容，同时报送给监管机构。Corda包括共识、校验、独一性、永恒性和认证等功能。 3.?私有链 私有链则仅在私有组织使用，区块链上的读写权限、参与记账权限按私有组织规则来制定。私有链的应用场景一般是企业内部的应用，如数据库管理、审计等。也有一些比较特殊的组织情况，比如在政府行业的一些应用：政府的预算和执行，或者政府的行业统计数据，这个一般来说由政府登记，但公众有权力监督。私有链的价值主要是提供安全、可追溯、不可篡改、自动执行的运算平台，可以同时防范来自内部和外部对数据的安全攻击，这个在传统的系统是很难做到的。根据资料［1］的解读，央行发行数字货币可能就是一种私有链。和联盟链类似，私有链也是一种许可链。 币科学（Coin Science）公司推出供企业建立私链的多链（Multichain）平台。它提供保护隐私和权限控制的区块链平台，来克服在金融行业里碰到的推广区块链技术的障碍。多链的目标有以下3个： 1）保证区块链上的活动只能由选择的参与者看到； 2）引入机制来控制哪些交易是被允许的交易； 3）提供安全的挖矿机制，同时不需要工作量证明以及与其相关的成本。 多链把挖矿权限制在一组实名的矿工范围，解决了一直困扰私有链解决方案中的一方垄断挖矿过程的问题。它的解决办法是限制在同一个时间窗口同一矿工能产生的区块链数。不像比特币那样只支持一条区块链，多链可以方便地配置多条区块链，并让用户同时用多条链。这样的话，机构用户可以让管理员配置区块链而不需要由区块链专业开发者来做。 多链让用户在一个配置文件中配置区块链的所有参数，这些参数包括： 区块链的协议，例如是私有链还是像比特币那样的公共链； 目标区块产生时间，例如1分钟； 权限，例如所有人能连接，只有一些人能发送或接收交易； 挖矿的不同形式（只适合于私有链）； 建立、移除管理员和矿工所需要的共识的程度，以及在建立期不需要强制执行的期限（只适合于私有链）； 矿工的报酬，例如每区块50个币，然后每210?000个区块减半付酬； 邻节点连接和JSON RPC API的IP端口，例如8571、8570； 允许的交易类型，例如paytoaddress、paytomultisig、paytoscripthash等； 最大的区块大小，例如1MB； 每个交易的最大元数据（OP_RETURN），例如4KB。 多链在节点的“握手”连接过程如下： 1）每个节点提供它的公共地址，使其他节点能将它的地址包括在允许连接的清 单中； 2）每个节点验证邻节点的地址是在它的授权连接的节点清单里； 3）每个节点发一个盘问（Challenge）消息给其他节点； 4）每个节点发回一个回复盘问信息的签名，证明拥有他们的对应公共地址的私钥； 5）如果双方对对方回复不满意，可随时中断连接。 在多链里，所有的权限的授予和回收都是通过包含特殊元数据的网络交易来实现的。找到创世区块的矿工被自动授予所有的权限，包括管理其他用户的管理员权限。管理员通过发交易给其他用户，并在交易的输出中包含授权用户的地址以及授权信息的元数据来给其他用户授予相应的权限。当要改变其他用户的管理和挖矿权限的时候，一个额外的限制条件是要由现有的管理员投票来决定。这些管理员的投票需要登记在不同的交易中，只有当足够的共识形成之后才能通过改变。 多链在很多方面的设计是为了使得用户在私链和比特币区块链能够进行双向迁移。多链是基于比特币核心的一个分叉。所有的对比特币的代码改变都是本地化的改变。未来比特币的升级功能可以并入多链的本地代码。它基于比特币的协议、交易和区块链架构，只是在握手协议上有所改变。其他的功能是通过元数据，同时改变交易和区块的验证规则来实现的。在接口方面与比特币完全兼容，所有的新功能通过新的命令来提供。它可以做成普通比特币网络的一个节点。 多链提供一个在企业内快速部署私链的解决方案。可以用于如去中心化交易所、数据库同步、货币结算、债券发行和P2P交易、消费行业积分奖励机制等场景。 4.?侧链 比特币主要是按其设计者中本聪的思想设计的一个虚拟货币系统，虽然很成功，但是其规则已经相对固定，很难在比特币上做大的修改，因为这些修改会引起分叉，影响现有的比特币用户。因此，要在比特币平台上做创新或扩展是比较困难的。一般来说，大部分代币系统是通过用比特币平台做基础，重构一条区块链，然后在上面使用新的规则发新的虚拟货币。这就是目前大部分代币的做法。然而这些代币系统要从无到有得到人们的价值认可是非常困难的，通常的办法是与比特币挂钩，相当于用比特币作为储备来发行代币，这样就可以完成代币的货币价值认可的过程。但随之而来的问题是，如何自动保障代币和比特币的挂钩呢？因为虚拟货币的一个特点就是价格波动非常大，一般人都不愿意持有波动大、流动性差的代币。一个直接的想法就是通过比特币平台和代币平台的整合来做到实时的挂钩。 2014年，亚当·贝克（Adam Back）等作者发表了一篇论文，题目是《Enabling Blockchain Innovations with Pegged Sidechains》，中文意思是“用与比特币挂钩的侧链来提供区块链创新”。其核心观点是“比特币”的区块链在概念上独立于作为资产的比特币。他希望通过技术能支持在不同的区块链上转移资产，这样新的系统可以重用原先的比特币。他提出一个侧链（Side Chains）的概念。所谓侧链，就是能和比特币区块链交互，并与比特币挂钩的区块链。贝克列出了侧链的一些属性： 一个用户在一条链上的资产被转移到另一条链上后，还应该可以转移回到原先链上的同一用户名下。 资产转移应该没有对手卷款逃跑的风险，也就是不诚实的用户没能力阻碍资产转移的发生。 资产的转移必须是原子操作，也就是要么全发生，要么不发生。不应该出现丢失资产或欺诈性增加资产的情况。 侧链间应该有防火墙。一条侧链上的软件错误造成链上资产的丢失或增加不会影响另一条链上的资产的丢失或增加。 即使在资产的转移过程中发生区块链的重组，也不应出现问题。任何因区块链重组造成的中断，应该局限在本条侧链上而不应影响其他区块链。通常侧链之间最好能相互独立，用户可以从其他链条提供数据。只有当存在明确的侧链的共识规则时才需要去检查另一条侧链来对其验证。 用户不应需要跟踪不经常使用的侧链。 比特币是大家公认的公共链，是很多代币的基础。但比特币的设计规则决定了比特币有一定的局限，例如平均每10分钟出一个区块，每个区块1MB大小限制，这使得大概每秒才能确认7笔交易，这种交易速度而在很多场景下不能满足业务需求。因此，通过侧链来提升效率，扩展比特币功能是一个非常有效的做法。比如，闪电网络把很多交易放在侧链，只有在做清算时才用上主链，这样一来可以极大地提升交易速率，又不会增加主链的存储负担。 5.?互联链 如图1-2所示，针对特定领域的应用可能会形成各自垂直领域的区块链，这些区块链会有互联互通的需求，这样这些区块链也会通过某种互联互通协议连接起来。与互联网一样，这种区块链上的互联互通就构成互联链，形成区块链全球网络。 图1-2　区块链网络示意图 1.1.4　区块链价值与应用 根据各个区块链采取的技术组合不同，形成的区块链特点也大不相同。但是需要指出的是，区块链技术是一揽子技术，可以根据业务的需要进行有针对性的组合和创新。 总体来说，去中心化信用机制是区块链技术的核心价值之一，因此区块链本身又被称为“分布式账本技术”“去中心化价值网络”等。自古以来，信用和信任机制就是金融和大部分经济活动的基础，随着移动互联网、大数据、物联网等信息技术的广泛应用，以及工业4.0等新一代工业革命的开启，网络空间的信用作为数字化社会的基石的作用显得更加重要。传统上，信用机制是中心化的，而中心化的信任和信用机制必然导致中心化机构成为价值链的核心，也容易引发问题。而区块链技术则首先在人类历史上实现了去中心化的大规模信用机制，在消除中心机构“超级信用”的同时，保证信用机制安全、高效地运行。 具体来看，区块链的颠覆性价值至少包括以下5个方面。 1）简化流程，提升效率。由于区块链技术是参与方之间通过共享共识的方式建立的公共账本，形成对网络状态的共识，因此区块链中的信息天然就是参与方认可的、唯一的、可溯源、不可篡改的信息源，因此原来许多重复验证的流程和操作就可以简化，甚至消除，例如银行间的对账、结算、清算等，从而大幅提升操作效率。 2）降低交易对手的信用风险。与传统交易需要信任交易对手不同，区块链技术可以使用智能合约等方式，保证交易多方自动完成相应义务，确保交易安全，从而降低对手的信用风险。 3）减少结算或清算时间。由于参与方的去中心化信任机制，区块链技术可以实现实时的交易结算和清算，实现金融“脱媒”，从而大幅降低结算和清算成本，减少结算和清算时间，提高效率。 4）增加资金流动性，提升资产利用效率。区块链的高效性，以及更短的交易结算和清算时间，使交易中的资金和资产需要锁定的时间减少，从而可以加速资金和资产的流动，提升价值的流动性。 5）提升透明度和监管效率，避免欺诈行为。由于区块链技术可以更好地将所有交易和智能合约进行实时监控，并且以不可撤销、不可抵赖、不可篡改方式留存，方便监管机构实现实时监控和监管，也方便参与方实现自动化合规处理，从而提升透明度，避免欺诈行为，更高效地实现监管。 区块链的创新性最大的特点不在于单点技术，而在于一揽子技术的组合，在于系统化的创新，在于思维的创新。而正是由于区块链是非常底层的、系统性的创新，区块链技术和云计算、大数据、人工智能、量子计算等新兴技术一起，被认为是最具变革性的新兴技术之一。其中，金融服务领域是即将被颠覆的关键领域之一，除此之外，区块链还可以被广泛应用于物联网、移动边缘计算等去中心化控制领域，以及智能化资产和共享经济（如自动驾驶汽车、智能门锁+租赁）等一系列潜在可应用的领域。下面我们重点介绍几类区块链变革金融服务的场景。 （1）金融领域的结算和清算 以金融领域的结算和清算为例，全球每年涉及各种类型的金融交易高达18万亿美元。如图1-3所示，由于交易双方互不信任，因此金融机构需要通过处于中心位置的清算结构来完成资产清算和账本的确认。这类涉及多个交易主体且互不信任的应用场景就非常适合使用区块链技术。原则上，可以直接在金融之间构建联盟链，那么机构之间只需要共同维护同一个联盟区块链，即可实现资产的转移和交易。 图1-3　区块链去中心化金融服务示意图 （2）数字货币 货币是一种价值存储和交换的载体，过去都是由中央法定机构集中发行的。以比特币为例，正是由于其非中心化的信任机制，虽然先后经历多次交易所倒闭、“虚拟货币”非法使用被查抄、多个政府禁止使用等危机，但比特币经受住了所有这些考验，目前仍能稳定运行。比特币的出现和稳定运行，可以说完全颠覆了人们对于货币的认识。相信区块链技术或者说分布式账本技术会在数字货币技术体系中占据重要地位。 （3）跨境支付 另一个区块链可颠覆的金融服务就是跨境支付。通常跨境支付到账时间长达几天甚至一个星期。除此之外，跨境支付需要双边的用户都向当地银行提供大量开户资料和证明，以配合银行的合规性要求，参与交易的银行和中间金融机构还需要定期报告，以实现反洗钱等其他合规性要求。这是一个典型的涉及多方主题的交易场景，区块链技术可以应用在多个环节。区块链技术，一方面可以减少用户重复提交证明材料，提升效率，另一方面可以更好地实现合规、实时性等，大幅提升金融机构的运行效率，提升监管效率。此外，由于区块链技术可以在银行等金融机构之间直接通过区块链实现资金和资产的转移，因此可以去掉高昂的中间费用。此外，还可以结合智能合约等技术，在合约中规定好实施支付的条件，在支付的同时保证义务的实施，提升交易的安 全性。 （4）财产保险 财险是除寿险之外最大的保险。传统上，财险理赔是用户的痛点和成本瓶颈，估计理赔成本的占比至少高达保险公司收入的11%。而且由于理赔过程中用户需要提供大量的资料，客户体验往往非常不友好。由于每个理赔可能会涉及大量的手工操作，因此需要占用大量的人力、物力来进行理赔处理。此外，由于保险公司各自为政，财险理赔还需要对抗保险欺诈。而区块链技术则可以很好地缓解财险理赔的用户痛点，降低理赔成本。首先区块链可以减少客户提供理赔资料和证明的负担，如果资产可以智能化地嵌入智能合约，则资产可具备自动启动理赔流程的能力，甚至可以实现自动化理赔，大幅加速理赔过程，改善客户体验，甚至可以在联盟成员之间进行合理的数据共享，有效地发现和排除保险欺诈。此外，区块链技术的应用可以大幅度减少保险公司对中介代理服务人员的需求，从而大幅度降低运营成本。 此外，区块链还可以广泛应用在物联网、边缘计算、存在性证明等许多领域，读者可以参考《Blockchain：Blueprint for a new economy》一书。此处，特别强调的是关于区块链的应用可能层出不穷，关键还是要理解区块链技术的内涵和变革原理，深刻体会区块链去中心化的系统化思维，从而可以结合自身对相关行业的理解和需求，创造出新的解决方案、新的价值。 1.2　区块链体验 区块链仍然是一个抽象概念，为了更好地理解区块链，为本书后续章节提供一个直观的理解基础，本节中我们将首先通过交易所购买少量比特币，然后转移到比特币钱包中，最后通过钱包实现比特币转账。 1.2.1　获取比特币的3种途径 获取比特币有3种途径：一是作为“矿工”挖矿获得，二是线上“交易所”购买或者线下通过中间人购买，三是作为商家收取比特币。 1.?挖矿 由于比特币的独特设计，参与者可以通过计算能力竞争的方式获取系统奖励和支付小费，同时也维护着比特币这个区块链的稳定运转，我们把这种算力竞争行为称为“挖矿”。比特币价格的一路攀升。挖矿的设备和算力也一路升级，如图1-4所示，从最初的CPU挖矿，到第二代的显卡挖矿，经历过短暂的FPGA挖矿时代后，迅速进入专用芯片（ASIC）挖矿时代。 图1-4　比特币算力增长图 而进入ASIC矿机时代之后，矿机芯片的工艺升级速度远超摩尔定律的演进速度，差不多3个月时间就会进化一代，蚂蚁矿机S9是目前新出产的主流挖矿设备已经采用了16nm工艺制造的专用芯片。 “挖矿”今天已经成为高度专业化的细分产业。为保证收益，挖矿不仅要求有较高的初始投入，以及更低廉获取“矿机”和电力的渠道，还要求有专业的管理能力。如图1-5所示，这是一座位于我国西南某处的比特币矿场。 随着挖矿专业化程度的提高，矿工往往都是通过联合挖矿组成矿池的形式来挖矿的，矿池用来协调和分布挖矿的收益，比特币的算力分布目前前几大矿池都位于中国。 图1-5　比特币矿场 2.?线上交易所或者线下撮合获取比特币 其中线上交易所方面，我国的okcoin、火币占据了交易量的绝大多数，两家交易量占线上交易量的93%以上。线下交易具有更好的匿名性。图1-6展示的是比特币历史交易价格，可以看到从最初的不到0.1美元到历史最高点接近1200美元，再到当前日期（2016年7月25日）的约660美元。中间经历多次大的价格波动。 图1-6　比特币历史价格（对数坐标，美元计价） 3.?比特币作为一种支付的手段 其优势在于跨境支付等场景下具备非常低的收费，并且非常快捷。在日常小额支付方面，目前在全球也有一定的市场。目前比特币作为一种支付手段，主要在欧美等发达国家和地区有比较广泛的分布。当然，由于比特币价格的波动性，一般商家都会实时将比特币转换为当地货币。比特币在我国不能作为货币支付手段，不能很方便地在银行 汇兑。 1.2.2　通过交易所购买比特币 在本节中，我们将通过OKCoin这个比特币交易平台购买少量比特币。读者可以选择火币、BTCC等其他平台购买获取比特币，基本过程是相似的。大部分主流交易平台也提供移动端App，读者可以根据情况选用。 首先，我们需要注册OKCoin的账号，在OKCoin中国站（https://www.okcoin.cn/user/register.do）通过邮箱（或手机号）注册即可。如图1-7所示，填写邮箱、密码，并勾选同意服务条款后，单击“注册”按钮即可完成注册。 注册成功后可看到注册成功的页面，如图1-8所示。然后开始身份认证。根据相关条例要求，目前几乎所有比特币交易平台都会要求真实身份认证。 　　 　　　??　图1-7　网站注册页面　　　?　　　　　　　　　图1-8　注册成功页面 单击图1-8中的“开始身份认证”按钮，将会进入如图1-9所示的提示页面，可以选择“个人用户”或者“企业用户”进行认证。这里选择“个人用户”这个类型进行 认证。 图1-9　身份认证提示页面 如图1-10所示，正确填写身份信息并提交就能看到如图1-11所示的认证成功提示。注意，请使用真实身份信息，如遇到忘记密码等情形，可能会需要配合平台方提供相关证明才能进行处理。 图1-10　个人身份认证页面 单击“设置资金密码”按钮，就会进入如图1-12所示的页面。根据提示，我们可以选择手机认证或者Google验证的方式来设置二次验证的方式。 我们选择Google验证的方式，安装iOS或者Android版Google Authenticator之后，单击图1-13中的“设置”按钮，打开App，扫描左边的条形码后就能看到OKCoin.cn的动态密码了。将App中的动态密码输入弹出页面中，就能看到成功提示页面，同时也可看到资金密码的“设置”按钮变为可用。单击该按钮将进入如图1-13所示的资金密码设置页面。 图1-11　个人身份认证成功页面 图1-12　二次验证设置页面 设置密码并填写Google验证的二次验证密码（如果前面是手机验证，则是手机验证码），就会看到如图1-14所示的提示页面。 单击“前往充值”按钮进入充值页面，如图1-15所示。我们选择“快捷充值”方式，也可以选择“支付宝充值”或者“网银汇款充值”的方式。 图1-13　资金密码设置页面 图1-14　资金密码设置成功提示页面 图1-15　充值选择页面 选择“快捷充值”后进入如图1-16所示的银行选择页面，根据个人情况选择网银进行充值。我们在这里选择充值100元用于购买小额的比特币，未来仍然可以通过交易所换回现金（当然可能会有少量的转账费用和价格波动）。 图1-16　快捷充值页面 充值成功之后就可以购买比特币了。我们可以通过“市价单”快速购买比特币，如图1-17所示。 图1-17　购买比特币页面 委托完成后，可以在页面下方的委托成交记录中看到交易记录，如图1-18所示。可以看到，我们以4389.76元/BTC的价格成功地通过交易所购买到了0.02个比特币。 图1-18　委托成交记录 1.2.3　比特币钱包和地址 在上节中，我们通过比特币交易平台购买了少量比特币。需要指出的是，交易平台仍然不属于中心化的服务机构，在交易平台的交易不属于区块链（比特币）之上的交易，其交易和资金的可靠性需要交易平台的背书。虽然，目前国内运营的几大交易平台没有发生大的诚信危机，但从比特币诞生至今也发生过多次交易所欺诈、倒闭和“跑路”事件，让不少比特币拥有者蒙受了巨额经济损失。为了进一步体验比特币和区块链的真实性，我们的体验之旅继续。在本节中，我们将在交易平台购买的比特币转入我们的比特币“钱包”，并可以在区块链上查询到这笔交易。 比特币钱包是一个形象的概念，比特币本身由一对数字密钥来决定归属，因为拥有私钥就能拥有对应地址比特币的处置权，可以说这些私钥就等于比特币，我们通常将管理这些数字密钥的软件称为“钱包”。比特币钱包，根据终端类型可以分为桌面钱包、手机钱包、网页钱包和硬件钱包。其中硬件钱包（见图1-19）成本最高，也相对更安全。对于小量比特币来说，我们可以选用网页钱包这种轻量级的钱包来存储，而对于较大额度的比特币，则建议使用更高级的钱包存储方式。 图1-19　比特币硬件钱包case（来源：choosecase.com） 我们接下来将选择开源钱包MultiBit HD桌面版，当然读者也可以选择其他优秀的钱包。在https://multibit.org/下载对应版本的文件后，单击安装，并选择中文作为界面语言。单击“下一步”按钮之后，可以进入如到图1-20所示的页面。 图1-20　创建钱包准备页面 特别需要强调的是，比特币不同于银行账户的概念，钱包是帮助我们管理这些私钥的，同时也要妥善保管好钱包的恢复密语和备份数据。MulitBit HD钱包使用一种新的密钥技术，即12个单词的密语可以恢复这个钱包，如图1-21所示。所以建议妥善保存这些单词，而且要离线保存。 图1-21　MultiBit钱包密语 继续按照提示完成后续操作，包括设置钱包密码等。完成之后可以看到如图1-22所示的创建钱包报告页面。 图1-22　创建钱包报告页面 创建完成后打开MultiBit，在发送/接受页面选择接收，可以看到钱包的比特币地址：1FA97cbn8EbFFRKnVkfFPQ4Z5C8WnFhtpP，如图1-23所示。或者单击地址栏后面第二个图标，可以显示二维码形式的比特币地址，这将是我们从交易平台购买的比特币提现地址。 图1-23　钱包比特币地址 1.2.4　从交易平台提取比特币到钱包 首先，我们需要在交易平台添加提现地址。登录OKCoin后，选择“资金管理”栏目，然后选择添加地址，正确填写钱包中的比特币地址，二次验证码，如果需要认证，则勾选“认证地址”复选框，并填写资金密码，如图1-24所示。单击“确定”后，平台会向用户发送确认邮件，确认后即可完成提现地址添加。 图1-24　添加比特币提现地址 最后一步，在“资金管理”栏目中选择“BTC提现”选项卡，如图1-25所示。提现地址可以选择上面认证过的提现地址，数量为我们能提现的数量，如0.02BTC（20mBTC）。注意，“网络手续费”为网络“矿工”维持比特币区块链网络运转的交易费奖励。当然，为了防止垃圾交易攻击和提高矿工处理交易的积极性，一般都会选择0.1～0.5mBT不等的小费（小费多少一般根据交易占用的容量大小而定）。 图1-25　比特币提现页面 目前国内的平台为了防止被盗，在提现要求提交后，一般都会由人工处理提现申请，包括电话确认提现是本人所操作、确认提现的数量等，确认完成后才会正式处理。等平台将交易发送到比特币网络，我们就可以在区块链上公开看到这笔交易了。我们可以在MultiBit上看到，刚开始的时候，MultiBit上会显示已收到付款，但是是“未确认”的，如图1-26所示。原则上，未确认的交易可能存在风险，比如发送者重复花费这部分比特币，在小额支付的场景下，零确认可能也是可以接受的，但是在较大金额的交易中，通常会选择等待至少6个以上的确认。 图1-26　未确认收款 1.2.5　比特币交易查询 经过比较长的时间后，我们可以使用blockchain.info和qukuai.com查询交易的结果。如图1-27所示，这笔交易是从一个有92.22788075的BTC，地址为1EDpd8oYNmKzHJvTrjQnWmkexENB7MXjxK中转出的，剩余的92.20788075BTC转到一个新地址1KqrkJvjqUmrzzq274wSkMRwbWbXprkNPF。交易在第421416个区块被锁定，截至写作时已经经历了1063个确认。图1-28中的“转入脚本”（也称为解锁脚本）和“转出脚本”（也称为锁定脚本）就是比特币的合约脚本，后续我们将会在2.1.3节详细介绍。 图1-27　BTC提现交易结果 到这里，我们的区块链（比特币）初次体验之旅就告一段落了。我们存储到MultiBit钱包的比特币可以直接用于支付、捐赠、打赏，也可以通过交易平台的比特币充值回流到平台，再换成人民币等。 1.3　本章小结 本章中，我们首先简单介绍了区块链的起源和定义，以及区块链的分类、价值和应用。然后我们通过图示的方式，以比特币这个目前最大的公链为例，带领大家体验比特币，包括如何获取比特币，如何通过交易平台购买比特币，以及如何通过钱包存储比特币，最后将交易平台的比特币提取到钱包中，并在区块链上公开查询到这笔交易。 毋庸置疑，区块链的发展已经远远超出了比特币和数字货币的范畴，可以说，区块链去中心化的信任机制和价值传递机制的变革将极具颠覆性，当前区块链领域的创新才刚刚开始。后续章节让我们一起继续关于区块链更深入的探索。 参考资料 ［1］ 中国人民银行.中国人民银行数字货币研讨会在京召开[J/OL]. 2016, http://www.pbc.gov.cn/goutongjiaoliu/113456/113469/3008070/index.html. ［2］ 中国人民银行.中国人民银行等五部委发布《关于防范比特币风险的通知》[J/OL].2013, http://www.pbc.gov.cn/goutongjiaoliu/113456/113469/999049/index.html. ［3］ R3. 2016, http://r3cev.com/. ［4］ HYPERLEDGER. 2016, https://www.hyperledger.org/.BLOCKSTREAM. 2016, http://www.blockstream.com/. ［5］ SWAN M. Blockchain: Blueprint for a new economy [M]. O'Reilly Media, Inc., 2015. 第2章 区块链基础 区块链是随着比特币等数字加密货币的日益普及而逐渐兴起的一种全新技术，它提供了一种去中心化的、无需信任积累的信用建立范式，目前已经引起金融行业、科研机构、政府部门和投资公司的高度重视与广泛关注。区块链技术通过建立一个共同维护且不可被篡改的数据库来记录过去的所有交易记录和历史数据，所有的数据都是分布式存储且公开透明的。在这种技术下，任何互不相识的网络用户都可以通过合约、点对点记账、数字加密等方式达成信用共识，而不需要任何的中央信任机构。在这种技术下，我们可以建立数字货币、数字资产、智能财产以及智能合约等。 通过上一章的介绍，相信大家已经对区块链和比特币有了初步的认识，在本章中，我们将继续探讨区块链的技术细节。 本章将首先介绍区块链的相关基本概念及其运作原理，然后介绍区块链上可以进行的操作和相关细节，最后再讨论区块链上的交易流程和它的验证过程。 2.1　区块链技术 区块链本质上是一个对等网络（peer-to-peer）的分布式账本数据库。比特币的底层就采用了区块链的技术架构。区块链本身其实是一串链接的数据区块，其链接指针是采用密码学哈希算法对区块头进行处理所产生的区块头哈希值。每一个数据块中记录了一组采用哈希算法组成的树状交易状态信息，这样保证了每个区块内的交易数据不可篡改，区块链里链接的区块也不可篡改。 2.1.1　基本概念 一个完整的区块链系统包含了很多技术，其中有存储数据的数据区块及其之上的数字签名、时间戳等技术，有作为支撑的P2P网络和维护系统的共识算法，有挖矿和工作量证明机制，有匿名交易机制和比特币钱包，还有链龄、UTXO、Merkle树、双花等相关技术概念。正是这些技术，使得区块链在无中心的网络上形成了运转不息的引擎，为区块链的交易、验证、链接等功能提供了源源不断的动力。 1.?数据区块 比特币的交易记录会保存在数据区块之中，比特币系统中大约每10分钟会产生一个区块，每个数据区块一般包含区块头（Header）和区块体（Body）两部分，如图2-1所示。 图2-1　区块结构 区块头封装了当前的版本号（Version）、前一区块地址（Prev-block）、时间戳（Timestamp）、随机数（Nonce）、当前区块的目标哈希值（Bits）、Merkle树的根值（Merkle-root）等信息。 区块体中则主要包含交易计数和交易详情。交易详情就是比特币系统中的记账本，每一笔交易都会被永久地记入数据区块中，而且任何人都可以查询。区块体中的Merkle树将会对每一笔交易进行数字签名，如此可以确保每一笔交易都不可伪造且没有重复交易。所有的交易将通过Merkle树的Hash过程产生一个唯一Merkle根值记入区块头。关于Merkle树本章后面将详细介绍。 如果你使用的是比特币核心钱包（Bitcoin core），那么每当你打开客户端时，区块数据文件都会被同步到电脑硬盘中，可以在blocks文件夹下找到它们。如图2-2所示的.dat文件就是我们要找的数据区块文件。 我们还可以使用hexdump指令在终端上将数据区块以十六进制的方式显示出来。我们可以通过解析这些数据得出交易记录、区块大小等基本信息，因此我们说区块链中的数据是完全公开透明的。如图2-3所示，我们使用指令hexdump -n 10000 -C blk00000.dat打开了编号为00000的创世区块（比特币中的第一块区块链）。 图2-3　用hexdump指令打开的创世区块 2.?挖矿与分叉问题 区块在挖矿过程中产生。所谓挖矿，实际上是穷举随机数算法，把上个区块的哈希值加上10分钟内的全部交易单打包，再加上一个随机数，算出一个256位的字符串哈希值，输入的随机数Nonce使哈希值满足一定条件就获得这个区块的交易记账权。新产生的区块需要快速广播出去，以便其他节点进行对其验证，以防造假。每个区块存着上一个区块的哈希值，可以溯源到源头，只有经过验证后才最终获得区块的交易记账权。比特币系统会让挖矿的矿工竞争记账权（在主链上链接区块的权利），这个竞争机制就是工作量证明机制。挖矿需要付出大量的能源和时间，谁付出的工作量多就能以更大的概率获得一个区块的记账权。获取记账权的矿工会将当前区块链接到前一区块，形成最新的区块主链，该矿工也会得到系统奖励的一定数量（2009～2013年每10钟产生50个比特币，2014年至今每10分钟产生的比特币将减半成25个）的比特币。所有的区块链接在一起形成了区块链的主链，从创世区块到当前区块，在区块链之上的所有数据历史都可以被追溯和查询。 需要说明的是，可能会出现不同地区的两个矿工同时“挖出”两个新区块加以链接的情况，这时主链上就会出现“分叉”。系统并不会马上确认哪个区块不合理，而是约定后续矿工总是选择累计工作量证明最大的区块链。因此，当主链分叉以后，后续区块的矿工将通过计算和比较，将其区块链接到当前累计工作量证明最大化的备选链上，形成更长的新主链，并自动抛弃分叉处的短链，从而解决分叉问题。 3.?时间戳和不可篡改性 时间戳是指从格林威治时间1970年01月01日00时00分00秒（北京时间1970年01月01日08时00分00秒）起至现在的总秒数，通常是一个字符序列，唯一地标识某一刻的时间。在比特币系统中，获得记账权的节点在链接区块时需要在区块头中加盖时间戳，用于记录当前区块数据的写入时间。每一个随后区块中的时间戳都会对前一个时间戳进行增强，形成一个时间递增的链条。时间戳技术本身并没有多复杂，但在区块链技术中应用时间戳却是一个重大创新，时间戳为未来基于区块链的互联网和大数据增加了一个时间维度，使得数据更容易追溯，重现历史也成为可能。同时，时间戳可以作为存在性证明（Proof of Existence）的重要参数，它能够证实特定数据必然在某特定时刻是的确存在的，这保证了区块链数据库是不可篡改和不可伪造的，这也为区块链技术应用于公证、知识产权注册等时间敏感领域提供了可能。 4.?分布式数据库 比特币系统中的区块就像一个记账本一样，记录了所有比特币的交易信息，每一个比特币用户的比特币收支情况都被永久地嵌入了数据区块中以供别人查询。这些数据区块中的交易数据存放在每一个比特币用户的客户端节点中，所有的这些节点则组成了比特币及其坚韧的分布式数据库系统。任何一个节点的数据被破坏都不会影响整个数据库的正常运转，因为其他的健康节点中都保存了完整的数据库。 5.?UTXO交易模式 UTXO（Unspent Transaction Outputs）是未花费的交易输出，它是比特币交易过程中的基本单位。除创世区块以外，所有区块中的交易（Tx）会存在若干个输入（Tx_in，也称资金来源）和若干个输出（Tx_out，也称资金去向），创世区块和后来挖矿产生的区块中给矿工奖励的交易没有输入，除此之外，在比特币系统中，某笔交易的输入必须是另一笔交易未被使用的输出，同时这笔输入也需要上一笔输出地址所对应的私钥进行签名。当前整个区块链网络中的UTXO会被储存在每个节点中，只有满足了来源于UTXO和数字签名条件的交易才是合法的。所以区块链系统中的新交易并不需要追溯整个交易历史，就可以确认当前交易是否合法。 6.?哈希函数 哈希函数在比特币系统中也有着重要的应用，区块链中的数据并不只是原始数据或者交易记录，还包括它们的哈希函数值，即将原始数据编码为特定长度的、由数字和字母组成的字符串后，记入区块链。哈希函数有着很多适合存储区块链数据的 优点： 1）哈希函数处理过的数据是单向性的，通过处理过的输出值几乎不可能计算出原始的输入值； 2）哈希函数处理不同长度的数据所耗费的时间是一致的，输出值也是定长的； 3）哈希函数的输入值即使只相差一个字节，输出值的结果也会迥然不同。比特币系统中最常采用的哈希函数是双SHA256哈希函数，通俗来说就是将不同长度的原始数据用两次SHA256哈希函数进行处理，再输出长度为256的二进制数字来进行统一的识别和存储。 总之，哈希函数是比特币系统中的关键技术，为比特币系统提供了很多便利。本书后面的章节将会对哈希函数做详细介绍，此处不赘述。 7.?Merkle树 Merkle树是数据结构中的一种树，可以是二叉树，也可以是多叉树，它具有树结构的所有特点。如图2-4所示，比特币区块链系统中的采用的是Merkle二叉树，它的作用主要是快速归纳和校验区块数据的完整性，它会将区块链中的数据分组进行哈希运算，向上不断递归运算产生新的哈希节点，最终只剩下一个Merkle根存入区块头中，每个哈希节点总是包含两个相邻的数据块或其哈希值。在比特币系统中使用Merkle树有诸多优点：首先是极大地提高了区块链的运行效率和可扩展性，使得区块头只需包含根哈希值而不必封装所有底层数据，这使得哈希运算可以高效地运行在智能手机甚至物联网设备上；其次是Merkle树可支持“简化支付验证协议”（SPV），即在不运行完整区块链网络节点的情况下，也能够对交易数据进行检验。所以，在区块链中使用Merkle树这种数据结构是非常具有意义的。本书后面的章节将会对Merkle树做详细介绍。 8.?双重支付 双重支付问题又称为“双花”问题，即利用货币的数字特性用“同一笔钱”完成两次或者多次支付。在传统的金融和货币体系中，由于金钱货币是物理实体，具有客观唯一存在的属性，所以可以避免双重支付的情况。但在其他的电子货币系统中，则需要可信的第三方管理机构提供保证。区块链技术则在去中心化的系统中不借助任何第三方机构而只通过分布式节点之间的相互验证和共识机制，有效地解决了双重支付问题，在信息传输的同时完成了价值转移。区块链技术通过区块链接形成的时间戳技术加上验证比特币是否满足UTXO（未花费交易）和数字签名，有效避免了双重支付的问题。如果有人用同一笔UTXO构造了两笔付给不同交易方的交易，则比特币客户端只会转发最先被侦听到的那个。矿工会选择将那笔交易包入未来区块，当其中一笔交易所在的区块后有5个链接的区块，这笔交易已经得到了6次确认。在比特币区块链上，6次确认后可以基本上保证比特币不被双花。 9.?P2P网络 P2P网络（peer-to-peer network，对等网络）是一种在对等者（peer）之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式。因此，从字面上，P2P可以理解为对等计算或对等网络，P2P网络示意图如图2-5所示。国内的迅雷软件采用的就是P2P技术。区块链系统是建立在IP通信协议和分布式网络的基础上的，它不依靠传统的电路交换，而是建立于网络通信之上，完全通过互联网去交换信息。网络中所有的节点具有同等的地位，不存在任何特殊化的中心节点和层级结构，每个节点均会承担网络路由、验证数据区块等功能。网络的节点根据存储数据量的不同可以分为全节点和轻量级节点，全节点存储了从创世区块以来的所有区块链数据（比特币网络现在大约有几十GB，且还在不断增长中）。全节点的优点是进行数据校验时不需要依靠别的节点，仅依靠自身就可以完成校验更新等操作，缺点是硬件成本较高。轻量级节点只需要存储部分数据信息，当需要别的数据时可以通过简易支付验证方式（Simplif?ied Payment Verif?ication，SPV）向邻近节点请求所需数据来完成验证更新。 图2-5　P2P网络 10.?加密算法 除了哈希算法以外，比特币中还存在一种为交易加密的非对称加密算法（椭圆曲线加密算法）。非对称加密算法指的就是存在一对数学相关的密钥，使用其中一个密钥进行加密的数据信息，只有使用另一个密钥才能对该信息进行解密。这对密钥中，对外公开的密钥叫作公钥，不公开的密钥就叫作私钥。打个比方来说，公钥就像银行的账户，私钥就像是该账户的密码或者账户所有者的签名。区块链之上的有效交易有一个用于交易发起方私钥签名有效的数字签名，而该交易的签名可以通过使用交易发起方的公钥进行验证。公钥可以通过算法从私钥中计算得出，但私钥却不能从公钥中推出。比特币系统中使用的就是一种非常典型的非对称加密算法——椭圆曲线加密算法（ECC）。 如图2-6所示，比特币系统一般从操作系统底层的一个密码学安全的随机源中取出一个256位随机数作为私钥，私钥总数为2256个，所以很难通过遍历所有可能的私钥得出与公钥的对应的私钥。用户使用的私钥还会通过SHA256和Base58转换成易书写和识别的50位长度的私钥，公钥则首先由私钥和Secp256k1椭圆曲线算法生成65字节长度的随机数。一般情况下，比特币钱包的地址也由公钥所生成，其生成过程为首先将公钥进行SHA256和RIPEMD160双哈希运算，并生成20字节长度的摘要结果（即Hash160结果），这个将作为比特币地址的主体（body）信息，再在前面加上版本前缀0x00，在后面添加4个字节的地址校验码。地址校验码通过对摘要结果进行两次SHA256运算，取哈希值的前4位产生。最后通过Base58处理把连在一起的版本前缀、主体信息和校验码转换成可以容易让人识别的比特币字符地址。 图2-6　比特币非对称加密机制 11.?数字签名 数字签名就是在信息后面加上另一段内容，作为发送者的证明并且证明信息没有被篡改。一般是发送者将信息用哈希算法处理得出一个哈希值，然后用私钥对该哈希值进行加密，得出一个签名。然后发送者再将信息和签名一起发送给接收者。接收者使用发送者的公钥对签名进行解密，还原出哈希值，再通过哈希算法来验证信息的哈希值和解密签名还原出来的哈希值是否一致，从而可以鉴定信息是否来自发送者或验证信息是否被篡改。 12.?比特币的隐私模型 传统隐私模型（见图2-7）为交易的参与者提供了一定程度的隐私保护，第三方不会交出交易者的个人身份信息，公众所得知的只是某个人将一定数量的货币发给了另外一个人，但是难以将该交易与某个特定身份的人联系起来，公众无法知道这人到底是谁。这同股票交易所发布的信息是类似的，每一手股票买卖发生的时间、交易量是记录在案且可供查询的，但是交易双方的身份信息却不予透露。但实际上，交易双方的个人信息是存放在第三方机构，所以一定程度上交易参与者的隐私信息还是会有泄露的风险。 图2-7　传统隐私模型 在比特币的隐私模型（见图2-8）中，所有的交易不需要第三方的操控，也不需要提供任何身份信息，只需要提供比特币的地址就可以跟任何人完成一次准匿名的交易。在一定程度上，交易不可追溯到交易者本身，因此比特币上的交易可以在一定程度上摆脱监管。但通过对区块链上交易的地址以及交易额做关联分析，也可以获得有关交易者的蛛丝马迹。因此，比特币的交易还不是纯粹的匿名交易机制，而是准匿名（pseudo-anonymous）交易机制。 图2-8　比特币的隐私模型 2.1.2　框架与特点 1.?框架简介 目前大多数区块链技术的应用与比特币类似，大部分是在比特币架构基础上的扩展。目前，区块链技术在金融行业得到广泛关注，被认为可以用来从最底层重构传统金融业现有的IT基础架构。我们将区块链的基础架构分为三层来进行讲解，如图2-9所示。 图2-9　区块链基础架构 首先，在网络层之上，区块链是建立在IP通信协议和对等网络的基础上的一个分布式系统，和传统带中心的分布式系统不一样，它不依靠中心化的服务器节点来转发消息，而是每一个节点都参与消息的转发。因此P2P网络比传统网络具有更高的安全性，任何一个节点被攻击都不会影响整个网络，所有的节点都保存着整个系统的状态信息。 其次，在数据层面上，区块链就是一个只可追加、不可更改的分布式数据库系统，是一个分布式账本。如果是公开的区块链，也就是公有链，那么这个账本可以被任何人在任何地方进行查询，完全公开透明。在区块链网络中，节点通过使用共识算法来维持网络中账本数据库的一致性。同时采用密码学的签名和哈希算法来确保这个数据库不可篡改，不能作伪，并且可追溯。例如，在比特币系统中，只有在控制了51%的网络算力时才有可能对区块链进行重组以修改账本信息。由于比特币系统的设计者中本聪在系统设计中巧妙地加入了带有经济激励的挖矿工作量证明（PoW）机制，使得即使拥有网络51%以上算力的人也不会损害其自身利益而发起对网络的攻击。因此，比特币系统自上线7年多来一直持续不断地正常运行，没有出现过因为比特币系统本身缺陷而造成的安全故障。 再次，在应用层面，我们可以用区块链代替传统的登记、清算系统。2016年6月22日，波士顿咨询公司指出，到2030年，全球支付业务收入预计将会达到8070亿美元。基于区块链技术的汇兑和支付属于区块链的1.0应用版，其安全性、交易时间、成本都会对传统支付业务进行颠覆式改进。花旗银行也明确指出，到2020年，如果各大金融机构都使用区块链技术，每年能够节省超过200亿美元的成本。国信证券分析报告指出，通过区块链的点对点分布式的时间戳服务器来生成依照时间前后排列并加以记录的电子交易证明，可以解决双重支付问题，从而带来结算成本趋零的可能性。根据德国银行的一份引用波士顿咨询的研究报告，欧洲银行的IT成本支出平均占据银行整体运行成本的16%[5]。一个重要原因就是传统银行在账本的维护、支付交易的结算和清算方面的架构过于复杂，维护成本过高。 在应用方面，区块链平台能够提供编程环境让用户编写智能合约。通过智能合约，可以把业务规则转化成在区块链平台自动执行的合约，该合约的执行不依赖可信任的第三方，也不受人为的干预。理论上只要一旦部署，一旦符合合约执行的条件就会自动执行。执行结果也可以在区块链上供公开检查，提供了合约的公正性和透明性。因此，智能合约可以降低合约建立、执行和仲裁中所涉及的中间机构成本。区块链的智能合约奠定了未来建立可编程货币、可编程金融，甚至是可编程社会的基础。 2.?架构特点 区块链具有去中心化、可靠数据库、开源可编程、集体维护、安全可信、交易准匿名性等特点。如果一个系统不具有以上特征，将不能被视为基于区块链技术的应用。 （1）去中心化 区块链数据的存储、传输、验证等过程均基于分布式的系统结构，整个网络中不依赖一个没有中心化的硬件或管理机构。作为区块链一种部署模式，公共链网络中所有参与的节点都可以具有同等的权利和义务。 （2）可靠数据库 区块链系统的数据库采用分布式存储，任一参与节点都可以拥有一份完整的数据库拷贝。除非能控制系统中超过一半以上的算力，否则在节点上对数据库的修改都将是无效的。参与系统的节点越多，数据库的安全性就越高。并且区块链数据的存储还带有时间戳，从而为数据添加了时间维度，具有极高的可追溯性。 （3）开源可编程 区块链系统通常是开源的，代码高度透明公共链的数据和程序对所有人公开，任何人都可以通过接口查询系统中的数据。并且区块链平台还提供灵活的脚本代码系统，支持用户创建高级的智能合约、货币和去中心化应用。例如，以太坊（Ethereum）平台即提供了图灵完备的脚本语言，供用户来构建任何可以精确定义的智能合约或交易类型。关于以太坊的更多内容请参考2.2节。 （4）集体维护 系统中的数据块由整个系统中所有具有记账功能的节点来共同维护，任一节点的损坏或失去都不会影响整个系统的运作。 （5）安全可信 区块链技术采用非对称密码学原理对交易进行签名，使得交易不能被伪造；同时利用哈希算法保证交易数据不能被轻易篡改，最后借助分布式系统各节点的工作量证明等共识算法形成强大的算力来抵御破坏者的攻击，保证区块链中的区块以及区块内的交易数据不可篡改和不可伪造，因此具有极高的安全性。 （6）准匿名性 区块链系统采用与用户公钥挂钩的地址来做用户标识，不需要传统的基于PKI（Public Key Infrastructure）的第三方认证中心（Certif?icate Authority，CA）颁发数字证书来确认身份。通过在全网节点运行共识算法，建立网络中诚实节点对全网状态的共识，间接地建立了节点间的信任。用户只需要公开地址，不需要公开真实身份，而且同一个用户可以不断变换地址。因此，在区块链上的交易不和用户真实身份挂钩，只是和用户的地址挂钩，具有交易的准匿名性。。 区块链技术的核心优势是去中心化，能够通过运用哈希算法、数字签名、时间戳、分布式共识和经济激励等手段，在节点无需互相信任的分布式系统中建立信用，实现点对点交易和协作，从而为中心化机构普遍存在的高成本、低效率和数据存储不安全等问题提供了解决方案。近年来，伴随着国内外研究机构对区块链技术的研究与应用，区块链的应用前景受到各行各业的高度重视，被认为是继大型机、个人电脑、互联网、移动/社交网络之后计算范式的第5次颠覆式创新，是人类信用进化史上继血亲信用、贵金属信用、央行纸币信用之后的第4个里程碑。它被视为下一代云计算的雏形，有望彻底重塑人类社会活动形态，并实现从现在的信息互联网到价值互联网的转变。 2.1.3　区块链运作的核心技术  1.?区块链的链接 顾名思义，区块链即由一个个区块组成的链。每个区块分为区块头和区块体（含交易数据）两个部分。区块头包括用来实现区块链接的前一区块的哈希（PrevHash）值（又称散列值）和用于计算挖矿难度的随机数（nonce）。前一区块的哈希值实际是上一个区块头部的哈希值，而计算随机数规则决定了哪个矿工可以获得记录区块的权力。区块链的链接模型如图2-10所示。 图2-10　区块链的链接模型 2.?共识机制 区块链是伴随比特币诞生的，是比特币的基础技术架构。可以将区块链理解为一个基于互联网的去中心化记账系统。类似比特币这样的去中心化数字货币系统，要求在没有中心节点的情况下保证各个诚实节点记账的一致性，就需要区块链来完成。所以区块链技术的核心是在没有中心控制的情况下，在互相没有信任基础的个体之间就交易的合法性等达成共识的共识机制。 区块链的共识机制目前主要有4类：PoW、PoS、DPoS、分布式一致性算法。 （1）PoW PoW（工作量证明），也就是像比特币的挖矿机制，矿工通过把网络尚未记录的现有交易打包到一个区块，然后不断遍历尝试来寻找一个随机数，使得新区块加上随机数的哈希值满足一定的难度条件，例如前面10位是零。找到满足条件的随机数，就相当于确定了区块链最新的一个区块，也相当于获得了区块链的本轮记账权。矿工把满足挖矿难度条件的区块在网络中广播出去，全网其他节点在验证该区块满足挖矿难度条件，同时区块里的交易数据符合协议规范后，将各自把该区块链接到自己版本的区块链上，从而在全网形成对当前网络状态的共识。 优点：完全去中心化，节点自由进出，避免了建立和维护中心化信用机构的成本。只要网络破坏者的算力不超过网络总算力的50%，网络的交易状态就能达成一致。 缺点：目前比特币挖矿造成大量的资源浪费；另外挖矿的激励机制也造成矿池算力的高度集中，背离了当初去中心化设计的初衷。更大的问题是PoW机制的共识达成的周期较长，每秒只能最多做7笔交易，不适合商业应用。 （2）PoS PoS权益证明，要求节点提供拥有一定数量的代币证明来获取竞争区块链记账权的一种分布式共识机制。如果单纯依靠代币余额来决定记账者必然使得富有者胜出，导致记账权的中心化，降低共识的公正性，因此不同的PoS机制在权益证明的基础上，采用不同方式来增加记账权的随机性来避免中心化。例如点点币（PeerCoin）PoS机制中，拥有最多链龄长的比特币获得记账权的几率就越大。NXT和Blackcoin则采用一个公式来预测下一个记账的节点。拥有多的代币被选为记账节点的概率就会大。未来以太坊也会从目前的PoW机制转换到PoS机制，从目前看到的资料看，以太坊的PoS机制将采用节点下赌注来赌下一个区块，赌中者有额外以太币奖，赌不中者会被扣以太币的方式来达成下一区块的共识。 优点：在一定程度上缩短了共识达成的时间，降低了PoW机制的资源浪费。 缺点：破坏者对网络攻击的成本低，网络的安全性有待验证。另外拥有代币数量大的节点获得记账权的几率更大，会使得网络的共识受少数富裕账户支配，从而失去公正性。 （3）DPoS DPoS（股份授权证明）机制，类似于董事会投票。比特股（bitshares）采用的PoS机制是持股者投票选出一定数量的见证人，每个见证人按序有两秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一个时间片对应的见证人。持股人可以随时通过投票更换这些见证人。DPoS的这种设计使得区块的生成更为快速，也更加节能。 优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证。 缺点：选举固定数量的见证人作为记账候选人有可能不适合于完全去中心化的场景。另外在网络节点数少的场景，选举的见证人的代表性也不强。 （4）分布式一致性算法 分布式一致性算法是基于传统的分布式一致性技术。其中有分为解决拜占庭将军问题的拜占庭容错算法，如PBFT。另外解决非拜占庭问题的分布式一致性算法（Pasox、Raft），详细见本书第5章的共识算法。该类算法目前是联盟链和私有链链场景中常用的共识机制。 优点：实现秒级的快速共识机制，保证一致性。 缺点：去中心化程度不如公有链上的共识机制；更适合多方参与的多中心商业模式。 3.?解锁脚本 脚本是区块链上实现自动验证、自动执行合约的重要技术。每一笔交易的每一项输出严格意义上并不是指向一个地址，而是指向一个脚本。脚本类似一套规则，它约束着接收方怎样才能花掉这个输出上锁定的资产。 交易的合法性验证也依赖于脚本。目前它依赖于两类脚本：锁定脚本与解锁脚本。锁定脚本是在输出交易上加上的条件，通过一段脚本语言来实现，位于交易的输出。解锁脚本与锁定脚本相对应，只有满足锁定脚本要求的条件，才能花掉这个脚本上对应的资产，位于交易的输入。通过脚本语言可以表达很多灵活的条件。解释脚本是通过类似我们编程领域里的“虚拟机”，它分布式运行在区块链网络里的每一个节点。 比特币的脚本目前常用的主要分为两种，一种是普通的P2PKH（Pay-to-Public-Key-Hash），即支付给公钥的哈希地址，接收方只需要使用地址对应的私钥对该输出进行签名，即可花掉该输出。另一种是P2SH（Pay-to-Script-Hash），即支付脚本的哈希。以多重签名来举例，它要求该输出要有N把私钥中的M把私钥（M≤N）同时签名才能花掉该资产，它类似于现实生活中需要多把钥匙才能同时打开的保险柜，或是多人签名才能使条约生效一样，只是它是自动执行。 比如在比特币中，P2PKH的脚本规则如下： Pubkey script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG Signature script: <sig> <pubkey> P2SH的脚本规则如下： Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL Signature script: <sig> [sig] [sig...] <redeemScript> 在上述的两种脚本规则里，Pubkey script代表锁定脚本，Signature script代表解锁脚本。OP_开头的单词是相关的脚本命令，也是“虚拟机”所能解析的指令。这些命令规则根据Pubkey script的不同来进行划分，它也决定解锁脚本的规则。 比特币中的脚本机制相对简单，只是一个基于堆栈式的、解释相关OP指令的引擎，能够解析的脚本规则并不是太多，不能实现很复杂的逻辑。但它为区块链可编程提供了一个原型，后续一些可编程区块链项目其实是基于脚本的原理发展起来的，比如以太坊就是深入增强了脚本机制，脚本机制里不再单单是简单的OP指令，而是支持脚本的一套图灵完备语言，该脚本语言可以通过“虚拟机”去执行。以太坊实现了一个支持图灵完备脚本语言的区块链平台。 脚本的机制对于区块链来说非常重要，它类似于区块链技术提供的一个扩展接口，任何人都可以基于这个接口开发基于区块链技术的应用，比如智能合约的功能。脚本机制也让区块链技术作为一项底层协议成为可能。未来很多基于区块链的颠覆性应用，都有可能通过区块链的脚本语言来完成。 4.?交易规则 区块链的交易就是构成区块的基本单位，也是区块链负责记录的实际有效内容。一个区块链交易可以是一次转账，也可以是智能合约的部署等其他事务。 就比特币而言，交易即指一次支付转账。其交易规则如下： 1）交易的输入和输出不能为空。 2）对交易的每个输入，如果其对应的UTXO输出能在当前交易池中找到，则拒绝该交易。因为当前交易池是未被记录在区块链中的交易，而交易的每个输入，应该来自确认的UTXO。如果在当前交易池中找到，那就是双花交易。 3）交易中的每个输入，其对应的输出必须是UTXO。 4）每个输入的解锁脚本（unlocking script）必须和相应输出的锁定脚本（locking script）共同验证交易的合规性。 对于以太坊来说，交易还可能是智能合约的部署。交易规则就确定了符合一定语法规则的合约才能被部署在区块链上。 5.?交易优先级 区块链交易的优先级由区块链协议规则决定。对于比特币而言，交易被区块包含的优先次序由交易广播到网络上的时间和交易额的大小决定。随着交易广播到网络上的时间的增长，交易的链龄增加，交易的优先级就被提高，最终会被区块包含。对于以太坊而言，交易的优先级还与交易的发布者愿意支付的交易费用有关，发布者愿意支付的交易费用越高，交易被包含进区块的优先级就越高。 6.?Merkle证明 Merkle证明的原始应用是比特币系统（Bitcoin），它是由中本聪（Satoshi Nakamoto）在2009年描述并且创造的。比特币区块链使用了Merkle证明，为的是将交易存储在每一个区块中。使得交易不能被篡改，同时也容易验证交易是否包含在一个特定区块中，Merkle树说明详见4.2节。比特币的Merkle证明树如图2-11所示。 图2-11　比特币的Merkle证明树 Merkle树的一个重要使用场景就是快速支付验证，也就是中本聪描述的“简化支付验证”（SPV）的概念：轻量级节点（light client）不用下载每一笔交易以及每一个区块，可以仅下载链的区块头，每个区块中仅包含下述5项内容，数据块大小为80字节。 上一区块头的哈希值 时间戳 挖矿难度值 工作量证明随机数（nonce） 包含该区块交易的Merkle树的根哈希 如果一个轻客户端希望确定一笔交易的状态，它可以简单地要求一个Merkle证明，显示出一个在Merkle树特定的交易，其根是在主链（main chain，非分叉链）上的区块头。 Merkle证明可以让区块链得到更广阔的应用，但比特币的轻客户有其局限性。虽然可以证明包含的交易，但无法证明任何当前的状态（例如：数字资产的持有，名称注册，金融合约的状态等）。一笔交易影响的确切性质（precise nature）可以取决于此前的几笔交易，而这些交易本身则依赖于更为前面的交易，所以最终你需要验证整个链上的每一笔交易。为了解决这个问题，以太坊进行了更进一步的创新。 以太坊的每一个区块头中并非只包含一棵Merkle树，而是包含了3棵Merkle树（见图2-12），分别对应了以下3种对象： 交易（Transactions） 收据（Receipts，基本上，它是展示每一笔交易影响的数据条） 状态（State） 图2-12　以太坊的Merkle证明树 这三棵树允许轻客户端轻松地进行并核实以下类型的查询答案： 1）这笔交易被包含在特定的区块中了吗？ 2）告诉我这个地址在过去30天中，发出X类型事件的所有实例（例如，一个众筹合约完成了它的目标）。 3）目前我的账户余额是多少？ 4）这个账户是否存在？ 5）假装在这个合约中运行这笔交易，它的输出会是什么？ 第一种是由交易树（transaction tree）来处理的；第3和第4种则是由状态树（state tree）负责处理，第2种则由收据树（receipt tree）处理。计算前4个查询任务是相当简单的。在服务器简单地找到对象，获取梅克尔分支，并通过分支来回复轻客户端。第5种查询任务同样也是由状态树处理。 7.?RLP RLP（Recursive Length Pref?ix，递归长度前缀编码）是Ethereum中对象序列化的一个主要编码方式，其目的是对任意嵌套的二进制数据的序列进行编码。 以太坊中的所有数据都以“递归长度前缀编码”（Recursive Length Pref?ix encoding，RLP）形式存储，这种编码格式将任意长度和维度的字符串构成的数组串连接成字符串。例如，['dog', 'cat']被串接（以字节数组格式）为[130，67，100，111，103，67，99，97，116]；其基本的思想是把数据类型和长度编码成一个单独的字节放在实际数据的前面（例如‘dog’的字节数组编码为[100，111，103]，于是串接后就成了[67，100，111，103]）。注意RLP编码正如其名字表示的一样，是递归的；当RLP编码一个数组时，实际上是在对每一个元素的RLP编码级联成的字符串编码。需要进一步提请注意的是，以太坊中所有数据都是整数；所以，如果有任何的以一个或多个0字节开头的哈希或者地址，这些0字节应该在计算出现问题的时候去除。以太坊中没有串接数据结构包含任何以0开头的数值。整数以大端基础（Big Endian）256格式存储（例如32767字节数组格式为[127，255]）。 2.1.4　区块链交易流程 以比特币的交易为例，区块链的交易并不是通常意义上的一手交钱一手交货的交易，而是转账。如果每一笔转账都需要构造一笔交易数据会比较笨拙，为了使得价值易于组合与分割，比特币的交易被设计为可以纳入多个输入和输出，即一笔交易可以转账给多个人。从生成到在网络中传播，再到通过工作量证明、整个网络节点验证，最终记录到区块链，就是区块链交易的整个生命周期。整个区块链交易流程如图2-13所示。 图2-13　区块链交易流程 交易的生成。所有者A利用他的私钥对前一次交易和下一位所有者B签署一个数字签名，并将这个签名附加在这枚货币的末尾，制作成交易单。 交易的传播。A将交易单广播至全网，每个节点都将收到的交易信息纳入一个区块中。 工作量证明。每个节点通过相当于解一道数学题的工作量证明机制，从而获得创建新区块的权力，并争取得到数字货币的奖励。 整个网络节点验证。当一个节点找到解时，它就向全网广播该区块记录的所有盖时间戳交易，并由全网其他节点核对。 记录到区块链。全网其他节点核对该区块记账的正确性，没有错误后他们将在该合法区块之后竞争下一个区块，这样就形成了一个合法记账的区块链。 2.2　以太坊 2.2.1　什么是以太坊 自2008年比特币出现以来，数字货币的存在已经渐渐为一部分人所接受。人们也积极展开了基于比特币的商业应用的思考与开发。但是随着应用的扩展，人们发现比特币的设计只适合虚拟货币场景，由于存在着非图灵完备性、缺少保存状态的账户概念，以及PoW挖矿机制所带来的资源浪费和效率问题，在很多区块链应用场景下并不适用。人们需要一个新的基于区块链的具有图灵完备性、高效共识机制、支持更多应用场景的智能合约开发平台。以太坊在这种情况下应运而生。 以太坊的目的是对脚本、竞争币和链上元协议（on-chain meta-protocol）等概念进行整合和提高，使得开发者能够创建任意的基于共识的、可扩展的、标准化的、图灵完备的、易于开发和协同的应用。 以太坊是一个通用的全球性区块链，可以管理金融和非金融类型应用的状态。以太坊的新颖在于其神奇的计算机网络，它促成了一种新型的软件应用，真正的去中心化应用。将信任逻辑嵌入小程序里，运行在区块链上。而与比特币相比，以太坊建立了一种新的密码学技术基础框架，在其上开发应用更加容易，并对轻客户端友好，同时允许应用共享一个可行的经济环境和可靠的区块链安全。以太坊在全球范围内激发了商业和社会创新，为前所未有的去中心化应用打开了大门。从长远来看，它所带来的改变将影响全球经济和控制结构。 以太坊是个平台和编程语言，包括数字货币以太币（Ether），以及用来构建和发布分布式应用的以太脚本（EtherScript）。 以太币和著名的数字货币比特币有非常多的相似之处。两者均为数字货币且无法伪造，都以去中心化的方式运行来保证货币供应不被某一方所控制。以太坊的另一半重要特性是提供一个完整的编程语言环境，有时也被叫作以太脚本。我们都知道，编程语言是人类用来控制计算机工作的。因此，用任何编程语言写好的指令对计算机来说都是准确无误没有歧义的。也就是说，计算机如何执行一段代码是没有二义性的。在同样的条件下，一段代码总是会按照既定的步骤执行。这种特性正是人类现行法律与合约所缺失的。因此，有了以太脚本之后，我们就可以制定没有二义性的合约了。 从最底层角度来看，以太坊是一个多层的、基于密码学的开源技术协议。它的不同功能模块通过设计进行了全面的整合，作为一个整体，它是一个创建和部署去中心化应用的综合平台。虽然，以太坊看起来像由多个互相联系的开源项目构成的混合体，但是它的进化一直被明确目标所引导，所以各个组件可以协同地组装在一起。 同时，以太坊也是区块链与智能合约的完美结合，是智能合约的完整解决方案，被设计成了一个通用的去中心化平台，拥有一套完整的、可以扩展其功能的工具，在P2P网络、加密、HttpClient等技术的支持下实现了一个类似于比特币的区块链。它通过工作量证明机制实现共识，由矿工挖矿，通过对新的网络协议的制定实现对区块链的同步等操作。不同于比特币的是，在以太坊上可以任意编写智能合约，通过智能合约实现强大的功能，实现去中心化应用的开发。在以太坊上部署的智能合约运行在以太坊特有的虚拟机上，通过以太坊虚拟机和RPC接口与底层区块链进行交互。 以太坊的总体系统架构如图2-14所示。 图2-14　以太坊总体架构 2.2.2　以太坊技术 1.?以太坊核心概念 （1）以太坊虚拟机 以太坊虚拟机（EVM）是以太坊中智能合约的运行环境。它是以太坊项目中的另一个主要创新。有人说EVM“位于区块链之上”，实际上它是由许多互相连接的计算机组成的。任何人都可以上传程序，并让这些程序自动执行，同时保证现在和所有以前的每个程序的状态总是公共可见的。这些程序运行在区块链上，严格地按照EVM定义的方式继续执行。所以任何人都可以为所有权、交易格式和状态转换函数创建商业逻辑。 （2）账户 以太坊中有两类账户，它们共用同一个地址空间。外部账户，该类账户被公钥-私钥对控制。合约账户，该类账户被存储在账户中的代码控制。外部账户的地址是由公钥决定的，合约账户的地址是在创建合约时由合约创建者的地址和该地址发出过的交易数量计算得到。两类账户的唯一区别是：外部账户没有代码，人们可以通过创建和签名一笔交易从一个外部账户发送消息。每当合约账户收到一条消息，合约内部的代码就会被激活，允许它对内部存储进行读取、写入、发送其他消息和创建合约。 以太坊的账户包含4个部分：①随机数，用于确定每笔交易只能被处理一次的计数器；②账户目前的以太币余额；③账户的合约代码（如果有的话）；④账户的存储（默认为空）。 （3）消息 以太坊的消息在某种程度上类似于比特币的交易，但是两者之间存在3点重要的不同。 1）以太坊的消息可以由外部实体或者合约创建，然而比特币的交易只能从外部创建。 2）以太坊消息可以选择包含数据。 3）如果以太坊消息的接收者是合约账户，可以选择进行回应，这意味着以太坊消息也包含函数概念。 （4）交易 以太坊中“交易”是指存储从外部账户发出的消息的签名数据包。交易包含消息的接收者、用于确认发送者的签名、以太币账户余额、要发送的数据和被称为STARTGAS和GASPRICE的两个数值。为了防止代码出现指数型爆炸和无限循环，每笔交易需要对执行代码所引发的计算步骤做出限制。STARTGAS就是通过需要支付的燃料来对计算步骤进行限制，GASPRICE是每一计算步骤需要支付矿工的燃料的价格。 （5）Gas 以太坊上的每笔交易都会被收取一定数量的燃料Gas，设置Gas的目的是限制交易执行所需的工作量，同时为交易的执行支付费用。当EVM执行交易时，Gas将按照特定规则被逐渐消耗。Gas价格由交易创建者设置，发送账户需要预付的交易费用= GASPRICE * Gas amount。如果执行结束还有Gas剩余，这些Gas将被返还给发送账户。无论执行到什么位置，一旦Gas被耗尽就会触发一个out-of-gas异常。同时，当前调用帧所做的所有状态修改都将被回滚。 （6）存储、主存和栈 每个账户都有一块永久的内存区域，被称为存储，其形式为key-value，key和value的长度均为256位。在合约里，不能遍历账户的存储。相对于主存和栈，存储的读操作开销较大，修改存储甚至更多。一个合约只能对它自己的存储进行读写。 第二个内存区被称为主存。合约执行每次消息调用时都有一块新的被清除过的主存。主存可以按字节寻址，但是读写的最小单位为32字节。操作主存的开销随着主存的增长而变大。 EVM不是基于寄存器的，而是基于栈的虚拟机。因此所有的计算都在一个称为栈的区域内执行。栈最大有1024个元素，每个元素有256位。对栈的访问只限于其顶端，允许复制最顶端的16个元素中的一个到栈顶，或者是交换栈顶元素和下面16个元素中的一个。所有其他操作都只能取最顶的一个或几个元素，并把结果压在栈顶。当然可以把栈里的元素放到存储或者主存中。但是无法只访问栈里指定深度的那个元素，在那之前必须把指定深度之上的所有元素都从栈中移除才行。 （7）指令集 EVM的指令集被刻意保持在最小规模，以尽可能避免可能导致共识问题的错误。所有的指令都是针对256位这个基本的数据单位进行的操作，具备常用的算术、位、逻辑和比较操作，也可以进行条件和无条件跳转。此外，合约可以访问当前区块的相关属性，比如它的编号和时间戳。 （8）消息调用 合约可以通过消息调用的方式来调用其他合约，或者发送以太币到非合约账户。消息调用和交易非常类似，它们都有一个源，一个目标，数据负载，以太币，Gas和返回数据。事实上每个交易都可以被认为是一个顶层消息调用，这个消息调用会依次产生更多的消息调用。 一个合约可以决定剩余Gas的分配。比如内部消息调用时使用多少Gas，或者期望保留多少Gas。如果在内部消息调用时发生了out-of-gas异常或者其他异常，合约将会得到通知，一个错误码被压入栈中。这种情况只是内部消息调用的Gas耗尽。在solidity中，这种情况下发起调用的合约默认会触发一个人工异常，这个异常会打印出调用栈。 就像之前说过的，被调用的合约（发起调用的合约也一样）会拥有崭新的主存，并能够访问调用的负载。调用负载被存储在一个单独的被称为calldata的区域。调用执行结束后，返回数据将被存放在调用方预先分配好的一块内存中。调用层数被限制为1024。因此对于更加复杂的操作，我们应该使用循环而不是递归。 （9）代码调用和库 以太坊中存在一种特殊类型的消息调用，被称为callcode。它跟消息调用几乎完全一样，只是加载来自目标地址的代码将在发起调用的合约上下文中运行。这意味着一个合约可以在运行时从另外一个地址动态加载代码。存储，当前地址和余额都指向发起调用的合约，只有代码是从被调用地址获取的。这使得Solidity可以实现“库”。可复用的库代码可以应用在一个合约的存储上，可以用来实现复杂的数据结构，从而使智能合约更加的强大。 2.?以太坊的状态转换 以太坊的状态转换是指在一个交易（TX）发生时，以太坊从一个正确状态（S）转变到下一个正确状态（S’）的转换过程，如图2-15所示。对于交易而言，为了防止代码的指数型爆炸和无限循环，每笔交易需要对执行代码所引发的计算步骤做出限制。STARTGAS就是限制，GASPRICE是每一计算步骤需要支付矿工的费用价格。 图2-15　以太坊状态转换 以太坊的状态转换函数为APPLY(S, TX) -> S’，可以定义如下： 1）检查交易的格式是否正确，签名是否有效，以及随机数是否与发送者账户的随机数匹配。如否，返回错误。 2）计算交易费用fee = STARTGAS * GASPRICE，并从签名中确定发送者的地址。从发送者的账户中减去交易费用和增加发送者的随机数。如果账户余额不足，返回错误。 3）设定初值Gas = STARTGAS，并根据交易中的字节数减去一定量的燃料值。 4）从发送者的账户转移价值到接收者账户。如果接收账户还不存在，创建此账户。如果接收账户是一个合约，运行合约的代码，直到代码运行结束或者燃料用完。 5）如果因为发送者账户没有足够的费用或者代码执行耗尽燃料导致价值转移失败，恢复原来的状态，但是还需要支付交易费用，交易费用加至矿工账户。 6）若代码执行成功，将所有剩余的燃料归还给发送者，消耗掉的燃料作为交易费用发送给矿工。 例如，假设一个合约的代码如下： if !contract.storage[msg.data[0]]: contract.storage[msg.data[0]] = msg.data[1] 需要注意的是，在现实中合约代码是用底层以太坊虚拟机（EVM）代码写成的。上面的合约是用我们的高级语言Serpent语言写成的，它可以被编译成EVM代码。假设合约存储器开始时是空的，一个值为10以太、燃料为2000、燃料价格为0.001以太并且两个数据字段值为[2，'CHARLIE']的交易发送后，状态转换函数的处理过程如下： 1）检查交易是否有效，格式是否正确。 2）检查交易发送者是否至少有2000×0.001=2个以太币。如果有，从发送者账户中减去2个以太币。 3）初始设定Gas=2000，假设交易长为170字节，每字节的费用是5，减去850，所以还剩1150。 4）从发送者账户减去10个以太币，为合约账户增加10个以太币。 5）运行代码。在这个合约中，运行代码很简单：它检查合约存储器索引为2处是否已使用，注意到它未被使用，然后将其值置为CHARLIE。假设这消耗了187单位的燃料，于是剩余的燃料为1150-187 = 963。 6）向发送者的账户增加963×0.001=0.963个以太币，返回最终状态。 如果没有合约接收交易，那么所有的交易费用就等于GASPRICE×交易的字节长度，交易的数据就与交易费用无关了。另外，需要注意的是，合约发起的消息可以对它们产生的计算分配燃料限额，如果子计算的燃料用完了，它只恢复到消息发出时的状态。因此，就像交易一样，合约也可以通过对它产生的子计算设置严格的限制，保护它们的计算资源。 3.?以太坊客户端 为了测试各种语言对以太坊的支持，同时使更多的人能够参与以太坊的开发及使用，目前有4种语言编写的以太坊的客户端。它们分别是用Go语言实现的客户端Geth，用C++实现的客户端Eth，用Python语言实现的客户端Pyethapp和用Java实现的客户端EthereumJ。其中，Go语言版是以太坊官方一直维护并推荐使用的客户端。 以太坊包括一个专用的客户端浏览器，使得用户可以运行各种各样的去中心化应用（DApp），发布智能合约。这一浏览器被称为Mist，它易于使用，降低了用户使用门槛，从而使得DApp和智能合约能够被大量用户使用。它的作用等同于浏览器之于互联网或者iTunes之于数字化内容下载。Mist由特殊的安全层、密钥管理、去中心化账户管理和与区块链相关的组件几部分组成。这一切使得Mist成为普通用户运行或者管理区块链去中心化应用不可或缺的工具，普通用户不需要理解技术方面的东西。 从用户体验角度而言，可以在Mist中使用DApp，就像通过常规浏览器与网站进行交互一样。例如，一个纯DApp（例如预测市场Augur）就可以在以太坊Mist浏览器中运行。当然，这些服务也可以通过一个常规浏览器以更加传统的Web 2.0的方式实现。 2.2.3　以太坊智能合约 1.?智能合约 智能合约是由尼克萨博提出的理念，几乎与互联网同龄。但是由于缺少可信的执行环境，智能合约并没有被应用到实际产业中。自从比特币诞生后，人们认识到比特币的底层技术区块链天生可以为智能合约提供可信的执行环境，以太坊首先实现了区块链和智能合约的完整契合。 以太坊是内置有图灵完备编程语言的区块链，通过建立抽象的基础层，使得任何人都能够创建合约和去中心化应用，并在其中设立他们自由定义的所有权规则、交易方式和状态转换函数。建立一个代币的主体框架只需要两行代码就可以实现，诸如货币和信誉系统等其他协议只需要不到20行代码就可以实现。智能合约就像能在以太坊的平台上创建的包含价值而且只有满足某些条件才能打开的加密箱子，并且因为图灵完备性、价值意识（value-awareness）、区块链意识（blockchain-awareness）和记录多状态所增加的功能而比比特币脚本所能提供的智能合约强大得多。 2.?开发语言 以太坊的软件开发语言是其最大特性之一，因为对区块链进行编程是一项首要目标。以太坊具有4种专用语言：Serpent（受Python启发）、Solidity（受JavaScript启发）、Mutan（受Go启发）和LLL（受Lisp启发），都是为面向合约编程而从底层开始设计的语言。 作为以太坊的高级编程语言，Serpent的设计非常类似于Python。它被设计为最大可能地简洁和简单，将低级语言的高效优势与编程风格中的易用性相结合。 Solidity是以太坊的首选语言，它内置了Serpent的所有特性，但是语法类似于JavaScript。Solidity充分利用了现有数以百万程序员已掌握JavaScript这一现状，降低了学习门槛，易于被掌握和使用。 以太坊区块链的另一关键特征是它的“图灵完备性”，这保证了以太坊可以解决所有的计算问题。更加准确地说，它是“半”图灵完备的，因为它是通过对计算量设置上限，它避免了完全图灵完备语言存在的无法停机问题。此外，因为以太坊的语言是为区块链专门设计的，它有账户的概念，使得它在交易的可视化和查询账户状态方面提供了实时性。这是一个受人欢迎的功能，但对比特币而言实现起来具有一定的挑战。在比特币上，由于只有UTXO而没有账户的概念，我们需要导入区块链数据库，解析所有的交易，并为了抽取出在区块链上的某个用户的交易情况而查询交易。而用以太坊，我们则可以在实时的区块链上，根据一个地址情况实时查看当前账户情况和交易状态。 3.?代码执行 以太坊合约的代码是使用低级的基于堆栈的字节码的语言写成的，被称为“以太坊虚拟机代码”或者“EVM代码”。代码由一系列字节构成，每一个字节代表一种操作。一般而言，代码执行是无限循环，程序计数器每增加一（初始值为零）就执行一次操作，直到代码执行完毕或者遇到错误、STOP或者RETURN指令。操作可以访问3种存储数据的空间： 1）堆栈，一种后进先出的数据存储，入栈、出栈的基本单位为32字节。 2）内存，可无限扩展的字节队列。 3）合约的长期存储，一个密钥/数值的存储，其中密钥和数值都是32字节大小。与计算结束即重置的堆栈和内存不同，存储内容将长期保持。 代码可以像访问区块头数据一样访问数值、发送和接收到的消息中的数据，代码还可以返回数据的字节队列作为输出。EVM代码的正式执行模型非常简单。当以太坊虚拟机运行时，它的完整的计算状态可以由元组（block_state，transaction，message，code，memory，stack，pc，gas）来定义，这里block_state是包含所有账户余额和存储的全局状态。每轮执行时，通过调出代码的第pc（程序计数器）个字节，每个指令如何影响元组都有定义。例如，ADD将两个元素出栈并将它们的和入栈，将Gas减1并将pc加1；stack将顶部的两个元素出栈，并将第2个元素插入由第1个元素定义的合约存储位置，同样减少最多200的Gas值，并将pc加1。虽然有许多方法通过即时编译去优化以太坊，但以太坊的基础性的实施可以用几百行代码实现。 2.2.4　以太坊的去中心化应用 1.?什么是DApp 一个DApp是由智能合约和客户端代码构成的。智能合约就像加密的包含价值的箱子。只有当特定条件被满足时它才被打开，它封装了一些逻辑、规则、处理步骤或者双方间的协议。 从架构角度而言，DApp非常类似于传统的Web应用。主要区别是：在传统Web应用中，客户端有JavaScript代码，由用户在自己的浏览器中执行；服务器端的代码由主机运行。但是在一个DApp中，它的智能逻辑运行在区块链上，客户端代码运行在特殊浏览器Mist里面。 2.?应用举例 正如苹果电脑公司的App Store给众多公司和个人提供了极佳的商业机会一样，以太坊这样的平台上一定会出现类似“愤怒的小鸟”这样的成功范例，对于IT导向的创业公司和个人，这是一个广阔的空间。下面举几个例子，看看这个空间中正在孕育的项目。 Augur（www.augur.net），一个正在开发去中心化预测系统。Augur在英文中的意思是“预言家”，用户可以在这个应用上对各种事件打赌并下注，例如希拉里会不会赢得2016年美国的大选；2016年中国的GDP增长会不会超过7%；上证指数2020年之前会不会超10000点，等等。对于参与者而言，如果预测正确，则将获得经济上的回报；而对于社会整体而言，Augur便成了一个群体智慧的收集器，在它上面的下注信息反映了人们对于未来某事件发生可能性的最佳评估。当你打开搜索引擎，输入“×××会不会赢得2020年美国的大选”的时候，可能搜到这样的结果：“Augur：该事件发生的可能性为46.6%”。 Maker（www.makerdao.com），一个正在开发中的金融类去中心化自治组织。Maker是一个去中心化自治组织（Decentralized Autonomous Organization，DAO），它维护一系列用于金融服务的合约软件（即智能合约），其中的一个软件是贷券信贷系统（The Dai Credit System）。贷券信贷系统是一个通过抵押进行借贷的应用，当用户在区块链上拥有众多资产时，一个必然的需求就是，在不出售资产的情况下通过抵押借款获得资金，类似于房屋抵押贷款。 WeiFund，一个正在开发中的去中心化众筹平台。这个众筹平台的好处是资金不需要第三方托管，而是由程序托管，因此能够确保资金100%安全。如果在限定时间内众筹项目的资助超过预定目标，则程序将资金发送给创业者；如果目标未达到，则将资金退回给众筹参与者。 Boardroom，一个正在开发中的DAO管理平台。去中心化自治组织与传统公司一样，也可以有股份的概念，通常就是DAO的代币，这些代币又可以有投票权。与上一个例子中的WeiFund结合，可以发生有趣的事：如果众筹募资的目标达到，则WeiFund可以将资金发送给Boardroom，并将该众筹项目的参与者组成DAO。如此一来，这些参与者便可以通过投票来控制资金的具体使用，而不是简单地将资金一次性发放给创业者，这样便大大避免了来自创业者的道德风险。 Ujo Music，一个音乐版权管理平台，测试版。Ujo Music作为音乐版权管理平台，可以直接在歌曲的创作者与消费者之间建立直接的联系，从而省去了中间商的费用提成。更进一步，歌手甚至可以将自己的作品在WeiFund上进行IPO上市，如此一来，持有歌手代币的投资者就会分得歌手今后歌曲的销售收入，他们是歌手天然的铁杆粉丝团。帮助歌手推广音乐也不仅仅出于经济动机，同时也是出于情感上的支持，试想在周杰伦默默无闻的时候就持有他的代币，该是一件多么令粉丝感到骄傲的事。同时代币也是歌手与粉丝团之间互动的媒介，例如歌手可以让持有代币的粉丝优先购买演唱会的门票，如此，粉丝经济会更加红火。 贷券（Decentralized Autonomous Insured Bond）简称Dai或者Dai Bond，是一种可转让的、彼此等价可互换的“加密债券”，它流通于信贷系统中，使用者无需事先认证，同时又是低风险的。贷券的发行人（借款方）将在以太坊区块链上的以太等数字加密资产作为抵押品来发行贷券，再将这些贷券在市场上卖给贷券持有人以换回流动性好的资产。贷券的持有人之所以买入贷券是为了赚取收益，或者是为了将贷券当作价值稳定的加密货币来流通使用。 2.3　基于区块链的电子货币 2.3.1　元币平台 元币（metacoin）单词前缀“meta-”意为“在其中”。所以元币是衍生于现有加密货币体系之上，更专注于业务系统的代币种类。 （1）彩币 彩币（Colored Coins）是一种建立在比特币数据块上的高级衍生应用协议。彩币建立在P2P网络之上，具有去中心化的所有优势，可以用来进行任何虚拟财产和现实资产的交易，并且比传统金融交易更加快捷和方便，更重要的是，它没有手续费。彩币由一种特殊的钱包负责管理，进行记录和阐释附加在彩币中的元数据。通过这种钱包，用户可以通过添加标签，将一定量的比特币转化为彩币，使其具有特殊意义。而这种特殊意义，往往使其价值提升。相关元数据是由用户来定义的，并且使比特币转化为彩币。彩币一旦定义，便可以进行买卖、分销、积累或者分红。当然，也可以去颜色化，回归比特币。 （2）万事达币 万事达币（mastercoin）发布于2013年6月24日，是建立在比特币协议之上的二代币，旨在帮助用户创建并交易加密货币以及其他类型的智能合同。万事达币不仅仅是一种代币，更像是一个去中心化的财产交易、合同签署、用户货币、智能财产代币等的平台。打个形象的比方，就像HTTP运行在TCP层之上一样，万事达币是工作于比特币交易层之上的应用层协议。 （3）合约币 合约币（counterparty）是另一种建立在比特块链基础之上的协议层，它把比特币块链当成可信的时间戳服务和可信的信息发布证明。合约币在比特币中添加额外的信息记录，以此强化比特币的交易。合约币实现了用户货币、可交易代币、财经工具、去中心化交易等一些功能。 2.3.2　代币 尽管部分代币没有使用比特币，而是直接在区块链的基础上全新创建的，但事实上，大多数代币都是比特币衍生出来的。其中最值得一提的是莱特币（Litecoin），而莱特币本身又被作为代币的母币，衍生出更多新的代币。以同样方式诞生的还有代链这个概念。如同字面意思，两者的区别在于，代币用作货币目的，而代链用于非货币目的。本节介绍内容属于代币范畴。 代币的创建过程非常简单。2011年8月，通过修改比特币的一些参数，加速货币的产生速度，世界上第一种代币IXCoin诞生。自此以后，代币发展极其迅速。到2016年，已经有超过600种代币发布，并且，大部分是莱特币的变种。它们与比特币的差异主要存在于货币政策、工作量证明和共识机制以及所引入的新特性方面。其实，大多数代币之间差异甚微，甚至，有些代币的产生，只是发明者为了增加收入的一种手段，并不具备研究价值。但是，这些代币中还是有一些比较明显的例外，或者说有非常重要的创新值得我们学习。那么如何衡量一种代币呢？通常从如下几个方面思考：是否具有重大创新？是否能因为与比特币的区别从比特币吸引过来用户？是否针对市场或者应用？是否能吸引足够多的矿工来抵御联合作弊？财经和市场指标上，又可以从资本量、预计用户量、日交易量和流通性上来评价一种代币。 1.?通过货币参数修改而建立的代币 比特币有一些货币参数来预防货币通货膨胀。比特币限制为2100万主要货币单元的货币总量。许多代币修改了比特币的主要参数，从而实现了新的不同货币政策。最具代表性的有如下几种。 （1）莱特币 要介绍莱特币（Litecoin），就不得不提Tenebrix，它是第一个应用不同工作量证明算法的加密货币。此算法被称作scrypt，是专门为预防暴力破解密码而设计的。Tenebrix并没有成功，却为莱特币的诞生奠定了基础。作为主要的成功代币，莱特币的核心是继承了scrypt算法，修改了块产生时间，使之从比特币的10分钟缩短到2.5分钟，从而成为一种轻型代币。拥护者们认为，相对于比特币，莱特币更适合零售业的交易。更重要的是，以莱特币为基础，后来延伸出来上百种类似的代币。 提示： 块产生时间，2.5分钟；总货币量，8400万（2140年）；共识算法，工作量证明Scrypt；市值， 96 961万元（2016年年中）。 （2）狗狗币 作为莱特币的变种，狗狗币（Dogecoin）发布于2013年12月。狗狗币的货币政策特点是发行迅速，货币配额巨大。 提示： 块产生时间，1分钟；总货币量，10?000亿（2016年年中）；共识算法，工作量证明Scrypt；市值，8201万元（2016年年中）。 （3）运输币 运输币（Freicoin）发布于2012年7月，是一种滞期代币。其储存额具有负利率。运输币不鼓励持有，它收取4.5%的年费来促进消费。运输币之所以出名，是因为它所采用的货币政策与比特币的通货紧缩政策完全相反。作为代币，运输币并没有取得成功，却成为了供代币借鉴的多样性货币政策的重要一员。 提示： 块产生时间，10分钟；总货币量，1亿（2140年）；共识算法，工作量证明SHA256；市值，13万美元（2014年年中)。 2.?基于共识机制的创新而建立的代币 比特币的共识机制是建立在用SHA256算法加密的作业证据基础之上的。从此，共识机制的创新进入了一个狂热的发展阶段。一些代币采用了各式各样的算法，如：Scrypt、Scrypt-N、Skein，Groestl、SHA3、X11、Blake等。还有的代币同时采用其中的几种算法。2013年，作为工作量证明的替代品，权益证明（Proof of Stake）被提出，为许多新代币的诞生提供了基础。权益证明系统中，拥有者可以将货币像股票一样抵押生息。它在某种程度上类似于存款证明，持有者可以保留所持货币的一部分，同时，以利息支付和交易费的形式赚取投资回报。 （1）点点币 点点币（Peercoin）诞生于2012年8月，是第一种综合使用工作量证明和权益证明机制来发行新币的代币。 提示： 块产生时间，10分钟；总货币量，不限；共识算法，工作量证明机制与权益证明结合；市值，5825万元（2016年年中）。 （2）Myriad Myriad发行于2014年2月，具有复合算法的特性，是第一个同时包含5种算法的加密货币。与比特币只能使用SHA256矿机挖矿不一样，Myriad兼容SHA256、Scrypt等算法，同时兼容GPU及CPU挖矿。Myriad对共识攻击具有更强的抵抗力，这是因为只有多种挖矿算法同时被攻击时才会受到攻击。 提示： 块产生时间，平均0.5分钟；总货币量，20亿（2024年）；共识算法，工作量证明机制与多算法共用；市值， 12万美元（2014年年中）。 （3）黑币 发行于2014年2月的黑币（Blackcoin）使用权益证明作为共识算法。黑币走进人们的视野是因为它引入了多池这种可以根据利润差异在不同代币间自动切换的挖矿池。 提示： 块产生时间，1分钟；总货币量，不限；共识算法，权益证明；市值，1125万元（2016年年中）。 （4）维理币 维理币（VeriCoin）发行于2014年5月。它使用权益证明共识机制，并且采用根据市场供求动态调节的利率。同时，维理币也是第一种可以自动兑换成比特币的代币。 提示： 块产生时间，1分钟；总货币量，不限；共识算法，权益证明；市值，390万元（2016年年中）。 （5）未币 未币（NXT）彻底抛弃工作量证明，而仅仅使用权益证明共识机制，故NXT是一种全新的加密货币，因此不应称之为比特币的变种或者代币。NXT具有许多先进特性，如：名称注册、去中心化的财产交易、整合分散的安全消息、股票代表等。因此，NXT常被称作下一代数字加密货币。 提示： 块产生时间，1分钟；总货币量，不限；共识算法，权益证明；市值，3816万元（2016年年中）。 3.?通过双目标挖矿机制创新而建立的代币 比特币的工作量证明算法仅仅具有一个目的，那就是确保比特链的安全。尽管相对于传统支付系统的安全，这点挖矿开销并不高，但是被指是一种浪费。双目标工作量证明算法在产生工作量证明来满足安全的同时，解决一个具体的问题。但这样做也带来一定的风险。在向货币安全添加额外功能的同时，也影响了其供求曲线。 （1）质数币 质数币（Primecoin）发行于2013年7月，据称其“具有数学价值”。这种币尝试把虚拟货币中无目的的算法所浪费的资源利用起来。质数币的工作量证明机制有一定的科学价值。所以从某种意义上讲，质数币的矿工在挖矿的同时也促进了科学的进步。质数币是没有总量上限的。但是，质数币的产生速度很慢，这与大质数的计算困难特性有关。 提示： 块产生时间，1分钟；总货币量，不限；共识算法，工作量证明和质数链发现；市值，533万元（2016年年中）。 （2）治疗币 治疗币（Curecoin）发行于2013年5月。它将SHA256工作量证明算法与蛋白质折叠研究相结合，强调对生命科学和医学的贡献。其中蛋白质折叠是蛋白质生化反应的计算密集型模拟，目的在于发现新药。 提示： 块产生时间，10分钟；总货币量，不限；共识算法，工作量证明和蛋白质折叠研究；市值，194万元（2016年年中）。 （3）格雷德币 格雷德币（Gridcoin）发行于2013年10月。它支持基于scrypt的工作量证明算法。格雷德币通过伯克利的分布式计算项目（BOINC）进行包罗万象的科学探索，只有在挖矿的同时运行BOINC才能够获得较多的币。BOINC是一种科研网格计算的开放协议，允许参与者贡献自己的空余计算力来进行一系列科研计算。所以，不同于质数币和治疗币那样目的单一，格雷德币可以通过BOINC这个计算平台帮助进行各种科学研究，包括寻找外星人、计算RNA结果等。 提示： 块产生时间，2.5分钟；总货币量，不限；共识算法，工作量证明和BOINC网格计算；市值，2858万元（2016年年中）。 4.?注重隐私性的代币 比特币常常被误认为具有隐私性。事实上，通过大数据分析，关联身份和比特币地址相对容易，从而通过连接彼此的地址，解析一个人的比特币消费习惯。所以，一些代币专注于强隐私性，试图直接解决此问题。 （1）零币 零币（Zerocoin）作为比特币之上保持隐私性的元币协议，是针对隐私性的第一个尝试。它诞生于2013年，仅是一种针对数字货币隐私性的理论方法。应用零币理论的代币叫作Zerocash，至今仍在研究阶段，并未发行。 （2）CryptoNote CryptoNote公布于2012年12月，是一种为匿名数字货币提供基础的参考实践代币。它的设计初衷就是为了不同的实践并且内置定时重置机制，这使得它本身不太可能成为一种货币。CryptoNote的出名还来自于它不是比特币的翻版，而是全新从头设计实践的加密货币。基于CryptoNote衍生出来的数字货币还有Bytecoin（BCN）、Aeon（AEON）、Boolberry（BBR）、DuckNote（DUCK）、Fantomcoin（FCN）、Monero（XMR）、MonetaVerde（MCN）和Quazarcoin（QCN）等。更详细的CryptoNote衍生代币请见网页https://en.wikipedia.org/wiki/File:Forks-tree-f?ixed.png。 （3）百特币 百特币（Bytecoin）发行于2012年7月，是第一个衍生自CryptoNote的代币（比CryptoNote本身的发行早）。百特币基于CryptoNote技术，提供一种可行的匿名货币。它从CryptoNote继承了环签名、非连接交易和抵制区块链分析的隐私性。之后，百特币还进行了包括多签名交易、安全更新等方面的改进。 提示： 块产生时间，2分钟；总货币量，1.84亿元；共识算法，工作量证明Cryptonight；市值， 2909万元（2016年年中）。 （4）门罗币 门罗币（Monero，XMR）是CryptoNote的另外一种应用。相比于百特币，它具有略微平坦的发行曲线，在前4年就发行了80%。它继承了CryptoNote所有的隐私性。 提示： 块产生时间，1分钟；总货币量，1844万元；共识算法，工作量证明Cryptonight；市值，2622万元（2016年年中）。 （5）黑暗币 黑暗币（Darkcoin）发布于2014年1月。作为匿名货币，它对所有交易采用一种叫作DarkSend的再混合协议。另外，黑暗币的出名还在于它在工作量证明算法中使用了11种不同的哈希函数（blake、bmw、groestl、jh、keccak、skein、luffa、cubehash、shavite、simd、echo）。 提示： 块产生时间，2.5分钟；总货币量，2200万（2016年年中）；共识算法，作业证明多算法共用；市值，1900万美元（2014年年中）。 2.3.3　货币的未来 加密货币的未来整体来说比比特币更加繁荣。它们在比特币的基础上引进了全新的去中心化的组织形式和共识机制，并由此衍生出了数以百计的不可思议的创新。这将影响与经济相关的众多部门，如：财政、经济、货币、中央银行、企业管理等。 许多之前需要中心机构来执行授权或信用控制的活动，现在可以去中心化了。区块链和共识机制的发明，在根除权力集中、腐败、监管俘获的同时，必将大幅度削减组织和大规模系统协调的费用。 2.4　本章小结 本章主要介绍了区块链技术的基础知识。首先，介绍了区块链技术，这是这本书的基础，包括区块链技术的基本概念、框架与特点，核心技术及交易流程。在这个基础之上，我们详细介绍了区块链技术最成功的应用——比特币，包括概念、原理、及隐私模型。之后，我们介绍了区块链的另外一个重要应用——以太坊。以太坊是区块链技术发展的一个重要的方向，是区块链技术未来的一部分。我们介绍了以太坊技术、以太坊智能合约、以太坊去中心化应用、以太坊发展的现状及未来。最后，我们分析了现有的流行的电子货币各自的优缺点。 参考资料 ［1］ 袁勇，王飞跃.区块链技术发展现状与展望[J].自动化学报，2016，42(4). ［2］ Antonopoulos A M. Mastering Bitcoin: Unlocking Digital Crypto-Currencies[J]. Oreilly Media Inc Usa, 2015. ［3］ Swan M. Blockchain: blueprint for a new economy[M]. O'Reilly, 2015. ［4］ 以太坊（Ethereum）：下一代智能合约和去中心化应用平台.以太坊爱好者，2016-06-23. ［5］ Deutsch Bank, Banking & Technology Snapshot, DB Research, 20 December 2012. ［6］ Vatalik Buterin, Merkling-in-Ethereum, https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/.