如何用最短的时间理解一项数字技术？推荐这7本最新的白皮书（大数据、云原生、区块链、联邦学习等，附下载）

信息技术、数据被国家认定为新的生产要素，对于数据从业者来说是时代赋予的巨大红利，但也要认识到，数据要素要发挥出价值，离不开数据要素市场的培育，更依赖于信息技术（大数据、人工智能、区块链、云计算、边缘计算、物联网等）的加持。

为了抓住这难得的的机遇，数据从业者除了掌握必要的数据管理技能外，也要突破专业的限制，对最新的数字技术有所理解，这样才能挥斥方遒，推进数字技术的融合创新，从而更好的发挥出数据要素的价值。

那么，如何了解这些最新的数字技术呢？

笔者的感觉是，如果总是从一个点切入去理解这些技术，虽然比较具体，但往往成了盲人摸象，很难形成一个体系化的认知，而《白皮书》则为理解某个技术的全貌提供了很好的指引。

自己最近连续学习了七本最新的白皮书，分别是《大数据白皮书（2020）》、《云计算发展白皮书（2020）》、《云原生架构白皮书》、《云原生中间件白皮书（2020）》、《联邦学习白皮书V2.0》、《区块链白皮书（2020）》、《数字孪生白皮书（2020）》，受益匪浅，本文针对每本白皮书的核心内容做了摘录，如果你对相关内容感兴趣，可以下载下来仔细读一读（文末有全部白皮书的下载地址）。

一、信通院《大数据白皮书（2020）》

这本白皮书给出了下面这张大数据技术全景图，很有价值。有两篇文章专门做了解读，一篇是《万字长文解读最新最全的大数据技术体系图谱！》，主要讲了主流的大数据技术和产品，另一篇是《如何理解《2020年大数据白皮书》的大数据技术最新发展趋势？》，介绍了存算分离、数据分析能力服务化、数据管理自动化智能化、图分析及隐私计算五个技术趋势。

二、信通院《云计算发展白皮书（2020）》

这本《白皮书》给出了云计算发展的四个趋势，分别是云原生的大幅进化、云需求从IaaS 向SaaS 上移、云布局从中心向边缘延伸及云定位从基础资源向基建操作系统扩展。

1、云原生推进云计算从粗放向精细转型

过去十年，云计算技术快速发展，云的形态也在不断演进。基于传统技术栈构建的应用包含了太多开发需求，而传统的虚拟化平台只能提供基本运行的资源，云端强大的服务能力红利并没有完全得到释放。随着云原生技术进一步成熟和落地，用户可将应用快速构建和部署到与硬件解耦的平台上，使资源可调度粒度越来越细、管理越来越方便、效能越来越高。

容器和微服务的组合为云原生应用开发提供了基本的底层架构。在此基础上，当前云原生技术关注点逐渐上移，云原生中间件、服务网格、无服务器等技术使用户更加聚焦业务逻辑，最大化应用开发的价值。

（1）云原生中间件

指在公有云、私有云和混合云等新型动态环境中，用于构建和运行可弹性扩展的应用，持续交付部署业务生产系统的分布式中间件。云原生时代的中间件延续了传统中间件的功能，不同之处在于其将功能从应用中剥离，在运行时为应用动态赋能，比如Kafka等等。

（2）服务网格（Service Mesh）

主要是为了解决众多微服务间通信的性能瓶颈问题，其重新构建了服务间通信模式，给云原生应用开发者带来更好的开发和维护体验，加速业务的创新效率，服务网格可以认为是微服务的TCP/IP协议。

（3）无服务器（Serverless）

Serverless 是一种软件系统架构思想和方法，它的核心思想是开发者使用Serverless 无须关注底层资源，而只需关注业务应用的开发，即用户只需要关注函数这个实现业务逻辑的最小单元，无需关注和业务不相关的资源申请和资源运维等工作，从而缩短流程，节省的运维人力可以投入到研发，提高研发效率，缩短业务上线时间。

（4）数字中台

数字中台为业务而生，包括了数据中台、业务中台和技术中台。业务中台需要微服务、云原生、分布式事务体系支撑，并设计业务模型和微服务边界，最终形成业务单元；数据中台引入多终端、多形态数据，采用数据分层架构模式，同时需要指标管理、数据服务、元数据管理等一系列的数据管理技术做支撑。云原生技术为数字中台建设提供了强有力的技术支撑，形成了数字中台建设的技术底座，为企业数字化转型和业务能力沉淀赋能。

