AI与云原生，技术圈最火热的搭档

原文链接： https://github.com/apache/servicecomb-java-chassis/tree/master/java-chassis-spring-boot/spring-boot-starter/spring-boot-starter-discovery

作者 | 贺宇&华为云布道师

在容器技术、编排系统、微服务理念等云化技术和管理方法的带动下，应用上云已然成为一种趋势，云原生理念应运而生。一方面，云计算已经重塑了软件的整个生命周期，从架构设计到开发，再到构建、交付和运维等所有环节；另一方面，企业 IT 架构也随之发生巨大变化，而业务又深度依赖 IT 能力。而这带来了一定程度的复杂性和挑战性。

云原生理念被认为是云计算发展的必然导向，采用基于云原生理念的技术和方法：以容器为基石，通过微服务化的改造，融合 DevOps 理念，有助于更好地实现业务“迁于云”或“生于云”，能够帮助企业快速构建更加适合云的敏捷应用服务。

QCon 全球软件开发大会于 5 月 6 日在北京正式拉开帷幕。5 位华为云布道师在“AI 与云原生实践”专场发表了精彩演讲。演讲内容聚焦当前云原生的技术痛点以及 AI 相关的解决方案，向业界输出了华为在相关技术层面的实践经验。

1ServiceComb 协同开源和业界力量共同解决微服务痛点难题  

华为云布道师首先分析了微服务的痛点以及面临的挑战，对于微服务的具体实践，也给出了自己的看法。

  微服务是用户应用上云、全面解耦的基石

传统IT应用开发过程中遇到的典型问题，比如烟囱型架构遇到的资源分散、数据不通问题；互联网+转型的传统企业遇到业务上新周期长、流量不确定等问题，还有集团性大企业在数字化转型过程中遇到个性化需求激增、多厂商难集成难管控等问题。

随着云原生技术的发展，以虚拟机为资源服务的资源云化开始向以应用为中心提供能力服务的应用云化演进。微服务凭借其独立、轻量级、去中心化、松耦合等特征，结合云上完善的自动化运维体系，帮助用户构筑快速试错、短平快交付、按需弹性的能力，解决用户关心的痛点问题。因此，微服务也成为云化时代的流行架构，可以说，微服务是用户应用上云、全面解耦的基石。

然而，微服务不是“万能钥匙”，它面临着如何高效开发和上线、保障高可靠、问题快速定位与恢复、遗留系统低成本迁移等挑战。这些都是华为各产品线微服务化实践的精华，也因此衍生了易用、开放、多场景、企业级的微服务解决方案。

  Apache ServiceComb开源微服务解决方案

华为在2017年6月将内部实践了5年、商用了3年的微服务解决方案无保留地开源到ServiceComb，并捐赠给Apache基金会。2018年10月成长为Apache基金会首个微服务顶级项目。

面对团队协作困难、资源利用率低、问题定位困难、分布式事务和多语言等在微服务开发中遇到的挑战，ServiceComb坚持“将复杂留给自己，将极简留给用户”的设计理念，通过构建标准契约管理、异步内核、编程/通信模型分离、精细化监控治理、插件式集成等关键技术能力，帮助用户实现最小成本改造、减少基础设施运维工作量、提升系统性能和资源利用率、问题定位效率和灵活扩展。

“提供一站式的开源微服务解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理”是ServiceComb社区的愿景。ServiceComb不会止步，它将协同开源和业界的力量，在自己的技术积累基础上继续将微服务行业发展壮大，并分享给遇到微服务化难题的企业、用户和开发者。同时，也将和同样面临数字化转型的企业、用户和开发者共同探讨和持续创新解决微服务难题，促使行业更快地向云化转型。

  Apache ServiceComb是如何帮助用户实现微服务转型的？

在大型企业做数字化转型过程中，往往会遇到服务难拆分、开发效率低、系统性能弱、多语言集成以及多厂商集成导致的项目周期长、业务难打通、标准不统一等问题，这些都是单体的架构以及在传统的微服务框架里面经常遇到的典型痛点。

ServiceComb 通过提供扎实的微服务技术支撑，结合更快、更稳、更经济的华为云 ServiceStage 一站式应用开发平台提供的支持多种编程语言，集成 Eclipse、IDEA、Jenkins、Maven 等多种工具生态，支持线下开发环境和线上云环境的无缝集成，面向 DevOps 提供应用开发、编译、构建、发布、部署、配置、压测、上线、运维和治理等全栈、全生命周期能力，帮助企业、用户和开发者，快速实现数字化转型上云。

• 沉淀服务化转型要素、微服务拆分原则，确定合理及可持续演进的系统架构设计；

