前言：这篇文章介绍阿里云部署计算型存储节点的过程中所做的一些工作，目的是为了使云原生关系数据库能够经济高效地支持分析型工作负载。借助其计算存储分离架构，云原生关系数据库必须将前端数据库节点（计算节点）中的某些数据密集型任务（例如表扫描）下推到后端存储节点以便高效支持分析工作负载。然而，设计人员认为保持存储节点的成本效益是一个挑战（这个也是本文从始至终需要克服的一个问题）。他们利用新兴的计算型存储来解决这个问题：通过以计算型存储替代传统的固态硬盘存储驱动器，存储节点可以利用存储节点内嵌的计算能力，更高效地服务于表扫描（本文要解决的一个问题）。这个简单的想法实现起来并不容易，需要整个软件栈（即数据库，文件系统和I/O）和硬件（即计算存储驱动器）层的协同创新。这篇文章介绍阿里云原生关系数据库POLARDB使用计算型存储高效支持分析型工作负载的部署及其在阿里云中的整体设计，讨论实施面临的主要挑战，并提出为解决这些问题而设计的算法流程。下面的文章的观点和技术解读。前言       云原生关系数据库能够为分析工作量提供足够的支持是令人感到相当满意的一个特性。鉴于云原生关系数据库已经将计算和数据存储，网络解耦。因此数据库节点（计算节点）和存储节点之间的带宽变为稀缺资源。但是，这个体系架构对于经常涉及大量数据访问的分析型工作负载不太友好。特别是，为了更好地服务于OLTP工作负载，云原生关系型数据库通常使用便捷的行存储数据模型（或行列混存[5]）。这可能会进一步加剧网络带宽资源的消耗。为了支持分析工作负载且不会引发太大的网络流量开销，几乎唯一可行的选择是将频繁访问数据的任务（特别是表扫描）从数据库节点卸载到存储节点。这个想法已被数据库厂商相应的产品（例如Oracle Exadata）和开源数据库（例如，MySQL NDB Cluster）采用。尽管概念简单，它在云原生背景下的实际应用却相当不容易（这也是本文需要解决的问题）。一方面，每个存储节点必须能够处理繁重的表扫描任务，这需要大大增加每个存储节点的数据处理能力。另一方面，控制云原生数据库的成本维持在较低的水平，不应显著（甚至适度）增加成本。阿里云的设计人员对这个问题的解决方法是给CPU配备专用硬件(FPGA,GPU)，以异构计算方式实现计算能力的增强却不显著增加成本。中心思想是将表扫描任务卸载和分散到存储节点内部的各个存储设备上。对比使用专用的集中式计算设备（例如，基于FPGA/GPU的PCIe卡）承担表扫描操作的做法，将表扫描任务分解并且分配给最接近数据的存储驱动器可以最大程度地减少存储/内存之间的数据流量并消除了数据处理的热点。这个方法在应用过程中最大的两个挑战是：1）如何在整个软件栈中实际支持表扫描算法下推操作；2）如何低成本地实现高性能的表下推操作。在结合阿里云的POLARDB实现这一简单想法的过程中，他们开发了一套的软件/硬件融合的技术以解决上述两个主要问题。为了达到缩短产品开发周期同时确保成本效益，计算型存储驱动器使用以FPGA为中心的主机管理架构。在每个计算存储驱动器内部，只有一个中档低成本Xilinx FPGA芯片可同时处理闪存控制和表扫描。利用高度优化的软件和硬件设计，每个存储驱动器在压缩数据上支持高吞吐量（超过2GB/s）的表扫描操作，同时在IO性能上与高端的NVMe SSD具有可比性。为了POLARDB能够充分利用存储驱动器的能力，他们针对软件栈开发了一系列技术。下面介绍这些设计技术，并详细说明其实施。                                                                                     图1.PolarDB体系结构这一节简要介绍PolarDB的体系结构（对PolarDB感请兴趣的同学，不妨多关注我们华为云的Taurus，架构更先进，性能更优越）。POLARDB是一款由阿里云设计的新型云原生OLTP数据库，是基于云计算框架的下一代关系型数据库。它的设计动机来自阿里云客户的真实需求：大实例存储容量（数十TB）、高TPS、高可扩展和高可用性。PolarDB提供企业级云数据库服务并兼容MySQL和PostgreSQL。图一介绍了PolarDB计算存储分离的架构。数据库计算节点和存储节点是通过高速RDMA网络连接。在POLARDB集群中，只有一个读/写数据库节点处理读写请求，其它节点作为只读节点仅处理读取请求。实例中所有的节点，包括读/写节点和只读节点，访问存储节点上的相同数据副本最小化存储开销。为了确保高可用，PolarDB使用并行化raft协议对数据实施3副本存储。从这个体系结构可以看到，为了支持分析性工作负载，系统不可避免地需要将表扫描等数据访问密集型操作卸载到存储节点进行。否则，网络带宽将会成为系统瓶颈。为了支持这个想法，最简单的操作是对存储节点进行纵向扩展。但是从成本角度考虑，这个方法不具有可操作性。此外，在行存储的数据格式上（大部分OLTP数据库采用行存储）进行表扫描对于CPU的体系结构也不友好，不能充分发挥CPU的能力（高速缓存和SIMD指令资源）。从性能角度考虑，纵向扩展存储节点从性能上也不是最优的。因此，阿里云的设计人员转而使用给存储节点配备专用处理硬件（FPGA和GPU）以便更高效，更经济地支撑表扫描操作。      传统的做法是使用集中式的架构来专门处理表扫描操作。但是他们认为这个做法有以下弊端 1）数据拥堵。所有数据都需要从存储节点移动到FPGA/GPU专用PCIe卡。由于表扫描的数据访问密集性，这个不可避免地对PCIe和DRAM通道造成严重的拥堵；2）系统热点。每个存储节点包含若干的NVMe SSD盘，这些设备可以达到数GB/s的读吞吐量。单个PCIe卡很快达到处理上限，成为系统热点。鉴于从这些角度考虑，他们使用分布式的体系结构。如图2所示。   此外，从成本角度考虑，他们使用基于FPGA的主机控制策略。这可以从以下两个方面减少开发成本，1）可以使用单个FPGA在计算型存储驱动内实现闪存控制与数据计算。对比基于ASIC编程，FPGA的电路级别的可编程性极大减少开发周期与开发成本。2）计算存储驱动完全由主机管理相应的功能（例如，地址映射，请求调度和垃圾回收）。它的主机可管理性质促进了计算存储驱动器无缝融合到现有软件堆栈中。                                                                                                                                           图二.集中式与分布式的体系结构实现                                                                                                          图3.系统整体架构    针对第一个问题。PolarDB团队提出了如图3的体系结构。图3是软件堆栈的整体展示。每个POLARDB数据库服务器都包含称为前端分析处理引擎MPP。为了与MySQL协议兼容，这种分析处理引擎可以解析，优化和使用AST（抽象语法树）以及许多嵌入式优化规则重写SQL。从本质上讲，它将每个SQL查询转换成由运算符和数据流拓扑组成的DAG（有向无环图）执行计划。这种分析处理引擎本身支持将表扫描操作从数据库节点下推到存储节点。因此，无需修改分析处理引擎。如图3所示，为了支持表扫描下推功能，系统必须适当地增强处理引擎下方的整个存储堆栈，包括POLARDB存储引擎、PolarFS（分布式文件系统在POLARDB下），以及计算存储驱动。下面将详细介绍这些模块已实施的增强功能。      PolarDB存储引擎采用类似RocksDB的LSM存储（应该是X-Engine，见sigmod 2018：X-Engine: An Optimized Storage Engine for Large-scale E-Commerce Transaction Processing）。PolarDB本身支持表扫描下推。在最初的实现中，它利用CPU执行这项操作。本文的初衷是将表扫描操作委托给计算型存储驱动，因此需要将表扫描操作从存储引擎再下移到PolarFS。如图3所示，存储引擎按照文件偏移量访问数据块。 每个表扫描请求包含：（1）待扫描的数据在文件中的偏移量（2）表模式（3）应用在表上的评估条件。 同时，POLARDB存储引擎将分配一个内存缓冲区以存储从计算驱动返回的数据，并且每个表扫描请求都包含此内存缓冲区的位置。值得注意的是，PolarFS并不是支持所有的条件查询，例如LIKE操作目前就支持不了。因此PolarDB引擎首先需要将扫描条件解析出来，将能够支持的条件下推。并且，对不支持的条件查询在本地执行。如图3所示，PolarDB需要分布式文件系统PolarFS的支持。PolarFS确保同一个文件位于同一个存储驱动上。PolarDB团队的技术人员在一下方面增强了文件系统PolarFS，（1）假设要扫描的数据跨越m个计算存储驱动，增强的PolarFS将此请求分解为m扫描请求，每个请求独立扫描不同存储驱动上的数据。 （2）对于每个扫描请求，PolarFS将数据位置信息转换为LBA中的偏移量。 如图4所示，增强的PolarFS随后将转换后的基于LBA的位置信息的m个请求转发到底层计算存储驱动。如上文第2.3节所述，计算存储驱动完全由内核空间中的主机端驱动程序管理。该驱动程序将计算存储驱动器对外暴露为NVMe块设备，并且可以提供正常的NVMe I/ O命令。收到PolarFS的每个表格扫描请求后，文件系统会分析查询条件，如有必要将重置查询条件。此外，PolarFS还会进一步将表扫描操作划分为子任务，增加并行度，减少系统资源争夺。PolarDB对底层计算存储驱动的修改主要是统一数据比较操作符，例如全部的数据比较由memcmp实现。此外，修改数据块格式，提升硬件的利用效率，体现在以下方面，（1）计算存储驱动器可以解压缩每个块并检查CRC而不要求POLARDB存储引擎传递的每个数据块大小的信息。 （2）通过在每个数据块开头的字段添加“键数”和“重新启动数”（应该是数据项的结尾和开始处的地方），硬件可以方便地处理每个块中的边界并检测每个块的末尾。 这非常适合硬件的数据顺序处理流程，因此简化了基于FPGA的硬件实现。                                                       系统评估       实验对TPC-H的6个表扫描操作进行评估，对比基于CPU（CPU-based）和基于计算存储驱动的（Computational Storage driver-Base，CSD-based）表扫描吞吐量，CPU利用率，内存带宽占用率以及延迟。                                        图4.a~c,不同测试场景下的表扫描率；d-f，不同测试场景下CPU利用率 图4的a-c显示了表扫描下推关闭的场景下的系统吞吐率。在关闭的情况下，系统的吞吐率随着CPU的增加而增加，这是必然是；在表扫描下推打开的情况下，系统吞吐率随着CPU的增加而急剧增加，这是因为计算存储驱动的表扫描吞吐量随着上层CPU下推的表扫描数据而增加。在CPU数目为4-8的时候，即可达到系统最大吞吐率，大大地节约CPU的使用。图4的d-f显示了，CPU的使用效率可以节省4-8倍左右。                                                                         图5.a-c是PCIe数据移动量；d-f是内存的数据移动量       图5展示了CPU-based与CSD-base的表扫描算法对设备带宽的压力。可以看到在测试语句TS-5的情况下CSD-based的表扫描算法基本消除了PCIe的设备带宽占用，这是因为TS-5(即图4-a)的语句选择率很高，基本过滤了需要处理的数据。而TS-6仅仅涉及投影操作，CPU-based表扫描算法可以更好地处理该类型的扫描。图4-c是平均的PCIe带宽占用。平均而言，在PCIe与内存带宽的占用上，CSD-base的表扫描算法要低8倍左右的带宽占用。                                                                                             图6.节省的查询延迟  图6是在TPC-H的测试的22查询语句上CSD-based的查询的延迟对比CPU-based的查询的提升幅度。可以看到，在22个查询语句上CSD-based表扫描方法节省的延迟平均在40%，最高的延迟时间节省接近70%的时间。个人总结       从目前看来，PolarDB的这个产品有一定的借鉴价值，利用异构计算将表扫描操作下推至文件系统级别，对存储引擎、文件系统以及存储计算驱动分别进行了相应的增强，在性能与成本之间达到一个很好的平衡。在计算与存储分离大行其道的今天，将数据访问密集型的操作下推至存储节点或者是文件系统不是一个可选项，而是一个必选项。同时，云端的OLAP产品迟迟未能有突破性产品面世，或许是受制于HTAP产品的不成熟，亦或是云端基础设施的不充分。虽然PolarDB的这个AP特性能够提升系统在AP方面的性能达40-70%，但是对比微软SQL Server的AP性能在10-100x上提升，实在是相形见绌。未来如何在华为云原生数据库Taurus是实现AP支持是我们重点思考的问题之一。                     

