目前米姆采用人性化管理及制度综合管理相结合的方式让企业管理效率最大化，目前我公司的管理制度，涉及到安全、流程、认证等各方面，各种制度健全合理，包含部分岗位流程SOP、销售服务准则、职能认证规范及要求等十数种程序文件。从各种制度的执行情况来看，各种制度制定的有效合理，能够有效地给予生产进行指导和员工行为规范的约束

米姆核心目标：

米姆信息科技专注企业IT服务，技术创新驱动的企业服务专家，主要开展网络安全、信息化建设、公有云服务、私有云建设、中台开发、等保测评、DevOps构建&应用、K8s&容器云搭建、云MSP服务、自动化运维等业务。目前已经在全国服务了超千家企业。

    2021年5月份，多个集团公司遭受了sodinokibi勒索病毒，用户多地集团的终端陆续出现被感染的情况，该病毒导致客户部分业务中断无法正常使用。严重影响了用户的日常工作。在勒索信中提到攻击组织名称REvil，信中除了解密方式，攻击者还提到他将客户重要资料截图发在图片站点https://prnt.sc。

    勒索信提到“我们还从您的服务器下载了大量敏感数据，如果您不付款，我们将开始将您的文件上传到我们的公共博客"图片。通过威胁情报以及对最近2个月内的应急响应案例进行分析，在4月份，其他行业也同样遭受过该类攻击，sodinokibi勒索病毒是继承了GrandCarb的代码结构，然后进行升级勒索手段的方式进行勒索，根据情报该病毒已经席卷了部分知名厂商。

    网络安服团队根据最近的攻击行为分析，本次的攻击手段从原来的钓鱼邮件等方式演变为入侵客户主机后进行直接投放病毒文件的方式进行勒索，定义为APT式勒索软件。结合最近某大型行业的情况，大致判断为有APT攻击组织盯上某大型行业进行勒索攻击。

    如下是网络安服团队对本次病毒事件的具体分析及处置建议。

    Sodinokibi勒索病毒分析

    通过被勒索终端排查及样本提取中招主机，排查主机发现勒索样本broker.exe和样本加载脚本start.batstart.bat，在日志内容中发现攻击者从某主机（跳板机）上共享下载并执行勒索样本，该脚本放在组策略启动项中，实现开机关机等操作自启动。推测攻击者通过域控组策略下发勒索病毒加载脚本，从跳板机的共享上下载勒索病毒。broker.exe 式勒索病毒加密本体，采用了白切黑的方式有数字签名，可以实现部分杀软免杀。

    样本入口如下：

新人用户

拼团产品

【阿里云】【微消息队列MQTT】【升级通知】

升级窗口：

北京时间2020年10月12日 23:00 - 2020年10月13日 07:00

北京时间2020年10月14日 23:00 - 2020年10月15日 07:00

北京时间2020年10月19日 23:00 - 2020年10月20日 07:00

北京时间2020年10月21日 23:00 - 2020年10月22日 07:00

北京时间2020年10月26日 23:00 - 2020年10月27日 07:00

北京时间2020年10月28日 23:00 - 2020年10月29日 07:00

升级内容：所有地域的MQTT服务。

升级影响：

升级期间MQTT控制台和集群中每个服务节点可能出现秒级闪断（闪断时间和集群规模正相关），客户端应用需要设置自动重连，以免影响业务。

升级期间，消息发送可能会有少量失败，应用做好断连失败重试机制；同时可能会有消息延迟的现象。如需在控制台进行管理操作，请避开维护时间段。

给您带来的不便敬请谅解，有任何问题，可随时通过工单联系反馈。

【阿里云】【消息服务MNS】【升级通知】
升级窗口：

北京时间2020年10月15日 00:00 - 06:00

北京时间2020年10月22日 00:00 - 06:00

北京时间2020年10月29日 00:00 - 06:00

升级内容：华北1（青岛）、华北2（北京）、华北3（张家口）、华北5（呼和浩特）、华东1（杭州）、华东2（上海）、华南1（深圳）、华东2金融云、华南1金融云、华北2政务云、香港、亚太东南1（新加坡）、亚太东南2（悉尼）、亚太东南5（雅加达）、亚太南部1（孟买）、中东东部1（迪拜）、欧洲中部1（法兰克福）、美国东部1（弗吉尼亚）、美国西部1（硅谷）、英国（伦敦）等地域的消息服务升级。
升级影响：升级期间MNS相关服务及控制台访问可能会出现闪断或者拒绝连接现象，每次闪断或拒绝连接不会超过1分钟，请在客户端中做好重连重试机制。如需在控制台进行管理操作，请避开维护时间段。

给您带来的不便敬请谅解，有任何问题，可随时通过工单或服务电话95187联系反馈。

【阿里云】【消息队列AMQP】【升级通知】

升级窗口：（已更新）北京时间2020年10月21日 00:00 - 03:00
升级内容：华北1（青岛）、华北2（北京）、华北3（张家口）、华北5（呼和浩特）、华东1（杭州）、华东2（上海）、华南1（深圳）、香港等全部地域（及铂金版）的服务升级。
升级影响：升级期间消息队列AMQP相关服务访问可能会出现多次闪断或者拒绝连接现象，每次闪断或拒绝连接不会超过 5 分钟，请在客户端中做好重连重试机制。如需在控制台进行管理操作，请避开维护时间段。

给您带来的不便敬请谅解，有任何问题，可点击联系我们进行咨询反馈。

【阿里云】【域名】【注册局维护通知】

维护时间：北京时间2020年10月17日 08:00 - 22:00

维护内容：接到注册局的通知，注册局将于上述时间对后台系统进行维护升级。

维护影响：届时 .cn/.中国 域名的注册、续费、信息修改和查询域名注册信息等操作，将会无法使用，在此期间会对您造成的影响如下：

1、您提交的域名注册、续费、转入、赎回、一口价域名购买等业务在支付费用后状态为“处理中”，待维护结束后将变为相应的处理结果和状态。

2、维护过程中，您无法对域名注册信息进行修改，将提示修改失败。

3、维护过程中，您无法下载相关域名的域名证书，将提示下载失败。

4、维护过程中，.cn/.中国域名实名认证不能正常提交至注册局，将为“审核中”状态，待维护结束后按顺序提交。

如果您需要注册或管理以上业务操作，建议您避开该时间段，以免给您的业务造成影响。

由此给您带来的不便，我们表示歉意，敬请谅解。

【阿里云】【Datahub】【产品稳定性升级】

升级窗口：北京时间2020年10月21日 10:00 - 19:00

升级内容：

1. 公有云HTTPS证书更新

2. 版本统一升级到2.18版本

升级区域：华北，华东，华南，新加坡，吉隆坡，孟买，德国

升级影响：在升级过程中，有服务短暂抖动重试，属于正常现象，其他如有任何问题，可点击联系我们进行咨询反馈。

给您带来的不便敬请谅解。

2020年10月13日，阿里云应急响应中心监测到Apache Solr发布安全更新，其中修复了CVE-2020-13957 Apache Solr configset upload文件上传漏洞。攻击者通过构造特定的请求，成功利用该漏洞可直接获取服务器权限。

漏洞描述

Apache Solr是一个开源的搜索服务，使用Java语言开发。Apache Solr Configset Api上传功能存在未授权漏洞。在特定条件下，攻击者可以构造特定请求，上传相关恶意文件，从而直接获取到服务器权限。阿里云应急响应中心提醒Solr用户尽快采取安全措施阻止漏洞攻击。

影响版本

Apache Solr 6.6.0 - 6.6.5

Apache Solr 7.0.0 - 7.7.3

Apache Solr 8.0.0 - 8.6.2

安全版本

Apache Solr 8.6.3

安全建议

1. 升级至安全版本

2. 如果未使用ConfigSets API，请禁用UPLOAD命令，将系统属性： configset.upload.enabled 为 false ，可参考官方文档：https://lucene.apache.org/solr/guide/8_6/configsets-api.html。

3. 增加身份验证/授权，可参考官方文档：https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html

4. 使用在SOLR-14663中提到的补丁程序：https://issues.apache.org/jira/browse/SOLR-146634。

5. 禁止Solr API 以及管理 UI 直接对公网开放。设置防火墙，以便只允许受信任的计算机和人员访问。

相关链接

https://issues.apache.org/jira/browse/SOLR-14925

https://issues.apache.org/jira/browse/SOLR-14663

阿里云云安全中心应急漏洞模块已支持对该漏洞一键检测

阿里云云防火墙已可防御此漏洞攻击

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.13

2020年10月13日，阿里云应急响应中心监测到微软发布补丁修复了TCP/IP远程执行代码漏洞（CVE-2020-16898），官方评级严重。目前微软官方已提供相应的月度安全补丁以修复该漏洞。

漏洞描述

微软官方于10月13日发布安全更新，其中修复了一个TCP/IP远程执行代码漏洞（CVE-2020-16898），攻击者通过构造并发送恶意的ICMPv6（路由通告）数据包，从而控制目标主机。同时，微软10月补丁中还涉及其他多个高危漏洞，阿里云应急响应中心提醒 Windows 用户尽快安装补丁阻止漏洞攻击。

漏洞评级

CVE-2020-16898 严重

影响版本

Windows Server 2019

Windows Server 2019 (Server Core installation)

Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

Windows Server, version 2004 (Server Core installation)

安全建议

1、前往微软官方下载相应补丁进行更新：https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898

2、阿里云云安全中心Windows系统漏洞模块已支持对该漏洞补丁一键检测和修复，详情登陆云安全中心

Windows Server 2019 补丁：KB4577668

3、可以通过禁用ICMPv6 RDNSS来缓解风险。

使用以下PowerShell命令禁用ICMPv6 RDNSS，以防止攻击者利用此漏洞。此解决方法仅适用于Windows 1709及更高版本。

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

注意：进行更改后，无需重新启动。

可以使用以下PowerShell命令禁用上述缓解方法。

netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=enable

注意：禁用替代方法后，无需重新启动。

相关链接

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.13

2020年10月14日，阿里云应急响应中心监测到VMware vCenter特定版本存在任意文件读取漏洞，攻击者通过构造特定的请求，可以读取服务器上任意文件。

漏洞描述

VMware vCenter 服务器是一种高级服务器管理软件，提供一个用于控制 VMware vSphere 环境的集中式平台。VMware vCenter特定版本存在任意文件读取漏洞，攻击者通过构造特定的请求，可以读取服务器上任意文件。阿里云应急响应中心提醒VMware vCenter用户尽快采取安全措施阻止漏洞攻击。

已知影响版本

VMware vCenter 6.5.0a-f

安全版本

VMware vCenter 6.5u1

安全建议

升级至安全版本

相关链接

https://www.vmware.com/products/vcenter-server.html

阿里云云安全中心应急漏洞模块已支持对该漏洞一键检测

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.14

2020年10月15日，阿里云应急响应中心监测到 sonatype官方 发布了 Nexus Repository Manger 2&3 Shiro验证绕过漏洞。

漏洞描述

Sonatype Nexus Repository 是一个开源的仓库管理系统，在安装、配置、使用简单的基础上提供了更加丰富的功能。近日Sonatype官方发布安全公告披露了在Nexus Repository Manager 2 & 3 版本中使用了旧版本的Shiro组件，存在权限绕过漏洞。攻击者可利用该权限绕过漏洞访问到后台功能，并可能导致命令执行。阿里云应急响应中心提醒Nexus Repository Manager 2&3用户尽快采取安全措施阻止漏洞攻击。

影响版本

Nexus Repository Manager OSS/Pro version 2.x < 2.14.19

Nexus Repository Manager OSS/Pro version 3.x < 3.27.0

安全版本

Nexus Repository Manager 2 versions 2.14.19

Nexus Repository Manager 3 versions 3.27.0

安全建议

1. 升级至安全版本

2. 该漏洞检测请参考 【漏洞预警】Apache Shiro < 1.6.0 权限绕过漏洞（CVE-2020-13933）

相关链接

https://support.sonatype.com/hc/en-us/articles/360053556313-CVE-2020-13933-Nexus-Repository-Manger-2-3-Shiro-Authentication-Bypass

阿里云云安全中心应急漏洞模块已支持对该漏洞一键检测

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.15

2020年10月19日，阿里云应急响应中心监测到 Adobe官方发布了 CVE-2020-24407 Magento 远程代码执行漏洞通告。

漏洞描述

Magento是一套专业开源的电子商务系统。近日Adobe官方发布安全公告披露了在 Magento Commerce/Open Source 2.3以及2.4版本中存在CVE-2020-24407远程代码执行、CVE-2020-24400 SQL注入等多个漏洞。在具有管理特权的情况下，攻击者可构造恶意请求，绕过文件上传限制，从而造成远程代码执行，控制服务器。阿里云应急响应中心提醒Magento用户尽快采取安全措施阻止漏洞攻击。

影响版本

Magento Commerce/Open Source <= 2.3.5-p2

Magento Commerce/Open Source <= 2.4.0

Magento Commerce/Open Source <= 2.3.5-p1

安全版本

Magento Commerce/Open Source 2.4.1

Magento Commerce/Open Source 2.3.6

安全建议

升级至安全版本

相关链接

https://helpx.adobe.com/security/products/magento/apsb20-59.html

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.19

2020年10月20日，阿里云应急响应中心监测到 Apache Kylin官方修复 CVE-2020-13937 API未授权访问漏洞。

漏洞描述

Apache Kylin™是一个开源的、分布式的分析型数据仓库。近日Apache Kylin官方修复 CVE-2020-13937 API未授权访问漏洞。攻击者可构造恶意请求，访问API地址，可以获取Apache Kylin的相关配置信息，从而导致身份凭证等信息泄漏。阿里云应急响应中心提醒 Apache Kylin 用户尽快采取安全措施阻止漏洞攻击。

影响版本

Kylin 2.x.x

Kylin <= 3.1.0

Kylin 4.0.0-alpha

安全版本

Kylin 3.1.1

安全建议

升级至安全版本

相关链接

https://www.mail-archive.com/dev@kylin.apache.org/msg12170.html

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单或服务电话95187联系反馈。

阿里云应急响应中心

2020.10.20

我们一直在讲，通过路由传达到控制器，处理好数据并渲染到视图，但是对于现代的应用，
前后端分离的情况下，后端写个接口就完事儿了。

本期为大家说一说用laravel写restful风格的API，看看能有多简单。

以路由开端

写API接口，与传统的渲染前端模板页面有什么区别？少了视图，只需要准备好数据，
并按照规则格式化，返回就可以了。

laravel默认的api接口路由在 routes/api.php 文件内定义，默认的情况下预定义了一个资源类型的api接口，代码如下：

Route::middleware('auth:api')->get('/user', function (Request $request) {
    return $request->user();
});

调用了 auth:api 中间件用于验证用户的授权，如果授权通过，声明的get方法获取用户的信息，并返回 User 模型。这在之前的章节是很常见的操作，我们不做赘述了。

那么这个路由文件，是什么时候加载上去的呢？在文件 app/Providers/RouteServiceProvider.php 内，看这样一段：

protected function mapApiRoutes()
{
    Route::prefix('api')
        ->middleware('api')
        ->namespace($this->namespace)
        ->group(base_path('routes/api.php'));
}

该服务提供者声明路由使用 api 字符前缀，并调用 api 中间件，该中间件定义在 app/Http/Kernel.php 文件内：

protected $middlewareGroups = [
    'api' => [
        'throttle:60,1',
        IlluminateRoutingMiddlewareSubstituteBindings::class,
    ],
];

至于命名空间 $this->namespace 一般返回 AppHttpControllers，我们为了区分API与其他应用，在目录 app/Http/Controller 下创建 API 目录，用于存储所有API相关的控制器。

那么上述的 RouteServiceProvider.php 文件内 mapApiRoutes 方法内的 namespace 需要这样写：

->namespace($this->namespace . 'API')

仍然以 Event 模型作为示例，在 routes/api.php 文件内声明一个资源类型的路由：

Route::resource('/events', 'APIEventsController');

注意命名空间上多出来的前缀 API ，这说明我们是把 EventController 文件放在了 API 目录下。

用户权限

让我们把目光还聚焦在系统默认声明的那条路由：

Route::middleware('auth:api')->get('/user', function (Request $request) {
    return $request->user();
});

注意中间件 auth:api，因为api请求是无状态的，每次请求之间没有任何关联，所以使用用户权限区分资源的返回。那么我们怎么拿到用户授权呢？这在 config/auth.php 文件内定义，看系统自带的这一段配置代码：

'guards' => [
    'api' => [
        'driver' => 'token',
        'provider' => 'users',
        'hash' => false,
    ],
],

这一段定义了我们使用何种方式认证用户的身份。默认的驱动 token 定义在框架文件 laravel/framework/src/Illuminate/Auth/TokenGuard.php 内。长话短说，默认构造类传入的字段如下：

UserProvider $provider,
Request $request,
$inputKey = 'api_token',
$storageKey = 'api_token',
$hash = false

简单说，就是使用 users 表的 api_token 字段用户鉴权。那么默认我们 users 表显然缺少一个这样的字段，现在使用迁移文件补上：

php artisan make:migration add_api_token_field_to_users_table --table=users

首先是迁移方法 up 函数：

public function up()
{
    Schema::table('users', function (Blueprint $table) {
        $table->string('api_token', 60)->unique();
    });
}

还有回滚使用的 down 方法：

public function down()
{
    Schema::table('users', function (Blueprint $table) {
        $table->dropColumn('api_token');
    });
}

这些都是常规操作，我们在之前的章节，使用了N多次了。执行指令迁移数据库：

php artisan migrate

看看效果

准备好了路由，而且路由内声明了一个get方法返回用户模型数据。也准备好了数据库表字段 api_token。我们在数据库表内找到一个用户数据，把api_token值设置为 1234，用于测试。

现在在浏览器内请求类似如下的url地址：

http://www.example.com/api/user?api_token=1234

如无异常，顺利会输出一个 json 字符串，

{
    "id":1,
    "provider":null,
    "provider_id":null,
    "first_name":"Tom",
    "last_name":"Hanks",
    "email":"tom@admin.com",
    "city":"",
    "state_id":null,
    "zip":"43016",
    "lat":null,"lng":null,
    "timezone":"America/New_York",
    "title":"Laravel Developer",
    "created_at":"2020-10-14 17:46:19",
    "updated_at":"2020-10-14 17:46:20",
    "last_login_at":null,
    "is_admin":0,
    "api_token":"1234"
}

这个json格式的数据是怎么来的呢？是在路由内，$request->user() 方法返回的User模型，使用 toArray() 格式化方法获得的。为了演示，很多字段与实际可能有所出入。

特别需要注意的是，关键的密码字段，以及 token 字段，是默认隐藏的，这得益于 User 模型内 $hiden 属性的定义：

protected $hidden = [
    'password', 'remember_token',
];

这些字段都对对外不公开访问。

写在最后

本文介绍了如何声明api地址，已经解释了api从中间件到路由的由来，明白了api授权的方式，可以为我们更灵活地定制授权方式提供便利。这在laravel内都是可插拔的，替换为我们的逻辑代码就可以愉快工作了。

Happy coding :-)

我是@程序员小助手，专注编程知识，圈子动态的IT领域原创作者

作者 | 张建飞  阿里巴巴高级技术专家

导读：针对业务在不同场景下的差异，我们常常会习惯性地使用 if-else 来实现不同的业务逻辑，久而久之代码越来越难以维护。那么如何消除这些 if-else？面对复杂业务应如何思考和分析？本文分享阿里高级技术专家张建飞（Frank）关于复杂业务治理的方法论，介绍一种多维度分析问题的方法：矩阵分析法。

You should not be a if-else coder, should be a complexity conquer. 
——Frank

这篇文章，是对之前我在《阿里高级技术专家方法论：如何写复杂业务代码？》说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我们缺少一个多维度看问题的视角，这种维度思维的缺失，可能会导致 miss 掉一些重要的业务信息，从而使我们制定软件设计策略的时候，陷入困难。

有了维度思维，我们便可以更加方面的去看清业务的全貌，更加全面的掌握业务信息，从而帮助我们更加体系化的去治理复杂性。

从 if-else 说起

我经常说，我们不要做一个 if-else coder。这里的 if-else，不是说我们在 coding 的时候不能使用 if-else，而是说我们不应该简陋地用 if-else 去实现业务的分支流程，因为这样随意的代码堆砌很容易堆出一座座“屎山”。

业务的差异性是 if-else 的根源。以零售通的商品业务为例。不同的处理场景，其业务逻辑实现是有差异性的。如下图所示，商品业务的差异性，主要体现在商品类型、销售方式和仓储方式的不同。

这三个维度上的差异组合起来，有 2 3 2 = 12 之多。这就是为什么在老代码中，到处可以看到 if(组合品) blabla，if(赠品) blabla，if(实仓) blabla 之类的代码。

那么，要如何消除这些讨厌的 if-else 呢？我们可以考虑以下两种方式：

• 多态扩展：利用面向对象的多态特性，实现代码的复用和扩展。
• 代码分离：对不同的场景，使用不同的流程代码实现。这样很清晰，但是可维护性不好。

1. 多态扩展

多态扩展可以有继承和组合两种方式。继承勿用多言，组合有点像策略模式，也就是把需要扩展的部分封装、抽象成需要被组合的对象，然后对其进行扩展，比如星环的能力扩展点就是这种方式。

这里，我们举一个继承的例子，商品在上架的时候要检查商品的状态是否可售，普通商品（Item）检查自己就好了，而组合商品（CombineItem）需要检查每一个子商品。

用过程式编码的方式，很容易就能写出如下的代码：

public void checkSellable(Item item){
    if (item.isNormal()){
        item.isSellable(); 
        //省略异常处理
    }
    else{
        List<Item> childItems = getChildItems();
        childItems.forEach(childItem -> childItem.isSellable()); 
        //省略异常处理
    }
}

然而，这个实现不优雅，不满足 OCP，也缺少业务语义显性化的表达。更好的做法是，我们可以把 CombineItem 和 Item 的关系通过模型显性化的表达出来。

这样一来，一方面模型正确的反应了实体关系，更清晰了。另一方面，我们可以利用多态来处理CombineItem和Item的差异，扩展性更好。重构后，代码会变成：

public void checkSellable(Item item){
    if (!item.isSellable()){
        throw new BizException("商品的状态不可售，不能上架");
    }
}

2. 代码分离

所谓的代码分离是指，对于不同的业务场景，我们用不同的编排代码将他们分开。以商品上架为例，我们可以这样写：

/**
* 1. 普通商品上架
*/
public void itemOnSale(){
    checkItemStock();//检查库存
    checkItemSellable();//检查可售状态
    checkItemPurchaseLimit();//检查限购
    checkItemFreight();//检查运费
    checkItemCommission();//检查佣金
    checkItemActivityConflict();//检查活动冲突

    generateCspuGroupNo();//生成单品组号
    publishItem();//发布商品
}

/**
* 2. 组合商品上架
*/
public void combineItemOnSale(){
    checkCombineItemStock();//检查库存
    checkCombineItemSellable();//检查可售状态
    checkCombineItemPurchaseLimit();//检查限购
    checkCombineItemFreight();//检查运费
    checkCombineItemCommission();//检查佣金
    checkCombineItemActivityConflict();//检查活动冲突

    generateCspuGroupNo();//生成单品组号
    publishCombineItem();//发布商品
}

/**
* 3. 赠品上架
*/
public void giftItemOnSale(){
    checkGiftItemSellable();//检查可售状态
    publishGiftItem();//发布商品
}

这种方式，当然也可以消除 if-else，彼此独立，也还清晰。但复用性是个问题。

3. 多维分析

细心的你可能已经发现了，在上面的案例中，普通商品和组合商品的业务流程基本是一样的。如果采用两套编排代码，有点冗余，这种重复将不利于后期代码的维护，会出现散弹式修改（一个业务逻辑要修改多处）的问题。

一个极端情况是，假如普通商品和组合商品，只有 checkSellable() 不一样，其它都一样。那毫无疑问，我们使用有多态（继承关系）的 CombineItem 和 Item 来处理差异，会更加合适。

而赠品上架的情况恰恰相反，它和其他商品的上架流程差异很大。反而不适合和他们合用一套流程代码，因为这样反而会增加他人的理解成本。还不如单独起一个流程来的清晰。

那么，问题来了，我们什么时候要用多态来处理差异，什么时候要用代码分离来处理差异呢？

接下来，是我今天要给你着重介绍的多维度分析问题的方法论之一：矩阵分析法。

我们可以弄一个矩阵，纵列代表业务场景，横列代表业务动作，里面的内容代表在这个业务场景下的业务动作的详细业务流程。对于我们的商品业务，我们可以得到如下的矩阵：

通过上面的矩阵分析，我们不难看出普通品和组合品可以复用同一套流程编排代码，而赠品和出清品的业务相对简单，更适合有一套独立的编排代码，这样的代码结构会更容易理解。

维度思维

1. 多维度的重要性

上面的案例不是我编造出来的，而是我在和张文（我同事）讨论应该用哪种方式去处理业务差异的真实故事。

我记得在和大学讨论完，开车回去的路上，我一直在想这个问题，然后在第二个路口等红灯的时候，突然有一个灵感冒出来。我抑制不住兴奋，一边开车，一边发消息给张文说：“我想到了一个很 NB 的方法论，能解决在‘多态扩展’和‘代码分离’之间如何做选择的问题”。

其实，我知道我兴奋的不仅仅是解决了这个问题。我兴奋的是，我第一次真正领悟到了多维度思考的重要性。从而有机会从一个“单维度”生物，升级成一个“多维度”思考者。妈妈再也不用担心我被“降维打击”了 :)

结构化思维有用、很有用、非常有用，只是它更多关注的是单向维度的事情。比如我要拆解业务流程，我要分解老板给我的工作安排，我要梳理测试用例，都是单向维度的。

而复杂性，通常不仅仅是一个维度上的复杂，而是在多个维度上的交叉复杂性。当问题涉及的要素比较多，彼此关联关系很复杂的时候，两个维度肯定会比一个维度要来的清晰，这也是为什么说矩阵思维是比结构化思维更高层次的思维方式。

实际上，我们从汉语的词汇上，也不难看出一个人的思维层级，是和他的思考维度正相关的。当我们说这个人很“轴”、“一根筋”的时候，实际上是在说他只有一维的线性思维。所以，观察事物的视角越多，维度越丰富，其思维层级也会越高。

2. 无处不在的多维思考

有了这些感悟，我开始系统的整理关于多维度思考分析的资料，发现这种思考方式真是无处不在。发现的越多，我越是感慨，为什么如此重要的思维方式，我到现在才领悟到。

1）波士顿矩阵

比如，在做产品分析的时候，有对产品发展前景进行分析的波士顿矩阵。

2）订单要素分析

当年，我在 1688 做交易下单业务的时候，有非常多的下单场景，每种场景下，买家享受的权益是不一样的（如下表所示）。我们当时也是使用了矩阵去表达这个复杂的关系，只是当时还没有想到要将其提升到方法论的高度。

3）数据交叉分析

在数据分析中，维度分析是非常重要的，特别是维度很多的时候，我们可以通过皮尔逊积矩相关系数，做交叉分析，从而弥补独立维度分析没法发现的一些问题。

简单相关系数矩阵

4）分析矩阵

最近我碰巧看到 Alan Shalloway 写的《设计模式解析：Design Patterns Explained》，这是一本非常经典的关于 OOP 的书，里面的第十六章就是专门讲“分析矩阵”的，作者创造这个方法论的初衷也是因为业务涉及的要素太多，信息量太大，他需要一种组织海量数据的新方式。

我和 Alan 的路径不一样，但是都得出了同样的结论。由此可见，这种矩阵分析的方式的确是对复杂业务进行分析的一把利器，业务场景越多，交叉关系越是复杂，越需要这样的分析。

5）组织阵型

生产关系决定生产力，对于一个管理者来说，如何有效的设置组织结构是决定团队是否能高效协作的关键。所以我们可以看到公司里面，每年都有比较大的关于组织结构和人员安排的调整。

对于技术团队来说，我们习惯于按领域划分工作范围，这样做的好处是责任到人、职责清晰。然而，领域只是一个维度，我们工作通常都是以项目的形式的开展，而项目通常是贯穿多个领域的。所以，在做团队组织规划的时候，我们可以通过业务领域和业务项目两个维度去看。

比如，在我负责的商品团队，我会按照如下的形式去做职责划分。

6）时间维度

除了工作，生活中也到处可见多维思考的重要性。

比如，我们说浪费可耻，应该把盘子舔的很干净，岂不知加上时间维度之后，你当前的舔盘，后面可能要耗费更多的资源和精力去减肥，反而会造成更大的浪费。

我们说代码写的丑陋，是因为要“快速”支撑业务，加上时间维度之后，这种临时的妥协，换来的是意想不到的 bug，线上故障，以及无止尽的 996。

7）RFM 模型

简单的思考是“点”状的，比如舔盘、代码堆砌就是当下的“点”；好一点的思考是“线”状，加上时间线之后，不难看出“点”是有问题的；再全面一些的思考是“面”（二维）；更体系化的思考是“体”（三维）；比如，RFM 模型就是一个很不错的三维模型。可惜的是，在表达上，我们人类只能在二维的空间里去模拟三维，否则四维可能会更加有用。

复杂业务治理总结

在前言部分，我已经说过了，多维分析是对之前方法论的升级。加上以前的方法论，完整的方法论应该是“业务理解-->领域建模-->流程分解-->多维分析”。

为了方便大家理解，下面我把这些方法论做一个简单的串联和解释。

1. 业务理解

理解业务是所有工作的起点。首先，我们要找到业务的核心要素，理解核心概念，梳理业务流程。

比如，在零售通的商品域，我们要知道什么是商品（Item），什么是单品（CSPU），什么是组合品（CombineItem）。在下单域，我们要知道订单（order）的构成要素是商品、优惠、支付。在 CRM 领域，我们要理解客户、机会、联系人、Leads 等等。

这里，我想再次强调下语言的重要性，语言是我们思考的载体，就像维特根斯坦说的：“凡是能够说的事情，都能够说清楚”。

你不应该放过任何一个模糊的业务概念，一定要透彻的理解它，并给与合理的命名（Ubiquitous Language）。唯有如此，我们才能更加清晰的理解业务，才能更好的开展后续的工作。

2. 领域建模

在软件设计中，模型是指实体，以及实体之间的联系，这里需要我们具备良好的抽象能力。能够透过庞杂的表象，找到事务的本质核心。

再复杂的业务领域，其核心概念都不应该太复杂，抓住了核心，我们就抓住了主线，业务往往都是围绕着这些核心实体展开的。

比如，商品域虽然很复杂，但其核心的领域模型，无外乎就如下图所示：

3. 流程分解

关于流程分解，在《阿里高级技术专家方法论：如何写复杂业务代码？》里面已经有非常详细的阐述，这里就不赘述了。

简单来说，流程分解就是对业务过程进行详细的分解，使用结构化的方法论（先演绎、后归纳），最后形成一个金字塔结构。

比如，在商品领域，有创建商品、商品上架、上架审核、商品下架、下架审核、修改商品、删除商品等一些列动作（流程），每个动作的背后都有非常复杂的业务逻辑。我们需要对这些流程进行详细的梳理，然后按步骤进行分解。最后形成一个如下的金字塔结构：

4. 多维分析

关于多维分析，我以二维的矩阵分析为例，我想我前面应该已经说清楚了。

业务的复杂性主要体现在流程的复杂性和多维度要素相互关联、依赖关系上，结构化思维可以帮我们梳理流程，而矩阵思维可以帮忙我们梳理、呈现多维度关联、依赖关系。二者结合，可以更加全面的展现复杂业务的全貌。从而让我们的治理可以有的放矢、有章可循。

既然是方法论，在这里，我会尝试给出一个矩阵分析的框架。试想下，如果我们的业务很简单，只有一个业务场景，没有分支流程。我们的系统不会太复杂。之所以复杂，是因为各种业务场景互相叠加、依赖、影响。

因此，我们在做矩阵分析的时候，纵轴可以选择使用业务场景，横轴是备选维度，可以是受场景影响的业务流程（如文章中的商品流程矩阵图），也可以是受场景影响的业务属性（如文章中的订单组成要素矩阵图），或者任何其它不同性质的“东西”。

通过矩阵图，可以清晰的展现不同场景下，业务的差异性。基于此，我们可以定制满足差异性的最佳实现策略，可能是多态扩展，可能是分离的代码，也可能是其它。

这就是矩阵分析的要义，其本质是一种多维度思考的方法论。

篇后寄语

最后，我想说世界是熵增的（即万物都在缓慢的分崩离析），控制复杂度是我们这些从业者无法推卸的责任和使命。

软件行业的发展才几十年，还是一门年轻的学科，软件工程就像一个刚学会走路的小孩，还很不成熟，有时还很幼稚。

但毕竟还是有几十年的沉淀，还是有一些好的方法和实践可以参考，我的这些总结沉淀只是在前人的基础上，多走了一点点而已。但就是这一点点，也实属来自不易，其中冷暖，只有自己能体会。可以说，这一路走来，是一场对心力、脑力和体力的持续考验。

• 心力是指不将就的匠心，不妥协的决心，不满足的好奇心、以及不放弃的恒心。
• 脑力是指那些必要的思维能力、学习能力、思考能力、思辨能力。
• 之所以说“业务理解-->领域建模-->流程分解-->多维分析”是体力，是因为实现它们就像是在做填空题，只要你愿意花时间，再复杂的业务都可以按部就班的清晰起来。

梳理清晰了，再配合 COLA（https://start.aliyun.com/）的指导，我们就有可能写出清晰、易读的代码，就有可能从一个 if-else coder 升级为一个 complexity conquer。

而这不正是我们工程师孜孜不倦的追求吗?

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

