如何配置智能网络支持服务

1 、简介

什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

如果还是不理解，那么可以举个例子：假如目前有很多人想要给我付钱，但我的服务器除了正在运行支付的服务之外，还有一些其它的服务在运行，比如搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的不少内存与CPU资源，为了能把钱都收下来（钱才是目标），我设计了一个动态开关，把这些不重要的服务直接在最外层拒掉，这样处理后的后端处理收钱的服务就有更多的资源来收钱了（收钱速度更快了），这就是一个简单的服务降级的使用场景。

2 、使用场景

服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。

3 、核心设计

3.1 分布式开关

根据上述需求，我们可以设置一个分布式开关，用于实现服务的降级，然后集中式管理开关配置信息即可。具体方案如下：

服务降级-分布式开关

3.2 自动降级

超时降级 —— 主要配置好超时时间和超时重试次数和机制，并使用异步机制探测恢复情况失败次数降级 —— 主要是一些不稳定的API，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况故障降级 —— 如要调用的远程服务挂掉了（网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常），则可以直接降级限流降级 —— 当触发了限流超额时，可以使用暂时屏蔽的方式来进行短暂的屏蔽当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

3.3 配置中心

微服务降级的配置信息是集中式的管理，然后通过可视化界面进行友好型的操作。配置中心和应用之间需要网络通信，因此可能会因网络闪断或网络重启等因素，导致配置推送信息丢失、重启或网络恢复后不能再接受、变更不及时等等情况，因此服务降级的配置中心需要实现以下几点特性，从而尽可能的保证配置变更即使达到：

服务降级-配置中心

启动主动拉取配置 —— 用于初始化配置（减少第一次定时拉取周期）发布订阅配置 —— 用于实现配置及时变更（可以解决90%左右的配置变更）定时拉取配置 —— 用于解决发布订阅失效或消失丢失的情况（可以解决9%左右的发布订阅失效的消息变更）离线文件缓存配置 —— 用于临时解决重启后连接不上配置中心的问题可编辑式配置文档 —— 用于直接编辑文档的方式来实现配置的定义提供Telnet命令变更配置 —— 用于解决配置中心失效而不能变更配置的常见3.4 处理策略

当触发服务降级后，新的交易再次到达时，我们该如何来处理这些请求呢？从微服务架构全局的视角来看，我们通常有以下是几种常用的降级处理方案：

页面降级 —— 可视化界面禁用点击按钮、调整静态页面延迟服务 —— 如定时任务延迟处理、消息入MQ后延迟处理写降级 —— 直接禁止相关写操作的服务请求读降级 —— 直接禁止相关度的服务请求缓存降级 —— 使用缓存方式来降级部分读频繁的服务接口针对后端代码层面的降级处理策略，则我们通常使用以下几种处理措施进行降级处理：

抛异常返回NULL调用Mock数据调用Fallback处理逻辑4 、高级特性

我们已经为每个服务都做好了一个降级开关，也已经在线上验证通过了，感觉完全没问题了。

场景一：某一天，运营搞了一次活动，突然跑过来说，现在流量已经快涨到上限了，有没有批量降级所有不重要服务的方式？开发一脸懵逼的看着，这又不是操作DB，哪里有批量操作呀。

场景二：某一天，运营又搞事了，说我们等下要搞一个活动，让我们赶紧提前把不重要的服务都降级了，开发又是一脸懵逼，我怎么知道要降级哪些服务呀。

反思：服务降级的功能虽然是实现了，可是没有考虑实施时的体验。服务太多，不知道该降级哪些服务，单个操作降级速度太慢……

4.1 分级降级

当微服务架构发生不同程度的情况时，我们可以根据服务的对比而进行选择式舍弃（即丢车保帅的原则），从而进一步保障核心的服务的正常运作。

如果等线上服务即将发生故障时，才去逐个选择哪些服务该降级、哪些服务不能降级，然而线上有成百上千个服务，则肯定是来不及降级就会被拖垮。同时，在大促或秒杀等活动前才去梳理，也是会有不少的工作量，因此建议在开发期就需要架构师或核心开发人员来提前梳理好，是否能降级的初始评估值，即是否能降级的默认值。