【前言】Taurus是华为对标AWS Aurora的一款重磅云原生数据库。其设计思想是Log-as-database以最小化网络IO，采用计算存储分离的架构。Taurus的市场定位是OLTP的企业级市场以及高端MySQL客户，但兼顾中小客户。技术路线上兼容MySQL/PG生态，减少客户获取成本，降低风险。本文介绍Taurus数据库产品产生的背景、系统架构以及技术细节。此外，我们还对比了AWS Aurora/Aliyun PolarDB与Taurus的一些特性。相关背景             图1. 第一代云数据库系统架构    在移动互联和物联网等新的应用场景之下，半结构化与非结构化数据例如图片、文本、音频、视频等出现爆炸性增长。传统数据库系统难以应对大数据时代下的存储需求，企业客户迫切需要新的数据库产品，具备动态扩缩容、高吞吐量、低成本等。在云计算技术不断成熟的背景之下，云数据库开始崛起，并因为按需扩展、按需付费等优异特性获得中小企业及互联网客户的青睐。云数据库经历了若干时期的发展，逐渐从托管式服务进化到云原生数据库。云原生数据库在某种程度上颠覆了传统数据库的架构设计。因为云环境基本已经提供相应的高可用功能，而大部分云厂商提供的数据库服务并没有利用这个特性从而错过许多优化空间。以MySQL为例子，如图1所示，数据库系统部署在虚拟机和分布式块存储之上。每个数据库有一个主实例和至少一个只读实例。外部客户通过一个虚拟IP(VIP)访问数据库。当主节点发生故障，云端管理软件会将VIP自动切换至新的主实例。主实例和只读实例都将数据存放在云存储的块设备上。主实例将数据页、保证页面原子性的double write以及redo日志通过文件系统接口写入云存储侧，然后将binlog发送到只读节点。只读节点接收到这些binlog之后写入relaylog，然后回放日志重建数据库副本。回放线程也会将这个过程产生的redo日志，binlog和数据页写到云存储。整个系统可以工作，但是却存在如下几个问题。l  存储空间浪费为了确保数据的可靠性，云存储对于写入的数据一般都是采用3副本存储。所有的数据库实例包括主实例和只读实例都是将数据写入云存储。这种情况下，主实例是3副本存储，其它只读实例也是3副本存储，总共消耗3*(N+1)副本的存储空间，其中N为只读实例的个数。理想情况下，整个数据库系统只需为主实例保留一份数据，只读实例可以共享这份数据，那么可以极大地节省存储空间。l  较大的RTO和数据滞后在现有的RDS部署中，数据库系统的高可用取决于主备之间binlog同步和故障切换协议。在事务提交之前，主机将binlog同步至备机，等待备机的ACK。备机将接收到的binlog进行回放，重建数据库副本。主机发生故障的时候，备机只有将binlog回放完成才能接管系统，对外提供服务。在云环境，MySQL将数据存储在远端的分布式云存储上。数据库日常操作产生的磁盘IO都会转化成网络IO。对比本地存储，云存储的优点在于提供了更大以及更可靠的存储空间。它的主要不足在于延迟较大。这直接影响了备机binlog回放性能。虽然MySQL5.6支持MTS特性，但是一个库只有一个回放线程。在最坏的情况下，需要等待数小时备机才能就绪，对外提供服务。MySQL5.7引入MTS多线程并行回放特性，但是帮助有限，这仍然不能从根本上解决问题。本质上而言，主库的更新压力越大，从库回放日志的时间也就越长，接管系统等待的时长随之增加。因此系统的RTO增大。由于从库需要回放日志来反映主库上的更新，备机回放性能的不足使得主从延迟较大。理想的情况下是，主备共享云端的数据，这可以完全消除备机回放过程和开销，极大地缩小RTO和主从滞后。l  计算资源浪费在现有的RDS部署中，创建备机的主要目的是回放binlog，备机不响应任何的客户端请求。这其中主要的原因是防止查询工作负载影响回放进程。类似地，只读副本系统的回放进程也会影响查询性能。如果备机能够消除回放过程，那么系统的所有计算都可以用来相应用户请求。l  系统性能RDS MySQL主实例将redo日志、binlong和数据页(双写)写入远端的分布式云存储。当系统redo存储空间或缓冲区脏页比例达到阈值，MySQ进行checkpoint操作将脏页写入云存储。对比本地存储，云端较大的写时延制约系统的性能，特别是写入性能。在AWS Aurora纯写测试基准下，现有MySQL RDS的QPS是50~60K，而Aurora能够到达110k。在64个虚拟处理核心下，Aurora甚至能够达到200K的QPS。l  网络带宽消耗在当前的RDS部署中，所有数据库实例都会通过网络将其所有数据写入后端云存储。以master为例，一个MySQL master实例需要写redo日志、binlog和数据页(双写)。对于Aurora纯写测试基准，峰值吞吐量为200 K QPS，这转换为70 M字节/秒的重做日志，但是，写数据页将生成另外700 M字节/秒的流量。对于云存储，所有这些都是多副本存储。这仅对于单个数据库实例。在这种带宽消耗规模下，在相同基础架构上运行的数据库实例数量将会很少。此外还有写入放大、大库支撑不足和从库加入时间较长等问题。Amazon首先意识到上述问题，近年来推出的云数据库Aurora就是为云计算时代而专门定制的一款关系型数据库。其目标主要是最小化网络IO，充分利用云基础设施来提升系统的可扩展性与可用性。Aurora的设计哲学是log is database，对数据的更改只写日志，不刷脏页，极大地简化恢复子系统。Amazon宣称Aurora的RTO最大为2分钟左右；可以在秒级时间内完成故障节点切换与扩容，性能对比MySQL5.6可以优10倍。TaurusDB作为一款cloud native的数据库，设计理念类似AWS Aurora，但青出于蓝而更胜于蓝。TaurusDB不仅针对IO与写操作进行了优化，而且还考虑了读优化，让应用程序可以在缓冲区内以最小的代价获得最新的数据，明显区别于国内厂商（腾讯CynosDB基本完全按照AWS Aurora的设计思路，与TaurusDB原型版本设计思路类似，这里我们把它归为AWS Aurora一类）。TaurusDB针对用户痛点进行了相应的技术革新，对比第一代云数据库其优点相当明显。以下是TaurusDB的架构设计，文章的最后是TaurusDB与其它厂商的对比。                                                                                                             TaurusDB特点             图2. 基于DFV共享存储的TaurusDB架构TaurusDB是华为MySQL RDS经历了云盘时代单机版、Active-Standby主备版和金融高可用一主两备三节点架构版本后，作为华为云自研的最新一代cloud native分布式数据库。它采用华为下一代云存储（DFV）实现弹性扩缩容、高可用和共享存储。如图2所示，系统自顶向下分为3大部分，SQL节点、存储抽象层SAL(Storage Abstract Layer)以及存储节点(storage server)。TaurusDB SQL节点形成一个集群，包括一个主节点和多个只读副本（RO，最多15个）。每个集群属于一个云租户，一个租户可以具有多个集群。SQL节点管理客户端连接，解析SQL请求，生成查询执行计划，执行查询以及管理事务隔离。主节点和只读副本之间的通信流量很小，主要交换一些状态信息（DDL更新、slice/pages分配更新和活跃事务列表、只读副本中最旧的读取视图、副本最小LSN）。在故障切换期间，任何只读副本都可以接管集群。只有主SQL节点负责数据库更新和DDL操作，而只读副本处理数据库只读查询，并为客户端提供可重复读（RR）和读已提交（RC）隔离级别。如图2所示,SAL(存储抽象层)是SQL节点和存储层之间的桥接器。SAL包括两个主要组件，SAL SQL模块和DFV存储节点内部的Slice存储。SAL SQL模块为SQL节点（主/只读副本）提供了SAL API，用以与底层存储系统进行交互。如图3所示， SAL SQL模块包含通用日志处理器CLP（Common Log Processor）、数据库分片管理器SM（Slice Manager）、页面读取器PR(Page Reader)以及与只读副本节点同步信息的工具程序。CLP负责将数据库全局重做日志持久到DFV，解析日志并将其分发到相应的DFV分片，并生成同步消息（脏页，活动事务列表，分片持久LSN等）以供只读副本获取。CLP还需要处理数据库崩溃恢复，重新加载已提交的全局重做日志并将其重新分配给所有相应的分片。SM维护分片策略以及页面映射信息，确定何时添加更多的分片以及哪些数据库页面应分配给哪个DFV切片等。页面读取器负责通过查找页面映射信息将特定的页面读取请求路由到相应的切片管理器。SAL SQL模块还为SQL节点与存储系统交互提供了其他一些接口，包括定期将日志清除信息（RecycleLSN）传递到数据库片等。                          图3. SAL-SQL包含的主要模块Slice Store是在DFV存储节点内部运行的插件模块。它需要与DFV存储框架一起使用，用以在相同DFV节点上管理多个数据库片，支持多租户资源共享，并将页面的多个版本提供给SQL节点。如图4所示，对于每个分片，slice Store使用日志目录作为中心组件来管理重做日志和页面数据。Slice store的主要职责是1) 接收分片重做日志，将其持久化并注册到日志目录中；2)接收页面阅读请求并构建特定版本的页面;3)垃圾回收和合并日志。                                                图4.slice store组件TaurusDB存储层建立在华为云存储DFV持久层之上。DFV持久层为上层SQL节点存储提供读写接口，提供跨地域3AZs之间的数据强一致性和可靠性保证。 TaurusDB使用两种模式实现write-optimized以及read-optimized，分别是PLOG模式与iShard模式。PLOG模式提供强一致性保证，而iShard模式实现最终的一致性。TaurusDB SQL节点使用PLOG模式存储整个数据库的WAL重做日志，使用iShard模式对数据在多个存储节点之间进行分片和管理。PLOG以SSD友好的追加写方式使事务提交更快；iShard将redo以页面为单位进行聚合，管理数据分片，实现快速数据读取，并支持超大型数据库（128 TB）。存储层支持多个TaurusDB集群实例，单个存储节点支持多租户数据库分片。部署灵活，可以将PLOG和iShard部署在单独的存储池中或共享同一存储池。在这种体系架构下，整个数据库集群只需一份足够可靠的数据库副本集，极大地节约成本。所有只读副本共享在云存储中的数据，去除数据库层的复制逻辑。一写多读，没有独立的备用实例。主节点发生故障，集群进行切换操作时，只读副本都可以切换为主节点，接管集群服务。为了节省宝贵的网络带宽，只有数据库日志通过网络从数据库计算节点写入 DFV 存储层，没有脏页、逻辑日志和双写的流量。基于 DFV 存储层内的数据库日志重构数据面，独立于上层的计算节点，实现存储和计算分离。为了应对大数据存储需求，TaurusDB利用DFV的切片策略对数据库进行自动分区，对应用透明。单个DFV存储节点可以管理来自不同数据库集群实例的多个分片，实现存储容量无限扩展。TaurusDB的设计中，充分使用了异步线程、批量IO以及流水线工作模式实现写入高性能。这对于有大量写入需求的场景，例如物联网是相当合适的。通过在存储层内嵌数据库插件可以快速读取所需的数据。从这一角度上来说，TaurusDB是一个write-optimized以及read-optimized的数据库系统。总的来说，TaurusDB具有以下的优点：1.   节省资源如上所述，TaurusDB只需一份足够可靠的数据库副本集。所有只读副本共享云存储中的数据。添加只读节点时，只需添加计算节点，无需额外购买存储。只读节点越多，节省的存储成本越多。另外一个值得注意的地方就是数据库去除了复制逻辑，对比主备高可用架构这在一定程度上了节省了网络流量，提升计算节点效率。总体而言，在成本开销上，TaurusDB提供企业级的服务能力，但只有1/10商用数据库的成本。2.   便捷扩展性与高可靠性在第一代云数据库的主从架构下，添加只读时需要拷贝数据，重放 binlog，这要求备库完整地执行一次查询请求，在大数据量情况下速度很慢，尤其是对于采用本地盘方案。主从复制延迟问题会影响主备切换，无法保证 RTO，影响SLA。此外，备份恢复速度很慢，TB级的数据量通常需要耗费数小时，使得数据库扩展性严重受限。对比传统的逻辑复制，物理复制则没有上述缺点。因为物理复制只需在日志指定的存储位置上恢复/应用数据的前置镜像/后置镜像即可，完全跳过了查询执行过程。TaurusDB采用物理复制，减少IO操作的同时，让复制更加可靠、高效，并且几乎不会对性能造成影响。由此带来秒级主备切换、快速动态的读扩展和故障恢复。TaurusDB最高支持扩展到15个只读节点。虽然TaurusDB使用了物理复制，但是基于客户在数据分析和传输上需要Binlog，我们也支持Binlog进行数据同步。得益于底层强一致分布式文件系统DFV的支撑以及TaurusDB架构在数据访问上的设计，TaurusDB支持跨AZ部署，跨region容灾，实现单点故障0中断，满足金融级别可靠性。3.   高性能TaurusDB包含MySQL 8.0的所有重要功能，还在其基础之上进行了大量的优化，例如针对硬件特性的适配与大并发下的优化。TaurusDB对封锁子系统进行了分区，减少了锁表的竞争，并行化死锁检测；在事务子系统上采用Lock-Free数据结构来管理事务子系统的活跃事务列表。除此之外，引入内核特性，例如Query result cache，Query plan cache，Online DDL等提升用户体验。相比于TaurusDB1.0版本，TaurusDB2.0版本在性能表现上有了显著提升，在关键情况下都有了数倍的改进。对比MySQL 8.0的官方版本，TaurusDB2.0的优化改进所带来的效果也非常明显，尤其是物理复制方面具有显著的优势。在纯写情况下，TaurusDB2.0的性能可以比官方MySQL8.0高7倍以上。4.   强悍的备份恢复支撑TaurusDB 引擎采用定制的新一代分布式存储系统DFV，极大提升了数据备份、恢复性能。DFV持久层集群包括多个存储节点。每个存储节点包含多个SSD设备和适应SSD介质的append存储服务进程，提供AppendOnly vs. WriteInPlace的数据写入模式。DFV将数据按多时间点多副本存储，支持海量快照和快照秒级生成。在这种能力支撑之下，基于底层存储系统的多时间点模式，TaurusDB不需增量日志回放，可直接实现按时间点回滚,轻松支持PITR（Point-In-Time-Recovery）特性。TaurusDB将特定计算任务（备份与恢复逻辑）下推到DFV，以便更高效，快速地实现备份、恢复，而上层计算节点专注于业务逻辑处理。在这种模式之下，客户可以通过本地访问数据并直接与第三方存储系统交互，高并发高性能。通过异步数据拷贝外加按需实时数据加载机制， TaurusDB 可在数分钟内达到完整功能可用，实现快速实例恢复。横向比较      TaurusDB 的共享存储架构将数据持久化放入新一代存储中，充分保障数据强一致性和 0 丢失；针对硬件定制上层系统，充分利用 RDMA 网络、NVME SSD 等硬件优势，在这些关键技术上整合创新，使得 TaurusDB 的性能有了质的飞跃。对比目前业界的同类型产品，AWS Aurora和阿里的PoloarDB，TaurusDB的纯写性能方面要优30%左右。从阿里云对外公布的技术资料分析，PolarDB仍然需要将数据页写入存储侧，对数据进行SSD不友好的update-in-place操作。相比Aurora，PolarDB在体系结构上进行了一些创新，例如与数据库交互的IO设计、与现代硬件的适配等。腾讯的CynosDB则基本上参照AWS的Aurora进行设计，也沿用了很多系统概念例如数据段一致LSN(SCL)，MTR完全点(CPL)，最大存储卷MTR完全点(VDL)等。TaurusDB为了应用程序能够在计算节点以最小代价读到最新的数据，另辟蹊径对系统架构进行了不同层面的思考。利用CLP组件实现快速事务提交，利用slice store达到读优化的目的。在这点上，TaurusDB跟SAP HANA的设计思路有类似之处，数据在系统不同阶段有不同的作用。SAP HANA中，数据从行存储形态逐渐转化成列存储，从写优化向读优化演变；而TaurusDB中，日志从开始阶段的写优化通过compact操作向读优化演进。日志兼顾保证系统的持久性与效率。在不同的时期，日志的作用不同。系统恢复阶段，日志通过回放将系统恢复到最新一致性状态；在系统正常运行阶段，日志通过回放将系统最新数据提供给应用程序。并且得益于对多版本数据的剪枝（页面解析plug-in），计算节点可以以最小的代价从存储节点获得最新数据，无需RDMA网络的支撑即可高效完成。这也是TaurusDB能够顺利实现跨AZ部署，跨region容灾的关键点。表一是从用户较关心的角度出发，对TaurusDB，AWS Aurora以及阿里PolarDB“三驾马车”的横向对比。文章的最后，欢迎对taurus感兴趣的技术人员加入我们一起挑战技术巅峰，长风破浪，直挂云帆济沧海！简历发送至zhuyuean@huawei.com                                                    表一 TaurusDB VS. PolarDB VS.Aurora RPO (PITR)RTO       MySQL/PG兼容          系统纯写性能比率    支持跨AZ 只写logTaurusDBY <=30sec               Y                    1 Y      Y阿里PolarDBY >=1min               Y                   0.7 N      NAWS AuroraY <=30sec               Y                   0.7 Y      Y