Redis读写分离实例的原理是：key统一写入到master，然后通过主从复制同步到slave，用户的请求通过proxy做判断，如果是写请求，转发到master；如果是读请求，分散转发到slave，这种架构适合读请求数量远大于写请求数量的业务，读写分离架构示意图如下所示。

阿里云Redis读写分离版读写命令转发示例

bitfield命令

经过和客户沟通查看后，客户使用了大量的bitfield做读取，首先介绍一下这个命令的用法和场景，bitfield 是针对bitmap数据类型操作的命令，bitmap通常被用来在极小空间消耗下通过位的运算（AND/OR/XOR/NOT）实现对状态的判断，常见的使用场景例如：

• 通过bitmap来记录用户每天应用登录状态，即如果$ID用户登录，就SETBIT logins:20200404 $ID 1，表示用户$ID在20200404这一天登录了，通过BITCOUNT logins:20200404可以得到这一天所有登录过的用户数量；通过对两天的记录求AND，可以判断哪个用户连续两天登录了，即BITOP AND logins:20200404-05 logins:20200404 logins:20200404。
  判断用户是否阅读了共同的文章，观看了共同的视频等。

前一阵子，答题领奖活动非常火爆，“答对12道题的同学有机会瓜分奖池”，这种如果使用bitmap来实现，就非常容易判断出用户是否全部答对。

一个使用Redis BITMAP设计的答题游戏系统

答题系统设计如：

• 每个用户每轮答题，设置一个key，比如user1在第一轮答题的key是 round:1:user1
  每答对一道题，设置相关的bit为1，比如user1答对了第5题，那么就设置第5个bit为1就可以了，如： SETBIT round:1:user1 5 1 ；如果用户1在第一轮答对了第9题，那么就把第9个bit设置为1，SETBIT round:1:user1 9 1；值得注意的是，bitfield默认bit都是0，答错可以不设置

计算用户总共答对了几道题，就可以使用 BITCOUNT 命令统计1的bit个数。如user1答对了3道题，user2在第一轮全部答对，那么user2就有机会参与答题（第1轮）的后续玩法

可见，Redis的bitmap接口可以用非常高的存储效率和计算加速效果。回到bitfiled命令，它的语法如下所示：

BITFIELD key  
[GET type offset] // 获取指定位的值
[SET type offset value] // 设置指定位的值
[INCRBY type offset increment] // 增加指定位的值
[OVERFLOW WRAP|SAT|FAIL] // 控制INCR的界限

读写分离实例处理bitfield的问题

从上文可知，bitfield的子命令中，GET命令是读属性，SET/INCRBY命令为写属性，因此Redis将其归类为写属性，从而只能被转发到master实例，如下图所示为bitfield的路由情况。

这就是为什么客户使用了读写分离版，而只有master节点cpu使用高，其余slave节点却没有收到这个命令的打散的原因。

解决方案

• 方案一：改造Redis内核，将bitfield命令属性标记为读属性，但是当其包含SET/INCRBY等写属性的子命令时候，仍旧将其同步到slave等。此方案优点是外部组件（proxy和客户端）不需要做修改，缺点是需要对bitfiled命令做特殊处理，破坏引擎命令统一处理的一致性。
  方案二：增加bitfield_ro命令，类似于georadius_ro命令，用来只支持get选项，从而作为读属性，这样就避免了slave无法读取的问题。此方案优点是方案清晰可靠，缺点是需要proxy和客户端做适配才能使用。

经过讨论，最终采取了方案二，因为这个方案更优雅，也更标准化。

添加bitfield_ro

{"bitfield_ro",bitfieldroCommand,-2,
"read-only fast @bitmap",
0,NULL,1,1,1,0,0,0},

完成之后，下图是在slave上执行bitfield_ro命令，可以看到被正确执行。

tair-redis > SLAVEOF 127.0.0.1 6379
OK
tair-redis > set k v
(error) READONLY You can't write against a read only replica.
tair-redis > BITFIELD mykey GET u4 0
(error) READONLY You can't write against a read only replica.
tair-redis > BITFIELD_RO mykey GET u4 0
1) (integer) 0

Proxy转发

为了保持用户不做代码修改，我们在proxy上对bitfiled命令做了兼容，即如果用户的bitfield命令只有get选项，proxy会将此命令转换为bitfield_ro分散转发到后端多个节点上，从而实现加速，用户不用做任何改造即可完成加速，如下图所示。

添加BITFIELD_RO命令后处理BITFIELD逻辑流程

贡献社区

我们将自己的修改回馈给了社区，并且被Redis官方接受

值得一提的是，阿里云在国内是最大的Redis社区contributer，如在新发布的Redis-6.0rc中，阿里云的贡献排第三，仅次于作者和Redis vendor（Redis Labs）。阿里云仍旧在不断的回馈和贡献社区。

阿里云Redis通过增加bitfield_ro命令，解决了官方bitfield get命令无法在slave上加速执行的问题。

除过bitfield命令，阿里云Redis也同时对georadius命令做了兼容转换，即在读写分离实例上，如果georadius/georadiusbymember命令没有store/storedist选项，将会被自动判断为读命令转发到slave加速执行。

我们思考读写分离版的场景，为什么用户需要读写分离呢？为什么不是用集群版呢？我们做一下简单对比，比如设置社区版的服务能力为K，那么表的对比如下（我们只添加了增强版Tair的主备做对比，集群版可以直接乘以分片数）：

方式 Redis社区版集群 Redis社区版读写分离 Redis（Tair增强版）主备
写（key均匀情况） K分片数 K K3
读（key均匀情况） K分片数 K只读节点数 K*3
写（单key或热key） K（最坏情况） K K*3
读（单key或热key） K（最坏情况） K只读节点数 K3
​表1. Redis社区版（集群/读写分离）和增强版（主备）简单场景对比

可见，其实读写分离版属于对单个key和热key的读能力的扩展的一种方法，比较适合中小用户有大key的情况，它无法解决用户的突发写的瓶颈，比如在这个场景下，如果用户的bitfield命令是写请求（子命令中带有INCRBY和SET），就会遇到无法解决的性能问题。

从表的对比看，这种情况下，用户如果能把key拆散，或者把大key拆成很多小key，就可以使用集群版获得良好的线性加速能力。大key带来的问题包含但不仅限于：

大key会造成数据倾斜，使得Redis的容量和服务能力不能线性扩展
大key意味着大概率这个key是热点
一旦不小心针对大key有range类的操作，会出现慢查询，还容易打爆带宽
这也是Tair增强版在阿里集团内各个应用建议的：“避免设计出大key和慢查，能避免90%以上的Redis问题”。

但是在实际使用中，用户仍旧不可避免的遇到热点问题，比如抢购，比如热剧，比如超大型直播间等；尤其是很多热点具备“突发性”的特点，事先并不知晓，冲击随时可达。Redis增强版的性能增强实例具备单key在O(1)操作40～45w ops的服务能力和极强的抗冲击能力，单机主备版就足够应对一场中大型的秒杀活动！同时如果用户没有大key，增强性能集群版能够近乎赋予用户千万甚至几千万OPS的服务能力，这也是Tair作为阿里重器，支持每次平稳渡过双11购物节秒杀的关键

原文链接：https://www.9i0i.com/article-95490-1.html

创新且锐意进取，是这个公司的基因。

洋葱学院由杨临风、朱若辰和李诺联合创办，团队希望通过技术方式促进教育均衡。在创立之初，团队就做出了一个意识超前的决定：整套业务系统均基于阿里云搭建。

要知道，2013年，能选择全面上云的中国企业屈指可数。

上云先锋洋葱学院这一路走来，也是和阿里云一同携手成长的难忘历程。几年前，由于某个特殊使用场景，线上业务受到严重影响，洋葱学院和阿里云紧急沟通、快速排查问题，阿里云云数据库的专家同学进行了重启、备份等一系列工作。

早先，洋葱学院起步于初中数学、物理课程，但是随着不断发展，开始加入语文和英语等学科，这些课程特点不同、相应的学习流程不同。除了早先选用的ECS云服务、SLB负载均衡、阿里云云数据库等经典基础产品之外，洋葱学院也尝试将新的业务应用搭建于一些新兴阿里云产品，如ACK容器服务、RSS弹性伸缩、SLS日志服务、Blink实时计算、ARMS前端监控等，来满足日趋复杂和多样化的业务需求。

如今，从初中理科逐渐扩展到小初高全学段全学科，为130多万教师以及3600多万的中小学生提供24小时在线的“云课堂”。

疫情大考突如其来，IT架构稳如泰山

疫情期间（近一个月以来），有超过700万学生、35万教师使用洋葱学院APP在线学习或辅助授课，同时还将课程资源开放给学习强国、快手等第三方平台播放，帮助更广泛的学生远程学习。

能应对猝不及防的疫情流量洪峰，洋葱都做了怎样的努力、下足了哪些功夫呢？

在线教育业务的一个重要特点，就是波峰波谷比较规律，可预测。在学校下课或放假时期，业务会达到上升，洋葱学院便会在数分钟扩容云上资源，待学生返校上课之时，再根据业务情况释放资源，这样持续保持较高的资源利用率，既节省成本又确保业务响应。

3年前，洋葱学院开始尝试微服务改造，将复杂的单体架构进行拆分和解耦。同时采用容器技术，并也将swarm迁移至阿里云容器服务ACK之上，原本每个模块都对应一套ECS与SLB，但是随着微服务越拆越细，开始出现资源浪费的情况，而且调度复杂度都在迅速膨胀。容器服务可以根据不同模块的配置所需，资源分配更加合理，按照定义规则自动弹性伸缩避免了复杂的调度维护。

容器的弹性

基本功夯实的基础上，洋葱学院还做了一些方案优化和升级。

延期开学的这段时间里，广大学生学习时间较为集中，面对大流量、高并发访问需求，洋葱学院需要确保业务稳定性，采用阿里云容器服务与云数据库融合解决方案，在应用不变的情况下，快速平稳实现扩容的问题。阿里云容器服务可以在几分钟内扩充底层资源，满足快速部署数千个应用实例的需求。阿里云容器服务团队的建议下，洋葱学院还进一步优化了整体的ECS服务器配置，将大量的小规格ECS服务器更换成30至50核大规格ECS，从容应对10倍扩容，同时运维管控更加便捷。

针对疫情延期开学，洋葱学院作为头部K12在线教育公司，免费向全国师生开放了平台的全部核心课程资源，这期间每天的学习访问人数持续飙升。使用云容器之后，系统在资源利用率上提升了约60%，出现问题后可快速隔离，当面对急剧增长的业务量，也可以在短时间内扩容进行业务支撑。——李诺 洋葱学院联合创始人&CTO

数据库的升级

为了确保平台使用起来“丝般顺滑”，阿里云为洋葱学院提供了综合架构解决方案：数据库层将云数据库Redis数据库做高速缓存，RDS PostgreSQL+MongoDB做持久化存储；应用层对微服务进行改造，以及容器化部署。这是完成挑战的核心能力。

洋葱学院还对冷用户和冷热数据做了优化：冷用户，即第一次来的用户信息较少，此期间冷用户过多，亟需优化冷用户的流程处理，这需要提高高压下的数据快速处理能力，处理变得更快；老师和学生的作业数据，会有冷热数据之分，每隔一段时间进行数据迁移，但是热数据增长过快，此前方案逐渐应接不暇。在阿里云云数据专家的建议下，将冷用户缓存增加，升级数据库，对数据库进行了分库分表，还进行了一系列索引优化、语句改写以及业务改造等工作。

在此次疫情中，洋葱学院利用阿里云数据库的极致弹性、无缝升级扩容能力，一晚上便完成了几十个核心数据库的容量升级以及PG实例版本升级。单个云Redis集群可承载千万级访问的超高性能，确保了即使流量数十倍增长也不会有业务瓶颈。同时，持久化存储RDS PostgreSQL、MongoDB有更强的承载能力，不仅可以应对复杂查询，还可做到极致超强弹性水平扩展，全面保障了洋葱学院的运行，在业务量比历史同期翻了10倍的情况下仍然保持平稳。

故障检测

此外，原本只能依靠负载均衡的定时扫描错误节点，故障检测存在一定时延；而Kubernetes自带容灾和错误发现机制，容器内部pod之间自动实现切换，大大缩短问题发现时间，同时基于阿里云云监控、ARMS Prometheus、ARMS前端监控和日志服务，实现云资源、容器集群、容器节点、Pod等指标的完善监控，对集群变更状态、pod创建拉起删除、组件异常等信息，基本可以覆盖到各种监控报警问题，将重大故障‘扼杀于摇篮之中’。

AI辅助教学，学生老师个性化“Friday”

看过复仇者联盟的朋友们，都记得钢铁侠的AI助手Friday，每次关键时刻都协助钢铁侠力挽狂澜。

洋葱学院的APP，其实早已经成为很多学生和老师的AI助手Friday。2017年，洋葱学院成立人工智能实验室，并尝试将AI赋能引入其教学体系。最主要的原因，是希望为学生们打造完整的学习闭环，产品能根据学生的学习现状和效果，动态规划学习路径，推送个性化学习内容。

而老师则可以通过数据后台实时充分掌握班上每名学生的学习能力和知识掌握情况，为同班同学一键布置不同的教学任务。

用心做产品，以诚待客

洋葱学院自成立之处，便决心搭建于云上。在他们看来，自己研究开源方案或重新搭建系统，是"事倍功半"的，意味着巨大的运维负担；因此，每当有新的业务需求时，洋葱学院都会首先考虑能否使用云上已有方案，他们相信阿里云服务的稳定性、专业性。

洋葱学院将更多的人力和精力投入到了课程研发之中，打磨课程。如今，洋葱的用户遍布全国，深受师生和家长的喜爱，多达3600万学生自发推荐，社科院白皮书显示其教师推荐度和家长满意度分别高达85%和90%。

洋葱学院以匠人之心打造“ 云 ”课堂，是一群践行教育初心的梦想家和冒险家。

每年双十一都会出现的这块大屏到底有什么神通广大呢？要想今年双十一吹不一样的牛逼，就要了解一下不一样的神器——DataV数据可视化

专业解释：DataV是一个拖拽式可视化工具，可以在零售、物流、电力、水利、环保，还有交通领域，通过交互式实时数据可视化视屏墙来帮助业务人员发现、诊断业务问题。

它到底有什么样的魅力？

专业级的数据可视化

专精于地理信息与业务数据融合的可视化，提供丰富的行业模版和交互组件，支持自定义组件接入。

来瞅一眼这个组件有多丰富，DataV的开发小伙伴也太为大家着想了一点。（开发小伙伴还偷偷告诉我，第三方的组件包购买之后也可以接入DataV哦！我真的不是商业间谍）

指挥中心、实时监控、地理分析、汇报展示等等这么多的屏幕模板，真的不用怕没有设计师！

多种数据源支持

支持接入包括阿里云分析型数据库、关系型数据库、本地CSV上传和在线API等，而且支持动态请求。

大数据计算的能力有没有发挥的很棒！（请跟我一起竖起大拇指）

图形化编辑界面

拖拽即可完成样式和数据配置，无需编程就能轻松搭建数据大屏。

只要轻轻动动你的小手指，拖拖拽拽，不需要编程能力，就可以创造出专业的可视化应用！（我真的不是DataV的脑残粉）

灵活部署和发布

适配非常规拼接大屏，创建的可视化应用能够发布分享，没有购买DataV产品的用户也可以访问到应用，作为对外数据业务展示的窗口。或者通过密码/Token的方式进行访问权限控制，保护数据隐私安全。还可以通过历史快照来保存历史版本，并在历史版本之间切换并发布。

在某些场景，如数据涉密无法上云、展示现场网络条件有限等条件下，还可以采用 DataV 本地部署的方式。

部署和发布如此流畅，不如一起来拖拖拽拽一个可视化界面，展示一下你真正的实力。

双十一期间购买DataV可享受超级福利折扣价！
详情优惠请戳：购买链接

1、云端向设备发送的下行消息或者异步服务调用到平台也算结束，平台再向设备进行一个透传
2、设备端向平台发送的上行消息到平台就算结束
3、云端通过服务端订阅来获取设备上行的消息

原理
1、要想获取异步服务调用的返回结果，首先设备得有返回
(1) 设备接收平台端透传过来的异步服务调用

(2)设备端收到数据后进行响应

2、这里的设备响应结果发送给平台之后，平台可通过
云产品流传或服务端订阅，再将消息发送给云端
方式一：云平台流转，注意选择Topic:
/${productKey}/${deviceName}/thing/downlink/reply/message

这个为什么可行？可参考官方文档说明

然后添加操作为发布到AMQP消费组

方式二:AMQP服务端订阅
订阅什么呢？勾选设备上报消息即可（前提是设备端有返回，即满足原理1的前提）

操作步骤
不多说了，直接上步骤
1、准备测试用的产品和设备
主要是定义一个异步服务：这里不详细阐述

2、准备测试用的云端调试工具
可以是集成云端SDK的Demo，可以是业务逻辑应用调用云端API，最简单的直接使用云端API在线调试工具
具体参数填写规范，这里也不做详细阐述

3、物联网平台控制台上配置好规则引擎
（1）云平台流转

选择好产品设备和topic

注意SQL语句的编写，这里的字段就是要发送给AMQP客户端的消息内容，可以事先进行调试。

这里要注意AMQP客户端都是按照既定的协议格式进行过滤数据的，所以这里的消息内容需要按照协议进行配置

确定好消息内容后

SQL语句：

SELECT timestamp('yyyy-MM-dd'T'HH:mm:ss'Z'') as 云平台流转至AMQP测试,deviceName() as deviceName, code as code,data as data,topic() as topic,messageId() as requestId,id as id,topic(1) as productKey,iotId as iotId FROM "/a16hDZJpRCl/IoTDeviceDemo1thing/downlink/reply/message" WHERE

（2）服务端订阅

勾选设备上报消息即可，具体消费组怎么创建就不详细阐述

实测效果：

4、设备端接收消息+响应reply

代码示例：
pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>MQTTClient</artifactId>
    <version>1.0-SNAPSHOT</version>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>6</source>
                    <target>6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <dependencies>
        <dependency>
            <groupId>org.eclipse.paho</groupId>
            <artifactId>org.eclipse.paho.client.mqttv3</artifactId>
            <version>1.1.0</version>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>23.0</version>
        </dependency>
        <dependency>
            <groupId>com.aliyun</groupId>
            <artifactId>aliyun-java-sdk-core</artifactId>
            <version>3.5.1</version>
        </dependency>
    </dependencies>

</project>

AliyunIoTSignUtil：

package com.alibaba.taro;

import javax.crypto.Mac;
import javax.crypto.SecretKey;
import javax.crypto.spec.SecretKeySpec;
import java.util.Arrays;
import java.util.Map;

/**
 * AliyunIoTSignUtil
 */