2、云需求从IaaS 向SaaS 上移

伴随企业上云进程不断深入，企业用户对云服务的认可度逐步提升，对通过云服务进一步实现降本增效提出了新诉求。企业用户不再满足于仅仅使用基础设施层服务（IaaS）完成资源云化，而是期望通过应用软件层服务（SaaS）实现企业管理和业务系统的全面云化。未来，SaaS 服务必将成为企业上云的重要抓手，助力企业提升创新能力。

3、云布局从中心向边缘延伸

随着5G、物联网等技术的快速发展和云服务的推动使得边缘计算备受产业关注，但只有云计算与边缘计算通过紧密协同才能更好地满足各种需求场景的匹配，从而最大化体现云计算与边缘计算的应用价值。未来，随着新基建的不断落地，构建端到端的云、网、边一体化架构将是实现全域数据高速互联、应用整合调度分发以及计算力全覆盖的重要途径。

4、云定位从基础资源向基建操作系统扩展

在企业数字化转型的过程中，云计算被视为一种普惠、灵活的基础资源，随着新基建定义的明确，云计算的定位也在不断变化，内涵也更加丰富，云计算正成为管理算力与网络资源，并为其他新技术提供部署环境的操作系统。未来，云计算将进一步发挥其操作系统属性，深度整合算力、网络与其他新技术，推动新基建赋能产业结构不断升级。

三、阿里云《云原生架构白皮书》

关于云原生没看过瘾，因此特意找了阿里云不久前发布的《云原生架构白皮书》来读，下面是《白皮书》的目录，干货满满，大家一定要读一读。

1、云原生架构定义

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

上图展示了在代码中通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码；“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库；“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。

云原生架构相比较传统架构进了一大步，从业务代码中剥离了大量非功能性特性（不会是所有，比如易用性还不能剥离）到 IaaS 和 PaaS 中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。

2、云原生架构原则

阿里总结了七大原则，分别是服务化原则、弹性原则、可观测原则、韧性原则、所有过程自动化原则、零信任原则、架构持续演进原则，非常通俗易懂。

3、主要架构模式

（1）服务化架构模式

云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合 DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。

通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级，从而提升了整体的迭代效率。

（2）Mesh 化架构

就是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的Client部分，Client 通常很少变化，只负责与 Mesh 进程通讯，原来需要在SDK中处理的流量控制、安全等逻辑由 Mesh 进程完成。整个架构如下图所示。

（3）Serverless 模式

和大部分计算模式不同，Serverless 将“部署”这个动作从运维中“收走”，使开发者不用关心应用在哪里运行，更不用关心装什么 OS、怎么配置网络、需要多少 CPU。架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。

（4）存储计算分离模式

分布式环境中的CAP困难主要是针对有状态应用，因为无状态应用不存在C（一致性）这个维度，因此可以获得很好的A（可用性）和P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，则可以考虑通过采用 Event Log + 快照（或 Check Point）的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。

（5）分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。

（6）可观测架构

包括Logging、Tracing、Metrics三个方面，其中Logging提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；Tracing 提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。

（7）事件驱动架构（EDA，Event Driven Architecture）

本质上是一种应用/ 组件间的集成架构模式，事件和传统的消息不同，事件具有schema，所以可以校验event 的有效性，同时EDA 具备QoS保障机制，也能够对事件处理失败进行响应。典型的事件驱动架构如下图：

4、云原生技术

（1）容器技术

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

（2）微服务

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。

微服务架构经历了四代，2016 年出现了第三代微服务架构 - 服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到丰富的服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等。

（3）Serverless

随着以 Kubernetes为代表的云原生技术成为云计算的容器界面，Kubernetes成为云计算的新一代操作系统。面向特定领域的后端云服务（BaaS）则是这个操作系统上的服务 API，存储、数据库、中间件、大数据、AI 等领域的大量产品与技术都开始提供全托管的云形态服务，如今越来越多用户已习惯使用云服务，而不是自己搭建存储系统、部署数据库软件。当这些 BaaS 云服务日趋完善时，Serverless 因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless 计算包含全托管的计算服务、通用性、自动的弹性伸缩及按量计费四大特征。

（4）开放应用模型（OAM）