01 什么是云原生（Cloud Native）      在目前这个互联网时代，无论是中小型企业、还是大型的互联网公司都是可以拥抱到云计算的好处，各大公有云产商的平台提供了接近零的停机时间、无限的扩展性、可控的容错及成本控制等。但我们的业务如何配合云计算达到最大化的收益呢？那么就是云原生，通过云原生构建具有弹性、轻量级、无状态的应用以适应目前互联网发展所需的大流量及大负载服务处理的能力。02 云原生可以解决什么痛点应用需支持快速上线 应用需支持快速扩容 应用需实现故障监控探测 应用需实现故障自我隔离应用需实现故障自我恢复... 03 如何达到云原生      云原生并不是一种具体的技术，具体来说应该是一种思想的集合，包括敏捷、DevOps、CI/CD、微服务、服务治理、容器技术、云计算等，整合并重组以致于推动公司商业业务的发展。也可以说云原生是对技术、管理的一种整合。DevOpsDevOps（Development与Operations的单词组合）DevOps并不是一种技术，而是应用交付的文化，是促进开发、运维、测试3个部门间的沟通协作的整合，目标就是为了快速、稳定的交付应用。传统的开发方式会设计到多个部门，开发人员在对配置修改之后没有通知到运维人员，运维人员缺少对应用的运行环境及应用内部实现的了解，开发周期长等问题，会造成应用在发布时运维人员难以选择正确的运行环境或者配置、开发人员无法感知到应用运行潜在的问题，往往这些问题需要花费大量的时间进行解决。而为了解决这些传统开发方式的问题，就有必要引入DevOps文化。CI/CD持续集成（Continuous Integration）持续集成是指开发人员会持续的将代码更改提交到代码仓库中，更改会触发编译、测试等作业验证此次提交的代码是否满足预期要求，已确保新提交代码可以对原有代码进行集成，已防止新提交的代码造成部署后应用出现问题。持续交付（Continuous Delivery）持续交付是指持续集成的进一步扩展，已经正常通过测试及验证代码的稳定性，下一步就是将代码部署在预发环境中，可以使用自动化的方式重复的进行频繁的交付，这可以避免因为人工配置错误等原因造成问题。持续部署（Continuous Deployment）持续部署是指在持续交付的基础上，证实应用在预发环境中通过测试，将应用自动化的部署到生产环境的过程。有些应用场景也突出持续交付旨在交付构建的产物，而持续部署是负责在构建仓库中将构建产物部署到运行环境中。敏捷（Agile）敏捷是一种软件交付迭代方法，从项目开始就逐步构建应用，而不是试图在即将结束时立即交付所有应用。是将项目分解成一些称为用户故事的用户功能 ，对它们进行优先级排序，然后在较短周期中连续性的交付。微服务（Micro Services）微服务是一种架构模式，将单一大应用拆分成多个独立的轻量级服务，每个服务围绕具体的业务进行构建，服务可支持水平扩展，功能单一且独立。服务之间相互协调、互相配合并可以支持独立部署。服务治理（Service Governance）服务治理是为了实现对服务的生命周期管理与定义策略及规范，主要有服务注册、服务发现、负载均衡、服务限流、服务降级、服务熔断、服务重试、链路追踪、服务配置、API网关等等。主流有Dubbo、Spring Cloud等框架，但这些框架是针对于特定语言，如果有其他语言想要实现同等的服务治理能力，那么需要重复的造轮子去实现。服务网格应求而出，解决了开发语言之间的壁垒，解耦了服务访问者和服务提供者的拓扑，并把服务治理能力下降成通用的能力提供给不同的服务，大大的降低了服务复杂度及减少了开发人员压力。容器技术（Container Technology）容器是基于操作系统隔离的进程，这些进程间是受到资源限制并相互隔离，容器是没有自己的操作系统的，直接共享宿主机的内核，这比传统的操作系统虚拟化更加轻量级。目前容器解决方案主流是Docker，而容器管理解决方案是Kubernetes，为容器化的应用提供部署运行、资源调度、服务发现、动态伸缩、故障自愈等一些功能。云计算（Cloud Computing）云计算是提供按需弹性的计算、存储、网络资源的服务模式，这种模式可以快速提供安全可靠的IT基础设施，例如数据库、消息队列等服务，用户不需要关心太过于底层实现的事情，只需要用很简单的方法就可以接入使用。康威定律（Conway's Law）一个应用最终是什么样子大概率是由企业组织结构决定的，是组织内部、组织之间的沟通结构。要得了一个合理设计的应用或者系统架构，单单从技术方面考量是不够的，还需要从组织架构入手才真正有效。04 云原生总结再回顾下什么是云原生？我认为是软件的未来。而这个未来已经来到。      应用的架构从单机 -> 垂直扩展 -> 水平扩展 -> SOA -> 微服务一直在变革。类似互联网应用总是需要满足快速迭代、高可用性、高性能等，那么首先我们需要将应用设计成无状态并运行于容器平台之上，需要高服务能力时水平伸缩容器组的数量即可，通过容器特性实现高可用等，通过CI/CD打通实现自动化发布流程，服务网格打通语言间的壁垒及重复造轮子的问题，降低开发团队的压力。云原生应用需要与基础架构解耦，可以随意在任何一家公有云或者私有云上运行，并支持水平或垂直的扩展性要求。通过打通技术与管理上的壁垒，将二者更好的结合在一起创造出云原生应用。简单而又重复的事情，应该交由系统自动化去完成，把重点放在创造更多的业务价值上。关于作者叶康铭南开大学计算机系毕业、云计算及云原生的布道者、阿里云认证云栖专家、华为云认证云享专家、深圳HDZ社区核心组织者。熟悉国内外各大云产商，在大规模的服务应用、安全防护、计算平台、架构设计有多年的实践经验及管理方法，致力于让更多人和企业更好认识及应用云计算及云原生。为何书写作为一个布道者，有一个平台提供知识传播能力，帮助更多的人学习并应用云计算、云原生。作为一个技术人，记录下自己走过的技术道路，作为技术的沉淀积累，人生也需要定期的复盘，不断去思考优化调整。未来期待每周会定期输出云原生技术文章、从入门开始逐步剖析深入到企业级的项目中，也分享一些在架构设计领域的技术文章及想法。如果有技术上的问题，也欢迎一起探讨及分享。联系作者添加好友时麻烦请备注来源、公司及名称，谢谢HDZ社区—携手全球开发者 共建开放、创新、多元的开发者社区组织       HDZ是Huawei Developers Zone的英文缩写，是华为开发者生态面向全球开发者建立开放、创新、多元的开发者社区组织。      致力于帮助开发者学习提升、互动交流、挖掘机会，推动ICT、互联网等产业生态的建立和发展。      对云计算、IoT、人工智能、5G、区块链、鲲鹏、昇腾、软件开发与运维、开源等各技术领域感兴趣的开发者、软件工程师、创业者、运营人、产品人、大学生、老师等都可以参与到HDZ。      HDZ秉承开放、创新、多元的社区文化，完全由各地HDZ组织者、志愿者自发组建和领导。华为公司不直接参与HDZ组织建设和领导，只按需对HDZ社区活动提供必要的方向指导、资源支持、活动支撑等，并为各地HDZ组织者提供与全国组织者互动交流的机会。扫描上方二维码即可报名申请成为各城市核心者、志愿者