public class AliyunIoTSignUtil {
    public static String sign(Map<String, String> params, String deviceSecret, String signMethod) {
        //将参数Key按字典顺序排序
        String[] sortedKeys = params.keySet().toArray(new String[] {});
        Arrays.sort(sortedKeys);

        //生成规范化请求字符串
        StringBuilder canonicalizedQueryString = new StringBuilder();
        for (String key : sortedKeys) {
            if ("sign".equalsIgnoreCase(key)) {
                continue;
            }
            canonicalizedQueryString.append(key).append(params.get(key));
        }

        try {
            String key = deviceSecret;
            return encryptHMAC(signMethod,canonicalizedQueryString.toString(), key);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    /**
     * HMACSHA1加密
     *
     */
    public static String encryptHMAC(String signMethod,String content, String key) throws Exception {
        SecretKey secretKey = new SecretKeySpec(key.getBytes("utf-8"), signMethod);
        Mac mac = Mac.getInstance(secretKey.getAlgorithm());
        mac.init(secretKey);
        byte[] data = mac.doFinal(content.getBytes("utf-8"));
        return bytesToHexString(data);
    }

    public static final String bytesToHexString(byte[] bArray) {

        StringBuffer sb = new StringBuffer(bArray.length);
        String sTemp;
        for (int i = 0; i < bArray.length; i++) {
            sTemp = Integer.toHexString(0xFF & bArray[i]);
            if (sTemp.length() < 2) {
                sb.append(0);
            }
            sb.append(sTemp.toUpperCase());
        }
        return sb.toString();
    }
}

Demo：

package com.alibaba;

import com.alibaba.taro.AliyunIoTSignUtil;
import org.eclipse.paho.client.mqttv3.*;
import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;
import org.json.JSONObject;

import java.util.HashMap;
import java.util.Map;


public class CustomTopicMessageDemo2 {

    public static String productKey = "a16hD*****";
    public static String deviceName = "IoTDevice****";
    public static String deviceSecret = "0895205d*********";
    public static String regionId = "cn-shanghai";


    // 物模型-属性上报topic
    //private static String pubTopic = "/sys/" + productKey + "/" + deviceName + "/thing/event/property/post";
    //private static String subTopic = "/sys/" + productKey + "/" + deviceName + "/thing/service/property/set";
    // 自定义topic，在产品Topic列表位置定义
    //private static String pubTopic = "/"+productKey + "/" + deviceName+"/user/DemoTest";
    //private static String subTopic = "/"+productKey + "/" + deviceName+"/user/DemoTest";
    private static String pubTopic = "/"+productKey + "/" + deviceName+"/user/get";
    private static String subTopic = "/"+productKey + "/" + deviceName+"/user/get";

    private static MqttClient mqttClient;

    public static void main(String [] args){

        initAliyunIoTClient();
//        ScheduledExecutorService scheduledThreadPool = new ScheduledThreadPoolExecutor(1,
//                new ThreadFactoryBuilder().setNameFormat("thread-runner-%d").build());
//
//        scheduledThreadPool.scheduleAtFixedRate(()->postDeviceProperties(), 10,10, TimeUnit.SECONDS);
        // 汇报属性
        //String payloadJson = "{"params":{"MasterLightSwitch":0,"LivingLightSwitch":0,"SecondaryLightSwotch":0,"MasterCurtainSwitch":1,"SecondaryCurtainSwitch":1,"LivingCurtainSwitch":1}}";
        //String payloadJson = "{"params":{"Temp":77,"yyy":{"tttt":"123"}}}";
        String payloadJson = "{"params":{"Temp":77,"yyy":"8888"}}";
        //String payloadJson = "{"tts":"ss"}";
        //String payloadJson = "34454545";
        postDeviceProperties(payloadJson);

        try {
            mqttClient.subscribe(subTopic); // 订阅Topic
        } catch (MqttException e) {
            System.out.println("error:" + e.getMessage());
            e.printStackTrace();
        }

        // 设置订阅监听
        mqttClient.setCallback(new MqttCallback() {
            @Override
            public void connectionLost(Throwable throwable) {
                System.out.println("connection Lost");

            }

            @Override
            public void messageArrived(String s, MqttMessage mqttMessage) throws Exception {
                String payload =  new String(mqttMessage.getPayload());
                System.out.println(" 接收消息：");
                System.out.println("Topic : " + s);
                System.out.println(payload); //打印输出消息payLoad
                System.out.println("=================================================================");

//                String subTopic = "/sys/" + productKey + "/" + deviceName + "/thing/service/property/set";
//                if(s.equals(subTopic)) {
//                    JSONObject jsonProperty = new JSONObject(payload);
//                    if(jsonProperty.has("params"))
//                    {
//                        String paramsJson = jsonProperty.get("params").toString();
//                        System.out.println("test paramsJson is:n" + paramsJson);
//                        String params = "{"params": " +  paramsJson + "}";
//                        System.out.println("test params is:n" + params);
//                        System.out.println("收到属性设置后，再上报一次属性：");
//                        postDeviceProperties(params);
//                    }
//                }

                //收到服务调用，给予返回reply
//                下行（Alink JSON）：
//                请求Topic：/sys/{productKey}/{deviceName}/thing/service/{tsl.service.identifier}
//                响应Topic：/sys/{productKey}/{deviceName}/thing/service/{tsl.service.identifier}_reply
                String subTopic = "/sys/" + productKey + "/" + deviceName + "/thing/service/StartP2PStreaming";
                String replyTopic = "/sys/" + productKey + "/" + deviceName + "/thing/service/StartP2PStreaming_reply";
                if(s.equals(subTopic)) {
                    JSONObject jsonProperty = new JSONObject(payload);
                    if(jsonProperty.has("id"))
                    {
                        String id = jsonProperty.get("id").toString();
                        String replyJson = "{"data":{},"code":200,"id":""+ id +""}";
                        //System.out.println("test replyJson is:n" + replyJson);
                        //String replys = "{"params": " +  replyJson + "}";
                        //System.out.println("test reply is:n" + replys);
                        System.out.println("收到服务调用后，给予返回");
                        postServiceReply(replyJson,replyTopic);
                    }
                }
            }

            @Override
            public void deliveryComplete(IMqttDeliveryToken iMqttDeliveryToken) {

            }
        });

    }

    /**
     * 初始化 Client 对象
     */
    private static void initAliyunIoTClient() {

        try {
            // 构造连接需要的参数
            String clientId = "java" + System.currentTimeMillis();
            Map<String, String> params = new HashMap<String, String>(16);
            params.put("productKey", productKey);
            params.put("deviceName", deviceName);
            params.put("clientId", clientId);
            String timestamp = String.valueOf(System.currentTimeMillis());
            params.put("timestamp", timestamp);
            // cn-shanghai
            String targetServer = "tcp://" + productKey + ".iot-as-mqtt."+regionId+".aliyuncs.com:1883";

            String mqttclientId = clientId + "|securemode=3,signmethod=hmacsha1,timestamp=" + timestamp + "|";
            String mqttUsername = deviceName + "&" + productKey;
            String mqttPassword = AliyunIoTSignUtil.sign(params, deviceSecret, "hmacsha1");

            connectMqtt(targetServer, mqttclientId, mqttUsername, mqttPassword);

        } catch (Exception e) {
            System.out.println("initAliyunIoTClient error " + e.getMessage());
        }
    }

    public static void connectMqtt(String url, String clientId, String mqttUsername, String mqttPassword) throws Exception {

        MemoryPersistence persistence = new MemoryPersistence();
        mqttClient = new MqttClient(url, clientId, persistence);
        MqttConnectOptions connOpts = new MqttConnectOptions();
        // MQTT 3.1.1
        connOpts.setMqttVersion(4);
        connOpts.setAutomaticReconnect(false);
        connOpts.setCleanSession(false);
        //connOpts.setCleanSession(true);

        connOpts.setUserName(mqttUsername);
        connOpts.setPassword(mqttPassword.toCharArray());
        connOpts.setKeepAliveInterval(60);

        mqttClient.connect(connOpts);
    }

    /**
     * 汇报属性
     */
    private static void postDeviceProperties(String payloadJson) {

        try {
            //上报数据
            //高级版 物模型-属性上报payload
            System.out.println("上报属性值:");
            //String payloadJson = "{"params":{"Status":0,"Data":"15"}}";
            //String payloadJson = "{"GeoLocation":{"Longitude":120.99,"Latitude":30.13,"Altitude":39.01},"BatteryPercentage":40.703533, "Temperature":2.233362}";
            //String payloadJson = "{"id":"3","version":"1.0","params":{"GeoLocation":{"Longitude":120.999,"Latitude":30.13,"Altitude":39.01},"BatteryPercentage":42.99999, "Temperature":2.233362}}";
            //String payloadJson = "{"params":{"MasterLightSwitch":0,"LivingLightSwitch":0,"SecondaryLightSwotch":0,"MasterCurtainSwitch":1,"SecondaryCurtainSwitch":1,"LivingCurtainSwitch":1}}";
            System.out.println(payloadJson);
            MqttMessage message = new MqttMessage(payloadJson.getBytes("utf-8"));
            message.setQos(0);
            mqttClient.publish(pubTopic, message);
            System.out.println("=================================================================");
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }

    /**
     * 服务返回
     */
    private static void postServiceReply(String payloadJson,String relpyTopic) {

        try {
            //上报数据
            //高级版 物模型-属性上报payload
            System.out.println("服务调用返回:");
            //String payloadJson = "{"params":{"Status":0,"Data":"15"}}";
            System.out.println("Topic:");
            System.out.println(relpyTopic);
            System.out.println(payloadJson);
            MqttMessage message = new MqttMessage(payloadJson.getBytes("utf-8"));
            message.setQos(0);
            mqttClient.publish(relpyTopic, message);
            System.out.println("=================================================================");
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }

}

实测效果：

5、云端使用AMQP客户端登录，并接收消息

参考官方文档，这里就不作详细阐述。
https://help.aliyun.com/document_detail/143601.html?spm=a2c4g.11186623.6.624.304e354e2OEGFh

代码示例：
pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>Test</artifactId>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <!-- amqp 1.0 qpid client -->
<!--        <dependency>-->
<!--            <groupId>org.apache.qpid</groupId>-->
<!--            <artifactId>qpid-jms-client</artifactId>-->
<!--            <version>0.47.0</version>-->
<!--        </dependency>-->


        <!-- https://mvnrepository.com/artifact/commons-codec/commons-codec -->
        <dependency>
            <groupId>commons-codec</groupId>
            <artifactId>commons-codec</artifactId>
            <version>1.10</version>
        </dependency>


        <!-- https://mvnrepository.com/artifact/org.apache.qpid/qpid-jms-client -->
        <dependency>
            <groupId>org.apache.qpid</groupId>
            <artifactId>qpid-jms-client</artifactId>
            <version>0.47.0</version>
        </dependency>

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-simple</artifactId>
            <version>1.7.25</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.maven.surefire</groupId>
            <artifactId>maven-surefire-common</artifactId>
            <version>2.12.4</version>
        </dependency>


        <!-- util for base64-->

<!--        <dependency>-->
<!--            <groupId>commons-codec</groupId>-->
<!--            <artifactId>commons-codec</artifactId>-->
<!--            <version>1.3</version>-->
<!--        </dependency>-->
    </dependencies>


</project>

Demo

package com.alibaba;

import org.apache.commons.codec.binary.Base64;
import org.apache.qpid.jms.JmsConnection;
import org.apache.qpid.jms.JmsConnectionListener;
import org.apache.qpid.jms.message.JmsInboundMessageDispatch;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import javax.jms.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.net.URI;
import java.util.Hashtable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class AmqpJavaClientDemo {

    private final static Logger logger = LoggerFactory.getLogger(AmqpJavaClientDemo.class);

    //业务处理异步线程池，线程池参数可以根据您的业务特点调整，或者您也可以用其他异步方式处理接收到的消息。
    private final static ExecutorService executorService = new ThreadPoolExecutor(
            Runtime.getRuntime().availableProcessors(),
            Runtime.getRuntime().availableProcessors() * 2,
            60,
            TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(50000));


    public static void main(String[] args) throws Exception {
        //参数说明，请参见AMQP客户端接入说明文档。
        String accessKey = "LTAI4G2*****";
        String accessSecret = "Mp2f4qopmULI6*****";
        String consumerGroupId = "e0oRIYMSOYwQ*****";
        //iotInstanceId：购买的实例请填写实例ID，公共实例请填空字符串""。
        String iotInstanceId = "";
        long timeStamp = System.currentTimeMillis();
        //签名方法：支持hmacmd5、hmacsha1和hmacsha256。
        String signMethod = "hmacsha1";
        //控制台服务端订阅中消费组状态页客户端ID一栏将显示clientId参数。
        //建议使用机器UUID、MAC地址、IP等唯一标识等作为clientId。便于您区分识别不同的客户端。
        String clientId = "yangboClientId";

        //userName组装方法，请参见AMQP客户端接入说明文档。
        String userName = clientId + "|authMode=aksign"
                + ",signMethod=" + signMethod
                + ",timestamp=" + timeStamp
                + ",authId=" + accessKey
                + ",iotInstanceId=" + iotInstanceId
                + ",consumerGroupId=" + consumerGroupId
                + "|";
        //计算签名，password组装方法，请参见AMQP客户端接入说明文档。
        String signContent = "authId=" + accessKey + "&timestamp=" + timeStamp;
        String password = doSign(signContent,accessSecret, signMethod);
        //接入域名，请参见AMQP客户端接入说明文档。
            String connectionUrl = "failover:(amqps://1875496626634053.iot-amqp.cn-shanghai.aliyuncs.com:5671?amqp.idleTimeout=80000)"
                + "?failover.reconnectDelay=30";

        Hashtable<String, String> hashtable = new Hashtable<String, String>();
        hashtable.put("connectionfactory.SBCF",connectionUrl);
        hashtable.put("queue.QUEUE", "default");
        hashtable.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.qpid.jms.jndi.JmsInitialContextFactory");
        Context context = new InitialContext(hashtable);
        ConnectionFactory cf = (ConnectionFactory)context.lookup("SBCF");
        Destination queue = (Destination)context.lookup("QUEUE");
        // Create Connection
        Connection connection = cf.createConnection(userName, password);
        ((JmsConnection) connection).addConnectionListener(myJmsConnectionListener);

        System.out.println("connection success");
        // Create Session
        // Session.CLIENT_ACKNOWLEDGE: 收到消息后，需要手动调用message.acknowledge()。
        // Session.AUTO_ACKNOWLEDGE: SDK自动ACK（推荐）。
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        connection.start();
        // Create Receiver Link
        MessageConsumer consumer = session.createConsumer(queue);
        consumer.setMessageListener(messageListener);
    }

    private static MessageListener messageListener = new MessageListener() {
        @Override
        public void onMessage(Message message) {
            try {
                //1.收到消息之后一定要ACK。
                // 推荐做法：创建Session选择Session.AUTO_ACKNOWLEDGE，这里会自动ACK。
                // 其他做法：创建Session选择Session.CLIENT_ACKNOWLEDGE，这里一定要调message.acknowledge()来ACK。
                // message.acknowledge();
                //2.建议异步处理收到的消息，确保onMessage函数里没有耗时逻辑。
                // 如果业务处理耗时过程过长阻塞住线程，可能会影响SDK收到消息后的正常回调。
                executorService.submit(new Runnable() {
                    public void run() {
                        processMessage(message);
                    }
                });
            } catch (Exception e) {
                logger.error("submit task occurs exception ", e);
            }
        }
    };

    /**
     * 在这里处理您收到消息后的具体业务逻辑。
     */
    private static void processMessage(Message message) {
        try {
            byte[] body = message.getBody(byte[].class);
            String content = new String(body);
            String topic = message.getStringProperty("topic");
            String messageId = message.getStringProperty("messageId");


            System.out.println("receive message"
                    + ", topic = " + topic
                    + ", messageId = " + messageId
                    + ", content = " + content);
            logger.info("receive message"
                    + ", topic = " + topic
                    + ", messageId = " + messageId
                    + ", content = " + content);
        } catch (Exception e) {
            logger.error("processMessage occurs error ", e);
        }
    }

    private static JmsConnectionListener myJmsConnectionListener = new JmsConnectionListener() {
        /**
         * 连接成功建立。
         */
        @Override
        public void onConnectionEstablished(URI remoteURI) {
            logger.info("onConnectionEstablished, remoteUri:{}", remoteURI);
        }

        /**
         * 尝试过最大重试次数之后，最终连接失败。
         */
        @Override
        public void onConnectionFailure(Throwable error) {
            logger.error("onConnectionFailure, {}", error.getMessage());
        }

        /**
         * 连接中断。
         */
        @Override
        public void onConnectionInterrupted(URI remoteURI) {
            logger.info("onConnectionInterrupted, remoteUri:{}", remoteURI);
        }

        /**
         * 连接中断后又自动重连上。
         */
        @Override
        public void onConnectionRestored(URI remoteURI) {
            logger.info("onConnectionRestored, remoteUri:{}", remoteURI);
        }

        @Override
        public void onInboundMessage(JmsInboundMessageDispatch envelope) {}

        @Override
        public void onSessionClosed(Session session, Throwable cause) {}

        @Override
        public void onConsumerClosed(MessageConsumer consumer, Throwable cause) {}

        @Override
        public void onProducerClosed(MessageProducer producer, Throwable cause) {}
    };

    /**
     * 计算签名，password组装方法，请参见AMQP客户端接入说明文档。
     */
    private static String doSign(String toSignString, String secret, String signMethod) throws Exception {
        SecretKeySpec signingKey = new SecretKeySpec(secret.getBytes(), signMethod);
        Mac mac = Mac.getInstance(signMethod);
        mac.init(signingKey);
        byte[] rawHmac = mac.doFinal(toSignString.getBytes());
        return Base64.encodeBase64String(rawHmac);

//        return Arrays.toString(Base64.encodeBase64(rawHmac));
    }
}

实测效果：
云平台流转方式的返回结果：

AMQP订阅方式返回结果：

首发公众号：码农架构
视图就是虚拟表:

如何创建，更新和删除视图

创建视图：CREATE VIEW

CREATE VIEW player_above_avg_height AS
SELECT player_id, height
FROM player
WHERE height > (SELECT AVG(height) from player)

当视图创建之后，它就相当于一个虚拟表，可以直接使用：

SELECT * FROM player_above_avg_height

嵌套视图

CREATE VIEW player_above_above_avg_height AS
SELECT player_id, height
FROM player
WHERE height > (SELECT AVG(height) from player_above_avg_height)

修改视图：ALTER VIEW

ALTER VIEW view_name AS
SELECT column1, column2
FROM table
WHERE condition

删除视图：DROP VIEW

DROP VIEW view_name

需要说明的是，SQLite 不支持视图的修改，仅支持只读视图，也就是说你只能使用 CREATE VIEW 和 DROP VIEW，如果想要修改视图，就需要先 DROP 然后再 CREATE。

如何使用视图简化 SQL 操作

利用视图完成复杂的连接

CREATE VIEW player_height_grades AS
SELECT p.player_name, p.height, h.height_level
FROM player as p JOIN height_grades as h
ON height BETWEEN h.height_lowest AND h.height_highest

利用视图对数据进行格式化

CREATE VIEW player_team AS 
SELECT CONCAT(player_name, '(' , team.team_name , ')') AS player_team FROM player JOIN team WHERE player.team_id = team.team_id

使用视图与计算字段

CREATE VIEW game_player_score AS
SELECT game_id, player_id, (shoot_hits-shoot_3_hits)*2 AS shoot_2_points, shoot_3_hits*3 AS shoot_3_points, shoot_p_hits AS shoot_p_points, score  FROM player_score

总结

使用视图有很多好处，比如安全、简单清晰。

存储过程像是函数.

什么是存储过程，如何创建一个存储过程

定义一个存储过程：

CREATE PROCEDURE 存储过程名称([参数列表])
BEGIN
    需要执行的语句
END    

删除已经创建的存储过程:

DROP PROCEDURE

更新存储过程:

ALTER PROCEDURE

实现一个简单的存储过程:

CREATE PROCEDURE `add_num`(IN n INT)
BEGIN
       DECLARE i INT;
       DECLARE sum INT;
       
       SET i = 1;
       SET sum = 0;
       WHILE i <= n DO
              SET sum = sum + i;
              SET i = i +1;
       END WHILE;
       SELECT sum; -- 在调用的时候会打印这个值
END

mysql> call study_stored_procedure(50);
+------+
| sum  |
+------+
| 1275 |
+------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

使用这个存储过程:

CALL add_num(50);

DELIMITER

如果你使用 Navicat 这个工具来管理 MySQL 执行存储过程，那么直接执行上面这段代码就可以了。如果用的是 MySQL，你还需要用 DELIMITER 来临时定义新的结束符。因为默认情况下 SQL 采用（；）作为结束符，这样当存储过程中的每一句 SQL 结束之后，采用（；）作为结束符，就相当于告诉 SQL 可以执行这一句了。但是存储过程是一个整体，我们不希望 SQL 逐条执行，而是采用存储过程整段执行的方式，因此我们就需要临时定义新的 DELIMITER，新的结束符可以用（//）或者（$$）。如果你用的是 MySQL，那么上面这段代码，应该写成下面这样：

DELIMITER //
CREATE PROCEDURE `add_num`(IN n INT)
BEGIN
       DECLARE i INT;
       DECLARE sum INT;
       
       SET i = 1;
       SET sum = 0;
       WHILE i <= n DO
              SET sum = sum + i;
              SET i = i +1;
       END WHILE;
       SELECT sum;
END //
DELIMITER ;

存储过程的 3 种参数类型

IN 参数必须在调用存储过程时指定，而在存储过程中修改该参数的值不能被返回。而 OUT 参数和 INOUT 参数可以在存储过程中被改变，并可返回。

CREATE PROCEDURE `get_hero_scores`(
       OUT max_max_hp FLOAT,
       OUT min_max_mp FLOAT,
       OUT avg_max_attack FLOAT,  
       s VARCHAR(255)
       )
BEGIN
       SELECT MAX(hp_max), MIN(mp_max), AVG(attack_max) FROM heros WHERE role_main = s INTO max_max_hp, min_max_mp, avg_max_attack;
END

调用:

• 调用的时候需要在变量前面加 @ , 否则报错

CALL get_hero_scores(@max_max_hp, @min_max_mp, @avg_max_attack, '战士');
SELECT @max_max_hp, @min_max_mp, @avg_max_attack;

流控制语句

1. BEGIN…END：BEGIN…END 中间包含了多个语句，每个语句都以（;）号为结束符。
2. DECLARE：DECLARE 用来声明变量，使用的位置在于 BEGIN…END 语句中间，而且需要在其他语句使用之前进行变量的声明。
3. SET：赋值语句，用于对变量进行赋值。
4. SELECT…INTO：把从数据表中查询的结果存放到变量中，也就是为变量赋值。
5. IF…THEN…ENDIF：条件判断语句，我们还可以在 IF…THEN…ENDIF 中使用 ELSE 和 ELSEIF 来进行条件判断。
6. CASE：CASE 语句用于多条件的分支判断，使用的语法是下面这样的。
7. LOOP、LEAVE 和 ITERATE：LOOP 是循环语句，使用 LEAVE 可以跳出循环，使用 ITERATE 则可以进入下一次循环。如果你有面向过程的编程语言的使用经验，你可以把 LEAVE 理解为 BREAK，把 ITERATE 理解为 CONTINUE。
8. REPEAT…UNTIL…END REPEAT：这是一个循环语句，首先会执行一次循环，然后在 UNTIL 中进行表达式的判断，如果满足条件就退出，即 END REPEAT；如果条件不满足，则会就继续执行循环，直到满足退出条件为止。
9. WHILE…DO…END WHILE：这也是循环语句，和 REPEAT 循环不同的是，这个语句需要先进行条件判断，如果满足条件就进行循环，如果不满足条件就退出循环。

CASE 
  WHEN expression1 THEN ...
  WHEN expression2 THEN ...
  ...
    ELSE 
    --ELSE语句可以加，也可以不加。加的话代表的所有条件都不满足时采用的方式。
END

关于存储过程使用的争议

存储过程有很多好处:
• 存储过程可以一次编译多次使用
• 存储过程的安全性强
• 可以减少网络传输量
缺点也是很明显的:
• 可移植性差
• 调试困难
• 版本管理也很困难
• 不适合高并发的场景

近年来，随着人工智能对传统行业的赋能改造，越来越多的基于人工智能的业务解决方案被提出来，声纹识别在保险行业中的身份认证便是一个很好的例子. 声纹识别是根据说话人发音的生理和行为特征，自动识别说话人身份的一种生物识别技术，对应在电话销售场景下，它主要解决以下安全问题：一方面，有不法分子窃取电话销售人员账号信息，非法获取客户个人信息资料并进行贩卖、泄露，严重侵犯了公民个人的信息隐私权，另一方面，部分行业从业人员利用一些规则漏洞，通过套保、骗保等非法手段实施金融诈骗. 针对这些安全问题，可以通过实时声纹认证加以解决，以电话销售人员为监管核心，利用每个人独一无二的声纹进行严密的个人身份认证，保证电话销售人员对接客户时是本人注册登录，规范电销人员行为，从源头上有效规避信息泄露、漏洞利用等风险。

二、声纹识别原理

上图是端对端的深度学习训练和推理过程。对比传统声纹识别模型，我们的模型在实际使用中优势明显，在用户远程身份验证场景，通过注册用户说一段话，即可轻松快速的确认注册用户身份，识别准确率达到95%以上，秒级响应，实时声纹核身。下面简要介绍我们模型的特点。

2.0 度量学习

实验发现，在声纹识别中采用softmax进行网络训练 ，用余弦相似度的测试性能往往不如传统声纹识别模型，尤其是在鲁棒性上。分析发现[6]基于softmax的分类训练，为了得到更小的loss，优化器会增大一些easy samples的L2 length，减小hard examples 的L2 length，导致这些样本并没有充分学习，特征呈现放射状，以MNIST识别任务为例，基于softmax学到的特征分布如图3(a)所示. 同类别特征分布并不聚拢，在L2 长度上拉长，呈放射状，且每个类别的间距并不大，在verification的任务中，会导致相邻的两个类别得分很高。

为了达到类内聚拢，类间分散的效果，我们研究了在图像领域中应用较为成功的几种softmax变种，包括AM-softmax[4]，arcsoftmax[5]等，从图3(b)可以看到，基于margin的softmax，相比纯softmax，类间的分散程度更大，且类内特征更聚拢，对声纹1:1比对和1:N搜索的任务友好。

2.1 噪音鲁棒性

在特征提取时，对于简单加性噪音，我们提出了基于功率谱减法，实现噪音抑制；对于其他复杂噪音，我们提出了基于降噪自动编码器的噪音补偿模型，将带噪语音特征映射到干净语音特征，实现噪音消除。

在模型训练时，我们采用数据增强的训练机制，将噪音数据通过随机高斯的形式加入到声纹模型的训练中，使得训练后的模型对噪音数据具有更好的鲁棒性。

2.2 短音频鲁棒性

为了提高短音频鲁棒性，我们提出了基于短时帧级别的模型训练机制，使模型能够在极短的语音时长（约0.5秒）下即可完成声纹识别. 在此基础上，我们在模型训练中引入了更多高阶的音频统计信息和正则化方法，进一步提升了模型在短语音条件下（2~3秒）的识别精度。

三、如何使用AnalyticDB搭建声纹对比系统

3.0 创建插件

使用一下SQL来分别创建AnalyticDB的非结构化分析插件OpenAnalytic和向量检索插件fastann。

3.1 建表

我们可以建立一个表来保存所有说话人的声音和声音的特征，后续我们可以从这个表中搜索说话人。

3.2 创建索引

我们可以为特征向量列创建向量检索索引。

3.3 创建声纹识别算法pipeline

通过以下sql，我们可以在数据库中创建声纹特征提取的算法模型。

3.4 获取说话人声纹特征

通过以下sql可以使用3.3创建的pipeline。这个UDF的输入是pipeline名称和目标文本。输出是一个说话人声音的特征向量。
`# 通过声音文件识别
SELECT open_analytic.pipeline_run_dist_random('speaker_feature_extractor',

                    <声音文件>);`

3.5 说话人声纹特征导入AnalyticDB

获取声音特征后, 我们可以使用一下sql来讲数据插入3.1创建的表中。

3.6 在数据库中搜索最相似的的人

通过以下sql，我们可以在声音特征库中搜索最相似的说话人。然后我们可以根据特征间距离是否满足预设的阈值来判断是否是同一个人。

3.7 比较两个声音是否为同一个人

我们还可以提取出两个人的声音特征然后直接计算二者的距离来判断这两个声音是否来自同一个说话人。SQL如下

四、AnalyticDB介绍

分析型数据库(AnalyticDB)是阿里云上的一种高并发低延时的PB级实时数据仓库，可以毫秒级针对万亿级数据进行即时的多维分析透视和业务探索。AnalyticDB for MySQL 全面兼容MySQL协议以及SQL:2003 语法标准, AnalyticDB forPostgreSQL 支持标准 SQL:2003，高度兼容 Oracle 语法生态。

向量检索和非结构化数据分析是AnalyticDB的进阶功能。目前两款产品都包含向量检索功能, 可以支持人脸, 人体, 车辆等的相似查询和推荐系统。AnalyticDB在真实应用场景中可以支持10亿级别的向量数据的查询, 毫秒级别的响应时间。AnalyticDB已经在多个城市的重大项目中大规模部署。

在一般的包含向量检索的的应用系统中, 通常开发者会使用向量检索引擎(例如Faiss)来存储向量数据, 然后使用关系型数据库存储结构化数据。在查询时也需要交替查询两个系统, 这种方案会有额外的开发工作并且性能也不是最优。AnalyticDB支持结构化数据和非结构化数据(向量)的检索，仅仅使用SQL接口就可以快速的搭建起以图搜图或者图片+结构化数据混合检索等功能。AnalyticDB的优化器在混合检索场景中会根据数据的分布和查询的条件选择最优的执行计划，在保证召回的同时，得到最优的性能。AnalyticDB向量版采用了多项创新性技术, 这些技术在我们的论文 AnalyticDB-V: A Hybrid Analytical Engine Towards Query Fusion for Structured and Unstructured Data 中有详细介绍介绍。目前论文已经被数据库三大顶会之一的VLDB接受, 具有技术领先性。

结构化信息+非结构化信息（图片）混合检索在实际应用中被广泛使用的。例如人脸门禁系统被部署在多个小区时, 我们使用一张表存储了所有小区的人脸特征, 在人脸检索时我们只需要检索当前小区的人脸特征。在这种情况下, 使用AnalyticDB我们只需要在SQL中增加where 小区名 ='xxx' 就可以轻易实现。AnalyticDB同时提供了先进的图像文本分析算法, 能够提取非结构化数据的特征和标签, 用户仅仅需要使用SQL就可以完成图像文本内容的分析。

五、参考文献

[1] Heigold G, Moreno I, Bengio S, et al. End-to-end text-dependent speaker verification[C]//2016 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). IEEE, 2016: 5115-5119.
[2]Li C, Ma X, Jiang B, et al. Deep speaker: an end-to-end neural speaker embedding system[J]. arXiv preprint arXiv:1705.02304, 2017.
[3] Snyder D, Garcia-Romero D, Sell G, et al. X-vectors: Robust den embeddings for speaker recognition[C]//2018 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). IEEE, 2018: 5329-5333.
[4] Wang F, Cheng J, Liu W, et al. Additive margin softmax for face verification[J]. IEEE Signal Processing Letters, 2018, 25(7): 926-930.
[5] Dang J, Guo J, Xue N, et al. Arc face: Additive angular margin loss for deep face recognition[C]//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019: 4690-4699.
[6] Ranjan R, Castillo C D, Chellappa R. L2-constrained softmax loss for discriminative face verification[J]. arXiv preprint arXiv:1703.09507, 2017.

六、结语

本文介绍了如何使用AnalyticDB来搭建声纹比对系统。AnalyticDB还支持其他多种多样人工智能算法如目标检测, 商品识别, 基因识别等等。想了解更多请用钉钉扫码加入AnalyticDB向量版交流群。

到如今2020年，中国数据库的发展已经历时四十多年，国产数据库在这片土壤上开始逐渐繁茂，从最初的盲目模仿到如今越来越多的数据库企业走向自主研发，国产数据库正在以一种前所未有的速度和力量成长。

计算技术领域的年度盛会 CNCC 将于 10 月 22-24 日在北京盛大召开，届时10月23日下午，“数据库领域校企合作探索”论坛将在北京新世纪日航饭店（主会场）举办，本次论坛邀请了四位行业资深技术专家及学界泰斗带来精彩演讲，从国产数据库在产业实践的经验体会分享，到全新的产教研融合创新模式的探讨，再到数据库行业人才生态战略的深入探索。

本论坛将为大家邀请业界及学界共同探讨如何通过产研合作，充分发挥企业业务场景和高校研究能力的优势，突破核心技术、人才培养等难题，实现中国数据库产业自主创新。

论坛议程

16:00-16:40 杨传辉 蚂蚁集团
蚂蚁集团数据库产业实践

16:40-17:10 钱卫宁 华东师范大学
应用驱动与产教研联动的数据库研发和人才培养实践

17:10-17:40 彭智勇 武汉大学
国产数据库研制人才培养实践

17:40-18:00 梁刘红 蚂蚁集团
构建 OceanBase 全连接的学术合作与人才培养的生态圈

议题简介

嘉宾一：杨传辉（花名：日照）

嘉宾介绍：蚂蚁集团资深总监、OceanBase 研发总经理，全面负责 OceanBase 研发工作。作为 OceanBase 创始成员和首席架构师，主导了 OceanBase 技术架构设计，实现分布式数据库在核心金融场景零的突破，完成蚂蚁集团核心数据库100%上 OceanBase ，主导 OceanBase TPC-C 测试并打破世界纪录。曾在百度负责云存储与云计算系统研究工作，著有专著《大规模分布式存储系统：原理与实践》。

演讲议题：蚂蚁集团数据库产业实践

议题介绍：蚂蚁集团为何选择自研数据库，自研数据库从0到1的发展历程、技术方案以及后续规划，并分享国产数据库从学术研究到产业实践的经验体会。

嘉宾二：钱卫宁

嘉宾介绍：华东师范大学教授、博士生导师，数据科学与工程学院院长。在复旦大学获得计算机科学与技术学士、硕士与博士学位。上海市优秀学术带头人，入选教育部新世纪人才计划和上海市青年科技启明星计划。作为项目负责人主持包括国家“核高基”重大专项课题、国家重点研发计划课题、国家自然科学基金项目重点项目和面上项目在内的多项科研项目。

目前担任中国计算机学会数据库专委会常务委员，教育部人工智能科技创新专家工作组成员。曾获国家科技进步二等奖奖1次（第二完成人）、上海市科技进步一等奖1次（第一完成人），以及教育部科技进步一等奖、二等奖、教育部自然科学二等奖各1次。研究兴趣包括可扩展事务处理，大数据管理系统基准评测，海量数据分析处理及其应用，以及计算教育学。

演讲议题：应用驱动与产教研联动的数据库研发和人才培养实践

议题介绍：数据库系统是支撑关键核心业务（mission-critical applications）的基础软件。在诸多领域数字化转型的背景下，数据库系统面临着海量数据和互联网级负载的双重压力。自主研发数据库系统，助力行业转型，实现替代工程，无论是对于这些行业领域，还是对于我国的信息技术产业，都具有极为重要的意义。

数据库系统研发的基础知识面广、研究-工程-应用链条长，涉及大规模分布式系统和新硬件利用与优化等前沿技术，需要创新性研究思路，需要核心技术攻坚，还需要大规模工程实现验证，是典型的工程研究问题。报告将介绍我们在应用驱动和校企联动的分布式数据库系统研究和人才培养方面的探索和初步成果，并讨论新的产教研融合创新模式。

嘉宾三：彭智勇

演讲议题：国产数据库研制人才培养实践

议题介绍：研制国产数据库需要大量掌握数据库内核实现技术人才。目前国内各大高校数据库教学过于偏重原理性知识传授以及特定数据库系统的应用技能培养，而忽视了对于数据库管理系统内核实现机制的教学。我们构建了“基础知识-应用技术-科研创新”的分层次数据库教学体系，引进美国斯坦福“数据库系统实现”课程，自编“数据库内核分析”课程教材，引导学生分析数据库管理系统 PostgreSQL 源代码，指导学生参与国产数据库核心技术开发，为华为、阿里、腾讯、百度等企业培养了很多国产数据库研制人才。

嘉宾四：梁刘红

嘉宾介绍：现任蚂蚁集团 OceanBase 合作伙伴和生态合作部总经理。复旦大学计算机系硕士研究生毕业，加入 OceanBase 前，先后供职于微软、IBM，本土云计算创业公司青云 QingCloud，拥有15+年云计算领域及企业软件行业的丰富经验，擅长战略规划，生态合作、商业运营等。

演讲议题：构建 OceanBase 全连接的学术合作与人才培养的生态圈

议题介绍：蚂蚁集团 OceanBase 期望构建全联接的学术和人才生态，助力学术界产研实践和人才培养，与各大高校共同培养兼具理论与实践能力的创新型复合人才。本次报告将发布全连接的学术和人才生态战略。

其中，OceanBase 的研发总经理杨传辉及生态合作部总经理梁刘红也将分别从数据库技术产业发展、数据库产业人才培养等维度为大家带来 OceanBase 的经验分享。

据悉，今年9月，OceanBase 已经与华东师范大学签署战略合作，共建“华东师范大学－北京奥星贝斯分布式数据库联合实验室”，未来 OceanBase 还将连接更多的高校联合培养优秀的科技人才。

OceanBase 坚定地相信分布式数据库就是未来的主流。OceanBase 愿意也期待积极地通过自身实践来加速新的数据库生态的建立，以帮助更多的开发者 / DBA 更好地成长，为社会输出更多的分布式数据库人才。

目前行业内OLTP类的数据库单库单表支撑不了几十亿数据的在线处理，包括一些NoSQL数据库，因此对于数据量较大的场景需要进行数据库拆分，如mysql单表建议数据量再500w以内，一些强大的NoSQL单表可以支撑几亿的数据量，但是对于几十亿的数据量一样无法直接支撑，因此我们要做分库分表

    垂直切分是将一个表的不同属性切分到不同的表中，可以将访问频率高的、长度短的、或者经常一起访问的放在一个表里，

其它的放在另一个表里，从而提升数据库本身缓存的命中率来提升性能，但是单表大数据量依然存在性能瓶颈问题。
•水平拆分：借用分布式的优势，使用多个数据库的能力来提升存储容量和性能。

将数据均匀的分布在多个数据库多个表中

1. 拆分键的选择

拆分键是水平分库分表的关键，怎么选择拆分键是能否做好分库分表的关键

1）找到业务主体，确保核心的数据库操作都是围绕这个主体数据进行，然后使用该主体对应的字段作为拆分键

1）选择拆分键的核心是要保证数据量均匀和请求量均匀

2）要考虑热点查询语句，尽量保证其不会进行跨库查询

3）要兼顾关联表，尽可能保证关联表的分库分表规则和主表一致

1. 非拆分键的加速查询

1）多维度表法：如订单表，本身按照订单进行拆分，按照实际场景又分别按照买家和卖家生成订单表

2）缓存映射法：缓存中记录查询条件->拆分键的映射关系，如fpdm+fphm -> fpid

3）基因融入法: 将查询条件融入到拆分键生成中，如假设分8个库，采用id%8路由，潜台词是，id的后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的基因。

name -> 基因生成函数 -> name_gene -> 3bit

id(64 bit) = 生成全局唯一id（61 bit）+ 3bit

4）数据冗余法：使用外置索引（搜索引擎）或者大数据处理（如hive、hbase）来冗余数据进行解决

1. 分库分表的查询过程

分库分表的查询一般使用DRDS、MyCat等中间件来实现，但是用哪款中间件不重要，重要的是我们要了解其核心原理，原理是基础，其他都是表现形式，有了内功之后做什么都无往不利，如令狐冲独孤九剑+吸星大法+易筋经

1）分片规则：自定义分片策略，主要是根据拆分键值计算出将该条数据放在哪个库哪个表里

2）JDBC规范重写：针对DataSource、Connection、Statement、PreparedStatement和ResultSet接口封装，对外提供的是逻辑实例，在内部封装多个真实物理实例实现类集合

3）sql解析：解决sql语法，可以直接使用druid的SQLParser

4）sql改写：修改逻辑表名->真实表名；替换不支持的功能，如：avg->sum和count；有可能一条sql语句变成多条，如avg查询会变成 2 * 分表数 的sql语句

5）sql路由：单表路由（不一定落在单表上，如in、between查询）、binding表路由（路由规则一致，如fpzxx和fpmx）、笛卡尔积路由（两个关联表路由不一致，性能很低，占用连接数很高，一般不使用）

6）sql执行：多线程并发执行sql

7）结果归并：遍历类、排序类（归并排序）、聚合类（比较型、累加型、平均型）、分组类

订单场景是人们高频接触的一类场景，无论是线下商场购物、吃喝玩乐消费，还是线上淘宝、会员充值、外卖预定。只要涉及人就会有交易，只要有交易就会产生订单。毫不夸张的讲，所有的应用都会涉及到支付与订单的管理，因此，完善的订单管理架构是每一个架构师或开发人员都要直面的挑战。

对于订单系统，保证事务与强一致是前提，架构师们通常都会选择MySQL等TP型数据库。但是遇到大规模数据场景下也不得不面临一定的问题。首先，需要通过分库分表等方式提供一个分布式能力提升数据库数据存储、吞吐量，其次数据量大对于查询与聚合等需求难以支持，严重会影响表服务能力与性能。但是在大规模数据下，订单的多维检索、订单分析、以及周期性报表等需求，也是不能够舍弃的。因此需要一个历史订单库，将订单数据派生到其他存储引擎，从而拓展数据的查询、分析、聚合等能力。

这时，用户会考虑数据双写、数据同步等方式将数据派生一份到搜索引擎或其他NoSQL分布式数据存储，来扩展MySQL性能成本非常高的使用场景。多写的方案一般很少，这对写入一致性项目运维成本与写入性能会有很大的挑战。当前，更被大众所接受的是基于TP数据库的binlog订阅做数据同步，虽然数据同步上会有延时（通常秒级别甚至更低），但是在运维成本、能力扩展、数据一致性上表现优异。

DTS+Tablestore方案

本文主要介绍一套基于DTS与Tablestore实现一套完善的订单系统架构。实时订单数据主要针对用户侧的实时生产与修改，实例订单数据则是基于数据同步服务DTS，全、增量订阅TP库中的订单数据，从而保证Tablestore中数据与TP库数据的最终一致性。异步同步的方式不可避免的存在延时，但历史订单库在实时性上要求会适当放宽，但其派生出来的数据在服务能力与功能扩展上得到了极大的提升，尤其是Tablestore这种分布式服务能力强、下游计算生态丰富的NoSQL存储服务。

系统架构设计

系统架构如下图，架构基于订单数据的使用功能与实时性分两部分：实时在线订单数据与历史订单数据。

• • 在线订单数据：存储在TP型数据库，如MySQL、PolarDB等，用于保证订单的强事务能力；
• • 历史订单数据：存储在Tablestore，分布式存储，支持多维检索与聚合能力，拥有完善的大数据生态；
• • 同步链路：DTS（数据传输服务），支持全量数据迁移与实时数据同步，实时同步延时秒级别；
  

Tablestore的能力与生态

Tablestore的服务性能、分析查询能力以及下游生态，值得着重强调，丰富的能力扩展正是数据派生的核心价值。这里主要展示多元索引、大数据生态两个亮点，更多Tablestore场景与功能，请参考《表格存储Tablestore权威指南》

• • 多元索引：
  基于倒排索引和列式存储，可以解决大数据的复杂查询难题，包括非主键列查询、全文检索、前缀查询、模糊查询、多字段自由组合查询、嵌套查询、地理位置查询等功能。适用于元数据管理、历史订单维护、地理围栏等场景。

深入了解多元索引：多元索引官网文档、《TableStore发布多元索引功能，打造统一的在线数据平台》

• • 大数据架构
  Tablestore 作为一款高性能低成本的存储引擎，海量的数据存储伴随的就是大数据生态对接，并已经形成了一套稳定、高性能的大数据架构，产品在核心功能的升级迭代的过程中，也不断的加强计算引擎对接，目前已经对接了阿里云几个核心计算引擎，包含：MaxCompute、EMR Spark、Blink、DLA 、FC，更总结出一套流批一体处理框架（Lambda plus）。

深入了解数据中台、大数据体系：《数据中台之结构化大数据存储设计》、《基于 Tablestore 的大数据分析 Lambda 架构 - 云原生、弹性、流批一体》
架构搭建实战

准备工作

1、服务准备

• • 开通RDS服务：并购买MySQL实例，此处不做详细介绍，可参考《文档》；
• • 开通Tablestore服务：创建实例（免费），不做详细介绍，可参考《文档》；
• • 开通DTS服务：并购买MySQL同步Tablestore实例
  目前仅上线MySQL、PolarDB到Tablestore，其中PolarDb需要主动开启binlog开关才能支持增量同步。Tablestore暂时开发上海、北京、深圳，本例使用上海实例。

2、资源准备

创建子账号AccessKey

并对子账号实例级别授权，权限为操作Tablestore资源权限，让DTS有权限操作用户该实例资源（注意region跟实例名）

• • 创建子账号
  
• • Tablestore实例授权

{
    "Version": "1",
    "Statement": [
        {
            "Action": "ots:*",
            "Resource": "acs:ots:[myInstanceRegion]:*:instance/[myInstanceName]/*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "ots:ListInstance",
                "ots:GetInstance"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

建表语句

/******************************************/
/*   DatabaseName = dts_demo   */
/*   TableName = order_contract   */
/******************************************/
CREATE TABLE `order_contract` (
  `oId` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单id',
  `createTime` datetime NOT NULL COMMENT '下单时间',
  `payTime` datetime DEFAULT NULL COMMENT '支付时间',
  `hasPaid` tinyint(1) NOT NULL COMMENT '是否支付',
  `cId` varchar(20) NOT NULL COMMENT '消费者id',
  `cName` varchar(20) NOT NULL COMMENT '消费者姓名',
  `pBrand` tinytext NOT NULL COMMENT '产品品牌',
  `pCount` mediumint(10) NOT NULL COMMENT '产品数量',
  `pId` varchar(20) NOT NULL COMMENT '产品id',
  `pName` varchar(20) NOT NULL COMMENT '产品名',
  `pPrice` decimal(10,2) NOT NULL COMMENT '产品价格',
  `sId` varchar(20) NOT NULL COMMENT '售货员id',
  `sName` varchar(20) NOT NULL COMMENT '售货员姓名',
  `totalPrice` decimal(10,2) NOT NULL COMMENT '总价格',
  PRIMARY KEY (`oId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='在线订单表';

用户下单

直接通过sql写入，模拟用户下单与应用订单数据写入

INSERT INTO order_contract (oId, payTime, createTime, hasPaid, cId, cName, pBrand, pCount, pId, pName, pPrice, sId, sName, totalPrice)
VALUES 
("00000001", null, "2020-08-05 11:11:11", false, "c00001", "消费者1", "iphone", 1, "p00001", "iphone 7 plus",  9999.80, "s00001", "售货员1", 9999.80),
("00000002", null, "2020-08-05 12:11:11", false, "c00001", "消费者1", "iphone", 1, "p00002", "iphone 8 plus",  10999.80, "s00001", "售货员1", 10999.80),
("00000003", null, "2020-08-05 13:11:11", false, "c00002", "消费者2", "小米", 2, "p00010", "小米 7 plus",  999.81, "s00001", "售货员1", 1999.62);

同步配置

• • 配置DTS实例
  
• • 配置目标、源配置
  
• • 配置同步表、字段与类型转换
  

字段类型映射不建议全部选用默认，根据需求做定制，其中Boolean在MySQL中表现为tinyint(1)，需要主动设置成Boolean，时间默认使用String如需转换为时间戳，目标类型主动配置成Integer类型。

启动任务

启动并进入预检

预检完成会自动进入结构迁移（初始化建表）、全量迁移、增量同步阶段。然后用户可以基于DTS控制台查看结构迁移与同步状态。

目标检查

结构迁移

结构迁移完成，Tablestore实例下表初始化成功，主键符合预期

存量数据

进入存量阶段，开始同步MySQL库已有数据，同步成功后目标库数据可见。

增量校验

使用样例中的SQL模拟下单、更新订单、删除订单等操作，观察Tablestore实例中表的数据变化

下单

INSERT INTO order_contract (oId, payTime, createTime, hasPaid, cId, cName, pBrand, pCount, pId, pName, pPrice, sId, sName, totalPrice)
VALUES ("00000004", null, "2020-08-05 11:11:11", false, "c00003", "消费者3", "iphone", 1, "p00001", "iphone 7 plus",  9999.80, "s00001", "售货员1", 9999.80);

支付修改订单状态

update order_contract set payTime = "2020-08-05 21:11:11", hasPaid = true WHERE oId = "00000004";

删除数据

DELETE FROM order_contract WHERE oId = "00000004";

扩展能力

多元索引聚合查询

多元索引对于历史订单的管理，我们曾给出过最佳实践，用户可以参考《基于Tablestore打造亿量级订单管理解决方案》与控制台样例了解功能使用的详细方案。您只需在Tablestore相应的表中直接创建多元索引，便可完成历史订单数据的多条件组合查询、模糊查询、地理位置查询、存在性查询、简单的统计聚合与分析等。通过对产品名做分词，支持模糊查询能力，实例中查询"iphone"关键字，会从全量订单数据中检索出相应的2行数据。

多元索引的订单实战样例，可以参考文章《基于Tablestore打造亿量级订单管理解决方案》，并提供了直观感受的demo样例，如下图。用户可以参考借鉴。

除了多维组合查询，多元索引还是统计、聚合的能力，该能力没有在控制台上暴露，需要通过sdk使用，这里暂不距离，具体使用，可以参考《文档：多元索引的统计聚合》。
使用统计聚合功能可以实现求最小值、求最大值、求和、求平均值、统计行数、去重统计行数、按字段值分组、按范围分组、按地理位置分组、按过滤条件分组、嵌套查询等；同时多个统计聚合功能可以组合使用，满足复杂的查询需求。

流批一体的电商大屏

订单对于电商场景的最根本数据源，如何让海量的订单数据易分析、易可视化是场景的重要需求点，电商大屏或周期交易报表是最直接的数据价值挖掘的方式。这里以大屏为例，大屏可以包含全量订单、实时订单的聚合，全量订单的聚合提供的是全景的综合数据视图，而实时订单的聚合展示的是实时的运营指标数据。
谈完流批计算对数据价值挖掘的作用，就要见一下实现。Tablestore已经拥有较多的实战案例与架构文章，这里不做重复输出，用户可以直接前往文章《Tablestore结合Spark的流批一体SQL实战》，了解构建方案与效果。大屏效果如下图。

免费专家服务

欢迎加入Tablestore社区了解产品或参与讨论，更多文章欢迎前往《表格存储Tablestore权威指南》。
表格存储 (Tablestore) 提供专业的免费的技术咨询服务，期待您的加入。群号 : 23307953

-阿里云数据中台官网 https://dp.alibaba.com/index

作者：柯根

从整体上看，数据中台体系架构可分为：数据采集层、数据计算层、数据服务层三大层次。通过这三大层次对上层数据应用提供数据支撑。

数据采集层

对于企业来说，每时每刻都在产生海量的数据，数据采集作为数据体系第一环尤为重要。

因此在数据采集层需要建立了一套标准的数据采集体系方案，并致力全面、高性能、规范地完成海量数据的采集，将其传输到大数据平台。

互联网日志采集体系包括两大体系：Web端日志采集技术方案；APP端日志采集技术方案。

在采集技术之上，企业可以用面向各个场景的埋点规范，来满足日志数据打通等多种业务场景。同时，还可以建立了一套高性能、高可靠性的数据传输体系完成数据从生产业务端到大数据系统的传输；在传输方面，采集技术可既包括数据库的增量数据传输，也包括日志数据的传输；既需要能支持实时流式计算、也能实时各种时间窗口的批量计算。另一方面，也通过数据同步工具直连异构数据库（备库）来抽取各种时间窗口的数据。

下图展示数据采集层在数据分层中的位置：

数据计算层

从采集系统中收集了大量的原始数据后，数据只有被整合、计算才能被用于洞察商业规律、挖掘潜在信息，实现大数据价值，达到赋能商业、创造商业的目的。从采集系统中收集到的大量原始数据，将进入数据计算层中被进一步整合与计算。

面对海量的数据和复杂的计算，数据计算层包括两大体系：数据存储及计算云平台和数据整合及管理体系。

- 数据存储及计算云平台
例如，MaxCompute是阿里巴巴自主研发的离线大数据平台，其丰富的功能和强大的存储及计算能力使得企业的大数据有了强大的存储和计算引擎；StreamCompute是阿里巴巴自主研发的流式大数据平台，在内部较好地支持了企业流式计算需求。

- 数据整合及管理体系
“OneModel”是数据整合及管理的方法体系和工具，大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致，充分发挥在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，构建企业数据公共层，并可以帮助相似大数据项目快速落地实现。

数据中台数据加工链路也是遵循业界的分层理念：包括操作数据层（ODS，Operational Data Store）、明细数据层(DWD，Data Warehouse Detail)、汇总数据层(DWS, Data Warehouse Summary)和应用数据层(ADS，Application Data Store)。通过数据中台不同层次之间的加工过程实现从数据资产向信息资产的转化，并且对整个过程进行有效的元数据管理及数据质量处理。

下图展示数据公共层（ODS+DWD+DWS）与数据应用层（ADS）在数据分层中的位置：

图：数据公共层与数据应用层关系

（1）统一数据基础层
我们通过各种方式采集到的丰富数据，在清洗、结构化后进入统一的ODS数据基础层。

其主要功能包括：
-同步：结构化数据增量或全量同步到数据中台
-结构化：非结构化(日志)结构化处理并存储到数据中台
累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、数据清洗

在权责方面，所有数据应该在源头统一，统一所有的数据基础层，并由一个团队负责和管控，其他团队无权复制数据基础层的数据。

（2）数据中间层
我们进行数据建模研发，并处理不因业务特别是组织架构变动而轻易转移的数据中间层。包括DWD明细数据中间层和DWS汇总数据中间层。

其主要功能包括：
-组合相关和相似数据： 采用明细宽表，复用关联计算，减少数据扫描。
-公共指标统一加工：基于OneData体系构建命名规范、口径一致和算法统一的统计指标，为上层数据产-品、应用和服务提供公共指标；建立逻辑汇总宽表；
-建立一致性维度：建立一致数据分析维度表，降低数据计算口径、算法不统一的风险。

在权责方面，面向业务提供服务之前，由统一的团队负责从业务中抽象出源于业务而又不同于业务的数据域，再主导统一建设数据中间层，包括侧重明细数据预JOIN等处理的明细中间层、侧重面向应用可复用维度和指标的汇总数据中间层。特别是要由唯一团队负责将核心业务数据统一加入数据中间层。允许部分业务数据有独立的数据团队按照统一的OneModel体系方法论建设数据体系，ODS数据基础层和DWD+DWS数据中间层因其统一性和可复用性，被称为数据公共层。

（3）数据应用层
在面向应用提供服务时，业务团队或深入业务线的数据团队有极大的自由度，只要依赖数据公共层，即可自由的建设ADS数据应用层。

其主要功能包括：
-个性化指标加工：不公用性；复杂性（指数型、比值型、排名型指标）
-基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串

数据服务层

当数据已被整合和计算好之后，需要提供给产品和应用进行数据消费，为了更好的性能和体验，需要构建数据服务层，通过接口服务化方式对外提供数据服务。针对不同的需求，数据服务层的数据源架构在多种数据库之上，如Mysql和Hbase等。

数据服务可以使应用对底层数据存储透明，将海量数据方便高效地开放给集团内部各应用使用。如何在性能、稳定性、扩展性等多方面更好地服务用户；如何满足应用各种复杂的数据服务需求；如何保证数据服务接口的高可用。随着业务的发展，需求越来越复杂，因此数据服务也在不断地前进。

不管是数据公共层还是应用层，最终都需要面向业务提供服务。为了让业务部门找数据、看数据、用数据更加方便，我们将OpenAPI升级为能缓解业务变化对数据模型冲击的包括方法论+产品在内的OneService体系，使其在提供统一的公用服务的同时，兼容面向个性化应用的服务。

下图为数据服务层在数据分层中的位置：

图：数据应用层与数据服务层关系

综上，企业数据中台依托数据采集层、数据计算层、数据服务层，为上层数据产品、业务系统等提供数据支撑。云上数据中台产品Dataphin从“采、建、管、用”为企业提供一站式数据中台各层次的实现，配合阿里云系列产品，可实现企业数据中台全链路稳定、高效构建。

数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。

目前正通过阿里云对外输出系列解决方案，包括通用数据中台解决方案、零售数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。

其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包括：

• - Dataphin，一站式、智能化的数据构建及管理平台；
• - Quick BI，随时随地 智能决策；
• - Quick Audience，全方位洞察、全域营销、智能增长；
• - Quick A+， 跨多端全域应用体验分析及洞察的一站式数据化运营平台；
• - Quick Stock， 智能货品运营平台；
• - Quick Decision，智能决策平台；

官方站点：
数据中台官网 https://dp.alibaba.com
钉钉沟通群和微信公众号

大家好，为帮助大家更好的找到适合的岗位，拿到心仪公司的offer，社区收集了多家实时计算及 Flink 企业用户的招聘需求，如：知乎、VIPKID、新氧、作业帮、得物、好未来、阿里巴巴等招聘信息，整理如下，供大家参考。

欢迎更多企业投递实时计算及 Flink 相关招聘信息，更欢迎 Flink 专家、技术爱好者自荐。相关需求可联系小松鼠（微信 ID:Ververica2019）。

本期招聘企业及岗位如下，找工作或有意向换工作的同学快到碗里来！

知乎 | 大数据实时处理平台研发工程师
VIPKID | 实时计算研发工程师
得物APP | 实时数据开发
作业帮 | 实时计算架构研发工程师
新氧科技 | 大数据开发工程师
好未来 | 实时计算 Flink 专家岗 / 数据平台开发 - Flink 实时&离线岗
阿里云计算平台事业部 | 研发工程师

知乎：大数据实时处理平台研发工程师

知乎数据架构团队正在围绕 Apache Flink 为核心打造大数据实时计算平台，为知乎内部业务提供批流融合的大数据计算能力，加入知乎数据架构团队共同探索新一代的大数据技术。欢迎大家推荐简历！

岗位描述

1. 参与 Apache Flink 的二次开发，建设 Flink 批流融合大数据计算引擎
2. 深入理解业务并与业务部门密切合作，基于 Apache Flink + Kubernetes 建设知乎的实时计算平台

岗位要求

1. 计算机、通信、数学等相关专业，具备良好的计算机技术基础
2. 熟悉 Java，具备扎实的数据结构和算法基础
3. 具备良好的沟通和团队协作能力，做事主动积极，有技术热情和激情面对挑战
4. 深入理解 Flink 或 Spark Streaming 原理者优先
5. 有 PB 级数据处理经验和实时计算平台开发经验者优先
6. 熟悉 Hadoop Ecosystem 例如 -- Flink/Spark/Hadoop/Hive/Kafka/Pulsar 以及 Kubernetes，向社区贡献过代码者优先

简历投递

• 工作地点：北京
• 简历投递：sunxiaoguang@zhihu.com

VIPKID：实时计算研发工程师

岗位职责

1.参与实时计算平台建设和架构设计开发，维护与优化；
2.负责海量数据的采集，清洗等工作。

岗位要求

1.5年以上工作经验;
2.熟练掌握hadoop、spark、storm、flink等大数据相关组件，深入理解系统原理，并有丰富Flink开发及运维经验
3.精通数据采集、实时计算
4.3年以上的Java或scala开发经验(熟练使用java、scala、python等开发语言);
5.了解数据结构及算法（基本算法即可）
6.具有较强的学习能力，自我管理能力、驱动能力

加分项：

有过主导和设计实时计算平台的系统规划，并落地的经验优先

简历投递

• 工作地点：北京
• 简历投递：yangliang@vipkid.com.cn

得物APP：实时数据开发

岗位职责

负责公司实时相关的业务数据统计需求的开发，包括实时数仓，标签体系，日志和业务数据的etl等工作。

岗位要求

1. 熟悉 Java、Scala 中至少一门语言，熟练使用 SQL。
2.有大数据组件使用经验，熟悉大数据相关技术，如 Spark、Flink、HBase、Hive、Clickhouse 等。
3. 使用 Flink 开发过复杂业务，熟悉 Datastream 和 Table/Sql API，有flink 作业线上调优经验优先。
4.良好的业务理解能力和沟通表达能力，主动性强。

简历投递

• 工作地点：上海市杨浦区互联宝地
• 简历投递：luoziyu@theduapp.com

作业帮：实时计算架构研发工程师

岗位职责

1. 负责作业帮业务数据内容规划和设计，实现数据互通共享体系，解决海量数据面临的挑战；
2. 负责公司流量数据OLAP引擎和实时计算框架的设计、开发和优化，构建实时数据的公共层；
3. 负责Spark、Flink集群的管理和优化，保证集群持续稳定；
4. 根据业务需求进行上游数据平台设计开发，打造高可用的数据平台；

岗位要求

1. 有一线互联网公司2年数据开发经验，或独立负责大中型业务大数据实时架构的经验；
2. 熟悉Linux系统，具备Java/Scala/Python等一种或几种语言的开发能力；
3. 熟悉Flink/Spark/Kafka/Presto/Hadoop/HBase等大数据相关技术，对源码有研究或者有调优经验者优先；
4. 熟悉并行计算或者分布式计算原理，熟悉高并发、高稳定性、海量数据的系统特点和技术方案；
5. 有大数据系统平台项目经验，掌握实时数据处理系统搭建和开发；
6. 学习能力强，热衷开源技术，有团队观念，具备独立解决问题的能力；

简历投递

• 工作地点：北京
• 简历投递邮箱：zhangying14@zuoyebang.com

北京新氧科技有限公司：大数据开发工程师

岗位职责

1. 负责新氧实时业务数据支撑；
2. 主要参与新氧流量、内容、电商、会员等各主题域实时数据仓库开发。
3. 负责实时数据仓库程序上线并持续迭代优化以及日常运维

岗位要求

1. 本科以上，计算机相关专业；
2. 3年以上的大数据研发经验，有flink实时作业开发部署调优经验。对kafka有较深入研究，对性能调优、故障恢复有一定的处理经验。
3. 熟悉Linux操作环境，有良好的至少一门语言 (Java、Scala) 开发调试经验；
4. 熟悉大数据开发相关技术，如hadoop、hive、spark、kafka、 spark streaming、Flink等；
5. 熟练数据仓库，对多维数据建模有深入理解；
6. 对数据系统热爱，乐于解决具有挑战性的问题, 具备优秀的分析问题、解决问题能力；

简历投递

• 工作地点：北京
• 简历投递：gaohongchao@soyoung.com；liuyuquan@soyoung.com

好未来：实时计算 Flink 专家岗 / 数据平台开发 - Flink 实时&离线岗

实时计算 Flink 专家岗

岗位职责

1.负责行业实时计算开发平台的架构设计，完善实时计算方案
2.支撑公司内部的实时业务开发
3.对 Flink 以及周边技术进行源码级探索改进

岗位要求

1.有实时计算引擎设计项目经验，并能完成相应系统设计研发
2.有丰富的Flink线上部署/日常运维/性能分析/故障定位能力
3.精通 Java 编程语言，计算机基础知识（网络/操作系统/分布式基础等）扎实
4.有过 SQL 引擎开发经验，或者对编译原理有所了解
5. 有过完整实时开发平台项目经验者优先

简历投递

• 工作地点：北京
• 简历投递：liuwenlin@tal.com

数据平台开发：Flink 实时&离线岗

岗位职责

离线

1.参与集团数据中台大数据基础设施建设
2. 负责大数据生态组件的调优和二次开发
3. 负责大数据平台开发套件相关子系统开发

实时

1.实现行业实时计算开发平台
2. 支撑公司内部的实时业务开发
3. 对flink以及周边技术进行源码级探索改进

岗位要求

1.3-5年相关工作经验，计算机相关专业本科以上学历
2.精通java语言，熟悉常用设计模式、主流开发框架，3年以上相关开发经验；

离线

1.参与过大数据开发套件产品的后端开发者优先，包括大数据离线任务调度系统，元数据管理系统，数据质量系统等。
2. 熟悉Hadoop集群及相关生态组件（HDFS、Zookeeper、YARN、Hive、Spark、Kerberos、AirFlow、Flink、Presto、Kudu等），有调优和二次开发经验者优先。
3. 熟悉集群权限控制及开发者优先
4. 熟悉数据安全管理和实践经验优先

实时

1. 有实时计算引擎设计项目经验，并能完成相应系统设计研发
2. 有丰富的Flink线上部署/日常运维/性能分析/故障定位能力
3. 有过SQL引擎开发经验，或者对编译原理有所了解
4. 有过完整实时开发平台项目经验者优先

简历投递

• 工作地点：北京
• 简历投递：liuwenlin@tal.com

阿里云计算平台事业部：研发工程师

团队介绍

1. 基于Hadoop、Spark、Hive、HBase、Flink，Kafka，TensorFlow等开源大数据组件，构建云原生大数据平台，提供大规模计算能力；
2. 提供一站式大数据应用开发平台, 包括大数据安全体系，数据治理，作业调度，交互式查询，专项领域监控，通过机器学习算法帮助用户智能诊断复杂问题；
3. 打造世界顶级的开源大数据平台，在公共云、裸机、私有云和混合云等环境, 为阿里云客户提供云原生大数据全家桶服务；
4. 参与阿里云城市大脑、智慧交通等多项国家战略项目建设，利用实时/批技术处理真实世界中的海量数据。

职位描述

1. 计算机、通信、数学等相关专业，具备良好的计算机技术基础；
2. 熟悉Java/C++/Python/GO等至少一种编程语言，具备扎实的数据结构和算法基础；
3. 具备良好的沟通和团队协作能力，做事主动积极，有技术热情和激情面对挑战；
4. 熟悉主流JAVA框架，包括spring、netty、mybatis等技术者优先；
5. 熟悉Hadoop/Spark/Flink/Storm/HBase/Hive/Kafka/TensorFlow/Kubernetes/Prometheus技术者优先。

简历投递

• 工作地点：北京
• 简历投递：wali.rcd@taobao.com

▼ 实时计算 Flink 技术交流群 ▼

9月10日，陈洪进与来自全国各地的36家大型企业的43位信息化高管共聚美丽的北国春城，参加由阿里巴巴与中国一汽联合举办的阿里CIO学院走进一汽共创会，从智能制造、新营销和新IT三个角度探寻企业转型中的“数字化力量”。

活动期间，陈洪进与其他学员们就企业数字化转型进行了深入交流。会后，陈洪进接受CIO学院的新媒体访谈，他表示对传统的制造企业而言，数字经济带来的不是数字化转型，而是数字化升级，中国防水行业亟待拥抱数字化变革。

走进一汽感受数字化力量

在参加完走进一汽的活动后，陈洪进对两个内容感触较深：

第一，数字化工厂的实践。对传统的制造型企业而言，红旗数字化工厂不像媒体上宣传的各种类型的无人产线那么高不可攀，现场有很多人在不同工序从事各种作业，各种AGV设备也有明显地自行改造的影子，但通过优化现场流程实现了生产效率的大幅度提升。除了遍布全厂的AGV小车外，无人值守库房、工序配件的自动调度、车间电子看板取代纸质单据等内容，都令人印象深刻，值得借鉴。

第二，产品数字化在价值链上的拓展。一汽提出根据服务的价值链不同，构建不同的数字孪生主体，包括研发孪生、制造孪生、营销孪生、运营孪生等。当前传统制造型企业讨论的孪生大多偏重于设备领域，以设备模拟和预防性维护为主要方向，一汽的孪生理念拓展了产品数字化的边界，以产品为载体，整合企业价值链的各种数据形成适应每个价值模型的数字化产品，这种理念超越了对个别业务进行数字孪生的认知，对于指导制造型企业进行全面数字化转型具有很好的引领作用。

陈洪进在活动现场

凯伦股份全力加速数字化转型

凯伦股份是中国建筑防水行业首家创业板上市公司，缔造了传统制造领域民营企业6年上市的传奇速度。2017年上市至今，年复合增长率63%。

凯伦股份在信息化建设上具有前瞻性。2012年工厂投产即投用了定制的金蝶ERP系统，良好的支撑了企业运营和上市；上市后，2018年即着手实施Oracle ERP系统，于2019年1月1日顺利上线，支持了企业由单一工厂到多工厂、单一组织到多组织的快速发展。

2019至2020年进一步实施了MES、HR、BI、智能化大屏等系统。

凯伦的信息化面临的主要挑战是如何为公司的快速发展保驾护航，涉及集团管控、异地工厂管理、新业务模式涌现等课题。凯伦所在的行业是建材领域，面对的客户主要是传统的建筑工程市场客户，产品非常标准化，属于典型的“toB”业务，企业管理的重点是提升自身的运营效率。

根据如上情况，凯伦提出了“数字化运营，可视化管理”的信息系统三年战略目标，要求在经营、生产的全过程实现数字化，同时对每个职能通过报表、大屏等实现可视化管理。进而凯伦设定了核心的管控指标：部门KPI指标覆盖率，要求由系统出具考核数据的部门KPI指标占比60%以上。

数字化转型？数字化升级！

在下午举行的阿里CIO学院走进一汽共创会上，来自中国一汽数字化部、启明信息、阿里巴巴的6位讲师针对 “新制造”、“新基建”、“新营销”等话题进行了深度分享，深度讲解以云数智为代表新兴数字技术正在为汽车产业赋能，加速行业向智能化、电动化、网联化、共享化的出行服务转型。

陈洪进表示，对传统的制造企业而言，数字经济带来的不是数字化转型，而是数字化升级。以阿里为代表的互联网企业带来了很多新技术、新理念、新做法，值得传统制造企业借鉴。

2019年，阿里的“中台”概念火热却在制造业鲜有案例，关键原因应该是制造业中很少涉及一个公司内要在较短的时间内、由不同部门实现类似业务快速上线的应用场景。但在不到一年的时间内，苏州的一家企业使用中台、微服务的理念，以单点登录为切入点，重构了企业内部系统，极大提升了员工使用业务系统的效率；在一汽参观中，启明信息更是提出基于中台架构，通过微服务设计，将传统的ERP系统拆解成分布式、开放式和服务化的业务平台。

在当前各行各业都面临巨大挑战，业务的瞬息万变，要求对应的信息系统具有良好的弹性，开放化、服务化将成为永恒的主题。在这种背景下，中台、微服务的理念对于在现有的业务系统基础上，快速构建全新的业务支持系统具有重要的理念引导作用，无疑是阿里输出给社会的成功经验。架构中台化也将是凯伦未来三年要重点实现的技术目标。

在陈洪进看来，阿里还有很多如云平台、弹性计算这些可以直接使用的技术，阿里的管理理念也是当前企业管理界的热点。传统制造业应该充分借鉴和应用这些理念和技术，提升自身的管理能力和经营效率，加快转型和升级，以更好的状态参与市场竞争。

陈洪进参与圆桌论坛环节

数字化转型人才和开放合作至关重要

当前中国防水市场正在加速转型，目前规模每年2000亿元，绝大部分业务是toB业务，但头部企业已经涉足C端市场，直接面向消费者；同时，随着凯伦为代表的高分子防水市场的拓展，中国的防水行业深入参与国际市场竞争也是可以预见的未来。

在这种背景下，陈洪进认为，以下三个方面是防水行业数字化升级的主要内容：首先，以“提质、降本、增效”为核心的内部管理的数字化升级；其次，面向防水工程的施工过程管理的数字化升级；再次，面向家装领域即C端的业务模式、营销模式的数字化创新，未来防水行业的数字化升级的亮点就在这三个方向上。

更重要的是，传统制造型企业转型，对业务部门而言是理念的挑战，对IT部门而言是技术和业务的双重挑战，这可能是制造型企业的共同痛点。业务部门由于不懂IT技术，很难理解IT技术的边界，也很少会用IT的视角诠释业务需求，所以需要在理念上认同数字化；IT部门首先要立足业务需求解决业务问题，其次要用更合理的技术确保可扩展性，两个方面要兼顾。归根结底，企业需要培养数字化复合型人才，这是一个永恒的话题。

陈洪进指出，凯伦需要培育核心的数字化复合型人才，需要兼顾业务和IT技术。制造型企业的信息化往往不是技术创新驱动型，需要精通行业特点的人才，立足于业务本身，使用IT技术解决实际问题。防水行业如今整体信息化水平一般的问题核心是复合型人才稀缺。凯伦的目标不仅仅局限于国内市场，所以必须培养出核心的数字化复合型人才，才能支持各种可能的业务方向。

对于技术，陈洪进倾向于开放合作。他认为制造型企业不像互联网行业一样有众多精英IT人才。所以，凯伦应该有懂得IT边界的、精通业务流程的人才，能阐明业务需求，而对于业务的具体技术实现，可以根据实际情况选择。

在陈洪进看来，大数据和人工智能将会带来行业的巨变。他记得在此次参观中，一汽的领导在分享业务对象数字化的认识时，提出：一个设备，最早只是一个代码，不到1K的信息；当数据累计到10M时，可以支持设备的全生命周期管理；1G时，可以开展预防性维修；10G时，可以支持虚拟仿真。这个例子比较形象的说明了业务对象的数据累积到一定程度，大数据、人工智能等技术可以带来量变到质变的过程。

“因为相信，所以看见”，“仰望星空，脚踏实地”，陈洪进表示，阿里的这两句话最代表他对大数据、人工智能技术的感触。

阿里CIO学院应考虑建立行业分院

陈洪进：首先很感激阿里给CIO创造的这样一个公益平台，让大家有机会深入学习和了解阿里，也有机会互相学习。通过阿里CIO学院的组织走进中国一汽，观摩标杆企业的精益制造；领略前沿的数字化转型，学习先进的数字化方法论；专家老师全程相伴，并与阿里巴巴和中国一汽的数字化高管面对面交流，倾听实战分享、可谓一场完美的主题活动。

我觉得未来可以考虑行业分院的形式，让学员更加有针对性。同时也可以开展分院之间的交流互动，取长补短。

公司简介

凯伦股份是一家集防水材料研发、制造、销售及施工服务于一体的国家高新技术企业。先后获得“中国防水行业质量提升示范企业”、“中国房地产500强首选供应商”、“江苏省优秀企业”等荣誉称号。企业以“融合防水”为旗，于国内首创MBP高分子自粘胶膜防水卷材和白色抗流挂聚氨酯防水涂料，填补了国内高分子防水领域的技术空白，引领行业转型升级。2017年10月26日，凯伦股份实现A股上市，成为中国建筑防水行业首家创业板上市公司。

公司目前在华东、华北、华中和西南建有现代化生产基地，引进全套进口成型生产线和先进的胶体磨等设备，精细化和自动化程度达到国际同行先进水平。为快速响应市场，公司不断完善产业布局，在西北、华南和华东（新）投资建设产业基地，抓住长三角生态绿色一体化发展示范区机遇，在苏州建设世界一流的高分子防水材料生产基地。

秉承“精细化的融合、看得见的诚实”的经营理念，公司短短几年内把业务推向多个建筑防水领域，先后与万科、恒大、碧桂园、绿地等20多个龙头房地产建立战略合作关系，承接了多个高铁、地铁、隧道、核电站和地下管廊等防水项目；凯伦股份放眼全球，销售遍布美国、英国、德国、澳大利亚、以色列、新加坡、印度等60多个国家和地区。

凯伦股份坚守“高品质”和“绿色生产”的战略定位，致力成为国际领先的功能性建材制造商，以稳健的步伐，确保基业长青，效力百年建筑，造福人类，回馈社会。

文章来源：阿里飞天CIO学堂微信公众号

名人堂

名人堂是阿里CIO学院打造的一档大伽访谈栏目，每周一期。以推动企业创新与数智化升级为愿景，通过采访行业顶尖客户，帮你更好地了解和思考企业数字化转型中可能面临的挑战，梳理行业痛点和方法路径，从而相互滋养，共同成长。

更多文章

点击查看青岛华通集团智能研究院明磊：拥抱数字化转型正在成为CIO头等大事 | 阿里CIO学院名人堂>>>

点击查看ERIC，ZHANG：地产业数字化转型按下“加速键”美好人居正当时 | 阿里CIO学院名人堂>>>

点击查看李锋：联接数智化生态，打造“数字化越秀” | 阿里CIO学院名人堂>>>

点击查看龙湘君：基金行业奏响数字化转型五部曲 | 阿里CIO学院名人堂>>>

点击查看段晓力：从一个小目标的对立 到万个小目标的融合 | 阿里CIO学院名人堂>>>

点击查看贾坤：扶贫基金事业借数字化转型助力决胜脱贫攻坚战 | 阿里CIO学院名人堂>>>

点击查看郑荣：世界的香格里拉——从“藏在深闺无人识”到“网红旅游目的地” | 阿里CIO学院名人堂>>>

点击查看魏琴：前海再保险以科技创新打破保险行业传统疆域 | 阿里CIO学院名人堂>>>

点击查看王丽静：深挖“数据宝藏”打造新型高端智库 | 阿里CIO学院名人堂>>>

点击查看石廷洪：推动数字化转型 打造世界一流企业 | 阿里CIO学院名人堂>>>

点击查看韩海潮：数字化浪潮引领基金行业转型新方向 | 阿里CIO学院名人堂>>>

点击查看谢钧棋：以“数”转型 用“脉”管理 | 阿里CIO学院名人堂>>>

作者 | 张建飞  阿里巴巴高级技术专家

架构

什么是架构？

关于架构这个概念很难给出一个明确的定义，也没有一个标准的定义。

硬是要给一个概述，我认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。

架构始于建筑，是因为人类发展（原始人自给自足住在树上，也就不需要架构），分工协作的需要，将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作。

为什么需要架构？

有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件都需要设计和架构。

我很喜欢《系统架构：复杂系统的产品设计与开发》里面的一句话：结构良好的创造活动要优于毫无结构的创造活动。

与之相对应的，现在很多敏捷思想提倡 no design，只要 work 就好。期待好的架构可以在迭代中自然涌现。这个想法有点太理想化了，在现实中，只要能 work 的代码，工程师是很少有动力去重构和优化的。

架构师的职责

作为架构师，我们最重要的价值应该是“化繁为简”。但凡让事情变得更复杂，让系统变得更晦涩难懂的架构都是值得商榷的。

架构师的工作就是要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，使哪些系统不再那么难懂。我们应该努力构建易懂的架构，使得在系统上工作的其他人员（例如设计者、实现者、操作员等）可以较为容易地理解这个系统。

软件架构

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

软件架构的核心价值应该只围绕一个核心命题：控制复杂性。他并不意味着某个特定的分层结构，某个特定的方法论（贫血、DDD 等）。

软件架构分类

在介绍应用架构之前，我们先来看一下软件架构的分类。

随着互联网的发展，现在的系统要支撑数亿人同时在线购物、通信、娱乐的需要，相应的软件体系结构也变得越来越复杂。软件架构的含义也变得更加宽泛，我们不能简单地用一个软件架构来指代所有的软件架构工作。按照我个人理解，我将软件架构划分为：

业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。例如，阿里巴巴在没有中台部门之前，每个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688 等各有一套体系结构。而后，成立了共享平台事业部，打通了账号、商品、订单等体系，让商业基础实施的复用成为可能。

应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。

分布式系统架构：分布式系统基本是稍具规模业务的必选项。它需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP（Consistency，Availability，Partition tolerance）之间进行权衡。

数据架构：对于规模大一些的公司，数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准，是数据架构需要关注的问题。其目的就是统一数据定义规范，标准化数据表达，形成有效易维护的数据资产，搭建统一的大数据处理平台，形成数据使用闭环。

物理架构：物理架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

典型应用架构

分层架构

分层是一种常见的根据系统中的角色（职责拆分）和组织代码单元的常规实践。常见的分层结构如下图所示：

CQRS

CQS(Command Query Separation，命令查询分离)，最早来自于 Betrand Meyer（Eiffel 语言之父，OCP 提出者）提出的概念。其基本思想在于，任何一个对象的方法可以分为两大类：

• 命令(Command): 不返回任何结果(void)，但会改变对象的状态。
• 查询(Query): 返回结果，但是不会改变对象的状态，对系统没有副作用。

六边形架构

六边形架构是 Alistair Cockburn 在 2005 年提出，解决了传统的分层架构所带来的问题，实际上它也是一种分层架构，只不过不是上下，而是变成了内部和外部（如下图所示）。

六边形架构又称为端口-适配器架构，这个名字更容器理解。六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。

适配器分为两种类型（如下图所示），左侧代表 UI 的适配器被称为主动适配器（Driving Adapters），因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器，被称为被动适配器（Driven Adapters），因为它们只会对主适配器的操作作出响应。

洋葱圈架构

洋葱架构与六边形架构有着相同的思路，它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来，避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换，可以一定程度地避免技术、工具或者供应商锁定。

不同的是洋葱架构还告诉我们，企业应用中存在着不止两个层次，它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次（Application，Domain Service，Domain model，Infrastructure等）。

另外，它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利，这样可以使用 mock 代替它们方便测试。

在洋葱架构中，明确规定了依赖的方向：

• 外层依赖内层；
• 内层对外层无感知。

COLA 应用架构

COLA 架构是我团队自主研发的应用架构，目前已经开源。在 COLA 的设计中，我们充分汲取了经典架构的优秀思想。除此之外，我们补充了规范设计和扩展设计，并且使用 Archetype 的方式，将架构固化下来，以便可以快速的在开发中使用。

COLA 开源地址：https://github.com/alibaba/COLA

分层设计

COLA 的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示，左边是传统的分层架构，右边是 COLA 的分层架构。

其每一层的作用范围和含义如下：

1）展现层（Presentation Layer）：负责以 Rest 的格式接受 Web 请求，然后将请求路由给 Application 层执行，并返回视图模型（View Model），其载体通常是 DTO（Data Transfer Object）；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理；

4）基础实施层（Infrastructure Layer）主要包含 Tunnel（数据通道）、Config 和 Common。这里我们使用 Tunnel 这个概念来对所有的数据来源进行抽象，这些数据来源可以是数据库（MySQL，NoSql）、搜索引擎、文件系统、也可以是 SOA 服务等；Config 负责应用的配置；Common 是通用的工具类。

扩展设计

对于只有一个业务的简单场景，对扩展性的要求并不突出，这也是为什么扩展设计常被忽略的原因，因为我们大部分的系统都是从单一业务开始的。但是随着业务场景越来越复杂，代码里面开始出现大量的if-else逻辑。此时除了常规的策略模式以外，我们可以考虑在架构层面提供统一的扩展解决方案。

在扩展设计中，我们提炼出两个重要的概念，一个是业务身份，另一个是扩展点。

业务身份是指业务在系统唯一标识一个业务或者一个场景的标志。在具体实现中，我们使用 BizCode 来表示业务身份，其中 BizCode 采用类似 Java 包名命名空间的方式。例如，我们可以用“ali.tmall”表示阿里天猫业务，用“ali.tmall.car” 表示阿里天猫的汽车业务，而用"ali.tmall.car.aftermarket"代表这是阿里天猫的汽车业务的后市场场景。

每个业务或者场景都可以实现一个或多个扩展点（ExtensionPoint），也就是说一个业务身份加上一个扩展点，可以唯一地确定一个扩展实现（Extension）。而这个业务身份和扩展点的组合，我们将其称之为扩展坐标（ExtensionCoordinate），如下图所示。

这样，通过业务身份+扩展点，我们就可以从框架层面实现对不同租户，不同业务，不同场景的扩展定制了。整个阿里业务中台正是基于这个思想，实现的多业务支撑的。

规范设计

任何事物都是规则性和随机性的组合。规范的意义就在于我们可以将规则性的东西固化下来，尽量减少随心所欲带来的复杂度，一致性可以降低系统复杂度。从命名到架构皆是如此，而架构本身就是一种规范和约束，破坏这个约束，也就破坏了架构。

COLA 制定了一些列的规范：包括组件（Module）结构、包（Package）结构、命名等。

比如对于组件，我们要求使用 COLA 的应用都应该遵循如下图所示的组件划分：

COLA 架构总览

在架构思想上，COLA 主张像六边形架构那样，使用端口-适配器去解耦技术细节；主张像洋葱圈架构那样，以领域为核心，并通过依赖倒置反转领域层的依赖方向。最终形成如下图所示的组件关系。

换一个视角，从 COLA 应用处理响应一个请求的过程来看。COLA 使用了 CQRS 来分离命令和查询的职责，使用扩展点和元数据来提升应用的扩展性。整个处理流程如下图所示：

应用架构的核心

纵观上面介绍的所有应用架构，我们可以发现一个共同点，就是“核心业务逻辑和技术细节分离”。

是的，六边形架构、洋葱圈架构、以及 COLA 架构的核心职责就是要做核心业务逻辑和技术细节的分离和解耦。

试想一下，业务逻辑和技术细节糅杂在一起的情况，所有的代码都写在 ServiceImpl 里面，前几行代码是做 validation 的事，接下来几行是做 convert 的事，然后是几行业务处理逻辑的代码，穿插着，我们需要通过 RPC 或者 DAO 获取更多的数据，拿到数据后，又是几行 convert 的代码，在接上一段业务逻辑代码，然后还要落库，发消息.....等等。

再简单的业务，按照上面这种写代码的方式，都会变得复杂，难维护。

因此，我认为应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑可以反映领域模型和领域应用，可以复用，可以很容易被看懂。让技术细节在辅助实现业务功能的同时，可以被替换。

最后我们发现，应用架构的道就是：“让上帝的归上帝，凯撒的归凯撒。”

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

以下内容根据演讲视频以及PPT整理而成。观看回放
更多课程请进入“玩转ECS详情页”了解

本次分享主要围绕以下三个方面：

    一、云上部署和运维的特点
    二、资源编排ROS
    三、运维编排OOS

今天主要分享的内容是云上自动化部署和运维的正确姿势，下面先来看看云上部署相比于传统的RDC部署有哪些不同。

一、云上部署和运维的特点

无论是部署还是运维，在云上都有如下四个特点：

首先，可重复。在云上部署相对于传统RDC部署而言更加灵活，只需要编写一次模版就可以随时随地拉起一套环境，做到一键部署。目前有两种类型的环境部署，一种是测试环境、预发环境、生产环境。第二种是在不同地域进行部署，如北京地域、上海地域以及杭州地域。

第二点，多环境保持一致。因为使用的是相同的模版进行部署，所有环境部署出来的结果都一样，这样可以避免人为错误，避免问题排查时的环境影响，环境造成的问题往往是最难排查的问题之一。

第三点，可审计。所有操作均通过API，所有API操作都可以被审计，集成操作审计服务ActionTrail即可。

第四点是DevOps。从环境部署到应用部署都模板化，版本管理使用Git，可以做代码评审、代码回滚。

资源编排ROS和运维编排OOS

阿里云针对云上部署和运维特点，推出了两个产品，包括资源编排ROS（Resource Orchestration Service）——解决自动化部署问题，运维编排OOS（Operation Orchestration Service）——解决自动化运维问题。两款编排产品除了支持ECS的实例，还支持其它阿里云的产品，如负载均衡，关系型数据库RDS，对象存储OSS等。

二、资源编排ROS

资源编排ROS的典型场景

资源编排ROS的典型场景主要有四种：
• 第一种是部署模版，资源编排ROS是通过模版方式达到可以重复部署的目的，使用模版可以在任何时间任何地点拉起一套环境。
• 第二种是MSP、ISV提供自己的部署模版，可以一键开出复杂的业务系统，如SAP HANA等系统，将部署时间缩短为几个小时。由于云上的环境都是标准的，只要有测试通过后的模版就可以在不同的环境、不同的账号中重复部署。
• 第三是解决方案中心，阿里云通过自身多年服务客户和双11的经验，总结了大量的最佳实践，在解决方案中心中提供了很多高质量的模版，支持开箱即用。
• 第四是CI/CD集成，在DevOps开发模式下，只有将部署模版放到CI/CD中才能打造DevOps的开发模式，轻松的做到蓝绿部署，并且支持阿里云云效。

ROS控制台及操作演示

下图是资源编排ROS主页https://rosnext.console.aliyun.com/ ，上方对ROS产品进行了简单的介绍；下方是常见的部署架构作为示例模版。

左侧菜单栏中有“我的模版”和“模版示例”，其中我的模版是需要自定义的模版，模版示例中提供了大量常见的部署形式，如Jenkins、Kafka等。解决方案中心中是由阿里云解决方案架构师团队、最佳实践团队、各业务方团队和资源编排团队合作共建，将阿里云多年沉淀的最佳实践和针对各种场景的解决方案沉淀为资编排源模版，用户可以使用这些最佳实践模版使得云上部署更加安全高效。

“资源类型”模块中展示了ROS支持的阿里云云产品。

下面以构建我的模版LNMP-deom-1作为例子，模版以JSON格式表达，也支持YAML格式，最重要的是，还提供了可视化的架构图。

可以发现所有的资源都在VPC内部，包括关系型数据库RDS和ECS实例。图中两个ECS实例挂在负载均衡LoadBalance下面。

接着可以使用此模版创建资源栈，之后通过事件tab知道每一步创建步骤。在资源tab中看到所有被模版创建的资源，只需要点击资源ID，就可以打开实例详情页面。在输出tab在有显示一个网站链接，可以发现此次网站部署成功。参数tab中提供了每次模版的参数。当用户手动修改一些资源，与模版出现不一致时，可以使用检查资源偏差查看不同点。

三、运维编排OOS

运维编排OOS的典型场景

运维编排OOS的典型场景同样分为四种：
• 首先是批量操作实例和执行远程命令，例如启动、停止等，相比于其它方式无需密码，无需登录，无需使用跳板机，且无需担心安全问题，运维编排使用了阿里云RAM进行控制。
• 第二种场景是定时运维，在固定的时间执行制定的命令，相当于云上Cron服务，并且免托管，分布式。
• 第三种场景是支持报警和事件驱动运维，当某个事件发生时自动触发告警任务。
• 第四是提供大量丰富的公共模版，阿里云总结了大量的典型运维场景，并将总结成果开源到了Github上，欢迎大家贡献优质模版，共同打造运维社区。

OOS控制台及操作演示

下图是运维编排OOS主页https://oos.console.aliyun.com/ ，左侧菜单栏中有批量操作实例模块，任务类型包含发送进程命令、批量下载文件、实例操作、实例属性修改等。批量管理软件模块中可以批量的给实例下载和安装常见的软件，在我的软件模块可以自行部署和卸载。

定时开关机模块中可以选择在指定的时间关闭、开启或重启实例。在包年包月的服务器情况下，客户需要在固定的时间升级临时宽带，等高峰过去后再下降，以达到节约成本的目的。在创建更新镜像模块中可以基于已有的实例进行更新，也可以基于已有的镜像创建实例，进一步更新，再创建新的镜像。

定时运维模块可以在固定的时间和固定的地域执行指定的任务。告警与事件运维模块中若控制台上显示当某个事件发生时自动触发模版，比如CPU使用率过高时重启实例操作。

所有的模版都提供了可视化视图，提供了更加直观的展示方式，还提供了YAML和JSON两种格式的文本，方便用版本管理软件如Git进行管理。

下图展示的是批量操作实例，发送远程命令，命令内容是发送输出命令。之后选择实例，可以手动选择，可以指定实例标题，也可以指定实例资源组，或者上传csv文件，从ECS实例表中导出csv文件来选择实例。

在高级选项部分可以配置执行模式，如出现错误时继续执行还是暂停实例，设置并发速率，允许的最大错误次数等。

此外还有更加快速的执行实例命令方式，在实例列表模块中选择具体的实例，进入实例详情页后会显示本实例远程命令，显示了历史的执行命令，同时可以发送新的远程命令。其次在实例列表中同时选择多台实例，选择更多，发送远程命令，这时多台实例就可以同时执行命令。

使用ROS、OOS的部分阿里云产品

下图中列出了支持ROS、OOS的常见阿里云产品，包括ACS容器服务、FC函数计算、SLS日志服务、SMC服务迁移中心等等，这与产品本身的部署场景契合。

云产品需要支持多种地域，阿里云有22个地域，使用ROS和OSS可以最大提高部署和运维效率。阿里云对内部系统变更有非常严格的要求，需要提供信息完整的变更单、申请、审批、以及需要为变更过程中可能出现的问题提前准备脚本。因此OSS会预先提供变更模版和回滚模版，从而提供自动化运维程度，降低人工错误。

客户对自动化运维有不同的需要，从下图左侧可以分出运维的几个层次，从最底层的手动运维、到半手工，半自动化运维、再到高度自动化运维、标准化运维以及智能运维（AIOps）、大部分客户的需求集中在中间三层，大部分的公司处于半手工，半自动化运维，异或高度自动化的方式，少部分的公司更加激进的走到了更加标准化运维，享受到了更加DevOps的方式，阿里云自动化部署ROS和自动化运维OOS的主打场景可以满足这三个主要层次的自动化需求。

今天的分享到此结束，感兴趣的同学可持续关注云上自动化部署ROS和运维OOS产品动态。

游戏市场需求旺盛，行业景气度持续提升
据相关数据显示，我国广告投放刊例花费整体呈负增长趋势，2019年2月下降幅度最大达到18.3%，下降幅度虽然有所放缓，但是整体而言，我国广告投放刊例花费下降幅度仍然较大。2020年1月，我国广告投放刊例花费下滑5.6%。
分媒体来看，传统广告媒介主要包括报纸媒体、杂志、广播、电视、户外媒体和售点等。2020年1月，报纸、杂志、广播等较为传统的广告媒介刊例下降幅度较大，报纸、杂志等纸媒下降了30%以上，广播媒介下降了19.5%。电视、传统户外同样下降了4.9%和9%;整体而言，传统媒体广告刊例花费呈下降趋势。
与传统媒体广告相比，互联网广告市场规模逐渐上升。根据中关村互动营销实验室的数据，2010-2019年我国互联网广告市场增速虽然放缓，但是我国互联网广告市场规模呈现出逐年上升的发展趋势，2010-2019年我国互联网广告市场规模复合增速达40%以上。2019年我国互联网广告总收入约4367亿元人民币，相较上年增长18.22%，增幅较2018年略有放缓，但仍保持增长的态势。

行业发展方向

互联网广告时代正在来临，大数据驱动智能化精准广告投放
随着互联网的普及，以及精准化程度高、性价比高、媒体质量优等优势，互联网广告迅速崛起，不断持续冲击传统媒介，市场份额持续上升：2016-2019年，我国互联网广告规模占整体广告市场规模比重持续上升，到2019年，互联网广告所占比重已超过50%。

互联网媒体广告相对于传统广告而言具有较多优势，例如互联网广告形式更新频率比报刊广告、广播广告、电视广告等传统媒体更快，能快速适应市场环境的变化，是高度综合的媒体，扩容性高。互联网媒体广告的发展迅速较快，已不仅仅是展示广告，而是更加精准化、个性化和自动化，能够紧紧地把握市场潮流以及引领着技术的进步。

面临的痛点

大数据驱动下数据存储成难题，资源浪费成难题
互联网广告平台的增加，一方面为读者提供了更多的阅读平台，但是背后产生了大量的阅览、订阅、购买数据，而这些数据的产生已经从过去的TB级向PB级甚至EB级跨越，而要利用好这些数据，需要大量的存储空间和计算资源，尤其是为了提高广告推送的准确率以及点击率，需要对大量的数据进行复杂的运算，而这给企业提出了难题。持有的资源过多，虽然可以满足业务需求，但是在空闲期间限制，如果不持有相应的资源，那么又不能很好的解决业务问题。如何很好的寻找业务和资源消耗的平衡点，摆在了各个广告投放企业眼前。

数据湖解决方案

阿里云数据湖解决方案，助力企业真正释放数据价值

基于阿里云对象存储OSS构建的数据湖解决方案，可以全面满足数据的存储、离线分析、交互查询等各种业务诉求，帮助解决上面提到的这些难题。
首先，数据湖解决方案可为用户存储的数据提供高达12个9的可靠性，让数据安全存放，保障用户数据不丢不坏。

 其次，阿里云的数据湖解决方案，也是一套十分智能的解决方案。其中对象存储OSS，可以对接个多业务系统，存储来自不同业务系统的多种数据源，如些系统的原始数据、游戏日志数据等。等数据汇聚到数据湖之后，它的上层系统可以兼容多种计算引擎，如开源大数据引擎像Hive，Spark，阿里云EMR、DLA等，帮助用户便捷地实现数据处理和分析，不需要再重复拷贝多份。同时采用 Jindofs提供缓存加速方案，还可以获得比使用HDFS更好的体验。

这样一套整体的数据存储、处理分析解决方案，能很大程度地减少系统兼容性问题，管理维护也更加简单，帮助IT人员从复杂且繁琐的运维中解放出来，更加专注在产品创新和业务模式的运营上。

最佳案例实践

客户简介
客户是一家致力于为广告主企业构建贯穿消费者生命周期的流量网络，形成企业私有化的消费者数字资产。在国内享有很高的知名度。

业务挑战
1、智能流量平台的数据量在急剧增长，每天的业务日志数据在持续的产生和上传，曝光、点击、推送的数据在持续处理，每天新增的数据量已经在5TB左右，对整个数据处理系统提出了更高的要求。
2、通过运用AI图像识别技术对内容场景进行智能识别与自动匹配，实现不同场景下的创意的精准匹配，真正实现千人千面千种场景的沟通。
3、不断升级AI运算技术能力，建立不同营销目的下的流量协同过滤模型，实时进行流量优选，实现不同场景下的流量的高效使用。另外，从触达、互动到消费、忠诚，全面升级消费者各阶段的沟通体验，增值企业消费者数字资产。

解决方案
1、利用DLA+ OSS极致分析能力来应对业务波峰波谷。一方面轻松应对来自品牌客户的临时分析。另一方面利用DLA的强大计算能力，分析按月、季度广告投放，精确计算出一个品牌下面会有多少个活动，每个活动分媒体，分市场，分频道，分DMP的投放效果，进一步增强了加和智能流量平台为品牌营销带来的销售转化率。
2、DLA提供的Serverless的弹性服务为按需收费，不需要购买固定的资源，完全契合业务潮汐带来的资源波动，满足弹性的分析需求，同时极大地降低了运维成本和使用成本。

客户价值
为客户的智能流量平台提供了性价比极高的处理方案。
1、相对性价比提升30%，无需专门维护人员，按量付费，成本低。
2、临时业务需求承接率提升200%~300%。
3、即需即用，准备成本低，响应快速。平均任务耗时降低67%。
4、代码通用，支持数据业务无缝迁移。
5、海量资源存储在OSS上，对业务支撑效果超过自建平台。
6、计费简明，业务成本方便计算。

MySQL 死锁异常是我们经常会遇到的线上异常类别，一旦线上业务日间复杂，各种业务操作之间往往会产生锁冲突，有些会导致死锁异常。这种死锁异常一般要在特定时间特定数据和特定业务操作才会复现，并且分析解决时还需要了解 MySQL 锁冲突相关知识，所以一般遇到这些偶尔出现的死锁异常，往往一时没有头绪，不好处理。

本篇文章会讲解一下如果线上发生了死锁异常，如何去排查和处理。除了系列前文讲解的有关加锁和锁冲突的原理还，还需要对 MySQl 死锁日志和 binlog 日志进行分析。

正文

日常工作中，应对各类线上异常都要有我们自己的 SOP (标准作业流程) ，这样不仅能够提高自己的处理问题效率，也有助于将好的处理流程推广到团队，提高团队的整体处理异常能力。

所以，面对线上偶发的 MySQL 死锁问题，我的排查处理过程如下：

1. 线上错误日志报警发现死锁异常
2. 查看错误日志的堆栈信息
3. 查看 MySQL 死锁相关的日志
4. 根据 binlog 查看死锁相关事务的执行内容
5. 根据上述信息找出两个相互死锁的事务执行的 SQL 操作，根据本系列介绍的锁相关理论知识，进行分析推断死锁原因
6. 修改业务代码

根据1，2步骤可以找到死锁异常时进行回滚事务的具体业务，也就能够找到该事务执行的 SQL 语句。然后我们需要通过 3，4步骤找到死锁异常时另外一个事务，也就是最终获得锁的事务所执行的 SQL 语句，然后再进行锁冲突相关的分析。

第一二步的线上错误日志和堆栈信息一般比较容易获得，第五步的分析 SQL 锁冲突原因中涉及的锁相关的理论在系列文章中都有介绍，没有了解的同学可以自行去阅读以下。

下面我们就来重点说一下其中的第三四步骤，也就是如何查看死锁日志和 binlog 日志来找到死锁相关的 SQL 操作。

死锁日志的获取

发生死锁异常后，我们可以直接使用 show engine innodb status 命令获取死锁信息，但是该命令只能获取最近一次的死锁信息。所以，我们可以通过开启 InnoDB 的监控机制来获取实时的死锁信息，它会周期性（每隔 15 秒）打印 InnoDb 的运行状态到 mysqld 服务的错误日志文件中。

InnoDb 的监控较为重要的有标准监控（Standard InnoDB Monitor）和 锁监控（InnoDB Lock Monitor），通过对应的系统参数可以将其开启。

-- 开启标准监控
set GLOBAL innodb_status_output=ON;
-- 关闭标准监控
set GLOBAL innodb_status_output=OFF;
-- 开启锁监控
set GLOBAL innodb_status_output_locks=ON;
-- 关闭锁监控
set GLOBAL innodb_status_output_locks=OFF;

另外，MySQL 提供了一个系统参数 innodb_print_all_deadlocks 专门用于记录死锁日志，当发生死锁时，死锁日志会记录到 MySQL 的错误日志文件中。

set GLOBAL innodb_print_all_deadlocks=ON;

死锁日志的分析

通过上述手段，我们可以拿到死锁日志，下图是我做实验触发死锁异常时获取的日志(省略的部分信息)。

该日志会列出死锁发生的时间，死锁相关的事务，并显示出两个事务(可惜，多事务发生死锁时，也只显示两个事务)在发生死锁时执行的 SQL 语句、持有或等待的锁信息和最终回滚的事务。

下面，我们来一段一段的解读该日志中给出的信息，我们按照图中标注的顺序来介绍：

TRANSACTION 2078, ACTIVE 74 sec starting index read // -1 事务一的基础信息，包括事务ID、活跃时间，当前运行状态

表示的是 ACTIVE 74 sec 表示事务活动时间，starting index read 为事务当前正在运行的状态，可能的事务状态有：fetching rows，updating，deleting，inserting, starting index read 等状态。

mysql tables in use 1, locked 1  // -2 使用一个table，并且有一个表锁
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1  // -3 涉及的锁结构和内存大小 

tables in use 1 表示有一个表被使用，locked 1 表示有一个表锁。LOCK WAIT 表示事务正在等待锁，3 lock struct(s) 表示该事务的锁链表的长度为 3，每个链表节点代表该事务持有的一个锁结构，包括表锁，记录锁或 autoinc 锁等。heap size 1136 为事务分配的锁堆内存大小。

2 row lock(s) 表示当前事务持有的行锁个数，通过遍历上面提到的 11 个锁结构，找出其中类型为 LOCK_REC 的记录数。undo log entries 1 表示当前事务有 1 个 undo log 记录，说明该事务已经更新了 1条记录。

下面就是死锁日志中最为重要的持有或者待获取锁信息，如图中-5和-6行所示，通过它可以分析锁的具体类型和涉及的表，这些信息能辅助你按照系列文章的锁相关的知识来分析 SQL 的锁冲突。

RECORD LOCKS space id 2 page no 4 n bits 80 index PRIMARY of table `test`.`t` trx id 2078 lock_mode X locks rec but not gap  // -5 具体持有锁的信息
RECORD LOCKS space id 2 page no 4 n bits 80 index PRIMARY of table `test`.`t` trx id 2078 lock_mode X locks rec but not gap waiting // -6 等待获取锁的信息

在 《锁类型和加锁原理》 一文中我们说过，一共有四种类型的行锁：记录锁，间隙锁，Next-key 锁和插入意向锁。这四种锁对应的死锁日志各不相同，如下：

• 记录锁（LOCK_REC_NOT_GAP）: lock_mode X locks rec but not gap
• 间隙锁（LOCK_GAP）: lock_mode X locks gap before rec
• Next-key 锁（LOCK_ORNIDARY）: lock_mode X
• 插入意向锁（LOCK_INSERT_INTENTION）: lock_mode X locks gap before rec insert intention

所以，按照死锁日志，我们发现事务一持有了 test.t 表上的记录锁，并且等待另一个记录锁。

通过死锁日志，我们可以找到最终获得锁事务最后执行的 SQL，但是如果该事务执行了多条 SQL，这些信息就可能不够用的啦，我们需要完整的了解该事务所有执行的 SQL语句。这时，我们就需要从 binlog 日志中获取。

binlog的获取和分析

binlog 日志会完整记录事务执行的所有 SQL，借助它，我们就能找到最终获取锁事务所执行的全部 SQL。然后再进行具体的锁冲突分析。

我们可以使用 MySQL 的命令行工具 Mysqlbinlog 远程获取线上数据库的 binlog 日志。具体命令如下所示：

Mysqlbinlog -h127.0.0.1 -u root -p --read-from-remote-server binlog.000001 --base64-output=decode-rows -v

其中 --base64-output=decode-rows 表示 row 模式 binlog日志，所以该方法只适用于 row 模式的 binlog日志，但是目前主流 MySQL 运维也都是把 binlog 日志设置为 row 模式，所以这点限制也就无伤大雅。-v 则表示将行事件重构成被注释掉的伪SQL语句。

我们可以通过死锁日志中死锁发生的具体事件和最终获取锁事务正在执行的SQL的参数信息找到 binlog 中该事务的对应信息，比如我们可以直接通过死锁日志截图中的具体的时间 10点57分和 Tom1、Teddy2 等 SQL 的具体数据信息在 binlog 找到对应的位置，具体如下图所示。

根据 binlog 的具体信息，我们可以清晰的找到最终获取锁事务所执行的所有 SQL 语句，也就能找到其对应的业务代码，接下来我们就能进行具体的锁冲突分析。

小节

死锁系列终于告一段落，如果大伙有什么疑问或者文中有什么错误，欢迎在下方留言讨论。也希望大家继续持续关注。

个人博客，欢迎来玩

【阿里云】【消息队列MQ】【升级通知】

升级窗口：

北京时间2020年10月14日 22:00 - 2020年10月15日 04:00

北京时间2020年10月21日 22:00 - 2020年10月22日 04:00

北京时间2020年10月28日 22:00 - 2020年10月29日 04:00

升级内容：所有地域的MQ服务（包含TCP、MQTT、HTTP接入方式）。

升级影响：升级期间MQ控制台和集群中每个服务节点可能出现秒级闪断（闪断时间和集群规模正相关），客户端会自动重试机制，一般不会影响业务，但会有异常日志。

升级期间，消息可能会有重复，应用应该按最值实践，做好消息的幂等；同时可能会有消息延迟的现象。如需在控制台进行管理操作，请避开维护时间段。HTTP接入可能会出现闪断或者拒绝连接现象，每次闪断或拒绝连接不会超过1分钟，请在客户端中做好重连重试机制。同时，您可使用监控管理功能对重要业务进行监控，具体设置方法请点击MQ控制台左侧监控报警菜单。

给您带来的不便敬请谅解，有任何问题，可点击联系我们进行咨询反馈。

【阿里云】【域名】【Donuts注册局维护通知】

维护时间：北京时间2020年10月13日 20:00-22:00

维护内容：接到注册局的通知，注册局 / 注册商将于上述时间对后台系统进行维护升级。

维护影响：届时 .chat 域名的注册、续费、信息修改和查询域名注册信息等操作，将会无法使用，在此期间会对您造成的影响如下：

1、您提交的注册（购买）、续费、转入、赎回、一口价域名业务在支付费用后状态为“处理中”，待维护结束后将变为正常的“成功”状态；

2、维护过程中您无法对域名注册信息进行修改，将提示修改失败。

如果您需要注册或管理以上业务操作，建议您避开该时间段，以免给您的业务造成影响。

由此给您带来的不便，我们表示歉意，敬请谅解。

【阿里云】【堡垒机】【升级通知】

1、升级窗口：2020年10月10日-11月30日 ；

2、升级区域：升级国内站、国际站区域

3、升级内容：

堡垒机产品V3.2.10版本升级至V3.2.13版本，V3.2.13版本在系统架构、用户/主机配置、双因子手机号、支持语言等均进行了优化升级：  

1）系统架构：支持高可用的双节点版本，提供带宽扩展包

2）主机/用户配置：新建主机或用户可直接指定到相应的组

3）用户向导：新增用户向导功能，更迅速的配置使用

4）双因子手机号新增德国、澳洲、美东、美西、迪拜、东京、英国、印度、中国澳门的手机号码

5）主机配置：标记已经释放的ecs，详细区分主机账号的报错信息

6）维护功能：支持tcp端口检测

4、升级方式：系统自动升级到最新版本

5、升级影响：需要您提前断开正在运维的会话，保存会话数据

【阿里云】【边缘容器服务】【商业化通知】

商业化时间：

北京时间2020年8月28日 14：30
商业化内容：

阿里云边缘容器服务已于2020年8月28日正式转商用化。

边缘容器服务基于标准Kubernetes运行环境，提供Kubernetes 集群云端托管、边缘计算业务高度自治的能力。通过将边缘算力快速接入、统一管理、统一运维，轻松实现云边一体化协同的容器应用交付、运维和管控。

商用后收费模式请参考产品计费文档：https://help.aliyun.com/document_detail/178718.htm

关于边缘容器服务：https://help.aliyun.com/document_detail/124723.html

【阿里云】【ESSD PL0】【商业化通知】

阿里云ESSD PL0规格云盘已经结束公测，于2020年9月29日正式商业化上线。此次上线的ESSD PL0规格云盘拥有最低百微秒时延，最大10000的IOPS，并且支持无损变配至ESSD系列其他规格。详细功能介绍以及价格信息请参考官网介绍。

【阿里云】【ACK Pro】【商业化】

商业化时间：

北京时间2020年10月23日00:00

商业化内容：

容器服务ACK Pro版集群将于2020年10月23日00:00正式转为商用。针对许多对于生产环境有着高稳定性和高安全性要求的企业客户，ACK Pro版集群在ACK托管版集群的基础上进一步增强了可靠性、安全性，并且提供可赔付的SLA。

转商用后定价计费请点此查看。

了解ACK Pro请点此查看。

【阿里云】【商标】【商标局国庆/中秋期间服务器维护停止商标审核/递交申请通知】

维护时间：北京时间2020年10月1日-8日

维护内容：因商标局国庆/中秋假期服务器维护，阿里云商标服务将于北京时间2020年10月1日-8日停止商标订单审核、递交商标申请。

维护影响：阿里云商标服务将于2020年9月30日16：00停止递交商标注册申请，届时对您产生的影响包括：

1、2020年9月30日16：00之后审核通过的订单将顺延至2020年10月9日递交；

2、2020年9月30日递交的申请回执（申请号）将顺延至2020年10月9日后同步到订单中；

3、2020年9月30日提交审核的商标订单将顺延至2020年10月9日开始审核

在此期间购买阿里云商标服务、填写订单、支付费用及补齐材料等不受影响。

由此给您带来的不便，我们表示歉意，敬请谅解。

变更窗口：

北京时间2020年10月20日 00:00 - 2020年11月1号00:00

变更内容：华北1（青岛）、华北2（北京）、华北3（张家口）、华北5（呼和浩特）、华东1（杭州）、华东2（上海）、华南1（深圳）、华东2金融云、华南1金融云、华北2政务云、香港、亚太东南1（新加坡）、亚太东南2（悉尼）、亚太东南5（雅加达）、亚太南部1（孟买）、中东东部1（迪拜）、欧洲中部1（法兰克福）、美国东部1（弗吉尼亚）、美国西部1（硅谷）、英国（伦敦）等地域的OpenAPI服务IP变更。

变更影响：OpenAPI旧的的服务IP将下线不可用，如果您所负责的应用或安全策略中有涉及到硬编码阿里云OpenAPI的服务IP，请在变更前及时修改，以免变更后影响应用的正常运行。

给您带来的不便敬请谅解，有任何问题，可随时通过工单或服务电话95187联系反馈。

特别提醒：OpenAPI各服务的IP不定时会有变动，请不要以任务形式绑定固定IP，包括（不限于）自定义DNS、添加Hosts绑定、在安全组策略中绑定等行为，以免IP变动时对业务造成影响

【阿里云】【域名】【注册局维护通知】

维护时间：北京时间2020年9月20日 09:00 - 09:45

维护内容：接到注册局的通知，注册局将于上述时间对后台系统进行维护升级。

维护影响：届时 .com/.net 域名的注册、续费、信息修改和查询域名注册信息等操作，将会无法使用，在此期间会对您造成的影响如下：

1、您提交的注册（购买）、续费、转入、赎回、一口价域名业务在支付费用后状态为“处理中”，待维护结束后将变为正常的“成功”状态；

2、维护过程中您无法对域名注册信息进行修改，将提示修改失败。

如果您需要注册或管理以上业务操作，建议您避开该时间段，以免给您的业务造成影响。

由此给您带来的不便，我们表示歉意，敬请谅解。

【阿里云】【域名】【MMX注册局维护通知】

维护时间：北京时间 2020年9月22日 13:00 - 15:00

维护内容：接到注册局的通知，注册局将于上述时间对后台系统进行维护升级。

维护影响：届时 .Vip/.Work/.Beer/.Luxe/.Fit/.Yoga 域名的注册、续费、信息修改和查询域名注册信息等操作，将会无法使用，在此期间会对您造成的影响如下：

1、您提交的注册（购买）、续费、转入、赎回、一口价域名业务在支付费用后状态为“处理中”，待维护结束后将变为正常的“成功”状态；

2、维护过程中您无法对域名注册信息进行修改，将提示修改失败。

如果您需要注册或管理以上业务操作，建议您避开该时间段，以免给您的业务造成影响。

由此给您带来的不便，我们表示歉意，敬请谅解。

【阿里云】【域名】【Donuts注册局维护通知】

维护时间：北京时间2020年9月29日 01:00-2:30

维护内容：接到注册局的通知，注册局 / 注册商将于上述时间对后台系统进行维护升级。

维护影响：届时，您的 .ltd/.group/.pub/.live/.rocks/.band/.market/.software/.social/.lawyer/.engineer/.news/.video/.studio/.today /.plus/.world/.run/.show/.city/.gold/.today/.cool/.zone/.chat/.company/.企业/.游戏 等域名的续费、转入转出、信息修改和过户域名等操作，将会无法使用，在此期间会对您造成的影响如下：

1、您提交的续费、转入、转出域名等操作在支付费用后状态为“处理中”，且可能出现“不成功”等状态；

2、维护过程中您无法对域名注册信息进行修改，将提示修改失败。

如果您需要注册或管理以上业务操作，建议您避开该时间段，以免给您的业务造成影响。

如您的业务操作失败，建议维护后再次尝试。

由此给您带来的不便，我们表示歉意，敬请谅解。

【阿里云】【消息队列AMQP】【升级通知】

升级窗口：北京时间2020年9月25日 00:00 -  03:00

升级内容：华北1（青岛）、华北2（北京）、华北3（张家口）、华北5（呼和浩特）、华东1（杭州）、华东2（上海）、华南1（深圳）、香港等全部地域（及铂金版）的服务升级。

升级影响：升级期间消息队列AMQP相关服务访问可能会出现多次闪断或者拒绝连接现象，每次闪断或拒绝连接不会超过 5 分钟，请在客户端中做好重连重试机制。如需在控制台进行管理操作，请避开维护时间段。

给您带来的不便敬请谅解，有任何问题，可点击联系我们进行咨询反馈。

2020年9月22日，阿里云应急响应中心监测到FastAdmin爆发远程代码执行0day漏洞，黑客登录前台会员中心，即可远程GetShell，风险极大。

漏洞描述

FastAdmin是一款基于ThinkPHP和Bootstrap的后台开发框架、开放会员中心的站点，上传特定文件可直接GetShell。阿里云应急响应中心提醒FastAdmin用户尽快采取安全措施阻止漏洞攻击。

影响版本

全版本（截止2020年9月22日官方暂未发布安全补丁或修复版本）

漏洞评级

严重

安全建议

1、关闭站点会员中心功能，在/application/config.php文件中，设置'usercenter' => false

2、暂时关闭文件上传功能

相关链接

https://github.com/karsonzhang/fastadmin/issues/73

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单联系反馈。

阿里云应急响应中心

2020.9.22

近日，阿里云应急响应中心监测到Openwall社区披露一个Linux内核AF_PACKET原生套接字内存破坏漏洞，该漏洞出现在net/packet/af_packet.c中，由整数溢出导致越界写，可以通过它进行权限提升。该漏洞危害评级为高，编号为CVE-2020-14386。

漏洞描述

Linux发行版高于4.6的内核版本net/packet/af_packet.c中，在处理AF_PACKET时存在整数溢出漏洞，可以通过它进行权限提升。阿里云应急响应中心提醒用户尽快采取安全措施阻止漏洞攻击。

受影响Linux发行版系统

1、Ubuntu Bionic (18.04) 及后续的版本

2、Debian 9/10

3、CentOS 8/RHEL 8

漏洞评级

CVE-2020-14386  高危

安全建议

1、升级内核至安全版本

2、禁用CAP_NET_RAW功能

3、阿里云云安全中心Linux软件漏洞模块已支持对该漏洞一键检测和修复，详情登陆云安全中心

相关链接

https://www.openwall.com/lists/oss-security/2020/09/03/3

https://github.com/cgwalters/cve-2020-14386

https://sysdig.com/blog/cve-2020-14386-falco/

我们会关注后续进展，请随时关注官方公告。

如有任何问题，可随时通过工单联系反馈。

阿里云应急响应中心

2020.9.22

他认为，区块链技术并非单纯点对点和去中心化。区块链技术的出现会让整个传统互联网平台更加可信、更加透明、更加公平。目前使用区块链技术提供的应用程序，更加互联网化，更加强调公平与双向激励，方便每个人参与进来，分享生态的成果，这才是最好的商业模式。

魔橙在应用场景中实现有效“信用传递”
区块链技术的落地就是在一个没有中心的业务模式中，帮助多方建立跨主体的信任环境，否则区块链技术可能并不是最好的解决方案。实际上，区块链技术是一个由所有节点共同维护、共同记账的“公共大账本”。

魔橙科技独创的联盟链底层技术，结合了多个共识算法优势，实现可伸缩的网络节点准入机制，允许多重共识组合相互切换。极大降低区块链网络开发成本，使得商用网络在构建及运营阶段更加灵活可控，规避了因需求调整带来的潜在风险。

核心模块包含：高性能共识算法，可伸缩节点，跨共识引擎及链上治理机制等

通过区块链底层混沌系统，能够确保参与联盟链共建节点的完全可控性，保证联盟链整体运营的稳定。链上数据公开，联盟见证者可通过区块链浏览器对所有链上数据查询，保证了联盟链的数据公开完整及数据公平。在实际企业项目中，魔橙联盟链能够基于丰富行业应用经验，并结合联盟链的底层技术，以及数据隐私保护和多方安全技术等应用框架的构建，适用于想通过区块链改进商业应用性能的商业需求。

与银行如何擦出火花？
金融一直被认为是区块链最合适的落地场景之一，在魔橙的合作方中有不少是大型银行、城商行以及券商。

在说到区块链应用的细分赛道时，陈敏涛坦言，供应链金融对魔橙来说是很重要的一个主推方向。2020年年初，魔橙参与服务世界500强商业银行的项目中。在该项目中，魔橙提供了结合业务应用场景的整体解决方案，在根据银行单一应用场景细化实现方式。因为是创新技术在金融领域的试点，项目采用敏捷方式开展实施，快速迭代如期交付。（因合作方要求，对于合作银行名字予以保密）

据魔橙科技负责该项目的总监黄洋表示，在这个项目中，魔橙的主要作用是协同银行，基于“区块链+”模式重构银行生态系统，构建新型的区块链金融服务业务模式和拓展商业银行多类应用场景拓展。目前项目搭建基于区块链技术的微服务控制台系统，包含区块链服务接口、合约网关、安全合规、链上账户管理、智能合约管理；通用服务、可信存证、交易查询中心、通用监控，前端控制台等模块。

“我们提供的是基础设施，让客户基于我们的服务，去做自己的金融服务，目的是让他们用魔橙的区块链。同时，供应链金融一个很大的特性是参与方越多越好，而且不同参与方的链与链之间是有交集的，最终市场将形成网状。”黄洋表示，魔橙的愿景是，通过底层，把所有的核心企业、上下游企业、金融机构，包括保理，券商之类的企业链接在一起，他们做他们的业务，我们降低他们的交易和信任成本。只要规模做大了，就是魔橙的诉求。
**
魔橙的目标和定位是什么**

区块链是个基础设施，最终市场上同类企业不会太多，做底层技术的也不会有几家，但是在这个基础设施上做应用的公司非常多。我们要把基础设施做好，目的是让其他业务公司用我们的区块链。

每个行业都是有门槛的，但是以技术为依托，我们会有很多合作伙伴，魔橙会和行业专家一起做事情，争取行业的支持。2020年7月，魔橙与复旦大学、上海海事大学、上海海洋大学联合研发推出“跨境贸易风险监测与可信溯源”平台正式上线。

接下来，魔橙科技将与更多金融机构共建跨产业、跨机构的数字经济新模式，实现真正意义上的产业数字化。

基本环境 CentOS 7.3
（一）安装 Nginx

yum -y install nginx

查看是否安装成功

nginx -v

如果安装成功则显示

(二)安装 PHP
Wafer 的 Demo 需要 5.6 以上版本的 PHP,添加 remi 源.

wget 'https://mirrors.tuna.tsinghua.edu.cn/remi/enterprise/remi.repo' -O /etc/yum.repos.d/remi.repo

查看是否安装成功

php -v

php版本要大于5.6
(三)配置 Nginx 和 HTTPS
申请一个 SSL 证书，可以到阿里云申请免费的 SSL 证书，申请成功之后下载证书，并把压缩包中 Nginx 目录下的证书文件上传到服务器的 /data/release/nginx 目录，如果没有这个目录则新建：上传完证书以后，配置 Nginx，进入服务器的 /etc/nginx/conf.d 目录，新建一个 weapp.conf 文件，内容为以下,注意(www.xx.com改为自己的域名,1_www.xx.com_budle.crt和2_www.xx.com.key分别改为自己的证书文件)

# 重定向 http 到 https

www.xx.com

server { listen 80; server_name www.xx.com; rewrite ^(.*)$ https://$server_name$1 permanent;}server { listen 443; server_name www.xx.com; ssl on; ssl_certificate /data/release/nginx/1_www.xx.com_bundle.crt; ssl_certificate_key /data/release/nginx/2_www.xx.com.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA; ssl_session_cache shared:SSL:50m; ssl_prefer_server_ciphers on; root /data/release/php-demo; location ~ .php$ { root /data/release/php-demo; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location /weapp/ { root /data/release/php-demo; index index.html index.htm index.php; try_files $uri $uri/ /index.php; }}

运行nginx

nginx -t

(四)安装mysql
安装mysql5.7

1、配置YUM源

下载mysql源安装包

wget http://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm

安装mysql源

yum localinstall mysql57-community-release-el7-8.noarch.rpm

检查mysql源是否安装成功
yum repolist enabled | grep "mysql.-community."

2、安装MySQL

yum install mysql-community-server

3、启动MySQL服务

systemctl start mysqld

查看MySQL的启动状态
shell> systemctl status mysqld

4、开机启动

systemctl enable mysqld
systemctl daemon-reload

5、修改root本地登录密码

mysql安装完成之后，在/var/log/mysqld.log文件中给root生成了一个默认密码。通过下面的方式找到root默认密码，然后登录mysql进行修改：
grep 'temporary password' /var/log/mysqld.log

登陆并修改默认密码
mysql -u root -p

mysql>ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码!';

新建一个数据库名为 cAuth，排序规则为 utf8mb4_unicode_ci，小程序后台用到
mysql>CREATE DATABASE IF NOT EXISTS cAuth，排序规则为 DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;

(五)上传 Demo 和启动
到 wafer2-quickstart-php 仓库下载最新的 Demo 代码，修改 server/config.php：

<?php/**

Wafer php demo 配置文件
*/$config = [ 'rootPath' => '', // 微信小程序 AppID

'appId' => '', // 微信小程序 AppSecret
'appSecret' => '', // 使用腾讯云代理登录
'useQcloudLogin' => false, //不使用腾迅云代理登录 /**

这里请填写云数据库的
*/
'mysql' => [ 'host' => 'localhost', 'port' => 3306, 'user' => 'root', 'db' => 'cAuth', 'pass' => '数据库密码', 'char' => 'utf8mb4'
], 'cos' => [ /**

区域上海：cn-east广州：cn-sorth北京：cn-north广州二区：cn-south-2成都：cn-southwest新加坡：sg@see https://cloud.tencent.com/document/product/436/6224
*/

'region' => 'cn-sorth', // Bucket 名称

'fileBucket' => 'wafer', // 文件夹
'uploadFolder' => ''

], // 微信登录态有效期
'wxLoginExpires' => 7200, 'wxMessageToken' => 'abcdefgh', // 其他配置
'serverHost' => 'wx.wafersolution.com', 'tunnelServerUrl' => 'http://tunnel.ws.qcloud.la', 'tunnelSignatureKey' => '27fb7d1c161b7ca52d73cce0f1d833f9f5b5ec89', // 腾讯云相关配置可以查看云 API 秘钥控制台：https://console.cloud.tencent.com/capi
'qcloudAppId' => 1200000000,// 必须是数字
'qcloudSecretId' => '你的腾讯云 SecretId', 'qcloudSecretKey' => '你的腾讯云 SecretKey', 'networkTimeout' => 30000];

接着将 server 目录下的所有文件都上传到 /data/release/weapp/php-demo 目录下：

相关推荐：

linux下apache重启并查看php环境

PHP环境配置

LNMP环境搭建（一）搭建PHP环境

以上就是阿里云如何搭建小程序PHP环境的详细内容。

云服务器ECS地址：链接地址
阿里云2000元通用代金券：点击领取

• 本期直播主题：如何0基础获得Apache Cassandra Administrator国际认证？
• 直播时间：9月25号（周五）16:00-17:00
• 直播讲师：米诺｜阿里云NoSQL数据库产品专家
• 直播简介：Apache Cassandra在宽表数据库流行度中持续8+年排第一，已成为国内外流行度最高的宽表数据库。本次技术直播将为您分享0基础拿Cassandra Administrator国际认证的考试经验。

参与方式：

钉钉扫描下方海报二维码进群观看直播

金钱成本 服务周期

资源限制 人力投入

阿里云ECS服务器:

根据企业运行环境按需购买

数据多次备份

超A级数据中心--双路独市电，三路网络，N+1柴油发电机后备电源

自动化运维自动迁移到其他物理机 ----稳定性和联系性

云盾----安全防护

将企业数据库资源，存储资源，计算资源打通，连接资源孤岛，应用孤岛，数据孤岛，全局快速进行市场洞察

今天完成了6个课程，首先了解了什么是ECS(elastic compute service)，然后创建了服务器实例，安装CentOS系统，用ssh远程连接了系统，完成了Apache、SQL的安装。

1.创建资源

1. 在页面左侧，单击 云产品资源 下拉菜单，查看本次实验资源。
2. 单击 免费开通 创建所需资源。

资源创建过程需要1~3分钟。完成实验资源的创建后，您可以在 云产品资源 列表查看已创建的资源信息，例如：IP地址、用户名和密码等。

2.创建PolarDB数据库账号

1. 单击页面左侧 云产品资源 > 一键复制登录url 。

1. 打开浏览器隐身窗口（无痕模式），粘贴已复制的url地址前往 RAM用户登录 界面，登录 阿里云管理控制台 。

以Chrome浏览器为例，打开新的无痕窗口，登录 阿里云管理控制台 。

1. 依次单击更多>打开新的无痕窗口。
2. 在地址栏粘贴登录url，访问 RAM用户 登录页面
3. 在登录用户名称处，输入 子用户名称 ，单击 下一步 。
4. 输入密码，单击 登录 进入 阿里云管理控制台 。

1. 在 阿里云控制台首页 左侧导航栏，依次单击 产品与服务 > 云数据库PolarDB ，进入 云数据库PolarDB管理控制台 。

1. 单击左侧 集群列表 ，然后选择云产品资源提供的地域。例如：华东2（上海）。

1. 创建数据库账号。

   1. 在 集群列表 页面，单击 集群ID ，进入 集群详情界面 。

1. 单击左侧导航栏 配置与管理 > 账号管理 。
2. 单击左上方 创建账号 。

1. 参考说明配置账号信息，然后单击 确定 。

• 数据库账号：输入数据库账号名称，例如：test_user 。
• 账号类型：此处选择普通账号。
• 密码：设置账号密码，例如：Password1213。
• 确认密码：再次输入密码。

1. 创建数据库。

   1. 在实例详情页，单击左侧导航栏的 数据库管理 ，然后单击 创建数据库 。

1. 参考说明配置数据库信息，然后单击 创建 。

• 数据库（DB）名称：输入数据库名称，例如：pbootcms 。
• 支持字符集：默认设为utf8mb4。
• 授权账号：选择上一步创建的数据库账号test_user。
• 账号类型：默认设置为读写。
• 备注说明：非必填。用于备注该数据库的相关信息，便于后续数据库管理，最多支持256个字符。

1. 设置数据库白名单。

连接数据库需要设置数据库白名单，点击 [集群白名单]，然后点击 [设置] 设置数据库集群白名单。

在白名单界面将默认的白名单地址127.0.0.1更改为 0.0.0.0/0，然后点击 [确定] 使白名单地址生效。

连接ECS服务器

1. 打开终端工具。

• Windows：打开命令窗口。
• MAC：打开命令行终端Terminal。

Windows用户请检查系统中是否安装有SSH工具。检查方法：

在终端中输入命令 ssh -V 。

ssh -V

如果显示SSH版本则表示已安装，如下图所示。

如果未安装，请下载安装 OpenSSH工具。

1. 在终端中输入连接命令 ssh [username]@[ipaddress] 。

您需要将其中的username和ipaddress替换为步骤一中创建的ECS服务器的弹性公网IP。例如：

ssh root@123.123.123.123

命令显示结果如下：

1. 输入 yes。
2. 同意继续后将会提示输入登录密码。 密码为已创建的云服务的ECS的登录密码。

登录成功后会显示如下信息。

安装LAMP环境

LAMP是指运行在Linux下的Apache、MySQL和PHP的环境。参考以下操作在云服务器上安装开发环境。

1. 在ECS服务器上，执行以下命令安装Apache服务及其扩展包。

yum -y install httpd httpd-manual mod_ssl mod_perl mod_auth_mysql

返回类似如下图结果则表示安装成功。

1. PbootCMS是使用PHP语言开发的CMS系统。参考以下操作安装PHP环境。

执行以下命令，安装PHP。

yum -y install php php-mysql gd php-gd gd-devel php-xml php-common php-mbstring php-ldap php-pear php-xmlrpc php-imap

1. 执行以下命令下载并安装MySQL。

wget http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm
yum -y install mysql57-community-release-el7-10.noarch.rpm
yum -y install mysql-community-server

1. 执行以下命令启动MySQL数据库。

systemctl start mysqld

搭建门户网站

在完成环境部署后，参考以下操作搭建门户网站。

1. 在ECS服务器上，执行以下命令，安装Git。

yum -y install git

1. 在ECS服务器上，执行以下命令下载PbootCMS源码文件。

cd ~ && git clone https://gitee.com/hnaoyun/PbootCMS.git

1. 执行以下命令将安装包拷贝到Apache的wwwroot目录下。

cp -r PbootCMS/* /var/www/html/

1. 执行以下命令修改站点根目录文件权限。

chmod -R a+w /var/www/html

1. 向数据库中导入CMS的初始数据。

执行以下命令初始化数据库pbootcms的表结构和数据。

说明: 在执行命令前，请修改一下三个参数。

• 数据库连接地址参见集群详情页面下方链接地址板块。
• test_user为步骤二中创建的数据库账号。
• Password1213步骤二中创建的数据库密码。

sql_file="/var/www/html/static/backup/sql/"$(ls /var/www/html/static/backup/sql/) &&
mysql -h数据库连接地址 -utest_user -pPassword1213 -Dpbootcms < $sql_file

1. 执行以下命令，修改CMS系统数据库配置。

说明: 在执行命令前，请根据参数说明替换您的数据库配置。

cat > /var/www/html/config/database.php << EOF
<?php
return array(
    'database' => array(
        'type' => 'mysqli', // 数据库连接驱动类型: mysqli,sqlite,pdo_mysql,pdo_sqlite
        'host' => '数据库连接地址', // PolarDB数据库链接地址
        'user' => 'test_user', // PolarDB数据库的用户名
        'passwd' => 'Password1213', // PolarDB数据库的密码
        'port' => '3306', // 数据库端口
        'dbname' => 'pbootcms' //数据库名称
    )
);
EOF

1. 返回ECS控制台，在ECS实例列表页面，单击已创建的ECS实例ID链接进入ECS详情页。
2. 在左侧导航栏，单击 本实例安全组 ，然后单击安全组的ID链接查看安全组配置。

确保安全组开放了80端口访问，否则无法访问已搭建的门户网站。安全组是一种虚拟防火墙，具备状态检测和数据包过滤能力，用于在云端划分安全域。通过配置安全组规则，您可以控制安全组内一台或多台ECS实例的入流量和出流量。

1. 访问程序。

执行以下命令重启 Apache服务。

systemctl restart httpd

在浏览器地址栏输入云服务器的公网IP地址，进入门户网站首页。

系统后台默认访问路径为http://<ECS公网IP地址>/admin.php。默认账号为admin，密码为123456。

至此您已完成门户网站的搭建，您可以根据公司的需求自定义门户网站的内容。

本教程将介绍如何搭建个人Leanote云笔记本。

场景体验目标

本场景将提供一台配置了CentOS 7.7的ECS实例（云服务器）。您可以参考本教程的操作基于已有的环境搭建一个Leanote云笔记本。

背景知识

Leanote是一款在线的云笔记应用，有如下特点：

• 支持网页、PC、手机APP客户端和微信版，随时记录，方便分享，支持语音，图片输入。
• 代码高亮，涵盖所有主流语言的代码高亮，随心所欲在Leanote里写代码，记知识。
• Markdown 编辑器,实时同步预览。
• 专业数学公式编辑,像Word和Latex能编辑数学公式。
• 支持创建思维脑图，将散乱的想法以树状信息分层展示。
• 详细历史纪录，每次保存都在后端备份，轻松查找，一键恢复。
• 实时同步云端。

1.创建资源

1. 请点击页面左侧的 云产品资源，在下拉栏中，查看本次实验资源信息；
2. 在资源下拉栏点击 免费开通 按钮，开始创建实验资源。

说明：资源创建过程需要1-3分钟。完成实验资源的创建后，用户可以通过 云产品资源 查看实验中所需的资源信息，例如：IP地址、用户名、密码等。

2.连接ECS服务器

1. 打开系统自带的终端工具。

• Windows：CMD或Powershell。
• MAC：Terminal。

1. 在终端中输入连接命令ssh [username]@[ipaddress]。您需要将其中的username和ipaddress替换为第1小节中创建的ECS服务器的登录名和公网地址。例如：

ssh root@123.123.123.123

命令显示结果如下：

1. 输入yes。
2. 同意继续后将会提示输入登录密码。 密码为已创建的云服务的ECS的登录密码。

登录成功后会显示如下信息。

3.安装MongoDB

MongoDB是一个基于分布式文件存储的高性能数据库，介于关系数据库和非关系数据库之间，它支持的数据结构非常松散是类似于json和bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

Leanote云笔记使用MongoDB作为后端数据库，按照以下步骤按照MongoDB数据库。

1. 执行以下命令，安装MongoDB。

yum -y install mongodb mongodb-server.x86_64 mariadb-devel.i686

1. 执行以下命令，启动MongoDB服务。

systemctl start mongod

1. 执行以下命令，查看MongoDB运行状态。

systemctl status mongod

4.安装Leanote

1. 下载Leanote二进制安装包。

wget https://nchc.dl.sourceforge.net/project/leanote-bin/2.6.1/leanote-linux-amd64-v2.6.1.bin.tar.gz

1. 解压安装包。

tar -zxvf leanote-linux-amd64-v2.6.1.bin.tar.gz

1. 编辑文件leanote/conf/app.conf，在文件中找到app.secret项，将该项的值改为任意字符串。（如不修改将会有安全风险）。

说明： 根据Leanote官方文档，如不修改app.secret项的值，将会有安全隐患。

1. 使用vim编辑器打开文件leanote/conf/app.conf。

vim leanote/conf/app.conf

1. 进入vim编辑器后，输入:/app.secret=并按下回车查找app.secret位置。
2. 找到该项位置后按下i键进入编辑模式，修改该项的值为任意字符串。
3. 修改完成后，按下esc键退出编辑模式，输入:wq保存并退出vim编辑器。

修改后如图所示。

1. 初始化数据库。

mongorestore -h localhost -d leanote --dir /root/leanote/mongodb_backup/leanote_install_data/

1. 启动服务。

nohup bash /root/leanote/bin/run.sh > /root/leanote/run.log 2>&1 &

1. 访问云笔记。

在浏览器中访问http://<ECS公网地址>:9000，请将<ECS公网地址>替换为左侧资源栏中的ECS公网IP地址。默认管理用户为admin，密码为abc123。登录成功后如下图所示。

阿里云ECS覆盖50多款操作系统，包含开源LAMP组合和常见的Windows平台。

包含传统x86服务器及GPU和FPGA的异构计算，包含通用型，内存型，网络增强型，本地SSD型和计算型，甚至企业级Oracle数据库所需的超大规格独占物理机，配置及使用更为灵活。

ECS在底层对每份数据进行多次备份，物理层面拥有超A级数据中心，通过双路独市电引入、三路网络和Ｎ＋１柴油发电机后备电源确保数据安全。

ECS自动化运维将数据迁移到其他物理机，将数据恢复到故障前最后状态，屏蔽硬件故障同时保证业务稳定和连续。

ECS可在底层打通企业数据库资源，存储资源和计算资源，联通传统IT烟囱式架构下的资源孤岛，应用孤岛和数据孤岛，提高信息整合能力。

$ sql_file="/var/www/html/static/backup/sql/"$(ls /var/www/html/static/backup/sql/) &&
mysql -h数据库连接地址 -utest_user -pPassword1213 -Dpbootcms < $sql_file

1. 修改CMS的数据库配置,使用PolarDB数据库:

$ cat > /var/www/html/config/database.php << EOF
<?php
return array(
    'database' => array(
        'type' => 'mysqli', // 数据库连接驱动类型: mysqli,sqlite,pdo_mysql,pdo_sqlite
        'host' => '数据库连接地址', // PolarDB数据库链接地址
        'user' => 'test_user', // PolarDB数据库的用户名
        'passwd' => 'Password1213', // PolarDB数据库的密码
        'port' => '3306', // 数据库端口
        'dbname' => 'pbootcms' //数据库名称
    )
);
EOF

1. 在ECS控制台上开放80端口,然后重启apache服务,即可通过ECS IP访问到该门户网站.

2、上传主题包，安装主题。

3、安装主题碰到的问题

（1）、上传的文件尺寸超过upload_max_filesize文件中定义的php.ini值.

        解决方法：
        修改/etc/php.ini文件中的   

        post_max_size = 20M
        upload_max_filesize = 20M
        然后保存，重启一下apache服务。

（2）、Wordpress上传文件提示“无法建立目录wp-content/uploads/2020/09。有没有上级目录的写权限？”

       解决方法：找到wordpress数据库，打开wp_options表，修改表中键名为upload_path的键值 这个值是一个路径，里面是空的（也可能不是空的），添加 “wp-content/uploads” 就解决了。 ＝＝＝双引号必加！类似于注册表键值

在本文中我们将介绍如何使用 Java 语言的图分析库 JGraphT [5] 并借助绘图库 mxgraph [6] ，可视化探索 A 股的行业个股的相关性随时间的变化情况。

数据集的处理

本文主要分析方法参考了[7,8]，有两种数据集：

股票数据（点集）

从 A 股中按股票代码顺序选取了 160 只股票（排除摘牌或者 ST 的）。每一支股票都被建模成一个点，每个点的属性有股票代码，股票名称，以及证监会对该股票对应上市公司所属板块分类等三种属性；

表1：点集示例

股票关系（边集）

边只有一个属性，即权重。边的权重代表边的源点和目标点所代表的两支股票所属上市公司业务上的的相似度——相似度的具体计算方法参考 [7,8]：取一段时间（2014 年 1 月 1 日 - 2020 年 1 月 1 日）内，个股的日收益率的时间序列相关性 $P_{ij}$ 再定义个股之间的距离为 (也即两点之间的边权重）：

$$l_{ij} = sqrt{2（1-P_{ij}）}$$

通过这样的处理，距离取值范围为 [0,2]。这意味着距离越远的个股，两个之间的收益率相关性越低。

表2： 边集示例

这样的点集和边集构成一个图网络，可以将这个网络存储在图数据库 Nebula Graph 中。

JGraphT

JGraphT 是一个开放源代码的 Java 类库，它不仅为我们提供了各种高效且通用的图数据结构，还为解决最常见的图问题提供了许多有用的算法：

• 支持有向边、无向边、权重边、非权重边等；
• 支持简单图、多重图、伪图；
• 提供了用于图遍历的专用迭代器（DFS，BFS）等；
• 提供了大量常用的的图算法，如路径查找、同构检测、着色、公共祖先、游走、连通性、匹配、循环检测、分区、切割、流、中心性等算法；
• 可以方便地导入 / 导出 GraphViz [9]。导出的 GraphViz 可被导入可视化工具 Gephi[10] 进行分析与展示；
• 可以方便地使用其他绘图组件，如：JGraphX，mxGraph，Guava Graphs Generators 等工具绘制出图网络。

下面，我们来实践一把，先在 JGraphT 中创建一个有向图：

import org.jgrapht.*;
import org.jgrapht.graph.*;
import org.jgrapht.nio.*;
import org.jgrapht.nio.dot.*;
import org.jgrapht.traverse.*;

import java.io.*;
import java.net.*;
import java.util.*;

Graph<URI, DefaultEdge> g = new DefaultDirectedGraph<>(DefaultEdge.class);

添加顶点：

URI google = new URI("http://www.google.com");
URI wikipedia = new URI("http://www.wikipedia.org");
URI jgrapht = new URI("http://www.jgrapht.org");

// add the vertices
g.addVertex(google);
g.addVertex(wikipedia);
g.addVertex(jgrapht);

添加边：

// add edges to create linking structure
g.addEdge(jgrapht, wikipedia);
g.addEdge(google, jgrapht);
g.addEdge(google, wikipedia);
g.addEdge(wikipedia, google);

图数据库 Nebula Graph Database

JGraphT 通常使用本地文件作为数据源，这在静态网络研究的时候没什么问题，但如果图网络经常会发生变化——例如，股票数据每日都在变化——每次生成全新的静态文件再加载分析就有些麻烦，最好整个变化过程可以持久化地写入一个数据库中，并且可以实时地直接从数据库中加载子图或者全图做分析。本文选用 Nebula Graph 作为存储图数据的图数据库。

Nebula Graph 的 Java 客户端 Nebula-Java [11] 提供了两种访问 Nebula Graph 方式：一种是通过图查询语言 nGQL [12] 与查询引擎层 [13] 交互，这通常适用于有复杂语义的子图访问类型; 另一种是通过 API 与底层的存储层（storaged）[14] 直接交互，用于获取全量的点和边。除了可以访问 Nebula Graph 本身外，Nebula-Java 还提供了与 Neo4j [15]、JanusGraph [16]、Spark [17] 等交互的示例。

在本文中，我们选择直接访问存储层（storaged）来获取全部的点和边。下面两个接口可以用来读取所有的点、边数据：

// space 为待扫描的图空间名称，returnCols 为需要读取的点/边及其属性列，
// returnCols 参数格式：{tag1Name: prop1, prop2, tag2Name: prop3, prop4, prop5}
Iterator<ScanVertexResponse> scanVertex(
            String space, Map<String, List<String>> returnCols);
Iterator<ScanEdgeResponse> scanEdge(
            String space, Map<String, List<String>> returnCols);

第一步：初始化一个客户端，和一个 ScanVertexProcessor。ScanVertexProcessor 用来对读出来的顶点数据进行解码：

MetaClientImpl metaClientImpl = new MetaClientImpl(metaHost, metaPort);
metaClientImpl.connect();
StorageClient storageClient = new StorageClientImpl(metaClientImpl);
Processor processor = new ScanVertexProcessor(metaClientImpl);

第二步：调用 scanVertex 接口，该接口会返回一个 scanVertexResponse 对象的迭代器：

Iterator<ScanVertexResponse> iterator =
                storageClient.scanVertex(spaceName, returnCols);

第三步：不断读取该迭代器所指向的 scanVertexResponse 对象中的数据，直到读取完所有数据。读取出来的顶点数据先保存起来，后面会将其添加到到 JGraphT 的图结构中：

while (iterator.hasNext()) {
  ScanVertexResponse response = iterator.next();
  if (response == null) {
    log.error("Error occurs while scan vertex");
    break;
  }
  
  Result result =  processor.process(spaceName, response);
  results.addAll(result.getRows(TAGNAME));
}

读取边数据的方法和上面的流程类似。

在 JGraphT 中进行图分析

第一步：在 JGraphT 中创建一个无向加权图 graph：

Graph<String, MyEdge> graph = GraphTypeBuilder
                .undirected()
    .weighted(true)
    .allowingMultipleEdges(true)
    .allowingSelfLoops(false)
    .vertexSupplier(SupplierUtil.createStringSupplier())
    .edgeSupplier(SupplierUtil.createSupplier(MyEdge.class))
    .buildGraph();

第二步：将上一步从 Nebula Graph 图空间中读出来的点、边数据添加到 graph 中：

for (VertexDomain vertex : vertexDomainList){
    graph.addVertex(vertex.getVid().toString());
    stockIdToName.put(vertex.getVid().toString(), vertex);
}

for (EdgeDomain edgeDomain : edgeDomainList){
    graph.addEdge(edgeDomain.getSrcid().toString(), edgeDomain.getDstid().toString());
    MyEdge newEdge = graph.getEdge(edgeDomain.getSrcid().toString(), edgeDomain.getDstid().toString());
    graph.setEdgeWeight(newEdge, edgeDomain.getWeight());
}

第三步：参考 [7,8] 中的分析法，对刚才的图 graph 使用 Prim 最小生成树算法（minimun-spanning-tree），并调用封装好的 drawGraph 接口画图：

普里姆算法（Prim's algorithm），图论中的一种算法，可在加权连通图里搜索最小生成树。即，由此算法搜索到的边子集所构成的树中，不但包括了连通图里的所有顶点，且其所有边的权值之和亦为最小。

SpanningTreeAlgorithm.SpanningTree pMST = new PrimMinimumSpanningTree(graph).getSpanningTree();

Legend.drawGraph(pMST.getEdges(), filename, stockIdToName);

第四步：drawGraph 方法封装了画图的布局等各项参数设置。这个方法将同一板块的股票渲染为同一颜色，将距离接近的股票排列聚集在一起。

public class Legend {
  
...
  
  public static void drawGraph(Set<MyEdge> edges, String filename, Map<String, VertexDomain> idVertexMap) throws IOException {
     // Creates graph with model
     mxGraph graph = new mxGraph();
     Object parent = graph.getDefaultParent();

     // set style
     graph.getModel().beginUpdate();
     mxStylesheet myStylesheet =  graph.getStylesheet();
     graph.setStylesheet(setMsStylesheet(myStylesheet));

     Map<String, Object> idMap = new HashMap<>();
     Map<String, String> industryColor = new HashMap<>();

     int colorIndex = 0;

     for (MyEdge edge : edges) {
       Object src, dst;
       if (!idMap.containsKey(edge.getSrc())) {
         VertexDomain srcNode = idVertexMap.get(edge.getSrc());
         String nodeColor;
         if (industryColor.containsKey(srcNode.getIndustry())){
           nodeColor = industryColor.get(srcNode.getIndustry());
         }else {
           nodeColor = COLOR_LIST[colorIndex++];
           industryColor.put(srcNode.getIndustry(), nodeColor);
         }
         src = graph.insertVertex(parent, null, srcNode.getName(), 0, 0, 105, 50, "fillColor=" + nodeColor);
         idMap.put(edge.getSrc(), src);
       } else {
         src = idMap.get(edge.getSrc());
       }

       if (!idMap.containsKey(edge.getDst())) {
         VertexDomain dstNode = idVertexMap.get(edge.getDst());

         String nodeColor;
         if (industryColor.containsKey(dstNode.getIndustry())){
           nodeColor = industryColor.get(dstNode.getIndustry());
         }else {
           nodeColor = COLOR_LIST[colorIndex++];
           industryColor.put(dstNode.getIndustry(), nodeColor);
         }

         dst = graph.insertVertex(parent, null, dstNode.getName(), 0, 0, 105, 50, "fillColor=" + nodeColor);
         idMap.put(edge.getDst(), dst);
       } else {
         dst = idMap.get(edge.getDst());
       }
       graph.insertEdge(parent, null, "", src, dst);
     }


     log.info("vertice " + idMap.size());
     log.info("colorsize " + industryColor.size());

     mxFastOrganicLayout layout = new mxFastOrganicLayout(graph);
     layout.setMaxIterations(2000);
     //layout.setMinDistanceLimit(10D);
     layout.execute(parent);

     graph.getModel().endUpdate();

     // Creates an image than can be saved using ImageIO
     BufferedImage image = createBufferedImage(graph, null, 1, Color.WHITE,
                                               true, null);

     // For the sake of this example we display the image in a window
     // Save as JPEG
     File file = new File(filename);
     ImageIO.write(image, "JPEG", file);

   }
  
  ...
    
}

第五步：生成可视化：

图1中每个顶点的颜色代表证监会对该股票所属上市公司归类的板块。

可以看到，实际业务近似度较高的股票已经聚拢成簇状（例如：高速板块、银行版本、机场航空板块），但也会有部分关联性不明显的个股被聚类在一起，具体原因需要单独进行个股研究。

图1： 基于 2015-01-01 至 2020-01-01 的股票数据计算出的聚集性

第六步：基于不同时间窗口的一些其他动态探索

上节中，结论主要基于 2015-01-01 到 2020-01-01 的个股聚集性。这一节我们还做了一些其他的尝试：以 2 年为一个时间滑动窗口，分析方法不变，定性探索聚集群是否随着时间变化会发生改变。

图2：基于 2014-01-01 至 2016-01-01 的股票数据计算出的聚集性

图3：基于 2015-01-01 至 2017-01-01 的股票数据计算出的聚集性

图4：基于 2016-01-01 至 2018-01-01 的股票数据计算出的聚集性

图5：基于 2017-01-01 至 2019-01-01 的股票数据计算出的聚集性

图6：基于 2018-01-01 至 2020-01-01 的股票数据计算出的聚集性

粗略分析看，随着时间窗口变化，有些板块（高速、银行、机场航空、房产、能源）的板块内部个股聚集性一直保持比较好——这意味着随着时间变化，这个版块内各种一直保持比较高的相关性；但有些板块（制造）的聚集性会持续变化——意味着相关性一直在发生变化。

Disclaim

本文不构成任何投资建议，且作者不持有本文中任一股票。

受限于停牌、熔断、涨跌停、送转、并购、主营业务变更等情况，数据处理可能有错误，未做一一检查。

受时间所限，本文只选用了 160 个个股样本过去 6 年的数据，只采用了最小扩张树一种办法来做聚类分类。未来可以使用更大的数据集（例如美股、衍生品、数字货币），尝试更多种图机器学习的办法。

本文代码可见[18]

Reference

[1] 用 NetworkX + Gephi + Nebula Graph 分析<权力的游戏>人物关系（上篇）https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/

[2] 用 NetworkX + Gephi + Nebula Graph 分析<权力的游戏>人物关系（下篇） https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph-part-two/

[3] NetworkX: a Python package for the creation, manipulation, and study of the structure, dynamics, and functions of complex networks. https://networkx.github.io/

[4] Nebula Graph: A powerfully distributed, scalable, lightning-fast graph database written in C++. https://nebula-graph.io/

[5] JGraphT: a Java library of graph theory data structures and algorithms. https://jgrapht.org/

[6] mxGraph: JavaScript diagramming library that enables interactive graph and charting applications. https://jgraph.github.io/mxgraph/

[7] Bonanno, Giovanni & Lillo, Fabrizio & Mantegna, Rosario. (2000). High-frequency Cross-correlation in a Set of Stocks. arXiv.org, Quantitative Finance Papers. 1. 10.1080/713665554. 

[8] Mantegna, R.N. Hierarchical structure in financial markets. Eur. Phys. J. B 11, 193–197 (1999).

[9] https://graphviz.org/

[10] https://gephi.org/

[11] https://github.com/vesoft-inc/nebula-java

[12] Nebula Graph Query Language (nGQL). https://docs.nebula-graph.io/manual-EN/1.overview/1.concepts/2.nGQL-overview/

[13] Nebula Graph Query Engine. https://github.com/vesoft-inc/nebula-graph

[14] Nebula-storage: A distributed consistent graph storage. https://github.com/vesoft-inc/nebula-storage

[15] Neo4j. www.neo4j.com

[16] JanusGraph. janusgraph.org

[17] Apache Spark. spark.apache.org.

[18] https://github.com/Judy1992/nebula_scan

阿里技术（阿里云开发者社区）提供分享、学习、认证、工具、资源、大赛、社群、MVP等一站式服务能力，满足开发者全生命周期成长需求。

议题简介

《携程DRC-MySQL数据双向复制实践》(戳我观看）

直播时间：

2020-09-21 19:00

讲师介绍

李明冬，携程软件技术专家， 围绕数据异地多活项目，负责DRC（数据实时双向或多向复制）项目设计与开发工作、 负责DAL（数据库访问中间件）项目设计和演进。

内容简介

DRC通过将部署在不同机房的MySQL数据进行双向复制，实现单机房保存全量数据，业务本地读写。单机房故障时，分钟级机房流量切换。本次演讲将深入剖析DRC内部设计和实现原理。你将了解到：
1、DRC基本架构；
2、DRC高可用设计方案；

《携程第二代API网关设计与实践》(戳我观看）

直播时间：

2020-09-23 19:00

讲师介绍

俞炯，携程软件技术专家， 2016年加入携程，主要负责携程API网关的维护与研发，以及公共反爬相关基础设施建设。
​

内容简介

API网关是携程路由体系内的重要一环，在隔离&解耦网络环境、海外加速、单元化等场景内都承担着重要角色。网关同时也是公共业务需求的载体，包括安全认证、反爬、限流熔断、监控告警等。作为公共基础设施，保证自身稳定性，同时支撑业务发展是我们的首要目标。
​
本次将着重分享内容包括：
1、业务流量增长带来的性能问题；
2、出海、上云、异地多活对架构的要求；
3、多协议、多场景带来的治理问题；

《Envoy 架构在网易轻舟的落地实践》(戳我观看）

直播时间：

2020-09-30 19:00

讲师介绍

王佰平，网易数帆轻舟事业部 工程师， 负责轻舟Envoy网关与轻舟Service Mesh数据面开发、功能增强、性能优化等工作。对于Envoy数据面开发、增强、落地具有较为丰富的经验。
​

内容简介

Envoy 是一款由 Lyft 开源的高性能数据和服务代理软件，CNCF 毕业项目。新兴 API 网关如 Gloo，Ambassador 都基于 Envoy 进行扩展开发；而在服务网格中，Istio、Kong 社区 Kuma、亚马逊 AMS App Mesh、微软 Open Service Mesh 都使用 Envoy 作为默认数据面。
​
本次分享将详细介绍 Envoy 整体架构以及其功能特性，及经验总结：
1、Envoy 是什么？
2、Envoy 有什么？
3、Envoy 能做什么？

《云开发Serverless架构服务》(戳我观看）

直播时间：

2020-10-13 19:00

讲师介绍

杜欢（风驰），阿里云Serverless云开发平台负责人， 阿里巴巴前端委员会委员，致力于推动研发生态实现云端Serverless研发能力升级，实现云的开箱即用。 ​

内容简介

随着函数计算等 FaaS 云产品的不断完善，研发生态对 Serverless 的认知也日渐清晰，尝试也越来越多。在诸多实践中，许多人开始陷入一种迷思，FaaS 是不是只能用在一些 “计算任务” 场景？是不是只能在小程序这个场景才能用？K8S是不是很大规模的公司才能用？云原生，Serverless是不是只是说的好听，离我其实还很远呢？我们将为你揭示，一个真正人人可用的云时代研发模式已经到来！
​
在此分享中，你会了解到阿里云Serverless云开发平台如何通过三套Serverless架构服务帮助应用落地到Serverless架构。包括：
1、云原生时代的架构应该怎么做？
2、Serverless架构有什么优势？
3、应用如何落地？

    第一位嘉宾浙江大学教授、阿里巴巴-浙江大学前沿技术联合研究中心（AZFT）智能计算机系统实验室主任--陈文智，给大家分享了《教研云助力高效数字化转型》。陈教授展示了基于教研云的新一代教学平台，能够实现教学场景的全覆盖、AI优化教学质量、云化提升教学体验以及教学数据的多维分析，未来高校科研新模式将实现科研的数字化运营，打造科研协作空间，从而构建科研新生态。
    第二位嘉宾校宝在线CPO&创新事业部总经理--李杰，他是浙江大学管理学硕士、原阿里巴巴高级产品专家、原百度商业产品经理，这次给大家分享的主题是《透过疫情，看教培行业的DT未来》，现在IT时代正在逐步迈入DT时代，未来教育越来越多的基于数据驱动，因此教育行业也要顺势而为，拥抱DT，实现机构业务数据化、行业数据标准化、产业服务生态化的三步升级。
    第三位嘉宾阿里云智能解决方案架构师--胡中泉，作为十年阿里巴巴DBA，一直从事企业数字化转型数据库解决方案架构设计，这次带来的是《鱼熊兼得——云原生数据库技术解析》。云原生数据库存储计算分离，分别无限弹性，可具备HTAP特性，同时，云原生数据库关注弹性、性能和成本优化等上层需求，相比传统数据库，云原生数据库拥有更低的TCO、更好的性能与吞吐量，更便捷的使用体验更科学的使用方式。
    第四位嘉宾校宝在线架构师--李同刚，他是阿里云MVP、校宝在线共享技术部基建业务负责人，负责并参与了校宝云服务平台、DevOps平台、开放平台建设，这次分享了非常落地的《教育信息化平台DevOps实践》。DevOps 业务链路较长，因此我们要始终从业务问题出发，实现客户价值结合业务痛点，找到切入点，团队 Leader 要想好客户价值，聚焦、不要贪，“少则得，多则惑”，同时坚持大道至简，规范先行，从客户场景出发，方案做简单些，并且制定规范，做好期望管理。

    在四位精彩的嘉宾演讲之后，本次云栖大会教育专场还专门圆桌讨论了《云时代的教育SaaS平台技术演进之路》，校宝在线架构师肖伟宇、资深net开发工程师王斌与阿里云智能容量服务产品经理范捷惟、杭州互次方技术VP金立四位嘉宾在现场给大家带来了精彩有深入的交流探讨。

    每一位演讲嘉宾分享之后，现场的参会嘉宾也都提出了自己的疑惑和问题，现场交流气氛浓厚，大家对于新技术、新教育充满激情和能量。

阿里云·云效服务的内部版本“Aone”承载着阿里集团数百个BU协同研发和持续交付的职责，笔者在数月前短暂的参与了该平台的效能透视镜板块建设，因而得以从平台的“上帝视角”重新审视效能度量这件事，随着项目开展，略微摸索了些门道。此文中观点源于这段时间里笔者在团队内以及与周边相关团队的讨论和个人思考，且作抛砖引玉之用。

度量的分类

度量的分类方式有很多，其中比较有意思的一种角度，是根据目标意图将度量划分为“针对人的度量”和“针对事的度量”。

任何协作系统都离不开人的参与，加之可与绩效、考核等事情牵上关系，即使相关指标的分析往往伴随着争议，针对人的度量在企业里有时依然被视为一种“刚需”。譬如“代码量”、“代码质量”、“工作时长”等数据评判都是常见的依据指标。从产品实现而言，由于对结果可解释性要求高，这类度量的单因素指标居多，计算方案通常不会太复杂，宜采用小范围同维度横向比较，防止过度泛化。

相比之下，针对事度量的范畴和方法更加灵活。既包括简单的数值指标，譬如产研中的发布频率、需求交付时长；也包括需要对比分析的多元指标，譬如需求在各阶段的停留时长、缺陷在各环境的漏测率等。在就事论事的基础上，为了更全面的理解事实的客观规律，还经常需要将一组数据向上聚合（譬如整个部门、整个项目的情况）或者跨领域关联（譬如业务领域需求关联到相关代码提交情况），从而获得更宽的观察视角。由于涉及的度量主体更多，有时为了确定哪个主体是主要的影响因素，还需要进行额外的归因判定。相较于以人为目标的度量，对事进行度量时，可以包含更多的经验和推理因素。

对人或对事主要是针对度量目的而言，在实际运用时，两者采用的具体指标会有许多共同之处，并不能一概而论。根据管理学中的“平衡计分卡（The Balanced ScoreCard）”理论，度量活动要遵循“目标-度量-指标-行动”的规则，指标最终服务于目标的达成，好的度量产品不仅应当反映“发生了什么”，还应当能根据目标提供“该怎么做”的辅助建议。因此度量类产品的成败，不仅是对指标设计者的领域理解、抽象能力的挑战，而且对产品自身的业务目标清晰度也会提出很高的要求。

效能的本质

归根究底而言，效能的本质是对价值流动速度和质量的评价。

“价值流”的概念伴随着精益思想的传播，被越来越多行业所接纳。不过很少有其他哪个行业能够像软件研发行业这样，能够让价值交付的各个环节几乎完全在线数字化，从而提供大量可分析的过程数据样本。

所谓价值流动过程可以表示为，“价值原料”在可被度量的价值加工活动之间有序传递，不断叠加价值增量，最终形成可被消费的“价值产物”。下图将这一过程的度量抽象为一种非常简洁的表示结构，可称为效能度量的“元模型”。

度量中所用的各类“领域特征”则是由在此元模型之上的领域对象，以及基于这些对象的“领域指标”来定义的。

譬如在研发领域，“价值原料”可以是一个业务方的需求，或是一个开发者突发奇想的创意。可被度量的活动包括需求拆解、任务指派、代码编写、测试、部署、验证、发布等等。每个活动本身都具有可被观测的属性，实体之间也具有可被量化的关系。这些实体、属性、关系就组成了特定领域的模型，下图展示了一种简化的研发度量领域模型（为了美观省略掉很多实体关系连接，仅作示意）。

有了领域模型，就可以基于规则制定指标。指标通常被描述为各种量化特征和实体属性的数值计算。有些指标是领域无关的，譬如端到端流通时长；有些指标是多个领域之间可以复用的，譬如许多行业都会有单位时间任务吞吐量、任务按时完成率这样的指标；有些指标是领域特有的，譬如研发领域的千行代码缺陷率等等。

在指标之上，还需要有与具体运用场景相匹配的工具或平台来将度量结果转换为便于观察分析的表现形式。譬如各种图表、报表，以及事件通知。

元模型和领域对象的分离，似乎能够形成一种足够抽象的通用度量产品，通过领域相关的指标规则、展示规则、通知告警规则，快速适配不同目标和场景，然而现实情况其实更复杂。一方面受制于计算能力，有些指标实际无法根据模型+规则实时计算出来，必须单独预先算好，以空间换时间。另一方面受限于价值增值过程的可观测性，并非所有行为的结果都能立即被简单量化（否则说服人们坚持锻炼身体就容易多了），即使在高度数字化的软件研发领域，依然存在数据质量和时效性问题，在使用数据时需要加以考虑。因此各种效能的场景虽然具有十分相似的流动特征，实际产品依然会不可避免的根据业务定制化，万能的度量工具或公式是不存在的。

模型的存储

对于度量模型的存储，图数据库可能是最好的选择，没有之一。

相比结构化的SQL数据库和文档型的NoSQL数据库，图数据库属于比较小众的一种偏门奇术，主要用在知识图谱和基于关系的信息搜索领域。从基本特征而言，图数据库通常具备NoSQL的非结构化KV存储能力，允许同一类实体具有不同属性项的实例，这对于处理来自多种数据源或多个子类型的实体信息带来很大便利。同时，图数据库通常能像SQL数据库那样支持事务和多实体关联查询。不仅如此，图数据库对复杂关系的检索性能远高于SQL数据库，对于判断、循环查询的支持也比SQL存储过程更加优雅。

然而这些基础能力上的差异，并非我推荐将图数据库用于效能度量的主要原因。

好的技术选型应该能够充分适应潜在的业务需求变动，避免过早将技术实现耦合到局部的应用场景。在基于SQL表的开发模式里，“表结构设计”是在软件详细设计阶段里非常重要的一个环节，因为它不仅是对整体业务领域的建模，还关系着未来数据查询的效率和便利性。熟悉SQL表设计的同学应该知道，1对1、1对N、N对N关系，数据表的处理方法是完全不同的：N对N关系需要额外设计关联表，1对N关系通常是在后者的实体上设计外键，而1对1关系的外键设计就更有讲究了，要根据实际场景来决定该在哪个实体上放另一者的外键，然后在使用的时候顺着这个关联方向来查询。对于聚合的设计也是如此，需要事先在被聚合表上提前设计好用于聚合的外键，因此会有“事实表”、“维度表”的区分。数据的查询规则，在数据库表结构设定的时候就被确定下来了。

对业务模式比较固定的场景而言，提前考虑好数据的使用方法并做针对性优化显得合情合理，然而效能度量业务并不属于此类。在度量领域里，关联、级联、聚合都是十分常见的指标计算操作，由于指标的作用在于发现潜藏于表面之下的问题，事先不应当提前规定只能从哪一类实体作为关联查询的起点，或者必须以哪些维度做聚合观察。

就图数据库的存储模型来说，所有业务实体都是平等的，任何类型的关系都由实体间的关联来表示。这就像是在SQL表设计时，不论是1对1还是N对N关系，总是额外增加一张关联表，却无需顾虑多表JOIN带来的性能影响。这样一来，相当于将查询和聚合方式的决策推迟到实际使用的时候再做，从而有效解耦建模和查询时的相互制约，不再需要为优化查询而返工改表。

此外，由于关联直接建立于实体之间，当删除实体的时候，实体间的关联也将自动断开。这就像有垃圾回收机制的Java语言不用自己管理内存指针一样。图数据库绝不会产生由于关系修改时的不对称清除而导致的数据不一致情况。

那图数据库会不会有坑？肯定有。不过在我们目前有限的探索里，遇到比较大的麻烦主要来自它不够完善的周边工具配套、阿里云图数据库服务的某些配置限制，以及市场上稀缺具备相关技能的专业工程师。

专家经验

在研发效能领域，度量的终极目标是DevOps文化所提倡的识别和消除系统性瓶颈。

通过各式各样的过程数据，经验丰富的项目经理和管理教练往往能够准确判断出项目的潜在问题和交付风险。

在经济学领域有个十分有趣的“古德哈特定律”，即“当决策者试图以一个事物的客观测度指标作为指针来施行政策时，这一指标就再也不能有效测度事物了”。

然而效能度量并不是玄学，价值生产活动中的风险应当是有章可循的。古德哈特式的此消彼长现象其实来源于经济领域的范围太过宽广，任何实用指标往往只能是局部度量的结果。效能透视镜产品的提出者嵩华老师曾经分享过一种识别研发项目系统性风险的思路，即有的放矢的关注四种典型的全局现象：

• 流动阻滞
• 返工
• 落后的工程能力
• 技术债务

这几种现象不太容易在局部进行遮掩，且在一定条件下能够相互叠加，成为“烂项目”的标配。

透过整个研发过程中的种种现象，找到反映这些全局性问题的蛛丝马迹，不仅能在一定程度上让“专家经验”产品化、标准化，也有助于将效能数据的使用方法从当前普遍的“事后复盘”式向以全局流动速率和质量作为关注点的“风险管控”式发展，从而在可靠性和时效性两个方面都得到提升。

总结

数据不会骗人，但数据的呈现和解读依然有很大的空间值得探索。现实事物复杂而多面，度量正是为描述和对比这些具象事实而采取的抽象和量化措施，从某种意义上来说，度量的结果一定是片面的，反映部分事实。没有银弹，也没有完美的效能度量。

对于企业研发效能的提升，开发者工具、效能方法理论、效能度量指标都是缺一不可、环环相扣的几个重要板块，相信随着数据价值被越来越多的挖掘，我们终将实现更有效的反馈和更精确的赋能，让研发协作真正变得透明、简单、高效。

最后

分享十条前人总结的经验观点。

• 任何指标一旦用于管控，就不再可靠（古德哈特定律）。
• 测量的对象与人越近，越不可靠。
• “凡可度量，皆可改造”是错的。
• 变化趋势的价值高于指标绝对值。
• 选择适当的而非“标准的”指标，若发现指标没用，果断舍弃。
• 务必了解指标的获取成本，明确指标意图和针对的企业目标。
• 设计“北极星指标”，指标数量越多，边际收益递减。
• 不要将指标对所有人透明。
• 让一线人员参与指标制定。
• 如果可能，合理缩短度量周期。

系统重构后产生新的需求

掌游科技有SaaS游戏发行运营平台，帮助游戏厂商通过大数据分析更好的运营游戏。随着业务量的不断上涨，之前单数据库的系统架构逐渐出现了性能瓶颈。

为了能更好的支撑业务，掌游科技将单库按业务拆分为了四个数据库，整个系统也因为分库而进行了重构。但是重构后的系统经过测试发现有很多问题，几次上线后都出现了不稳定的情况，并且由于业务复杂，开发人员众多，很难快速、全面的发现系统Bug和性能约束点，所以急需通过APM工具来发现系统中存在的各个性能约束点。

掌游科技期望APM工具能具备以下五点特性：

• 快速无侵入的接入方式：期望最大限度的不改动系统代码，以无侵入、无感知的方式将监控系统接入现有系统；

• 系统性能低损耗：接入的监控系统不对能宿主系统产生过高的性能损耗，期望不超过5%；

• 可视化的配置操作方式：不期望繁琐的、通过命令形式的配置。期望可以通过Web控制台的方式方便的进行配置，比如采样率、SQL提取规则、业务监控配置等；

• 全方位的应用监控能力：期望从应用层面、节点层面、接口层面、主机层面多维度监控系统。比如应用的整体健康度，接口的调用次数、响应时间、慢SQL分析、异常分析、JVM分析、内存快照分析、CPU/内存/IO分析等；

• 支持PHP语言：客户主要使用PHP语言进行开发，希望监控系统可以全面支持PHP语言的各个组件和框架。比如CURL、PDO、Mysqli、Yar Client、GRPC Client、Predis Client、Memcache Extension等。

解决方案

阿里云自研的应用实时监控服务ARMS完美的契合了客户的诸多痛点，通过Agent的方式无侵入的、快速的接入客户系统，通过白屏化的方式进行设置，提供各种丰富完善的视图协助客户全方位监控系统，并且ARMS结合众多客户场景和专家经验，提供智能诊断功能。帮助客户快速、准确的发现和定位到了系统重构后的很多性能约束点和隐患，让客户有的放矢的对系统进行优化。

1. 性能瓶颈和Bug一目了然：无论从CPU、内存、磁盘、网络、JVM GC、JVM堆内存、内存快照分析的主机层面还是从接口响应时间、请求数、错误数、异常分析、上下游接口、接口快照、调用链路、线程剖析的接口层面，亦或是慢SQL分析、数据库连接数、CPU/内存/磁盘使用率、网络流入/出流量监控的存储层面，以及NoSQL、MQ监控等。将系统360度无死角的监控起来，所有性能问题都无所遁形。

2. 提前预知系统问题：ARMS提供了完善的预警通知功能，可以基于主机监控、JVM监控、异常接口调用、应用调用统计、数据库指标等多个指标类型下几十钟触发条件来灵活的设置预警规则。同时提供多样化的通知方式以满足不同客户的通知需求。

3. 支持PHP：目前开源的APM工具对PHP支持的都不够完善，无论在无侵入接入方面，还是支持的组件方面，面对PHP语言构建的系统，都不能很好的支撑形成监控链路闭环。ARMS在对PHP语言系统的监控方面已经沉淀多年，绝大多数PHP的框架和组件都已支持，有很完善的问题分析定位的链路闭环和最佳实践。

Spring 5 中文解析之核心篇-IoC容器

Spring 5 中文解析核心篇-IoC容器之依赖关系

Spring 5 中文解析核心篇-IoC容器之Bean作用域

Spring 5 中文解析核心篇-IoC容器之自定义Bean性质

Spring 5 中文解析核心篇-IoC容器之BeanDefinition继承与容器拓展点

Spring 5 中文解析核心篇-IoC容器之基于注解的容器配置

Spring 5 中文解析核心篇-IoC容器之类路径扫描和组件管理

Spring 5 中文解析核心篇-IoC容器之JSR330标准注解

Spring 5 中文解析核心篇-IoC容器之基于Java容器配置

Spring 5 中文解析核心篇-IoC容器之Environment抽象

Spring 5 中文解析核心篇-IoC容器之ApplicationContext与BeanFactory

Spring 5 中文解析核心篇-IoC容器之Resources

Spring 5 中文解析核心篇-IoC容器之数据校验、数据绑定和类型转换

Spring 5 中文解析核心篇-IoC容器之SpEL表达式

Spring 5 中文解析核心篇-IoC容器之AOP编程(上)")

Spring 5 中文解析核心篇-IoC容器之AOP编程(下)")

Spring 5 中文解析核心篇-IoC容器之Spring AOP API

Spring测试篇章：

Spring 5 中文解析测试篇-Spring测试

Spring 5 中文解析核心篇-集成测试之概要和集成测试注解

Spring 5 中文解析核心篇-集成测试之TestContext(上)")

Spring 5 中文解析核心篇-集成测试之TestContext(中)")

Spring 5 中文解析测试篇-集成测试之TestContext(下)")

Spring 5 中文解析测试篇-Spring MVC测试框架

Spring 5 中文解析测试篇-WebTestClient

Spring存储篇章：

Spring 5 中文解析数据存储篇-Spring框架的事物支持模型的优势

[Spring 5 中文解析数据存储篇-事务同步和声明式事物管理
](https://mp.weixin.qq.com/s?__biz=MzA3NDgzODYzNg==&tempkey=MTA3OV91TU8vcGlxSXdvTGNhZ2o0a3p2RXZvSGpJeXNCMmNCUkszbU9OZzVSc09rT19Zejl6b3JCWHZHU0JfN3ZrVDhhbzZUV3BfS2s3aHFEakhPb3V4dXVkMVp4ajFfZllOcnM2N3huU2d1ZUJZZlN6T1lZNVVKWHJjOWRkdEg3Uzg3RmpFRzZXbHMzQ3lFUUEwd1JqTl9JOGZzWGxMYWh6N1lhY05DYnFRfn4%3D&chksm=1f7b0caa280c85bcce8c4ffe9fb21629f683d5d9127116dae91dc9b9cbd2f367a19514fef76f#rd)

[Spring 5 中文解析数据存储篇-@Transactional使用
](https://mp.weixin.qq.com/s?__biz=MzA3NDgzODYzNg==&tempkey=MTA3OV9RNU1VNnhsa0ZkRlhBb3Fla3p2RXZvSGpJeXNCMmNCUkszbU9OZzVSc09rT19Zejl6b3JCWHZHU0JfNTZ4dWhENjFrNUV6dlpieWYxVndQRlBNNkFRZVBFWlVyZHdiQlhTMmZMM0g0TnppT040Nk5QUU1rcEpNY2FDN09nZnNPeG5WTU8wajZCNUowaHZnTHhZcGpYdVRlNXQzWTZUSV8yOEpJNl9nfn4%3D&chksm=1f7b0cb3280c85a5682b1c9ea3cf7d2a69abdd6fe9147ed4335a5d5cfbef7c04ed314bd389de#rd)

Spring 5 中文解析数据存储篇-编程式事物管理

完整电子书地址

Spring对数据访问对象（DAO）的支持旨在使以一致的方式轻松使用数据访问技术（例如JDBC、Hibernate或JPA）。这使你可以轻松地在上述持久性技术之间进行切换，并且还使你无需担心捕获每种技术特有的异常即可进行编码。

2.1 一致的异常层次结构

Spring提供了从特定于技术的异常（例如SQLException）到其自己的异常类层次结构的便捷转换，该异常类层次结构以DataAccessException作为根异常。这些异常包装了原始异常，因此你永远不会丢失任何有关可能出错的信息。

除了JDBC异常，Spring还可以包装JPA和Hibernate特定的异常，将它们转换为一组集中的运行时异常。这样，你就可以仅在适当的层中处理大多数不可恢复的持久性异常，而不必在DAO中使用烦人的样板捕获和抛出块以及异常声明。（尽管如此，你仍然可以在任何需要的地方捕获和处理异常。）如上所述，JDBC异常（包括特定于数据库的方言）也被转换为相同的层次结构，这意味着你可以在一致的编程模型中使用JDBC执行某些操作。

在Spring对各种ORM框架的支持中，上述讨论对于各种模板类均适用。如果使用基于拦截器的类，应用程序必须关心处理HibernateExceptions和PersistenceExceptions本身，最好是通过分别委托给SessionFactoryUtils的convertHibernateAccessException(..)或convertJpaAccessException()方法。这些方法将异常转换为与org.springframework.dao异常层次结构中的异常兼容的异常。由于未选中PersistenceException，因此它们也可能被抛出(不过，在异常方面牺牲了通用的DAO抽象)。

下图显示了Spring提供的异常层次结构。（请注意，图像中详细说明的类层次结构仅显示整个DataAccessException层次结构的子集。）

2.2 用于配置DAO或存储类的注解

确保你的数据访问对象（DAO）或存储库提供异常转换的最佳方法是使用@Repository注解。此注解还使组件扫描支持可以查找和配置DAO和存储库，而不必为其提供XML配置。以下示例显示了如何使用@Repository注解：

@Repository //1
public class SomeMovieFinder implements MovieFinder {
    // ...
}

1. @Repository注解

任何DAO或存储库实现都需要访问持久性资源，具体取决于所使用的持久性技术。例如，基于JDBC的存储库需要访问JDBC数据源，而基于JPA的存储库需要访问EntityManager。完成此操作的最简单方法是使用@Autowired、@Inject、@Resource或@PersistenceContext注解之一注入此资源依赖项。以下示例适用于JPA存储库：

@Repository
public class JpaMovieFinder implements MovieFinder {

    @PersistenceContext
    private EntityManager entityManager;

    // ...
}

如果使用经典的Hibernate API，则可以注入SessionFactory，如以下示例所示：

@Repository
public class HibernateMovieFinder implements MovieFinder {

    private SessionFactory sessionFactory;

    @Autowired
    public void setSessionFactory(SessionFactory sessionFactory) {
        this.sessionFactory = sessionFactory;
    }

    // ...
}

我们在此显示的最后一个示例是对典型JDBC支持的。你可以将DataSource注入初始化方法或构造函数中，在此方法中，你可以使用此DataSource创建JdbcTemplate和其他数据访问支持类（例如SimpleJdbcCall等）。以下示例自动装配数据源：

@Repository
public class JdbcMovieFinder implements MovieFinder {

    private JdbcTemplate jdbcTemplate;

    @Autowired
    public void init(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    // ...
}

有关如何配置应用程序上下文以利用这些注解的详细信息，请参见每种持久性技术的特定介绍。

作者

个人从事金融行业，就职过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号：青年IT男 获取最新技术文章推送！

博客地址： http://youngitman.tech

CSDN： https://blog.csdn.net/liyong1028826685

微信公众号：

技术交流群：

【阿里云】【域名】【域名交易平台】【未实名.cc/.tv域名下架】

维护时间：北京时间2020年9月21日 00:00

维护内容：未完成实名认证的.cc/.tv域名将被系统下架一口价（万网）、域名竞价等出售信息。

维护影响：自北京时间2020年8月10日 10:00起，.cc/.tv域名的注册、转入、持有者信息修改（过户）等操作将要求进行域名实名认证（包括命名审核和实名资料审核）。

阿里云域名交易平台出售中的.cc/.tv域名若未完成实名认证，一口价（万网）、域名竞价等类型将无法被正常下单购买。请尽快完成.cc/.tv域名实名认证！

出售中的.cc/.tv域名，若未能在9月21日00:00前完成域名实名认证，相关出售信息将被系统自动下架，您须待域名实名认证完成后，重新操作域名上架。

由此给您带来的不便，我们表示歉意，敬请谅解。

       在此节假日期间亲爱的各位老铁，我们依然为您安排了值班工作人员哦！

       阿里云售前、售后：尹先生-13246463538

       阿里云技术支持：陈先生-14737363737

       其他服务需求与咨询：高先生-15869041323

     我们友好的小伙伴会一直陪在您身边，有问题速速联系我们吧！也可以移步至官网智慧表单提交您的需求或问题哦，我们会在第一时间处理。

     感谢大家在2020年对我们的支持，因为你们的信任，我们才能在激烈的市场竞争中不断进步与发展。未来我们不负年华，提升服务质量与体验。也祝您节日快乐。

                                                                                                         广州米姆信息科技有限公司

                                                                                                          2020年9月

作者：黛忻

浙江禾连网络科技有限公司（简称：禾连健康）成立于2014年，多年来专注医疗互联网产业，致力于通过互联网技术，建立服务患者、医生、医院的大平台。

业务范围从医院Wi-Fi、患者端App、医护端App，拓展到提供一站式医院物联网应用解决方案。目前医院Wi-Fi已签约全网245个城市1700多家医院，成为中国最大的医院Wi-Fi服务商。禾健康、禾连保、禾医助几个App提供一站式家庭健康管理服务，服务1亿用户。

客户需求：

禾连是聚石塔的最早一批用户，采用ECS + Docker模式部署应用。因聚石塔定位的变化，没有持续维护相关业务；再加上禾连业务的不断发展，而聚石塔在弹性、服务治理上的能力不满足预期，禾连不得不考虑重新做技术选型。

在架构优化初期，公司基于ECS自建整套微服务架构，过程中暴露了很多问题：

（1）产品迭代跟不上业务变化：传统开发模式无法支撑公司业务的快速发展，研发既要忙于业务，又要Cover底层组件开发和运维，效率非常低；

（2）硬件闲置成本高：云上按业务峰值保有大量的包年ECS，逐台购买安骑士服务。但业务具有潮汐特性，峰谷时闲置浪费高。而且业务瞬息万变，一旦发展不符合预期，购买的ECS会长期处于闲置状态。

（3）系统维护成本高，无运维人员：公司无专职运维人员，系统相对复杂，微服务架构 + APM工具等均采用开源自研，开发&维护成本高。聚石塔上ECS + Docker高密部署的降本方案，集群初始化非常繁琐且耗时较长，需给每台ECS安装探针，运行一系列初始化脚本。研发精力严重分散，疲于奔命。

（4）效率&稳定性：系统的扩缩容困难，流量高峰时效率得不到保证。且服务发布和重启的时候偶尔会影响线上业务稳定。

使用Serverless技术构建新型互联网医疗应用

基于Serverless应用引擎（SAE），提供了一个零改造、开箱即用的Serverless PaaS，最大程度帮助用户屏蔽底层IaaS、K8s运维、以及常用微服务组件的学习成本，解决了禾连长期以来运维成本高、开发迭代和弹性效率低，硬件闲置成本高等痛点问题。

降成本：节省自建微服务架构+APM的ECS成本，无需购买ECS安全骑士服务；基于秒级弹性能力，按需自动弹、同时通过一键启停开发测试环境，极大的提升了资源利用率，比ECS方案节省20%以上的硬件成本。

提效率：提供了开箱即用的微服务治理、应用监控的能力，零运维零改造直接使用，支撑新业务快速上线；提升定位诊断效率，让企业专注于业务本身。

极致弹性，发布无感知：基于SAE 的定时弹性和监控指标弹性（CPU、Memory等），无须容量规划，秒级弹性，便可轻松应对流量暴增，保障SLA。通过配置健康检查探针，系统自动检测，做到服务发布和扩缩容时业务无感知。

一站式体验：自动集成阿里云基础设施类产品：SLB、SLS、NAS等和微服务生态产品：ACM、ARMS、AHAS，对接DevOps产品云效，提供一站式的上云体验。

消息队列（Message Queue，下文简称MQ）是分布式互联网架构中必不可少的核心组件，包括RocketMQ、Kafka、RabbitMQ等在业界广泛使用的产品，在消息分发、异步解耦、削峰填谷、广播通知等领域发挥着巨大的作用。

在MQ的使用过程中，在线对MQ组件进行迁移是一个非常普遍的需求，在如下的几个场景中，都会涉及到MQ的在线迁移：

（1）规格升级。比如将3 Broker的Kafka集群替换成6 Broker的Kafka集群。

（2）更换另一种MQ产品。比如将RabbitMQ替换为性能和扩展性更强的RocketMQ。

（3）使用云服务替换自建MQ集群。比如将自建的RocketMQ集群替换为云上商业版RocketMQ服务。

在MQ迁移的过程中，存在3个非常重要的需求：

• 操作简单。
• 风险可控。
• 不影响业务系统的正常运行。

如何让MQ的在线迁移同时满足这3个重要的需求呢？本文将对几种可行的方式进行深入探讨。

理论基础

在涉及到MQ在线迁移的所有方案中，都存有一个很重要的原则：对于发往MQ的每一条消息，如果已经被它的消费者成功接收并得到处理，这条消息就不再具有业务含义。已经被成功接收并得到处理的消息，只体现出统计方面的价值，并不需要随着MQ本身的迁移而进行数据迁移。

在数据库迁移的场景中，新旧DB之间的数据迁移是非常重要的工作，这是因为DB中的数据是持久化的数据，需要伴随着数据库的生命周期而长期存在。

而对于MQ而言，消息一旦被消息者接收并得到处理，就不再是持久化的数据，可以直接删除或归档。因此在MQ在线迁移的场景中，对已经处理过的消息，是没有数据迁移必要的。这样就将问题简化为：如何在迁移的过程中确保每一条消息被成功接收并得到处理。

在系统维护期停业务迁移

我们先从一个最简单方案开始体验MQ在线迁移是如何进行的。对于不要求7*24小时连续运行的业务系统，可以利用系统维护期的时间窗口，通过停业务的方式来实现消息队列的迁移。这种迁移方式因为不需要保证业务的连续性，操作起来就非常简单。

（1）初始状态

进入维护窗口期后，关闭生产者应用，这个时候不会再有的新的消息写入MQ：

在这个状态下保持一段时间，当MQ上的所有消息都被消费者接收并成功处理后，就可以对消费者进行版本发布，使其从新的MQ上接收消息：

接下来再启动生产者，使其指向新的MQ，整个操作就已经完成。当系统运行稳定后，可以对原MQ实例进行相关数据归档后直接下线：

在停业务迁移方案中，最关键一步，在于如何在系统维护窗口期之内，确保原MQ上的所有消息被消费者接收并成功处理。因为生产者关闭之后，不会有新的消息写入原MQ，只要预留足够长的时间，原MQ上堆积的消息一定会被消费者取走。在这个方案中，新MQ和原MQ也可以是不同的产品，比如从RabbitMQ迁移到RocketMQ也是可以支持的，因为生产者和消费者都经过了版本发布的动作，只需要在新版本中对API和收发逻辑进行修改就可以实现。

双订阅方案

在互联网领域，能够容忍维护期将业务暂停的系统越来越少了，7*24不间断服务是行业的趋势，上述的停业务迁移方案就不再适用了，如何在MQ迁移的过程中确保业务持续运行呢？

有一个非常棒的idea是让消费者同时具有从原MQ和新MQ接收消息的能力，这样不管生产方往哪一个MQ发送消息，都能够确保消息得到及时的处理。这是一种不需要暂停业务的方案，我们来看一下具体的步骤。

首先对消费者进行改造，使其同时连上新老两个MQ，具备同时从新老MQ接收消息的能力，这就是所谓的“双订阅”：

接下来对生产者进行发布，使其往新MQ发送消息，等原MQ上堆积的所有消息被消费者接收并成功处理后，就可以对原MQ下线：

在对原MQ下线的时候，因为消费者还保持着双订阅的状态，所以最好先切断消费者与原MQ的连接，再关闭原MQ，否则会造成一些异常（取决于SDK的实现）。如果消费者的订阅逻辑实现的足够优雅，可以在不重启消费者的情况下，通过一个指令在线切断消费者与原MQ的连接。

这个方案看似可以用一种对业务无损的方式在线迁移MQ，在实际操作中可行性却很低，其根本原因在于：同时从两个MQ接收消息的改造工作量极大。一般情况下，每一个消费者都在引入MQ产品对应的SDK，并通过MQ提供接入点与MQ建立连接后，接下来就只需要围绕业务逻辑完成所需要的消息订阅操作。这个时候要想同时从一个新的MQ接入消息，需要在代码层面对所有的订阅逻辑进行改造，这是一项非常复杂的工作。

在新MQ和原MQ是不同消息队列产品的情况下，消费者需要同时引入两套不同的SDK，改造难度会变得更大。基于双订阅方案完成MQ的迁移后，还需要考虑将来清理掉消费者从原MQ接收处理消息的遗留代码，这也是需要一定工作量的。

如果在MQ和消费者中间，能有一个中间件来实现双订阅的逻辑，是不是消费者的代码就不需要改造呢？答案是肯定的。但引入这样的中间件本身就是一项非常有挑战的工作，还增加了整个系统的复杂度，如果仅仅是为了MQ的在线迁移而引入一个新的组件，是得不偿失的。

基于工作量和风险的考虑，尽量不要使用双订阅方案。

最优方案

双订阅的本质，在于存在一个消费者可以同时接收新旧两个MQ消息的中间状态，在这个状态下，不管生产者往哪个MQ发送消息，消息都可以得到及时的处理。能不能有一种更简单的方式让消费者可以同时接收新旧两个MQ的消息呢？当然有，而且实现方式更加的简单。

在一个可靠的分布式微服务系统中，应用都可以通过增加节点的方式而进行水平扩容，为了确保整套系统的高可用性，每一个应用都不应该长期处于单实例运行状态，而是通过多个无状态的应用实例组成一个应用集群。因此，在真实环境下，不管是消息的生产者还是消费者，都至少有2个实例在运行。在迁移MQ的过程中，“消费者可以同时接收新旧两个MQ的消息”的中间状态，并不一定要让消费者的每一个实例都通过双订阅来实现，其实只要让一部分实例从原MQ接收消息，另一部分实例从新MQ接收消息就能满足了。通过这样的思路，能极大程度上简化MQ迁移的工作量，而且在迁移的过程中确保业务不受任何影响。

在迁移之前，需要先把元数据信息从原MQ复制到新MQ集群，不同的消息队列产品之前元数据的格式不一样，需要根据业务场景进行元数据的转换，元数据包括Topic、Queue、消费组、基础配置等信息。

首先，通过灰度发布机制，让一部分消费实例连上新的MQ。如果之前的消费者是单实例，这个时候也可以增加一个新的消费实例来完成这个步骤：

接下来，让生产者往新的MQ发送消息，这个操作并不一定需要采取一刀切的方式，也可以通过灰度发布的方式让消息的转向逐步转移到新的MQ上来。最终，原MQ将不再接收新的消息，它上面堆积的消息总将会被成功接收处理，这个时候可以继续通过灰度发布的方式解除消费者与原MQ的连接，连接全部解除完之后，原MQ就可以关闭了。

在这个方案中，对于单个的生产者和消费者，都不存在同时连接新旧两个MQ的情况，因此在改造工作量非常小。而且迁移的过程通过灰度的方式实现，既不会影响业务，又可以进一步的降低风险，是消息队列在线迁移的通用方案。

常见问题

问: 为什么不在新旧MQ之间进行消息数据的同步？

答：对于MQ而言，消息一旦被消息者接收并得到处理，就不再是持久化的数据，可以直接删除或归档。在迁移的过程中，新旧MQ之间消息数据同步是没有必要的，反而会增加迁移的难度，并导致消息被重复接收。

问：迁移过程中需要验证消息幂等性吗？

答： RocketMQ、Kafka等大多数消息队列产品都没有从消息队列服务端本身确保消息只投递一次，需要消费者自行实现对幂等性的保证。因此，不管在消息队列的迁移过程中，还是正常使用中，都应该借助数据库、Redis等外部系统确保消息的幂等性，否则会造成业务逻辑重复处理。

近些年，在线教育行业飞速发展，为整个社会的知识传播提供了前所未有的便利性。通过多种形式的在线教育平台，学员与教师即使相隔万里也可以开展教学活动。借助丰富的网络课件，学员还可以随时随地的进行学习，真正打破了时间和空间的限制。在各种形式的网络课件中，视频课件自然是最直观表现力最丰富的形式，因此视频课件的市场占有率也在逐年提升。

视频处理需求分析

对于在线教育领域的视频课件出品方而言，每天都要对大量视频内容进行处理，下图展示了一个比较典型的场景：

（1）用户上传一个视频到平台后，会先在对象存储中对视频源文件进行暂存。

（2）平台对视频进行预处理，并打上水印。

（3）平台将视频文件转换为其他格式，并对分辨率进行调整，以适配各种不同的终端设备的要求。

（4）将处理好的视频文件保存回对象存储，并同步到CDN进行加速。

虽然从流程上来讲，这个场景比较简单，但在技术上的挑战其实是非常大的。视频课件的原作者来自于在线教育平台的广大用户，可能是平台负责内容输出的内部用户，也有可能是签约的教师，或者是平台认证过的分享型用户。用户上传视频的操作并没有固定的频率，往往集中在几个时间段，存在明显的波峰波谷。在业务高峰期，视频处理的需求量非常大，有的在线教育企业每天要完成数万个视频的转码工作。对于负责建设视频处理系统的技术团队而言，这样的业务场景就留给了他们一系列的挑战：

（1）如何确保这套系统在业务高峰期的高可用性？

（2）如何让每一个上传的视频尽可能快的处理完？

（3）如何尽可能的降低资源成本？

（4）如何高效率的应对需求的频繁变更？

基于这几个诉求，我们结合云计算的特点，来分析一下可行的解决方案。

使用SaaS化的云服务完成视频处理

随着各大云计算厂商产品线的不断丰富，我们可以很轻松的寻找到开箱即用的方案来解决这类典型的视频处理需求。以阿里云为例，视频点播类产品提供了视频采集、编辑、上传、媒体资源管理、转码处理、视频审核分析、分发加速于一体的一站式解决方案。

对于技术团队而言，采用这样的方案不用预先准备任何计算资源，甚至不用编写任何代码，就能够从无到有拥有一整套视频处理系统，完全不用考虑资源规划的问题。这样的方案非常适合在业务发展初级需要让系统快速上线的场景。

但随着业务的不断发展，开箱即用的SaaS化方案还是存在不少的局限性，基于如下的原因，大多数的技术团队还是会选择自己建设视频处理系统：

（1）对于之前已经通过FFmpeg技术实现的视频处理服务，因为涉及到复杂的业务逻辑，很难直接迁移到SaaS化方案上来。

（2）高阶的视频处理需求必须使用代码来实现：比如音频降噪、插入动态Gif水印、按固定频率截帧等等。

（3）使用高分辨率的大视频是行业趋势，对于超大视频的处理，比如10G以上的1080P视频，往往需要通过自定义的手段进行计算优化，才能保证处理的及时性。

（4）在很多种场景下，自建视频处理系统都会带来明显的成本优势。

（5）频繁的业务需求变更需要对整套系统进行更精细粒度的迭代管理，比如采用金丝雀策略降低新版本发布所带来的风险。

那么如何建设一套同时具备高性能、高可用性、高灵活性、低成本特点的视频处理系统呢？

基于分布式集群

最典型的方案是申请一组云虚拟机，在每台虚拟机上部署视频处理应用，组建成一个可以水平伸缩的服务集服。当有新的上频上传的时候，可以触发一个处理任务，并通过负载均衡或消息队列对任务进行分发，接到任务的应用节点负责完成对应的任务。

通过这个架构，在业务高峰期，用户上传视频行为比较密集，可以增加服务集群的实例数量，来提升处理能力。在业务低峰期，可以减少服务集群的实例数量，来减少资源成本。

此方案可以通过定制化的代码逻辑实现各种高阶的视频处理需求，灵活度非常高，配合可以水平伸缩的计算集群以及负载均衡机制，能同时满足性能和成本方面的需求，是一套被广泛采纳的方案。但在生产环境大规模运行的情况下，这套方案还是会暴露出很多问题：

（1）维护工作量大。

整套系统的维护工作量涵盖了虚拟机、网络、负载均衡组件、操作系统、应用等多个层面，需要投入大量的时间和精力来保障系统的高可用性与稳定性。举一个最简单的例子，当某个应用实例出现故障的时候，如何第一时间定位故障并尽可能迅速的将其从计算集群中摘除，摘除之后又如何保证之前没有完成的任务能够重新得到处理呢？这些都需要再配合完整的监控机制、故障隔离恢复机制来实现，甚至涉及到代码层的业务逻辑优化。

（2）弹性伸缩能力滞后。

有两种方式实现计算集群的弹性伸缩：通过定时任务触发，或者通过指标阈值（CPU利用率，内存使用率等）触发。不管采用哪种方式，都没有办法基于用户行为精细化管理，在遇到任务密度大幅度起伏的时候，会面临弹性伸缩能力滞后的问题。当来自用户的视频上传请求突增的时候，新增一个应用实例需要经过申请云资源>初始化>部署应用镜像>应用启动>加入负载均衡列表等多个阶段，即便通过Kubernetes+预留资源池等技术优化，也往往需要10分钟以上。

（3）资源利用率低。

滞后的弹性伸缩能力会导致伸缩策略制定的相对保守，造成计算资源的大量浪费，增加了使用成本，如下图所示：

有没有一种方案能能帮助技术团队专注于业务逻辑的实现，并可以根据用户的实际上传请求进行精细化的资源分配，实现资源利用最大化呢？随着云计算的飞速发展，各大云厂商都在积极探索新的方案，用更加“云原生”的方式来解决成本和效率的问题，阿里云提供的函数计算 + Serverless工作流就是这个领域非常具有代表性的方案。

函数计算

阿里云函数计算是事件驱动的全托管计算服务。通过函数计算，开发者无需管理服务器等基础设施，只需编写代码并上传。函数计算会为自动准备好计算资源，以弹性、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能，确保系统的稳定运行。

相比传统的应用服务器保持运行状态并对外提供服务的方式，函数计算最大的区别是按需拉起计算资源对任务进行处理，在任务完成以后自动的回收计算资源，这是一种真正符合Serverless理念的方案，能最大化的提升资源利用率，减少系统系统维护工作量和使用成本。因为不需要预先申请计算资源，使用者完全不需要考虑容量评估和弹性伸缩的问题，只需要根据资源的实际使用量来进行付费。

下图展示了函数计算的工作方式：

对于使用者而言，把实现关键业务逻辑的代码上传到函数计算平台，就能以事件驱动的方式触发函数执行。函数计算已经支持各种主流的编程语言，对于即有的代码，可以通过几个非常简单的步骤部署到函数计算。函数支持的所有开发语言请参考开发语言列表。

每一次计算资源的分配，都基于事件的触发，一个事件往往对应着业务上的一个任务。函数计算支持多种多样的触发器，比如HTTP触发器的事件源就是HTTP请求，函数计算接收到一次HTTP请求后，会按照预设的规格，分配相应的计算资源来处理这个HTTP请求，请求处理完成之后，函数计算会根据用户的设置决定是否立即回收这一次拉起的计算资源。而OSS触发器，能够监控发生在对象存储OSS上的各种事件，当有用户上传新文件或者对文件进行修改的时候，自动触发函数执行，这种方式就刚好适合视频处理的业务场景。更多支持的函数触发器请参考触发器列表。

在计算资源的调度上，函数计算进行了大量优化，面对用户请求的突增，可以在毫秒级拉起大量的计算资源来并行工作，确保用户体验。

通过函数计算进行视频处理

基于函数计算的特性，搭建一套视频处理系统就非常简单，只需要配置一个OSS触发器，并将视频处理的核心代码上传到函数计算，就大功告成：

通过这套方案，使用者不再需要考虑资源管理、负载均衡、系统高可用、弹性伸缩、系统监控等一系列复杂的问题，函数计算平台会按最优的方式根据用户的上传行为调度计算资源，低成本高效率的完成视频处理任务。具体的操作步骤和代码实现可以参考视频处理Python实现Demo，在这个Demo中，演示了如何基于函数计算将用户上传的视频统一转为640 * 480分辨率的mp4格式视频。

代码开发

每一个创建好的函数都会对应一个指定的入口，函数计算会从这个函数入口开始执行，类似于本地开发中的Main()函数。以Python语言为列，一个简单的入口函数如下：

def handler(event, context):
    return 'hello world'

当有事件触发的时候，就会从入口函数开始执行，其中event参数携带了事件源相关的信息，比如在视频处理场景中，event参数携带了上传到OSS的Bucket以及文件名等信息。而context参数携带了函数的运行信息，包括函数名、超时时间、访问凭证等。通过这些信息，就能让执行代码完成预定义的各种操作。

函数计算支持各种主流的编程语言，在这个编程语言当中，Node.js和Python等脚本型语言含了丰富的类库，开发效率很高，而且运算实例启动的速度很快，能够支持对延迟特别敏感的任务，是函数计算最匹配的语言。Java和Go等语言不能像脚本型语言一样直接上传代码就能创建一个函数，需要预先进行编译，使用起来会稍微复杂一些，但配合函数计算提供的Funcraft等工具，也可以大幅度提升开发和部署的效率。不管使用哪种开发语言，都建议使用者下载官方提供的Funcraft工具，更轻松进行开发、构建、部署操作，请参考Funcraft。

像Java这样的语言，在虚拟机启动的时候需要加载比较多的类库，不能够像实现运算实例毫秒级启动并进入执行状态，不能直接使用在一些对于延迟特别敏感的业务场景。但配合函数计算提供的预留实例以及单实例多并发新功能，能够消除冷启动对业务的影响，并降低等待下游服务响应的影响，让函数计算上运行的Java语言也能实现API网关等对延时要求特别高业务场景。请参考预留实例和单实例多并发。

Serverless工作流

通过前面介绍的方案，可以轻松完成对短视频的各种定制化处理。但每一个函数计算实例，在资源规格上和总运行时长都不是无限的，目前函数计算实例可以拥有3G的内存资源和10分钟的执行时间，这也就说明，当一个视频处理任务需要占用3G以上的系统内存，或者总执行时长超过10分钟的情况下，处理任务是会失败的。

在5G时代，超大视频课件是非常普遍的需求，如何通过函数计算处理这样的大视频呢？这个时候就要出动另一个武器---Serverless工作流，来配合函数计算一起完成这个任务。

Serverless 工作流是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序、选择、并行等方式来编排分布式任务，Serverless 工作流会按照设定好的步骤可靠地协调任务执行，跟踪每个步骤的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。Serverless 工作流通过提供日志记录和审计来监视工作流的执行，方便您轻松地诊断和调试应用。

您可以使用 Serverless 工作流编排一系列的函数资源，同时定义流程中每一步的输入和输出，使用内置控制步骤编排复杂逻辑、发起并行执行、管理超时或终止流程。另外通过控制台能够使用图形界面显示出执行任务状态和执行顺序，同时控制台会显示每个步骤的实时状态，并提供每次执行的详细历史记录。通过Serverless工作流 + 函数计算的组合，我们可以突破时间和空间的限制，对任意大小的视频文件进行复杂的处理。

大视频处理

简单来讲，处理一个大视频的基本思路是：

（1）将视频先进行切片处理，把每一个分片的大小控制在合理的大小，以便单个函数计算实例可以对其进行快速处理。

（2）拉起多个函数计算实例对每一个分片进行并行处理。

（3）对处理结果进行合并。

通过Serverless工作流 + 函数计算进行视频处理的流程如下：

通过Serverless工作流提供的可视界面，我们能在工作流执行的过程当中，方便的查看到每一个步骤运行的信息，并配合自定义的Dashboard实现对整套视频处理系统的全面监控：

总结

基于函数计算和Serverless工作流的弹性高可用视频处理架构，充分体现了云原生时代Serverless化思想，以事件驱动的形式触发函数执行，真实计算资源真正意义上的按需使用。

对于使用而言，这套方案在保证业务灵活度的同时，可以显著降低维护成本与资源成本，并大幅度的缩短项目交付时间。

在线教育领域对于视频处理的需求量非常大，而且对于处理速度、并发吞吐量、资源利用率等方面都有极高的要求，函数计算 + Serverless工作流方案组合帮助用户轻松建设弹性高可用的视频处理架构，是实现这些复杂需求的最优解。随着云原生的不断发展，Serverless相关技术还将深入更多的业务场景，有未来有无限可能！

事实上，基于服务器的云服务并不是云时代的终态。

试想一下，如果服务器的概念被进一步抽象，那么与服务器有关的维护工作都会变成由云来承担。这就是我们常说的Serverless。过去十年，云正在逐步向 Serverless 演进。阿里云最初发布的 ECS 是服务器抽象，随着云原生技术的发展，Docker 容器让应用运行变得简单，Kubernetes 让集群运维变得简单。

2016 年，阿里云发布的函数计算提供了函数级抽象，2019 年发布的 SAE 提供了应用级抽象，这些产品都抹去了服务器的概念，让用云方式得到极大的简化，并逐渐成为趋势。Serverless 已经不仅仅只有函数一种形态，它应该有不同的抽象级别。

阿里云有4种不同的 Serverless 产品，分别提供了容器实例、容器编排、应用、函数的抽象。抽象级别低的产品，客户会拥有更大的管理灵活度；抽象级别高的产品，由云承担的工作会越多，客户的研发和运维的效率也会越高。

这些 Serverless 产品可以给客户、给开发者带来什么样的价值呢？

Serverless有三大核心价值：

一是快速的交付：Serverless 通过进行大量的端对端整合以及云服务之间的集成，为应用开发提供了最大化的便利性，让开发者无需关注底层的 IaaS 资源，而更专注于业务逻辑开发，聚焦于业务创新，大大缩短业务的上市时间。

二是极致的弹性：在 Serverless 之前，一旦遇到突发流量，可能会直接导致各种超时异常，甚至是系统崩溃的问题。即使有限流保护以及提前扩容等手段，依然会出现评估不准的情况，进而引发灾难性的后果。有了 Serverless 之后，由于具备毫秒级的弹性能力，应对突发流量会变得更加从容。

三是更低的成本：就跟生活中用水电煤一样，我们只为实际消耗的资源买单，而无需为闲置的资源付费。Serverless 提供的端到端的整合能力，极大地降低运维的成本与压力，使 NoOps 成为可能。

基于快速交付、智能弹性、更低成本的三大核心价值，Serverless 被认为是云时代的全新计算范式，引领云在下一个十年乘风破浪。 那么下一个十年的 Serverless 将会有什么趋势呢？

第一，标准开放。通过支持开源的工具链和研发框架，Serverless 能够在多云环境下使用，无厂商锁定，免除客户后顾之忧。

第二，云原生结合。与业界认为容器和 Serverless 有对立关系不同，阿里云 Serverless 将借助容器出色的可移植性和灵活性，实现应用交付模式统一；通过复用云原生生态，Serverless 在存储、网络、安全、可观测等方面更加标准、强大。

第三，事件驱动。通过采用统一的事件标准，如 CloudEvent来建立云上的事件枢纽，让 Serverless 开发集成云服务、云边端应用更简单。

第四，解锁更多业务类型。Serverless 早已不再局限在代码片段、短任务、简单逻辑，长时间运行、大内存的任务，有状态的应用，以及 GPU/TPU 的异构计算任务都会在 Serverless 产品上得到支持。

第五，更低成本。在使用成本方面，采用 Serverless 产品的 TCO 会比基于服务器自建更低，一方面是引入预付费等计费模式，比按量节省 30% 以上；另一方面，随着 Serverless 不断演进，更大的资源池、更高的资源利用率，成本会进一步压低。在迁移成本方面，可以通过选择不同形态的 Serverless 产品，采用迁移工具，甚至一行代码不改，存量应用就能迁上 Serverless，享受 Serverless 红利。

阿里巴巴的 Serverless 实践在业内处于领先地位，不仅淘宝、支付宝、钉钉、闲鱼等已经将 Serverless 应用于生产，Serverless 产品更为新浪微博、石墨文档、跟谁学、Timing 等各行各业的企业提供服务，助力企业快速数字化。而能够做到这些，离不开阿里云在 Serverless 战略上的坚持与技术投入。

Serverless如何开启云的下一个十年，闲鱼是如何布局Serverless？一个没有服务器的世界是什么样子的？所有关于Serverless的热点话题，我们将在9月18日13:00 云栖大会「Serverless，引领云的下一个十年」全面揭秘！

扫码或点击预约直播，获取Serverless 实践与趋势解读。

容器镜像已经成为了分布式应用交付的标准，Kubernetes已经成为了分布式资源调度的标准：向下封装资源，向上支撑应用，已经成为了云应用操作系统，帮助应用以一致的方式运行在公共云、边缘计算和专有云环境中。在Kubernetes之上，也浮现出服务网格等新技术，进一步简化分布式应用架构开发和运维。

阿里云提供了经典的云原生容器产品，包括：

• Kubernetes服务 ACK，提供云端最佳容器运行环境
• 镜像服务 ACR，管理各种云原生应用资产
• 托管服务网格 ASM，加速新一代云原生应用架构落地

容器已经无处不在了。越来越多的应用，通过容器方式进行管理、交付，从Web应用、数据库、消息等中间件，再到数据化、智能化应用。

基于容器技术构建的新架构，会催生新的应用业务价值。其中，云原生 AI 是非常重要的应用场景，快速搭建 AI 环境，高效利用底层资源，无缝配合深度学习的全生命周期。好未来的AI中台基于容器服务搭建， 不仅帮助AI服务应对各种资源的急剧增长，而且解决了5个9的SLA需求。好未来AI中台技术负责人刘东东将会在18日的分享中详细讲述更多技术落地细节。

作为容器服务的提供者，容器技术会继续发展，被应用于“新的计算形态”、“新的应用负载”和“新的物理边界”。云原生技术理念使企业用户及开发者只需要关注应用开发，无需关注基础设施及基础服务。

因此除了上述的三款经典产品，阿里云还推出了 Serverless容器服务（ASK）和边缘容器服务（ACK@Edge）两款产品。

Serverless容器服务（ASK）遵循Serverless 理念，将应用服务资源化并以 API 接口的方式提供出来，使用者只需从客户端发起调用请求即可，更重要的是，pay as you go 能够真正为用户节省成本。18日的分论坛演讲中，微博架构师胡春林先生将分享微博如何基于Serverless容器应对突发热点。

此外，容器最被熟知的基础环境是数据中心，在业务流量高峰与低谷之时，凭借容器极致弹性可以实现应用与资源伸缩，有效地保证高利用率与高性价比。随着 5G 和物联网时代的到来，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求。将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，将是云计算的重要发展趋势。以 Kubernetes 为基础的云原生技术，在任何基础设施上提供与云一致的功能和体验，实现云 - 边 - 端一体化的应用分发， 支持不同系统架构和网络状况下，应用的分发和生命周期管理，并且针对边缘及设备进行如访问协议、同步机制、安全机制的种种优化。

容器可以适用于多种基础环境，比如数据中心、边缘云、和多云 / 混合云，使得开发者关注回归到应用本身。今年，阿里云容器服务也将迎来一系列新产品特性，并在9月18日「企业云原生创新与实践」分论坛上重磅发布。我们提前揭秘其中一部分新产品。

第一个是容器服务ACK Pro版。它是针对金融、大型互联网、政企客户对安全、稳定、规模的更高需求，推出的高度优化的K8s运行环境。它具备几个关键优势：

（1）基于神龙架构，软硬一体化优化设计，提供卓越性能；
（2）提供高效调度能力，可以有效优化计算成本；
（3）为企业提供全面安全防护，国内首批通过可信云容器安全先进性认证。

ACK Pro正式商用后将提供可赔付的SLA。

第二个是基于ACK的云原生AI加速器。Gartner预测到2023年，70% AI应用构建在容器和Serverless环境中。在过往的几年，阿里云帮助众多企业和阿里云计算平台等内部团队基于云原生技术构建AI平台。通过容器服务Kubernetes，可以对多种异构计算资源进行统一管理，提升资源利用率，降低计算成本。通过GPU共享等技术可以实现资源利用率2~4倍提升。

通过K8s调度优化和分布式缓存等技术，可以提升AI计算效率。在模型训练场景，计算效率提升20%。此外，通过对AI任务提供统一流程管理，构建可重现、可移植、可组装的的AI流水线，AI工程效率可以提升50%。在此基础上，容器服务ACK推出云原生AI加速器，将把异构计算资源管理、调度优化，AI任务流水线，和上层AI算法引擎等全栈优化能力有机整合在一起。 它面向企业AI平台建设者，可以让客户自由组合各层能力，构建符合自己需求的AI平台， 加速算力的释放。

以好未来为例，它是K12在线学习的领头羊，基于ACK的云原生AI加速器，提供了上百个AI服务。峰值请求量达每天8000万次。通过GPU共享调度，节省了近50%的资源成本。

第三个是容器镜像服务企业版 ACR EE。它为众多跨国企业、互联网、在线教育、游戏等公司提供企业级云原生应用管理和分发能力。ACR EE支持容器镜像和所有符合OCI标准的应用制品管理，比如Helm Chart。以欢聚时代为例，它作为互联网出海的代表企业，其容器化应用需要在全球多地域、多 IDC 部署。使用 ACR EE，全球应用分发效率提高 85% ，成本仅为自建 1/3。

第四个是阿里云托管服务网格ASM。Gartner预测，81%的企业将采用多云/混合云战略，混合云架构已经成为企业上云的新常态。在云原生时代，以Kubernetes为代表的技术屏蔽了基础设施的差异性，可以帮助企业在混合云环境下，进行统一资源调度和应用生命周期管理。

阿里云托管服务网格ASM，是业内首个全托管，与Istio全兼容的服务网格产品。 服务网格的控制平面的组件托管在阿里云侧，用户集群只包含数据平面组件。这个架构解耦了服务网格与K8s集群的生命周期，简化升级和问题诊断；提升了系统的可伸缩性和稳定性。此外ASM全面整合阿里云可观测性、安全等能力，大大简化了服务网格生产环境的运维管理。

9月，ASM正式商用，阿里云容器服务负责人易立将在9月18日云栖大会「企业云原生创新与实践」分论坛详细介绍ASM的新特性。

去年阿里云发布边缘容器服务ACK@Edge。帮助企业将云计算能力延展到边缘，降低应用网络延时，简化海量设备的分布式管理。短短一年，已经广泛应用于音视频直播、云游戏、工业互联网、交通、物流、能源、城市大脑等应用场景中。

这一次，ACK@Edge 与阿里云智能接入网关服务 SAG 共同推出多链路、云边协同的网络方案，具备安全加密、就近接入、即插即用等多种能力，使能边缘资源、业务一站式接入上云。在边缘计算领域，阿里巴巴云原生边缘计算平台 OpenYurt 在9月9日正式成为 CNCF 沙箱级别项目（Sandbox Level Project），标志着 OpenYurt 在边缘计算场景中构建云原生基础设施的能力受到了行业的广泛认可。

此外，在本次云栖大会上，阿里云原生还将发布沙箱容器 2.0等重磅产品，通过核心技术解读与案例分享，帮助企业获得更加敏捷、高效的容器实现。