容器技术以“彻底改变了软件打包与分发方式”迅速得到大量企业的广泛使用。不过软件打包与分发方式的革新，并没有能够让软件本身的定义与描述发生本质变化；基于 Kubernetes 的应用管理体验，还没有让业务研发与运维的工作变得足够简单。

最典型的例子，Kubernetes 至今都没有“应用”这个概念，它提供的是更细粒度的“工作负载”原语，比如 Deployment 或者 DaemonSet。在实际环境中，一个应用往往由一系列独立组件组成，比如一个“PHP 应用容器”和一个“数据库实例”组成电商网站；一个“参数服务节点”和一个“工作节点”组成机器学习训练任务。

OAM 的一个设计目标就是补充“应用”这一概念，建立对应用和它所需的运维能力定义与描述的标准规范。换而言之，OAM 既是标准“应用定义”同时也是帮助封装、组织和管理 Kubernetes 中各种“运维能力”。

在具体设计上，OAM 的描述模型是基于 Kubernetes API 的资源模型（Kubernetes Resource Model）来构建的，它强调一个现代应用是多个资源的集合，而非一个简单工作负载。

例如在 PHP 电商网站的 OAM语境中，一个 PHP 容器和它所依赖的数据库以及它所需要使用的各种云服务，都是一个“电商网站”应用的组成部分。同时，OAM 把这个应用所需的“运维策略”也认为是应用的一部分，比如这个 PHP 容器所需的HPA（水平自动扩展策略）。

例如，一个由 PHP 容器和 Redis 实例组成的应用，在 OAM 的框架和规范下，就可以用如下的示意图来表达出来：

（5）Service Mesh 技术

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。

这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，Service Mesh 以无侵入的方式实现了应用轻量化，下图展示了Service Mesh 的典型架构：

在这张架构图中，Service A 调用 Service B 的所有请求，都被其下的 Proxy（在 Envoy 中是 Sidecar） 截获，代理 Service A 完成到 Service B 的服务发现、熔断、限流等策略，而这些策略的总控是在 Control Plane 上配置。

（6）DevOps

DevOps就是为了提高软件研发效率，快速应对变化，持续交付价值的的一系列理念和实践，其基本思想就是持续部署（CD)，让软件的构建、测试、发布能够更加快捷可靠，以尽量缩短系统变更从提交到最后安全部署到生产系统的时间。

相对于传统IT基础设施，云具有更加灵活的调度策略，接近无限的资源、丰富的服务供用户选择、使用，这些都极大方便了软件的建设。而云原生开源生态的建设，基本统一了软件部署和运维的基本模式。更重要的是，云原生技术的快速演进，技术复杂性不断下沉到云，赋能开发者个体能力，不断提升了应用开发效率。

首先是容器技术和 Kubernetes 服务编排技术的结合，解决了应用部署自动化、标准化、配置化问题。CNCF 打破了云上平台的壁垒，使建设跨平台的应用成为可能，成为事实上的云上应用开发平台的标准，极大简化了多云部署。

一个完整开发流程涉及到很多步骤，而环节越多，一次循环花费的时间越长，效率就越低。微服务通过把巨石应用拆解为若干单功能的服务，减少了服务间的耦合性，让开发和部署更加便捷，可以有效降低开发周期，提高部署灵活性。

Service Mesh让中间件的升级和应用系统的升级完全解耦，在运维和管控方面的灵活性获得提升。Serverless让运维对开发透明，对于应用所需资源进行自动伸缩。FaaS 是 Serverless 的一种实现，则更加简化了开发运维的过程，从开发到最后测试上线都可以在一个集成开发环境中完成。无论哪一种场景，后台的运维平台的工作都是不可以缺少的，只是通过技术让扩容、容错等技术对开发人员透明，让效率更高。

（7）云原生中间件

云原生中间件最大的技术特点就是中间件技术从业务进程中分离，变成与开发语言无关的普惠技术，只与应用自身架构和采用的技术标准有关，比如一个 PHP 开发的 REST 应用也会自动具备流量灰度发布能力、可观测能力，即使这个应用并没有采用任何服务化编程框架。

微服务架构一般包含下列组件：服务注册发现中心、配置中心、服务治理、服务网格、API 管理、运行时监控、链路跟踪等。随着 Kubernetes 的流行，Kubernetes 提供的基础部署运维和弹性伸缩能力已经可以满足多数中小企业的微服务运维要求。微服务与 Kubernetes 集成会是一个大趋势。

