■关修永
数据库与芯片、操作系统并列为全球信息技术三大件，也是企业IT系统必不可少的核心技术，同时也是一切数字处理、计算力和智能化的基石。
上世纪70年代，E.F.Codd发表了一篇划时代的论文《A Relational Model of Data for Large Shared Data Banks》。从这篇论文开始，关系型数据库软件革命的序幕被拉开了。80年代初期支持SQL的商用关系型数据库Oracle和DB2相继面市，以及90年代诞生的SQL Server，开源的MySQL，PostgreSQL 等都是关系型数据库成功的代表。
时至今日，随着全球不同类型数据的指数级增长，市场上涌现出越来越多的新型数据库，然而关系型数据库仍然占据主导地位。根据市场研究机构IDC的最新统计数据显示，关系型在全球数据库中占据约80%的份额。
关系型数据库经受住时间的考验，成为全世界用户的钟爱，最主要的原因之一就是关系型数据库采用了SQL标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美衔接在了一起。到今天，这种编程语言还没有更加完美的替代品。
数十年来，关系型数据库都应用在以IOE为代表的软硬件紧耦合的技术架构环境之下，但是今天，关系型数据库面临着云计算成为主要承载工作流载体的巨大改变。
这种使用环境的变革性迁移之下，客户对关系型数据库也提出了新的要求，比如可以支持更大的存储、弹性扩缩容上更灵活，甚至数据库可以实现“自动驾驶”。
阿里云的数据库团队认识到，如果基于传统关系型数据库的架构进行小修小补，很难解决这些客户提出的问题，必须从根本上演进云上的关系型数据库架构，做一个全新的云原生关系型数据库。PolarDB云原生关系型数据库也就此诞生。
过去5年，阿里云针对PolarDB进行了诸多创新，通过采用存储计算分离、软硬一体化设计，PolarDB实现成本仅为传统商业数据库的十分之一。所实现的计算、内存与存储资源的3层解耦架构、多主多写、基于内存列存索引（IMCI）的HTAP，Serverless等功能已是全球首创或业内领先的技术。
PolarDB从发布以来，在技术和商业化上都获得了迅猛发展，如今已经成为阿里云数据库产品家族中最闪耀的产品。
三层解耦：资源解耦的极致
从40多年前数据库诞生开始，数据库的CPU和内存都是绑定在一起的，最多做到计算和存储解耦，没有数据库能做到CPU和内存的解耦，即使演进到目前的云原生数据库阶段，在PolarDB之前也没有任何数据库能够做到这一点。
然而在云计算时代，每一层的资源解耦都可以使得弹性能力带来数量级的提升。当前云原生数据库虽然实现了计算存储的解耦，相对于传统数据库，其弹性能力有了不小的提升，但是CPU和内存的强耦合极大地限制了弹性能力的进一步提升，难以实现秒级跨机迁移；同时也限制了内存的横向扩展，使得内存受到单机容量限制。
PolarDB历史性地提出并实现了基于CPU、内存和存储资源分离的三层解耦架构，构建了独立的CPU资源池、分布式内存资源池、分布式存储资源池，实现了资源的彻底解耦，CPU和内存分别独立计费。同时通过分布式内存和数据库秒级跨机迁移，使得弹性能力有了数量级的提升，大幅降本增效。
多主架构：云原生数据库不再是单写数据库
云原生数据库从诞生开始，就和一写多读绑定在了一起，似乎云原生数据库天生只能是单写。写扩展能力的缺失，给用户带来了很大的困扰，很多用户在写节点到达甚至接近最大规格一半的时候，就开始担忧后续业务快速增长会导致数据库出现瓶颈。因此不得不重新考虑其他数据库架构方案，而放弃云原生数据库，或是依赖传统数据库的横向扩展方案，例如中间件来实现横向扩展。虽然业内也有个别厂商开始尝试多主节点，但受限于节点数，并不能实现真正的横向写扩展。
作为应云而生的云原生数据库，有没有一个云原生的解决方案来实现写扩展呢？“PolarDB
多主架构”由此而生。这是业内第一个支持大规模多主多写的云原生数据库，最大支持32个写节点。在PolarDB多主架构中，阿里云在整体架构从元数据、事务、锁、Undo/Redo、IO、代理等所有子系统均做了多主
化改造；并采用了PolarFusion技术，实现了多个写节点的高效数据交互。
PolarDB多主架构从根本上解决了用户的单主焦虑，使得PolarDB第一次突破了单主限制，实现了横向写扩展。数据互通后的主主互备通过消除备节点在RTO不变的情况下节约一半的成本。跨主节点秒级流量切换也为SaaS、游戏等行业解决了多租户/游戏服的跨节点调度提供了强有力的手段。
Serverless的跨机突破
Serverless是最适合云数据库的一种交付模式，实现了按需供应，使得用户不需要再为数据库规划容量，在高峰时自动升配提升稳定性，在低峰时自动降配降低成本，一时间云数据库厂商都纷纷推出了自己的Serverless形态。
然而，当前业内的数据库Serverless形态均为单机Serverless，其容量上限受到了很大的限制（8~32core），并不能很好地实现其高峰时自动升配以保障稳定性的目标，也限制了企业级客户的使用，同时读写节点自身的升降配对本节点的吞吐同样存在影响。这些限制的本质是目前云数据库的无感跨机弹性和强一致跨机扩展能力都尚不成熟，导致当前只能实现单节点下有限的Serverless。跨机弹性的限制是节点无法跨机调度，因此单节点弹性上限只能限制到一个远小于物理机限制的值；而跨机强一致读扩展的能力缺失，导致其无法通过增删强一致的只读节点来实现读流量的弹性。
为解决单机Serverless的局限性，阿里云在业内第一次突破了这2个技术难点，基于事务续传和秒级切换的无感秒切技术，解决跨机弹性问题。性能无损的强一致读技术，结合热节点池技术，解决跨机透明读扩展问题。
基于以上技术突破，PolarDB Serverless的上限规格突破了1000core，带来了数量级的Serverless能力提升，使得Serverless技术有了支撑企业级业务的能力。
HTAP：同时处理交易和分析性负载
传统面向OLTP场景设计的关系型数据库，一般优化目标是提升单核性能、多核扩展性、增强集能力以提升可用性等，其分析性能往往不佳。然而真实业务的SQL又天然是TP/AP混合的，其需要事务处理和实时数据分析兼具的HTAP 系统。面对此问题，传统方案是使用一套数据同步系统串联起上游的TP系统和下游的数仓系统，形成一套搭积木的方案，用多套系统的组合来完成任务。
在云数据库时代这种架构因为串联了OLTP数据库，消息中间件，OLAP数据库三套系统，上下游协议不兼容，运行维护复杂。在云上很难规模部署以满足各种客户的需求。
针对这些问题，在PolarDB云原生数据库领域的技术积累基础上，阿里云在PolarDB上推出In-Memory Column Index 功能，为PolarDB带来列式存储以及内存计算能力，让用户可以在一套PolarDB数据库
上同时运行OLTP和OLAP型混合负载，在保证现有PolarDB优异的OLTP性能的同时，大幅提升PolarDB在大数据量上运行复杂查询的性能，让PolarDB 真正成为一款HTAP数据库。
PolarDB HTAP包含如下几个关键技术创新：
1.PolarDB存储引擎新增对列式索引（Columnar Index）的支持，用户可以选择通过DDL将一张表的全部列或者部分列创建为列索引，同时列索引采用列压缩存储，其存储空间消耗会远小于行存格式。
2.在PolarDB的SQL执行器层，阿里云重写了一套面向列存的执行器引擎框架（Column-oriented），该执行器框架充分利用列式存储的优势，使用向量化执行方法提升算子处理海量数据的效率。同时充分发挥现代CPU的SIMD指令能力，提升CPU单核心处理数据的吞吐，且所有关键算子均支持并行执行。在列式存储上，新的执行器对比MySQL原有的行存执行器有几个数量级的性能提升。
3.支持行列混合执行的优化器框架，该优化器会根据兼容性及执行计划代价两方面的因素，以选中最优的执行路径。
同时阿里云还充分利用了PolarDB云原生数据库的技术优势，支持HTAP节点的规格异构及按需弹性（Serverless），为用户提供一体化HTAP体验的同时兼具极致的性价比。
并行查询：突破单节点的资源和性能瓶颈
传统的基于MySQL的关系型数据库在部署到云上后，依然采用了主备复制的数据同步模式来提供实例的高可靠和高可用，但基于逻辑复制导致实例延迟增大、多份存储等问题。PolarDB通过共享存储和物理复制实现了云上的计存分离和资源池化能力，为用户提供了最优的弹性能力和性价比。而从线上的长期运维可以发现，云上用户实例对CPU资源的平均利用率是较低的，同时MySQL对查询的单线程处理方式又无法满足业务上基于海量数据的实时分析需求，这造成了极大的资源浪费。
为此阿里云推出了节点内以及跨节点并行查询（Parallel Query）功能，针对性的利用多核CPU并行计算来提升查询响应速度。但随着共享存储层的数据量进一步增长，单机的扩展能力将遇到瓶颈，包括CPU、Memory和IO等，传统数据库通过Share nothing的分片架构和MPP计算引擎来突破单机的资源瓶颈，但这破坏了云上计存分离带来的独立扩展性和极致弹性能力，有悖于现代云原生数据库的发展趋势。
PolarDB解决这个问题的方案是更为先进的计算、内存、存储三层解耦模式，通过将资源进一步拆解，在各个层面上各自独立扩展。而针对大数据量分析查询，在计算这一层基于
Parallel Query进一步演进，推出了基于共享存储的分布式弹性并行查询（Elastic Parallel Query），通过节点间+节点内两层并行的结合以及基于分布式资源视图的智能调度策略，打通了集内的多节点计算资源。与传统的固化的MPP架构相比，这带来了多方面的技术和成本优势：
1.通过多粒度的并行，更充分的利用集级的计算资源，突破单节点的资源和性能瓶颈，PolarDB在利用并行查询提升CPU利用率的同时，也开发了并行DDL等能力，大大缩短了DDL的时间，解决了一些大用户的一个重要痛点，实现和传统MPP系统相同甚至更优的极致查询性能。
2.基于分布式的全局资源视图，并结合数据的亲和性特征，对查询内的子计算任务进行智能调度，在尽可能避免IO 的情况下实现各节点计算资源的均衡利用，避免局部热点带来的性能和维护问题。
3.与云上的自动弹性无缝结合，随着实例计算层的Scale up/Scale out自适应的调整并行计算策略，既满足了用户的成本和性能需求，又无需额外的配置维护动作。
4.灵活控制实例级别的计算资源拓扑，通过不同接入地址（子集），实现不同业务的相互隔离和各自独立配置，满足具有不同特性的查询业务需求。
分布式：实现透明分布式体验
数据库经历过去40多年的发展，随着互联网、大数据的飞速发展，单台务器上的性能极限已经慢慢显露，在这种情况下，技术人员逐渐开始探索数据库的扩展能力，目前整体扩展架构有2种形态：基于共享存储的Share-storage架构、以及基于Share-nothing的分布式架构，这2种架构分别代表了2个不同的扩展思路，有各自的优缺点。
基于Scale-up的单机扩展架构，在面向高并发场景下，容易遇到单机扩展性的天花板，因此，从2019年开始，PolarDB 基于Share-nothing的分布式架构，正式推出了云原生分布式版（PolarDB-X），支持多写多读、以及低成本的冷热分离分层架构。
PolarDB云原生分布式版作为一款基于原生MySQL的云原生分布式数据库，高度兼容MySQL的协议和开源生态，引入Paxos多数派共识协议，聚焦国产化MySQL替代、分布式线性扩展、以及HTAP混合负载等场景。
PolarDB云原生分布式版（PolarDB-X）包含如下几个关键技术创新：
1.透明分布式体验，引入自动数据分区与数据自动亲和性聚集技术，自动识别数据的业务属性进行相关性绑定和统一调度，在提升数据库线性扩展能力的同时，避免因为跨分区的事务和复杂查询带来的性能开销，最大程度将事务涉及范
围局限在单个物理节点，以及最大化下推计算算子减少数据交换。结合全局二级索引、在线数据变更，做到分布式数据库接近单机数据库体验，打破了分布式能力应用现实场景中的关键障碍。
2.冷热分离存储架构，引入数据分区的Time-to-Live （TTL）策略，随着时间推进，可以将历史不常访问的冷数据进行定期归档，PolarDB分布式结合云对象存储OSS作为冷存储介质，采用编码压缩、以
及OSS本身的成本优势，冷数据仅有MySQL InnoDB在线数据1/20的存储成本，同时提供单个数据库实例的透明使用体验，统一SQL访问、备份操作等。
3.全面拥抱国产化，基于全内核开源的策略，坚持基于MySQL的敏捷可控路线，目前PolarDB已经顺利高分通过分布式数据库的金融行业标准认证、信通院的分布式数据库性能和高可用认证等。除了满足公有云的交付外，PolarDB还可以面向传统金融、政府行业的私有云交付以及基于开源内核的纯软部署能力，它全面支持数据库的多场景、多形态的交付能力。
PolarDB云原生分布式版（PolarDB-X）的数据库形态，结合云原生+分布式+国产化的技术，未来也会进一步融合HTAP混合负载能力，引入行列混存架构，更好的满足数据实时性的要求。
性能演进：提出一系列优化方法
设计之初，PolarDB的理念就是为云上用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。PolarDB采用计算和存储分离的架构，通过物理复制技术和共享存储架构，在满足业务容量弹性扩展需求的同时极大的降低了用户的存储成本。在设计上，PolarDB既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源云数据库简单开放、自我迭代的优势。
依托于阿里云先进可靠的硬件平台，PolarDB采用RoCE RDMA网络、3DXpoint存储介质等先进技术，
并面向新硬件架构实现软硬一体优化。从数据库内核、文件系统到网络通讯协议和分布式存储系统，PolarDB实现了纵贯软件栈各层次的深度优化。仅构建高性能硬件底座并不能完全解决云原生数据库的性能问题。例如即便拥有高吞吐的RDMA网络但聚合带宽难以充分利用；远端节点I/O访问、多副本持久化等要求使得云存储I/O延时远高于本地存储；又比如更长的数据链路中有更多的排队，导致I/O间的隔离性变低；共享存储架构缓存并发代价等。针对云原生数据库面临的性能挑战，PolarDB的存储引擎提出了一系列优化方法：
1.并行化多任务：例如对集中日志缓冲区按页面分区分片，实现并行写入并基于分片进行并行恢复。
2.预取和读取裁剪：例如通过收集并聚合分散的元数据至统一的超级块，将多个I/O合一实现快速验证；通过预读利用聚合读带宽、减少读任务延时等。
3.锁优化：针对系统瓶颈，实现无锁刷脏、基于Blink-tree 的无锁SMO等。
4.访问打散和优先级调度：例如将单个大I/O并发分散至不同存储节点分散访问，充分利用云存储聚合带宽；在DB 层面对不同I/O进行打标、调度优先级，消除长链路、低隔离I/O任务的影响。
5.通过绕过缓存的方式来避免分布式文件系统的高速缓存一致性，并在DB层面优化I/O格式匹配存储最佳需求格式。
上述例子也只是显露了冰山一角，PolarDB在性能演进之路上也将不断向前迈进。
展望未来：一切才刚刚开始
上市5年来，PolarDB在架构、功能、性能等方面不断创新，其实这些创新都是围绕一个目的，就是不断释放云计算资源池化的潜力，最大化云计算资源池化的价值。不仅如此，PolarDB还坚持开源开放的理念，将PolarDB-PG和PolarDB-X进行了全内核开源，推动了整个行业的技术变革。
2021年杭州云栖大会上，阿里云智能数据库产品事业部与达摩院数据库与存储实验室负责人李飞飞提出，PolarDB 要将云原生进行到底。因为他早在2019年就断言，未来的数据库一定是云原生数据库。他说：“云原生数据库在成本、灵活度、安全、技术进化层面都优于传统数据库，传统数据库会像马车一样被淘汰。
现代数据库技术已经有40多年发展历史，对比之下，新一代云原生数据库的创新也不过几年时间，一个全新的云原生数据库时代已经到来，创新才刚刚开始。
■宿俊艾
本篇文章将带您系统了解关于企业级微服务治理与开发的关键概念及选型指南，希望能为您的企业级现代化应用建设提供启发。
微服务是应用现代化趋势下的必然选择
随着数字经济的不断发展，企业面临着更加多样化、敏捷化的新时代IT需求。
用户行为的变化：业务应用的用户访问不可预估，突发性访问增多，存在临时热点事件或大促期间等不可控业务高峰期。
业务模式的变化：所有业务访问都是通过互联网渠道，包括Web、手机App、小程序等。
业务系统开发的变化：应用再也不像以前半年或一年进行规划，随时会有需求变化，两周一个迭代成为常态。业务应用交付周期短，质量要求高。
运维模式的变化：要求全天候值守，在线升级和快速响应，不同团队特别是外包团队使用不同的技术栈，无法统一管控。
因此，评估一家企业是否需要采用微服务架构，往往考察这五大关键条件：数据量和业务复杂度、团队规模、应对业务流量变化、是否有足够的容错容灾，以及功能重复度和差错成本。
在日益激烈的数字化竞争下，企业必须更快地拥抱市场变化、随时响应新的用户需求，比对手更迅速地将产品推向市场。
微服务作为加速企业提升敏捷创新能力的重要抓手，能够帮助企业快速实现独立更新和部署应用，快速应对市场变化，逐渐成为企业加速应用现代化的必然选择。那么，微服务架构要怎么选择？
Dubbo
Dubbo是比较早期的一款微服务架构，可以使得应用通过高性能的RPC实现服务的输出和输入功能，和Spring框架无缝集成。
优点是RPC长连接+NIO，性能更高，但协议的局限性，会限制生态发展和兼容性。
常见mpp数据库Spring
Cloud
Spring Cloud是基于Spring Boot的一整套实现微服务的框架，提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线等组件。Spring Cloud包含了

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。