您当前位置：首页 > php框架 > 框架设计 > 互联网产品灰度发布

互联网产品灰度发布

来源：程序员人生发布时间：2016-06-08 13:26:37 阅读次数：13179次

互联网产品灰度发布

关于2016年5月15日，DevOps成都站｜架构与运维峰会活动总结

1. 前言 2

2. 灰度发布定义 5

3. 灰度发布作用 5

4. 灰度发布步骤 5

5. 灰度发布测试方法 6

6. 灰度发布引擎 6

7. 灰度发布常见问题 8

7.1. 以偏概全 8

7.1.1. 问题特点： 8

7.1.2. 解决方案： 8

7.2. 知识的诅咒 9

7.2.1. 问题特点： 9

7.2.2. 解决方案： 9

7.3. 发布没有回头路可走 9

7.3.1. 问题特点： 9

7.3.2. 解决方案： 9

7.4. 用户参与度不够 10

7.4.1. 问题特点： 10

7.4.2. 解决方案： 10

8. 让产品具有灰度发布能力 10

8.1. 灰度机制的7个维度 10

8.1.1. 需求度 10

8.1.2. 速度 10

8.1.3. 灵活度 10

8.1.4. 冗余度 11

8.1.5. 开放协作度 11

8.1.6. 进化度 11

8.1.7. 创新度 11

8.2. 灰度发布的策略要素 11

8.2.1. 易于发布到云平台 11

8.2.2. 设置用户标识策略 12

8.2.3. 目标用户选取策略 12

8.2.4. 提供数据反馈入口 12

8.2.5. 新版本回滚策略 12

8.2.6. 新版本公关运营支持 13

8.3. 灰度发布的方案 13

8.3.1. 方案1：代码逻辑控制 13

8.3.2. 方案2：Alibaba预发机制 14

8.3.3. 方案3：SET部署 14

8.3.3.1. 依照业务隔离部署 14

8.3.3.2. 依照用户隔离部署 15

8.3.4. 方案4：动态路由 16

9. 采取灰度发布的案例 16

9.1. 谷歌Gmail Labs 16

9.2. 腾讯QZone 17

9.3. 微信wechat 17

9.4. Ucloud高可用架构实践 20

10. 参考资料 26

1. 前言

互联网产品有1个特点，就是不停的升级，升级，再升级。1般采取敏捷开发的团队，基本上保持每周1次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统down机的风险.....为了不这些风险，很多产品都采取了灰度发布的策略，其主要思想就是把影响集中到1个点，然后再发散到1个面，出现意外情况后很容易就回退。

很长时间，我们都1直在改进搜索引擎的排序算法，尽可能让最好的商品出现在搜索结果的第1屏。我们尝试了很多种算法，不断调剂各个排序因子所占的比重。但是我们没法确信我们的排序结果能满足所有用户的需求。所以我们采取了灰度发布，选取几个1级商品类目，在其中利用不同的排序算法，比如在女装类目中，我们把卖家信誉所占的比率调剂到60%，在珠宝类目中，我们把销售量所占的比率调剂到60%.. 然后发布出去，搜集用户反馈，终究选择1种大部份人认为好的算法。

在传统软件产品发布进程中（例如微软的Windows 7的发布进程中），1般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，触及的用户数也是逐渐放量的进程。

在互联网产品的发布进程中也较多采取此种发布方式：产品的发布进程不是一挥而就，而是逐渐扩大使用用户的范围，从公司内部用户->虔诚度较高的种子用户->更大范围的活跃用户->所有用户。在此进程中，产品团队根据用户的反馈及时完善产品相干功能。此种发布方式，依照中国特点的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

关于“灰度发布”叫法的来源无从考察。只不过依照中国传统哲学的说法来看，很符合中国人中庸的思惟模式：自然界所有的事物总是以对称、互补、和谐的情势存在，例如黑与白、阴与阳、正与负、福与祸。在2元对峙的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中间色——灰色。因而出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐任正非：管理的灰度），灰色收入，灰色地带等等。因此对灰度发布实际上就是从不发布，然后逐步过渡到正式发布的1个进程。

