构建从云原生到多云环境下的能力适配和支撑平台

　　今天准备谈下云原生下的多云适配话题，对于云原生的一些基础概念和关键要素的了解，可以参考我头条上发布的历史文章，在这里就不再单独列出。
　　具体可以参考如下两篇文章：
　　云原生-不是简单的微服务+DevOps+容器云集成
　　传统IT架构转型-从SOA和微服务到云原生解决方案实践
　　对基于云原生解决方案的技术中台产品规划和架构思考
　　而今天准备谈的内容主要是面向多个公有云服务商下的多云适配问题。当然如果你对比阿里云，华为云和腾讯云几大公有云服务厂商，实际各家提供的弹性计算存储服务能力，PaaS层的技术服务能力，包括当前云原生技术相关能力基本都相同，但是各家又都进行了自己个性化的一些差异封装和定制。
　　比如最常说的微服务开发框架，华为有ServiceComb，阿里有HSF，腾讯有自己的Tars微服务框架等。数据库阿里有polarDB，华为有高斯，即使对于同样的开源Mysql数据库，各家在提供数据库即服务能力的时候相关暴露的API接口也有差异。
　　所有这些导致的一个关键问题就是一个企业当迁移和实施到某一个公有云服务商的时候，实际上是很难快速平滑的迁移到另外一个服务商的。这个还仅仅在谈前期系统构建时候的开发框架，技术组件的选型，如果真要迁移还涉及到大量历史数据的迁移同样更加困难。云原生-》公有云服务商面向企业的触达能力
　　对于云原生，谈的最多的是云原生技术，包括了微服务，DevOps，容器云，Serverless无服务器化等。而对于云原生的本质我在前面文章也给出过一个说明，即：
　　云原生本质是应用的开发构建到后期运维全部面向云环境和云基础设施，只有这样最终开发的应用才能够快速的向云端交付，并同时具备高可用，高性能和高扩展能力。
　　那么云原生这个概念究竟谁谈的最多？
　　答案是各大公有云服务商，阿里，华为等大的公有云服务商都在推自己的云原生技术和云原生白皮书。同时也构建了面向云原生的整体解决方案和帮助企业进行IT应用架构转型，迁移的完整指导书和迁移手册。
　　如果从商业角度来看云原生，完全可以理解为云原生是公有云服务商进一步提升将自己的服务能力直接触达到客户的诉求。
　　云服务触达客户能力的三个阶段
　　从上面图可以看到，最早可能只是提供单独的虚拟化资源池，提供弹性计算和弹性存储服务，可以自己购买云主机，购买云主机后安装什么数据库，采用什么开发框架和架构，如何将开发完成的应用部署到云主机，这些云服务商并不关心。
　　到了第二阶段，即出现了基于虚拟机调度的PaaS平台，也就是说客户只需要把应用打包好，就可以直接进行应用托管和部署，包括后续的资源扩展调度。但是这个阶段发展的并不是很好，包括早期很多做Cloudfoundry公有云PaaS平台的公司也逐步退出。
　　其原因一个是原来的部署包太，笨重，托管的虚拟机也笨重，导致这个托管和调度过程慢。其次就是一个应用往往用到大量的技术服务能力和组件，需要这些配合才能够完成完整的业务功能，比如我们常说的消息，缓存等技术服务能力。
　　到了第三阶段，即PaaS发展到了基于容器和Kubernates的轻量化平台，同时数据库，消息，缓存，存储等大量的技术服务能力得到提供。这个时候基本形成了要给完整的PaaS层能力。
　　那么企业客户如何用？如何方便企业客户用？
　　这个时候就需要从最终能力的提供到过程能力的支撑，也就是提供一个完整的支撑过程方便你使用这些能力，方便你进行集成和交付。即常说的敏捷开发过程支撑，微服务开发框架和DevOps持续集成和交付过程支撑。有了这两个支撑过程，在开发应用的时候可以做到更加敏捷，高效，平滑快速的交付的到公有云环境。
　　过程绑定是强耦合
　　为何各大云服务商都不遗余力的推自己的敏捷开发过程和DevOps过程能力支撑，包括推广自己的微服务开发框架，自己的自研数据库，消息中间件等。
　　简单来说就是过程绑定是强耦合，是深度绑定客户的形式。
　　在最早仅仅采用虚拟机的情况下，客户如果不满意某一个云服务商，实际上是可以快速的迁移和切换到另外一家服务商的。但是当你研发过程，持续集成，开发框架等全部都采用的某一个云服务商的产品或技术的时候，这个时候就变成了一种紧耦合，要想做应用迁移不是简单的历史数据迁移和应用重部署，而且还是涉及到整个过程改变，应用开发代码的变更等。
　　所以完整的云原生解决方案虽然方便了企业上云，但是本身也使企业和云服务商之间形成了一种更加紧耦合的关系，这个是云服务商最愿意达到的效果。多云适配-进行解耦
　　前面谈到了对于敏捷研发管理，DevOps如果都采用某一家云服务商的产品，那么实际和该服务商就进行了深度绑定。如果要解耦，最好的办法就是在企业和云服务商之间增加一个适配层。
　　这个面向多云环境的适配能力平台即是基于这个背景产生的。
　　注意适配往往是解决大量重复工作和解决问题的关键方式，可以举一个企业构建电商平台的例子来进一步说明如下：
　　一个企业要开始打通各大电商平台，在各大电商开自营门店。刚开始和和京东对接，京东给了一套自己的接口标准；完成后又和天猫对接，发现又是一套新接口标准。但是不论对接哪个平台，实际上对接的商品，库存，订单等能力完全相同。这个时候就可以考虑通过一个适配层来统一解决这个问题。
　　针对前面分析的云原生下，避免被单一的公有云服务商深度绑定，就可以构建一个统一的混合云管理平台进行适配，如上图。
　　这个适配层本身对接到各大公有云服务商，实现云服务商的能力聚合和适配，通过云服务商开放的API接口进行服务是申请和创建，资源的管理和调度。
　　在统一适配的基础上，基于应用开发全生命周期，构建三方面能力。敏捷开发和过程管理面向DevOps的持续集成和交付统一监控和运维管理
　　同时基于这三方面的能力构建一个统一的能力开放平台和运营门户，再开放给B端企业或C端个人用户使用，并实现相应的自服务流程。
　　在这种场景下，企业不再面对最终的公有云服务商，而是通过混合云管理平台来实现统一的应用开放过程管理，应用集成和交付，后续的应用开发和运维。
　　当前的多云管理平台
　　当前有没有企业在做多云管理平台？
　　在网上搜索下可以看到，已经有不少企业在做多云管理平台或者推出了自己的混合云解决方案。但是这些方案更多的是偏运行期和运维期的管理。
　　比如网上厂家提供的多云管理平台解决或架构如下：
　　这些解决方案更多的还是偏IT资产管理，统一的IT监控，IT运维等方面的内容。而很少有在做企业上云过程管理支撑的整合。即前面谈到的敏捷研发过程管理和DevOps过程支撑等。
　　构建企业上云过程支撑能力平台
　　这是今天谈的一个主题，即构建一个服务于企业上云的过程支撑能力平台并实现多云的适配。这个适配实际上体现在开发，集成，交付的各个关键过程上。
　　开发过程适配：对于开发则体现在开发框架选型，同时屏蔽和适配各个云服务商在同一开发开发框架商的差异。比如采用SpringCLoud微服务框架的时候能够屏蔽各云服务商在框架商的定制差异。
　　其次，能够适配不同厂家的开发框架，比如开发完成的应用既可以适配华为的ServiceComb微服务框架，又可以适配阿里的HSF微服务框架。
　　对于开发过程，还需要提供一个独立于公有云服务商的敏捷开发过程管理平台，实现需求管理，项目管理，任务管理跟踪，缺陷管理等基础功能。
　　持续集成适配：对于持续集成，提供一套统一的基于DevOps标准过程规范的持续集成平台，提供各个公有云都具备提供的编译工具，构建工具和集成工具等。
　　持续集成在进行流水线设计的时候彻底和面向公有云的交付过程解耦。持续集成本身是过程能力，不依赖任何一个公有云厂商的资源或服务。
　　交付过程适配：持续交付适配即同时适配到各个主流的公有云服务商，一个应用在构建测试完成后，用户可以选择朝哪个公有云服务商进行持续交付。
　　同时在交付的基础上增加应用跨云迁移的能力，即一个应用可以在多云管理平台实现从阿里云到华为云的应用迁移。如果做得再完善还可以提供一套数据迁移服务或工具给用户选择使用，以实现应用历史数据得迁移。当然也可以提供跨云服务厂商得底层数据实时同步复制能力。
　　运行态技术服务适配：这块需要适配的内容相当多，可以理解为对各主流的技术服务能力进行适配，包括了数据库适配，缓存适配，消息中间件适配，对象存储适配，日志服务适配等。比如当你使用阿里云的时候采用了阿里的rocketMQ，而华为云是没有这个技术服务能力的，那么就需要多云平台提供这个技术服务并托管到华为云再提供能力。
　　监控运维适配：这个即是当前多云管理平台做得比较多的，你可以理解为将各个云服务商提供的后台云管理平台进行了整合，即你只需要再要给统一的管理平台对云资源，云服务进行管理和监控。多云适配-私有云和公有云桥梁
　　一个传统企业在进行数字化转型，进行传统IT架构微服务架构改造和上云迁移时候，本身是一个逐步迁移演进的过程。即企业内部的IT应用常时间会处于一个企业内部私有云和外部公有云同时使用，同时提供服务能力的状态。
　　那么多云适配平台就可以起到公有云和私有云间的适配桥梁。
　　可以举例一些场景来理解下这个适配。
　　场景1：企业应用在年结等峰值进行资源扩展
　　一个企业，原来内部私有云资源能力可以满足日常业务需求，但是到了年结期间业务并发量剧增，这个时候已有内部资源很难满足。那么是否可以将应用自动化的迁移部署到公有云环境，形成一个新的集群和能力提供点来分担应用负荷？
　　当年结结束后，本身又可以快速的收缩资源的使用节约成本。
　　场景2：研发测试在私有云，生产在公有云
　　企业在新应用构建和开发的时候，研发测试可以在自己内部的私有云环境，资源需求量也不多，同时内部私有云环境往往又更高的网络带宽。而在研发测试完成后，最终交付则部署到公有云环境，提供更好的安全性和弹性伸缩能力。
　　那么在一个应用就必须同时适配企业内部私有云和外部公有云，实现持续集成和动态交付。包括企业用户在应用测试通过后，可以一键交付到外部公有云环境。
　　场景3：业务网关和数据网关
　　当一个企业内部IT应用和公有云应用共存的时候，这两类应用之间本身还需要进行业务交互和数据交互。因此一个多云适配平台还需要提供业务服务网关和数据交换集成网关能力。
　　比如外部应用可以调用内部应用提供的API接口服务，同时外部应用产生的数据可以实时采集回内部应用中进行进一步的分析。后续进一步思考
　　前面对面向多个公有云服务商下的多云适配能力平台进行了初步构思，后续需要进一步展开的还是多云适配实现的具体技术和功能细节。
　　对于多云适配平台，各大云服务商一般不会去做，而是需要单独的第三方软件或服务能力提供商来进行建设，也正因为如此，多云适配会是一个很好的切入云原生解决方案市场的机会点。