对企业IT系统全部迁移公有云的演进路线思考(200918)

今天重点是整理和思考下对企业IT系统全部上云的一些关键点思考，当然IT全部上云本身也是云原生解决方案要解决的一个重点内容。对于企业遗留系统迁移上云是一个相当复杂的主题，一篇文章肯定无法讲清楚，包括我自己也需要在整理过程中进行相关内容学习和细化。

因此对于这个主题本身我也会逐步整理多篇文章来分享。

云原生概述

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。

Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。

在一般用法中，“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。 这意味着应用程序位于云中，而不是传统数据中心。

CNCF给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序，并作为应用程序部署的独立单元，实现高水平资源隔离
• 动态管理：通过集中式的编排调度系统来动态的管理和调度
• 面向微服务：明确服务间的依赖，互相解耦。

实际上我们看到对于完整的DevOps是包括了持续交付方面的内容的。因此对于云原生的概念完全和我前面经常谈到的微服务，容器化PaaS和DevOps相吻合。

即云原生 = 微服务+ DevOps + 容器化PaaS

在传统的PaaS平台阶段，我们看到更多的是实现中间件资源池，应用托管和中间件资源的自动调度。但是对于业务系统来讲可能仍然是大的单体应用，同时每个业务系统本身还有比较重的底层技术平台，依托于一个技术开发框架。

而在这种情况下业务系统要实现敏捷，高效的到云环境的交付并不现实。

也正是这个原因，在云原生下更加强调两点内容：

• 其一是原有的业务系统要进一步微服务化拆分，变成更加细粒度的组件化单元
• 其二是业务系统中和业务无关的内容要 全部下沉到平台层构建

当满足以上两点后我们构建业务系统更加容易实现面向公有云服务环境的持续集成和交付能力。其中核心底层技术是容器化PaaS，小而灵活，而且具备编排属性和能力，传统应用架构通过微服务化后变得足够小而自治，方便进行敏捷开发和迭代，快速的交付和响应，同时也方便部署和托管到容器中。

软件因云而生，即云原生，需要的就是上面三者的密切配合来完成。

综上所述，我们可以进一步将企业IT系统架构或者说平台+应用的分层架构演进体系分为三个阶段来理解。

最初可能仅仅是实现虚拟化资源池，实现IaaS平台层统一。在这个时候业务系统构建仍然是烟囱式的构建模式，每个业务系统底层有比较重的中间件和平台，业务系统是一个大的单体应用，内部各个业务模块仍然没有完全解耦。

第二阶段即我们常说的私有云PaaS平台建设阶段，在这个阶段进一步实现中间件资源池，也会做类似4A，流程引擎平台的整合和统一。业务系统逐步朝组件化开发过渡和解耦，但是业务系统内部仍然存在技术平台和技术支撑。

第三阶段实际上有几个大的变化，首先就是PaaS云平台从传统比较重的类似Cloudfoundry，Cloudify已经过渡到更加轻量高效的容器云平台，同时大量技术服务能力共性化建设。其次是业务系统彻底实现微服务架构化和解耦。那么在上层微服务设计，开发，部署和交付过程如何与底层的容器云平台，技术服务平台进一步协同？这里面就是我们常说的DevOps过程支撑平台。

而容器云+微服务+DevOps持续交付刚好就是当前主流云原生的核心。

从资源到服务-关键思维的两次转变

当我们谈到云计算或云原生的时候，一定要转变一个关键思想，就是从拥有资源到享受服务。那么如何理解资源和服务，简单来说如下：

资源本身是一个能够看得见实体或虚拟实体单元，服务则是一种能力价值体现

对于消费者或用户来讲，一定要搞清楚你需要得服务还是资源，你拥有了资源当然你能够获得资源提供得服务，但是你本质可能仅仅是需要服务而已。

• 比如我想吃鸡蛋，我并不需要一定要去养一只鸡。
• 我需要部署我的IT系统，我并不需要一定要买一台服务器回家。