2. 灰度发布定义

灰度发布是指在黑与白之间，能够平滑过渡的1种发布方式。AB test就是1种灰度发布方式，让1部份用户继续用A，1部份用户开始用B，如果用户对B没有甚么反对意见，那末逐渐扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就能够发现、调剂问题，以保证其影响度。

3. 灰度发布作用

a.尽早取得用户的意见反馈，完善产品功能，提升产品质量

b.让用户参与产品测试，加强与用户互动

c.下降产品升级所影响的用户范围

d.规避1定的发布风险

e.避免停服发布给用户带来不便

f.具有容灾能力

4. 灰度发布步骤

1）、定义目标

2）、选定策略：包括用户范围、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

3）、挑选用户：包括用户特点、用户数量、用户经常使用功能、用户范围等

4）、部署系统：部署新系统、部署用户行动分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

5）、发布总结：用户行动分析报告、用户问卷调查、社会化媒体意见搜集、构成产品功能改进列表

6）、产品完善

7）、新1轮灰度发布或完全发布

5. 灰度发布测试方法

灰度发布于互联网公司经常使用A/B测试似乎比较类似，老外似乎并没有所谓的灰度发布的概念。依照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的1种特例。只不过为了术语上不至于同等弄混淆，谈谈自己理解的二者的差异。

灰度发布是对某1产品的发布逐渐扩大使用群体范围，也叫灰度放量

A/B测试重点是在几种方案当选择最优方案

关于A/B测试可以参考这篇文章：A/B测试终极指南

6. 灰度发布引擎

对1般的小系统其实不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则便可。但对大型的互联网利用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

下面是1个灰度发布的架构示意图：

7. 灰度发布常见问题

7.1. 以偏概全

7.1.1. 问题特点：

a选择的样本不具有代表性；

b样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能

7.1.2. 解决方案：

样本选择要多样化，样本的组合涵盖大部份核心功能

7.2. 知识的诅咒

“知识的诅咒”的说法来自《粘住》中实验，具体可以自己搜索1下。我们自己对自己开发的产品极其熟习，因而乎想固然认为用户也应当能够理解产品的设计思路、产品的功能使用。

7.2.1. 问题特点：

a结果没有量化手段；

b只依赖于用户问卷调查；

c没有web analytics系统；

d运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

e对结果分析，只选择对发布有益的信息，对其他视而不见

7.2.2. 解决方案：

a产品设计斟酌产品量化指标

b结果分析根据量化指标而不是感觉

7.3. 发布没有回头路可走

7.3.1. 问题特点：

a新旧系统用户使用习惯差异太大，没有兼容原有功能

b新旧系统由于功能差异太大，没法并行运行，只能强迫升级

c新系统只是实现了旧系统部份功能，用户要完全使用所有功能，要在在新旧系统切换

d新旧系统数据库数据结构差异太大，没法并行运行

7.3.2. 解决方案：

前期产品策划重点斟酌这些问题，包括：回滚方案、新旧系统兼容方案、用户体验的1致性、用户使用习惯的延续性、新旧系统数据模型兼容性

7.4. 用户参与度不够

7.4.1. 问题特点：

a期望用户自己去发掘所有功能。对1个产品，大部份用户常常只使用部份功能，用户大部份也很怠惰，不会主动去发掘产品功能

b互动渠道单1

c堕入“知识的诅咒”，不尊重参与用户意见

7.4.2. 解决方案：

a善待吃螃蟹的样本用户，包括给予参与测试的用户小嘉奖（例如MS给参与Win7测试用户正版License）、给用户冠以title

b通过邮件、论坛、社区、Blog、Twitter等新媒体与用户构成互动

c提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

8. 让产品具有灰度发布能力

8.1. 灰度机制的7个维度

8.1.1. 需求度

用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度;