为了便于批量操作微服务架构中服务的降级，我们可以从全局的角度来建立服务重要程度的评估模型，如果有条件的话，建议可以使用 层次分析法（The analytic hierarchy process，简称AHP）的数学建模模型（或其它模型）来进行定性和定量的评估（肯定比架构师直接拍脑袋决定是否降级好很多倍，当然难度和复杂度也会高许多，即你需要一个会数学建模人才），而层次分析法的基本思路是人对一个复杂的决策问题的思维和判断过程大体上是一样的。

以下是个人给出的最终评价模型，可作为服务降级的评价参考模型进行设计：

我们利用数学建模的方式或架构师直接拍脑袋的方式，结合服务能否降级的优先原则，并根据台风预警（都属于风暴预警）的等级进行参考设计，可将微服务架构的所有服务进行故障风暴等级划分为以下四种：

评估模型：

蓝色风暴 —— 表示需要小规模降级非核心服务黄色风暴 —— 表示需要中等规模降级非核心服务橙色风暴 —— 表示需要大规模降级非核心服务红色风暴 —— 表示必须降级所有非核心服务设计说明：

故障严重程度为：蓝色＜黄色＜橙色＜红色建议根据二八原则可以将服务划分为：80%的非核心服务+20%的核心服务以上模型只是整体微服务架构的服务降级评估模型，具体大促或秒杀活动时，建议以具体主题为中心进行建立（不同主题的活动，因其依赖的服务不同，而使用不同的进行降级更为合理）。当然模型可以使用同一个，但其数据需要有所差异。最好能建立一套模型库，然后实施时只需要输入相关服务即可输出最终降级方案，即输出本次大促或秒杀时，当发生蓝色风暴时需要降级的服务清单、当发生黄色风暴时需要降级的服务清单……

4.2 降级权值

微服务架构中有服务权值的概念，主要用于负载时的权重选择，同样服务降级权值也是类似，主要用于服务降级选择时的细粒度优先级抉择。所有的服务直接使用以上简单的四级划分方式进行统一处理，显然粒度太粗，或者说出于同一级的多个服务需要降级时的 降级顺序该如何？甚至我想要人工智能化的 自动降级，又该如何更细粒度的控制？

基于上述的这些AI化的需求，我们可以为每一个服务分配一个降级权值，从而便于更加智能化的实现服务治理。而其评估的数值，同样也可以使用数学模型的方式进行 定性与 定量 的评估出来，也可以架构师根据经验直接拍脑袋来确定。

5 、总结与展望

以上提供了半实际与半理论的服务降级方案，使用者可以根据其公司的实际情况进行适当的选择，而完整的方案，笔者目前也没有发现有实施过的，但可以建议有长远服务治理规划的大厂进行完整方案的研究与实施，会对未来人工智能万物互联的时代有较好的治理价值存在（个人看法）。而小厂出于成本和其发挥的价值的考虑，不建议使用这么复杂的方案，但可以实现分布式开关和简单分级降级的功能特性。

本文主要以服务降级为核心进行更加理想的治理微服务架构，其中建议运用数学领域的适当模型来实现 定性和 定量 的合理分析和治理微服务，为未来 人工智能治理微服务（Artificial Intelligence Governance Micro Service，简称AIGMS）提供方案支持。

为了感谢关注公号纯洁的微笑的读者朋友们，特别向51CTO申请了一批优惠卷每张价值5元，大家可以使用这个优惠卷购买官网的专栏。

推荐大家购买我在 51CTO 开通的如下《微服务技术架构和大数据治理实战》课程，当然也可以购买别的你喜欢的课程。

只要注册了51CTO的账号，并且将信息填到以下表单中即可，一般情况下优惠券会在24小时候之内发放完毕。仅限前50名！

登记地址：https://diaochapai/survey2825434

END

早在去年年底，摩拜单车就宣布与贵州新特电动汽车正式签约，将在共享汽车领域展开合作。据悉，双方将在定制摩拜出行共享汽车、助力电动车，建设智能化电动汽车共享平台等方面展开深度合作。

新特DEV 1共享版

而现在，二者合作成果正式亮相。日前，新特汽车在北京召开新闻发布会，正式推出首款产品DEV1。据悉，新特DEV 1主要分为“DEV 1旗舰版”和“DEV 1共享版”两个版本，前者主要面向C端用户直接销售，后者则为摩拜共享汽车定制款车型。

