应用框架

近日，2017云栖大会·深圳峰会如期举行，多项阿里云新产品对外发布。在企业级互联网架构分会场，来自阿里中间件（Aliware）的技术专家及合作伙伴，为现场参会嘉宾带来最新的传统IT架构到企业级互联网架构跨越式升级、实现互联网转型的产品及解决方案。其中高级技术专家姜宇在分享中带来的Aliware新产品—全局事务服务（GlobalTransactionService，简称GTS），在分布式事务处理上带来的高性能和技术创新令到场参会的各路技术专家眼前一亮。

Aliware新成员—全局事务服务GTS技术分享现场

分布式事务背景

OLTP领域中很多业务场景都会面临事务一致性的需求，传统业务系统常以单体应用形式存在，只需借助特有数据访问技术和框架，结合关系型数据库自带的事务管理机制来实现事务一致性的要求。而目前大型互联网应用和平台往往是由一系列分布式系统构建而成，平台和技术架构也是流派纷呈。

尤其是微服务架构盛行的今天，一个看似简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，单一技术手段和解决方案已无法满足这些复杂应用场景。因此，分布式系统架构中分布式事务是一个绕不过去的挑战。什么是分布式事务？简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库或消息系统的数据一致性。

分布式事务三大难题：一致性、高性能和易用性

分布式系统的事务一致性本身是一个技术难题，没有一种简单完美的方案能够应对所有场景，很难兼顾事务一致性，高性能与易用性。三者缺一，则适用场景大大受限，实用价值不高。

首先是一致性：要求在各种异常情况下保证数据是强一致的。目前最常见的一致性解决方案是最终一致性方案，通常是结合消息中间件实现，在互联网企业中广泛使用。最终一致性实现方案比较复杂，开发、运维成本高，并且与强一致相比，业务上是受很多限制的。

其次是高性能：目前基于XA协议的两阶段提交是最常见的分布式事务解决方案，但XA类产品的典型不足是性能低下，这对于互联网大并发需求下的多数企业是无法接受的。国外具有几十年历史和技术沉淀的基于XA模型的商用分布式事务产品，在相同软硬件条件下，开启分布式事务后吞吐经常有数量级的下降。

第三是易用性：为了满足一致性和高性能要求，出现了一些特定场景下的分布式事务方案，但通常会限制用户用法，对业务侵入性强，无法做到简单易用，带来更多开发成本。

世界级应用场景，催生世界级分布式事务解决方案

早期的阿里巴巴集团随着业务高速发展，内部不断涌现各种典型的分布式事务需求，比如阿里内部广泛使用的TDDL分库分表所带来的分库间数据不一致问题，HSF服务化后所带来的服务链路上数据不一致问题等。在这个过程中，各业务技术团队利用现有中间件技术手段实现分布式事务处理，但这些手段都较为复杂，工作量大，对应用侵入严重，有些适用场景还有限制。

2014年5月开始，阿里中间件（Aliware）内部命名为TXC的分布式事务中间件开始研发，同年10月1.0版本发布，分布式事务功能已经具备，但性能还有局限，只适合于吞吐量较小的场景；2015年12月，TXC2.0版本发布，相比1.0版本性能提升10倍以上，在阿里内部多条业务线得到部署。

通过部署TXC，应用只需极少的代码改造和配置，即可享受分布式事务带来的便利。TXC作为阿里内部为解决分布式数据强一致性问题而研发的分布式事务中间件，彻底解决了分布式事务数据一致性的问题，简单易用，先后在淘宝，菜鸟，淘票票和村淘等多个业务的核心系统上得到部署和验证。

顺应云时代潮流，GTS应运而生

从2016年年中开始，在阿里内部一直接受锤炼的分布式事务中间件TXC在2.0版本后，随着阿里中间件上云热潮，开始通过专有云输出，并得到了市场极大认可，适用场景得到进一步拓展，全面涵盖电商、物流、金融、零售、政企、游戏、文娱等领域。2017年2月，TXC2.0通过阿里云对外公测，外部改名为全局事务服务（GlobalTransactionService，简称GTS）。

GTS总体架构图

在整体架构方面，GTS由三个组件组成：客户端（GTS-Client），资源管理器（RM），事务协调器（GTS-Server）。客户端与事务协调器间，资源管理器与事务协调器间都是通过GTS分布式事务协议进行通信。客户端负责界定事务边界，开启/提交/回滚全局事务，资源管理器负责管理资源，支持的资源包括：DRDS，Oracle，MySQL，RDS，PostgreSQL，H2，MQ，后续计划根据实际业务需求支持更多类型资源。事务协调器，也就是GTS服务器，是分布式事务处理的大脑，负责协调整个事务过程。GTS事务通过RPC框架和消息中间件进行事务传递，把整个业务调用链路或者消息链路串成一个分布式事务，极大简化应用开发。