8.1.2. 速度

快速实现单点突破，角度、锐度特别是速度，是产品在生态中存在发展的根本;

8.1.3. 灵活度

敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要;

8.1.4. 冗余度

容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功;

8.1.5. 开放协作度

最大程度地扩大协作，互联网很多恶性竞争都可以转向协作型创新;

8.1.6. 进化度

构建生物型组织，让企业组织本身在无控进程中具有自进化、自组织能力;

8.1.7. 创新度

创新并不是刻意为之，而是充满可能性、多样性的生物型组织的必定产物。

8.2. 灰度发布的策略要素

8.2.1. 易于发布到云平台

1般采取灰度发布都是具有自主产品的平台模式发布，而不是在客户服务器端进行发布，具有自主研发产品和有1定硬件部署能力的企业可以斟酌灰度发布。

灰度发布1般是基于云的需要，如负载均衡，用户隔离等机制。如大型的电商网站等都是采取的散布式部署方式，利用负载均衡实现服务器分发，将用户访问分配到不同的地区服务器访问，确保用户访问效力，提升用户体验。

之所以强调易于发布，就是公司要具有自己可操作的服务器装备（云服务装备），这样可以实现在用户不知情的情况下实现灰度发布。即，在用户无感知的情况下实现最优配置的测试部署，提升产品质量，实现产品快速迭代——频繁发布，实现具成心义的‘实时发布’策略。

注：需要开通云服务模式（有1定硬件和经济实力的公司可以斟酌）。

8.2.2. 设置用户标识策略

用于辨别用户，辅助数据统计，保证灰度发布进程中用户体验的联贯性（避免用户在新旧版本中跳变，匿名Web利用比较容易有这个问题）。匿名Web利用可采取IP、Cookie等，需登录的利用可直接采取利用的帐号体系。

8.2.3. 目标用户选取策略

即选取哪些用户先行体验新版本，是强迫升级还是让用户自主选择等。可斟酌的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户本身特点（性别、年龄、虔诚度等）。对细微修改（如文案、少许控件位置调剂）可直接强迫升级，对类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。

对客户端利用，可以斟酌类似Chrome的多channel升级策略，让用户自主选择采取stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承当试用风险。

8.2.4. 提供数据反馈入口

用户数据反馈：在得到用户允许的条件下，搜集用户的使用新版本利用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对照，决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。

8.2.5. 新版本回滚策略

当新版本灰度发布表现不佳时，应回滚至旧版本。对纯洁的Web利用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对客户端利用，如果期待用户自行卸载新版本另行安装旧版本，本钱和流失率都太高。可以斟酌通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。

对移动客户端，新版本发布本钱较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太肯定移动客户端产品如何处理灰度发布及回滚。但尽可能将客户端打造成Web App，会更有益于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已不允许在Appstore上发布这类利用了？）

8.2.6. 新版本公关运营支持

对改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对照通过隐式数据反馈得到的结论后，综合斟酌应对策略。

8.3. 灰度发布的方案

灰度发布1般有3种方式 nginx+lua，nginx根据cookie分流，nginx 根据权重来分配：
nginx+lua根据来访者ip地址辨别，由于公司出口是1个ip地址，会出现访问网站要末都是老版，要末都是新版，采取这类方式其实不合适nginx 根据权重来分配，实现很简单，也能够尝试nginx根据cookie分流，灰度发布基于用户才更公道。

Nginx+lua配置可以参考以下文章进行实践：

利用nginx+lua+memcache实现灰度发布

Nginx+Lua+Redis实例

nginx灰度方案---基于ip或基于cookies

8.3.1. 方案1：代码逻辑控制

实现：

在代码中埋开关，做if-else判断，对需要灰度的机器，设置开关为on，否则为off。每次版本发布都是有两个版本。

优点

· 快速回滚，不需要重新发布和重启系统。

缺点

· 对代码有倾入性。

· 分支逻辑，带来复杂性。