即我们大部分时候都仅仅需要的是资源提供的服务能力，而不是真正需要拥有这个资源。对应到IT系统建设，很多人感觉就是我必须买一台服务器回家，这个资产是我的，心里才放心。但是却没有想到服务器购买回来后涉及到机房，运维，用电等一系列其它成本投入。

第一阶段-购买云主机和存储

对于大部分企业来说，上云的第一阶段都是购买大量的云主机和云存储，然后迁移和部署自己的数据库和应用程序。但是我们要意识到在这个阶段虚拟机仍然是资源，只是从物理资源变为了逻辑资源。

当你仅仅购买资源的时候，你会看到：对于你在虚拟资源上部署的数据库或应用，后续的运维监控，后续的资源扩展，应用安全，冗余和可靠性等很多问题仍然需要你自己去解决。

简单来说，就有点类似于装修房子一样，我本来可以提供交钥匙的全套服务能力，但是你却要自己买原材料自己去装修和组装。

第二阶段-真正从IaaS层资源到PaaS层服务

理解这点，是我们全面切换上云的一个关键内容。即在云原生状态下的上云，更多的要从对资源层的关注转变到对服务层的关注。我们可以举例说明如下：

• 你原来是购买虚拟机装HA数据库，而新思路是直接购买数据库服务
• 你原来是买虚拟机搭建集群，新思路是直接购买容器云集群服务能力进行托管部署

也就是说转变到服务阶段后，云平台提供的一切能力都是服务，你不要再去关心底层的物理机，虚拟化资源，而是仅仅关注服务即可。

云平台运营方来保障提供服务能力的可靠性，安全和弹性扩展能力。

传统IT系统迁移上云方式和问题

在这里，我们将通过购买云主机，云存储和网络带宽的方式，自己搭建数据库和应用环境，并将企业内部IT系统迁移上云环境统称为传统方式。在这种方式下基本仍然停留在虚拟资源使用和消费上，最多也就是会再购买些类似集群，CDN内容分发服务等。

前提建议-去IOE

对于传统IT系统的上云，建议前提首先去IOE，即自己IT系统的构建不再使用类似Oracle， Weblogic，SAN存储等商用的数据库和存储。而是基于去IOE的思路进行开源化的改造，比如我们常说的Mysql数据库，Tomcat容器等。如果用商用数据库，后续涉及到的License和费用问题都很难去解决。

包括现在我们看阿里云提供的数据库服务，商用的数据库只保留有Sql Server数据库，其它全部都是开源数据库或阿里自研的数据库服务。

云环境的高可靠和高扩展问题

在这种场景下，整体云环境的IT基础架构和部署架构由你自己去设计，你需要去考虑整个架构的冗余和高可靠性。同时在这种场景下，整个基础架构不具备自动扩展能力，当你发现应用无法满足业务需求的时候，往往都是需要你手工申请新的计算和存储资源，然后进行扩展配置。

比如你采用Mysql数据库

你一开始就要规划是否采用读写分离集群，还是双主+读写分离集群。同时要确认可以在资源负荷大的时候，申请虚拟机资源实现读集群节点的自动化扩展。这些都需要你提前考虑清楚，否则最终切换上云环境后，你的整个DB将没有集群扩展能力。

同时对于数据库数据的安全和备份你也需要考虑，对于关键数据你自己还需要进行额外备份，防止数据丢失，也确保关键数据能够及时的恢复。

再比如你的中间件集群

你也需要考虑清楚你的集群部署方式，是否需要配置独立的集群管理节点，还是说每台服务器都自己手工去部署，然后再配置到类似Nginix的集群服务上。这些内容也得提前规划好，在你只购买虚拟云主机的情况云服务商不会去帮你考虑这些问题，而是需要你自己去解决。

自然，当集群性能无法支撑高并发时候，你也只能是手工再申请资源，配置集群节点来进行扩展，而很难做到资源自动化的弹性扩展。

各类技术服务组件的提前规划和部署

如果你自己的应用系统使用到类似消息中间件，流程引擎平台，各类开源技术组件，自己定制的技术组件服务等，这些都需要提前规划好并完成部署。在整个应用迁移前，你需要确保这些技术服务组件都已经独立部署好，并且能够单元测试通过。

