技术发展趋势：越是基础和通用的技术，越会趋向于一步步被标准化，技术每被标准化一层，原本繁琐低效的事情就少一些，技术标准化层面越高，技术门槛就会变地越低，或许未来真的只会有业务解决方案和业务代码。

一、IAAS和PAAS的标准化

IAAS和PAAS的标准化，是在提升运维和开发的效率，主要还是运维效率。

随着云计算的发展，目前的公有云产品已经可以提供非常好的IAAS和PAAS支持，比如：

a、IAAS层面：资源上，虚拟机，专用物理机，Serverless，或者GPU或FPGA服务器；网络上，私有网络、专线、负载均衡等等，只要配置一下就可以跑起来。

b、PAAS层应该也不用多讲了，缓存如Redis、消息如各种xxMQ，DB如RDS，存储如OSS、文件存储等等，在各种公有云上也都有现成的解决方案。

记得09年的时候，我们新上线一个业务，要提前做规划和预算，之后等设备到货，然后要在机房里蹲很多天，上架机器、拉网线、初始化系统。最痛苦的是，有时候业务发展快了，发现原来的组网结构无法满足扩容诉求，还要调整组网架构，带着业务去做网络设备变更就是刀尖上舔血，十分的危险，过程自然也十分的痛苦。软件开发，很多基础的组件也需要自研，举个最简单的例子，比如做数据库的读写分离和分表，就需要自己写路由逻辑，从成本上，当时用oracle，多一套实例就要多交一份钱，效率不高，成本却很高。

现在这些都可以省了，对一个创业公司，完全可以通过公有云平台去选择所需资源甚至是解决方案，而不用再花精力找IDC机房，去买硬件和网络设备，也不用找人帮忙拉网线上架机器等等。各个公有云平台提供了标准化的产品支持，这时就帮我们屏蔽了绝大部分基础层面的事情。标准化安装和交付，绝大部分情况下我们只管使用即可。

总结一下，也就是无论你选择阿里云，腾讯云还是AWS，或者其它共有云，你所获得的能力基本都是差不多的，从本质上讲，一定规模体量下，其实并没有太大区别。

从一个侧面来看可能会更有感受，你会发现想当初一个思科的CCIE或者是Oracle的OCM是何等的金贵，但是当云计算的IAAS和PAAS达到一定的成熟度之后，基础技术标准化了，一切都不一样了。

推荐下MacTalk的文章《后端工程师的危机》，关于这块已经写得很清楚了。

二、应用代码框架标准化—Spring Cloud

Spring Cloud的出现，或者说应用代码框架的标准化，大大提升了开发人员的效率，目的也是更大程度的释放开发的生产力。

上面提到基础设施和服务标准化了，但是再往深里关注下，其实在代码开发和维护上，也在向着标准化的方向发展。

在上篇文章《一个真实的DevOps演进过程是啥样的？》中提到，现在绝大部分的公司在高速发展阶段，技术架构上必然会朝着分布式服务化方向演进，下面我们要说的就是这个层面的标准化。以Java为例，还是先看下下面的一个真实的过程：

1、Spring Web

早期web应用大家都会基于MVC模式去设计开发，这其中就会用到轻量化SSH框架组合，这其中一个S就是Spring框架。Spring的出现大大提升了代码开发的灵活性和效率，但是早期的Spring框架使用需要进行大量的web、DB、事务、日志等等的xml文件配置才能运行起来，虽然比之前方便了很多，但是仍有很大的改进空间。不过之前采用单体或分层架构，应用数量不多，还可以接受。

2、Spring Boot

后来随着分布式服务化架构的产生，应用数量多了起来，每次新增加一个应用都要重复大量繁琐地配置，这就不是一个高效率的事情了。为了更加方便地开发服务化应用，Pivotal公司基于Spring打造出来Spring Boot框架，提倡约定大于配置。同时，它还提供了非常方便的与业界开源组件的整合方式，如redis、mybatis、RabbitMQ等等，一个团队可以基于自己的实际情况，约定好自己内部的配置和需要使用的开源组件，就可以快速生成自己的代码和配置架构。总之，开发可以省去大量（不是全部）配置和开源组件适配工作，专注于业务开发。

3、Spring Cloud

以上是针对单个应用的，更多的便利性体现在开发阶段，但是服务化之后产生的大量应用治理就又成问题了，至少得需要注册中心、服务发现和负载均衡这些基础能力吧。所以Pivotal就又顺势推出了Spring Cloud这个东东，它更像是服务化体系的大管家，管理和治理着各个服务化应用，在后续整个软件运行生命周期中起着核心作用。

从业界看Spring Boot和Spring Cloud已经成为很多公司服务化技术选型上，事实上的标准化框架。除了部分大厂能够有技术实力和人力储备去自研自己的中间件框架，对于技术历史包袱不重的公司，如果向分布式服务化方向演进，Spring Cloud基本可以满足绝大部分的需求，完全没有必要从头去自研。