这类方式笔者曾利用过，就是在阿里的时候把商品的数据库从Oracle切换到MySql，使用了1个状态变量进行控制。从而打到平滑迁移的效果。

8.3.2. 方案2：Alibaba预发机制

其实这个不是真正意义上的灰度。由于这个预先发布机器是内部IP，没有对外服务的。需要绑定域名进行验证。但是数据是完全的线上。所以本质上是灰度某些特定用户（可以访问灰度机器的用户，内部测试用户）的1种简单做法。其实API这边也有类似的做法，就是我们的Gamma环境，而且我们还提供了 Gamma机器的域名，方便外部合作用户配合测试。

优点

· 简单

缺点

· 浪费1台机器（这个可以预先发布完成以后投入正式环境，预发布的时候从nginx摘除，不过需要运维支持。）

· 不够灵活

· 只能针对接入层机器，IDL服务灰度需要另外斟酌。

8.3.3. 方案3：SET部署

8.3.3.1. 依照业务隔离部署

比如现在API Container的做法，部署的粒度可以到API级别，前端根据nginx进行转发。比如：

· 微购物 API Container: api.weigou.qq.com

· 拍拍 API Container：api.paipai.com

· 易迅 API Container: api.yixun.com

· 网购 API Container：api.buy.qq.com

上面是大业务级别的隔离部署。还可以进1步细化到模块级别，比如虚拟服务电商的API，是挂在拍拍下面的1个子业务模块，但是由于他们接入微信之后，访问量大增，为了不影响拍拍其他业务，也为了不受其他业务影响，API这里是给他们单独部署了两台机器，nginx配置1下就能够将针对虚拟的 API访问引流过来了：

虚拟API Container：http://api.paipai.com/v2/virbiz

这样，我们在发布1个版本的时候，可以先选择业务量最小的易迅进行发布，视察没有问题再全量其他平台。

8.3.3.2. 依照用户隔离部署

这个对开放平台来讲不是很合适，不过对SNS这类利用场景就很适合了。比如QQ系统，依照用户号码段分为若干个set，每一个set包括连续1亿个号码的用户。假定现在最新的QQ号码接近10亿，则总共有10个set（Set 1到Set 10）。这样每次可以选择其中1个SET进行发布，而且高位QQ常常是否是很重要的用户，所以会先发布SET10。

优点

· 隔离部署，各个业务线影响最小。自动支持灰度发布。

缺点

· 灰度的粒度取决于隔离部署的粒度，1般会偏大。

· 相对集中部署比较浪费机器。

· 各个业务线版本可能不1致，不利于统1管理。

· 有1定的实现和部署本钱

8.3.4. 方案4：动态路由

采取1个可以灵活配置的灰度策略，影响Load Balance的行动，让其根据灰度策略，返回灰度服务的IP和端口。

合适与后台IDL的服务灰度。

优点

· 灵活，可控。

缺点

· 现在的配置中心和L5本身没有斟酌指定路由策略，且不具有扩大性，需要在其外边开发。

· API的元数据来源比较分散，目前 API和IDL元数据，API等级和频率限制散布在不同的数据源，现在需要增加1个灰度路由数据源。

9. 采取灰度发布的案例

9.1. 谷歌Gmail Labs

Gmail Labs是1个新特性橱窗，用户可以自己选择1些未正式发布的新特性进行体验，不喜欢可以关闭，在这个进程中，吃了螃蟹，也当了Google的小白鼠。

这个做法比传统的灰度要高明很多，更加尊重用户：

1、它没有强加用户，用户是不是愿意当小白鼠完全自愿

2、新特性不是打包在1起的1个大版本，可以选择某几个喜欢的螃蟹尝尝

3、螃蟹不好吃可以扔掉，不用硬吃进肚子里引发肠胃炎

固然这些好处也是有代价的：

1、要开发1个labs平台实现新特性上架、独立尝试的功能，这可能要改动Gmail的前后台架构