据介绍，新特DEV 1共享版属于A0级产品，采用四座布局，配备17寸轮毂;搭载新特自主研发的D-OS智能车联网系统，可以提供电桩预约智能充电服务;搭载峰值功率为55kw的永磁同步电机，峰值扭矩170Nm，最高转速9000rpm;使用宁德时代的35KWh电池包，最大续航里程为350km。

新特DEV 1旗舰版

值得一提的是，新特DEV 1拥有6.6kw高性能充电机，在快充模式下，官方宣称可实现快充40分钟续航200km。目前该车已经开始预售，预计首批上线城市为上海、杭州、北京、贵阳、深圳。

文／曾斌

最近由于亚马逊的Echo卖得很火，2015年卖了400万台，2016年卖了800万台，2017年计划销售上1000万台。中国的厂家看到了市场的机会都想做一款类似亚马逊Echo的智能音响，在国内国外上市销售。

作者本人专注wifi音响已经有五年的历史，对WIFI音响的技术比较熟悉，所以最近接待了很多北京上海深圳的大公司的产品经理上门来请教，发现大家对Echo的研发还处在没有研究过的阶段，对Echo这款产品还只是停留在以一款蓝牙音响的认识去理解Echo这款智能语音识别音响。所以，我今天把我的技术开发，资源整合，市场情况，未来发展的积累给大家分享，减少大家的疑惑。

Echo的历史

首先简单介绍一下亚马逊的echo这款产品，这款产品是亚马逊耗费了2000人的研发团队，历时4年打造的产品。在此之前不得不提一提它的前辈——SONOS音响。SONOS音响是美国的一个成立于2002年历时6年研发打造的产品，这家公司的核心技术成员来至于美国一家高科技通讯公司——高通Qualcomm。

6年的技术攻关将WIFI的带宽高，高保真无损传输和解码，多台设备互相（利用wifi宽带宽，将几台音响连接到同一个局域网实现同时播放同一首歌，营造出给无线环绕声的效果）；同时，利用其音乐云服务控制的技术交换和商务合作，SONOS音响的APP集成了美国，中国，欧洲主流的音乐内容服务商资源，比如Pandora,Spotify,QQ music,虾米，多米等丰富的内容资源。

其结果是给公司带来了很高的知名度和丰厚的收益。2005年乔布斯在看到SONOS音响时感叹道“这是音响的未来”，长时间的技术研发和投入（据说研发投入2亿美金）带来了好的收益，单2011年SONOS音响销售额达到近2亿美金。其五款经典产品包括：3款wifi音响，1款soundbar,一款WIFI桥接器盒子，WIFI中控。

但其缺点也很明显：价格贵，体积大，仅仅适合高端消费人群，而且其核心优势multiroom功能只有在别墅才能体现出其优势来。2010年11月SONOS进入中国，所以从2011年开始中国有了第一批wifi音响的开发者，希望模仿SONOS的成功。而最早的一批开发者是用MTK5350或者高通的QCA9331开始开发的，但无疑都倒在了学习的路上。

于是有了亚马逊，亚马逊开始了Alexa的项目，大概开始于2011年，应该是受到了iphone4s语音助手Siri的启发吧（同时受到启发的还有“讯飞语音输入法”）。至于Echo（echo tap ,Echo, Echo dot）是Alexa实际应用的最成功的产品。（乔布斯真的是一代伟大的产品经理。）

其他平台的还有微软的小娜(基于windows平台)，苹果的Siri（苹果OS）

Alexa是亚马逊投入重兵研发出的语音识别云服务平台。像一个带语音搜索功能的APP Store（主要的功能有智能问答，音乐服务Amazon music,Spotify,Iheartradio等；新闻服务NBC；天气预报服务；打车服务Uber；智能家居服务IFTTT协议的灯等等）目前为止已经超过了5000个服务接入了亚马逊的Alexa云平台。

而Echo类似于苹果手机，不仅仅包括硬件，还包括一套基于Linux系统自主开发的操作系统（类似于Mac OS）。