在高可用方面，GTS支持同城容灾与两地三中心容灾，可保证各种异常情况下的数据一致。在易用性方面，GTS对业务无侵入，真正做到业务与事务分离，开发者可以集中精力于业务本身。在技术创新方面，GTS也走在了行业前沿。项目负责人阿里高级技术专家姜宇（花名于皋）拥有13项分布式事务的核心技术专利，研发团队的技术专家张松树也有3篇专利。通过大量的专利技术，精妙的算法，与精巧的分布式事务私有协议，GTS取得了超强的性能。

另外，在部分严苛的行业应用场景，比如金融用户的资管项目分布式事务场景下，GTS也经历了严格的测试，按照用户要求顺利完成功能性、稳定性和性能测试。下图是一个典型性能测试场景数据，从实测数据可以看出，开启GTS（TXC）分布式事务后性能下降不明显。目前GTS已经在资金业务上有实际应用，线上大量真实数据验证了GTS的高效可靠。

GTS典型性能测试场景数据

性能优异，业务场景广泛

作为新一代企业级分布式事务服务产品，全局事务服务GTS兼顾了事务一致性，高性能与易用性。在满足事务ACID的前提下，普通配置的单服务器就可以达到15000TPS以上的超强性能（两个小时内完成1亿多笔业务），3台8核16G内存虚机组成的服务器集群可以支撑1万TPS以上的分布式事务，与同类产品相比，性能优势明显。另外简单易用对业务无侵入，为广大企业大幅降低开发成本，业务场景非常广泛：

1、跨多分库的分布式数据库事务场景：关系型数据库普遍支持事务，能够满足事务内的SQL要么全部成功、要么全部失败。但客户从单机数据库往分布式数据库迁移的情况下，原有的一个事务往往会被拆分为多个分库上的事务。由于网络的不可靠性，容易出现部分分库上成功，部分分库上失败的情况。GTS结合DRDS可彻底解决了这一问题。

2、跨多数据库的事务场景：复杂的业务系统经常会使用多个数据库，甚至多种类型的数据库，比如企业中Oracle，MySQL和其他关系型数据库并存的情况时有发生。业务同时操作多个数据库的情况下，一旦发生先提交的事务成功、后提交的事务失败，就很难解决。GTS支持各种常见关系型数据库，并提供多数据库间的事务保证。

3、跨数据库系统、消息系统的事务场景：消息系统被广泛地用于系统间解耦，一般先执行一段业务逻辑，执行成功会向消息系统发送一条消息，用于通知或触发下游业务。这个场景下，如果业务逻辑执行成功、消息发送失败，则业务不完整；如果先发送消息，但执行业务逻辑失败，同样存在问题。GTS提供了针对消息系统以及常见关系型数据库的操作入口，保证数据库操作和发送消息要么同时成功、要么同时失败。

4、跨服务的事务场景：随着业务复杂度提升，大多企业会对业务进行服务化改造。可能存在服务一操作MySQL和DRDS，服务二操作Oracle，要求两个服务操作要么同时成功、要么同时失败，否则会造成业务数据的不一致。GTS可以很方便地进行跨多个服务的分布式事务。

依托阿里中间件(Aliware)，打造世界一流企业级互联网架构平台

据GTS项目负责人姜宇介绍，“GTS作为一款高性能、高可靠、接入简单的分布式事务中间件产品，可与DRDS、RDS、Oracle、MySQL、PostgreSQL、H2等数据源，EDAS、Dubbo及多种私有RPC框架，MQ消息队列等中间件产品配合使用，可轻松实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合。策略丰富，易用性和性能兼顾，将真正完善阿里云中间件产品线。”

GTS（TXC）的研发依托于阿里中间件(Aliware)团队，中间件技术部是阿里巴巴集团生态系统的技术基石，为集团各大业务群提供可靠、高效、易扩展的技术基础服务；并在此基础上打造世界一流的中间件产品、高可用架构基础设施和企业级互联网架构平台，为全球企业和客户提供服务。

更多AliwareGTS产品服务和技术细节，请访问官网：

相关新闻

2016-04-19

2016-06-13

2016-10-24

2016-11-04

2017-12-29