Pivotal已经将它们打造成了一个非常完善且强大的开发框架生态体系，它的主要项目如下：

具体大家可以直接看官网。

4、Netflix和Pivotal的贡献

这里不得不提到Netflix和Pivotal两家公司，Netfilx将其在AWS上Spring分布式方面的优秀实践开源，Pivotal又基于自家的Spring Boot框架，整合Netflix开源产品，推出了Spring Cloud，其中最为核心的子项目就是Spring Cloud Netflix。如果说Netflix是技术的贡献者，那Pivotal更像是技术的整合者和布道者，让技术在业界更加充分的落地和被广泛的应用，让技术的生命力也更加绚丽多彩。

而且有Netflix不断贡献新的实践经验，再加上Pivotal这样的商业公司不余遗力的打造和推广整个Spring生态，所以有这两个干爹在，不用太担心断更风险。

5、关于Dubbo

不得不提一下，曾几何时，在国内的服务化框架首选乃是Dubbo，天生自带光环，且也是出于阿里优秀实践的开源产品，早期甚至是现在也确实是一个非常优秀的服务化框架。但是近几年因为断更，且周边生态发展远逊于Spring Cloud，被众多的开发者所诟病，虽然近期重启开源维护，在阿里云产品中也有推广，但是在开源业界重新树立起开发者中的信心和口碑可能还需要很长的时间。

6、收个尾

上面写了很多关于Spring Cloud的文字，简单回顾下就是Spring配置繁琐，开发人员嫌麻烦，所以后来有了Spring Boot，不过开发代码是方便了，后续的应用管理和维护又麻烦了，所以就有了Spring Cloud一整套生态。

三、应用管理标准化—容器和K8S

应用管理标准化，大大提升了代码发布和应用部署效率，从而使得开发效率和需求吞吐率大大提升。

我们就用Docker代指容器吧，Docker的出现，一个核心目标就是-Develop,Ship And Run Any Application, Anywhere，从此我们管理的维度就是统一的Docker实例和镜像，而不再是什么Java应用、C++应用等等。再加上类似K8S这样优秀的容器编排系统出现，更加方便了容器的管理和使用，也就更加方便了应用的统一管理，最为直接的体现就是发布部署效率的提升。

当然，关于K8S，也不能简单的看做是一个编排系统这么简单，它的存在更像是一个容器化技术生态的核心，这一点会在后面的CNCF那一小节中简单说一下。

关于Docker和K8S就不啰嗦太多了，业界和各个社区有太多文章介绍，就不卖弄了。

至此，IAAS、PAAS、应用代码框架、应用管理都标准化了，标准化之后可以做些什么呢？

四、Cloud Native云原生理念

将上面的过程再串一下，可能会更好理解了，简单点讲就是开发用Spring Cloud提供的框架写代码，如果需要用到一些通用组件，如缓存、对象存储、消息、DB等，就可以用公有云的PAAS服务，然后代码写完，整个打包到Docker容器中，最后发布到公有云的计算资源上运行；运行过程中，涉及日志、链路跟踪、监控、降级等维护需求，Spring Cloud或者公有云也都提供了相应的基础服务或框架支持，这时可以基于这些服务开发出相应平台来支持运维。大致过程就是这样，当然细节要比这个复杂很多。

Cloud Native理念，目的是提供云上业务端到端的技术解决方案，全面提升软件交付效率，降低运维成本。

上面的这套思路早已被业界摸清，也就是现在被称为Cloud Native（云原生）的理念，被以不同的形式在推广和发展着，下面就看看几种形式：

1、商业化模式

这里又要提到Pivotal，这家公司早就已洞察到这个趋势，顺势推出了Cloud Native（云原生）这样的理念，应该是最早提出这个思路的厂商，而且它的牛逼之处在于，不仅提出思路和理念，还一并推出了自己的一整套解决方案和产品，当然你也可以理解为是为了卖自家产品（Cloud Foundry）而打造出的概念，但是不管怎样，确实是顺势而为，在驱动着一个趋势的发展。

搭载着自家公司的Cloud Foundry和Spring产品体系，以及其敏捷方法论，Pivotal Cloud Foundry（PCF）架构如下图，，仔细看下来，解决的就是我们上面提到的过程。

2、基金会模式

上面Pivotal如果是商业化产品，目的是为了盈利，那由Google凭借其超强的号召力和影响力，携K8S，牵头发起的CNCF（Cloud Native Computing Foundation），就更像是一个公益组织，更加纯粹地去打造云原生这样一个完整软件生态体系，所有想参与到Cloud Native标准制定的厂商或者开源项目都可以参与进来，只要遵守CNCF的章程即可。所以当前它暂时不是以具体的某种一整套解决方案或产品的形式呈现，而是一个个的开源项目，当然当这些项目和生态足够成熟和完善的时候，CNCF也会去做一些更加标准化的事情，比如：

When successful, the cloud native computing foundation will establish:
Standardized interfaces between subsystems.
A standard systems architecture describing the relationship between parts
At least one standard reference implementation of each sub-system.
Thinking about adding extensible architecture that end users can extend, replace or change behavior in every layer of the stack for their purposes.
详细可以参考。