强烈建议所有的技术类组件在独立部署完成后都需要进行全测试场景的单元测试和验证，以确保技术组件部署的完整性，同时也有益于在技术组件部署完成后出现问题的排查。

当然整个IT架构里面，技术组件你自己去部署和管理，那么对于单个技术组件本身的高可靠性，可扩展能力，通用需要你自己去规划和考虑清楚。

从资源订购到服务订购

即使你的IT系统还没有进行微服务架构和面向云原生的改造，我们仍然不建议你完全采用购买云主机的方式切换上云，即在这种模式下你后续要过渡到云原生阶段同样会相当大的工作量。

从通用资源到个性化服务

对于类似亚马逊，阿里云，华为云，腾讯云等各个大的云服务商可以看到。

对于云主机和云存储层面，各家的产品和服务都大同小异，基本都是标准化的云主机产品。也正是这个原因你可以看到，如果你原来应用部署在阿里云，如果你阿里云服务不满意，你可以很容易快速的切换到华为云。由于底层都是标准的虚拟机，仅仅是应用和数据迁移的工作量，对于应用程序本身并不需要做修改。

而当从资源层到服务层后，你可以看到各家公有云服务商提供出来的中间件，技术服务能力就出现了大的差异，即使阿里和华为云都提供MySql的数据库服务能力，本身在服务能力的底层构建模式，扩展性，包括数据库服务的接口，DB连接的使用上都可能存在个性化的差异。

特别是阿里云各类技术服务，经常会出现各种个性化的封装和定制。

因此，如果你整体上云规划已经认定了某一个云服务商提供的服务能力，那么你不需要考虑后续云平台的替换问题。否则你在实施和订购服务的时候，必须考虑到云服务兼容性。

思考点1：考虑数据库和存储的服务化

在遗留IT系统迁移上云的时候，我们优先需要考虑数据库的服务化。

如果你原来用的是Mysql数据库，你可以考虑采用阿里云的Mysql云数据库，这个数据库本身也是一种双Master+读写分离集群结构。后续很容易去做读节点的能力扩展和自动分配。

如果你原来采用的Oracle数据库，那么在云化的过程中，我们实际是建议将数据库进行迁移，你可以迁移到Mysql数据库，也可以迁移到阿里云的PolarDB数据库。

对于PolarDB数据库可以看到，对于Oracle引擎版本基本可以实现完全兼容Oracle数据库。

对于Polar DB实现了计算存储分离，有点类似于Oracle RAC集群数据库，但是其写节点只有一个节点，其它都是读节点。由于实现共享存储，因此其存储的弹性扩展能力足够强。当然整个PolarDB的性能根据官方数据也相当强。

因此如果采用Polar DB数据库服务，对于数据库集群的高可靠性，扩展，存储扩展等各类问题你都不需要考虑，都由云服务商帮你解决。对你来说你就是获取和实例化一个数据库连接，并去使用数据库即可。

当然除了结构化数据库外，本身各个公有云还提供其它各类数据库和缓存服务能力。

类似Redis库服务，时序数据库服务

也还有各类存储服务能力，从原来购买单纯的存储空间，可以变化为直接采用分布式对象存储接口等。这些也完全可以根据实际的业务场景和需求进行服务订购和消费。

比如Redis缓存库，你自己要去部署一个高冗余和高可靠的分布式集群仍然是很麻烦的事情，而现在你可以直接购买和订购数据库服务能力，其它都公有云平台帮你搞定。

思考点2：考虑关键中间件技术能力的服务化

其次我们可以考虑将我们用到的最常见的开源技术组件服务化，即优先采用公有云平台提供的服务能力，而部署自己再去部署这种技术中间件。

对于这块我认为最重要的仍然是消息队列，缓存，日志，短信通知，文件等几个关键技术服务能力。这几个能力也是我们最常使用的能力。

包括消息队列我们也可以看到，类似阿里云往往提供RocketMQ, Kafka, MQTT等各种消息中间件，你需要基于你实际应用场景去选择。中间件技术能力个人理解不需要完全去服务化，将关键的几个核心技术组件服务化即可。