注意：由于安卓模拟器方案和Robox容器方案均是基于Ubuntu 18.04进行适配的，与鲲鹏硬件OS不兼容，因此对应的文档已做下架处理。鲲鹏BoostKit ARM原生使能套件的移植、部署、调优端到端使用流程和一站式资源获取。鲲鹏BoostKit ARM原生使能套件文档获取地址：cid:link_0

1月4日，2019年MongoDB中文社区年终盛会在深圳时代大厦举行，大会邀请了众多知名云服务商和业内技术大咖，共同畅谈云时代下MongoDB如何寻求突破，如何给企业带来巨大红利。华为云NoSQL数据库负责人胡达与会并发表了《云原生时代的MongoDB》的主题演讲，表示云原生数据库在性价比、数据可靠性、弹性伸缩等方面十分具有优势，对企业发展具有重大意义。华为云NoSQL数据库负责人胡达现场分享云原生时代下的MongoDB随着数字化和智能化进程的加快，数据上云成为了各大企业的首选，而MongoDB也在数字化进程中不断加速云化过程，云服务也愈来愈多样，胡达对目前云上MongoDB的典型部署架构作了简要分析。目前国内云厂商的MongoDB兼容云服务基本是以社区开源版本的托管为主，通过用云硬盘替代本地硬盘，发挥了一部分云计算优势，实现存储容量快速扩展；提供一站式的部署、管理、运维能力，在数据可靠性、安全性、备份恢复等方面有一定的易用性改进，减轻了DBA的工作负担。但是，相比国外友商的基于云原生架构同类云服务产品，在弹性、高可用、可靠性、性能稳定等方面仍存在差距。会上胡达分享了云原生时代的MongoDB，认为未来的方向是计算存储分离架构下的Serverless模式，给用户提供更简单易用的使用体验。华为云GeminiDB的更多可能性基于云时代下客户数据上云，企业的数字化转型，客户对MongoDB的使用，大数据量的压力这些痛点，胡达在会上重点介绍了华为云数据库GeminiDB，这是一款基于华为自主研发的计算存储分离架构的分布式多模NoSQL数据库服务，100%兼容MongoDB接口，并提供高性能、高可靠的优势。与市面上各类MongoDB云服务相比，GeminiDB for MongoDB API构筑了以下优势：一是分钟级计算节点扩容和秒级存储扩容，扩容性能提升百倍，满足敏捷业务弹性需要。二是高性价比，同等成本下提升了3倍写性能。三是数据高可靠，基于分布式存储的数据副本故障快速恢复能力，副本重建时长缩短10倍+。此外，GeminiDB for MongoDB API支持单套实例最大100TB数据，N-1个节点故障容忍，具备一键部署、监控报警等服务能力。胡达表示，华为云数据库会充分利用华为软硬件优势持续构建业内领先的技术和服务，打造真正的云原生MongoDB API兼容的云服务。未来，云原生数据库，我们可以做得更好。欲了解更多云数据库详情，请前往华为云官网：https://www.huaweicloud.com/product/geminidb.html