Echo去除了SONOS的笨重，价格贵等缺点，当然最重要的是有Alexa做语音识别后台，产品有卖点，卖得特别好。其实，Echo已经不单单是一款wifi音响，已经成为了一台家庭智能中心产品，通过不断的采集用户习惯，收集用户问题训练Alexa让Alexa越来越智能，Alexa也集成越来越多的服务使得消费者越来越喜欢这款产品。

由于亚马逊是一家互联网公司，追求的不单是Echo销量的大幅增长带来的几十亿美金的销售额，更在乎的是Echo背后的Alexa代表的人工智能这个未来monster.所以，亚马逊把Alexa的API接口开放给到全球的开发者，开发者们可以利用Alexa开发出很多不同的硬件产品，比如：Alexa音响，Alexa车机，Alexa耳机等等。

怎么样开发出一款Echo音响产品（其他产品附带介绍）

1硬件

2软件

3云服务

4APP

5生产

6成本

7生态

（一）硬件：

1联网——WIFI芯片或模块（博通、瑞昱、MTK都可以）

2语音算法本地处理单元

（1降噪（背景噪音消除，回声消除）；

（2唤醒词唤醒；

（3语音方向识别）

——MIC整列（咪头）+ADC（音频模拟转数字信号芯片）+DSP（语音数字信号处理芯片）（一般由CPU模拟运算）。MIC整列负责语音的采集（一般来讲MIC越多声音采集的效果越好，但算法也就越复杂，对CPU的主频要求也就越高）ADC(将MIC采集的语音模拟信号转换成数字信号，并物理滤波消除一部分外部噪音，只保留20-20KHZ频段的声音)DSP（负责运行语音数字信号的处理，分两种：一种是用强大的CPU资源模拟运算降噪算法处理语音音频数字信号，一种是用芯片硬件处理的方式最终得到干净的人的语音信息）。

处理完成之后利用wifi信号将干净的语音信息编码打包上传到云服务器上做进一步的处理(语音识别，语义理解，服务调用)。MIC的参数主要注重灵敏度和几个MIC的一致性；ADC主要注重的是模拟转数字的采样率，（一般亚马逊对人声采样格式要求是44.1KHZ&16bit,这跟音响IIS音频高保真输出的192KHz&24bit的规格不一致，要做到兼容比较困难，尤其是外挂MP3解码芯片的这种方案。）

3跑整套音响系统的中央单元——CPU（处理器）+DDR（内存）+Flash(硬盘)；

CPU主要的功能是跑整套音响操作系统（Linux底层系统（类似于BIOS即各个硬件的驱动程序——CPU的SDK，WIFI（或者蓝牙）的驱动，音效DSP处理器驱动（一般是alsa协议），USB驱动，IIS驱动，GPIO的调用等），Linux之上的应用系统（类似于安卓系统或者window系统，包括网络上层通讯协议——配网的Smartconfig协议，AP-Station协议；网络数据下传协议Http,DLNA,Airplay,Qplay。

网络服务API接口配置Spotify,Alexa，QQ音乐，喜马拉雅音乐等；操作系统逻辑控制单元；软解码音频播放器；），其次是前面提到的语音算法运算也由CPU完成（一般的CPU是通过IIS接ADC芯片，ADC芯片再接模拟MIC，一路IIS可以接2个ADC，1个ADC可以接4个MIC；但是有些芯片原厂开发了直接支持数字MIC接口的芯片，就省去了ADC芯片的成本，但需要算法去满足这种直接数字MIC的输入）。

4音频解码单元——一般是CPU跑软Codec解决，也有采用外挂一颗支持IIS接口的MP3的芯片做硬解码。

5音效单元——音频DSP+功放+喇叭，音频DSP是需要调试的，尤其有EQ需求的音响调试就更困难，调试完以后把调音参数给到CPU的音乐播放器中（另外，一般的MP3芯片做硬解码的模式的是不能支持音效DSP的）。功放（分数字功放和模拟功放，如果DSP带DAC功能的可以接模拟功放，不带的只能接数字功放，现在主流的是用数字功放）。由于wifi信号比蓝牙功耗大，功率也就大，带来音效效果影响的可能也就越大，在电路设计和PCB的layout上需要做到信号屏蔽，防止视频电路对音频电路的信号干扰，一旦干扰会由于音频电路的信号放大在喇叭端引入很大的底噪，导致音质效果不好。

