深入浅出谈SCADA
一、什么是SCADA系统SCADA(Supervisory监控 Control控制 And Data Acquisition数据收集)系统，即数据采集与监视控制系统，主要应用于电力、石油、化工、燃气等领域的数据采集与监视控制以及过程控制等领域。
以燃气场站为例，下图就是一个典型的天然气场站SCADA系统，通过这样系统监测着场站里各种压力、流量、温度等设备的数据运转是否正常。场站里的设备种类多、数量多，SCADA系统具有采集、控制分散；管理集中的“集散控制系统”的特征。SCADA可以理解为不同厂家的管理监控系统（上位）对控制部分（下位）的数据采集与监控管理。
SCADA的产生应该是在上世纪80—90年代，当时各家自动控制系统相对独立，互相之间没有联络，这种垄断状况限制了自动化技术的发展，随着计算机技术的成熟，以计算机为基础的上位系统逐步发展起来，可以和各种厂家的控制部分去联络进行数据采集监控，从而打破当时各自动化厂商的垄断，这也使自动化技术逐步开放和发展起来。随着计算机与自动化技术的高速发展，各个系统都不再是独立系统，都纷纷推出各种接口功能去和其他系统去联络，这样就形成了这个控制系统的上位监控管理部分可以采集和监控别的控制系统的下位控制部分。
二、SCADA简短的历史随着遥测技术的出现，SCADA的发展可以追溯到二十世纪初。遥测涉及通过感测实时条件获得的数据的传输和采集。随着电力，电报，电话和无线通信技术的融合，遥控条件的监测变得可能。在上个世纪，更多的工业，如天然气，电力和水务公司，使用遥测系统来监测偏远地区的进程。
SCADA始于六十年代初，作为在主站和远程终端单元（RTU）站之间作为输入/输出（I / O）信号传输的电子系统。主站将通过遥测网络从RTU接收I / O传输，然后将数据存储在主机上。
在七十年代初期，开发了DCS（分布式控制系统）。 ISAS5.1标准将分布式控制系统定义为在功能集成的同时由一个子系统组成的系统，这些子系统可以在物理上分开并且彼此远离。大型制造商和工艺设备利用DCS主要是因为需要大量的模拟控制。
进一步开发使分布式控制系统能够使用比RTU更智能的可编程逻辑控制器（PLC）能够控制站点而不从主站获取方向。
在九十年代后期，SCADA与DCS之间的差异模糊。 SCADA系统具有DCS功能。 DCS具有SCADA功能。系统根据设计师内置的某些控制功能进行定制。现在随着互联网被更多地用作通信工具，一旦旧的遥测系统变得越来越先进，互连和可访问的控制功能。正在开发自动软件产品以利用互联网的互连性，某些门户可以连接到SCADA系统并下载信息或控制流程。
今天，良好的SCADA系统不仅可以控制流程，还可用于测量，预测，计费，分析和规划。今天的SCADA系统必须满足一个全新的控制自动化水平，与昨天的过时设备连接，灵活性足以适应未来的变化。
三、SCADA典型架构典型的SCADA像下图，分为场站端和管理端。
场站端：主要是三部分：下位机、通信网络、上位机。
管理端：一般包括前置采集、SCADA应用。
场站端：
下位机：侧重采集和控制。一般由RTU和PLC组成。
通信网络：实现上、下位机之间数据交流。
上位机：侧重监控功能。一般由电脑和服务组成，主要起到远程监控、报警处理、数据存储以及与其他系统集合的作用。
管理端（也叫中心端）
前置采集：各种采集设备的协议解析、转换。
SCADA应用：设备数据存储、监控。
四、庖丁解牛看SCADA接下来分块来说，SCADA中的各个部件：
4.1 场站端-传感器设备按照检测参数主要分四大类：压力仪表、温度仪表、流量仪表、液位仪表
常用的压力测量仪表：1、弹簧管式压力表；2、远传压力测量仪表
常用的温度测量仪表：1、显示仪表：如：玻璃液体温度计、双金属温度计；2、远传仪表：热电偶、热电阻、半导体等组成的远传仪表。
常用的流量测量仪表：1、速度式流量计（如孔板、涡轮、超声波等）；2、容积式流量计：椭圆齿轮流量计、腰轮流量计、刮板流量计等。
常用的液位测量仪表：1、浮子式液位计；2、差压式液位计。
I/O传输信号
模拟量信号：模拟量信号是一种连续变化的物理量，如电流、电压、温度、压力、位移、速度等。
数字量信号：在SCADA系统中，数字信号有编码数字（二进制或十进制）、开关量、脉冲序列等。例如：工控中，要对这些模拟量进行采集并送给PLC，必须要先对模拟量进行模数（A/D）转换。
4.2 场站端-下位机SCADA的下位机侧重现场仪表数据的采集和控制，典型有：PLC、RTU。
下位机功能
1、采集：下位机配置的各种输入设备（DI、AI等）进行数据采集。
2、控制：下位机配置的各种输出设备（DO、AO等）对现场设备进行控制。下位机接收上位机的监控，并向上位机传输各种现场数据。
指各种智能节点，各自都有自己独立的系统软件和应用软件，该节点可具备数据采集、设备或过程的控制功能，并将状态信号转换为数字信号。下位机通过各种通信方式传递到上位机系统，并且接受上位机的监控指令。典型的下位机包括RTU、PLC、PAC、智能仪表等。
4.2.1 场站端-下位机-PLC可编程序控制器定名为Programmable Logic Controller（PLC）。 PLC的构成 :从结构上分，PLC分为固定式和组合式（模块式）两种。固定式PLC包括CPU板、I/O板、显示面板、内存块、电源等，这些元素组合成一个不可拆卸的整体。模块式PLC包括CPU模块、I/O模块、内存、电源模块、底板或机架，这些模块可以按照一定规则组合配置。可编程逻辑控制器实质是一种专用于工业控制的计算机，其硬件结构基本上与微型计算机相同，基本组成如下图所示，基本构成详细描述如下：
对于燃气行业的站控，PLC/RTU 设备应支持标准 modbus RTU 或 标准 modbus TCP、 DNP3.0。
常见的PLC品牌有：西门子（Siemens）、西斯耐特（Sixnet）、恩畅（N-tron）、科洛理思（Korenix）等等，在燃气场站，西斯耐特（Sixnet）价格优势使用的较多。
4.2.2 场站端-下位机-RTURTU是Remote Terminal Unit（远程测控终端）的缩写，是对分布距离远，生产单位分散的生产系统的一种数据采集与监视控制系统。
4.2.3 PLC和RTU的区别虽然RTU和PLC在工程编程、数据采集和控制等方面很相似，但它们之间还是有很大区别的。
PLC一般主要用于 在场站内进行数据汇总和指令处理，主要应用于在室内环境。
RTU最显著的特点是远方功能， 即它与调度中心之间通过远距离信息传输所完成的监控功能。RTU 通常要具有优良的通讯能力和更大的存储容量，适用于更恶劣的温度和湿度环境，提供更多的符合专有标准的计算功能。
因此，PLC 是为满足传统工厂基础自动化的发展需求而设计和研发。而 RTU 是对传统PLC 在远程和分布式应用的产品补充，更适用于现代化新兴行业的分散监控的需求。
具体的一些对比如下：
1.RTU一般不受地理环境限制，可在室外现场测量点附近安装，一个RTU可以就地控制几个、几十个或几百个I/O测量点，因而它的适应恶劣环境能力强。其工作温度一般在-40~85;防护等级高，可用于潜水艇工作;一个电池组供电工作时间有时长达数月。PLC一般主要用于厂站内工业流水线的控制，系室内安装。工作环境温度要求0--55，空气湿度应小于85%。超过温度55，要安装风扇通风，高于温度60，要安装风扇或冷风机降温。
2.由于RTU不受工作环境约束，故要求其技术规格符合恶劣环境要求和特定要求。它的数据存储量大，模拟量采集能力强(最多24路)，模拟功能远比PLC更强大。
3.RTU通信功能强大。由于RTU要将采集的模拟量、开关量、数字量信息最终传输给调度中心，而调度中心有时远隔千里之外，故要求它具有远程通讯功能。PLC虽然也有通讯功能，但仅限于厂站内部近距离传送数据，其通信功能与RTU相比稍逊一筹。
4.传统的RTU没有可编程运算功能，现在的RTU大都具备了可编程运算功能，还有PID控制功能或逻辑控制功能、流量累计功能等。由于是新兴技术，势必是较先进的技术。它具有梯形图和C语言编程，屏幕组态软件编程等技术，运算能力强，可带液晶显示，就地显示和控制。这一些都是PLC不能比拟的。
5.RTU与PLC使用功效也不尽相同。RTU具有远方功能、当地功能以及自检与自调功能。它与调度中心相距遥远，与调度中心计算机通过信道相连接;它的当地功能是指RTU通过自身或连接的显示、记录设备，就地实现对网络的监视和控制的能力;RTU的程序自恢复能力是指RTU在受到某种干扰影响而使程序“走飞”时，能够自行恢复正常运行的能力。PLC仅有当地功能。
4.3 上位机上位机：通常具有友好的人机界面，通过网络从各下位机中采集数据，实现远程监视、控制功能。上位机侧重监控功能。上位机在工业控制当中又被称为HMI，就是一台计算机，只不过它的作用是监控现场设备的运行状态，当现场设备出现问题在上位机上就能显示出各设备之间的状态（如正常、报警、故障等）。HMI本质上是一个用户控制站，通常以触摸屏或者带按钮的屏幕出现。
SCADA和上位机HMI经常傻傻的分不清：推荐看一下老外的这个视频“SCADA与HMI区别”。
SCADA系统是许多软件、硬件的组合，包括传感器、RTU或PLC，来自这些系统的数据被发送到中央SCADA单元。HMI可以是SCADA的一部分，但SCADA不能是HMI的一部分。
4.3.1 基于组态软件开发上位机组态，是英文configure翻译过来的，configure也解释为配置、设置，那么组态软件的意思也就是配置软件，而不是单独编写计算机程序。。
简单理解，组态软件是用来开发人机界面的软件。现场的设备PLC，各种采集卡，各种仪表，这些设备都能产生数据，电脑可以通过串口，以太网或者专门的通信线路来获取这些数据。但是这些数据通常是不适合人类直接阅读和理解的，所以需要一个人机界面来展示这些数据，而组态软件的功能就是转化和展示这些数据。
可以理解，就是组态就像搭积木，摆好各个块后，在配置他们之间的关系。
典型的数据流图：
4.3.1 常用的组态软件国外：
GE的IFIX
西门子的WinCC
国内：
三维力控
北京亚控
4.4 通信协议：Modbus协议工业控制下位机和上位机通信大部分采用的通信协议为Modbus。Modbus是一种串行通信协议，是Modicon公司（现在的施耐德电气Schneider Electric）于1979年为使用PLC）可编程逻辑控制器）通信而发表。Modbus已经成为工业领域通信协议的业界标准，并且现在是工业电子设备之间常用的连接方式。 Modbus比其他通信协议使用的更广泛的主要原因有：
1、开源免费
2、易于部署和维护
3、报文简单紧凑
Modbus允许多个 (大约240个) 设备连接在同一个网络上进行通信，举个例子，一个由测量温度和湿度的装置，并且将结果发送给计算机。在数据采集与监视控制系统（SCADA）中，Modbus通常用来连接监控计算机和远程终端控制系统（RTU）。
MODBUS是基于串口的一种协议，它可以基于RS232,RS422,也可以基于RS485，是当初MODICON公司定义的PLC与计算机，PLC间的传输协议。后来成为了国际标准。
Modbus协议版本
Modbus通信协议具有多个变种，Modbus协议目前存在用于串口、以太网以及其他支持互联网协议的网络的版本，其中最著名的是Modbus RTU,Modbus ASCII和Modbus TCP三种。在工业现场一般都是采用Modbus RTU协议，一般而言，大家说的基于串口通信的Modbus通信协议都是指Modbus RTU通信协议。与Modbus RTU协议相比较，Modbus TCP协议则是在RTU协议上加一个MBAP报文头，并且由于TCP是基于可靠连接的服务，RTU协议中的CRC校验码就不再需要，所以在Modbus TCP协议中是没有CRC校验码的，所以就常用一句比较通俗的话来说：Modbus TCP协议就是Modbus RTU协议在前面加上五个0以及一个6，然后去掉两个CRC校验码字节就OK。虽然这句话说得不是特别准确，但是也基本上把RTU与TCP之间的区别说得比较清楚了。
Modbus数据帧格式
Modbus协议是一个master/slave架构的协议。有一个节点是master节点，其他使用Modbus协议参与通信的节点是slave节点。每一个slave设备都有一个唯一的地址。MODBUS协议定义了一个与基础通信层无关的简单协议数据单元（PDU）。特定总线或网络上的MODBUS协议映射能够在应用数据单元（ADU）上引入一些附加域。
先来简单分析一条MODBUS-RTU报文，例如：01 06 00 01 00 17 98 04
从机地址 功能码 数据地址 数据 CRC校验
01 06 00 01 00 17 98 04
这一串数据的意思是：把数据 0x0017(十进制23) 写入 1号从机地址 0x0001数据地址。 先弄明白下面的东西。
1、报文
一个报文就是一帧数据，一个数据帧就一个报文： 指的是一串完整的指令数据，就像上面的一串数据。
2、CRC校验
意义：例如上面的 98 04 是它前面的数据（01 06 00 01 00 17）通过一算法（见附录2，很简单的）计算出来的结果，其实就像是计算累加和那样。（累加和：就是010600010017加起来的值，然后它的算法就是加法）。
作用：在数据传输过程中可能数据会发生错误，CRC检验 检测接收的数据是否正确。比如主机发出01 06 00 01 00 17 98 04，那么从机接收到后要根据01 06 00 01 00 17 再计算CRC校验值，从机判断自己计算出来的CRC校验是否与接收的CRC校验（98 04主机计算的）相等，如果不相等那么说明数据传输有错误这些数据不能要。
3、功能码
意义：modbus 定义。 作用：指示具体的操作。 最常用功能码：
下面“线圈”“寄存器”其实分别直的就是“位变量”“16位变量”
01 (0x01) 读线圈
02 (0x02) 读离散量输入
03 (0x03) 读保持寄存器
04(0x04) 读输入寄存器
05 (0x05) 写单个线圈
06 (0x06) 写单个寄存器
15 (0x0F) 写多个线圈
16 (0x10) 写多个寄存器
再一个示例： 读寄存器数据（此例中将当前积算仪显示的数据读出）
主站发送：
17 03 00 00 00 10 46F0
地址 功能码 起始地址 寄存器数目 CRC校验码
从站响应：
17 03 20 00 00 00 37 12 05 A0 43 00 00 00 37 12 05 A0 43
地址 功能码 接收字节数 工况累积量 标况累积量
00 01 CB 6B 00 01 CB 89 00 00 14 00 00 00 65 53 BA 18
工况流量 标况流量 温度 压力 校验码
原文来源：深入浅出谈SCADA_田攀的博客-CSDN博客
蚂蚁金服天街：OceanBase 在大促 5 年来的技术演进
为了与金融从业者、科技从业者共同探讨金融 + 业务的深层次问题，蚂蚁金服联手 TGO 鲲鹏会，在 12 月 8 日举办了「走进蚂蚁金服：双十一背后的蚂蚁金服技术支持」活动。蚂蚁金服高级技术专家天街为大家分享了《蚂蚁双 11 大促 OceanBase 核心技术全解析》。本文根据当天演讲整理，有部分不改变原意的删减。
天街现场演讲照片
今天给大家介绍一下 OceanBase 在大促 5 年来的技术演进，主要内容是 OceanBase 大促体系，下文简称 OB。今年 OB 大促上有三个核心技术：百万支付、容器化和平台智能化。
OB 大促主要做什么事情？大促就是把平常的能力在双 11 舞台上做最大的展示。大促的内容很多，落到技术层面就是整个体系的分析，我们可以把它抽象出六个能力：
容量。面对这种脉冲式的压力上升，我们可以从单机性能和集群性能量方面来考虑满足大促容量；可靠性。作为金融级公司，我们在峰值上要保持脉冲风险稳定可靠；成本。日常使用的机器与双 11 相比非常少，需要降低大促使用的机器成本；效率。大促是常态化的流程，一年之中会有很多大促，要用最高的效率来实现大促，这是成败的关键；抗压。用压测试保证各方面的系统满足双 11 的峰值；弹性。这是双 11 最核心的技术，需要把应用服务器、DB 各种计算能力都弹到一个新的单元上，利用这部分资源支撑大促，同时在大促之后快速还回来。上图是 OB 这几年在大促上的弹性化体系，分为四层：
1、基础设施。今年大促的基础设施是网络、存储计算的介质、底层与内核的交互、网络互联。
2、基础架构。这是底层对业务可见的基础部署，我们把业务放到容器里，上面是业务可见的架构，有独立的异构 FO 和同城三级房部署。为了弹性的效率，我们还做了多副本的架构，比如传统的主库、备库以及最近两年新加的日志节点。
3、能力沉淀。大促需要的能力和日常需要的能力相辅相成，如果日常就具备这样的能力，那么大促时就能从容应对。
4、大促服务。我们今年双 11 做了 4 万 + 的变更，实际上是通过 AutoScale 平台做的，同时我们也会结合稳定性的要求，比如变更三把斧，把这些能力做进去。
我们的三年战略是百万支付，经测算三年之内交付峰值将达到一百万。因为应用是无状态的，只要我们在整个系统上做到可扩容、可弹性，把机器加上去就可以解决。但是 DB 端不行，一份数据所能够使用的存储空间和很多东西相关，比如业务方的分表、单机的性能都有一定的瓶颈，百万支付落到 DB 端最核心的问题就是怎么解决最小的数据分片，解决资源规格异构和负载均衡偏差的资源问题。
这个图代表了当前支付宝架构的解决方案。右边 00 代表一个分片，全中国路由出来是 UID 的 00。支付事务跨多张表，每一张表对应的多个分片，我们会把它聚合在一起，代表一个实例或者租户，一个租户使用的最大资源是物理机的资源。如果想要把 00 继续拆分，就把 00 分片再取两位做哈希。对新的业务通过弹性规则，访问对应的库。这样业务改造的工作量很大，因为要加四个数据库，并且加了之后没有办法回收。而且伸缩是有损的，因为要缩小服务器资源必然涉及到大量数据的缩容，那么应用就会感知到。
基于这些，我们提出了 OB2.0。这个项目最大的价值是做到 OB 分区，就是可以把一个应用维度看成一个数据分片，可以在 DB 端做到无限度的 sharding。我们通过 Partition Group 的概念，把不同表格相同分区聚合到相同的机器，同时还把任意一个分片结合物理机的数目进行二次聚合，聚合成大的 Partition Group，根据 server 数的不同，自动把分片分到不同的机器上，这就是百万支付结合 OB2.0 的架构。
OB2.0 打造百万支付能力的优势：
弹性伸缩。分片可以无限 sharding，实现线性扩展，并且每一个分片都具备独立的扩展能力，可以满足多元化的弹性需求；业务无感无损。无感是指业务感觉不到 DB 的伸缩，外部公司如果想要做一个大促活动，不需要业务感知，直接由 DB 完成。无损是指整个弹性过程中业务不会有失败，因为这是通过我们的协议来实现的；极致高可用。通过灰度做到不同分片之间互相隔离，并且可低版本和高版本同时运行，如果一个分片一个星期没有问题，就可以自动对下一个版本进行处理；资源。我们可以把一个在高峰期占有很大资源的数据源拆成一个非常统一的资源粒度，它的好处就是可以很独立地做负载均衡。我们做容器化有两方面原因：第一，常态；第二，大促。
常态会面临什么样的问题？现在 DB 服务器有几万台，如果对资源进行深入统计，就会发现 DB 资源肯定是过剩的。DB 资源无非就是 CPU、IO、内存，一个数据库不可能这三类都占满。我们做一个简单的统计，大促时所有的服务器的瓶颈是 CPU，而日常的瓶颈是存储空间，绝对不会是 CPU。另外，业务状态注定存在高峰 / 低峰访问。资源负载分为长尾、碎片两类，我们需要把碎片收集起来再利用。资源分为绝对资源和相对资源，在不同业务间它们的比例差距很大，在现在的支付宝规模下使用的资源浪费很大。我们每年采用的机型都有很大的变化，现在 CPU 越来越多、内存越来越多，CPU 也有换代更新，所以针对异构的机型要把能力统一标准化，提供统一的服务能力。
而大促态的成本体现在哪里？第一，大促所需服务器总数；第二，持有服务器的时长。如果使用一千台服务器，持有一个月，资源开销远远大于持有两千台服务器五小时，这涉及到服务器运营。
这些问题就对 DB 提出了要求，DB 要有容器化的能力，目的是要调度 DB，把它放在我们想要的地方。
我们做的容器化主要有三点：
规格归一。分区是一种方案，还有一种方案是业务拆分，比如把一些明显不合理的长尾业务进行拆分，我们会把线上所有的 DB 顺序分为五个可以满足需求的规格，比如 2C8G、8C32G。我们做容器化的时候，只要是这五种规格就可以；资源隔离 / 抢占，这是一个重点，因为容器化的目的是保证系统的正常运行，不要因为成本丢弃系统的稳定性。这里有三大块：CPU、内存和 IO 通过 Cgroup 隔离，同时结合应用画像，比如根据这个业务过去三个月的增长情况、存储空间，做一个容器画像，打上业务属性的标签，比如关键点的地域信息、资源信息；多维调度，应用、机房、机架的调度。在 DB 层面，哪些租户放在一起最节省资源，这是从上到下贯穿整个资源载体的调度。这是 OB 大促容器化的架构。底层是通用的调度平台，要识别各种 IaaS，包括蚂蚁、金融云、阿里云、混合云。再往上是统一的调度层：一层是 sigma，主要做统一资源规划、资源生命周期、资源弹性、资源规划；二层调度层分为 kipp 和 OB，按照不同租户的画像信息，得出调度策略是平铺、抢占还是资源亲和（资源亲是指，单机不超过 1% 的容灾，通过资源亲和，把一笔支付链路上所能够经过所有的应用和 DB 统一调度在同一台机器上，通过一个亲和性标签放在一起，大大降低宕机的影响面）；右边是调度管控，包含水位、资源 Plan 和资源标签；最上层是容器化达到的价值，首先是资源利用率，第二是单机 1% 容灾，第三是无损压测，第四是存区 & 存储就近，让存储节点和计算节点两者离得最近、网络和 IO 离得最近。
为什么要做平台智能化？第一是大促常态化。往年支付宝只有两个活动：双 11、双 12，但是现在每个月都有三四个大促，大促的稳定性要求很高，那怎么把活动支持得更好呢？传统上是做简单的扩容，做一些预案，但现在会发现光做这些不够了，我建议通过智能化的手段解决。可以把流程抽出来，结合最小的集群智能化，两者有机结合实现根本目标。第二是随着业务规模爆发，怎么解决硬件存在的隐患，怎么解决 10w+ 机器操作系统从 6U 升级到 7U。第三是稳定性，我们要做到 5 个 9，换算出来也就是全年停服不能超过 60 分钟。要到达到这个目标，任何的应急措施都不能依赖于人，也不能通过指令触发，必须通过智能。
介绍一下 OB 在大促智能化上的实践，主要有两点：第一，自动扩缩容；第二，SQL 调优。我们首先会对链路信息和 DB 运行状态进行建模，从应用服务器中间件数据源清洗出来链路信息，从 CPU、IO 各方面对每一条链路的 DB 节点进行数据拟合，得到拟合线后，通过指标的输入，推测在这个压力下 DB 的水位会产生什么样的波动或者峰值，从而可以把每一个业务的容量信息、每一个租户信息刻划出来，结合调度做一些智能的 rebalance；第二是 SQL 调优，我们会监控每一条 SQL 的状态，比如这一条 SQL 的使用概率、任意资源的消耗情况，给出 SQL 调优的建议。
第三是压测的资源预测和垄断。如果预测在接下来三分钟之内内存会占满，就自动停止掉。如果预测到 RT 水位对于业务来说是超时的，就停止自动压测。
我们把稳定性做到 5 个 9，分成三个模块：第一，感知，我们会对各种 workload 建模，形成非常丰富的曲线，通过曲线得出模型归纳和预测变化；第二，决策，第一个方法是基于经验，形成每一个数，每一个数的子节点是上一个节点的原因分析，往下是它的根因；第二个方法是机器学习，这是自我认知的过程，我们会把这些经验做输入，通过演进和优化不断得出最佳的决策树；第三，执行器，我们会对上一层信息进行更新阶段，根据诊断得出需要执行的方案，比如需要调优、扩容、还是修复。
OB 结合大促场景下的未来规划主要有两个方面：
资源。资源是我们做大促的核心价值，用最小的资源解决用户最大的问题。第一，统一调度。不仅仅是 DB 端的统一调度，我们还要把用户服务器、各种机型、资源池全部打通，这样就有了更大的池子，技术可发挥的空间更大；第二，混合部署。统一部署之后会分池分布、分类混布；第三，分时复用。混布和分时复用的效率体现很明显，因为不需要做大促处理时候可以节省资源开销；
自治。第一是 OB 内核的自治，第二是平台化的自治。自治分为三块：
自愈，主要解决稳定性的问题，有硬件故障、流量无峰、软件异常类的垄断；自驾驶，集群容量、租户容量、集群升级等完全不需要人参与，实现无人职守；自调优，把线上流量全部抓下来，在线下库里对流量进行滚放，滚放出来的流量可以自编程核对、关联度分析，所有的线上场景都可以在线下进行演练。