《云原生边缘计算架构分析》获中国边缘计算学术研讨会“优秀论文奖” 近日，由中国通信学会主办，中国通信学会边缘计算委员会（筹）及中国移动通信有限公司研究院承办的“2019全国边缘计算学术研讨会”在北京成功举办。工信部、通信学会、中国移动研究院的有关领导出席大会并致辞。本次学术研讨会吸引了来自政产学研各界的专家学者及企业领导等二百余人参与，以”边缘计算领域新技术的应用与发展趋势“为主题进行了深入的探讨与交流。华为云智能边缘云团队的论文《云原生边缘计算架构分析》在本次大会的众多参选作品中胜出，获颁“优秀论文奖”。          文中在分析业界与学术界多个边缘计算项目的架构后，阐述了一种基于Kubernetes架构的云原生边缘计算系统KubeEdge。KubeEdge由华为云智能边缘云团队提出，作为商业边缘服务智能边缘平台IEF的开源版本于2018年11月宣布开源，现已是CNCF官方项目之一，其本质是将Kubernetes的云原生微服务管理能力延伸到边缘，将云原生的生态和开发体验延伸到边缘，针对上层开发者提供统一的开发、部署、管理视图，并增强了离线运行能力、边云协同能力和边边协同能力。最后，给出了在智慧园区、工业互联网、 互动直播、自动驾驶等场景下KubeEdge的实际应用案例，以及未来在边缘应用安全、数据隐私和可信以及边缘AI方向的研究工作。 KubeEdge基于Kubernetes的架构体系并针对边缘场景提供了诸如离线运行能力、边云协同能力等多种特殊能力的支持，将云原生的生态和开发体验延伸到边缘，面向开发者提供统一的开发、部署、管理视图，屏蔽边缘和云端的差异。其整体架构如下图所示。         文中还特别的提到了使用EdgeMesh来支持跨越边界的微服务访问，随着微服务框架的流行和边缘节点计算和网络能力的增强，把部分服务部署到边缘处理设备产生的数据可以解决时延的问题，但由于安全等原因，大多数服务仍然运行在云上，云跟边、边跟边之间的协同是必须要解决的问题。EdgeMesh边缘微服务框架如下图所示，其主要解决了两个问题：l  由跨越了边、云而组成的大型分布式系统中的微服务之间互相发现和访问l  在微服务互相访问的过程中对访问过程进行治理、控制从而提升大型分布式系统整体的可用性                         华为智能边缘云生态经理欧争光表示，KubeEdge致力于打造一个开放共赢的边缘计算生态，助力于边缘计算行业的上下游发展，降低用户的二次开发成本，快速孵化端边云协同应用的创新。KubeEdge已经吸引了学术界和产业界广泛参与和部署，如中科大、北京邮件大学、东北大学、中国移动、烽火等著名高校和企业，也期待您的加入。点赞地址：https://github.com/kubeedge/kubeedge

