✌ 作者简介：小明的Java问道之路，某大型金融互联网公司，后端研发高级工程师，擅长订单/交易领域的高安全/可用/并发/性能的架构设计与落地，专注于研究计算机底层与金融科技领域技术🏆 CSDN博客专家/Java领域新星创作者、系统架构设计师🔥 如果此文还不错的话，还请关注、点赞、收藏三连支持一下博主本文导读：学习汇编语言的目的就是通过汇编语言进行深入地理解计算机底层的基本工作机理，达到可以随心所欲地控制计算机的目的。学习汇编语言的目的就是通过汇编语言进行深入地理解计算机底层的基本工作机理，达到可以随心所欲地控制计算机的目的。一、汇编语言、机器语言与冯诺依曼体系结构机器语言，就是0100110的二进制串汇编语言，用来于硬件沟通，是英文代码冯诺依曼体系结构：1、运算器：运算单元，保存临时数据2、控制器：控制单元3、输入输出4、存储器：寄存器组，用来保存指令和数据（为了加快运行速度）。寄存器按功能命名EAX: Accumulator for operands and results data 操作数和结果数据累加器EBX: Pointer to data in the DS segment 指向DS段中数据的指针ECX: Counter for string and loop operations字符串和循环操作的计数器EDX: I/O pointer I0指针ESI: Pointer to data in the segment pointed to by the DS register; source pointer for string operations 指向DS寄存器所指向段中数据的指针，，字符串操作原指针EDI: Pointer to data (or destination) in the segment pointed to by the ES register; destination pointer for string operations 指向ES寄存器所指向段中数据的指针，字符串操作目标指针ESP: Stack pointer (in the SS segment) 栈指针( SS段中)EBP: Pointer to data on the stack (in the SS segment) 指向栈上数据的指针( SS段中)在计算机初创时代，涉及到一个问题？基础存储单元多少位最合适？8位，所以在8086时代，一个通用寄存器占16位, 8080时代是8位。 为了兼容8080，16可以拆位两个8位，同理32位可以拆违两个16位。ax(al低8位ah高8位) e(extra)ax (高16位低16位) rax=16 32 64，数据是从高到低还是低到高引入了字节序。二、汇编语言相关硬件结构汇编语言是直接在硬件之上工作的编程语言，首先要了解硬件系统的结构，才能有效的应用汇编语言对其编程。在本节中，对硬件系统结构的问题进行探讨存储器：CPU是计算机的核心部件，它控制整个计算机的运作并进行运算，要想让一个CPU 工作，就必须向它提供指令和数据。指令和数据在存储器中存放，也就是平时所说的内存。磁盘不同于内存，磁盘上的数据或程序如果不读到内存中，就无法被CPU使用。存储器相当于语言中的数组，下标从0开始，每一个元素为1字节;寄存器：简单的讲是CPU中可以存储数据的器件，一个CPU中有多个寄存器。CPU对存储器的读写：CPU要想进行数据的读写，必须和外部器件(标准的说法是芯片)进行三类信息的交互：一、我要干啥：读还是写命令(控制信息)；二、我要的东西在哪：地址总线，存储单元的地址(地址信息)；三、我的东西要放哪：数据总线，读或写的数据(数据信息)那么CPU是通过什么将地址、数据和控制信息传到存储芯片中的呢？电子计算机能处理、传输的信息都是电信号，电信号要用导线传送。在计算机中专门有连接CPU和其他芯片的导线，通常称为总线，物理上是一根根导线的集合，逻辑上分为地址总线、数据总线、控制总线内存地址空间：一个CPU的地址线宽为10，那么可以寻址1024个内存单元，这1024个内存单元就构成CPU的内存地址空间。CPU对存储器进行读写的时候都通过控制总线发出读写命令。对CPU来讲，系统中的所有存储器中的存储单元都处于一个统一的逻辑存储器中，它的容量受CPU寻址能力的限制。这个逻辑存储器即是我们所说的内存地址空间。主板：PC机有一块主板，主板有核心器件和主要器件，这些器件通过总线（地址总线、数据总线、控制总线）相连三、CPU工作原理（寄存器）CPU概述：一个类型的CPU由运算器、控制器、寄存器等器件组成，这些器件靠内部总线连接，内部总线实现CPU内部各个器件之间的联系。外部总线实现CPU和主板上其它器件的联系。寄存器概述：8086CPU所有的寄存器都是16位的，可以存放两个字节。8086CPU有14个寄存器，AX、BX、CX、DX、SI、DI、SP、BP、IP、CS、SS、DS、ES、PSWCS和IP是8086CPU中最关键的寄存器，他们知识了CPU当前要读取指令的地址CS：代码段寄存器（存放段地址，一个段寄存器16位、一个PC计数器是16位），IP代码段+IP偏移=指令地址IP：指令指针寄存器（存放指针的偏移地址）AX、BX、CX、 DX通常用来存放一般性数据被称为通用寄存器。DS：寄存器，通常用来存放要访问的数据的段地址。SS、 SP指示栈顶：改变SP后写内存的入栈指令；读内存后改变SP的出栈指令。SI和DI是8086CPU中和bx功能相近的寄存器，SI和DI不能够分成两个8位寄存器来使用。8086PC工作过程1、从CS:IP指向内存单元读取指令，读取的指令进入指令缓冲器；2、IP= IP +所读取指令的长度，从而指向下一条指令;3、执行指令，跳转1并重复四、一些简单地汇编指令mov指令的几种形式:mov 寄存器，数据mov 寄存器，寄存器mov 寄存器，内存单元mov 内存单元，寄存器mov 段寄存器;寄存器push寄存器:将一个寄存器中的数据入栈pop寄存器:出栈，用一个寄存器接收出栈的数据

在2020年云栖大会上，阿里云CEO行颠从口袋里拿出了卡片式云电脑终端 ASC01，并发布了阿里云的无影云桌面。在之前的文章中我曾经分三期对无影云桌面进行了体验，这次我们终于拿到了这个ASC01。印有阿里云logo的一面是ASC01的背面，貌似还有一个唯一的设备身份标识。正面带有一个指纹识别模块，设备的整体质感非常好，让人忍不住拿在手里持续把玩。顶部和侧面各有一个USB口，其中顶部的规格USB3.2，主要用于连接显示器，侧面的规格为USB2.0，可用于辅助供电。有两种使用ASC01的方式，一种是用顶部的USB口连接带有USB 供电及HUB的显示器，通过显示器供电来驱动ASC01工作，并连接鼠标、键盘等外设。另一种方式是使用一个带有供电功能的USB HUB连接ASC01和显示器，我用的是后一种方式：上图中右下角是一根PD供电线，中间是一根HDMI数据线用于连接显示器，最远端的是一个键盘。此外，我还放了一个带有5G功能的iPad来提供互联网访问，这样可以避免手机热点在我走开或者接打电话时的桌面断联问题，显示器和无影云终端的供电我用一个充电宝来搞定。在这一套组合中，假如要评选一个ASC01的最佳CP，我觉得非HHKB莫属了。原因是ASC01虽然也支持蓝牙键盘，但蓝牙键盘有延迟、干扰、安全性方面的问题，因此我更倾向于使用有线键盘，但我分别尝试了nuphy、keychron、HHBK的三把有线键盘，只有这把HHKB能够正常使用，我猜测可能是nuhpy、keychron都是有线/无线切换的多模键盘，使用的控制芯片太新，ASC01无法正常驱动，而只有这把HHKB是纯有线键盘。而且，HHKB带有一个USB HUB可以连接鼠标、U盘、甚至是打印机，这里我就用ASC01进行了一次“云打印”。在ASC01初始化的过程中，蓝牙是默认关闭状态，因此一个带有dongle的无线鼠标或者有线鼠标是开启一切的关键，否则你无法使用ASC01连接任何其他设备。假如不了解HHKB，让我来科普一下：这把HHKB被称为程序猿的神器，像GNU 之父 Richard Stallman、C++ 之父 Bjarne Stroustrup 都是它的用户。上图是Richard Stallman和他的HHKB。Bjarne Stroustrup 的HHKB。为了致敬这些大神，让我们用ASC01运行一个Linux 桌面来结束这次分享吧。