• 提供一键式脚手架、开箱即用的服务治理，降低微服务开发入门门槛；

• 支持 springmvc/pojo/jaxrs 多种编程风格，提升遗留系统重构效率，用户最小改动实现微服务化；

• 首创服务契约管理，使数据、服务标准化，多厂商开发场景过程可管控，提升最终交付质量；

• 同时支持同步 / 异步通信共存和灵活组合，适应多场景的高性能诉求；

• 提供精细化监控和度量，解决多团队 / 服务协作场景定位难问题，保障业务的线上运行质量；

• 融合华为开源的 Mesher 方案实现多语言支持，快速集成遗留应用及三方系统，并实现统一治理；

• 提供跨 DC、异构服务中心互通方案，支持跨云、跨 DC、多异构系统集成。

 小结

ServiceComb 始终保持扎实做微服务，认真做开源的初心，协同开源和业界的力量，在自己的技术积累基础上继续将微服务行业发展壮大，共同解决微服务开发的痛点难题，为企业、用户和开发者做实事。在推广 ServiceComb 社区的过程中，不仅仅推广技术，更是坚持同时布道微服务理念、微服务方法论和 Apache 开源文化，希望能竭尽所能在吸取业界智慧的同时为业界尽可能地多做贡献。

2容器多云 & 混合云解决方案（MCP）  

在容器多云&混合云方面，华为云布道师分享了关于华为全球首个容器多云 & 混合云解决方案的实践。

追溯华为云的历史，华为云一直持续关注如何便利地实现混合云管理。近年来，随着容器技术的迅速普及，其带来的应用发布和部署接口的标准化给多云管理带来极大的助力。华为云多年来也在容器领域持续引领Kubernetes社区Federation开源项目的构建。Kubernetes Federation是容器多云 & 混合云解决方案的核心组件，通过Kubernetes Federation可以把容器应用非常方便地部署到多个kubernetes集群中并进行拉通管理。

目前容器多云 & 混合云解决方案已经验证多个容器云的混合管理，包括各厂商的公有云以及私有云Kubernetes产品，也可以管理用户基于开源自建的Kubernetes集群，实现应用的跨云部署和访问，提供多云互联网接入和容灾能力。

而CCE HCS Online，是华为基于CCE做的线下扩展，可以帮助用户在本地的数据中心部署华为云CCE的Kubernetes服务。容器多云 & 混合云解决方案也可以很方便地拉通公有云CCE以及CCE HCS Online进行混合云统一管理。

另外在混合云场景下，容器多云 & 混合云解决方案也提供了多样化的扩展插件能力：如基于Prometheus实现多云的统一监控框架，并支持多集群监控数据汇聚展示，并提供跨云的应用弹性伸缩能力；在混合云场景下，可以使用Istio进行跨集群的微服务调用、容灾限流、调用跟踪。

 华为容器多云 & 混合云解决方案整体架构

华为容器多云&混合云解决方案整体架构

容器混合云，可以支持跨云管理，避免厂商锁定。当前容器多云 & 混合云解决方案测试过管理包括华为云、OpenShift、阿里云以及用户自建的 Kubernetes，也可以很方便灵活地调整各个集群中负载数量，实现应用灵活迁移和容灾。

 华为容器混合云和多云解决方案举例

避免厂商锁定

统一开放管理平台

高效容灾管理

3CaaS 架构演进之路  

华为云布道师周晖在演讲中，首先回顾了CaaS架构演进历程。

华为云布道师周晖

最早的PaaS 来源于 Heroku。2007年，Heroku在云上提供应用托管服务，它有两个非常大的贡献：一个是贡献了云原生的12要素；另一个是Buildpack机制，可以自动构建，自动打包，自动运行。Heroku是公有云并没有开源，没有成为开源PaaS平台，但是它为云原生、为容器做出了贡献。从2009年开始，IBM发布WebSphere 的中间件，包括Workload deployer，本质上是应用服务器的多租户，难以支持第三方的应用服务器，不是现代意义上的PaaS，后来的Oracle基于Weblogic的PaaS也是这条道路。

CaaS架构演进之路

到 2011 年，Cloud Foundry 出现，它是现代意义上 PaaS 的雏形，引入了现代 PaaS 的概念。Cloud Foundry 目前仍在持续稳定的发展。