2018年8月3日，成都——IBM公司(NYSE：IBM)今日在成都举办“2018IBM金融创新者大会”，汇聚了来自国内金融和银行业的200多位创新领袖，共同探讨中国金融企业所面临的商业环境变迁、全新市场挑战，以及如何凭借科技创新促进业务转型与重塑等话题。大会期间，IBM发布了银行业和金融市场《2017全球最高管理层调研报告——传统企业的逆袭》行业调研报告以及《锐意创新，驭浪前行——传统银行拉开逆袭大幕》专家洞察报告，指出了传统金融企业数字化转型所呈现出的“构建平台创新优势、充分利用数据价值、实现敏捷运营”三大趋势，以及基于本地市场的三个“行动机遇”。IBM致力于凭借其领先的技术及解决方案，助力传统银行及金融企业树立信心，拥抱变革，实现企业成功转型。

2018IBM金融创新者大会现场

近年来，在科技金融迅速发展的政策和技术动因下，中国科技金融企业已经占据全球50%以上的市场份额。如今，领先的金融机构都在围绕数字化前台、灵活的中后台、快速的产品迭代、风险控制与合规、客户洞察与生态系统来打造核心竞争力。与此同时，人工智能、机器学习、云计算、区块链等新科技也在飞速迭代，并快速融入金融服务的各个领域。

IBM大中华区金融行业总经理郭仁声

IBM大中华区金融行业总经理郭仁声表示：“从几年前面对跨界竞争、颠覆变革的转型焦虑期，到如今借助技术创新重新掌握金融服务话语权，传统银行和保险企业正在迎来前所未有的数字化重塑机遇。但要真正实现业务创新，引领市场变革，银行和金融机构必须迅速采取行动，把握转型机遇。IBM拥有长达百年的科技积累和深厚的银行金融行业经验，在全球范围内有众多最佳实践，我们正在与中国的银行、保险和金融服务企业同行同创，把握全新发展机会，实现企业数字化转型逆袭。”

IBM全球商业价值研究院联合牛津经济研究院采访了来自112个国家、20个行业的12,854位高管，其中包括银行和金融服务业的1,618名最高层主管，发布了《2017全球最高管理层调研报告之银行业和金融市场传统企业的逆袭》。报告显示，40%的银行业受访者表示，他们所在的行业正经历翻天覆地的变化，但引发变化的主体相较于两年前却已经发生了截然不同的变化——71%的受访者则将剧变归因于那些曾经臃肿不堪，但如今已自我重塑，力争在数字时代蓬勃发展的金融机构。他们开始利用自身的生态系统优势，联合供应链上下游中的企业，大胆创新。受访高管一致认为，这些行业龙头企业比新进入市场的互联网等新锐企业更具竞争力。

构建平台创新优势，推动全新业务模式

在互联网时代，跨界竞争者往往将平台作为颠覆的利器——通过平台可以将供需双方直接连接起来，通过减少中间环节来有效创造价值，这一模式在零售等行业取得了巨大的成功。银行业和金融市场的最高层主管迅速发现了这种模式的潜力，虽然目前只有8%的受访者表示自己的企业采用了平台模式，但28%的受访者正在试验这个概念，21%的高管准备为此目的重新分配资本。

一些金融科技公司和互联网公司曾凭借平台等技术手段，通过蚕食、替代或转换等方式对传统银行业产生了一定程度的冲击和影响。但金融领域的特殊性使得金融平台不能仅仅连接供需双方，更重要的是要能够持续经营、管理风险、创造价值，而银行自身的资金优势和风险管理能力是新兴的技术金融公司无法比拟的。

相比较技术构建的优势壁垒，业务构建的竞争优势持续时间会保持得更长，而一旦锐意创新的传统银行开始全方位地采用新兴技术手段，有条不紊地推进变革，它们将具备更有利的条件做好新时代的金融服务，这也是传统银行业成功逆袭的基础。

IBM大中华区全球企业咨询服务部合伙人，金融服务行业总经理陈文

充分利用数据价值，创造全新商业价值

世界上的数据只有20%可以被公开搜索到，其他80%的数据都在传统企业的手中。从数据角度看，传统银行业相比“轻资产”的互联网企业拥有显而易见的优势。如果传统银行业能够利用好自己手中的数据“金矿”，就能为自身带来前所未有的价值。

在目前中国的实体经济中，众多行业中的企业都有大量的金融方面的需求，然而很多需求是过去的传统银行所不能完全满足的，因为很多需求是传统银行不能以有效且低成本的方式进行风险判别的。今天，随着众多新兴的数字化技术的出现，数据的潜能随着传统银行业数字化重塑的进程被无限的释放出来。