服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心问题。随着云原生技术的发展，服务发现领域出现了两个趋势，一个是服务发现标准化（Istio），一个是服务下沉(CoreDNS)；配置管理领域也有两个趋势，一个是标准化（ConfigMap），一个是安全(Secret)。

提到事件驱动就必须先讲消息服务，消息服务是云计算PaaS领域的基础设施之一，主要用于解决分布式应用的异步通信、解耦、削峰填谷等场景。消息服务提供一种BaaS化的消息使用模式，用户无需预先购买服务器和自行搭建消息队列，也无需预先评估消息使用容量，只需要在云平台开通即用，按消息使用量收费。

四、云原生产业联盟的《云原生中间件白皮书（2020）》

为了加强对于云原生中间件的理解，自己又去找了云原生产业联盟的《云原生中间件白皮书（2020）》来看，云原生技术几乎就是指云原生中间件了。

1、中间件的概念

中间件是指网络环境下处于操作系统、数据库等系统软件和应用软件之间的一种起连接作用的分布式软件。中间件主要解决异构网络环境下分布式应用软件的互连与互操作问题。提供标准接口、协议，屏蔽实现细节，提高应用系统易移植性为其主要技术优势。它使用户能使用一种脚本语言来选择和连接已有的服务，从而生成简单程序的软件开发工具。

中间件涉及软件的各个领域，是供公用应用程序编程接口的软件。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。

在容器及编排技术、开源、微服务等云原生理念的带动下，将应用部署到云端已经是不可逆转的趋势。在现有业务代码不变的情况下，想要让分布式系统无缝入云，如何设计云原生中间件以支撑应用的云上变迁成为关键问题。

云原生时代的应用更加轻量化，在对外提供功能保持一致的前提下，将与核心业务无关的能力剥离出去。这些能力将以中间件的形式下沉到基础设施中，成为云的一部分，从而加强和改善应用的运行环境，实现应用轻量化。

2、云原生中间件的概念

云原生赋于中间件新的内涵，即云原生中间件下沉到云基础设施，保持功能不变的情况下与应用解耦，在运行时为应用动态赋能，支撑上层应用系统。

云原生中间件是指在公有云、私有云和混合云等动态环境中，用于构建和运行可弹性扩展的应用，持续交付部署业务生产系统的分布式中间件。

云原生中间件能提供应用管理、发布部署、运维编排、监控分析、容灾应急等全生命周期管理的PaaS能力，支撑云原生应用的开发与管理，满足经典和云原生架构的运维保障需求。

云原生中间件在应用开发方面，能提供开发者体验工具支撑、API 开放能力、产品定制能力、微服务中间件平台、服务市场应用商店等，来支持云原生应用的开发与管理。

3、云原生应用开发的特点

传统企业应用随着业务越来越庞大会遇到各类问题。如在运维方面，传统集群运维繁琐，对于人员技能要求高导致运维效率低；业务架构从单体架构向分布式架构转变时，架构改造以及服务拆分带来的技术学习难度高；自建IT基础资源使整个应用运行成本极高，且大量计算资源无法被充分利用，资源利用率低。云原生的出现极大改善了企业业务上云的难度，其主要有以下优势：

（1）云生云长，充分利用云平台服务优

云原生应用可以快速构建并部署到平台上，平台提供了简单快捷的扩展能力并与硬件解耦，提供了更大的灵活性、弹性和跨云环境的可移植性。

（2）敏捷弹性，致力于高效高可用设计

在传统的旧基础设施故障时，服务是可能会受到影响的。在一个云原生的世界中，团队特别关注于为弹性和高可用进行架构设计。云原生焦点帮助开发人员和架构师设计不受环境中故障影响的在线系统，快速弹性的重建和保持系统可用。

（3）灵活扩展，云原生应用具备多云间扩展的灵活性

公有云的厂商绑定现象一直为人诟病，但是使用支持云原生技术的云平台，企业可以将构建在任何(公有或私有)云上的应用快速迁移，兼具不同云服务商的优势服务能力无需担心锁定，云原生应用的开发，有七个特点，分别是容器与编排、微服务化、计算存储分离、服务网关、分布式事务模式、业务服务无状态化。

4、云原生中间件十要素