2013年Mesos和2014年底DockerSwarm出现，但最后没有修成正果。相反，Kubernetes取得了成功。Kubernetes的架构非常好，能够真正形成生态。跟Cloud Foundry不一样，Kubernetes是对一个应用计算模型的抽象，应用只需要一个运行环境——Pod，其他交给Kubernetes来调度。至于是云原生应用还是大数据应用，这个模型抽象都可以适应。Kubernetes分离了控制面和工作负载面，所有应用相关的功能，比如日志、监控等均不在模型中。作为工作负载的一部分，反观Cloud Foundry，把日志、监管、负载均衡均放在系统架构中，这样严重约束了架构。如果要替换Cloud Foundry的日志，监管会有相当大的工作量，相当于是颠覆原来的CF架构。

为什么Mesos没有走下去？Mesos的架构来源于大数据架构，大数据的架构就是Master加Slave。Mesos连架构的名称没都改，它就是以大数据的模型来运行应用，显然不合适。大数据是要以任务调度为主，但应用很多都是长周期的运行的，所有Mesos后来又加了一个马拉松。

Kubernetes的Pod是个非常好的设计，带来了强大的可扩展性。只要在Pod中增加一个监管、日志的容器，就可以带来相应的功能。再比如服务网格，只要在应用Pod中增加一个边车容器，就可以实现应用的代理。这样几乎可以无限扩张各种功能，进而带来了Kubernetes强大的生态。

而无论是Cloud Foundry、Mesos、DockerSwarm都缺乏Pod这种模型的架构，要扩展功能都会比较复杂，而功能扩展负载，必定会弱化其生态。

DockerSwarm 最后基本上也被边缘化了。DockerSwarm是做一个容器的抽象，缺乏Pod这种可扩展性的架构模型。

 2019年PaaS 技术趋势

对于 2019年PaaS 技术趋势，周晖给出了自己的判断：

2019年，CNCF的趋势就是“ 从K8s独木到CNCF生态森林"。从2018年至今，有6个CNCF项目毕业。而Kubernetes也成为事实标准，它所有的竞争对手Mesos、Cloud Foundry、DockerSwarm都支持部署Kubernetes；即使是强大的公有云，如AWS有自己的调度，最后也提供了Kubernetes服务；微软也有自己的调度Service Fabric，2018年也提供Kubernetes 服务。从这些角度来看，Kubernetes基本上就是云的应用平台OS。

第二个技术趋势点是服务网格，服务网格是微服务领域发展的里程碑，促使微服务进展到新的阶段，使得微服务应用有了新的选择，可以不用代码框架，而是通过平台来实现微服务治理等功能，消除了目前微服务框架的痛点---现有应用微服务改造需要基于微服务框架重构。

第三个技术趋势点是Kubernetes多云，包括今年Google发布其Anthos的容器多云服务。

第四，基于容器的边缘计算也是逐步成为新的技术热点。

第五，Serverless也是PaaS的一个热点趋势，基于Kubernetes的Serverless得到越来越多的大厂商认可，并相继推出了现有的产品或服务。

 华为云容器创新

华为云容器是一个加速创新的过程，2015年有一个比较大的创新点，2016年有2个，2017年有3个，2018年有6个，并且每年以50%~100%的速度增长。今年上半年已经有3个了。2015年华为选择了Kubernetes作为容器服务的核心平台，发展至今已经有4年了。一方面，华为云对Kubernetes/CNCF社区积极贡献，另外一方面将成熟的部分做成商业化服务提供给客户。华为云在Kubernetes的发展上，无论是对社区的贡献还是企业级的功能，都是业界领先的。

华为云容器创新

有人说，对于开发者而言，云原生是最好的时代。以容器、服务网络、微服务、Serverless为代表的云原生技术，正在用一种全新的方式构建应用。除了云原生，AI在推动企业数字化转型上的影响力正在爆发。

4Mask-RCNN 快速模型开发    

华为云布道师孟繁亮针对如何基于 Mask R-CNN 快速完成模型开发，与现场开发者展开讨论。

华为云布道师孟繁亮

 Mask R-CNN 的核心

什么是Mask R-CNN？Mask模型不单单可以做图像轮廓型的标注，甚至配以适当的数据集，连人体、姿态、骨骼、头、躯干、四肢动作都可以标注。Mask R-CNN 核心的三大部分是CNN、RPN、ROI。

Mask R-CNN架构

Mask R-CNN的演进历程分为几个阶段：最早从R-CNN开始，它的底层是CNN网络。之后又出现了一个Faster R-CNN，后来又加了RPN网络，可以更好地处理一张图片里面比较小的物体的问题，最后演化成Mask R-CNN。之所以不断演进是为了追求更有效的数据利用率，这里面的关键点，其实是CNN、特征ROI、RPN特点是如何演化的。

具体看Mask R-CNN的构成，从Faster R-CNN进入，由FCN去处理抠图，主体是ResNet+FPN，最后增加Mask。其中，ResNet解决了传统的人机神经网络训练不好收敛的问题。

