作者 | 愚奇

 

今天，云和云计算技术已经被企业广泛所接受，关于云、云计算、云原生都有非常多的话题，但是我比较想讨论的是在所有云当中真正的主角，就是我们的应用。

 

因为当企业应用上云后，这些应用的高可用能力有可能提升了一部分，但仍存有许多问题；而当我们探讨上云后这些应用的运维效率，却未必有很大的提升，因为所有的运维都是基于基础设施进行的，而云计算是一个比较大的基础设施的改变；如果我们再问，上云后整个应用的开发速度是不是得到了极大的提升，这个时候很多人都要说，并不。

 

因此，今天主要探讨的就是如何利用云原生相关的技术帮助我们的应用去做优化，从传统应用转变成现代化应用。

 

非典型的典型——云上众生相

 

我们先采取一个从个体再到整体的形而上的方式，来看一个比较典型的企业案例。

 

这个企业虽然和很多上云企业有很多不同，比如说行业、应用类别、上云动机等等，但他们同时也有很多共同点：比如上云后解决了很多问题但仍然遗留了相当多的问题。这个企业属于新零售行业，有不错的销售额。

 

但是随着业务的发展，传统的 ERP 软件已经不能满足业务发展的诉求，最主要体现在当他要参与 618、双十一这样的年度大促时，他的 ERP 供应商告诉他，他们的软件并不能支持达到上千或者上万的 TPS，只能够支持到百级的 TPS。因此对于这些新零售的电商企业而言，他们没有办法去满足大规模业务发展的诉求，也因此找到了阿里云。

 

阿里云为企业提供了基于阿里云互联网架构的解决方案，也同时让这些新的互联网应用、新的电商平台应用迁移到阿里云上。整体而言，开发是找了 ISV 去进行委托开发，把客户的应用从线下 IDC 迁移到了线上公共云上，在这里面最主要的技术升级是区域化，上云之后整体的运维是客户自己的运维部门来负责。整个迁云的过程也非常成功，很好地解决了客户应用的大规模问题，使得客户可以很好地参与 618、双十一这类的大促。

 

同时由于整体软件也就是这个电商平台采用的是自研方式，所以比较大地释放了像传统 ERP 一样高昂的成本。但由于整体的结构迭代非常快，导致在有一次大促中，由于业务量非常大，导致原来架构中的一个隐患引发了比较大的生产事故，对客户自己而言，他们评估这次事故给他们造成了非常大体量的损失。

 

To 云：“不上很焦虑，上了也焦虑”

 

 

所以说今天的很多企业，他们对于上云都有很多的焦虑，体现在他们思考到底要不要上云，因为上云不能只是单纯跟风，而是要想上云到底可以为他们解决什么问题。

 

 

 

对于上云之后的企业，他们虽然取得了阶段性的成功，也需要思考他们还有哪些问题没有得到解决。所以说不管有没有上云的企业，他们都非常焦虑，这就体现在他们都在思考怎么样才能很好地缩短研发周期，以支持快速的业务发展需要；怎么样去提升整体的运维效率，并在这个过程中让他们的 IT 部门具备很强的控制力；在整体上云和上云之后，可以比较好地降低整体的 IT 应用成本，以及降低软件的复杂度，提升整个系统的高可用能力等，这些方方面面绝大部分都聚焦在应用的非功能性特性上面。

 

1.焦虑的根源

 

所有的这些焦虑，我们可以从应用的角度去深度分析是什么原因造成的。

 

 

大家知道对于应用而言，核心的就是架构，包括了应用的业务架构和技术架构。从应用架构上去看，需要满足客户的应用发展诉求。比如说数据的产生，随着今天 IoT 不断普及，数据会产生非常大的接入量，对于这些数据的处理也带来了更高的要求。

 

基于传统的、更多的服务于人的请求的响应式数据处理方式已经不能满足于业务的需求，对于 IoT 设备更多的是基于请求、响应这类事件的模型和方式。同样的，企业的业务发展需要跟更多的公司去进行生态的连接。这些大量的业务诉求也对底层的技术架构带来了比较多的要求。这些要求就体现在，要求底层的技术架构能够支持高度的冗余，能支持微服务和海量的业务并发、以及能够支持动态伸缩、能够提供 SLA 等。

 

如果我们再进一步深度发掘，这里面到底是需要解决什么样的核心矛盾时，我们可以发现其实核心矛盾在于随着上云、业务的复杂度不断增加，使得 IT 有更多的管理成本。而这个成本就体现在，所有的微服务、高可用都需要用高度的系统冗余去解决。同时由于业务的快速发展，需要整个 IT 系统去响应频繁的变换。核心矛盾就在于，系统的高度冗余与系统的频繁变化之间的矛盾，所有的分布式系统都在围绕这一主要矛盾来进行解决。

 