人工智能、区块链、物联网和云计算等新技术的兴起，让银行可以结合多年积累的行业专业知识和经验去挖掘数据背后的洞察、去发现未被满足的客户需求;能够以低成本高效率的方式去控制金融风险并大胆尝试各类业务和技术的创新;能够更高效地把手上的数据转化为真正意义上的商业价值。

实现敏捷运营，重塑基础架构、流程和文化

参与调研的企业高管指出影响企业成功的三个重要因素即率先尝试的新意愿、对高素质员工的支持，以及敏捷运营，这些领先企业通过重新设计基础架构、运营模式和组织文化，以快速响应市场变化。

首先，银行传统的IT基础架构框架是一维的，即业务功能以线性方式实现，这种架构常常导致跨渠道客户体验不一致，交易服务分散，功能重复和前后端数据分离。而未来的IT架构框架应当是多维的，能够跨出企业界限快速开发新服务，可扩展并能实时获取数据用于当前甚至未来的客户交互，并且通过集成实时响应洞察需求。

其次，银行面临的竞争不是部门级的竞争，而是企业级的竞争，因此建立从战略到流程再到应用的一整套企业级的、统一的标准规范至关重要。企业级标准不再以组织的边界划分，而是要打破部门或条线的竖井式流程，通过提取业务的变量，比如客户、产品、渠道和合作方等，形成整合的企业级流程，实现标准化。银行通过构建更高灵活度的业务流程，可以实现更高的业务敏捷性和灵活性。

此外，银行在转型中一定要解决文化转型的问题，IBM最高管理层调研发现，领先的企业往往非常重视对文化的变革，有70%的领先企业认为自己的企业已经建立了开放的企业文化，并且实现了敏捷运营。80%的银行业和金融市场重塑者已经开始主动征询员工的意见，开辟新的发展途径。

IBM大中华区金融行业总经理郭仁声指出，基于服务传统银行和金融行业多年的深厚行业积累，IBM认为广大银行和金融企业在数字化转型过程中，如果要实现成功逆袭，需要掌握三个行动机遇，即构建生态环境，拥抱平台金融;运用智能自动化高效、合规运营;建设安全云平台，打造数字化基础。

如今，传统银行及金融企业致力于创新并已经拉开逆袭大幕。通过平台化塑造、数据挖掘以及敏捷运营，传统银行及金融企业能够快速实现转型。然而，这些则依赖于现有科技能力的持续释放及高精尖的数字技术对现有信息科技系统的赋能。IBM则正是这些企业最坚实和有力的合作伙伴，通过领先的技术及解决方案，助力传统企业拥抱变革的浪潮，树立行业信心，并最终实现企业转型及业务重塑。

对于构建平台，IBM可以帮助银行及金融企业通过虚拟化将现有集中式基础架构中的单体应用转型到分布式基础架构;通过对业务流程、数据的梳理和建模，将单体应用解耦为分布式应用架构;通过微服务化或应用容器化，将分布式应用真正转型为以业务服务为基础的SOA架构;并通过构建开发、运维一体化，重构银行开发、测试、发布流程，使业务投放时间大大缩短，加快应用迭代。

不仅如此，IBM还将以其强有力的技术能力，将AI赋能到现有的科技体系中。包括，通过机器学习，找到高价值客户，在最适当的时机推荐最适合的产品;通过大数据分析，发现客户的异常行为，实时发现网络攻击，在事中自动启动防御措施;通过语音识别和文字理解，降低人工客户强度，提高人工客服质量;通过图像识别技术，实现票据自动分类，识别柜员和客户行为，提高业务效果，降低运行风险;通过自动化技术，把业务流程串接起来，减少人工环节，把人从简单重复的劳动中解放出来。

在协同创新方面，IBM通过更加开放的社区、黑客松及设计思维方式，与企业联手持续化地转型企业职工的技能，建立企业的创新文化和能力。IBM在区块链技术上的研发能力，能够极大增强交易环境的可信度，降低陌生交易对手的交易成本;IBMWatson技术可以把银行后台的整合能力拓展到上下游，创新合作模式，形成前所未见的“产品”;IBM的物联网技术，可视化技术(AR/VR)，将促使网点进一步数字化转型，促进金融与生活进一步接合，让金融服务无所不在。