举例来说，人脸识别出来的效果一定是人脸越近会越大，人脸越远会越小。这时候产生一个问题：怎么有效地把大的人脸识别出来？又怎么把小的人脸识别出来？

在Mask R-CNN里面，对一张图做5种层次的卷积计算。根据ResNet图，提取C1到C5，标注从C2到C5，做一个特征金字塔的计算。

RestNet——>FPN——>RPN

当我们有了很多特征之后，怎么样从大大小小的特征里面收集有用的特征？于是引入了模框的概念。模框会把边缘标出来，并根据不同的抽象层次，用这些模框去对比原始的标注信息。RPN利用特征图做两件事情，一件事情是判定前景和背景，另外一件事是获得最准确的推荐区域。

分类和目标检测是指通过full connect层与softmax计算每个region proposal具体属于哪个类别（如人，马，车等），输出cls_prob概率向量。同时再次利用bounding box regression获得每个region proposal的位置偏移量bbox_pred，用于回归获得更加精确的目标检测框。

分类和目标检测

5NLP 在企业智能场景的算法应用  

NLP 在近一两年实现了显著的突破，OpenAI 等技术的诞生、迁移学习等技术的成功应用使得 NLP 技术在不同行业领域内的发展不断壮大。但与此同时，不同领域不同的场景中会遇到各种各样的难题，例如面向企业的智能客服系统、智能助手、智能外呼等场景都会有很强的领域属性。

华为云布道师在 QCon 现场深度解析了 NLP 在企业智能场景中的算法应用、模型优化，以及如何快速构建诸如智能对话系统等企业智能应用。

NLP对话系统架构

自然语言相关的产品，大多对底层能力的要求很高，需要长期积累NLP基础能力，这也是常常被忽略的一点。比如分词，经常是系统效果不好的关键因素，在不同的场景可能用到的分词粒度不一样。同时需要能更好地把领域知识（如词典等）与模型最更好的融合。再比如命名实体识别（NER），大部分与自然语言相关的一些问题，不管是问答、对话还是舆情都可能用到NER，企业场景里的NER任务经常需要识别该领域或场景特有的类别。同时也需要高质量的标注数据来训练模型，比较好的解决办法是做多种方式融合的方案，比如说规则，与机器学习，深度学习的融合。

在对话系统中很常见的问题是意图识别。一句话过来，让机器人去理解其中的意图，然后根据意图决定后面该做哪些事情，这其实是个典型的文本分类问题，尤其是在企业场景中，容易遇到冷启动的问题。可以考虑根据不同阶段，选取不同模型。比如，前期冷启动中使用一些无监督模型，或者一个基础模型做分类；在数据量逐渐积累增多后，采用深度学习模型通常能够取得较好的效果，现在也有研究人员利用知识图谱对知识做泛化抽象，以增强模型效果。

与智能对话相关的应用场景有很多，在智能呼叫中心里有非常多跟语音语义相关的应用，如智能客服机器人、智能呼叫中心、外呼机器人等。在呼叫中心里，坐席人员接打电话，如果想知道坐席人员服务质量怎么样，传统方法是人工抽检。而现在用机器做质检，判断坐席人员说话有没有不恰当的地方。机器人也可以辅助坐席人员，帮助快速找到答案，从而提升坐席效率和用户体验。

6写在最后  

在中国市场，云原生仍然是一个较为新的概念，多数中国企业在云原生的专业知识、部署开发以及管理应用的能力仍不成熟。令人欣慰的是，在云原生道路上，云厂商们已经充分意识到了云原生将是企业数字化转型的加速器。

如今，大多数企业开始全面拥抱云计算，在 All-in-Cloud 全面到来的时代，有三个重要转变：基础设施的云化、核心技术的互联网化、业务的数据化和智能化。在各行各业中，都有很多业务应用从诞生之初就生长在云端，各个企业也因此越来越像互联网公司，而技术能力被视为不可或缺的核心竞争力。

正如人类社会发展伴随着技术革命与社会大分工一样，云原生技术的出现解耦了很多复杂性，这是 IT 技术的进步。

通过本次华为云“AI 与云原生实践”专场的技术布道，让开发者对云原生、容器、NLP、机器学习等技术有了更进一步了解，而华为云在上述技术上的实践方案也在向业界不断渗透，贡献自己的一份力量。

此外，华为云另外两位布道师也在今天的QCon大会上发表了演讲，探讨议题是：华为云深度学习在文本分类中的实践，K8s为AI应用提供大规模GPU算力之实践。请大家持续关注。

华为云亮相QCon北京 

在看点这里

戳“阅读原文”阅读相关源码

并给ServiceComb点个“Star”吧