中间件的使命是服务于上层应用系统，为了设计出能更好支撑云原生应用的中间件，我们从基础资源、设计原则、运行时状态、呈现形态四个维度抽象出以下十个关键要素。

（1）容器原生

云原生中间件应进行云原生架构设计，以容器化形式进行服务部署。容器化部署可支持中间件服务快速启动，可以灵活完成服务及资源的扩缩容。容器隔离了用户底层IaaS 资源的差异，利用容器编排可轻松实现多实例（Multiple Service Instances）部署；容器原生的中间件应用程序和容器镜像占用更少的资源，对于多容器部署的场景有更好的优化策略，提升基础资源利用率。

（2）服务状态

在云原生时代，中间件架构设计时需要定义服务的状态：有状态部分和无状态部分。无状态部分主要伴随业务逻辑的产生，如服务间通信、链路跟踪等。无状态服务是指该服务运行的实例不会在本地存储数据，并且多个实例对于同一个请求响应的结果是完全一致的。有状态部分是指该中间件可以产生并存储数据，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。所以将状态保存在有状态的中间件中，如分布式缓存、消息队列等。

（3）组件模块化

云原生中间件设计时应考虑可插拔、松耦合、可动态编排的组件化特征。每个组件都是高度抽象的、自包含的、封闭的并和其它的组件相有一定的逻辑隔离，使得不同的角色专注于其擅长领域的工作。开发人员可以通过组合模块的形式调度涉及到中间件，快速支撑业务，适用系统的运行时特征。松耦合的中间件让开发人员可以在处理每个中间件时都能够独立于其他中间件来工作。云原生中间件通过功能上的分离，对外提供统一的应用程序编程接口（API）供开发人员调用，使开发者可以专注于每项服务的核心功能，以提供细粒度的功能。

（4）事件驱动

事件驱动架构作为一种应用间集成模式，天然适合云原生中间件的调度和集成。在事件驱动的体系结构中，当服务执行其他中间件可能感兴趣的工作时，该服务将生成一个事件。其他服务使用这些事件，进而执行由该事件触发的任务。事件成为了可以被消费的对象，而不仅仅是在函数间传递的临时参数，从而可以同时被多个中间件消费。中间件不需要直接和生成事件的服务进行交互，仅通过监听事件，触发对应的操作，从而降低了服务内部的复杂度。

（5）可观测

在由微服务和容器等技术形成的高度复杂的应用系统运行态中，可观测性成为云原生中间件必须具备的能力。可观测性包含了监控、告警、日志聚合、分布式跟踪和依赖分析等部分，通过收集处理数据来定位问题，并简化信息的访问，实时深入的观察整个应用系统的健康状态，从业务资源计量等多个维度进行度量。日志、指标和请求跟踪是可观测性的基础。

（6）韧性设计

具备韧性设计的中间件具有高延时宽容、容错和故障恢复逻辑。可以防止连锁故障，允许快速失败和快速恢复，且具备较强的系统自愈能力和抵抗外部冲击，为其上层运行的应用系统提供高性能、高容错、高安全地支撑。

（7）弹性伸缩

可扩展指中间件具备资源按需动态伸缩能力，在保证业务连续性前提下，可以独立于其他服务对于底层资源进行扩展或者收缩。随着流量，需求和使用量的增加，中间件应用应具有弹性。弹性意味着当资源根据需求按比例地减少或者增加时，系统的吞吐量将自动地向下或者向上缩放，从而满足不同的需求。

（8）动态部署

云原生中间件具备服务全生命周期的动态部署与发布能力，在完成开发构建之后，能够以多种策略进行发布，如滚动发布、灰度发布、蓝绿发布等；具备多种部署策略，如批量并发部署、任务定时部署、分阶段部署等；具有版本控制功能，如版本追溯与回滚。

（9）统一响应式与声明式的API

云原生中间件承担了运行时为应用动态赋能的重任，应用与中间件以API 调用的形式进行通信与控制。响应式API 描述为了达到某一个效果或者目标所需要完成的指令；声明式API 描述的是应用期望的目标状态发出的指令。根据云原生的理念，应用无需知道下层中间件及资源的具体实现方式。声明式API 即可使中间件在调用时无需关注实现细节，在应用运行时动态赋予。

（10）平台化

将中间件功能下沉到基础设施，以云平台的形式对外输出能力，提供中间件的接口供用户按需调用，用户无需关注中间件服务的下层资源调度与运维，更加聚焦轻量级的业务应用。