备注：安卓模拟器方案和Robox容器方案均是基于Ubuntu 18.04进行适配的，与鲲鹏硬件OS不兼容，因此下架对应的文档。方案指导链接技术白皮书鲲鹏BoostKit ARM原生使能套件 技术白皮书https://www.hikunpeng.com/document/detail/zh/kunpengcps/twp/kunpengcps_19_0001.html云手机Turbo套件Kbox云手机容器文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/kboxcpc/kunpengcps_kbox_0001.html视频流引擎文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/videostreamengine/kunpengcps_video_0001.html指令流引擎文档https://www.hikunpeng.com/document/detail/zh/kunpengcps/cpturbokit/instrucstreamengine/kunpengcps_instruction_0001.html安卓模拟器方案安卓模拟器 安全说明书已下架安卓模拟器 编译指南 已下架安卓模拟器 安装指南（Ubuntu18.04）已下架安卓模拟器 安装指南（CentOS 7.6）已下架Robox容器方案Robox安卓容器 安全说明书已下架Robox安卓容器 编译指南已下架安卓镜像 编译指南（基于x86环境）已下架调优指南鲲鹏BoostKit ARM原生使能套件 调优指南已下架FAQ鲲鹏BoostKit ARM原生使能套件 FAQhttps://www.hikunpeng.com/document/detail/zh/kunpengcps/faqs/faq/kunpengcps_10_0001.html

      我loaction in 深圳，就是一个普通的资源开发整合，从云计算了解到之前的openstack是云计算的2.0，容器是云计算的3.0，现在从原生的角度来看一个事情，越容易实现公司项目的需求，这个就是我要的王道，就是如何让1+1>2是一个资源开发整合者的基本追求。       现在身在一个大企业中，技术运维等各种能力不是那么强悍的时候，这个时候就特别需要华为云的原生的生态去运维我司的业务，出现故障问题能够第一时间找到华为云的售后去解决问题，这个就是我希望要的效果吧。      容器来说比较轻量级别，对于一些应用或者说应用的迁移切换具备很多openstack挺多的优势，比如容器可以很快就起来一个的了，容器我经常理解为一个业务层的平台，非常快，期待容器的的操作更加傻瓜一些会更好。    云原生必然跟开业很多框架是生态化的，这样的话必然会有很多免费开源可以使用的东西，这样对我们来说确实是一个特别好的事情，我们也期待华为云的容器的CCE等原生态有更好的升级和更好的有机组合。   不单单是容器，现在时势都在谈论原生技术生态，作为一个技术的爱好者必须跟上学习的，不然可能就会错过风口，然后根据自己的业务项目情况判断一下是否要上到业务去，或者自己也会做一些灰度测试，或者灰度切换一部分业务上去跑一下。    在新的风口上，我起码努力去接触过，我努力过，人生能够遇上技术浪潮，跟上技术浪潮，我此生便无悔！     

我在华为云社区已经发布的博客《云原生（Cloud Native）产品之路》中阐述了一个观点：“Cloud Native产品之路的起点必须是产品团队对业务的深度理解，并且覆盖到团队每一个人。第二，将Cloud Native文化融入到业务与产品团队中。第三，团队的组织形式包括考核方式与这种文化匹配，简单的说，这个产品团队不应该有明确的职能划分。最后，选择合适的架构与平台，这个选择中做权衡时的原则是前三点。”在这篇博文中，我想详细打开第一点来讲讲。为什么说先要认识清楚自己的业务，然后再考虑云原生的问题？举个例子，你了解了云原生，告知你的团队需要打造一个云原生的产品，然后当进入到云原生细节之后发现，这里面太多的概念。说实话，一开始我就是完全处在混沌之中，技术词汇之多令人晕头转向。这时候很有可能你会放弃这条路，或者半推半就的摸索，事实上很多团队都是这么做的。其核心问题就是没有认识到这一规律：康威定律指出的组织形态决定了产品架构的形态。进一步说产品愿景决定了产品战略，产品战略决定了产品组织，产品组织决定了产品架构与开发模式。云原生的本质是一种产品组织方式，是否采用这种模式是产品战略自然而然选择的结果。举例来说，如果你的产品是一个小区智能监控系统，用户就是小区物业，需求几十年都不会变，这样的产品就不会选择云原生模式。再展开来说，如果你的产品是基于小区的智能监控，提供个性化的小区综合服务，比如访客管控、宠物跟踪等服务，主要用户变成了小区业主，产品要解决的问题是不同业主的生活服务需求，每天可能都有业主提出自己的想法，这时候如果你依靠产品体验而非资源垄断活下来了，可以断定你的产品一定会是云原生的，而且你的团队基本上聚焦在产品的体验与功能上，其他的中间件及底层都交给了服务提供商。产品愿景与战略是云原生产品的源点。因此，总结如何做优秀的云原生产品的第一条军规：明确产品愿景与战略，不人云亦云。那么云原生适配的产品愿景与战略是什么呢？我认为离不开这一点：为用户提供快速及可靠的服务。天下武功，唯快不破。云原生的最核心优点就是使用云端的资源将自己聚焦在业务之上，让自己的产品能够永远快人一步。只有这样，才能立于不败之地。如果你的产品战略有“快”这个核心要素，那么一定要选择云原生的产品组织形态。云原生为什么能快呢？简单来说就是人、流程与技术都是“快”的组织模式。云原生所提倡的“人”接近“通才”而非“专才”，这并不是说就不需要专业深度了，而是说具备专业深度的人还必须具备广度，要能做到专一且“什么都能做点”。我们所熟悉的全功能团队、全栈工程师都是如此，只不过这样的人确实不好找，所以需要营造一种文化，让团队每个人都开始打开思维。云原生的流程被人所熟知：DevOps。也即敏捷工程文化。其核心的思路就是不要什么都做完美了再拿出手，而是边做边给用户体验反馈，基于此将产品Idea到Product Feature的过程尽可能快起来，需求要快、设计要快、开发要快、测试要快、发布要快、交付上线要快......云原生的技术是最为被人知晓的，当然很多人也迷失其中，太多太多的技术栈了。简单一条，选择最主流的技术栈及最有实力的技术服务提供商。要想做到技术上快起来，一定不要小家子气，甚至有些还尝试自己去搭建云原生的基础环境，这绝对是错误的。总结如何做优秀的云原生产品的第二条军规：开放的拿来主义，只做自己擅长的，其他都交给别人。再强调，即使你再强大，如果你不是想做云原生的技术服务提供商，那你绝对不要关起门来思考与选择，找一个好平台，比如华为云的Service Stage，专心做自己的业务。第三条军规：把前两条军规告知每个人。结合我做的金融云产品，谈谈三条军规实践，以及为什么选择华为云。金融云产品的发展得以于蚂蚁金服和微信支付，将慢的金融行业变成了快的互联网行业。其中的本质我认为是：普惠化。普惠化实际上就是降低使用门槛，这需要技术和模式上的创新突破来实现，比如小额的信贷产品，银行为什么做不了？效率和成本的考量，简单地说就是不划算。蚂蚁金服通过大数据下的智能风控，实现了小额信贷的普惠化，一下子小生意的效率和成本问题没有了。这是中国的情况，世界更需要普惠化的金融技术，比如非洲和东南亚区域。这是中国金融云产品的更大机会。这就谈到第一条军规了，产品愿景和战略。我们定位于向世界输出普惠的金融技术平台，因此必须是云原生的，来处理不同的业务需求。第二条军规就需要选择适合自己的好平台，华为云被选择，因为全球通达的属地化服务能力、宏观资源的获取能力以及全栈技术的积累。开放的拿来主义，我们剥离掉了一切非业务核心的任务到华为云Service Stage，专心于业务本身。当然，师从蚂蚁金服也是必须的，Sofastack是一个很好的开源框架，值得每个金融云产品玩家实行拿来主义，至少是学习。其次，开放还要生态优先，也必须不重复造轮子。最后要基于三条军规做优秀的云原生产品，还要保持创新，更简单的说要正确的做正确的事。必须破除沉没成本，非云原生的那些积累通通要丢掉，别被老资产的复用思维所累。

    我来自一个手机厂商，了解到云原生的时候，是因为自己有用到这个技术的需求，当时自己在做一个私人的项目，需要同时兼顾前后端、数据库等这些组件，因为是自己的项目，所以没有很大的资金支持每种技术都配一**立的服务器，所以就查到了云原生这个系统里面的容器能解决我的问题。    首先来科普一下云原生是怎么一个东西，有什么特征，由什么组成。云原生是在2015年由科技巨头google这家公司牵头，一百多家企业和机构一起合作成立的一个项目，云原生包括3大特征，一是容器化封装，容器化封装就是将每一个小的功能封装起来，使得他不受当台电脑上其他的业务影响，也是我受用到的技术，二是动态管理，就是通过集中式的编排来对各项技术进行动态调配和管理，三是面向微服务，就是将原本一个很复杂的系统拆分成很多个小的板块来进行合作编排。    接下来讲一讲我和云原生中的容器三生三世的事情，这些事情可能没有电视中那么有趣，但看完后同样值得人去深思......    当时在做一个项目，需要同时搭建起来app和网站这两个东西，而且是online的，那么必定要有前后端代码支持放在服务器上，因为还要存储一些用户数据和后台数据，那么mysql数据库自然也需要一定的线上存储空间，因为是自己的一个项目，每项功能用不到考虑稳定性、延时性，而且要考虑成本，所以我刚开始就找了好几台1核1cpu的华为云机器去做这个技术，这就是云原生的第一世---错过篇。    租好这几台服务器后，第一步要做的就是搭环境，这几台服务器之间有一些公用的环境，我刚开始的时候就挨个在每台服务器上去搭建，这样不仅耗时而且无聊，然后我就了解到了云原生这个技术，第一仅要1台服务器就可以搞定，给我省了不少维护时间，第二很多环境只用搭建一遍，又省了一些时间，并且保证了稳定性(少动就会稳定)，这样我就将整个技术架构用到了云原生的容器分割里面，稳定又高效，这就是我和云原生的第二世---相约篇。    利用云原生技术，我最终的项目成果在公共展示的时候，获得了很好的一个成绩，这就是我和云原生的第三式---付出与回报篇。    云原生因为他的优势，现在已经有好多个开源技术框架产生，比如lstio、Prometheus、Helm、Spinnaker、KubeLess。

