混合云论坛作为大会分论坛之一，于8月15日下午举办。论坛邀请到了中国信通院、新华三、绿城集团、中国电信、长虹集团、腾讯等单位的专家，与大家共话混合云的应用与发展。
以下为长虹集团软件与服务中心数据服务部技术总监蒲文龙：《混合云助力长虹数字化转型》演讲全文：
大家下午好，很高兴今天有机会跟大家分享一下长虹这些年在云这块所做的一些事情。长虹创始于1958年，公司前身国营长虹机器厂是我国“一五”期间的156项重点工程之一，是当时 国内唯一的机载火控雷达生产基地。从军工立业、彩电兴业，到信息电子的多元拓展，已成为集军工、消费电子、核心器件研发与制造为一体的综合型跨国企业集团，并正向具有全球竞争力的信息家电内容与服务提供商挺进。目前长虹有1170.21亿的规模，去年开始了进入了数字化转型战略阶段。基于三坐标战略，提出“研发、制造、交易”三大智能平台建设战略，并拟定能力外放转型计划。长虹的转型也是它组织结构的转型，大家可能不太了解长虹，其实长虹目前子公司长虹电源是中国最大的航空电源提供商，四川爱联是中国最大的无线连接模块的生产制造商，长虹的佳华是中国最大数据存储方案提供商，华意压缩全球产销量第一的制冷压缩机，压缩机的技术也是全球领先的。同时长虹的技术体系，还成立了灯塔实验室和竞争力实验室，灯塔实验室就像华为的2012实验室，对我们而言，是一样的性质。长虹的转型主要围绕三个坐标：第一，商业的变革。第二，产品的变革。第三，技术的变革。今天重点分享下技术这块的变革，大家可以看到从云平台、大数据，然后再到最终能力外放的一个方向。
首先给大家看几个案例，2013年开始转型之后做的一些案例。战略地图，原来长虹在全国各地有几十家销售分公司，上千家经营部。原来要看一份报表数据的时候，其实它整个从统计，到逐层的上报需要一个月左右的时间，后来统一上了IT系统之后，将数据实时传到云端，进行实时的数据的统计分析，拿到数据报告，基本上就是当天之内就能保证拿到整个数据这块的报告。管理者能及时响应做出决策、降低决策风险。通过地图获知各行政区域销售情况，通过颜色深浅直观感受到销售好坏，通过时间轴可以看到公司历史销售情况，同时可直观看到渠道组织分布，销售任务信息，销售完成率等相关信息，随时随地了解各渠道组织销售完成情况，为经营决策提供可视化展现，从而更加快速响应业务变化。
这个案例是2014年10月的时候对8万5前多个端子信号源的使用情况的跟踪，得出的结果HDMI我们终端铺设了3路，而三路都插满的情况基本没有，再来看看YPBPR分子端口，基本只有发烧友会使用这个，他的使用占比也很少，可以取掉。而VGA一般是用于连接接电脑，很少人回家后还和家人分享一份商务的PPT，这块可以取掉。总的来说取掉的端子信号源，每年为公司节约几百万元直接的硬件成本，同时还提升了整个机型设计可用的空间。
个性化推荐，从我们的数据分析来看，目前整个电视这个大屏它的数据的流量的来源来自于个性化推荐的要占到40%以上。通过遥控器去点了之后，搜索到特定节目的情况只占5%不到，剩下其他是我们语音呼出这样的场景。而个性化推荐这块先后分了三个阶段。第一个阶段，那时候技术也不是很成熟，最早是把数据采集做了共性化的推荐，就是给用户反馈大家都在看什么，计算能力强大后，进入了基于家庭的推荐。用电视机大多数是一个家庭，所以没法区分到具体是某一个用户在用，这里做的推荐更多是电视终端的推荐。去年做了一个事情，就是通过深度学习去预测哪个时间段是家庭某一个成员他在看电视，做到千人千面的个性化推荐。
长虹也打造了自己的长虹大脑。其实就是语义分析和应用。目前做到多轮的对话，有40多个领域的技能，服务了千万级别的终端客户。
总的来说，长虹在云端这块能力的要求是亚秒级的响应，万亿集的数据集。而长虹传统的开发模式是项目制，就是一年上线一个项目或一个产品。所以，在整个用户爆发式增长的场景下求软服中心带来的挑战就是如何快速的迭代，如何快速的扩展、如何做到高可用。
挑战就有变革，原来的形式不行了。所以，从三个方面进行变革。第一，技术的革新：我们紧追新技术，包括最近微服务、容器等。第二，新的组织架构：也用产品线的方式做事情。第三，在企业的文化：推崇DevOps的文化。我们在实践过程中探索出基于基础云平台加速技术革新、devops文化落地到企业软件开发。
在上云的过程中有很多的挑战。原来IT采购方式，上一批机器就是两个月的时间，同时资源的利用率有的高、有的低，就琢磨着上云，而那时候要选择上云，各种云也特别多大大小小十几家云，我们用过的云很多阿里云、AWS、UCloud等等，基本上主流的云厂商我们都有用过。
公有云用的多后，发现最大的问题就是跨云之间怎么样去迁移，迁移一次，大的业务系统基本上得准备一个月，然后迁移一周，还得并行跑两三个月，然后整个任务才能完成，前前后后需要3、4个月。所以说，如何找一套好的方案来解决我们IaaS层迁移的问题。有幸的是，从2016年开始接触ZStack发现它解决了我们的问题，原来五六个人做的机房运维的事情，基本上一个人就可以搞定，整个私有混合云管理平台这块也做起来了，也不用装OpenStack那么麻烦。总结而言，一个核心就是如何降低TCO。混合云的要求最主要有两个方面，一个就是管理平台的打通，如何通过同一个平面将这种非标准的标准化，形成公司的一种标准。还有数据层面的一个打通，数据层面其实就是网络层面的打通，我们基本上也是通过专线的方式去打通。
Iaas我们通过Zstack解决了 ，PaaS层面的混合云管理，我们自己基于Docker开发了混合云Paas的管理的解决方案，叫Matrix Cloud。Matrix Cloud全面拥抱CloudNative技术，形成研发、运维、测试三个方面统一的基础云平台。Matrix Cloud速度上解决了一天多次部署的问题；在安全上保证了整个的可接性，还有应用的隔离。扩展方面能支持垂直和水平的扩展。还有优先性方面，因为电视终端有一个特点就是升级特别麻烦，业务的特点要求我们必须尽可能把计算放到云端。
Matrix Cloud整体的架构，其实很简单，底层是IaaS，就是ZStack私有云+公有云的方式，然后上面提供一些基础服务，主要是负载均衡和容器引擎，同时把数据库和存储抽象出来，因为要做容器，基本上存储要求存在远端保证服务的无状态化。然后DevOps服务就是我们开发的服务，包括敏捷的管理，代码的托管、测试的管理等，测试管理等。
容器平台我们基于K8s定制，和直接使用k8s 相比、在Matrix容器引擎控制台、应用的管理和部署更加简易（k8s 上手难、学习成本高）、自动生成部署网络拓扑图、让架构更加清晰、更加方便负载均衡配置管理、同时可以管理多个IDC的容器集群。
容器PaaS平台多集群的管理，就是通过统一的Total管理不同IDC的集群，达到混合云管理的效果。原来运维操作可能先起数据库，然后再起一个中间件，最后再起前端，业务编排做的事情，就是把整个应用统一的编排号，一键启动
高可用：我们把负载均衡分成内外网，平时我们使用软件WAF直接对接我们的内网LB，这样他有一个好处，就是如果我的WAF挂了之后，可以快速的通过DNS解析到外网LB，这样能保证整个服务高可用。同时做监控的时候也能监控内外部，快速定位内外部的问题。
除此之外，做了日志这块的管理，其实在容器整个日志这块的感觉很重要，如何把你的日志变得可搜索、可应用。有很多公有云的是用了ELK的解决方案，但是很多传统运维在用的时候是不习惯那种方式的，我们这里做了一些定制化的日志归档。
微服务引擎：兼容SpringCloud和servicecomb的微服务引擎、可视化的控制台、可视化服务治理配置、配置文件管理、客户端负载均衡策略配置、调用链的分布式追踪。
微服务必然会涉及到API网关。服务消费者（应用）通过 API网关然后转发到后端服务 ，请求通过API网关的时候对进行了认证鉴权、流量控制（每分钟请求多少次）、可约定应用对密文通信网关解密后转发给后端服务进行处理。API网关开放了自身的管理API便于集成，Matrix Cloud API网关除了对内部微服提供路由转发、安全认证功能外、还可以将内部软件能力服务能力开放给第三方合作伙伴。
通常的软件开发是需求、开发、测试、运维采用了多种IT工具进行协同、用户需要登录多套系统进行操作、比较繁琐。matrix devops服务是根据软服中心的研发流程做的深度定制，通过统一的控制台页面打通敏捷管理、开发 、测试、运维4个环境的协同。通过在页面上配置devops流水线完成开发过程中的单元测试、代码测试、接口测试 以及测试用例、集成测试环节的性能、安全扫描测试、以及最终的部署上线。
然后敏捷管理部分，我们基本上是以两周为迭代，然后去做持续集成，持续的测试，还有持续的交付。在整个迭代开发过程中，基本上都是走自动化的流程，必须要有人工测试的地方才会有测试人员去测试，基本上自动化能达到60%的水平。
整个DevOps的流程，很多都是自动化的流程，从拉代码到自动构建、自动扫描，只有在我们需要进行人工测试的时候才会走一个流程审批系统，然后去做测试资源的一个分配的申请。然后测试之后，测试人员会打一个Tag，相当于项目测试过了，然后整个项目就会进入到运维那里做应用的发布，运维那里发布也是一键就能上云。
举个典型的应用场景，这里我举的是语义相关的应用场景。其实终端过来之后，它会到API网关，API网关之后会到前台的一个聚合服务的智能语义服务，智能语义服务会调用业务中台的微服务能力，比如NLP专门做NLP的事情，知识图谱专门做知识图谱的事情。中台会利用后面的存储和数据库服务，把数据组合计算之后之后返回给聚合的前台，再返回给API网关，最终返回给终端的应用。
DevOps为软件团队提供软件开发全生命周期的DevOps工具链、从敏捷开发到代码驱动的自动化构建、自动化测试、自动化部署。
总结而言， Matrix Cloud带来的一个效益，成本节约这块，因为主要是Java多一些，总结了一下，基本上提升了20倍左右。因为原来研发在申请和运维申请服务器的时候申请的往往都很大，而且Java应用的内存是阶梯式的增长，这部分通过容器的监控，能细化在应用这块的问题，也能排除一些连接未关闭等的一些问题。同时也完成了公司在大数据、AI领域的多元化支撑。在效率这块，原来更多靠人，现在更多靠自动化，基本上提升在50%左右的提升，跨云可迁移也不受限于特定厂商
目前我们的应用相比前面嘉宾所介绍的应用规模而言还比较少，目前成规模的应用有50多个，自动化部署2000多次，微服务有100多个，20000+的自动构建，5000+ 容器。