5、云原生中间件典型服务

主要包括分布式消息队列、分布式事务系统、分布式配置服务、API网关、分布式缓存、链路跟踪服务等等。

五、微众银行等的《联邦学习白皮书V2.0》

数据要素要加强流通和开放，除了配套的政策、机制及流程，也需要更好的技术支持，在这个背景下，多方安全计算、隐私计算、联邦学习等技术成为当下的热点，微众银行的《联邦学习白皮书V2.0》对联邦学习的背景、定义、价值、分类、框架及发展路径做了介绍，可以作为联邦学习的入门读物。

1、联邦学习背景

如何在满足数据隐私、安全和监管要求的前提下，设计一个机器学习框架，让人工智能系统能够更加高效、准确的共同使用各自的数据，是当前人工智能发展的一个重要课题，我们倡议把研究的重点转移到如何解决数据孤岛的问题。我们提出一个满足隐私保护和数据安全的一个可行解决方案，这就是联邦学习。

联邦学习是：

（1）各方数据都保留在本地、不泄露隐私也不违反法规

（2）多个参与者联合数据建立虚拟的共有模型，并且共同获益的体系

（3）在联邦学习的体系下，各个参与者的身份和地位平等

（4）联邦学习的建模效果和将整个数据集放在一起建模的效果相同，或相差不大

（5）迁移学习是在用户或特征不对齐的情况下，也可以在数据间通过交换加密参数达到知识迁移的效果

2、联邦学习定义

在机器学习过程中，各参与方可借助其它方数据进行联合建模，各方无需共享数据资源，即数据不出本地情况下，进行数据联合训练，建立共享的机器学习模型，如下图所示。

3、联邦学习分类

联邦学习分为横向联邦学习、纵向联邦学习与迁移联邦学习，如下图所示。

4、联邦学习的开源框架

目前业界主要的联邦学习框架有FATE、Tensorflow Federated、PaddleFL、Pysyft等,框架比对如下：

六、信通院《区块链白皮书（2020）》

《白皮书》的内容比较多，这里仅以区块链技术和产业发展趋势为例简要说明。

1、区块链技术图谱

现阶段由核心技术、扩展技术和配套技术三者组成的区块链技术体系已逐步成形，未来将继续在数据流通、网络规模、技术运维、平台安全等方面创新演进。

核心技术指一个完整的区块链系统必须要包含的技术，包括密码算法、对等式网络、共识机制、智能合约、数据存储；扩展技术指进一步扩展区块链服务能力的相关技术，包括可扩展性、互操作性、协同治理、安全隐私；配套技术指提升区块链系统安全性、优化使用体验等相关技术，包括系统安全、运维部署、基础设施。

2、区块链技术发展趋势

（1）数据流通更高效

联盟数据的互联互通，包含联盟链治理模式的升级演进以及区块链配合链外多方数据，实现共享流通。

2020年主流联盟链平台越来越重视链的治理功能，联盟链一般由多方参与，有关平台的建设、使用、管理应由联盟多方共建，治理模式逐渐在一方牵头，超级管理员主导的模式上，提供更加精细公平的方式。比如成立联盟运营委员会，以多中心化的方式代替独家代理。

在链外数据系统方面，随着数据交换、共享力度的加大，其权属、合规性、安全性等诸多风险开始呈现，出现了数据共享难以及隐私无法保障等问题，区块链技术可使得数据权属更易确认，可为跨组织的数据协作提供共享安全性，同时是链外流通元信息的可信存储媒介，作为新型解决方案得到了业界的关注。

2020年也看到了越来越多区块链结合安全多方计算、可信执行环境技术等等，在链外数据流通方面提供解决思路，并最终在链上实现数据确权，信息存储锚定，实现更广泛的数据协同。

（2）网络规模更广泛

网络规模更广泛，包含单一区块链网络规模的扩展以及链间的互操作。首先对于单一联盟链网络来说，一般采用拜占庭容错共识算法，但随着共识节点数量增加，网络需要交换的信息增多，系统负载及网络通信量增大，造成性能下降，单一网络规模受到限制。

2020年我们看到联盟链共识算法正结合更多的技术尽心优化，比如将共识算法网络复杂度与共识节点规模解耦，节点类型氛围共识节点、非共识节点等，通过引入VRF(可验证随机函数)保证共识节点选取随机性和公平性；采用DAG(有向无环图)数据结构提升系统吞吐量、结合密码学算法优化共识效率等等，整体上单一网络规模不断提升。