2、新特性要依照1定规范来写，才能发布到这个平台上，可能会增加1些工作量

3、小白鼠用户增多以后，对系统的压力可能会有1定提升，由于每位用户调用的界面都不1样了

既然Gmail Labs能够顺利发布，那末说明对Google来讲，以上这些问题都不算问题。另外，现在展现的新特性，都注明了开发者的名字，那末，Gmail Labs可能会开放这个平台让外部开发者也能提交特性？这倒是很open的1种开发模式，非常合适Google的web app产品线。

9.2. 腾讯QZone

QZone是另外1个采取灰度发布的例子。大家都知道，QZone的改进是巨大的，从之前慢吞吞的老爷爷变成了1个充满青春活力的小伙子。其中经历了大小无数次的发布，他们的发布也都是采取了灰度发布的策略，用户数据的升级其实不是大面积的1次性升级，而是通过1个用户升级标志服务器，如果用户数据没有升级，后台会把此用户的数据逐渐迁移到新版本上，然后将升级标志位置1，升级进程中，用户依然可以访问旧的数据，升级完成后的访问都将转发给新的版本。

QQ的很多产品发布都采取灰度发布，有些是抽取部份QQ号段升级成新系统，然后根据用户反馈再大范围升级。

9.3. 微信wechat

灰度、灰度、再灰度

在变更后的部署方式上，微信在1些规则会限定不能1次把所有的逻辑变更上去，每次变更1小点视察到每个环节没有问题的时候，才能布局到全网上去。微信后台每天可以支持超过20个后台变更，在业界来讲，通常做到5个已是比较快了，但是微信可以做到快4倍。

腾讯内部的上线系统

而所谓灰度发布，是指在黑与白之间，能够平滑过渡的1种发布方式。AB test就是1种灰度发布方式，让1部用户继续用A，1部份用户开始用B，如果用户对B没有甚么反对意见，那末逐渐扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就能够发现、调剂问题，以保证其影响度。(在腾讯，灰度发布是最常采取的发布方式之1)

孙子兵法：古之所谓善战者，胜于易胜者也

常识上，解决1个复杂问题的时候，会用高明的技能解决复杂的问题，这个不是微信团队的目标，他们寻求的要做到让所有问题很自然和简单的方式解决掉。在周颢看来，微信架构的技术复杂点在4个要点：协议、容灾、轻重、监控。

微信架构

· 协议。手机终端跟后台服务器之间的交互协议，这个协议的设计是全部系统的骨架，在这1点做好设计可使得系统的复杂度大大下降。

· 容灾。当系统出现了若干服务器或若干支架(宕机的时候)，依然需要让系统尽量的提供正常的服务。

· 轻重。如何在系统架构中散布功能，在哪个点实现哪个功能，代表系统中间的功能配置。

· 监控。为系统提供1个智能仪表盘。

在协议设计上，移动互联网和常规互联网有很大的区分。首先有CMWAP和CMNET的不同，在中国现在有相当多的手机用户使用WMWAP连接，还有就是在线和离线的概念，当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中，不管在线还是离线系统表现都应当是1致的。还有1个是连接不稳定的问题，由于手机信号强弱的变化，当时信号很好，5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为协议设计带来较大困难。另外就是资费敏感的问题，由于移动互联网是依照流量计费的，这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延迟的问题。

对此，业界标准的解决方案：Messaging And Presence Protocol：1)XMPP;2)SIP/SIMPLE。它的优点是简单，大量开源实现。而缺点一样明显：1)流量大：状态初始化；2)消息不可靠。

微信在系统中做了特殊设计，叫SYNC协议，是参考Activesyec来实现的。特点首先是基于状态同步的协议，假定说收发消息本身是状态同步的进程，假定终端和服务器状态已被迟了，在服务器端收到最新的消息，当客户端、终端向服务器对接的时候，收取消息的过程实际上可以简单的归纳为状态同步的进程，收消息和收取你好友状态更新都是相同的。在这样的模式之下，我们会或许会把交互的模式统1化，只需要推送1个消息到达的通知就能够了，终端收到这个通知就来做消息的同步。在这样的简化模式之下，安卓和塞班都可以得到统1。这样的系统本身的实现是更加复杂的，但是取得很多额外的好处。