物联网市场的应用场景日益复杂，越来越多的上网设备需要支持更多的硬件资源、操作系统、软件工具及应用程序，现有的解决方案显然无法为数量庞大的物联网设备提供相应的灵活性，这使开发者们面临巨大的设计压力。虚拟化技术是解决这些问题的关键。不过，现有的虚拟化解决方案并不能满足物联网开发的轻量级和灵活性的特殊要求。为了满足当前物联网市场的发展趋势，Linux基金会推出了开源项目---ACRN，

ACRN到底具有哪些强大的功能,它又是怎么实现的？今天我们就从架构到应用对ACRN进行详细分析，让开发者们快速上手使用ACRN进行产品设计。

ACRN是一个专为嵌入式设备设计的hypervisor，包括如下两部分：一套hypervisor的参考软件和架构，通过虚拟机监视器（VirtualMachineManager）可以在同一个物理硬件上安全地同时运行多个操作系统。另外，它还为设备虚拟化模拟定义了一套参考设计框架，称为“ACRN设备模型”。

ACRNhypervisor是一个Type-I的hypervisor，可以直接运行在物理硬件上，适用于各种物联网和嵌入式设备解决方案。ACRNhypervisor解决了当前数据中心hypervisor和partitioninghypervisor之间存在的差距。ACRNhypervisor设计时把系统分为不同的功能域，并为物联网和嵌入式设备精心挑选的用户操作系统进行共享优化。

汽车应用案例

ACRNhypervisor的一个有趣的案例是用于汽车场景。ACRNhypervisor可以用于构建软件定义驾驶舱（SDC）或者车载娱乐系统（IVE）。作为参考实现，ACRN可以为嵌入式hypervisor厂商的解决方案提供一个很好的基础，以及一套I/O设备虚拟化的参考设计。

在这种场景下，汽车SDC系统由仪表盘（IC）系统、车载信息娱乐系统（IVI）和一个或多个后座娱乐系统（RSE）组成。为了整体系统安全性考虑，每个系统都作为独立的虚拟机运行。

仪表盘系统（IC）用于显示和驾驶员相关的车辆的驾驶操作信息，如：

•汽车的速度、燃油、行驶里程和其它驾驶信息；

•投影在挡风玻璃上的抬头显示，用以警告缺油或胎压报警；

•显示后视摄像头影像和车身的周边摄像头信息，用于辅助停车；

车载娱乐系统（IVI）的功能包括：

•导航系统、收音机和其它娱乐系统；

•连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；

•通过手势识别或触控进行交互；

后座娱乐系统（RSE）可以运行：

•娱乐系统；

•虚拟办公；

•连接到前排座椅的IVI系统和移动设备（云连接）；

•连接到移动设备，可以打电话，播放音乐或者通过语音识别来控制应用程序；

•通过手势识别或触控进行交互；

ACRNhypervisor可以支持Linux*和Android*虚拟机作为用户操作系统（UOS），UOS由ACRNhypervisor进行管理。开发者和OEM厂商可以在ACRNhypervisor之上运行自己的虚拟机，以及IC、IVI和RSEVM。ServiceOS是作为VM0运行（在Xen*hypervisor中被称为Dom0，在KVM*hypervisor中被称为HostOS），UserOS用户操作系统作为VM1运行（也被称为DomU）。

注：Android*虚拟机的支持将在未来版本发布。

图1显示了一个使用ACRNhypervisor的实例框图。

图1：SOS和UOS运行在ACRNhypervisor之上

从ACRNhypervisor的架构图中可以看到：

•ACRNhypervisor直接位于bootloader之上，因而具备快速启动的能力；

•部分资源进行partitioning，以确保安全关键性应用和非安全关键业务可以共存在同一平台上；

•丰富的I/O设备虚拟化提供在多个VM之间的I/O设备共享，从而提供全面的用户体验；

•通过高效的虚拟化，一个SoC可以支持多个操作系统同时运行；

图1中的黄色部分是ACRN项目的软件栈。该架构框图中列出的某些功能还没有完全实现，欢迎社区共同参与开发实现。另外，图中的其他模块来自于别的开源项目，这里仅供参考。

例如，ServiceOS和GuestLinux来源于https://clearlinux.org上的ClearLinux项目，而未来GuestAndroid的支持将会来自https://01.org/android-ia项目。

当前ACRN所支持的功能列表，请参照发布说明。

许可证

ACRNhypervisor和ACRNDeviceModel软件采用的都是自由许可证的BSD-3-Clause，它允许以“源代码和二进制再次发布和使用，无论是否进行了修改”，许可证中也注明了完整版权声明和免责声明。