链间互操作是指不同区块链系统实例之间交换信息，并对所交换信息加以使用的能力，又可称之为跨链，主要用于解决区块链世界“链极孤岛”问题，为了应对互操作的挑战，旨在搭建链与链之间可信交互渠道的跨链技术逐渐成为业界关注的焦点。

（3）技术运维更精细

在技术实现方面，核心技术点包括共识机制、加密算法、智能合约、对等网络不断夯实优化外，行业在应对大量数据突发请求场景下未雨绸缪，包括提供网络流量控制，灵活根据系统处理能力过滤暴涨的业务请求，保障服务持续可用；提供账本数据量控制，以应对账本无限增长情况下，账本占用过多资源，影响节点运行等、目的是在特殊场景下仍可保证区块链系统稳定可靠，服务可用。

在部署运维方面，越来越多的区块链底层配备有相应的上层服务管理应用，可屏蔽底层技术细节，提升易用性，简化运维；同时区块链即服务（BaaS）平台，不断简化节点部署，支持私有化部署、跨机房地域部署、混合部署等模式，可满足联盟链不同参与方的不同诉求，降低接入门槛。

（4）平台安全更可控

2020年行业内不断出现自研软硬件一体机的解决方案，结合国内品牌服务器，操作系统，集合软硬件一体，并根据政府、企业用户提供强隐私、高安全的区块链整套应用部署方案，在当前特殊背景下，正成为行业技术发展的一种选择。

在密码学上，国密算法逐渐成为联盟链的标准配置，包括适配区块链运用较多的哈希算法、数字签名，到逐步适配国密证书、国密传输协议等完整的全国密技术方案，以此提升系统的安全可控。

同时平台安全涉及到链上数据隐私保护，2020年越来越多的联盟链平台提供了链上同态加密，支持链上密文的可计算；提供群环签名，节点验证交易正确性的同时，不会暴露交易发起者的信息；零知识证明，可让一方不需在链上提供敏感信息的情况下，证明某个链上信息的正确性。

行业内各种隐私算法技术正不断在隐私性、可用性上不断探索突破。同时如何保证链上数据隐私的情况下，仍可被监管，也是行业不断攻克发展的方向。

3、区块链产业图谱

从产业结构来看，区块链产业主要分为底层技术、平台服务、产业应用、周边服务四部分。其中前三部分呈现较为明显的上下游关系，分别由底层技术部分提供区块链必要的技术产品和组件，平台服务部分基于底层技术搭建出可运行相应行业应用的区块链平台，产业应用部分主要根据各行业实际场景，利用区块链技术开发行业应用，实现行业内业务协同模式革新。周边服务部分则为行业提供支撑服务，其中包括行业组织、市场研究、标准制定、系统测评认证、行业媒体等，为产业生态发展提供动力，如下图所示。

七、信通院《数字孪生城市白皮书（2020）》

如果你对数字孪生这个概念有点望文生义，抓不到本质，则可以看看这本《白皮书》，其给出了数字孪生城市的九个核心能力要素的定义，分别是物联感知操控能力、全要素数字化表达能力、可视化呈现能力、数据融合供给能力、空间分析计算能力、模拟仿真推演能力、虚实融合互动能力、自学习自优化能力及众创扩展能力。

九大核心能力有力呼应精准映射、虚实交互、软件定义、智能干预四大特征，成为数字孪生城市的标准配置，有望规范数字孪生城市建设市场。

1、物联感知操控能力：反映实时运行状态

物联感知操控能力指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、连接、互动的物体或过程，采集其声、光、热、电、力学、化学、生物、位置等各种需要的信息，通过各类网络接入、实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知，识别、管理和控制。

2、全要素数字化表达能力：实现精准映射

全要素数字化表达能力，实质上是城市物理实体的三维模型表达，通过空天、地面、地下、水下的不同层面和不同级别的数据采集，结合新型测绘技术，对城市进行全要素数字化和语义化建模，实现由粗到细、从宏观到微观、从室外到室内等不同粒度、不同精度的城市孪生还原，形成全空间一体化并且相互关联的城市数据底板，实现数字空间与物理空间一一映射，为数字孪生城市可视化展现、智能计算分析、仿真模拟和智能决策等提供数据基础，共同支撑城市智慧应用，主要建模方式如下图。