什么是关键技术组件？至少应该满足两点

• 影响到整个业务系统核心业务流程执行和运转的组件
• 对性能需求高，本身存在高可靠，弹性扩展需求的技术组件服务

对于满足以上两个特点的技术组件服务我们就需要优先考虑服务化订购。

从服务订购到完全适配云原生交付

这个实际上是最理想的方式。但是这个有一个前提，就是企业的IT架构完全微服务化，同时各个微服务能够实现容器化部署。比如你企业新开发的一个业务系统，已经采用微服务开发框架和架构，同时已经通过jekins在做持续集成和容器的自动部署。那么在这种场景下是最理想的云原生交付前期准备。

在这种场景下，实际我们需要做出三个方面的工作。

其一：开发框架和环境

为了实现持续集成和持续交付，我们需要实现整个研发全生命周期的过程管控能力，其中就涉及到开发态的支撑能力，从开发态到运行态的交付能力。

在这个过程中你需要考虑微服务开发框架和环境。

当然你可以使用类似SpringCloud的微服务整体解决方案，但是这种解决方案里面就涉及到整个SpingCloud基础架构，网关，注册中心等的部署和管理，这些事情需要你自己去做。

你也可以使用公有云服务商提供的开发框架，微服务治理框架，使用这个的好处就是你只需要关注微服务模块的开发即可，其它都不用太关心，公有云基础环境已经具备。

简单来说就是：原来你需要关注整个SpringCLoud，现在你只需要关注SpringBoot开发微服务模块。

其二：容器云集群服务

注意，在新微服务架构下我们直接使用容器云集群服务能力，不再是单独去订购虚拟机去部署容器，而是直接实际容器集群服务。

在使用容器集群服务的时候，你可以配置你自己的调度规则，资源动态扩展规则。

对于容器云集群的使用，你可以将自己打包好的部署包通过管理界面进行自动化部署，也可以通过DevOps进行自动化集成和部署交付。

其关键点都在于整个应用集群基础设施架构你不用再关心了，你仅仅是使用服务。

其三：DevOps过程支撑能力

当前的各大公有云平台，类似阿里云，华为云本身都提供了完整的DevOps过程支撑能力。也就是说你整个研发过程管理，需求，打包构建整个过程全部上云。通过使用DevOps过程服务，自然你的应用可以自动实现持续交付能力。

那么你也可以看到通过DevOps虽然实现了自动化的持续交付，但是你跟公有云服务商提供的服务能力往往绑定的更加紧密，或者说你更难脱离你当初选定的公有云服务商。

这也是当前为何各大公有云都大力推自己的敏捷研发管理平台和DevOps原因。

如果做到以上三点，我们看基本就实现了一个完整的向公有云环境进行交付和迁移的能力。这种持续敏捷的向公有云交付才是真正云原生的核心。

而对于我们前面谈到微服务，容器，DevOps都是为了达成这个目标服务。

详细参考：阿里企业上云最佳实践

https://www.aliyun.com/acts/best-practice/index

为何要走到云原生持续交付这个层面？

最后再谈下为何要演进到云原生持续交付这个层面。前面实际上我已经谈到，只有将资源转变到服务层，你才能够充分享受到云平台带来的类似安全，可靠性，扩展，备份容灾等各种增值服务能力，这些能力往往才是你自己私有云很难去解决的能力，特别是类似我们原来经常谈到的异地容灾部署能力。

其次，真正实现了敏捷化的持续交付，实现了开发态到运行态的完整无缝集成。这个已经不仅仅是通过自动化节约成本的问题，而是真正满足业务用户敏捷需求的目标。

最后，你使用的是云平台提供的各种服务，那么自然你能够进一步享受为服务本身提供的运维监控和治理能力，也就是说对于运维，监控这些后续事项云平台也会帮你解决掉，不需要你自己去构建。比如你自己去构建一个业务系统，你可能还通过ELK去做日志分析和监控，而当你转变为采用云平台服务化，这些功能也自然具备。