今天的重点是整理思考企业全部IT系统上云的一些关键点。 当然，将所有IT系统迁移到云端本身也是云原生解决方案要解决的关键内容。 将企业遗留系统迁移到云端是一个非常复杂的主题，不可能在一篇文章中解释清楚。 甚至我在整理的过程中也需要对相关内容进行研究和提炼。

因此，我会逐步整理多篇文章来分享这个话题本身。

云原生概述

转化为云原生是Matt提出的一个概念。 它是一系列思想的集合，包括持续交付（）、微服务（）、敏捷基础设施（）、康威定律（Law）等，并根据业务能力对公司进行重组。

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

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

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

事实上，我们看到完整的版本包含了持续交付的内容。 所以，云原生的概念和我之前经常讲的微服务、容器化PaaS是完全一致的。

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

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

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

正是因为这个原因，云原生魔石模式更加强调两点：

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

软件诞生于云，即云原生，需要以上三者的密切配合才能完成。

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

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

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

第三阶段其实有几个比较大的变化。 首先是PaaS云平台从传统的重型平台转变为更加轻量级、高效的容器云平台，同时共建了大量的技术服务能力。 其次，业务系统完全架构化，与微服务解耦。 那么上层微服务设计、开发、部署和交付流程如何与底层容器云平台和技术服务平台进一步协同？ 这就是我们常说的流程支撑平台。

容器云+微服务+持续交付正是当前主流云原生的核心。

从资源到服务——关键思维的两个转变

图片来源网络

当我们谈论云计算或者云原生时，我们必须改变一个关键的观念，那就是从拥有资源到享受服务。 那么如何理解资源和服务简单如下：

对于消费者或者用户来说，你必须明确自己是否需要服务或者资源。 如果你有资源，当然可以获得资源提供的服务，但本质上你可能只是需要服务。

也就是说，很多时候我们只需要资源提供的服务能力，但并不真正需要拥有该资源。 说到IT系统建设，很多人觉得我得买一台服务器带回家。 这个资产是我的，所以我安心。 但没想到购买服务器后，会涉及到机房、运维、用电等一系列其他成本。

第 1 阶段 - 购买云托管和存储

对于大多数企业来说，上云的第一阶段就是购买大量的云主机和云存储，然后迁移部署自己的数据库和应用程序。

但我们需要认识到，现阶段虚拟机仍然是一种资源，只不过它从物理资源变成了逻辑资源。

当您刚刚购买资源时，您会看到：

对于你部署在虚拟资源上的数据库或者应用来说，后续的运维监控、后续的资源扩展、应用的安全性、冗余性和可靠性等很多问题仍然需要你自己解决。

简单来说，这有点像装修房子。 我本可以提供全套交钥匙服务，但你必须自己购买原材料、自己装饰和组装。

第二阶段——真正从IaaS层资源转向PaaS层服务

了解这一点是我们全面转向云的关键部分。 也就是说，云原生状态上云时，更多的注意力必须从资源层转移到服务层。

我们可以举个例子如下：

也就是说，过渡到服务阶段后，云平台提供的所有能力都是服务。 您不再需要关心底层物理机和虚拟化资源，只关注服务。

云平台运营商保证服务能力的可靠性、安全性和弹性扩展能力。

传统IT系统上云的方法及问题

在这里，我们将通过购买云主机、云存储和网络带宽的方式搭建自己的数据库和应用环境，并以传统的方式将公司内部的IT系统迁移到云环境中。 这样一来，基本上还是停留在虚拟资源的使用和消耗上。 顶多会购买一些类似的集群、CDN内容分发服务等。

早期建议——去IOE

对于传统IT系统向云的迁移，建议前期先走IOE，即自己搭建的IT系统不再使用商业数据库和存储如SAN存储等。 而是我们基于消除IOE的思想进行开源改造，比如我们常说的数据库、容器等。

如果使用商业数据库，将很难解决后续涉及到的成本和成本问题。

包括现在我们看阿里云提供的数据库服务，商业数据库只包括Sql数据库，其他都是开源数据库或者阿里巴巴自研的数据库服务。

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

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

例如，如果您使用数据库

您需要从一开始就规划好是使用读写分离集群还是双主+读写分离集群。 同时需要确认，当资源负载较重时，可以申请虚拟机资源，实现读集群节点的自动扩容。 你需要提前考虑到这些，否则你的整个DB最终切换到云环境后将不具备集群扩展能力。

同时，还需要考虑数据库数据的安全性和备份。 您还需要对关键数据进行额外的备份，防止数据丢失，保证关键数据能够及时恢复。

另一个例子是您的中间件集群。

您还需要考虑您的集群部署方式，是否需要配置独立的集群管理节点，或者是否需要手动部署每台服务器，然后将其配置为类似的集群服务。 这些内容也必须提前规划好。 当你只购买虚拟云主机时，云服务商不会帮你考虑这些问题，而是需要你自己解决。

当然，当集群性能无法支持高并发时，只能手动申请资源并配置集群节点进行扩容，但很难实现资源的自动弹性扩容。

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

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

强烈建议所有技术组件在独立部署后都需要进行单元测试，并在全测试场景中进行验证，以保证技术组件部署的完整性，并便于技术组件部署后问题的排查。

当然，在整个IT架构中，技术组件都是你自己部署和管理的，所以通常需要规划和考虑清楚单个技术组件本身的高可靠性和可扩展性。

从资源排序到服务排序

即使您的IT系统尚未进行微服务架构和云原生改造，我们仍然不建议您通过购买云主机的方式完全转向云。 也就是说，在这种模式下，未来你也必须过渡到云原生阶段。 工作量相当大。