麻烦大家帮我投一票哈，谢谢经常听到 Java 性能不如 C/C++ 的言论，也经常听说 Java 程序需要预热，那么其中主要原因是啥呢？面试的时候谈到 JVM，也有很多面试官喜欢问，为啥 Java 程序越执行越快呢？一般人都能回答上来，类加载，缓存预热等等，但是深入下去，最重要的几点却没有答上来，今天本系列文章就来帮助大家理解这个问题的关键，首先是 jit 编译优化。首先，我们从一个简单的例子看起，来感受下程序是否越来越快：package com.test; import java.util.concurrent.TimeUnit; public class CompileTest { public static void main(String[] args) throws InterruptedException { while (true) { test1(); TimeUnit.SECONDS.sleep(1); } } public static void test1() { long time1 = System.nanoTime(); long count1 = 0; for (int i = 0; i < 10000; i++) { count1++; } //为了和编译日志区分，这里输出到error输出 System.err.println(System.nanoTime() - time1 + "-----" + count1); } }运行时，加上参数-XX:+PrintCompilation，打印一下编译日志（其实这个参数以后也许就过期了，建议使用 JVM 标准日志参数：-Xlog:jit+compilation=info），可以看到：432900-----10000 250800-----10000 194600-----10000 197200-----10000 131600-----10000 184000-----10000 6369 374 % 3 com.test.CompileTest::test1 @ 9 (61 bytes) 162300-----10000 7369 375 3 com.test.CompileTest::test1 (61 bytes) 68300-----10000 60300-----10000 47200-----10000 48100-----10000 11371 378 % 4 com.test.CompileTest::test1 @ 9 (61 bytes) 55600-----10000 11388 374 % 3 com.test.CompileTest::test1 @ 9 (61 bytes) made not entrant 12372 379 4 com.test.CompileTest::test1 (61 bytes) 157600-----10000 12389 375 3 com.test.CompileTest::test1 (61 bytes) made not entrant 600-----10000 700-----10000 600-----10000 1200-----10000 900-----10000 900-----10000从输出中可以看出，貌似JVM对test1这段代码做了一些事情，使方法运行越来越快了。这就是JIT做的优化，随着代码的执行，热点代码会被优化，让执行更加迅速。这也是为什么，通过一般方法（javac命令）编译出来java class文件在执行的时候，要预热之后，才能发挥最大性能。接下来，我们来详细介绍下JIT。OpenJDK Hotspot JVM，是最广泛运用的Java JVM。主要包含两部分，执行引擎（execution engine）和运行时（runtime）。执行引擎包括两部分，一个是垃圾收集器，另一个就是我们今天的主题， JIT（just-in-time）编译器。什么是JITJVM是Java一次编译，跨平台执行的基础。当java被编译为字节码形式的class文件之后，他可以在任意的JVM运行。这里说的编译，主要是指前端编译器。Java中主要有两种编译器：前端编译器，将.java文件编译为JVM可执行的.class字节码文件，即javac，主要职责包括：词法、语法分析，填充符号表，语义分析，字节码生成。输出为字节码文件，也可以理解为是中间表达形式（称为IR：Intermediate Representation）。对应上面的例子就是将CompileTest.java编译成符合Java规范的字节码文件CompileTest.class后端编译器，在程序运行期间将字节码转变成机器码，通过解释器和运行时编译器混合模式（现在的 Java 程序在运行时基本都是解释执行加编译执行），如 HotSpot 虚拟机自带的解释器还有 JIT（Just In Time Compiler）编译器（分 Client 端和 Server 端），其中JIT还会将中间表达形式进行一些优化。对应上面的例子就是test1方法执行越来越快。Java 9中还引入了实验编译器AOT（Ahead-Of-Time）编译器，直接生成机器码。主要用于减少JAVA启动预热时间，比较适用于单次执行时间有限需要高效执行的程序，或者是小集成芯片环境，对效率要求比较高。AOT与Graal我们会在系列的最后着重介绍。对应上面的例子就是，test1方法不用预热就会执行的和上面最会一样那么快。但是相应的，机器码占用的大小比字节码大的多得多，而且不能跨平台。为什么要这么区分呢？首先，不同机器的机器码是不一样的，编译生成统一的字节码保证了跨平台应用的可能性。然后，将字节码优化（中间表达形式优化）放到运行时优化，这样低版本的java编译出来的字节码，在高版本的JVM运行，仍能享受高版本的JVM新的优化机制带来的性能提升，这是一种很好的向后兼容机制。所以有的时候，我们可以先把JVM升级到新版本来享受更高效的优化算法。刚刚提到了JVM使用混合模式来从字节码转换成机器可以运行的机器码，混合模式包括解释器和JIT：解释器工作机制：在编译时，主要是将java源代码文件编译为java统一的字节码，但是编译成的字节码并不能直接运行，而是通过JVM读取运行。JVM中的解释器就是将.class文件一行一行翻译之后再运行，翻译就是转换成当前机器可以运行的机器码，它不会一次性把整个文件都翻译过来，而是翻译一句，执行一句，再翻译，再执行，所以解释器的程序运行起来会比较慢，每次都要解释之后再执行。所以，有些时候，我们想是否可以把解释之后的内容缓存起来，这样不就可以直接运行了？但是，如果每段代码都要缓存起来，例如仅仅执行一次的代码也缓存起来，这样太浪费内存了。所以，引入一个新的运行时编译器，JIT来解决这些问题，加速热点代码的执行。JIT运行时编译器工作机制：JIT针对热点代码，进行编译与深度优化，优化后的机器码会被缓存起来，存入CodeCache中。对于非热点代码，例如只运行一次的代码（类构造器等等），直接解释执行，更加快速。JIT不仅花更多时间去编译优化，而且还多耗费了很多内存，并且 CodeCache 发生变化会发生部分或者所有线程进入 Safepoint 导致 Stop the world。字节码转换为可执行的机器码，大小会大很多很多倍。这也是为啥，解释器每次都要翻译并且执行，JIT只针对热点代码进行编译优化的原因。JIT编译器执行的一些常见优化操作包括数据分析，从堆栈操作到寄存器操作的转换，通过寄存器分配减少内存访问，消除常见子表达式等。JIT编译器进行的优化程度越高，在执行阶段花费的时间越多。因此，JIT编译器无法承担所有静态编译器所做的优化，这不仅是因为增加了执行时间的开销，而且还因为它只对程序进行了限制。这也就解释了为什么有些JVM会选择不总是做JIT编译，而是选择用解释器+JIT编译器的混合执行引擎。对于上面的例子，刚开始的时候，test1方法是解释器执行的，由于多了一步转换，所以比较慢。后面随着代码的运行和JIT优化，test1方法的机器码被优化并且存入代码缓存，下次执行直接从代码缓存读取执行。JIT的基本工作原理首先，需要判断一个方法是否是热点方法：在HotSpot虚拟机中使用的基于计数器的热点探测方法，他为每个方法都准备了两个计数器：方法调用计数器和loop-back-edge计数器。方法调用计数器：顾名思义，这个计数器用于统计方法被调用的次数。在一个方法被调用时，根据前面所述，会先看看是否存在与codecache中，也就是jit编译的版本，如果不存在，则将计数加一，判断是否大于阈值，如果大于，则那么将会向即时编译器提交一个该方法的代码编译请求。如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进行解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。loop-back-edge计数器：专用来统计loop次数的，就是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为loop-back-edge。这个计数器机制与上面的方法调用计数器一致。有了这些计数器，JIT可以根据这些计数器里面的统计信息，进行优化。当然，不止有这些计数器，还有一些其他更复杂的采集点。JIT编译器在JDK 8之前，例如JDK 7是区分client模式（C1编译器）还是server模式（C2编译器）的，从JDK 8开始，不做这个区分了，都是C1+C2编译器合作，分层优化。C1是一个简单快速的编译器，主要关注点在于局部优化，而放弃许多耗时较长的全局优化手段。C2则是专门面向服务器端的，并为服务端的性能配置特别调整过的编译器，是一个充分优化过的高级编译器。从Java 8开始，JIT编译优化是分层优化，分为5层，每层都会有C1或者C2参与。第0层（Tier-0），只有解释器参与，解释执行第1层（Tier-1），执行不带任何采集的的C1优化代码第2层（Tier-2），执行仅带方法调用计数器和loop-back-edge计数器profiling的C1优化代码第3层（Tier-3），执行带所有采集的的C1优化代码第4层（Tier-4），执行C2优化代码

近日，‍北京钛星数安科技有限公司(以下简称“钛星数安”)签署了 CLA（Contributor License Agreement，贡献者许可协议），正式加入龙蜥社区（OpenAnolis）。​钛星数安是一家云安全厂家，通过多年的技术积累和沉淀，基于“远程浏览器技术”，自主研发了互联网威胁隔离云安全平台，基于 SaaS 模式为关键信息基础设施领域提供实时防御，阻断黑客利用浏览器漏洞等各种高级攻击手段对网站服务器、核心业务应用服务器、电子邮件系统和办公终端发起的恶意攻击，从而保障业务的连续性，革新了目前威胁情报策略产品“滞后”防御的特性，开创了实时“预防”恶意攻击的新道路。目前，其产品和服务已应用于政务、运营商、金融、能源、教育、工业、医卫、交通、媒体等行业，并且得到了行业客户极高的肯定和评价。钛星数安CEO汤湘祁先生表示：“未来，钛星数安将积极参与龙蜥社区合作，为开源的操作系统贡献技术力量，与社区伙伴们一起，促进开源操作系统的持续健康发展和广泛应用，全力推进我国智能转型和数字经济发展。”龙蜥社区理事赵晓明表示：“钛星数安是互联网安全厂商，其多种云防护平台产品已为多个行业提供优质服务。相信钛星数安加入龙蜥社区后，将会依托其自身产品优势，在网络安全方面，携手龙蜥社区共同打造健康的网络环境，从而使龙蜥操作系统的防御机制更上一层楼。”截至目前，已有 200+ 家企业签署 CLA 协议加入龙蜥社区，包括安全厂商格尔软件、海泰方圆，数据库厂商南大通用、巨杉数据库，中间件厂商东方通、中创中间件、宝兰德等，欢迎更多企业加入。 ​龙腾计划可参看：“龙腾计划”启动！邀请 500 家企业加入，与龙蜥社区一起拥抱无限生态。—— 完 ——加入龙蜥社群加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！关于龙蜥社区龙蜥社区（OpenAnolis）由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的Linux 上游发行版社区及创新平台。龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。目前，Anolis OS 8.4已发布，支持 X86_64 、Arm64、LoongArch 架构，完善适配 Intel、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。欢迎下载：https://openanolis.cn/download加入我们，一起打造面向未来的开源操作系统！https://openanolis.cn

红象云腾秉承“从开源中来，到开源中去”的思想，于 2021 年加入到龙蜥社区。近日，红象云腾（Redoop Enterprise）V9 完成与龙蜥操作系统（Anolis OS）8 AArch64 的兼容适配，双方进行严格测试，测试结果显示，相互兼容，功能正常稳定。红象云腾总经理童小军表示：“红象云腾在完善生态体系建设方面一直保持持续投入，兼容性是基础软件核心竞争力。截至目前，红象云腾已完成与国内 17 家厂商，32 款软硬件产品兼容互认证。未来，红象云腾将充分发挥自身技术优势，进一步推动双方生态融合”。龙蜥社区始终秉持着“中立开放”的原则继续诚邀各企业与龙蜥操作系统（Anolis OS），围绕兼容适配、技术合作、商业版发行等多角度进行逐步合作，欢迎各位合作伙伴来进行产品适配，如有适配需求，请联系：陈佳 jackie.cj@openanolis.org「龙腾计划」自发布以来，已有超过百家企业签署 CLA 协议加入龙蜥社区，包括安全厂商格尔软件、海泰方圆，数据库厂商南大通用、巨杉数据库，中间件厂商东方通、中创中间件、宝兰德等，欢迎更多企业加入。 龙腾计划可参看：“龙腾计划”启动！邀请 500 家企业加入，与龙蜥社区一起拥抱无限生态。—— 完 ——关于红象云腾红象云腾成立于 2013 年，是一家专注于 Apache Hadoop 生态的大数据软件厂商，主要产品是红象云腾大数据基础平台(Redoop Enterprise V9.0)，产品代号 CRH（寓意“数据动车”），表示分布式动力，处理规模大，速度快。产品由 CRF 数据接入、CRH 数据存储、CRS 数据分析三大部分构成，为企业提供开放统一的大数据存储和处理环境。产品兼容支持Hadoop 生态圈中主要工具，提供 PB 级海量数据存储、查询、分析和挖掘能力。目前，已经在航天、石油、铁路、店里、金融及通信等基础设施的大数据场景部署上线运行，为用户提供高速高效，坚若磐石的大数据平台支撑服务。关于龙蜥社区龙蜥社区（OpenAnolis）由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的Linux 上游发行版社区及创新平台。 龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。 目前，Anolis OS 8.4已发布，支持 X86_64 、Arm64、LoongArch 架构，完善适配 Intel、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。 欢迎下载： https://openanolis.cn/download 加入我们，一起打造面向未来的开源操作系统！ https://openanolis.cn

2022年F5多云应用服务科技峰会于4月正式召开。阿里云智能混合云平台高级网络架构师张然（然犀）应邀于合作伙伴生态专场分享了阿里云混合云在开放网络生态领域的探索与实践。 混合云：政企数智创新首选近年来，混合云凭借着稳定安全、开放智能的特性获得了越来越多政企的青睐。国际权威咨询机构Forrester发布的《原生混合云加速企业数字化转型》报告中指出，混合云是全球企业数字化转型的关键动力，一体化原生混合云将释放自适应企业的无限潜能。 阿里云混合云是国内首个全自研大规模成熟商用的原生混合云。与阿里云公共云同根同源，客户可在任何环境本地化部署公共云产品及服务，并具备一键弹性至公共云的能力，让客户随时随地尽享混合云产品服务。目前，阿里云混合云Apsara Stack 2.0已从单一的私有云场景演进到服务于大型集团&行业云场景，不仅可以为政企定制稳定、安全、开放、智能的数字底座，实现智能管理和自动化运维，并可构建成为自主运营的“行业专有公共云”，致力于成为#政企数智创新的同行者#。 云下传统业务上云面临挑战在将传统数据中心业务迁移上云的过程中，如何将云下复杂多变的网络配置基于云上网络统一服务能力进行转换。用户及其业务架构通常会面临诸多的挑战，这些挑战存在于应用迁移、数据迁移等诸多场景中。 例如，在迁云过程通常会遇到用户上云需求迫切，云上IaaS提供的网络服务却无法在短期内满足用户个性化需求，用户又希望云上提供对等的服务能力。或者，客户重要业务上云，出于异构部署、使用习惯或用户技术栈等原因，用户希望在云内支持三方网络服务，以减少对应用架构改造的工作量以及因此带来的稳定性风险。 解决上述问题的常规思路是将云平台和传统的网络服务做集成。这种集成包括通过手工部署相应网络设备的虚拟化版本、云外部署硬件设备，或者插件集成的方式。但无论是哪种方式在高可靠性、功能特性、弹性扩展、平台兼容性和交付运维等方面都存在着诸多的使用不便。  网络分层架构灵活应对挑战基于传统客户上云所面临的挑战，阿里云混合云网络技术团队从整体架构规划上进行了深入的思考、深化的探索。由于混合云的业务属性和公共云有较大差异（如云平台运营责任主体差异、性能需求差异和成本差异等），需要考虑客户线下场景的实际诉求，包括以下几方面： 首先，客户的硬件需求：混合云客户有政企、金融、能源、医疗等各种大、中、小企业，客户对于硬件的需求完全不同。以网络设备举例，既有接受主流商用芯片系列的客户，也有基于IT自主可控战略平滑演进的客户，甚至部分客户出于各种原因要求采用指定的小众品牌。 其次，客户的业务需求：由于行业差异较大，客户对于云平台的规模、使用场景、云产品功能特性等的需求多种多样。网络架构既需要考虑对于云平台各种规模形态、上层云产品软件功能支持和持续演进，还需要考虑如何平滑无缝的和客户现有IT环境融合。 再次，客户的技术需求：需要考虑线下输出场景下客户对于云上应用的接受程度和自身的技术发展所处的阶段。客户上云之前已有成熟的业务系统，上云后的客户出于自身的需求，对于云上技术的接受程度有较大差异。 客户的需求就是阿里云混合云前进的动力，在云平台网络架构架构计上不仅需要为云平台提供弹性、灵活、安全合规、高可用的标准化网络架构，同时也需要侧重考虑通用性和开放性。 经过实践，阿里云混合云对网络进行分层，层和层之间再借助统一的服务化的语言进行解耦，最大限度的满足客户需求。   混合云需要确保能够适配线下输出场景各种不同的硬件基础设施组合。并且确保这些基础设施都能够在混合云定义的统一的架构标准下有效工作。由此我们引入的一层硬件抽象层。通过定义不同的功能分区和角色，形成一套基础架构，再借助不同角色功能区域组合满足灵活的架构形态；并在此基础上将架构基线化，通过抽象接口适配层和配置适配层屏蔽不同厂商、设备型号的差异，实现生态厂商的快速接入。目前，阿里云混合云不但可以支持阿里云自研硬件，也可以完美支持业内通用的主流商业硬件和国产化硬件，并建立了完善的产业生态系统。 在网络服务层，首先我们定义了NetService API对于网络原子服务能力进行了抽象化、标准化、让服务能力和具体产品管控能力解耦，并对上层调用提供编排能力，为上层产品快速迭代插上了翅膀。同时，通过网络资源服务对于Overlay/Underlay的所有网络资源进行统一的管理。最后，通过定义标准化的服务接口，搭建了开放网络服务平台（ONSP），对外提供三方网元的接入服务。而基于VNF形式的三方网元可以通过上层的混合云应用中心（AHM）作为入口进行管理。 混合云应用中心（AHM）为三方网元提供了运维管理的统一入口，同时对于三方网元镜像做到标准化的版本管理。混合云开放网络服务平台（ONSP）为三方网元提供底层能力支撑。开放网络服务平台构建在阿里云飞天洛神网络系统上，实现了飞天洛神网络和三方网络生态的充分融合，从而优化了企业客户生态服务的体验，更好的帮助客户迁云上云。既尊重客户既有使用习惯，又可以快速满足个性化需求。 阿里云混合云&F5联合方案阿里云和F5强强联手，整合双方在产品、技术和服务方面的优势，实现混合云平台和F5产品能力的有机融合，共同为客户提供一站式混合云解决方案。  F5虚拟化网元借助混合云开放网络服务平台（ONSP）在阿里云混合云融合部署方案，使得用户可以在混合云平台上获得和在传统IDC环境使用F5硬件一样的一致性体验的同时，将业务平滑的迁移到云上，获得云上的技术红利。 核心应用场景一：DMZ区云化 在客户的传统DMZ区里，往往可能会使用反向代理的ALG功能解决天窗问题。客户内网的风控系统也会通过在DMZ区部署的正向代理主动发起出向探测访问。随着传统IT全面云化，DMZ区也势必随着客户业务一起逐步上云。同时我们也能够看到DMZ区云化确实也能够借助资源池化提升效率，更快速灵活的响应各种安全合规和护网需求。另一方面，从政策层面，在某些监管相对严格的行业，我们也注意到出台了一些相关的行业标准，对于隔离设备：不限于硬件或软件等具体形态，主要起到隔离不同安全区域的作用。这为DMZ区云化进一步扫清了政策障碍。 核心应用场景二：传统应用平迁 传统用户上云的过程不是一蹴而就的。在企业里，上云迁移都是先从一些较为简单的应用开始迁移，然后再一步步把更多的应用和数据迁移到云，不可能同时把所有的应用都一下迁移过去。一方面是出于安全稳定性考虑，另一方面也是由于迁移上云也需要应用相应的云化改造。上图是一个典型云下客户的应用架构对应的网络分区图。在客户的DMZ区、业务区和数据区分别都使用了负载均衡设备。同时用户应用了irule的能力，使得用户应用和负载均衡实现强关联。当用户迁云时，我们可以对用户应用进行分类。对于已经实现或有条件实现云化的应用可以直接对接使用云原生的负载均衡服务能力。而对于部分未改造却又急需上云的业务，则完全可以在混合云平台内部署相应的F5虚拟化版本，从而实现传统应用快速平迁上云。 持续打造开放网络服务生态基于混合云开放网络服务平台（ONSP），虚拟网元设备实现无侵入式接入，从技术上解决了虚拟网络设备接入障碍，为用户提供更多的可选择项。同时，生态合作伙伴或客户自研的网络服务编排系统可通过平台开放的北向REST接口与平台实现深度集成，在提供一体化的管理运维体验的同时，满足更具定制化的需求。 随着用户关键业务持续上云，云计算的发展趋势将是越来越开放，封闭的技术无法满足用户的多样性、差异性需求。混合云开放网络服务平台（ONSP）将在开放性上持续迭代与创新，在支持更为广泛的生态合作伙伴接入的同时在易用性等方面为用户提供更优的体验。 未来，阿里云混合云在“做深基础“、“做厚中台“的基础上，将坚持秉承“做强生态”、“做好服务”的理念，持续通过开放、标准的互操作性打造好网络服务这一既传统而又崭新领域的生态，联合业内头部厂商共同为客户创造价值。   阿里云混合云（Apsara Stack）建管用一体化的全栈混合云平台，助力企业级客户全栈建云、智能管云、极致用云，致力于成为#政企数智创新的同行者#！更多产品资讯欢迎访问#阿里云混合云  #阿里云专有云  或加入钉群（32450454）交流。

6月23日，阿里云联合中山市锁业协会、天猫行业发布AIoT智能门锁视觉解决方案，重点解读智能门锁行业发展新趋势。发布会集聚芯片、模组、方案商产业上下游生态合作伙伴共聚中山市小榄镇，共同探讨智能门锁产业发展。会上阿里云面向智能门锁产业带率先推出“智能门锁视觉解决方案”，以平台升级、体验升级、安全升级为主题，助力锁业协会会员企业进行智能门锁产品升级。天猫智能门锁行业运营小二吴颖蕾分享了智能门锁行业发展趋势、天猫市场洞察分析、供给锁产业升趋势赛道分析、市场营销赋能、行业未来展望等内容，通过数据及行业解剖，为中山智能门锁企业带来新的营销思路。阿里云SMB业务部华南首席架构师周琴霞以云钉一体，助力门锁行业数字化转型为主题从面对市场多变、人员管理难、生产管理难掌控等痛点出发，解读如何通过软硬结合、一站式、低成本的标准数字化解决方案，助力成长型企业实现数字化原生。此次，阿里云发布的AIoT智能门锁视觉解决方案具有四大亮点：平台升级：针对智能门锁低功耗特点，Link Visual视频云平台提高了设备端和应用端开放SDK，可支持开发者自主进行设备开发和创新，同时以开放的方式提供云存储增值服务的企业自主运营策略，助力设备制造商转型云存储增值服务运营商。方案升级：为提升开发者平台对接的产品开发效率，阿里云推出软硬一体解决方案，低功耗Wi-Fi模组和猫眼模组预集成上云SDK，实现上电即上云，大大提升了开发者开发效率。体验升级：基于用户使用行为的Wi-Fi DTIM智能调节策略和设备端应用动态加载方案，大大降低了设备功耗和提升了出图速度，提升了用户体验。安全升级：全域安全防护措施，端云协同的安全方案，端云一体的安全芯片。阿里云智能高级产品解决方案架构师武师表示，多生物识别和联网智能门锁已逐渐走入千家万户，视觉、AI、安全及云加持的智能锁将引领智能门锁的发展趋势；随着消费者对智能门锁认知的不断加深，消费者对智能门锁的可视化、安全、可用性要求会越来越来高，如消费者门锁猫眼的视频对讲流畅度、视频出图的速度、门锁连云链路的安全等提出更加高的要求。阿里云推出的Link Visual智能门锁视觉解决方案，依托在视频领域千万级视频设备接入的实战经验，针对视觉智能门锁提供低功耗保活、快速出图、软硬一体、安全等端到端全链路解决方案，助力智能门锁产业升级，赋能合作伙伴产品创新。目前阿里云Link Visual可视对讲平台是具有千万级视频设备接入的实战平台，已接入视频设备数量5000万台，同时有预集成Link Visual SDK的软硬一体的硬件方案，包括WiFi模组、3D结构光人脸模组、低功耗双向保活可视对讲猫眼模组；可实现低功耗、快速出图等的能力，帮助客户快速落地产品及方案。根据智研咨询发布的《2022-2028年中国智能门锁行业全景调研及竞争格局预测报告》中，“对于可视猫眼能够实时进行监控，以及现阶段厂家技术的革新、体验性更好，关注度出现了大幅度的提升，甚至超过了生物识别，占比约为68.79%。”消费者对于可视方面的关注度在逐步提升。阿里云Link Visual视频云平台具有大规模商业化验证的成熟方案能力，阿里云正在协同产业链上下游合作伙伴，共同打造端云一体的智能门锁视觉解决方案，积极助推智能门锁的产业升级。

随着十四五规划强调打造数字经济新优势，将云计算列为数字经济重点产业，明确了以混合云为重点的云服务产业发展路线：“以混合云为重点培育行业解决方案、系统集成、运维管理等云服务行业”，混合云成为产业内众多服务商和政企客户关注的焦点。 2022年6月8日，由中国信息通信研究院、中国通信标准化协会主办，云计算标准和开源推进委员会承办的“专有云技术沙龙”线上直播圆满结束。本次沙龙除对专有云标准体系等进行解读外，还邀请了业内大咖倾情分享，共同探索专有云未来发展趋势。 阿里云混合云产品解决方案总经理李亮，与会并分享了「混合云建管用一体化探索实践」。阐述了阿里云混合云如何通过提供全栈建云、智能管云、极致用云一体化解决方案、完善的混合云服务和开放的混合云生态，助力政企应对数字化转型难题。  如今，越来越多的企业认同，混合云是实现数字化变革的必由之路。但由于每个企业所处的数字化阶段不同、需求各异，所以混合云建设的路径、方法和过程也不尽相同。在实现应用现代化的过程中，企业的IT管理者该如何选择一条最适合自己的技术转型道路呢？ 毫无疑问，只有打好数字基础设施的根基，才能进一步增强业务的韧性，有效应对日益复杂的应用需求，实现业务的创新与可持续增长。 李亮指出：作为推进政企数字化转型的核心基础设施，阿里云混合云（Apsara Stack）是业界最早践行公共云和专有云“同一架构”理念的云厂商，采用历经13年打磨的飞天云计算操作系统，与公共云同根同源，是国内首个全自研大规模成熟商用的原生混合云，且历经多年“双11”检验，集全栈建云、智能管云、极致用云于一体的全栈云平台。   全栈建云以飞天3.0为核心的阿里云混合云，具备“一云多芯”的能力，全面兼容X86、ARM等多种芯片全场景混部（Region内混部、同城容灾混部、跨Region混部）和统一调度。同时，阿里云混合云可以为政企客户构建大规模的跨地域多数据中心的“一朵云”， 打破地域限制，按照客户需求进行分层部署，分层为多个Region，各个Region之间相互关联、统一管理。 具备全场景容灾能力，支持传统的两地三中心架构&创新的同城三机房架构，实现核心业务RPO=0。历经8年行业深耕，阿里云混合云通过公安部等保三级、可信云认证、ISO27001、CSA等众多权威机构认证，是国内首家通过商用密码应用安全性评估的云厂商，为客户构建了全方位安全防护体系。 智能管云此外，阿里云混合云提供统一的混合云管理平台，支持云资源智能管理和云平台自动化运维。开放的OpenAPI平台提供丰富的SDK包和RESTful API接口。对于运维管理，通过OpenAPI获取云平台的基础管控信息，可以实现自定义管控系统的研发。 极致用云阿里云混合云提供云原生应用全生命周期管理，帮助构建 “双敏”研发能力，实现十倍研发效能提升；提供面向应用的新一代运维平台以及数字化业务系统安全工程。 在帮助政企迁云方面，阿里云混合云提供了一个涵盖云上网络规划、应用平迁、跨平台迁移、数据库迁移/替换、海量非结构化存储数据迁云的一站式业务上云平台，实现业务单元化、异地多活、应用就近接入等最优体验。目前，阿里云混合云拥有80多个全栈云产品，单集群最大规模达到1万台，可跨集群、跨机房进行云计算及大数据处理。基于底层飞天系统的统一框架，为客户提供一体化、高集成的技术架构，支持面向未来的业务创新和持续增长提供灵活的扩展。同时，还从硬件认证、应用生态和联合解决方案三个层面与各行业合作伙伴一起共建共享混合云开放平台。 阿里云混合云（Apsara Stack）建管用一体化的全栈混合云平台，助力企业级客户全栈建云、智能管云、极致用云，致力于成为#政企数智创新的同行者#！​更多产品资讯欢迎访问#阿里云混合云  #阿里云专有云  或加入钉群（32450454）交流。

点击下载：https://survey.aliyun.com/apps/zhiliao/JDxZBYdtN 随着云计算在政企行业的落地与普及，云已经从单向的底层技术支撑，逐渐向上与政企的业务越来越接近，甚至互相融合进入“云原生”时代。在这个过程中，阿里云混合云从诞生之初就坚定的选择了一条完全自研的道路，这也是一条充满挑战与机遇的道路。挑战在于，面对中国政企独特的场景和需求，阿里云混合云需要在自研的基础上，随着政企的需求不断迭代关键能力，且没有成功经验可以直接借鉴；机遇在于，我们将真正有机会打造一个适合中国政企的原生混合云，接受政企的打磨，成为政企数智创新路上能够互相理解与深度交流的伙伴。可以说，阿里云的原生混合云产品形态的演变，也是政企数智创新演进过程的一个缩影。2021年，Apsara Stack产品升级到2.0，这背后的动因正是政企客户需求迭代的催化结果：提到中国特色，“规模”这个词一定在其中。中国作为超大规模的经济体，从不惧怕规模的压力，而是能够利用规模的效益来实现时代伟业。聚焦在云平台上也是一样，现在很多政企云平台已经从单一站点私有云向集团云和行业云发展，尤其是大型机构或者分支众多的企业，往往倾向于集中投资建设云基础设施。其一，可以提高资源效率，基于规模降低建设和运维成本；其二，可以实现多数据中心跨地域统一管理与数据协同，为业务数字化创新提供统一的基础平台。“速度”，也是一个鲜明的中国特色，尤其在信息科技领域，中国弯道超车的速度有目共睹。现在，政企正在全面加速创新应用以外的核心业务的上云进程，传统业务和创新业务共存将是一段时间内的常见场景。一方面，客户需要快速地将传统以及核心业务加速并稳态迁移上云，包括迁移至异构芯片云，从传统简单单体架构应用上云、到复杂一体化应用平台上云、再到核心应用跨平台上云，这需要更加成熟的工具和经验传递，云厂商需要有低技术门槛，低成本，高效率的业务上云路径，从“网络-计算-数据”三层，帮助客户降低技术复杂度，降本增效，完成跨平台和业务云化两大趋势下的业务上云的评估、实施、验证；另一方面，核心业务的全面上云，意味着客户需要云平台有更高等级的容灾机制，即从单一业务容灾到全业务容灾，保障业务可靠性。第三点是“稳健”，不仅速度要“快”，还要“安全可靠”。在满足业务连续性、金融监管、等保2.0等对业务无中断、数据无丢失的要求以外，政企和云厂商需要增强自主创新可控能力，从单一硬件架构转为多硬件共存，通过将服务器芯片、专用芯片等异构硬件封装成标准、高质量算力，以屏蔽硬件架构差异，享受标准、高质量的云计算服务。第四点，是“统一”，统一的业务视角和统一的运维和运营管理。企业不仅需要从软件开发应用和数据中心运维不同的视角分层进行管理，更需要基于业务视角进行一体化资源管理来保障安全生产，这就需要从原来单纯的平台视角的静态资源管理升级到从应用/业务视角的动态资源管理。于是，以ITIL理念为指导，建设建管用一体化的从应用到云平台整体的统一运维和管理就变得尤为重要。云厂商提供商要“有理有据”的为管理者提供数据支撑，为决策者提供判断依据，最终大幅提高运维和运营管理效率。在云平台侧，全面上云后，客户需要更好地提高云资源的利用率，节省成本，真正享受云技术的红利。所以在管理上需要从传统的人工管理过渡到精细化资源管理，准确度量并预测指导未来资源的使用。 规模，速度，稳健，统一，这四个特点不仅描绘了中国政企对于云平台建管用方面的2.0需求，也反应了我们Apsara Stack 2.0核心产品能力的演进方向：Apsara Stack 2.0可以为政企构建大规模的跨地域多数据中心的“一朵云”，可以打破地域限制，由各级各地域各自分散建云，到建设跨地域多Region的一朵云，通过支持数据跨域计算与调度、全网数据统一协同，实现“物理分散，逻辑统一”，用数据赋能智能，助力经营决策科学化、经营管理精益化。所谓“一朵云”，是指统一运营&运维、计量、账户&权限：统一运营、运维：运营控制台入口在ASCM，运维控制台入口在ASO。对于云产品管控中心化部署的，对应跳转至中心化控制台；对于管控单元化部署的，对应跳转至单元化控制台。计量：计量服务OMS中心化部署，由各云产品从各region推送至中心的OMS服务存储，用户可以通过计量控制台查询到全域云资源的计量数据。账户、权限：控制台、POP网关以及OSS/OTS等存储类产品自建网关的鉴权依赖账户、权限等服务，因此既可以满足全域账户权限数据一套，又满足就近访问的能力。账户、权限服务在中心Region支持读写，数据同步至各单元Region，在单元内只读，实现读写分离。在帮助政企迁云方面，Apsara Stack 2.0提供了一个涵盖云上网络规划、应用平迁、跨平台迁移、数据库迁移/替换、海量非结构化存储数据迁云的一站式业务上云平台，实现业务单元化、异地多活、应用就近接入等最优体验，我们将这个能力成为“一站式迁云”，主要有3点优势：基于整体工具集的组合能力，提供统一的入口，从“网络-计算-数据”三个层面整合整体工具链领先的操作系统兼容性，具备覆盖多平台的软件和源码迁移能力完整的数据库迁移工具链和海量的数据迁移工具链专有云平台上承载着大量重要信息系统，政企业务对于安全的要求也更为严苛。因此，保障云的安全至关重要。“拐棍再好，不如腿好”，Apsara Stack 2.0作为真正的原生的混合云，也引入了真正的“原生云安全”。我们说的“原生云安全”，不是简单的基于云原生（容器）的安全，而是云的原生安全，是阿里云自研以及对OEM产品进行服务化改造后跟云平台有机融合的“原生云安全”。简单来讲，安全是为业务服务的，政企在进行业务的数字化转型的同时，我们也在进行安全的数字化转型，逐步向着平台化、服务化、数据化、智能化、自动化的方向发展，并以安全构建起政企对于阿里云混合云技术实力的信心：获得国家主管部门权威认可的安全能力，首批（仅两家）通过国内最为严格的网信办云计算服务安全审查增强级认证，政务云通过等保三级认证，金融云通过等保四级认证；连续多年参与国家级大型攻防演练零失分；某政务专有云项目早在2018年就通过了等保四级测评，阿里云专有云平台满足等保2.0四级要求的安全能力我们将安全与云深度融合，统一控制台和统一账号权限管理，把简单留给用户，同时支持服务化部署和分钟级交付，以及多租户和租户自助服务，所有安全产品账号和数据打通，实现联防联控，提高安全运营效率基于阿里巴巴十多年高强度攻防对抗经验，通过基于人工智能的威胁感知能力，驱动防御不断进化，更加快速与准确 在和各行各业的政企客户深度交流中，我们发现“应用部署治理和智能运维”是影响客户应用全面上云最重要的因素。以往，云厂商的注意力往往更多基于技术操作的自动化设计思路构建大量的工具，但是我们真正需要做的是为政企的运维治理及流程自动化负责。这意味着，我们不仅要帮助政企“管理”好云平台，从云资源层面的基本管理发展到云平台层面精细化运营，还要帮助政企来做云上应用系统的统一管理与运维。Apsara Stack 2.0 在帮助政企统一运维和运营管理方面，主要从4个方面进行了加强，分别是一体化管控、智能化运维、精细化运营和个性化扩展，集中来实现两个目标：一是深度整合，以标准化的方式被集成到政企已有的管理体系中；二是数据驱动，通过自闭环方式的持续提升和优化管好云的方法论。我们从政企的业务流程开始分析，从云上资源规范到应用的部署架构，沉淀出了一整套最佳实践，并通过逐步将最佳实践固化在平台产品中的思路，帮助政企完成应用上云的工作，我们称之为“面向应用的一体化运维”，这里的“一体化”，主要包括“租户+平台一体化”“应用+专业一体化”“云上+云一体化”“敏态+稳态一体化” Apsara Stack 的诸多核心能力都反应了中国政企客户独特的企业级需求。究其根源，Apsara Stack的核心产品能力，都是来自于中国政企客户的需求和实践。起初，在我们确定技术路线时，对阿里云公共云进行了一些技术复制，来发挥公共云技术领先性、产品体验性和规模等优势，延续在软硬一体神龙架构、大数据、数据库等方面的优势，但是这远远不够。后来，大型政企客户的特性需求，让Apsara Stack的企业级特性不断丰富，比如在构建某省政务一朵云的过程中，Apsara Stack一云多Region的能力不断成熟，后来被应用在某大型能源集团，成为业界的标杆；比如服务完某城市大脑后，Apsara Stack在大数据和数据智能方面的能力更进一步；在某大型金融机构行业云的打磨后，Apsara Stack累积了为政企打造面向政企的客户服务的“可运营的行业云”的能力；在支持某大型国有物流集团业务的过程中，Apsara Stack的稳定和弹性扛住了多年来流量洪峰的考验……可以说，如果没有中国政企走在数智创新道路上的革新者的支持和信任，Apsara Stack就不会存在，也难以不断积累实力，将经验与能力反哺给更多的中国政企。科技领域从零到一的创新从来都是无比艰难，混合云领域尤为明显。企业级科技领域的发展就像在海上驾驶航母，相比于朝着正确方向的缓慢行驶，调转方向造成的时间落后会更多。迎接新浪潮新机遇的最佳实践，不是不断的转动船舵，而是朝着正确的方向全速前进。值得庆幸的是，我们从一开始就选择了一条正确的原生混合云之路，在理论和实践上已经取得了代差优势。此外，加上多年政企的考验与锤炼，在大规模的业务实战后，诞生于中国的原生混合云的路线也在中国市场快速获得了巨大的认可。面向未来和政企并肩的新旅程，我们依然会坚定方向，全速前进。以上内容来自阿里云团队推出的《云栖战略参考 -- Apsara Stack同行者专刊》欢迎扫码或前往：https://survey.aliyun.com/apps/zhiliao/JDxZBYdtN 阅读完整内容​​阿里云混合云（Apsara Stack）建管用一体化的全栈混合云平台，助力企业级客户全栈建云、智能管云、极致用云，致力于成为#政企数智创新的同行者#！更多产品资讯欢迎访问#阿里云混合云  #阿里云专有云  或加入钉群（32450454）交流。

 云计算经历十几年的发展，从被认为是“新瓶装旧洒”受到很多怀疑，到在消费互联网领域得到广泛应用，再到传统政企客户普遍认同，并在政务互联网业务领域快速推广，当下已进入到全面替换政企客户传统IT基础架构的攻坚阶段。这一替换，在中国的政企市场，是以专有云&混合云及其延伸方案为主的独特云化演进路径（非欧美的公共云延伸演进路径）。以往，互联网企业和小型企业上公共云之前，主要做公共云厂商间的技术产品能力对比。但是，大中型政企客户上混合云前，则是要全面对比混合云与传统架构的技术产品能力。未来3到5年，阿里云混合云平台，将做为政企客户数智创新的同行者，虚心学习听取政企客户全面上云的需求和建议，开放透明分享以IaaS、数据库、大数据为核心的混合云平台的“建管用”好云知识经验，持续致力于完善混合云企业级特性和客户自主自助运维能力，帮助政企客户IT基础设施尽快全面云化，安全稳定、统一高效地支持客户双模应用的双态运维，成为政企客户最信赖的混合云！ 1-   架构技术洞察1.1 IT架构从传统平台适配传统应用，重回到云平台适配传统和云应用 传统IT架构经过近30年的发展，形成以硬件定义数据中心为特点的IT基础设施平台。这些平台由各种专有硬件系统为基础，由系统集成商和软件ISV做生态支持。使得客户应用开发专注于业务逻辑，各种复杂的可用性、连续性、扩展性、安全性等功能，由差异化的硬件系统完成（含专有OS和中间件）。这一阶段，是传统IT基础设施适配传统应用软件阶段。互联网业务快速发展，推动政企客户数字化转型不断深入，造成IT软硬件规模快速加大。继续用专有硬件系统和商业软件套件支持，有关软硬件投入过大，配套人力也需线性增加。为此，云架构应运而生。各种分布式微服务应用，直接在软件层实现更多的高可用、连续性、扩展性、安全性等功能，不再与IT基础设施紧耦合，使用大量通用服务器系统和IaaS/PaaS云平台替代传统大机/小机专有系统。这一阶段，是分布式应用适配云平台的阶段。该阶段专有硬件系统投入大幅降低，但需要大量软件开发运维人员，很多客户不具备这样的条件 。云原生技术架构的发展，推动IT架构重新回到更高阶的云平台适配云应用阶段。该阶段实际就是做深基础、做厚中台的过程。软件应用架构，向业务中台、数据中台、低代码平台、协同平台发展。分布式微服务框架向容器化、Mesh、Serverless发展，应用部署架构向单元化多地多活发展。数据库向HTAP离在线混合处理、大数据向湖仓一体/流批一体发展，IT基础设施向软硬一体、存算分离、异构算力池化、轻量化安全容器发展。最终，实现云应用更加轻量化、低代码化，大量非功能性需求、企业级特性，甚至代码生产交由各级云平台实现。从技术的角度，云原生架构是基于云原生技术的一套架构原则和架构模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，以便由云服务提供商CSP的云平台（云IT基础设施和云应用开发运行平台）接管云应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。（注：广义云原生架构=云原生技术+云架构原则+云应用架构模式+云应用+云IT基础设施+云应用开发/运行平台。） 1.2 双模IT应用还会长期并存，但IT基础设施需要加快整合进全栈IaaS云当前，政企客户的互联网业务已广泛使用云架构，但占主体的经营管理和核心生产应用，仍然运行在传统IT基础技术架构上。过去20、30年，政企研发积累了大量了传统集中式架构的应用系统。这些应用系统很难在中短期内低成本、全生态配合地重构成云原生架构应用，客户3%-5%的IT人员占比，也不足以支持这种快速重构和转换后上IaaS云，大多还是运行在传统IOE架构。随着政企的互联网类应用、 大数据类应用上 IaaS云后，客户需要同时维护好两套端到端不同的技术栈。特别是在运维压力最大的IT基础设施领域，传统专有硬件基础上的各种封闭系统，与软件化服务化IaaS、DBaaS等系统，在技术架构、运维方法、生态体系方面，都有非常大的差异。不加快整合进云平台，政企不仅无法降低TCO，也无足够资源深入学习掌控云架构。如果混合云IaaS+平台（含数据库、大数据平台），能够同时适配传统应用、云原生应用等不同云化成熟的应用，既支持客户分步对一些老旧应用、互联网应用进行云原生重构后上云，又支持客户对传统应用代码、技术工具、运维组织体系做少量云就绪改动，平滑迁移上云，替换传统集中式IT基础设施，就能很好地支持政企传统应用全面上云。 1.3 云厂商产品替换多家传统厂商产品，目的是打造更高体验的云OS阿里云的战略是做深基础、做厚中台、做强生态、做好服务，分层打造IaaS\PaaS\ DaaS\SaaS等云平台和云OS。做深基础，本质是在发展软件定义数据中心及IaaS云OS。所谓软件定义数据中心，就是将数据中心的建设运维视为业务，对这一业务的流程、组织、人员、数据做系统化的数据建模，再基于数据建模将所有业务操作和数据封装成服务，通过分层嵌套的服务化云平台和API接口，实现灵活的编排组织。做厚中台，就是持续打造软件定义开发中心及业务中台OS、软件定义数据管理中心和数据中台OS，使客户在我们的双中台上，能够低成本、高复用地开发应用和加工使用数据。同时，我们会努力使得技术栈上层云OS与下层云OS解耦，使其有能力灵活适配客户下层异构多云IaaS平台。之所以要一家云厂商替代原来众多的计算、存储、网络、安全等产品，目的是打破传统各个单一垂直专业领域封闭专有的软硬件技术栈，借助软件定义数据中心内部分层嵌套的计算、存储、网络、安全数据库、大数据库等服务化平台化架构，用统一的云平台软件管控调度能力，整合IT基础设施各种标准化硬件资源，对外按需提供灵活弹性、差异化SLA的IaaS服务。未来，在每个国家地区云计算市场，都会有很多家全栈的IaaS云厂商产品供政企业客户选用。这些云厂商帮助客户做好了系统集成和综合服务，不仅可以降低总体TCO，还能提升综合服务体验。就像开源开放Linux产品的广泛应用，替代了原有众多商业基础操作系统，不仅没有造成全球市场垄断，还帮助客户降低了服务器OS方面的采购成本。客户担心供应商垄断，满足招标采购需求，希望引入产品技术竞争时，不适宜再用传统的“部件”级分散竞争采购、高成本自组装集成方式，而适宜按需引入多个不同云厂商的全栈云来解决。 1.4 客户追求云产品的黑盒化体验，也需要对云架构有白盒化的自主掌控我们购买使用一台自动驾驶汽车或智能手机，目的不是要能够灵活组装、拆解维护这台汽车和手机，而是获得这些产品黑盒化安全稳定运行、简单灵活操控的体验。 混合云产品虽然是一个更加复杂、大型的企业平台系统，虽然很难马上做到极高的安全稳定性，低门槛的学习成本，也要坚持“把复杂留给自己，把简单留给客户”，努力为客户提供简单卓越的黑盒化使用体验。只要我们操控混合云，就像操控一台“自动驾驶汽车”一样，发出各种启动、刹车、选路、定速等各种指令和操作，都能获得稳定可靠、准确及时的操控体验，再加上智能驾驶仪表盘上各种灵敏、准确、全面的反馈，以及完备有效的应急服务体系，就能增进客户使用信心。当前，混合云平台还处于发展成熟过程中，对云厂商服务依赖还比较大，各种故障应急恢复操作平台工具内嵌化、快速启动自动恢复能力，以及自主扩缩容/升级打补丁、维修变更等运维操作能力都还需要持续提升。在这一阶段，我们需要同步“白盒化”开放透明分享我们的云架构建设理念和运维经验，听取客户的一线实践反馈，一起共创设计提升云平台“黑盒化”服务能力。 1.5 公共云与混合云架构既统一又差异，从单向能力传递走向互相促进云厂商公共云业务大多经历了10年左右的投入期，借助互联网客户的大规模应用，获得了公共云的规模经济共享经济红利，开始进入标准化、高效化，与客户共赢阶段。而线下政企客户混合云市场的技术和管理差异化很大，线下交付分散运维的成本很高。例如：仅为满足出厂商前的集测和质控，动辄就需要投入万台规模物理服务器，搭建各种异构多芯、多Region多版本的存量客户云实例集测验证环境。为此，只有坚持公共云与混合云统一核心基础架构，才能提高云厂商内部研发效率，分享公共云敏捷迭代、灰度验证的红利。公共云与混合云各自独立发展，研发投入会不足，容易给客户造成版本断代、强制换代等困扰。但是，坚持公共云与混合云核心基础架构一致，不意味着将公共云大规模、分布式DevOps建设运维体系映射出来的软件架构和组织管理模式强塞给客户，而是需要针对混合云客户场景，全面重构云管平台里的应用/云产品、租户/云平台运维系统，满足客户传统和云原生应用全面上云以及集中式建设运维管理的需求。同时，也希望我们的客户能够学习掌握云架构原则理念，分步推动一些组织流程、治理体系的配套云转型，以便更高效地发挥云架构的优势。政企客户不同云化成熟阶段的传统应用，将与高成熟的云原生应用长期并存。因此，对IaaS云平台的统一监控、存储/数据库同城复制、故障应急恢复、容灾切换演练、迁移热升级、自主扩缩容、灵活备份恢复、统一安全控制、多云/混合云管理等企业级特性有很高的要求。这些企业级特性往往会先在混合云环境建设完善，再反过来促进公共云技术架构和运维能力完善，为支持未来政企客户部分业务应用上公共云打好基础。 1.6 政企客户试点上云关注数智/敏捷/经济，全面上云更关注安全/自运维以公共云业务为代表的云计算发展初期，客户上公共云的主要驱动力是降本增效、敏捷弹性。但在专有云和混合云环境，政企客户CIO们关心的，首先是整个IT系统的持续安全稳定运行，出现故障问题之后能够自主可控快速恢复，以及自主可控产品技术的替代。其次是引入大数据、AIoT的数智化技术能力，促进业务的创新发展。第三，才是资源的池化共享、弹性伸缩，以及TCO的下降。大型互联网企业云原生应用在公共云上的敏捷自主研发、DevOps一体化运维、大量自研软件工具平台、软件管理软件的最佳实践，并不适合大多数政企客户人员少、软件自研能力弱、应用软件分散外包定制开发、软硬件系统集成和集中化IT治理和组织管理等云环境的背景特点。为此，混合云平台需要优先建设完善云产品高可用连续性设计，以及应用/平台智能运维能力，优先保证好混合云上各种云成熟应用的安全稳定运行，以及自主可控建设运维需求，再考虑经济、数智、弹性和敏捷能力。                                      2-   阿里云混合云技术能力建设2.1 坚持与公共云核心技术架构一致， 复用公共云红利多年来，阿里云混合云平台核心技术架构坚持与公共云保持一致，最大限度复用公共云技术研发实践红利，避免了产品技术路线分支可能的推倒重来，保持了产品技术架构稳定、平滑升级和持续发展。同时，我们在混合云平台上，增加研发了20台左右的小型化最低服务器数量起步方案，各种亲和性和非亲和性和异构多芯多集群调度策略，云产品IAC基线方式终态运维和自动化热升级能力，以满足混合云客户不同于公共云客户的差异化需求。为了在通用以太网络上全面替代传统的小机、SAN网络、SAN存储的软硬一体、存算分离架构。阿里云公共云三年前就已经开始全面投产神龙服务器、自研网络交换机、网络软硬一体加速、RDMA  ESSD全闪分布式云盘存储的软硬一体、存算分离架构。混合云也将延续这一公共云上验证成熟后的架构技术路线，以大幅提升了上层数据库、中间件、大数据产品的硬件卸载、共池管理、敏捷供应、快照备份、离在线混部、主备切换RPO=0等企业级特性/能力。阿里云混合云Apsara Stack的核心产品技术能力，一般都是在公共云上灰度验证、上线运行一年后才发布给混合云客户使用。公共云上敏捷DevOps运维积累的经验，也保障了混合云多年来的安全稳定运行，从未出现大的技术路线错误的或未验证的技术方案故障。 2.2 一云多Region架构满足混合云客户建云需求一云多Region是使用一套用户账户及权限体系的云平台系统，单一用户账户权限具备全域资源实例开通、管理、应用发布的能力。通常，大型机构或企业业务遍布全国甚至全球，往往会选择在集团总部搭建一朵“专有云”，总部下面的每一个职能机构又需要建设各自的Region。对于这种复杂的“总分型”场景，一云多Region架构可以很好的支撑业务的互通互联，通过大规模部署实现更高、更灵活的工作负载。为什么说“一云多Region”比“多云多Region”更有优势? 首先在管理层面：1.统一规划建设、运营、运维；2. 具备统一资源视图区域自治的能力；3. 具备统一账户以及统一权限。从开发视角来看：1.一次开发，多Region部署，代码可以做到集中管理、全域分发、就近访问；2. 大数据计算可以统一视图、跨域计算；3. 能够产品化支持跨域网络打通；4. 可以产品化支持跨域数据流动。从弹性及灾备视角来说：1. 支持应用的跨域弹性，最大化利用资源；2. 可以支持本地灾备以及跨域灾备；3. 一云多Region是一种产品化的灾备能力，可实现白屏化管理。一云多Region架构主要用于生产与研测环境隔离、高安全等级内网与外网强隔离、集团不同性质业务合规要求强隔离等场景。这些场景追求高度的隔离性，要求每个Region有自己完全独立的帐号权限、云管运维、运行安全管理系统。总部与省市分公司是多级法人的政企客户，如果采用多云架构，需要在多云之上，重新再搭建一套复杂的多云管理系统，实现帐号单点登录、权限统一管理，云管集成整合。由于各朵云建设时缺少地址分配、资源命名的统一规划，多套独立的管控系统没有原生的集成设计，很难给客户提供一体化管理的体验、跨域灵活共享数据。阿里云混合云物理分散、逻辑统一的“一云多Region”架构，很好地解决了这一问题，统一用户账号权限体系、资源全局视图统一调配，总分部大数据的跨域计算特别适合政企总部对于二级子公司“既要由总部全局统一管理，又要保持子公司自主活力”的需求。 2.3 “一云多芯”支持政企客户IT自主可控战略平滑演进IT基础设施的自主可控，需要混合云平台兼容适配目前市场上主流的五六种异构芯片服务器，这对于我们云产品的特性兼容适配、在线轮转升级、性能调优调度能力有很高的要求，研发测试部署运维工作量十几倍增加。经过近两年来持续的投入，不断地努力研发，阿里云混合云平台上的近百款云产品，大多数实现了单AZ内异构多芯多集群混部，部分云产品做到了集群内同构不同芯的混部，少量只支持单集群的产品，也实现了按产品混部。多集群混部：客户在申请创建云产品服务实例时，只要选择好异构芯片类型和厂商，就能将有关服务实例准确地创建到相应芯片的产品集群上。集群内混部：客户在申请创建云产品的云服务实例时，只需要选择x86或ARM芯片类型，不需选择不同厂商。集群内服务器分批替换过程中，该云产品上已创建好云服务实例的正常运行透明无感。未来，我们还将进一步发展支持集群内x86和ARM异构芯片混部。按产品混部：对于AZ内只能部署一个集群的云产品，客户可以一个云实例中，为这些云产品分别选择不同的芯片类型进行部署。单集群内不同芯片的扩容/替换，优先通过集群内混部解决，再是发展成多集群异构多芯混布，以及整集群短时间停机迁移方式解决。 2.4 行业云/政务云/集团云等类公共云运营模式趋于成熟为了转化服务模式、优化行业生态或增加运营收入，部分政企有了在专有云平台基础上对外运营行业云的需求，让自己的云变成一朵可以对外提供服务、可以被运营的“行业云”。与专有云不同，行业云的客户分为两层，一层是使用云平台的政企自身，第二层则是政企的客户。两层用户的存在与运营需求，需要能够区分平台和租户，将对云平台的管理从“运维”维度扩展到“运营”维度，同时不断沉淀行业解决方案。阿里云基于其公共云运营的能力和经验，在行业云领域具有先天优势，通过提供服务目录管理、流程审批、账单计费和运营增效等能力，帮助客户构建行业云的大型实践。尤其是其中的账单计费能力方面，我们基于阿里云公共云的账单计费系统进行了抽象和简化，使其可以更好地面向最终用户，提供灵活便捷的计费规则设置能力。同时，我们增强了云平台“可扩展”能力，对于特殊的运营售卖、业务流程诉求，可以通过标注换的扩展方式，与阿里云的生态伙伴一起，提供符合实际业务需要的功能，更好地支撑客户的行业云运营。 某省级政务一朵云、某金融机构行业云等阿里云与行业龙头企业和政府部门联合投入、经营风险共担，收益共享的运营模式成功运营多年，为国内混合云市场后续行业集中、地区集中、全国/省级集中的行业云建设趋势积累了很多有意义的经验。例如：某省级政务一朵云试点运行的“一云多Region架构，在后续某大型集团央企客户处得到了很好的推广。某金融机构行业云多租户的IaaS云平台服务，安全稳定运行三年多时间，为小型券商金融机构的交易应用、研发的灾备应用全面上云提供好了良好的支持。 2.5 软硬一体、存算分离打造云原生数据库    过去30年，政企客户借助传统的软硬一体、存算分离的“IOE”集中式数据库架构，支持保障客户核心业务系统的建设和发展，随着互联网的业务发展，数据量在急剧增多，数据库也逐渐在从Shared Mem/Disk的集中式架构，向Shared Nothing分布式架构演变。Shared Nothing分布式架构数据库要求应用架构配套分布式改造，客户很难对所有传统应用进行快速全面的分布式重构。大量传统应用仍然在使用基于单台x86物理机本地盘的主备/3节点选举的开源/RDS MySQL数据库。但计算和存储耦合的架构又无法发挥云计算资源池化、弹性扩缩、敏捷供应等技术红利带来的优势，单库存储容量小于6T，QPS/TPS有限。    随着基于神龙服务器+25G网络+CDS分布式共享云盘的软硬一体、存算分离架构的日渐成熟，阿里云混合云2022年将推出基于神龙CDS、容器化、Shared Everything架构的PolarDB O共享存储数据库，可为政企客户提供高度兼容Oracle语法的数据库引擎，通过所有数据库实例计算节点共享一份数据的方式实现1写15读（多写多读在研中）、100T存储&100万QPS的集中式大库，以及在线敏捷弹性伸缩、灵活快照备份恢复、计算节点故障切换RPO=0且RTO<15s的高可用、计算存储资源分别池化共享等企业级特性，满足政企客户传统应用系统不做分布式改造，也能IaaS化平迁上云的需要。  2.6 大数据方面取得的进展阿里云大数据技术经历11年的沉淀和发展，从2019年开始，数据仓库到数据湖形成主型发展的趋势，湖仓一体应运而生。阿里巴巴最早在该领域进行探索，2021年，湖仓一体对接了CDH、TX等，已经在政务和金融行业形成数个标杆和成熟方案。MaxCompute作为阿里巴巴数据中台技术底座，经历多年双11锤炼、技术自主可控，离线查询加速到秒级、金融级安全，在大规模点查和低成本查询加速场景中已经在多行业项目中落地。大规模数仓的高性能、低成本，支持多芯、多Region、容灾等能力在政企、金融头部客户得到了广泛的认可。MaxCompute是中国唯一入选Forrester全球云数仓卓越表现者象限的产品，TPCx-BB 100TB 五连冠全球冠军。在实时计算领域，阿里云基于开源 Flink 引擎打造新一代的 3.0 云原生大数据平台 Ververica Platform和企业级计算引擎 Ververica Runtime，超大规模的 Flink on ASI 调度，提出了流批一体的数据模型，即用一套API来完成实时数据与离线数据的处理，实现了流批统一的DataStream API + Table / SQL API + Connector，并在执行层支持流批一体的调度与面向批处理进行优化的Batch执行模式。2021年度，阿里云在大数据领域也获得了业界诸多认可。 3-   云平台建设展望3.1 传统应用PaaS化云原生重构上云和IaaS化云就绪平迁上云 传统应用PaaS化云原生重构任重道远。阿里云混合云将进一步完善“云效”敏捷DevOps平台，打造云原生应用研发运维一体底座。不仅为政企提供敏捷项目管理、需求管理、研发测试工具，还将增强云原生应用架构设计管控、企业通用应用组件复用、Mesh化/serverless架构推广、业务/数据双中台企业服务目录、低代码快速应用开发平台、多地多中心应用单元化多活架构、“无影”云上安全研发测试环境等方面的能力，为企业移动化、场景化业务创新提供各种平台/工具服务。传统应用IaaS+化平迁上云是当务之急。政企客户传统应用负载积累了几十年，很难中短期快速实现全面的云原生化重构。为此，阿里云混合云将提供屏蔽分布式技术复杂性、兼容传统Oracle数据库和开源数据库、兼具分布式扩展和高性能集中式大库的PolarDB数据库，具备丰富复制容灾、快照备份、共享存储等企业级特性的CDS云定义分布式存储，完善的网络安全访问控制解决方案，多地多活的平台容灾方案，一站式迁云工具，支持客户只对传统应用做少量改造，就能全面平迁上云。 3.2 硬件软件化和软件硬件化统一发展，构建新的软硬一体架构。硬件软件化，是指云计算发展过程，先是打破传统架构中各厂商纵向、差异化、封闭一体化的硬件技术堆栈，重构横向、标准化、分层服务化的软件平台。软件硬件化，是指云计算发展深入，开始基于新的软件定义架构，将软件能力卸载到分布式、标准化硬件上的GPU/DPU，对云操作系统进行软硬一体整体加速。云原生软硬一体架构，能够在标准化、通用化的x86/ARM服务器基础上，通过增加DPU、RDMA的硬件能力，提升计算、存储、网络、安全等IT基础资源的弹性伸缩和利用效率，解决存算分离后网络时延加大问题，获得存算资源分别池化共享、物理机敏捷供应虚拟化服务、主备切换不丢数和故障快速恢复、数据灵活快照备份恢复、虚机为单位降低售卖起步等企业级特性；能够将复杂的分布式技术封装起来，既可以提供ScaleUp纵向集中式扩展的IT服务，又可以提供ScaleOut横向分布式的IT服务，有效替代传统小机+SAN网络+SAN存储的传统存算分离架构，以及各种专有硬件设备。 3.3 应用与云产品、租户与平台一体化云管，满足集中式专业化运维需求。面向应用的云管系统，是混合云最重要的核心竞争力。不同于传统IT架构的外挂式监管控运维系统，混合云的云管是分层嵌套的服务化的混合云平台和各级服务和运维API的外在交互式体现。也就是说，混合云云管平台上能够实现的各种用户交互功能，都是通过编排调用各个云产品服务和运维API的方式实现。混合云客户所需要的各种应用系统、云产品平台的服务和运维管理功能，很多是云原生内嵌在各个云产品管控，云原生分布式微服务中间件和数据库里的，再加上云管系统的统一场景化集成交互界面，满足混合云客户跨业务、应用、产品平台、跨租户运维和平台运维进行集中统一运维管理的需求。未来，阿里云混合云的云管系统，将持续发展多种云成熟度应用的统一建模、架构蓝图可视化交互驱动、集中式运维场景化集成、应用运维关联整合平台运维、统一事件监控定级处理、应急预案集成和指挥协同、应用云管适配异构IaaS多云等功能。 以上内容来自阿里云团队推出的《云栖战略参考 -- Apsara Stack同行者专刊》欢迎扫码或前往：https://survey.aliyun.com/apps/zhiliao/JDxZBYdtN 阅读完整内容更多产品资讯欢迎访问#阿里云混合云 #阿里云专有云 或加入钉群（32450454）交流。