云原生的概念自2013年一经提出，就备受关注和推崇在IT圈儿混的，对云原生技术想必都不陌生特别是对容器、服务网格、微服务、Serverless 等云原生代表技术，或多或少都有一定了解很多企业甚至已利用云原生技术成功实现了业务上云的转型 那么问题来了从邂逅云原生到相识相知携手踏上新征程，你/公司是怎么做到的，都经历了些啥？520秀完恩爱，是时候秀秀你与云原生的那些事儿了！华为云容器团队现面向广大程序猿征集你与云原生的故事、技术心得、上云实践/案例等参与即有机会获得华为手环、云原生专业书籍、京东E卡等多重好礼哦分享创造更大价值，你还在等什么，赶紧参与吧~ 活动具体内容&规则如下：1. 征文时间：2019年5月27日-7月31日2. 参与对象：华为云容器服务用户、云原生技术爱好者3. 参与方式：点击进入“云原生研究所”- 选择“云原生生态”分类，即可发布参赛文章帖啦，记得将帖子标题及链接回复在本帖下哦（用于参赛统计和奖品发放，一定要回复到本帖下，否则可能无法参与评选）4. 内容要求：分享你/公司与云原生的故事、技术心得、上云实践/案例……只要与云原生相关内容皆可，500字以上，不限题材，自由发挥。比如，可以谈谈你对云原生技术的理解，聊聊你个人or公司在使用华为云容器服务过程中的心得体会。当然，如果能分享一些容器给公司业务带来的变化就更好啦~>举个栗子：-标题：我与容器的不解之缘-正文：坐标深圳，XX公司程序猿一枚，一直有关注容器技术……公司去年开始使用华为云容器服务CCE，逐步将应用进行容器化改造……大幅度降低了成本，提高了运维效率，还让我得到了晋升的机会……5. 评选规则：>评选标准：1）可学习参考性  2）内容真实性  3）内容完整性>评选方式：活动结束后，华为云容器服务专家评审团将对参赛文章进行评审，并于1周内公布结果。6. 活动奖励：一等奖：1名   华为手环+云原生专业书籍二等奖：3名   云原生专业书籍 三等奖：6名   50元京东E卡7. 注意事项：1）按参与方式参与，其他方式无效；2）请勿大篇幅抄袭其他用户的文章，一经发现，取消参赛、获奖资格；3）禁止恶意刷数据等作弊行为，如有发现，取消参赛、获奖资格；4）遵守华为云社区常规活动规则https://bbs.huaweicloud.com/forum/thread-5766-1-1.html5）本活动最终解释权归华为云容器团队所有。激扬文字，创造更大价值，点击参与吧~

【华为云专家，期待您的加入】如果您也热爱技术、乐于分享；想要参与技术沙龙、拓展人脉、打造个人技术品牌....华为云专家欢迎您的加入！华为云MVP：点击了解华为云·云享专家：点击了解更多问题欢迎咨询华为云专家小助手↓↓↓