举个例子，在原来的单机时代，如果我们只需要一个人管理一台机器，用一台机器上的软件就可以满足自身业务发展的要求，那么我们显然没有这么多的矛盾。只有当一个人变成几十甚至上百个人，当这样一台机器不是运行在一个节点而是几十上百甚至上千个节点时，整个 IT 需要处理的复杂度就从1对1变成了1对N的频发。所以说整体的复杂度得到了一个极大的提升，这也是我们所讲的矛盾的根源。

 

2.快速解和深度解

 

那么对于这样的矛盾有什么样的解法呢？今天在云的时代，我们总结了一下有快速的解法和需要更多资源投入的深度解法。

 

 

快速解就包括了 re-host 的模式，即把应用的运行环境从传统的线下 IDC 迁移到了云的环境。在这种模式下，应用的架构没有发生变化，应用的风险也是比较低的，但是价值的回报只能说是较高。与此对应的另一个解法就是 re-platform，就是把整体应用的交付和运维都改变，但是应用的软件架构不发生改变。

 

比如说我们通过容器的方式去改变整个软件的留存，改变整体的运维留存。那么在这个模式下面，它的架构变更的幅度是相对比较小的，实施风险是中等且可以得到比较高的价值回报。

 

但如果我们要彻底解决上面的问题，那么就要采取整个软件重构的 re-build 方式，或者对于软件的重要模块去进行一个 re-factor 重构的模式。这些模式都会涉及到软件的架构发生变化，因此它的实施风险也是很高的，但同样的高投入高风险也带来了高回报，改变后的应用可以更好地解决矛盾。

 

所有的解法都与云原生有着非常大的关系。云原生被提出来的最主要的原因，是企业上云之后发现很多应用不能很好地去利用云的特性，因此有人说很多应用不是云原生类型的应用。因此，云原生被提出来了。

 

云原生的关键内涵

 

我们先不去讨论云原生的定义是什么，但我们要专门提出关于云原生的三个关键内涵，理解这三个内涵对于我们怎么样去利用云原生构建现代化应用有非常大的帮助。

 

 

云原生技术：今天云原生的技术有闭源的和大量开源的。闭源通常体现在对应用相对透明的云厂商的基础设施上面。同样，大量的开源技术对于应用而言有比较大的关系，因为所有的应用会直接构架在这些开源的云原生技术栈上面。但如果说这些应用要比较好地去利用底层的云原生技术，我们通常会建议这些场景中我们的应用可以大量采用云原生的产品。

 

云原生产品：一部分客户的技术栈都基于开源的技术栈所构建，但开源的技术栈虽然在很多技术、功能、稳定性上没有问题，在可维护性和跟底层基础设施的配合上却可能会出现问题。因此我们会推荐应用尽量在云原生产品上去构建。

 

云原生理念：光靠技术和产品无法很好地解决前面提到的应用面临的方方面面的问题，因为技术和产品是生产工具，生产工具的改变往往会导致整个企业的 IT 文化，也就是生产关系的改变。

 

在整个 IT 文化当中，起到最主要作用的就是这其中整个企业的生产流程，以及生产流程之间人与人的合作关系。由于云原生的技术和产品在工具层面带来了改变，那么不可避免地就带来了在整个生产流水线，即企业的生产流程之间的改变。

比如说，原先有的岗位对人的要求发生了改变，或者原先的岗位没有了，同样一些新的岗位可能就被创造出来了。在这过程中，受到最大影响的就是人，包括人与人之间的协作关系。因此要很好地去运用云原生，特别要注意的就是云原生的技术和产品对于整个企业的生产流程、生产流水线上带来的改变，特别是对于人和组织上面要求的升级。

 

1.云原生是云计算的再升级

 

云原生不仅能帮助大家更好地去建好云、用好云、管好云，同样也是整个云计算的再升级。

 

 

这不仅体现在云的基础设施层面的升级，即云计算的提供厂商会意识到今天所提供的基础设施还不能比较好地满足应用的要求，需要不断地升级以能够更好地满足应用在高效的交付、运维上面的需求。

 

同样的，他也会要求应用在架构上彻底升级，让应用体现出更好的弹性、韧性和可观测性。有了基础设施和应用的升级，我们会进一步去追求整体研发效率的提升，这其中有采用 Serverless 这些新的计算形态去帮助我们应用提升整体的交付和运维效率的方式，以及更重要的就是解决频繁变化的 IT 系统当中的快速迭代和系统稳定性之间的矛盾。

所以我们说云原生是云计算整体的一个再升级。

 

2.什么是现代化应用

 

什么是现代化应用，跟传统的应用又有什么区别呢？

 

 

现代化应用中包含弹性、可观测性和度量、无状态和安全等典型特征，在整体的一个计算结构上我们可以看到，现代化应用跟云原生应用有非常多相似之处。它们之间的区别在于，现代化的应用不一定要跑在云上。

 