3、可视化呈现能力：数字城市“打开方式”

可视化呈现能力是指通过图形引擎，多层次实时渲染呈现数字孪生体的能力，既可以渲染宏大开阔的城市场景，又可展示地理信息局部特征，实现城市全貌大场景倒城市细节，再到城市实时视频的多层次渲染，真实展现城市样貌、自然环境、城市细节、城市实时交通等各种场景，实现空间分析、大数据分析、仿真结果等可视化，实现大屏端、桌面端、网页端、移动端、XR设备端多终端一体化展示，满足不同业务和应用场景需求。

4、数据融合供给能力：建立数据资源体系

数据融合供给能力包括数据集成融合能力和数据供给能力，其中数据融合是以城市多源、多类型数据为基础，以城市时空数据为主要索引，构建多层次时空数据融合框架，形成以基础地理和自然资源数据为基础、以政务数据为主干、以社会数据为补充的全空间、全要素、全过程、一体化的时空数据体系。

5、空间分析计算能力：优化要素空间布局

空间分析计算能力是指基于数字孪生城市三位模型，结合时空网格技术、北斗定位服务等，针对具体业务需求，进行空间数据相关计算、分析、查看、展示额能力，包括距离测量、面积测量、体积测量等测量能力，叠加分析、序列分析和预测分析等时空分析，路径规划、漫游定制、可视域分析等场景分析，以及全景图定制以及场景标注等。

6、模拟仿真推演能力：预测未来发展态势

模拟仿真推演能力是在数字空间中通过数据建模、事态拟合，进行某些特定事件的评估、计算、推演，为管理方案和设计方案提供反馈参考。与物理世界相比，数字世界具有可重复性、可逆性、全量数据可采集、重建成本低、实验后果可控等特性。

7、虚实融合互动能力：打通两个世界接口

虚实融合互动能力是指针对具体对象或业务，数字空间与物理空间之间的互操作与双向互动，既能在数字空间再现与影响现实世界，也可在现实世界中进入虚拟空间，二者满足实时、动态、自动、互动等属性。包括数字孪生场景的自动实时动态演变、数字孪生运行态势自动实时动态还原、数字孪生系统反向干预物理世界、物理世界多入口触达数字孪生系统等多种需求。

8、自学习自优化能力：辅助城市管理决策

自学习优化能力是指利用计算机视觉、机器学习、知识图谱等人工智能技术，实现城市运行数据感知-图像智能识别-知识图谱沟通-数据深度学习-智能决策的循环，通过对城市数据的深度学习，推动智慧城市自我优化运行，满足政府、企业、市民的按需、即时和精准决策需求。

9、众创扩展能力：形成应用创新平台

众创扩展能力是在数字孪生城市中枢平台基础上，将城市信息模型（CIM）更新编辑服务、数据集成处理服务、仿真算法服务、行业应用开发服务等应用能力集开放，让面向行业应用的产品设计者、技术开发者、运营管理者等各类群体参与到数字孪生城市建设中，形成能力开放和应用创新平台，为全社会各类应用赋能。

结语

至此，七本《白皮书》就简述完了，《白皮书》挺像综述论文，能够比较全面的介绍某个技术的方方面面，很多概念的解释也比较通俗易懂，如果你想快速了解某种技术概况，读《白皮书》是一种不错的选择。

蜻蜓点水的白皮书显然不能代替具体的学习，我读了之后的体会就是白皮书能让你知道一些不知道的东西，或者让你知道一些以为知道其实不知道的东西，比如自己原来对于云原生的认知就是三件套，微服务、容器及Devops，现在才知道原来内涵要广得多，在读的过程中会碰到很多新的概念，这促使我进行衍生的学习。

搞技术的容易成为一只刺猬，比如做数据分析的完全不懂云计算，白皮书可以让我们变得更狐狸一点，一方面拓展技术视野，另一方面也有利于外部的协作，这也是自己读白皮书的原因。

在数字化大背景下，企业需要能基于大数据、云计算、云原生、区块链、联邦学习、数字孪生等技术进行融合创新，这样读白皮书的意义似乎更大了。

白皮书获取方法：

第一步，关注公众号，将本文章分享到你的朋友圈

第二步，分享完朋友圈后，公众号后台回复“book2021”即可获取下载方法