0  我是谁？杜军，《Docker——容器与容器云》和《云原生分布式存储基石：etcd》这两本书的作者。现任职于华为Cloud BU PaaS服务产品部，主要负责容器与Kubernetes集群管理技术的研发。是Kubernetes核心维护者，也是CNCF TOC Contributor。在Kubernetes社区主导了Kube-proxy IPVS模式，Pod网络QoS，流图调度器Poseidon，Cluster-API-OpenStack和边缘计算KubeEdge等项目的开发。你可以在KubeCon，LinuxCon和CNUTCon等大会找到我分享的主题演讲，我也做过多次Kubernetes和CKA考试的培训。1      如何理解“云原生”这三个字？  云计算时代，企业将不再耗巨资投资自己的IT系统，而是直接使用无限制的按需付费的云服务，这无疑将显著降低IT基础设施的开销，加速软件占据世界的进程。作为程序员，我时常为自己有机会投身于这个波澜壮阔的技术变革事业而感到莫名激动。  回到正题，我理解的云原生是一种新的软件工程方法，即充分利用云计算的优势来构建（build）和运行（run）软件。“Build once, run everywhere”，当初Docker公司提出的这个口号现在喊起来是否已经朗朗上口了？  有时候我们会反思，当容器技术方兴未艾的时候，是什么促使了云原生技术如雨后春笋般在企业内萌发呢？诚然，“一次构建，到处运行”——容器良好的良好的可移植性，敏捷性和Docker革新的镜像打包方式相较云计算最初的IaaS虚拟机形态，更加容易地成为公有云全新的基础设施和交付手段。但Docker毕竟只是一个runtime，当我们需要一个编排框架作为系统核心来串联开发、测试、发布、运行和升级等整个软件生命周期时，它就略显单薄。  搞大规模的基础设施，还得看Google，毕竟人家管理大规模的容器集群已经快二十年了，哪怕是在公有云领域攻城略地、出尽风头的AWS，都没有Google在容器领域积累的深厚经验。Kubernetes就是Google照着鼎鼎大名的Borg系统开源出来的容器编排引擎。如今的Kubernetes，既是 GitHub上的明星项目，也获得了了全世界所有公有云厂商（包括AWS）的青睐，更是让当年不可一世的Docker公司低下了他那高傲的头颅。  关心容器生态圈的朋友，想必都已经接受了Kubernetes作为容器编排甚至是云原生标准的事实。2      什么样的技术才能配得上“基石”二字？  etcd的作者，李响曾“傲娇”地说，“etcd就是用来存储云上最重要的数据的”。  从技术上的角度，用户大可以放心这么做，因为etcd底层采用的Raft一致性协议保证了数据的分布式强一致性和高可用。一个etcd数据集群，即使挂掉半数节点，也不影响集群的正常工作。  李响的底气更来自于，etcd同时被经典PaaS的代表Cloud Foundry和容器云新贵Kubernetes采用，作为他们后端数据存储和协同的关键组件。毫不夸张地说，etcd就是Kubernetes和Cloud Foundry的“心脏”。更饶有趣味的是，Docker Swarm的节点管理系统也引用了etcd的Raft库，要知道Docker和CoreOS（开发etcd的公司）曾经在容器runtime战场上有过一番争夺啊！我只能感叹，etcd的代码质量之高以至于让商业竞争对手都放下了门户之见。又或许，Docker Swarm那时也找不到更稳定的Go语言版本的Raft实现了。更不用说，TiDB这类新兴的分布式NewSQL数据库基于etcd的Raft库构建分布式事务、跨数据中心数据强一致性、故障自恢复等能力。  经典PaaS我们不必再提，考虑到Kubernetes在当今云原生时代所扮演的角色，用“基石”二字形如etcd的重要性一点都不为过。事实上，etcd也不负众望，很好地扮演了“坚若磐石，稳如泰山”的云原生大厦基石的角色。etcd作为硅谷明星创业公司CoreOS最重要的项目，一开始便含着“金钥匙”出生，直接被Kubernetes指定作为其后端的存储实现。  “Kubernetes是Borg的开源实现，在Google内部，Borg使用Chubby作为分布式协同的后端，Kubernetes选择了etcd——一个Go语言的Chubby实现。”  Kubernetes的创始人如是解释道Kubernetes和etcd的结缘。相较于基于Paxos协议，并且给Google的工程师们带来无尽软件工程梦魇的Chubby，etcd底层的Raft协议容易实现太多，再加上由Go这门被Google寄托了太多云时代愿望的编程语言编写，自然能够无缝融入到Kubernetes的生态之中。  如果说当初etcd搭上Kubernetes的快车还有些“幸运”的成分，但是etcd伴随着Kubernetes共同成长，历经了从V2到V3的重大版本更新，经受住了Kubernetes大规模部署最严苛的可用性和性能考验，就是它实力的体现了。Kubernetes项目早期还预留了对接多种后端存储的接口设计，现如今再去讨论这个话题已经失去了意义，因为etcd作为Kubernetes后端唯一存储早已深入人心。诞生于云原生星火燎原之时，上天再把你派到Kubernetes这个老大哥身边，把你打造成开源的Chubby，云原生的分布式存储基石，这是一份多么让人艳羡的履历啊！什么叫天之骄子？我想这便是！3     成书缘由  笔者求学于国内云计算研究最前沿的浙大SEL实验室，从研究生开始便投身于云原生技术的探索与实践。从最开始研究KVM虚拟机，再到后来的底层基础设施CloudStack，OpenStack，也参与过经典PaaS Cloud Foundry在企业私有云的落地。  在2014年Docker和Kubernetes技术刚诞生之时，我们实验室的几位老师和博士（其中便包括后来的Kubernetes核心维护者张磊）便敏锐地意识到这将是改变未来十年基础设施的新技术，出于技术布道的目的，我们合著了并出版了国内第一本深度解析Docker和Kubernetes的书《Docker——容器与容器云》。由于我负责该书Kubernetes部分，因此在写作过程中便对etcd有过较深入的研究，但考虑到彼时etcd还是0.4版本，功能比较简单，而且和该书的主题关联不强，所以就没有花篇幅介绍etcd。但彼时便被etcd简明的架构设计和优美的Raft算法实现深深折服，从此心中埋下了一颗独立出版一本介绍etcd书籍的种子。  毕业后由于工作关系一直深耕Kubernetes，并基于Kubernetes构建华为公有云的PaaS平台。自然，etcd是整个华为PaaS平台的重中之重，我所在的技术团队也经历了从Kubernetes 1K节点到10K节点百万容器规模的艰辛蜕变，积累了不少etcd在大规模场景下的运维和性能调优经验。我想，任何基于Kubernetes构建的云平台都会碰到我们之前解决过的各种etcd相关的问题，比如：数据容灾恢复，watch缓冲区溢出，高并发带来的读写性能衰退，磁盘I/O低下导致的集群频繁选主等问题。很多情况下，这些问题并非etcd的问题，是因为我们对etcd的核心机制不理解或理解不充分导致的。     etcd的官网只有粗浅的API使用等资料，缺乏对etcd架构和原理的深度剖析——可能这个世界上最懂etcd的人太忙没时间写文档吧。市面上介绍Kubernetes的书籍多如牛毛，却“不约而同”地忽略了最关键的etcd的相关内容。按李响的原话讲，“etcd是一个需要动脑子的项目”。尽管Raft算法和Paxos相比容易理解了很多，但对初学者来说里面仍然有不少奥秘需要点破。恰逢etcd准备捐献CNCF，急需中立的项目维护者，我希望更多人了解到这个优秀的项目，壮大开源社区。  因此，本着技术分享，回馈社区的心态，我们华为云容器服务团队合著了这本《云原生分布式存储基石：etcd深入解析》，希望在探索云原生落地的道路上，有更多志同道合的朋友加入，有你从此便不再孤单。  可能有人会问，市面上不是已经有一本etcd源码解析的书了吗？但我们需要注意到，etcd项目迭代更新快，今天拉的代码过上几个月有可能就变得面目全非，纯粹的源码解析的书籍很难做到与时俱进。此外，很多etcd的运维人员可能并不关心etcd的源代码，他们更关心如何使用etcd。在我的上一本书写作过程中，我就意识到了这个问题，因此《云原生分布式存储基石：etcd深入解析》是第一本涵盖分布式基本理论，分布式一致性协议Raft，etcd使用，运维，API，源码解析等内容的书，更是第一本综合分析了etcd V2和V3差异的书。希望各个层次的读者都能够从中获益。4      谁应该看这本书？如果你正在学习或者使用Kubernetes，我建议你看下这本书，因为Kubernetes后期的坑都在etcd，这本书可以让你提前知晓并且避开那些坑。如果你是分布式系统的爱好者，你可以从这本书了解到分布式系统的基本理论，包括：CAP理论，复制状态机，拜占庭将军问题，FLP不可能性等。如果你想自学Raft协议，这本书详解了Raft一致性算法，包括：Raft选举过程，日志同步，快照，异常恢复等机制。如果你是etcd的初学者，这本书手把手教你如何部署一个etcd集群，并用相当多的篇幅解释了etcd的基本概念、常用命令和配置方法等，更有常见问题的Q&A和实践分享。如果你是Kubernets/etcd的运维人员，etcd集群的稳定性关乎线上/线下环境的平稳，我建议你的案头放一本这书，每天闲时翻一翻，集群升级，备份恢复，日志监控，性能调优，认证授权等知识点一网打尽，彻底告别临时抱佛脚。如果你是etcd的开发者，这一本不错的API参考书，里面详细罗列了etcd V2和V3的常用API调用和各个参数的含义。如果你是高阶的分布式系统开发者和架构师，这本书你没有理由错过，因为它从源码级别娓娓道来etcd的多版本并发控制（MVCC），etcd V2存储机制，etcd V3数据模型，etcd的日志和快照管理，etcd V3的事务和隔离，etcd watch机制等实现细节，你可以从中汲取分布强一致性存储系统的设计灵感。5     如何获得这本书？《云原生分布式存储基石：etcd深入解析》一书由机械工业出版社在2018年11月5日正式出版，华为云容器服务团队荣誉出品。 各大平台均有发售，新书发售期间折扣力度较大：京东（自营有电子版），淘宝，当当（自营有电子版）。欢迎大家积极勘误，找到的错误直接回帖即可，找错最多的五位同学将有机会获得作者本人给各位充值话费哦~还请各位专家不吝赐教并反馈宝贵意见帮助后续改进！

每期直播预告+材料下载，请点击收藏总帖：https://bbs.huaweicloud.com/forum/thread-9573-1-1.html【Cloud Native Lives系列直播 】第1期：《云原生技术的前世今生 》，7月12日直播已经结束。错过直播的朋友也不用遗憾，奉上最全材料~1.网页回放地址：https://zhibo.huaweicloud.com/watch/22349432.扫码观看回放：3.PPT最全下载：Cloud Native Lives 课程一：云原生技术的前世今生 (1).pdf( 预览 )