ACRNDeviceModel,ServiceOS,andUserOS

为了使ACRNhypervisor代码尽可能精悍且高效，用于实现I/O设备共享的devicemodel代码运行在ServiceOS中而非ACRNHypervisor。哪些I/O设备被共享以及其实现细节将在下面的pass-through章节具体介绍。

ServiceOS在所有虚拟机里，以最高优先权运行，以满足那些对时间响应要求很高的需求和系统服务质量的需求（QoS）。具体到ServiceOS中的任务（task），他们的优先级则有高有低。例如响应UserOS请求的回调函数，其运行在ServiceOS的软件（或者mediator）就会继承UserOS的优先级。另外，在ServiceOS中还有一些在后台运行的任务也是低优先级。

在上述的车载系统示例中，UserOS是驾驶控制和车内娱乐的中心枢纽。它能提供收音机和各种娱乐选项、车内空调和通风控制、车辆导航显示等支持。它可以让第三方设备使用USB、蓝牙或者WiFi等连接技术与车载系统进行交互，例如：AndroidAuto* 或者 AppleCarPlay*, 还能提供许多其它功能。

启动步骤

在图2中，我们展示了在一个采用英特尔架构平台的NUC上使用UEFI验证启动的步骤。

Figure2ACRNHypervisorBootFlow

启动引导顺序执行如下：

1UEFI验证和启动ACRNhypervisor和ServiceOS的引导加载程序；

2UFEI（或ServiceOS的引导加载程序）验证并启动ServiceOS内核；

3ServiceOS的内核通过dm-verity验证并且加载ACRNDeviceModel和虚拟引导加载程序；

4 虚拟引导加载程序启动用户端的验证启动进程；

ACRNHypervisor架构

ACRNhypervisor是Type1的虚拟机管理程序，能够直接运行在硬件系统上。它是一个混合的VMM架构，采用一个运行在特权级的ServiceOS来管理和协调I/O设备的使用。它能支持多个用户虚拟机，其中每个虚拟机都可以运行Linux或者安卓操作系统作为用户操作系统。

在虚拟机内运行的操作系统是与其它虚拟机内的系统或应用程序相互隔离的，从而缩小了潜在的被攻击可能性，最大限度地减小安全隐患。当然由于系统运行在虚拟机内也可能会给其应用程序的运行带来额外的延迟。

图3显示了ACRNhypervisor、车载系统中的InstrumentalCluster(IC)VM和ServiceVM一起协同工作的架构图。ServiceOS（SOS）负责包括平台设备在内的大部分设备的管理，并提供I/O的协调功能。某些PCIe设备可以通过VM配置直通给UserOS使用。IC应用程序和虚拟机特定的应用程序都运行在SOS中，例如：ACRNdevicemodel和ACRNVM管理器。

ACRNhypervisor内还有ACRN虚机管理器，用来收集UserOS的运行信息，并控制用户虚拟机的开始、停止和暂停，还能暂停或者恢复执行单个虚拟CPU。

图3ACRNHypervisor 架构图

ACRNhypervisor采用了英特尔虚拟化技术（IntelVT），其运行在虚拟机扩展模式（VMX）的root模式下，也称为主机模式或VMM模式。其他所有的用户虚拟机包括UOS和SOS都运行在VMXnon-root模式或guest模式下。（以下为了简略，我们将继续使用术语VMM模式和guest模式）。

VMM模式下有4种权限的ring模式，但ACRNhypervisor仅在ring0的特权模式下运行，其余ring1-3并未使用。运行在guest模式下的用户系统（包括SOS和UOS）也有自己的4个ring模式（ring0-3）。用户系统的内核运行在guest模式下的ring0，而用户系统的应用程序则在guest模式下运行于ring3（ring1和ring2一般不被商业操作系统所使用）。

图4VMX 简介 

如图4所示，VMM模式和guest模式通过VMExit和VMEntry进行切换。当引导加载程序将控制权交给ACRNhypervisor时，处理器还未启动VMX模式。ACRNhypervisor首先需要通过VMXON指令启用VMX模式。启用VMX后，处理器处于VMM模式，它可以通过VMresume指令进入guest模式(或者通过第一次VMlaunch指令)，然后可以通过处理器的VMexit事件回到VMM模式。一般处理器会在响应某些指令和事件时发生VMexit。

