精华内容
下载资源
问答
  • 何宁 青云QingCloud原文地址:...文中,何宁详细分享了太平保险集团独特的信息化建设之路,以及实现太平云建设的历程和多年积累的云计算实践经验,非常值得从业者借鉴与学习。1 私有是一个伪命题关于太...

    何宁 青云QingCloud

    原文地址:https://mp.weixin.qq.com/s/1IUta4X59S1Wpw93UCvc1A

        前言:本文为中国太平运营管理处副处长何宁在青云QingCloud 保险沙龙上的技术分享整理而来。文中,何宁详细分享了太平保险集团独特的信息化建设之路,以及实现太平云建设的历程和多年积累的云计算实践经验,非常值得从业者借鉴与学习。

    1 私有云是一个伪命题

    关于太平集团
        太平集团是国内金融界有点另类的集团性保险企业,作为第一家在境外上市的中资保险企业,是唯一一家管理总部设立在香港的中管金融保险集团。太平集团经营区域涉及中国内地、港澳、北美、欧洲、大洋洲及东南亚等国家和地区;业务范围涵盖寿险、财险、养老保险、再保险、再保险经纪、互联网保险、资产管理、证券经纪、金融租赁、不动产投资、养老、养老产业投资等领域,业务种类齐全,为客户提供一站式综合金融保险服务。
        正是由于以上背景原因,太平集团的信息化建设之路可能与一般的保险公司有所差异,这样的差异对我们打造太平云也有着一定的影响。
    我一直认为私有云是一个伪命题,可以从以下几个方面来看:
    • 从在线程度来看,公有云一定比私有云有更高度的在线程度;
    • 从数据流动产生信息从而生成价值的角度来看,公有云更有明显优势;
    • 从建设速度来说,公有云等于开箱即用,私有云需要部署、集成、调试步骤。
        这种情况下,肯定要有人提及安全问题。
        但是,从宏观角度来说,只要金融行业拥抱互联网,无论是公有云还是私有云,面临的安全问题都是一样的。去年的蠕虫病毒,公有云服务提供商没有受多大影响,但金融行业,不少企业的局域网里反而出现了不少问题。
        从微观角度来看,有什么证据能说明金融机构做信息安全的能力可以高于专业提供资源服务供应商的能力呢?
        当然,在公有云真正普及之前,未来的 5-8 年内,私有云还会在中国市场上生根发芽、枝繁叶茂,这是我们无法规避的阶段,就像社会主义初级阶段或者社会主义新阶段。

    2 太平云建设规划:1 个目标,3 个要求

        去年,集团开始规划要搭建太平云,制定了 1 个目标、3 个要求。
        第一,这个云要建立在集团的范围内,不是只给某一个公司或者营业机构提供服务;
        第二,这件事情的整个周期为 8 个月;
        第三,最终衡量太平云平台的好坏不在于是否完成了建设,而是平台之上是否可以实现各种应用的价值。
    我们当时做了一个计划,以太平集团旗下最大的太平人寿作为试点,试点成功后共享推广,最后形成真正的集团标准,在境内外使用。

    3 两地三区域落地

        第一期,我们主要以建设 IaaS 为主,基本满足虚拟化、SDN,实现在此之上部署一些 PaaS 服务。这些服务基本是面向应用开发部门,让大家可以快速高效地拥有完备的应用开发测试环境。
        目前,太平云处在规划建设的 2018-2019 年阶段,建设中心是 I-PaaS ,我们更多的还是面向应用开发部门,为他们提供更好的 PaaS 服务,同时让更多的专业子公司使用这个平台。
        我们现在在做科技太平的课题。明年,我们会往下一个阶段发展,转向提供面向业务应用的 B-PaaS 或者 SaaS服务。比如客户画像或者认知识别,将来很可能会通过 B-PaaS 的方式交付给集团下属各专业公司使用。
        太平云的一期建设,从 2017 年 8 月份开始启动,12 月迎接第一次开门红,今年 3 月份收尾,用时 7 个月 30 天,比规划的要求提前了 1 天。
        一期规划落地的时候,主要实现的是“两地三区域”,我们有上海数据中心、武汉数据中心。上海数据中心被我们划为生产区域,武汉有开发测试和生产区域。
        去年,我们在上面使用了不少青云 OEM 的 PaaS 组件,目前匹配良好。我们把原来一些商务数据库上的东西迁移到 MySQL 上。
        其实 MySQL 本身的一致性的问题不好解决,青云在这方面做很多优化与实现,帮我们解决了不少技术难点。除此之外,非关系型数据库、缓存、Hadoop 等东西都已经放在了上面。
        在太平集团内部,私有云平台建设的出资方是太平人寿,托管给太平金科运营。其他公司,比如财险、寿险、养老、太寿香港等,他们做为用户方来租赁私有云。
        这就像是集团内部公有云,太寿出钱,金科运维,其他公司租赁。从集团的角度考虑,如果想要把新生事物顺利推广到集团范围内,建立管理制度和技术标准非常重要,这个理念在整个行业或者信息产业内都是一致的。
        所以我们一方面建私有云平台,另一方面建立私有云管理办法和准则;在此之上建立运营细则树立运维标准,指导实际运营工作;在运营和运维细则基础上,我们建立一套财务细则,制定各公司和金科的月度结算流程和标准。
    此外,我们还制订了一套比较适合集团使用的服务目录,包括各个资源整合和分离的定价体系,嵌入了资源申请审批流程,增强了资源计费报表分析功能。这两部分比较贴近私有云而非公有云的客制化开发部分,要感谢青云的投入和产出。

    4 太平云建设的五个阶段性成果

        太平云建设规划一期落地,实现了“太平云”平台的五个子目标,太平集团拥有了一个在架构和功能上都较完整、先进的,真正意义上的私有云。
        第一,给集团各单位提供统一、快捷、按需申请的基础设施分配服务。
        我们还有一个目标是建立能提供服务的基础上,还能用于支持服务配套管理制度体系。
        第二,面向应用开发能够提供开箱即用的开发平台、应用支持、安全防护等 PaaS 服务。
        这里有一个隐性目标,我们非常希望把开源的东西落进去。我们集团是一个比较传统的企业,拥抱开源需要创新的思维。我们    希望把在商务套件的支出慢慢转到开源项目上。但是,这里涉及一个概念,我们不能认为开源就是便宜,绝对不是,它只是资金支出方向不同 – 从对商务套件的授权的资金支出转为对内部人才培养的资金支出。
        第三,统一管理的多地域、多数据中心资源。
        我们想做异地灾备,想在今年或者明年尝试一些跨域的互联互通应用。
        第四,提供多租户方式下的调度管理和服务计费功能。
        我们想做利旧。现在国内每年开门红会购置一批机器。开门红一过,60-70% 的机器就有闲置压力。
    当我们有了平台和资源,开门红只有一两天,在那个时间段里可以尽可能压缩测试区域资源,把里面的资源全部投入到生产区域;结束之后,再把资源释放回来,放在开发测试区域使用,这样资源投入不会短时间大幅度增长,而且既能兼顾开门红业务,也不影响平日开发测试。
        第五,满足现有虚拟化的资源需求,支持未来灵活的需求。
        我们希望有一个平台,除了可以纳管云平台之下的资源,还能将 VMware 、裸机等系统统一在一起管理。这样集团可以清晰知道哪些资源在用、哪些闲置、哪些该扩容、哪些该撤销,往资源集约化、降本增效的方向运作。

    5 太平云端的业务实践

        平台落地后便是做应用,太平人寿成立了创新发展部,在云平台上做应用——太平云保就是这样一款互联网核心应用。

    微销产品通过微信渠道销售各种各样的产品。这有点像众安的方式,但是众安的方式是以客户打通客户,微销则是通过代理打通代理和客户。


    (说明:原图不清晰,转载时重新绘制了一下)

        如上图所示,上面是微销平台,下面有互联网核心系统。互联网核心通过消息队列慢慢有序的递交到传统核心系统里。总的来说,底下基础架构有云平台支撑,中间有互联网核心,上面有应用层支持创新业务。
        这件事挺有挑战,互联网核心平台去年 3 月份设计,6 月份完成,8 月 18 日启动私有云项目,9 月 4 日部署好上海站,经过两个月安全和压力测试,12 月初开始迎接开门红。
        开门红那天,早上 11 点资源遇到瓶颈,我们在云平台上用 16 分钟,扩展出 20 个节点。大概 15分钟后,资源占用一下就下来了,直到当天晚上 11 点,再也没有出现资源紧张的情况。
        一个新私有云平台加上一个新的互联网核心,在开门红的这一天,支撑了三分之一的保费。这还是比较有说服力的。

    6 业务实践后续规划

        现在有了平台和应用,后续的计划主要分为四个维度:
        第一,纵向,希望满足各公司资源需求,实现预设目标;横向,希望各个专业公司新建系统都要云化。
        现在主要用的是寿险、金科,今年我们会把它推广到养老、太平香港、太寿香港、财险公司,目前资产公司也在运作中。更为重要的是,由于接入多、高并发业务多,我们希望青云私有云平台可以经受得住更激烈的考验。
        第二,从应用来说,它有集成性,毕竟私有云平台是新的,我们要想办法把传统应用集成起来。
        现在保险行业比较流行的做法比如秒赔、闪赔,要把非结构化的数据做前置,现在我们和青云合作也在探索如何把对象存储应用到这些业务中,把非结构化数据从后端移到前端。
        第三是制度,第一次制定云平台制度,一定会有不满意不科学的地方,还有优化的空间。尤其是考虑到境外监管机构要求和国内要求不太一样,未来,我们也需要建立在国际上能通用的制度。
        最后是创新,最重要的是开源创新。此外还有数据安全创新和基础网络部分的创新。

    7 云平台建设中的 5 点思考

        最后跟大家分享我们做规划和建设过程中的一些思考:
        第一,平台价值的体现。
        我们认为一个平台服务的价值绝对不是体现在平台本身,平台本身是一个非常基础的东西。它真正要体现的价值是建立在平台之上的应用,以及应用所能提供的服务价值。
        第二,私有云和公有云的差异。
        青云是一家对私有云和公有云差异性有清晰认知的公司。公有云和私有云真正放在企业里,概念是不太一样的。公有云没有真正流程的概念。企业有比较严谨的审批流程、合规流程,要经得起考验、稽核以及审计,不是每个人想申请资源,就有资源。而这些都是公有云上不会考虑的。
        去年我们做了很多事情,把私有云独特的东西抽取出来,和青云做开发改进,青云也帮助我们解决了资源申请、费用结算等私有云比较独特的需求。
        第三,平台周边系统关系处理。
        太平集团的做法是一步步来,适合迁移的,我们可以逐步做迁移。现在没有实力、没有能力、没有精力、没有资金做迁移的,保持中庸的容忍。
        在用户体验一致性层面,我们尽可能把青云和原来的体系通过某些定制化开发来实现平滑的过渡。对于用户来说,他对迁移的感知度极小。
        网络层面来看,我们现在有两个数据中心,一个在上海,一个在武汉,中间是两根 1G 的带宽。如果你的底层核心在上海,你想让别的公司在武汉用,不解决网络问题,这件事很难推进。
        现在网络成本比较高,我们今年可能会尝试用裸光纤或者其他方式解决两地城际网络的问题。我们预计同一平台下的“两地三区域”访问能达到 4G 的城际网水平,但这是一笔不小的支出。
        第四,平台上的专业交流。
        既然都在一个平台上,当大家对于同一个问题感兴趣的时候很方便组织沟通交流,比如去年财险和寿险对 Spring Cloud架构的沟通交流。我认为这是平台带来的另一个附加好处,各个公司可以在技术层面上有共同语言,大家有共同研究的契机。
        第五,平台中沉淀的数据。
        对于数据分析和生命周期管理,太平集团一直在做。目前,已经将寿险、财险、养老等客户信息集中在一起,我们希望有精准的客户画像,提高将来产品投放的精准度。之前那套系统比我们后面想在私有云平台上做困难很多,我们现在也希望逐步把它移到开源的体系中去。
    展开全文
  • 云平台如今已经不是陌生的概念,在互联网企业中,基于云平台已经发展出一套全新的技术研发体系,颠覆了原有的开发框架、运维框架甚至是企业组织架构和项目管理方式。而互联网企业也利用其先天的技术优势和开放、灵活...

    作者简介

    Gavin,程序员、软件架构师、企业架构师,关注智能制造。

    云平台如今已经不是陌生的概念,在互联网企业中,基于云平台已经发展出一套全新的技术研发体系,颠覆了原有的开发框架、运维框架甚至是企业组织架构和项目管理方式。而互联网企业也利用其先天的技术优势和开放、灵活的互联网思维,以互联网为基础,快速而高效的影响甚至颠覆了诸多传统行业。

    另一方面,制造企业也一直在思考如何利用先进的技术和理论改造和升级其生产和运营模式。比如现在制造企业普遍部署使用的软件系统主要分为两类,一类是在车间层面、工厂层面、集团层面使用的的综合业务类管理系统,比如MES、ERP等;另一类是满足特定需要的功能性系统,比如专注于数据采集和控制的SCADA系统,专注于仓储物流的WMS系统,专注于产品设计的CAD系统等。但系统使用得多了逐渐会衍生出一些问题,比如说信息孤岛,不同厂商系统间难以交互协作。在制造企业,这是一个重要但又难以很好解决的难题。比如MES系统为了分析某些指标需要SCADA系统和WMS系统提供某些数据,而由于现场技术条件限制所需数据无法提供或者数据质量不达标,从而导致MES系统的分析功能无法产生理想结果,这种情况在实际项目中经常出现。于是软件厂商为了满足企业的需求,一般会从两个方面进行改进,一方面是开发数据接口增强与外围系统的协同能力,另一方面是干脆逐步扩大自己的功能范围,既满足客户整体性的业务需求又抢占了更大的市场资源。软件厂商扩大功能范围的思路有两个,一种是把软件做大,然后通过配置裁剪功能,早期很多软件都是这种做法,但问题是研发和维护成本大幅增加。另外一种思路就是作平台,平台提供基础资源、服务和标准,然后通过合作伙伴按照平台标准提供特定功能性应用来配套形成企业整体的解决方案,这样一方面解决了研发和运维成本的问题,另一方面通过标准和接口也提高了不同应用之间的整合能力,而云计算也是恰逢其时的为这种思路提供了实现的技术手段,所以就涌现出了各种各样的工业云平台。而作云平台的思路也有两种。一种是系统集成商或者第三方来做的公有云平台,在平台之上部署有各类现成的应用和服务,企业来用就好。另一种思路是企业来做私有云平台,软件厂商在企业的云平台上按照企业的标准和要求开发应用,这样从满足企业需求的角度来讲无疑是最佳的。并且两种模式又可以彼此融合,互相补充。

    如此,便发生了一件有意思的事情。就是互联网企业和传统制造企业,两类原本不相干的企业慢慢的逐渐走向相同的技术路线,甚至互相影响,互相融合。但是在这个过程中,双方也都面临这巨大的困难。对于互联网企业来讲,制造企业的行业领域知识、生产管理体系还有底层纷繁复杂的工控设备、自动化仪表仪器是难以逾越的坎;而对于制造企业来讲,互联网企业快速更新的软件研发技术、研发管理模式还有敏捷快速的互联网思维则也是难以克服的障碍。

    最典型的就是经常被作传统行业软件的同行,比如MES的工程师或者PLC的工程师问到,客户让我们上云,但什么是云呀?云平台有什么用呀?怎么上云呀?所以本文就来谈一谈我对这方面的理解:制造企业使用云平台可以做什么?

    1、云化机房,提高运维效率

    构建私有IaaS云可以让机房运维更加简单。

    所谓云化你的机房,就是在你的机房里建一个基础设施云环境,称之为私有IaaS云,主要功能就是在你原有的服务器集群上搭建一个可以按需使用的虚拟机集群。怎么搭建私有云呢,有两个技术方案可以选择,OpenStack和vSphere,OpenStack和vSphere有什么区别呢,你可以理解为Linux和Windows的区别或者是Android和IOS的区别。OpenStack开源,所以相对廉价但稳定性差。生产环境下就不要打算使用纯开源的OpenStack了,可以选择国内外专门做OpenStack的厂商,它们会对每个版本的OpenStack做大量的稳定性和适配性测试,并封装一些小工具以提高使用的便利性,同时还有技术团队帮你做实施和维保,可以很大程度的解决使用和稳定性方面的问题。vSphere相比就好用和稳定多了,缺点主要就一个字,贵。国外原厂的价格我感觉一般企业是不太容易接受,如果考虑使用vShphere,也可以考虑使用国内服务器厂商提供的oem版,价格低廉的多。这是在你现有机房做私有云的可选方案,如果你是想从零开始IaaS云,还有一个选项,就是超融合。

    云化你的机房有什么好处呢?

    (1)提高服务器的使用效率。因为云可以在你原有的服务器资源的基础上做出更多的虚拟机(当然这是有上限的),通俗的讲就是一台服务器可以当多台服务器使用。这样就可以避免你机房里运行着好多服务器,但每一台服务器只有个10%左右的资源使用率的情况。

    (2)降低基础设施成本。一家企业如果上一套大一点的系统,很少说一台服务器包打天下的。可能需要配备应用服务器、报表服务器、数据库服务器、开发服务器等等好几个服务器,有些高富帅企业还需要搞个存储外加小机,成本是相当高滴。而将机房云化以后,你可能增加一个计算节点就够了。做同样的事情,需要的服务器少了,购机成本、运维成本还有电费自然就下降了。

    (3)降低运维门槛,提高运维效率。企业机房的运维不像个人管理自家的电脑,要处理的事情复杂的多。包括路由器、交换机、存储阵列的配置还有不同类型服务器的维护,并且这些配置大多需要命令行操作,非专业人士想上手来做这件事还是蛮困难的。而且生产制造企业一般对稳定性、响应速度的要求都很高,在突发事件发生时快速定位错误并解决错误是机房运维人员最大的挑战,每逢节假日经常看到朋友圈搞运维的朋友恶搞自己,给服务器贴符上香,求服务器保佑过节不要宕机。虽是恶搞,但也真是担心系统搞事情假日泡汤。不过使用云平台就好多了,在云平台上配置网络、存储还有创建服务器通过图形化界面就可以操作,上手容易。要是担心关键系统突然挂掉,可以做个镜像,再做一下数据备份,在错误不好定位解决的时候直接把原有环境删掉重建,简单粗暴,但也立竿见影。

    所以,现在不少企业也都开始部署和使用私有的IaaS云。但这么做有短板没?当然有了。比如说:

    (1)云计算的基础是虚拟化技术,虚拟化必然会导致服务器性能的损耗。对于一般的应用系统,这种性能损耗是可以容忍的,所以放到云平台里是没有问题的。但对于那些对CPU,磁盘IO要求高的应用,在生产环境下是否放在云平台中就需要慎重考量了。比如说数据库、大数据分析平台,这些从理论上讲都是可以部署在云平台上的,在实验室里使用也没什么问题,但是在生产环境里,还是推荐直接使用物理服务器。

    (2)直连现场设备困难。在生产现场,如果是物理服务器想直连一台物理设备是很容易的,通过网线就可以连接。如果接口比较特殊,给服务器插一个扩展板卡也能解决。而使用云平台,一般都是通过网络IP地址访问目标设备,所以如果如果目标设备无法通过网络访问就比较麻烦了。

    2、像互联网企业一样高效开发

    构建私有PaaS云可以让企业软件研发和维护更加快捷高效。

    云化你的机房,是构建私有IaaS云,但这只是第一步,帮助企业解决机房运维上的诸多烦恼。但现如今,绝大多数的云厂商都已经不再单纯的提供IaaS云服务了,配套推出的还有PaaS云服务。PaaS云出现的比IaaS云晚,即使现在几家大型的公有云平台厂商,推出PaaS云服务的时间也不长。但好多互联网企业在自己的研发环境中实际都已经应用了PaaS云。并且,业界比较著名的工业互联网平台也都是基于PaaS云搭建的,像Predix,Mindsphere,SAP Cloud无一例外。什么是PaaS云呢,平台即服务。什么平台呢?开发运行平台。

    IaaS云改变了服务器的使用方式,新上一套系统,你可以不用新部署一台新服务器,而是新建一个虚拟机就够了。但你还是必须要创建好虚拟机、配置好运行环境才能部署系统;但使用PaaS云,虚拟机也不用创建了,环境也不用配置了,你所需要做的就是把应用部署到云平台上去,就可以用了。你想使用数据库,你也不必搞个数据库服务器、安装操作系统、安装数据库然后再完成复杂的配置,你所要做的只是在云平台上选择创建一个数据库服务,然后绑定到应用上就可以使用了,这就是PaaS云带来的变化。

    这样的好处是什么?首先,PaaS云替你完成了除了应用本身之外几乎所有的配置管理工作,你所关心的只是管理应用,而对应用的管理也变成了只是一条指令或者一个按钮就可以完成的事情。而像数据库、消息队列等这些基础工具,PaaS云平台也都作为服务提供给你,开箱即用。另外,PaaS云还将系统冗余变成了常规功能。在传统架构中,冗余是很昂贵的,这意味着你需要配备冗余服务器或者设计一套分布式的软件架构。但在PaaS云上,只需一条指令就可以为一个应用创建多个实例,几乎是零成本。最后,PaaS还可以自动实现资源扩展,应用故障自动重启等功能,相当于一个二十四小时不间断服务的运维工程师。

    更进一步,由于PaaS云将底层的运行环境标准化为容器,所以进一步提升了软件开发的自动化程度。可以提升到什么程度,开发人员提交代码就OK了。后面的集成测试、打包、部署、启动、运维PaaS云全部帮你搞定,这就是所谓的DevOps。由于PaaS云的出现,缩短了代码开发到应用部署使用的时间距离,降低了软件开发运维的成本。这就意味着更少的人可以做更多的事情,更短的时间可以做出更加快速的响应。并且,PaaS云平台将分布式架构的开发成本降得极低,所以你可以将大而全的系统分拆成一个个小的服务,即所谓微服务架构。这是一个很大的变化,因为一个单体的大型系统,面临两个问题,一是前期投入成本和风险都很高。一个大型的系统动辄几百万、上千万,但在系统应用之前你是不知道系统好用不好用的,你是要承担着几百万打水飘的风险的。二就是大型系统越到后期修改和维护的成本就越高,牵一发而动全身,因此企业上系统之后后期的维保、升级也都是一笔不小的费用。但微服务的架构就降低了这些问题的影响。因为它是可以迭代生长的,一个几百万的项目,你不必一下子全部投入进去。因为各个模块是松耦合的,如果前期架构规划设计的好,你可以通过版本迭代一点一点的开发实施。开发一点,使用一点,如果不合适,马上调整。这样对于项目实施的甲乙双方都可以节省不小的成本。另外,即使后期业务需求发生了变化,变更修改也可以控制在较小的范围内,不会影响关联模块的稳定性。总之,在PaaS云上开发,你可以做到更简单、更快速、更轻量。

    搭建私有PaaS云平台,同样有两种主流的技术方案可以选择,Cloud Foundry和Kubernetes。它们之间的区别和vSphere与OpenStack之间的区别基本类似。目前著名的公有工业云平台,比如Predix,Mindsphere,SAP Cloud大部分都使用Cloud Foundry;而IaaS云厂商集成的PaaS云平台,比如阿里云、华为云则主推Kubernetes,国内的主要私有云厂商也主推Kubernetes,具体选择那种还要看具体实际情况定。

    但同样的问题,有没有短板呀?当然也有。

    比如,大部分的传统应用是无法运行在PaaS云上的。比如说你想在PaaS云上安装一个Word或者QQ,这是绝对做不到的。而制造企业里的遗留系统,移植到PaaS云上难度就更大了。因为企业的业务系统,往往都很“重”,业务关系复杂,使用的开发技术也不一定能满足PaaS云的技术要求。所以移植遗留系统要面临着技术重构和业务重构的双重问题,代价还是很大的。

    另外,PaaS云应用的开发与传统软件的开发差别很大。特别是制造领域的软件,越接近底层越普遍采用微软的c/s架构的技术体系,比如MFC、WPF、WCF,这类应用都是很难直接移植到PaaS云上的,因此如果想上云,需要寻找替代技术方案重写。

    并且,PaaS云应用之间主要依赖于http协议传输,制造企业现场复杂的各类通信协议也是PaaS云应用无法直接接入的。但现在好多工业互联网平台都提供了解决方案,就是工业网关。比如西门子Mindsphere的基于OPC UA的工业网关还有GE Predix的Predix Machine都是承担这样的角色。

    3、按需租用外部资源

    之前提的都是私有云,而大家了解和讨论更多的应该是公有云平台。像亚马逊、阿里云、腾讯云、百度云、华为云这些基础云平台厂商,提供IaaS+PaaS外加许多带有企业特色的附加增值功能;还有专门的工业互联网云平台,像Predix,Mindsphere,SAP Cloud等,都属于公有PaaS云平台;还有像Salesforce,Face++等提供专门的SaaS云服务。

    这就是云计算可以提供的一项重要价值,即使你没有机房,没有服务器,你仍然可以随时随地按需租用到你需要的各种资源。

    目前在公有云平台上,你可以租用到这样几类服务:

    (1)IaaS云服务:你可以在公有云上得到你能想到的绝大多数的基础设施环境,独立的虚拟机服务器,稍微复杂一些的虚拟网络环境,一个数据库服务集群,一个大数据分析平台、一个PaaS云平台......,按需购买,随购随用,而且不用考虑供电、运维、设备折旧的问题,非常方便。另外还有一类企业比较常用的功能就是云市场,云市场中会提供事先已经配置好的软件系统镜像,比如一个门户网站、一个CRM系统或者一个ERP系统,在你购买之后,IaaS服务商为你提供的实际就是一个虚拟机,不同之处是这个虚拟机是已经装好你需要的软件了,这样就节省了你购买、安装和配置软件的麻烦。

    (2)PaaS云服务:现在绝大多数的IaaS云厂商基本都已经提供在其上部署PaaS云的功能,同时也会提供公有的PaaS云环境。另外还有一些专门的行业PaaS云平台,比如我们所熟知的工业云平台,像Predix,Mindsphere,他们的核心架构基本就是PaaS云+工业网关,工业网关解决数据采集的问题,PaaS云解决数据增值的问题。这些平台提供了之前所描述开发和部署应用的环境。并且提供许多基础功能服务,比如访问控制服务、权限控制服务、关系数据库服务、历史数据库服务等。并且各平台还会提供许多自己的特色服务,比如行业数据分析服务等。使用这一类平台,可以极大的节省软件研发的成本,可以帮助你将精力从安全、性能、基础服务等诸多非功能需求中解放出来,更专注于业务功能的研发。而国内的工业云则在此基础上又作了不少变形,可能会增加个工业产品的网上购物商城、工业研发的众包平台或者其它一些功能,但这些和云计算技术的关系就不太大了。总之,使用工业PaaS云,你可以比较方便的实现接入数据、分析数据和展示数据,这是工业PaaS云的核心功能。

    (3)SaaS云服务:还有一种就是直接以公有云服务的形式租售自己的软件功能的厂商。小到一个具体的功能,比如人脸识别、语音识别,大到一个完整的系统,比如CRM系统、ERP系统。对于不太强调数据隐私并且业务定制化要求不是很高的企业来讲,SaaS系统是个不错的选择。支付少量费用即可使用,开箱即用,按需付费,非常方便。但缺点也比较明显,就是实现的功能范围比较受限制,如果业务功能定制化需求明显,就难以满足要求了。

    使用公有云服务的好处显而易见,省心。云平台厂商为你提供了各种开箱即用的功能服务,需要什么,买来就用,用完就停掉。所以,有了云平台,建系统你可以不用建设数据中心,做数据分析也不是必须做个大数据平台,而且不用考虑设备运维,不用考虑设备折旧,不用考虑环境配置,不用考虑突然宕机,所有这些问题都已经转移到公有云提供商的身上,对于使用者来讲当然就省心不少。至于说省不省钱,我觉得见仁见智吧。如果看初期投入成本,使用公有云平台必然是省钱的,但长期使用的话费用也是不少,这个就看实际情况了。但降低了初期投入风险是一定的,因为如果要是自建机房和系统环境,成本是在项目建设初期就投入进去的,如果不成功也就全赔进去了;使用云平台,是按照使用资源和使用时间慢慢累加的,初期投入成本少,风险自然也少。

    而至于短板,对于制造企业同样显而易见。首先就是网络安全的问题,因为生产是制造企业的命脉,生产运行环境的稳定和安全是企业的底线,所以一般生产制造企业的生产网络都是不与互联网联通的,因为这样可以大幅降低网络黑客破坏和数据安全的风险。但使用云平台就意味着生产环境要接入互联网,虽然现在有专线和VPN技术可以解决企业私有网络与公有互联网络的隔离问题,但实际效果是否能够为企业所接受还有待检验。其次就是数据隐私的问题,对于企业来讲生产数据中隐藏着企业的诸多秘密,企业的工艺信息、产能信息等都蕴含其中,将这些数据发送到互联网,对于企业来讲也是一个需要反复权衡的问题。另外还有就是性能问题,一般在软件系统架构中,网络时延是拉低系统整体性能的重要原因,如果是在局域网环境里,这个问题是可控的,但在互联网环境里,问题则要复杂的多。

    总结一句话,没有最好的技术,只有最适合的技术。云平台,作为一项或者一套技术,必然有其卓越的使用价值,但作为企业或者软件厂商能不能用好则要看你对自身的认知和对这项技术的认知,合理的规划设计可能更为重要。

    展开全文
  • 容器平台建设要考虑场景、技术、系统对接、成本、人员技能等因素,有不小的复杂度。本文从一个最精简容器平台所需考虑的各个方面,结合作者的项目实践,提出供大家参考的建议。 作者:蔡凯 来源: talkwithtrend ...

    原文地址:https://baijiahao.baidu.com/s?id=1601341541732219852&wfr=spider&for=pc
    容器平台的建设要考虑场景、技术、系统对接、成本、人员技能等因素,有不小的复杂度。本文从一个最精简容器平台所需考虑的各个方面,结合作者的项目实践,提出供大家参考的建议。

    作者:蔡凯

    来源: talkwithtrend

    目录

    1 银行建设容器平台的背景

    2 需求分析

    3 业务架构

    4 关键设计

    4.1 资源池管理

    4.2 网络设计

    4.2.1 技术方案选择

    4.2.2 网络拓扑规划

    4.3 镜像仓库

    4.4 应用管理

    4.4.1 应用编排

    4.4.2 生命周期管理

    4.5 安全管理

    4.5.1 对接安全合规体系

    4.5.2 多租户隔离

    4.5.3 应用等级隔离

    4.6 监控日志

    4.6.1 监控

    4.6.2 日志

    5 总结和建议

    1 银行建设容器平台的背景

    随着互联网金融的兴起,互联网企业依托互联网,特别是移动互联网为公众提供越来越多方便快捷、稳定高效的金融类服务,对传统的银行业务带来了很大冲击。作为应对,传统银行也在业务上不断创新,带来对IT基础设施和应用架构方面进行转型升级的要求。例如为了支撑电商促销活动对银行带来的高峰期海量支付请求,某银行很早就对支付渠道相关业务应用进行微服务架构改造,由此带来了容器技术的研究和运用。此银行的多年实践证明,采用容器技术平台很好地支撑了新的业务模式和业务容量。

    基于业务发展的需要,和快速进步的金融科技技术,越来越多的传统银行在思考自身的互联网金融战略、金融云规划等。其中重要内容之一,是希望从技术层面更有效地支持业务创新,如微服务架构、更好的灵活性、扩展性、高可用性、更高效的业务上线效率等,因此跟上云计算技术发展的趋势,建设并推广适合自身的基于容器技术的云平台是关键任务。

    2 需求分析

    银行建设容器平台,不仅需要为基于微服务架构的新业务提供容器化运行和管控平台之外,还必须非常重视满足金融行业严苛的监管和安全要求。这样的定位决定了在银行建设容器平台除了要具备市场上大多数容器平台产品的能力,还应该为银行的特殊监管需求进行定制。

    因此制定银行容器平台的需求时,建议考虑包括的方面有:

    管理大规模容器集群能力,包括:提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。

    为满足金融业务的监管和安全要求,平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志;如果容器平台还对公网提供访问,那么还需要考虑访问链路加密、安全证书等。

    还有一个重要方面是,银行的金融云是一个范围更大的复杂云环境,容器平台通常是这个复杂系统中的一部分,因此容器平台还要遵从银行已有IT技术规范和运维要求,例如可能还需要考虑:

    支持银行自身的应用发布体系、持续集成系统、应用建模规范、高可用管理策略

    对接金融云底层资源池(例如IaaS),遵从云计算资源的统一管理和分配

    对接或改造容器平台的网络,以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信,避免或尽可能减少对银行现有网络管理模式的冲击

    对接统一身份验证、和整个金融云其它系统采用统一的租户定义、角色定义、资源配额定义等

    对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统

    3 业务架构

    基于对容器平台的需求分析,可以用如下的业务架构图描述容器平台应提供的业务能力、以及容器平台在银行可能和周边系统的对接关系:

    各业务模块提供的功能,以及可能需要集成、对接的情况是:

    4 关键设计

    以下讨论业务架构中各个业务模块的关键设计思路。

    4.1 资源池管理

    容器平台资源池管理负责容器运行所需的计算、存储资源申请、分配、容量管理,以及适合的容器网络通信方案。容器网络方案比较复杂,稍后专门论述,这里先探讨关于计算和存储资源的管理。

    对于计算和存储资源的申请、分配、容量管理,可能的两种做法是:

    按照容量预估,预先为容器平台分配预测的计算节点、存储容量的资源,在容器平台中将这些资源注册到容器集群中使用。当需要扩容或删除某些资源时,重复相应的动作。

    对接外部的资源管理和供给系统,通常是IaaS系统或者具备资源供给能力的自动化系统,通过调用外部系统的接口,容器平台按需获取所需的计算和存储资源。

    第一种做法的优势在于系统简单,不需要对接外部资源管理系统,适合技术验证平台,或容量不需要频繁变化的情况。对于生产系统或复杂的测试系统,基本上都应该考虑第二种做法,虽然带来了系统集成的复杂性,但容器平台可以借助外部的IaaS等系统,确保所申请的资源的高可用性,例如可以借助底层IaaS系统的功能,确保容器平台获得的宿主机均匀分布在不同的可用区AZ,这些不同的可用区AZ可能具备不同的供电、网络连接设备等,通常对应于数据中心不同的物理区域、楼层或楼宇,由此减少某一故障导致大部分甚至全部容器宿主机瘫痪的可能性;同时,第二种做法让资源申请和获得无需人工介入,因此能做到容器平台资源的按需自动申请、弹性扩容。

    目前市场上的容器平台开源技术方案,或商业容器平台,大多具备了和IaaS系统的集成能力,或者需要开发的相关集成逻辑也并不复杂,例如只需通过IaaS的接口获取虚拟机,并用自动化任务在虚拟机中执行容器平台添加计算节点的命令,即可完成从资源申请到自动加入容器平台的完整过程。

    4.2 网络设计

    4.2.1 技术方案选择

    在资源管理中,网络的管理是比较复杂的。对于容器平台可能的网络方案,基本上分为以下几类:

    原生NAT方案

    隧道方案(Overlay),代表性的方案有Flannel、Docker Overlay、OVS等

    路由方案,代表性的方案有Calico、MacVlan

    自定义网络方案

    原生NAT方案中,容器借助宿主机端口映射、以及在宿主机上配置的iptables规则,对容器的网络数据包进行NAT转换,再通过宿主机的路由转发实现不同容器间跨主机的网络通信。这种方式的优势是原生支持、简单、容器实例不需要额外消耗骨干网络IP地址、也不会增加在宿主机间传递数据包的长度;但是缺陷也是明显的:

    同一宿主机上不同容器在宿主机上的映射端口必须区分开以避免端口冲突;

    容器迁移到不同宿主机时,很可能需要改变所映射的宿主机端口,控制比较麻烦;

    通过NAT通信使得容器网络数据包在骨干网上使用的不是自身的IP,给防火墙策略带来不便;

    端口映射带来的网络性能损失,笔者自己的环境下测试结果是,使用NAT方式的容器在进行跨宿主机通信是,吞吐率只能达到宿主机间吞吐率的1/3。

    因此,原生的NAT网络比较适合小规模的功能验证和试验环境,网络性能不是重要的考虑因素,测试的场景中也不涉及很多容器迁移、防火墙安全等问题。很显然,在银行正式的测试环境、生产环境下,采用原生NAT方案不足以满足功能、性能和安全监管要求。

    隧道方案,也就是Overlay方案,借助容器宿主机网络,构建出一个对于容器来说三层路由可达虚拟网络。具体做法是通过把容器网络数据包整体封装放进宿主机网络报文,由宿主机网络转发到目标容器所在的宿主机,再由目标容器所在的宿主机对报文进行拆解得到容器网络数据包,交给容器网桥,由容器网桥再转发到目标容器。隧道方案的好处是没有NAT方案的端口冲突问题、不消耗额外的骨干网络IP、与现有网络技术不产生冲突因此灵活性大、通过构建不同的VLAN虚拟网络很容易实现网络隔离、网络性能损失比原生NAT方案小,在满足银行业务功能和安全监管要求的同时,对性能也有一定的照顾。因此隧道(Overlay)方案目前是应用比较多的选择,在技术上的可选择性也最大,方案成熟度也比较高,所以相对其他的方案,隧道方案的实施、定制化、维护的成本比较低。不过事情都有两面,如果选择隧道方案,您还是有一些不可回避问题需要考虑解决:

    如果容器平台中运行业务与其它平台上运行业务需要通信,则需要配置从容器外部访问容器的路由,否则容器的地址从容器平台外部不能直接路由访问。由于容器动态变化和跨主机迁移的特点,配置从外部访问容器的路由是一个比较复杂的问题,不仅需要在外部路由器、宿主机路由表中进行配置,还需要将这些配置动作和容器的启停联动起来,这需要复杂的SDN能力;

    由于容器网络数据包在底层网络上传输时被封装在宿主机网络报文中,因此对普通防火墙来说,容器网络数据包的地址不可见。如果需要对容器数据包进行精确的防火墙规则设置,代价很大,几乎不可行;变通的方法可以考虑把需要进行网络隔离的容器,在启动时指定所在的VLAN,通过不同的VLAN来实现隔离;

    由于容器网络数据包需要被封装在底层宿主机网络报文中,因此会增加底层网络数据包的长度,当您的底层网络也是Overlay网络,或者Overlay的层数较多时,会影响网络数据包承载数据的效率,并且封装和拆解数据包的次数也会显著影响网络的传输效率,对于性能关键的场景,这个问题也需要引起重视。

    路由方案通过路由技术从三层或者二层实现跨主机容器互通,没有NAT,没有Overlay方案需要的数据包封装和拆解,每一个容器具有路由可达的IP地址,且可以做到从容器平台外部路由可达。这种网络方案的好处是性能损失小、外部路由可达、传统的防火墙仍然能正常发挥作用等。但缺点是:

    IP地址消耗大,如果容器数量规模大,特别是采用微服务架构后,大量的容器IP资源被消耗,且可能出现大量IP冲击到路由表里,导致路由效率降低等问题;

    容器平台外部对容器网络中网络实体的变化仍不能感知,例如新的容器创建或发生跨主机迁移时,以Calico方案为例,Felix和BGP client模块可以保证容器网络内的路由策略更新,但由于容器平台外界不能感知容器的变化,外部到此新创建容器的路由则没办法被自动创建,仍然需要额外的路由更新工作补充。

    再来探讨自定义网络方案,本文所提的自定义网络方案泛指针对自身特定需求,而在既有网络技术基础之上进行改造,或者将不同的网络技术进行整合、打通而形成的特殊方案。例如在某银行,容器平台作为整个金融云平台的一部分,在设计容器网络时,需要考虑整个金融云网络管理上的一致性,由此要求容器网络具备和底层宿主机网络相同的网络层级、IP地址规划、子网划分规则,并能够实现容器实例和容器平台以外的直接路由互通,以便能够对容器网络复用既有的SDN控制器管理、防火墙、安全漏扫、网络抓包分析工具等的能力。因此该银行在建设自己容器平台网络时,对接了IAAS的Neutron+SDN进行统一网络管理,工作原理是:

    当容器平台需要为新的租户分配网络资源时,通知Neutron,由Neutron对接的SDN控制器按照预先定义的规则为容器平台分配所需的子网和网络地址空间;

    开发网络驱动,实现CNI接口。当容器平台创建新的容器实例时,网络驱动调用Neutron接口创建port,为容器实例在子网中分配MAC和IP,并把IP绑定到容器网卡(类似nova-compute的工作),然后通知Neutron容器IP配置成功;

    容器平台记录容器的IP地址,作为进行服务注册、服务发现、监控服务的基础;

    Neutron和SDN联动,完成为容器实例设置相关的路由策略、防火墙策略等。

    这种方案的效果即保证网络效率、也能完全融入现有网络管理体系、还能做到完全的SDN联动,但复杂程度高,定制的成本也比较大,且由于完全基于路由而没有Overlay,也存在IP地址消耗比较大的问题。

    需要声明以上只是以某个特定银行的定制方案为例,读者所在的银行和企业可能有自己对容器网络的需求,以及自己的技术考虑,因此自定义网络方案的可能性多种多样,最终实现的能力和代价也差别很大。

    如何选择容器平台的网络技术方案会相当复杂,涉及技术、场景、人员技能、成本等多方面。容器平台网络方案直接关系到平台的容量、效率、实施和运维成本,因此选择需要充分论证,考虑容器平台的定位、规模发展、承载的业务场景、对现有网络的影响、对与集中监控系统、安全合规检查系统集成的影响等,需要认真评估需求、平衡收益和成本。

    4.2.2 网络拓扑规划

    除了技术方案,网络拓扑规划是网络设计的另一个重要方面,不仅涉及网络管理复杂度,还直接关系到安全合规。传统上银行科技部门会为不同安全等级的应用划分不同的网络区,分别提供不同的安全等级保护;也可能会根据运行业务的特点,分为可直接对外提供服务的网络隔离区,和只在内部运行业务处理和数据处理的业务区、数据库区等。在规划容器平台的网络拓扑时,建议保留这些已经成熟并实践多年的网络区域划分方法,保持遵守对安全合规的监管要求。

    同时,根据对容器平台的定位和管理策略,容器平台可能需要在传统的网络拓扑上做相应的扩充,例如:

    如果容器平台是金融云的一部分,网络拓扑必须支持多租户的隔离;

    容器平台中的容器和宿主机都运行在网络中,容器运行应用属于业务,而宿主机运行容器属于资源,建议把容器所在的业务域和宿主机所在的资源域划分到不同的网络区,分别使用不同的管理和访问策略,保留足够的灵活性满足不同的用户需求;

    容器平台自身运行所需的管理节点、镜像仓库、计算节点可以考虑放到不同的网络区,以满足它们各自不同的运行要求。例如镜像仓库可能需要提供对公网的服务,以便用户从公网浏览和管理镜像、管理节点可能需要运行在支持带外管理的网络区等。

    用下图总结以上探讨的银行如何规划容器平台网络拓扑的内容:

    4.3 镜像仓库

    镜像仓库负责存储和发布应用的镜像部署版本,在功能上并不复杂,但由于监管要求和业务的特殊性,银行高度关切生产环境的安全性,都要求用于生产发布的镜像版本必须通过严格的测试阶段,以及严密的安全检查步骤,因此建议对生产环境运行专用的生产镜像仓库;同时,在持续集成越来越普遍的情况下,为了保证开发和测试的方便,我们需要测试镜像仓库。建议生产镜像库和测试镜像库在物理上分开、网络上的连通通过防火墙策略做限制(只开放必须的端口用于镜像同步)。

    在使用规则上,测试镜像仓库允许随时的镜像上传和更新,通常都会对接持续集成系统;而对于生产镜像仓库,为了保证镜像来源的安全、可控,建议限制为只能从测试镜像同步,规定只有在测试镜像仓库中标记为完成测试、经过安全检查的镜像,由有相应权限的账号,在经过必要的审批或者满足一定规则的情况下,从测试镜像仓库中把镜像同步到生产镜像仓库。一旦镜像进入生产镜像仓库,就被当做正式的生产发布版本,接下来就按照银行现有的生产发布和变更流程,在指定的变更窗口,从生产镜像库中拉取镜像进行部署,这样做也很好地满足了银行的安全监管要求。

    下图总结建议的镜像仓库体系、和相关工作流程:

    4.4 应用管理

    应用管理负责运行基于容器镜像的轻量级应用或微服务,提供应用的微服务编排能力、应用全生命周期管理。

    4.4.1 应用编排

    应用编排的目的是为了给容器平台上运行的应用进行建模标准化,描述应用运行的资源需求、部署模式、部署参数、运行时动态规则(弹性伸缩、故障迁移等)。目前开源和商用容器平台都已支持自己的应用编排,例如Kubernetes的yaml文件方式,但对银行来说,可能还存在一些不足:

    对银行的特定需求支持不足,例如银行应用的安全等级、部署的网路区等这些特殊信息的描述;

    不同的容器编排系统、甚至同一编排系统的不同版本,可能存在编排语法不同、不兼容的问题。银行的应用建模是重要的资产,不能允许由于版本升级、技术改造而导致众多应用的建模不兼容。

    因此建议容器平台自定义应用编排规范,如果容器平台定位为银行整体金融云的一部分,那么容器平台的应用编排应兼容整体金融云的应用建模规范,确保金融云上所有应用建模的一致性。

    在用自定义的编排规范对应用进行标准化描述后,需要对底层的容器平台进行能力扩充定制,对应用编排信息进行翻译,变成容器平台可以理解的信息,再根据这些信息对应用进行部署、升级和运行管理。下面的图描述了应用建模、以及使用应用建模进行部署、升级和运行管理的过程。

    4.4.2 生命周期管理

    应用全生命周期管理负责应用的上架、部署、升级、下架、支持运行时动态管理策略,还可支持双活部署、同城灾备切换等金融云高级能力。这部分功能可能需要对接金融云的应用发布、高可用部署和切换模块,提供整个金融云所有应用统一的部署、高可用体验。在上一节应用编排,我们讨论了有关上架、部署、升级、运行管理等,这里来看应用的高可用部署和切换。

    容器平台可以从实例、服务、应用三个层级,分别实现应用的高可用,分别是:

    实例级,即容器故障自动恢复;

    服务级,即服务/微服务的多个实例的跨不同可用区部署;

    应用级,即应用跨数据中心切换。

    从单个运行实例级别,可以采用容器故障自动恢复机制,对发生故障的容器实例进行快速的故障发现、自动迁移和恢复。基本上开源和商业的容器集群管理系统都支持按照用户预定义的规则,进行故障检测和实例恢复。

    从单个服务级别,可以把一个服务或微服务的多个容器运行实例,在跨多个可用区中进行分布部署。在容器平台在进行资源池管理时,借助底层IaaS平台,确保容器宿主机均匀分布在不同的可用区AZ中。当在容器平台部署一个服务或微服务的多个容器实例时,尽量把多个容器实例调度运行在处于不同可用区AZ的宿主机上,这可以借助容器调度策略、以及事先对宿主机加标签以方便识别所在的可用区来配合完成。

    绝大多数情况下,我们都有机会从实例级别、服务级别进行努力,提高应用的高可用性。

    现在越来越多的银行都在建设自己的多地或多中心系统,或者即有本地私有数据中心,也同时具备云端的数据中心。如果您有这样的基础设施,或有相关的建设目标,那么您还可以从更高的级别,即从整个应用的级别来考虑高可用性。做法是在多个数据中心,对应用进行多活、或者主备的部署,把业务流量按照合适的比例分发到不同的数据中心进行交易处理。多数据中心部署的一个关键问题是交易数据的一致性,由于分布式数据库在数据一致性上目前并不成熟,分库分表又会带来额外的关联复杂性,因此大多数银行当前阶段选择起来还很谨慎,而会继续采用单个集中的主数据库,加上位于不同数据中心的备库,之间通过数据库自身的同步技术、加上底层存储系统的快速同步,确保备库和主库的数据保持一致,在进行数据中心切换时,尽可能地减小数据丢失,即减小RPO。采用主备库同步的方案,会对网络低延迟有比较高的要求,这限制了不同数据中心间的最远距离,通常位于同一城市区域、相距数十公里以内是比较可行和普遍的。

    4.5 安全管理

    安全管理是满足行业监管要求必须考虑的问题,是银行建设容器平台的特殊要求。

    安全管理的难点在于涉及面广,包括系统漏洞、病毒威胁、链路加密、攻击防范、系统访问权限上收、操作审计等,此外安全管理面对的安全威胁不断地发展变化,也增加了防范的技术难度和持续的工作量。同时金融云和容器自身的特点,在传统银行安全管理的基础上,还增加了多租户隔离、角色管理、镜像安全检测等新问题。

    4.5.1 对接安全合规体系

    鉴于安全管理的复杂性,如果在容器平台中单独进行安全管理,代价很高;而且安全管理也十分依赖长时间的积累,容器平台单独进行安全管理,也难免在一段时间内出现各种安全问题纰漏。因此建议容器平台在安全管理上直接对接银行现有的安全管理防范体系,充分利用现有的各类安全工具、手段,在现有安全管理手段的基础上,按需增加功能应对容器平台带来的新需求新问题。这应该是见效快、成本低、风险也比较低的方式。

    银行面对严格的行业安全监管要求,现有的安全管理防范体系,包括技术工具、工作流程和指导规范等都已经相当完备,例如系统漏洞扫描、补丁安装、防病毒系统、SSL和证书申请、WAF、统一身份认证和4A访问管理、操作日志审计等。为了利用上这些能力,需要在容器平台设计,特别是网络方案的设计上,仔细考虑如何才能让这些工具和手段对容器平台发挥作用。例如某银行系统漏洞扫描的方式是由运行在网络中的扫描服务,定期地通过向被扫描目标IP发送端口检测报文,分析响应结果来判断是否存在系统漏洞,做出是否需要安装补丁或者关闭被扫描目标相关系统服务等决定。为了让系统漏洞扫描服务能对容器平台正常工作,那么在设计网络方案时,让漏洞扫描服务与容器平台中的容器IP路由可达就是必须要考虑的问题。

    4.5.2 多租户隔离

    如果容器平台作为金融云的一部分,并计划为不同的租户提供服务,那么根据租户对安全的要求,支持不同租户的隔离也是要考虑的内容。

    在之前讨论网络拓扑规划时,建议把不同租户的容器运行在各自不同的虚拟网络VLAN中,并为不同的VLAN设置必须的防火墙规则、关闭相关的路由来保证不同租户的业务在网络上隔离。

    由于容器共享宿主机内核的特点,如果把不同租户的容器运行在同一台宿主机上,租户可能面临来自其他租户容器运行带来的不利影响,例如:

    资源竞争导致的性能下降;

    其他租户容器应用的bug导致的宿主机内核运行异常,进而导致自己租户容器的运行故障;

    潜在的来自其他租户的恶意容器应用,利用共享内核进行攻击和窃密。

    因此,建议容器平台为不同的租户分配各自专属的、不同的资源池,租户只能在属于自己的宿主机上运行自己的容器应用。这虽然导致了资源利用率的降低,但在根本上回避了容器运行依赖共享宿主机内核、隔离性天生不如虚拟机的局限,这和主要基于虚拟机的IaaS平台对多租户隔离的做法不同。

    4.5.3 应用等级隔离

    除了不同租户间的隔离,即使在同一租户下,运行不同安全等级的应用,因为容器共享系统内核的特点,应用也面临其它等级应用的资源争抢、故障影响等问题。另外,不同等级的应用,往往要求不同级别的运行环境高可用性、安全性,因此在同一租户下,也应该把不同等级的应用隔离开,分别部署到各自专属的资源池内。

    下面的图以两个租户、分别有不同的安全等级的应用部署为例,描绘应用的部署状态:

    4.6 监控日志

    4.6.1 监控

    和安全管理类似,监控体系也在银行发展多年,特别是针对生产系统的监控、告警体系,根据自身运维的需要,不断积累、优化了多年,大多已经比较完备;围绕目前的监控体系,也形成了成熟的应急方案、流程,人员技能和经验也多围绕既有生产监控系统进行培训、学习。

    因此,如果容器平台没有特别的需求,在银行的生产环境下,建议将容器平台的监控体系对接目前的集中监控系统,方便运维人员对生产环境的统一监控管理,既有的应急方案、流程、人员技能和经验都可以得到沿用。

    即使容器平台有不同于传统的监控需求,例如:

    容器运行不再关注单个容器实例的增加和消失,而只关注整体服务的可用性;

    新的业务应用通过输出标准化日志,对日志进行分析提取业务性能数据、成功率。

    出现这些不同的需求,也建议用集中监控系统进行展示和告警,只是需要在集中监控系统之外先进行处理,再把处理后的结果对接到集中监控系统。例如,我们不用再在集中监控系统中配置去监控每一个容器实例的IP,而是由容器平台检查服务所需要的容器实例数量是否还在允许的最小值以上,只有当实例数量低于接受的最小值,才给集中监控系统发送告警,其它情况下只需要汇报当前实例数量即可,不在乎实例数量的波动。

    在设计具体的监控时,应把监控进行分类,分别处理。具体可分为:

    应用和服务监控

    资源监控

    平台监控

    应用和服务监控关心业务服务的正确工作状态,这可能需要通过调用平台API、或通过应用日志分析、特定端口响应等方法来判断,需要开发一定的逻辑处理,再把结果对接到集中监控。

    资源监控主要关注每个宿主机、以及计算节点集群的整体资源的使用情况,是否需要增加节点扩容等,这一点基本上传统的监控体系都已经能够做到,方式上以在宿主机上运行agent,进行资源数据收集、然后上报为多。

    平台的监控关注容器平台的控制节点、数据库、提供的服务等是否工作正常,这一点通常开源和商业的容器平台自身就已提供相应的管理控制台。如果不介意界面风格的差异,集中监控系统可以直接嵌入或跳转到容器平台的管理控制台;如果为了一致的监控体验,或者需要进一步的监控和告警定制,就需要开发集成逻辑,通过调用容器平台的API,对获得的数据进行处理、封装,再对接到集中监控系统。

    4.6.2 日志

    在容器平台中,日志大致分为两类:

    环境日志,包括容器运行日志、宿主机容器引擎日志、容器平台管理日志;

    应用日志,指运行在容器中的业务应用在进行业务处理中,对处理过程中的关键结果、状态所进行的记录。

    环境日志有各自固定的输出位置,主要用于出现故障时进行运维排查,和容器平台运行的业务并无直接关系;对于容器平台,更需要关注、处理的是应用日志。因为以容器为载体,以分布式方式运行,无论是运行位置、数量等都会随时发生变化,所以如果不对应用日志做特别处理,应用日志会散布在容器集群的任意节点上。传统的方式,即登录到某一个特定的节点上去查看日志,已经不能适用于容器平台中的应用了。

    我们必须对应用的日志进行集中收集,相关的开源方案选择也比较丰富,例如ELK、Fluentd等,或者直接通过在容器中挂载NFS共享文件系统,把业务运行的日志实时写到共享文件系统中进行集中收集。

    5 总结和建议

    容器平台的建设要考虑场景、技术、系统对接、成本、人员技能等因素,有不小的复杂度。以上各部分从一个最精简容器平台所需考虑的各个方面,结合作者的项目实践,提出供大家参考的建议。

    容器技术发展非常迅速,相关的开源社区和厂商都在努力贡献,新技术层出不穷。同时,微服务框架的功能越来越完备,随着微服务架构思想不断普及,不久的将来会有越来越多的新业务基于微服务架构的形式出现,而容器是微服务架构应用的最理想运行环境,这就意味着容器平台未来的应用场景也是不断改变、进化和越来越丰富的。

    在目前阶段,容器平台的建设是一个不断改进,迭代积累的过程。一开始可能没办法在各个方面都能想得很清楚,不仅在技术方案,更在业务场景、运维方式、安全合规等方面,都需要很多的讨论。但不应该怀疑这个大的趋势,看看Google、Netflix等国际大厂商在容器、微服务上的成功,以及国内的互联网厂商在容器和微服务上不断的投入和积累,我们应该相信这个方向并持续地发展下去。近几年在人民银行年度的银行获奖科技项目中,有关容器技术的项目逐渐增多,也是肯定在这个方向发展的标志。

    技术和市场不会停下来等任何人,如果您想跟上技术的趋势,请在您的组织内给容器平台、微服务推广等工作足够的信任,投入上从小规模试验做起,积累经验后慢慢推广,随着技术和和市场的成熟,更多的微服务架构应用运行在容器平台上,为业务带来服务能力和效率提升,也为您的投入带来应有的回报。

    本文作者:蔡凯,多年IT从业经历,曾服务于IBM、HP、微软等企业,以及全国性股份制商业银行科技部,具有丰富的软件开发、系统架构经验。近年专注于云计算PaaS相关领域,对基于容器、微服务架构等开源技术的架构设计和应用有广泛积累。

    展开全文
  • 新一代数字化企业云平台缘起

    千次阅读 2016-08-22 14:49:19
    互联网化是目标,数字化是手段。从IT角度看,若企业实现了数字化,就带来了企业的互联网化。数字化确实相对抽象一些,但是更好的描述了事物的本质。目前来讲,随着技术进步,数字化是全方位的,万事万物的数字化。

    转载本文需注明出处:EAII企业架构创新研究院,违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复公众号:“EAII企业架构创新研究院”。(微信号:eaworld)


    序:

    互联网化是目标,数字化是手段。从IT角度看,若企业实现了数字化,就带来了企业的互联网化。数字化确实相对抽象一些,但是更好的描述了事物的本质。目前来讲,随着技术进步,数字化是全方位的,万事万物的数字化。



    来看一下一次交通意外事故所产生的数字化过程。




    企业也希望综合运用多种技术支持,将已有能力向社会开放,改善客户联系,在创造社会价值的同时实现企业价值。



    Gartner对数字化的总结,把人(People)、事(Things)、商业(Business)联接起来。



    IT组织是一个服务制造型组织,我们生产产品(软件),用产品(软件)提供服务。产品的生产和服务,必然要适应企业数字化的要求。我们需要更加快速,需要IT的精益运营。而如今IT精益运营面临诸多方面挑战。


    我们说,业务是BiModel的,架构应该是微服务的。


    GARTNER在其大会上曾提出“BiModel"概念。



    这几年,我们一直在强调“大平台,微服务”,新一代平台就是对最佳实践的一种沉淀。



    软件生产的工艺线路很长,全线的改造比较困难。



    以上是业务、架构和过程,过程是以IT精益运营为目标。


    我们认为,IT的精益最好从DevOps开始,比较容易发现问题,也容易解决问题。



    实施IT精益化运营,解决了IT隐性成本和消除技术债务,同时为IT自身的数字化奠定了一定基础。



    (完)


    如需加入云计算架构设计群或加入EAII研究院成为会员请添加微信公众号:elaineyuan928(验证时请备注姓名、公司、职位)。


    关于作者:

    焦烈焱

    EAII-企业架构创新研究院 常务理事

    2001年加入普元信息,现任CTO,全面负责普元信息技术与产品的运营工作,公司技术发展战略的重要决策人。焦烈焱在企业技术架构研究方面有二十余年的经验,长期致力于分布式环境的企业计算、 SOA与云计算技术研究与实践。加入普元信息后组织完成一系列核心产品的研发工作,包括SOA应用平台、以BPM &/ESB为核心的业务集成平台、以复杂事件处理/数据治理/作业调度为核心的大数据平台,期间主持了中国工商银行、中国建设银行等多家大型企业技术平台的规划与研发。著有《SOA中国路线图—实施版》一书。


    关于EAII

    EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,是专注于企业架构与业务创新领域的研究机构,致力于金融、电信、能源与政务等行业领域的企业软件架构优化设计与 创新研究,以及分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等领域的技术研究。


    eaworld项目(微信号:eaworld,长按二维码关注)


    eaworld是EAII的官方微信账号。

    展开全文
  • 容器云究竟能带来哪些业务价值,容器云又有哪些技术路线可以选择,为更好的理解容器和容器云的相关基础问题,社区特别组织了以“银行业容器云平台建设需求分析线上探讨”为主题的线上交流活动,来自多家单位的同事...
  • 管理平台时代充分发挥云计算特性优势大幅提升生产力、应对新增混合多云资源管理问题的平台工具。当前在国外已发展多年并非常成熟,而在国内,一方面企业上云后特别是采纳混合后,IaaS本身提供的服务普遍...
  • 点击“蓝字”关注我们来源 |CHIMA“武汉市健康”打通了全市市、区43家公立医院和204家基层医疗机构以及部分部、省属医院,是武汉市智慧医疗建设的一次提档升级。国家卫生健康委基...
  • 而面向企业级用户的物联网云平台则需要更多考虑到第三方服务平台与其内部系统的融合,例如企业内部的客户管理系统等。除此之外,一些企业有很多的部门和团队,不同的部门和团队负责产品的不同方面,他们需要第三方...
  • 阿里云分布式架构云平台解决方案

    万次阅读 2018-09-01 12:35:14
    遵循集中化、标准化、集成化、可靠化和可扩展化的设计原则,以价值创造为使命,以规范化、一体化、智能化的云平台为支撑,实现信息的透明共享、业务的敏捷协同、管控及时、决策科学为设计目标,选择传统成熟的J2EE、...
  • 构建运营商企业管理平台

    万次阅读 2016-10-08 10:13:01
    目前3类业务分别有各自的管理平台,管理平台建设分散,将导致功能重复及软硬投资重复,严重造成资源浪费。 客户需要构建一套统一管理平台,即企业管理平台,实现公司IT资源的优化整合,并进行统一管控,保障...
  • 某大型企业私有云建设思路解析

    千次阅读 2018-08-30 17:36:12
     在以AWS、Google、阿里等为代表的公有发展的同时,很多大型企业出于数据安全性、系统稳定性、软硬件自主权、对自主可控以及TCO低的考虑,更加倾向于建设企业私有来承载内部业务信息系统的运行。  构建企业...
  • 而面向企业级用户的物联网云平台则需要更多考虑到第三方服务平台与其内部系统的融合,例如企业内部的客户管理系统等。除此之外,一些企业有很多的部门和团队,不同的部门和团队负责产品的不同方面,他们需要第三方...
  • 4大要点搞定企业私有云建设

    千次阅读 2019-02-12 21:15:00
    导读:在以AWS、Google、阿里等为代表的公有发展的同时,很多大型企业出于数据安全性、系统稳定性、软硬件自主权、对自主可控以及TCO低的考虑,更加倾向于建设企业私有...
  • 智能家居云平台设计

    万次阅读 2019-04-09 16:39:07
    智能家居云平台设计 摘要 智能家居是未来家居的发展方向,其利用先进的网络技术、计算机技术和无线通信技术等将家居中的各种电子电气设备连接起来,统一管理、远程监控和资源共享,实现了高效、便利的生活环境。近...
  • 遵循集中化、标准化、集成化、可靠化和可扩展化的设计原则,以价值创造为使命,以规范化、一体化、智能化的云平台为支撑,实现信息的透明共享、业务的敏捷协同、管控及时、决策科学为设计目标,选择传统成熟的J2EE、...
  • 腾讯Docker云平台GaiaStack

    千次阅读 2017-12-14 18:08:29
    GaiaStack是基于kubernetes打造的Docker私有云平台,腾讯内部所有BG都有产品或者服务在GaiaStack上运行。GaiaStack的本质是一个资源管理和调度平台,作为一个云操作系统服务于上层的各类应用。 GaiaStack是基于...
  • 企业私有云建设指南》-导读

    千次阅读 2019-01-23 17:16:45
    内容简介 ...第3章从计算、网络、存储资源池等方面讲解了私有的规划和建设,以及私有云建设的总体原则。 第4~5章分别讲解了基于开源的OpenStack和商业的VMware的私有设计与部署,从计算资源...
  • 云平台令人担忧的安全现状

    千次阅读 2019-08-19 14:43:02
    但是自从上个月国家互联网应急中心(CNCERT)对外发布了《2018年中国互联网网络安全报告》后,行业内开始将担忧的目光频频投到云平台上。 原因是报告里称,云平台已成为网络攻击的重灾区。 报告一出,很多网友都在...
  • 企业级云服务体系中,CMP(Cloud Management Platform,平台)从传统IT系统建设中脱胎而出,因云计算进入主流市场,愈发博得企业客户关注。CMP承载着统一调度传统IT与原生资源与应用、支持业务快速迭代创新...
  • 国内外智慧医疗云平台调研

    万次阅读 2015-07-24 15:13:30
    智慧医疗英文简称WIT120,是最近兴起的专有医疗名词,通过打造健康档案区域医疗信息平台,利用最先进的物联网技术,实现患者与医务人员、医疗机构、医疗设备之间的互动,逐步达到信息化。在不久的将来医疗行业将融入...
  • 遵循集中化、标准化、集成化、可靠化和可扩展化的设计原则,以价值创造为使命,以规范化、一体化、智能化的云平台为支撑,实现信息的透明共享、业务的敏捷协同、管控及时、决策科学为设计目标,选择传统成熟的J2EE、...
  • 云平台常见风险

    千次阅读 2018-12-05 19:27:31
     技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务...
  • 导语:2017年是中国云计算的转折之年,中国企业争相上云的热度空前高涨。2017年4月,工 信 部 信息化和软件服务业司...随着企业的积极上云,新的多样化的需求和特征也随之表现出来,从以往单一的建设私有到转变为...
  • 跨数据中心一体化协同分布式管理平台建设 发表时间:2013/1/28 林强 罗欢 来源:万方数据 关键字:广东电网云计算应用 管理平台 数据中心一体化 信息化调查找茬投稿收藏评论好文推荐打印社区...
  • 在信息化建设方面,深圳联友科技有限公司(以下简称为联友科技)作为东风日产信息化建设的承接者,承担东风日产业务全价值链信息化建设、私有云建设、车联网建设等工作。联友科技是中国领先的汽车行业全价值链信息化...
  • openstack云平台简介

    千次阅读 2018-04-27 11:58:38
    OpenStack是一个由NASA(美国国家航空航天局)和...OpenStack支持几乎所有类型的环境,项目目标是提供实施简单、可大规 模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设...
  • 【摘要】随着技术和社区的成熟,容器、Kubernetes、微服务等新事物不再只是概念,已在很多企业落地并发挥了生产力,对容器和PaaS的需求也从试探性转向规模化推广和纵深探索,建设企业级容器PaaS平台成为必然趋势。...
  • 云平台和架构

    千次阅读 2016-10-31 09:49:27
    亚马逊经过多年的深耕积累,发展成为了行业的标杆企业,甚至是建立了解决方案的标准。 在领域,也存在相应的开源解决方案,在开源的解决方案里有若干公司将解决方案进行开源,而最为著名的有openstack...
  • 基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源,开发人员只需要开发...
  • 工程物资云产品是国内首个工程物资管理云平台,引领物资管理新模式。专注工程物资管理应用与创新,致力于服务企业数字化转型与信息化发展,是中国工程建筑业的SaaS服务领军企业,努力打造行业物联网、互联网应用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 22,596
精华内容 9,038
关键字:

企业云平台建设目标