CNCF设想中的云原生分层架构示意图：

CNCF组织成立后，圈子中的大佬们纷纷加入，比如前段时间最重量级的AWS，还有前面多次提到的Pivotal等等，国内的腾讯云和阿里云也参与其中，它支持的核心项目除了K8S外，还有Goggle的gRPC，Docker的ContainerD，CoreOs的rkt等重量级开源项目。

虽然整个生态里面没有看到Spring Cloud，但是却有类似于的项目，比如服务发现CoreDNS，服务治理linkerd、Envoy，按照CNCF的定义叫做Service Mesh，还有分布式跟踪，如OpenTracing，Jaeger等。

这些项目都是原生（天生）的与K8S集成和配套的，可以看到Google是想基于K8S打造出容器化的分布式微服务的云原生标准，其它厂商也不想错过这个参与制定标准的机会，纷纷加入。而对应的，微软也发起了OCP这样类似的基金会组织。

所以，云原生标准制定的争夺战已经开始，未来出现什么样的局面不敢妄下判断，但是趋势已不可逆转。

3、事实上的云原生—公有云

这个应该不难理解，Pivotal也好，CNCF也好，当前都是解决方案，而公有云才是业务真正能运行起来基础设施，或者说公有云才是所有解决方案最终的落脚点和归宿。

拿公有云影响力最大的AWS来说，虽然在官网上没有特别强调Cloud Native的词汇，但是有Netflix这样的超级业务在上面，且是基于AWS上原生的技术服务如S3、大数据、SES、ECS、容器等打造出来的，所以AWS本身就已经是云原生体系了，类似的Azure、腾讯云、阿里云等公有云也一样，其本身就是一种事实上的云原生标准。

同时，Netflix在高速发展过程中产生出来的更新更优秀的最佳实践也在反哺着AWS和整个业界，比如其开源产品被Pivotal包装，打造出了更好用的Spring Cloud。

4、相互融合的模式

这种现象就是，以上几种模式的相互融合，比如AWS加入CNCF，业界为啥会大呼惊叹，因为CNCF的项目，特别是K8S也需要在AWS这样级别的公有云上真正大规模商用过，得到过广泛实践才算是最终的成功，Google必然看重与AWS的亲密接触，CNCF如果只是开源爱好者们的兴趣集中地和Demo版本，是不会有影响力和生命力的。

同时，AWS也在实践Spring Cloud，以及K8S，大家关注Qcon大会的话，就会发现AWS在这方面也在不断的尝试和努力。我想AWS也需要在自己的平台上，能够结合业界最佳实践，给更多的用户提供更加普适的解决方案，毕竟采用Spring Cloud的用户很多，尝试K8S的用户也很多。

再就是Pivotal，如果仔细看上面那张图，PCF也并不是只能在自家的CF上跑，放到AWS、Azure或者私有云上也可以。（文章发布前，10.12日云栖大会上CF公布支持K8S，果然是在不断融合。）

当然，现在还有很多基于CNCF标准，围绕着K8S提供商业解决方案的创新公司，也是基金会和商业的结合体，而且体现出非常非常大的活力。

所以可以看到，这几种模式也是在不断地融合和交融，从业界的实践案例来说，很多公司也是在这几种模式结合中找到最适合自己的解决方案。比如传统企业会可能选择成熟稳健和具备服务支持的商业解决方案，初创型公司会选择公有云+K8S这样灵活性和生态更丰富的解决方案，如果我们细心，其实可以看到业界很多类似的案例，在文章里我就不提了。

相信在类似Pivotal、CNCF、AWS这样的商业或基金会组织的共同努力和驱动下，新一波的技术理念一定会得到长足的发展和进步。

最后

不知道看晚上上面这个过程，是否感受到了文章最初提到的那个趋势和规律。

总之，我们可以看到，越是基础和通用的技术，越会趋向于一步步的被标准化，技术每被标准化一层，云本繁琐低效的事情就少一些，技术标准化的层面越高，技术门槛就会变地越低，或许未来真的只会有业务解决方案和业务代码。

未来，对于我们技术人，更高更迫切的能力要求将会是：如何能够利用好业界已有的丰富的技术产品和平台，在面对复杂的业务和不同领域需求时，能够找到最佳的业务解决方案和切入点，而不再是重复造轮子全部重新来过。

当然，也不要以为技术门槛降低就意味着技术和解决方案的复杂度会降低，特别是业务解决方案的复杂度，对于人的素质要求也不再是简简单单纯技术层面的要求。

前途是光明的，道路必然是曲折的，云原生是否能形成统一的标准化体系，会产生多少产品，这种理念到底能够多么方便的帮助业务快速落地，还需要我们拭目以待。

对于前端、客户端等等技术，是否有同样的体会呢？

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/uIyc8BW6BkNV91kHyD0QIg

创作场景

技术标准化—纷繁复杂趋势背后的规律