在guest模式下，处理器的执行是由一个虚拟机控制结构（VMCS）所控制的。VMCS包含了虚机状态（在VMEntry时加载并在VMExit时保存），主机状态（在VMexit时加载），以及虚机的控制执行。ACRNhypervisor为每个虚拟CPU创建了一个VMCS数据结构，并使用该VMCS来控制运行在guest模式下处理器的行为。

当虚机执行到一个敏感指令时，就会触发一次定义在VMCS配置中的VMexit事件。当VMexit发生后，系统的控制权就交给了ACRNhypervisor。ACRNhypervisor会模拟虚机的指令（如果VMexit的原因是由于指令权限问题），然后恢复虚机继续执行它的下一条指令，或者根据VMexit的原因进行相关处理（例如，一个虚机的存储页面需要建立映射关系），然后恢复虚机重新执行该条指令。

需要注意的是用于VMM模式的地址空间和用于guest模式的地址空间是不同的。guest模式和VMM模式下使用不同的内存映射表，因此虚机是无法访问ACRNhypervisor的。ACRNhypervisor使用EPT来映射虚机地址，虚机页表会将虚机的线性地址映射到虚机的物理地址， EPT表则将虚机的物理地址映射到机器物理地址或主机物理地址（HPA）。

ACRNDeviceModelArchitecture

因为系统设备可能需要在不同的虚机之间被共享，虚机内应用程序（和操作系统）要对这些共享设备进行访问就需要借助设备模拟。一般来说，设备模拟有三种架构：

·第一种架构被称为hypervisor中的设备模拟，这是在VMware*工作站产品（一个基于操作系统的hypervisor）中实现的设备模拟方式。在这种方式中，hypervisor负责模拟需要在各个虚机操作系统之间共享的常见设备，其中包括：虚拟磁盘、虚拟网络适配器和其它必要的平台资源。

·第二种架构称为用户空间的设备模拟。顾名思义，不是将设备模拟的实现嵌入到hypervisor中，而是将其放在一个用户空间的应用程序中实现。比如被各种独立的hypervisor所使用的QEMU就提供了此类的设备模拟方式。这种架构的优势在于设备模拟的实现不依赖于hypervisor，所以其它hypervisor可以重用改实现。甚至它还可以做任意设备的模拟，而不必担心其功能的实现会影响hypervisor（其在特权模式下运行）。

·第三种架构则是从基于hypervisor的设备模拟改变而来的半虚拟化驱动程序。该架构一开始是在XEN项目中引入的，其中hypervisor提供物理设备驱动，每个虚机操作系统则需要安装一个与能与物理驱动配合使用的hypervisor感知的驱动程序。

在以上讨论的设备模拟架构中，共享设备都需要付出代价。因为不管设备模拟是在hypervisor中，还是在每个虚机内的用户空间中，都存在相应的系统开销。不过只要系统设备需要被多个虚机操作系统共享，这种开销就是值得的。反之如果设备不需要被共享，那么就可以使用更有效的方法来访问设备，例如使用“直通”。

看完以上的分析，你是否对ACRN有了更深入的了解？也是否有更多问题急需解答？不用着急，我们将在下期中继续讲解各种技术细节，例如ACRN设备模块架构、设备passthrough， ACRNI/Omediator,Virtio框架结构等一一为你展示。

随着互联网的发展，越来越多的业务不仅仅由单一节点（或是单一语言）就可承载，而是趋向多语言分布式协同开发（如接入层由Node.js完成，逻辑（数据）层由C++/GO/Python实现）并由此组成大型异构系统。

我们（现SuperTeam）基于 Tars 体系研发出 Tars.js 以便用户在不改变异构系统整体架构的情况下快速搭建（迁移）Node.js服务，并可非常方便的将原来的单一服务拆分为多个（逻辑）子服务。

Tars.js在腾讯内部经过5年多的沉淀与迭代（Node.js@0.10版本即提供支持），广泛运用于腾讯QQ浏览器、腾讯桌面浏览器、腾讯地图、应用宝、腾讯手机管家、互联网+、腾讯医疗、腾讯觅影、保险、彩票等几十个重要业务中，日承担了上百亿流量。

Tars.js包含下述特性：

l 100%由JavaScript编写，不包含任何C/C++代码。

l 多进程负载均衡与管理。

l 代码异常监控与重启。

l 服务日志搜集与处理。

l HTTP(s)服务监控与用量自动上报，并支持用户自定义维度上报（PP监控）。

l 符合 Tars(IDL)规范的编解码模块。

l 支持 TarsRPC调用与染色（模调自动上报）。

l 支持在线发送管理命令、拉取服务配置。

l 独创 LongStackTrace™异常跟踪机制。