6电源管理单元——一般会有一颗电源管理IC负责分配从火牛或者锂电池输出的电流电压，Echo没有内置电池，所以不需要有电池充放电管理电路。也可以用DCDC来做出简单的电源供电电路

（二）软件

这里指的软件是指音响端的整套系统软件。最近这几年突然多了很多机器人公司，很多都支持语音对话这个功能，分为带屏幕的，不带屏幕的，会走路的，不会走路的，会转头的，不会转头的。后来发现这些机器人用的都是安卓系统，基本都是以前平板电脑的方案商在做，用的就是以前平板电脑的芯片。

所谓的自主研发其实就是在安卓系统的基础上做了一个人脸的UI，集成了一些内容（故事，儿歌，音乐等）——跟个APP差不多，这也就是罗锤子那一套，号称自己开发的手机系统其实只是做了一套安卓UI主题。这不是我们今天聊的软件系统，我们说的是这套软件系统其实等于安卓系统。因为linux是开源的，安卓是建立在linux系统上的一套应用系统，等同于window。我们讲的就是这套音响的操作系统。

现在有用安卓系统开发音响的，也有linux开发Echo的。安卓系统稳定性不如Linux，有很多冗余的功能需要底层裁剪，有可能裁剪错误导致系统不稳定，最大限度的裁剪也会导致系统固件有150MB，至少需要256MB的DDR，需要512MB的nanflash。

同时开机速度会比linux系统的音响慢10-15S，用得越久还会产生系统冗余导致运行得越来越慢。所以，无论从器件的成本，系统的稳定性，还是用户的体验上安卓都不适合做wifi音响，这也难怪亚马逊会选择用linux开发Echo音响，虽然开发时间多耗费了两年时间。而linux系统的音响只需要4MB的固件只需要16MB的norflah，64MB的DDR，开机速度可以做到10S以内开机，而且不会产生冗余文件，始终如一的用户体验。所以，SONOS和Echo都是用的linux平台。

这套操作系统包括：

1各个外围器件的驱动（DSP，按键，AUX、USB结构，IIS，IIC协议），配网，语音算法运行，音乐播放器，内容对接集成，网络传输协议（HTTP，DLNA，Airplay），服务API接口对接等等。

2本地语音识别的算法，对于算法包括两部分，一部分是本地设备端的降噪，背景噪音消除算法，本地唤醒算法，一部分是云端的语音识别和语意理解算法。我们先将第一部分，设备端的语音识别算法，设备端需要将背景噪音消除，降噪之后得到干净的语音内容，有两种解决方式1是通过科胜讯这种带DSP的ADC芯片通过固化到芯片里面的DSP将ADC转换得到的数字语音信号分析之后通过IIS接口输送给CPU再上传到云端，一个IIS接口可以接两个ADC芯片，每个ADC芯片可以接4个MIC。当然唤醒的算法是本地的一套软件集成到CPU里面——即设备的名字，如”Alexa”这个名字，激活词需要训练的，需要采集至少100多个人不同音色的发音，所以定制激活词会产生费用。2是通过降噪算法和激活词算法全部运行在CPU里面，所以，需要数字MIC将数字语音信号直接接到CPU端。目前能直接接数字MIC的芯片并不多，如全志的G102是可以直接接8个数字MIC的，但需要算法去把8个数字MIC直接调通。

（三）云服务

云服务是Echo的重点，包括了人工智能+各种服务，人工智能是负责语意理解和内容搜索并回答的，比如：你问Alexa今天天气怎么样，他会先把你说的话通过本地处理完以后的语音音频文件上传到云端的服务器，服务器将语音信息翻译成文字，然后把文字的关键词找出来，并通过了大数据的训练以后明白这段文字的抽象意思，然后帮你找到对应的答案，这个答案又必须去调用如气象信息的数据库（这个数据库也要支持语音搜索调取才行），最后反馈给音响，音响播报出来——哦，今天天气晴转小雨，需要带伞哦。

那么这一系列的动作是人工智能，天气信息数据库就是云内容。亚马逊集成了至少10000个云内容�...