云原生应用顾名思义一定与云相关，但是他们很多特征都是一样的，它们都要求整体的应用要构建在云原生的技术产品之上，这些技术和产品能真正地体现在应用采用云原生的架构时，并且在整体的实施过程中要彻底贯彻云原生的开发理念。这样的应用才能够比较好地跑在各种基础设施上面。

 

既然提到了架构是承载应用的关键要素，那么云原生架构有什么特点呢？

 

云原生架构

 

云原生架构是一组架构原则、设计模式和设计方法的组合。在这个组合上面有非常明显的、区别于传统架构的特点。

 

 

云原生架构会尽量帮助我们的应用把其中的非功能性代码进行剥离。而在传统应用中，有不少代码需要去处理非功能性的问题。云原生架构下，这部分代码剥离出来后会被放到云原生的基础设施、产品和技术中去，由底层的 PaaS 平台和 IaaS 平台去承载客户应用当中非功能性的问题，从而让开发人员更多关注业务代码的编写。

 

有了这样的云原生架构去接管应用中原有的大量非功能特性，业务中原本因非功能性问题造成的业务中断也可以被避免，同时使应用具备了更轻量、敏捷、高度自动化的特征。

 

1.云原生架构原则

 

 

我们在云原生架构下抽取出了最重要的 7 个云原生架构原则：

 

1、服务化原则：微服务化颗粒度可以更好地满足客户应用的特征；

2、弹性原则：从虚拟机到容器层面到进一步应用层面具备不同弹性；

3、韧性原则：高可用原则的进一步提升，应用在各种情况下持续为客户提供服务；

4、可观测性原则：与监控不同，可观测性模型可事先提供大量从日志到链路跟踪的有效信息，从而主动发现系统中的潜在风险；

5、自动化原则：从底层的硬件到软件、组件，都有比较大的提升，因此更希望有自动化原则去帮助我们更有效地运维，从而降低运维成本；

6、零信任原则：云原生架构可以运行在不同架构上，因而对安全提出了新的要求，要求所有的应用不管运行在什么环境都是不信任的，每次运行请求都需要校验合法性；

7、持续演进原则：可以根据企业的特点，每个阶段采取适合的演进目标，长期迭代后使每个目标最终演变到现代化的应用。

 

2.云原生的主要架构模式

 

云原生的架构模式非常多，列举如下图所示，详细的内容可以参考近期出版的《阿里云云原生架构实践》。

 

3.阿里云云原生架构方法

 

 

关于云原生的架构方法，我们提出了 ACNA 的架构方法。这是阿里云关于云原生架构的一个架构设计方法，包含了对云原生架构的评估体系和成熟度的度量体系，同时也包含了阿里云对广大客户在对应用实施云原生技术改造过程中，积累的最佳实践和用到的产品体系和技术。在这之中有一些架构视角，我们希望对每个企业来说，他们可以根据自己企业的情况去选择与之相匹配的技术架构能力，最终为业务发展、企业战略发展服务。

 

4.阿里云云原生架构闭环

 

整个架构方法是包含了多个视角的综合体，在这之中我们希望通过架构持续演进能形成一个闭环。

 

 

整个架构闭环包含了最主要的八个阶段。从识别业务痛点到确定架构目标，在评估风险过程中选取相应的技术制定迭代计划，推动落地计划中我们建议企业在实施云原生架构过程中有一些专门的机构去评审整体的风险，从而让整个过程形成一个闭环。而在这个过程中要特别关注架构治理视角，这需要有相应的组织或人员来帮助应用在迭代过程中进行架构治理。

 

5.如何衡量云原生架构的成熟度

 

在 ACNA 里我们提出了一个衡量云原生架构的成熟度模型，其中有六个关键维度，我们简称 SESORA。

 

这六个维度的能力，也是在现代化应用中的最主要的六个关键指标。每个指标从0-3分为了四个等级，每个等级有对应的得分，在评估后可以得出一个关于应用在云原生架构上得到的评分高低。今天阿里云提出的这个 SESORA 模型已经在业界中得到很多机构和企业的采纳，从而可以帮助企业在云原生架构改造上提高成熟度。

 

客户案例

 

最后来看两个典型案例。第一个案例是在阿里云上的应用怎么通过云原生的产品去有效预防在系统架构设计当中稳定性的风险。我们采用了微服务的架构模式，有大量数据是存放在 MongoDB 中的，在这个架构中客户采用了 PTS、ARMS和AHAS 这个组合，这可以比较好地帮客户去主动探测系统中是否存在潜在的风险，从而去预防稳定性的风险。

 

 

第二个案例是关于 Serverless 的案例，解决的问题是帮助微服务应用快速上云。因为在这个过程中，我们往往需要应用去解决很多问题，而在 Serverless 模式下，这些底层的部署都得到了很大的复杂度降低。

当客户应用有突发流量增加时，Serverless会探测到并主动申请新资源，从而使新增流量得到及时响应；当突发流量消失时 Serverless 也会主动释放资源，从而降低成本。