从通用资源到个性化服务

亚马逊、阿里云、华为云、腾讯云等主要云服务商都可以看到这一点。

至于云主机和云存储层面，各家公司的产品和服务都差不多，基本都是标准化的云主机产品。 正是因为这个原因，你可以看到，如果你原来的应用部署在阿里云上，如果你对阿里云的服务不满意，你可以轻松快速地切换到华为云。 由于底层是标准的虚拟机，因此只是应用程序和数据迁移的工作量，不需要对应用程序本身进行修改。

而当从资源层到服务层时

可以看到，各个公有云服务商提供的中间件的技术服务能力存在很大差异。 即便是阿里巴巴和华为云提供的数据库服务能力，也是基于服务能力的底层构建模型和可扩展性。 数据库服务接口和DB连接的使用可能存在个性化差异。

特别是阿里云的各种技术服务往往都带有各种个性化的套餐和定制。

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

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

在将遗留IT系统迁移到云端时，我们首先需要考虑面向服务的数据库。

如果你原本使用数据库，可以考虑使用阿里云的云数据库。 这个数据库本身也是双元+读写分离的集群结构。 未来易于扩展和自动分配读节点能力。

如果您原来使用的是数据库，我们实际上建议您在云化过程中迁移数据库。 您可以迁移到数据库，也可以迁移到阿里云数据库。

从数据库中可以看到，引擎版本基本上可以与数据库完全兼容。

DB实现了计算与存储分离，有点类似于RAC集群数据库，但只有一个写节点，其他都是读节点。 由于共享存储的实现，其存储弹性扩展能力足够强。 当然，从官方数据来看，整体表现还是相当强劲的。

因此，如果您使用DB数据库服务，则无需考虑数据库集群的高可靠、扩展、存储扩展等各种问题，云服务商会帮你解决。 对于您来说，您只需要获取并实例化一个数据库连接并使用该数据库。

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

类似于图书馆服务和时间序列数据库服务

当然，还有各种存储服务能力。 从原来购买简单的存储空间，改为直接使用分布式对象存储接口。 也可以根据实际业务场景和需求进行服务订购和消费。

比如缓存库，你自己部署一个高冗余、高可靠的分布式集群还是很麻烦的。 但现在你可以直接购买订购数据库服务能力，公有云平台会帮你搞定。

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

其次，我们可以考虑服务于我们使用的最常见的开源技术组件，即优先考虑公有云平台提供的服务能力，自己部署这个技术中间件。

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

包括消息队列，我们​​还可以看到阿里云经常提供各种消息中间件如MQTT等。 您需要根据自己的实际应用场景进行选择。 我个人对中间件技术能力的理解是不需要完全去服务化。 只需要服务化为几个关键核心技术组件即可。

关键技术有哪些？至少要满足两点

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

从服务订阅到完全适应的云原生交付

云原生开源生态系统

这其实是最理想的方式。 但这有一个前提，那就是企业的IT架构完全基于微服务化，每个微服务都可以部署在容器中。 例如，您公司新开发的一个业务系统采用了微服务开发框架和架构，并且一直在进行容器的持续集成和自动化部署。 所以在这种场景下，是云原生交付最理想的前期准备。

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

一：开发框架及环境

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

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

当然，你可以使用类似的整体微服务解决方案，但是这个解决方案涉及到整个基础设施、网关、注册中心等的部署和管理，这些事情都需要你自己来做。

您还可以使用公有云服务商提供的开发框架和微服务治理框架。 使用这个的好处是你只需要专注于微服务模块的开发，不需要过多关心其他的事情。 基础公有云环境已经具备。

简单来说就是：

原来你需要专注于整体，现在你只需要专注于开发微服务模块。

第二：容器云集群服务

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

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

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

关键点是你不再需要关心整个应用集群基础设施，你只需要使用服务即可。

第三：工艺支撑能力

目前各大公有云平台，与阿里云、华为云本身类似，都提供了完整的流程支撑能力。 也就是说，你的整个研发流程管理、需求、打包、构建都搬到了云端。 通过使用流程服务，您的应用程序可以自动实现持续交付功能。

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

这也是目前各大公有云都在大力推广自己的敏捷研发管理平台的原因。

如果做到了以上三点，我们认为我们就基本具备了完整的交付和迁移到公有云环境的能力。 这种持续、敏捷地交付到公有云是真正的云原生的核心。

至于我们前面讲的微服务和容器，都是为了实现这个目标的服务。

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

为什么要走到云原生持续交付的层面？

最后我们来说说为什么需要进化到云原生持续交付的水平。 其实我之前也提到过，只有将资源转移到服务层，才能充分享受云平台带来的安全、可靠、扩展、备份、容灾等各种增值服务能力。 这些能力往往是自己的私有云很难解决的能力，尤其是我们之前经常谈到的异地容灾部署能力。

其次，真正实现了敏捷持续交付以及从开发状态到运营状态的完整无缝集成。 这不再只是通过自动化节省成本的问题，而是真正满足业务用户敏捷需求的目标。

最后，如果你正在使用云平台提供的各种服务，那么自然可以进一步享受服务本身提供的运维监控和治理能力。 也就是说，对于运维来说，云平台也会帮你监控这些后续的事情。 已删除，无需自己构建。 比如你自己搭建一个业务系统，也可能会使用ELK进行日志分析和监控。 当你切换到云平台服务后，这些功能自然就可用了。

注：个人技术视频目前仅在哔哩哔哩和今日头条账号更新。 欢迎大家关注我的同名今日头条和哔哩哔哩账号。 目前技术直播和问答仅在B站进行，欢迎关注。