l …… 更多特性可访问 @tars/node-agent 了解

设计理念：

»A．高自由度：

l 兼容所有（≥0.10）官方Node.js版本。

l 对 Node.js源码无侵入无修改。

l 底层对上层完全透明，支持各种上层框架，无需变更。

也就是说：

您可以使用任何您熟悉的框架（如 Express.js/Koa.js等，包括但不仅限于Web框架），也无需对框架进行任何修改（无需引入任何中间件）。即可通过Tars.js运行，享受平台提供的各种监控与管理特性。

与此同时，Tars.js所提供的模块，也可以根据您的需求引入（如未使用到则可不引入）。

»B．高性能：

Tars.js为高性能与大并发量而设计，使用了大量的前端（V8）优化技巧（如FlattenString/FastProperties等）尽量降低所提供的能力对于业务性能的影响。

经过我们测试（WebServer），默认的旁路上报与监控对服务性能的影响≤5%，常用模块（RPC、日志等）性能位于业界前列。

»C．差异化：

Tars.js根据不同的业务类型提供差异化运营方案：

l 高流量业务：尽力降低框架对业务性能的影响。

l 低流量业务：充分利用硬件资源提升开发体验。

HelloWorld

我们来看Node.js官网的 例子 (如下)，无需任何变更，直接通过Tars.js进行部署，它会拥有哪些特性？

✓ 进程管理

默认基于 cluster 模块进行负载均衡，进程数可以配置为1~max（CPU核心数）、还可配置为auto（物理核心数相同）以减小内存压力提升“性价比”。

与此同时，进程僵死检测也会同时启动，实时监控业务进程。

»案例说明

某服务在论坛UBB代码转HTML时，使用未优化的正则表达式进行XSS攻击过滤，但由于用户发帖时图片采用BASE64编码，导致正则表达式计算时间过长，CPU使用率飙涨到100%：

开启僵死检测后，Tars.js监控到业务进程僵死时，自动重启业务进程，从而缩短了业务无响应时间：

Tars.js虽然无法解决业务代码的问题（BUG），但会尽最大努力保证业务的可用性。

✓ 服务监控

以服务名、接口名（URL-PATH节）为纬度，统计总流量、平均耗时、超时率、异常率：

其中返回码大于400（可配置）作为异常进行上报。

»监控说明

Web服务一般由静态与动态资源（接口）组成，由于静态资源（本地文件）的请求耗时远低于动态资源（业务逻辑），请求量往往又很高，拉低了服务整体耗时。

基于此，Tars.js将请求URL中的PATH节作为接口，每个接口均可查看其总流量、平均耗时、异常率，便于用户全面了解服务性能。

✓ 特性监控

无论您服务的类型是什么，总是会上报下述特性，便于回溯问题与评估性能：

l memUsage：内存用量，将会上报rss、heapUsed、heapTotal这三个用量（单位为字节）

l cpuUsage：CPU用量，将会上报CPU使用率，数据汇总为逻辑单核（单位为百分比）

l eventloopLag：（任务）队列延迟，每隔2秒采样（单位为毫秒）

l libuv：I/O用量，将会上报activeHandles、activeRequests这两个用量

各策略以平均值（Avg）、最大值（Max）、最小值（Min）分节点进行统计：

✓ 日志输出

所有通过Console模块（如console.log）输出的日志，都会输出到服务本地文件内。并附加相关信息（如下），方便定位问题。

日志格式：日期时间|进程PID|日志级别|输出文件名与行号|日志内容

2018-07-0112:00:00|332|DEBUG|app.js:13|Serverrunningathttp://127.0.0.1:3000/

✓ LongStackTrace™

由于Node.js采用异步机制，在发生异常时堆栈不完整，导致定位问题复杂。

鉴于此，我们提供了长链路跟踪技术在产生异常时自动附加前序调用堆栈，同时还支持在异常堆栈中过滤出用户代码部分。

由于开启此特性时会造成性能损耗，故默认关闭，管理平台等性能不敏感业务可直接通过配置开启。

»案例说明

执行上述代码会抛出下述异常：

ReferenceError:ThisMayThrowErrorisnotdefined

atTimeout.setTimeoutas_onTimeout

at_disibledevent="http://superzheng.com/">@SuperZheng 创立于2017年。团队成员均为全栈架构师（Super寓意Superman——无所不能），熟知Web(3D)、终端、后端与大数据计算，并由传统前端向互联网从业者方向发展。欢迎前端牛人加入，共创前端美好未来。