让剩下系统实现的部份更加简单，简化了交互模式，状态同步可以通过状态同步的差值取得最小的数据变更，通过增量的传输得到最小的数据传输量。通过这样的协议设计，微信可以确保消息是稳定到达的，而且是按序到达。援用1句俗话：比它炫的没它简单，比它简单的没它快，没谁比他更快，哪怕在GPRS下，微信也能把进度条轻易推到底。

9.4. Ucloud高可用架构实践

DevOps成都站｜架构与运维峰会活动总结地址：

http://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=2656298704&idx=2&sn=68d5d42a9c26640a21eebd3253ca81c3&scene=1&srcid=0519IBq6Q2k77kYAQmXuofuV&from=groupmessage&isappinstalled=0#wechat_redirect

此处主要截取账户计费系统架构演进进程的6个阶段进行整理。

服务架构的演进进程

UCloud服务架构的演进主要经历了以下6个阶段：

a.单体模式；

b.具有灰度发布能力；

c.前后端分离；

d.服务化改造；

e.按SET部署；

f.分机房按SET部署，按SET进行跨机房热备容灾。

1. 单体模式架构上线业务系统

UCloud服务早期上线时的架构主要分3部份：

PHP Web Conosle,负责所有前端展现交互、后台服务间逻辑组装；

平台类服务，账户、计费、监控、名字服务等公共服务；

各业务系统分数据中心后台服务的接入层。

PHP Web Console、业务系统分数据中心的服务、平台类服务组合上线，Web Console 通过Protobuf与所有后端服务进行通讯。

2. 具有灰度发布能力

要解决前面面临的问题，我们首先需要支持Web层灰度发布包括以下的灰度方式：

无用户态特性依照单IP -> IP段(地区) -> 到IP取模逐渐灰度控制影响范围；

有用户态特性依照单内部用户(开发账号) -> 内部测试账号 -> 用户分级逐渐灰度发布控制影响范围。

3. 前后端分离

开发API Gateway 层用来管理后端 API 注册和管理、权限验证管理、流量控制；

开发API层，解决前台交互层，需要整合跨系统逻辑调用问题，前端只专注产品交互和用户体验；

开发统1的单点登陆Token，系统方便前端实现跨域API调用让前端代码可以完全静态化。

在此阶段，完成前端展现可以独立控制发布，完全实现了前后端解耦，API协议保证向前兼容，Web端可以随便重构交互优化前端架构,实现了跨域独立部署,独立的灰度策略相互之间不受影响，极大的提高了前端团队开发效力和稳定性。

4. 服务化改造

对业务端API开发效力优化：

依照业务模块化，所有业务API由后台产品研发部门独立部署发布上线；

抽象通用平台类特性例如：子账号特性，权限体系，计费等特性抽象公共能力让业务端在API中组装。

整体目标：让业务API开发效力提升并单独部署保护，提高产品特性的研发迭代效力并提高稳定性。

5. 按SET部署

基础架构优化终了，各个业务系统单独部署发布，开始对系统进行容量和容灾方面的斟酌，从部份平台类系统开始斟酌按SET部署架构测底解决容量和容灾问题，每一个SET只服务1部份用户，保证遇到物理服务器宕机等故障情况下只影响部份用户或业务。

例如图上所示， SET 1 服务1 ～服务50000000 用户，SET 2 服务50000001 ~ 100000000 的用户，1个SET 出现问题只影响1个部份用户，不同的业务根据本身情况进行SET切分，范围大小也视情况而定，按SET部署后公道的划分方式下不同SET之间数据还可以相互迁移，来平衡弄负载或高容量的SET,极大的提高了可运维性。

6. 分机房部署SET