云原生应用，你了解多少？

1)从 Function 到 Service

一、从函数说起

我是 1993 年学习电脑的。学习的开发语言有三种：汇编、C、DbaseIII。

所以在我学习的时候，我并不了解面向对象的代码架构设计和代码编程实现。所以要从字面上来区分函数和函数之间的关系，主要就靠函数命名、放在同一个代码文件里、放在同一个代码目录文件夹里来区分他们之间的关联性。

在当时函数时代，也没啥异常保护、异常处理、异常日志的函数编写基本原则，所以我们除了命名以外，主要注重的就是函数的输入数据参数以及格式、输出数据的参数以及格式。

二、面向对象

我的面向对象是用 Object Pascal 开始的，但真正大量写面向对象代码的时候是使用 Delphi，那已经是 1996 年的事情了。

因为有了类这个东西，所以函数就可以物以类聚了。有的函数属于私有函数只能这个类里面才能调用，有的函数属于公有函数可以供外部调用。

但是我那时候使用类还很初级，往往是一个源代码文件中就定义一个类。而且类也没有使用继承，也就是说我所有的类都是平行的，类和类之间通过 Public 型的公开函数调用才产生了关系。

三、面向接口

Delphi 这个开发语言是优美的，它的定义申明和它的详细实现是分离的。

业务功能进一步复杂起来了，过去没什么太多关系的业务现在关系越来越紧密了，有些类和类之间的调用就太多了。我就想着重写这块代码，把这两个类进行合并了。但一重写吧，需要动的东西太多了。

用继承、用多重继承的方法来做吧，太麻烦，总要在实现里写一个空函数(就是没有代码但只有函数架子的，以备编译器能语法通过)。后来认识了接口，就用接口定义了，就不使用空函数了，就定义，不实现，编译器照样能通过。

四、面向组件

我是完整经历过面向组件时期的，并且用面向组件技术编写过一整代完整的 ERP 引用套件。从 CORBA 技术到 COM/DCOM/COM+技术都娴熟学习并使用过。我也是完整经历单机版本到 C/S 客户端服务器端局域网版本到 C/S/S 三层架构的。

一开始我用 DBaseIII 写应用，UI 开发、业务逻辑开发、数据库开发都是一个开发语言搞定。

后来用 Delphi 写 C/S 应用，就用了 SQLServer 大型关系数据库，在数据库层就写了不少存储过程和定时 JOB 任务。但当时业务逻辑代码和 UI 代码都是运行在客户端，所以这两层之间的分离也并不清晰。

然后写 C/S/S 三层架构，业务逻辑层独立出来，而且是物理独立部署，这样客户端代码和业务逻辑层代码就必须要彻底分开，不能不清不楚地混杂在一起了。在那个时候，我才开始大量使用精心的接口设计、对象设计。

因为有了独立的业务逻辑层，那么这些代码(接口/类)何时创建对象实例，何时释放，这些对象实例要运行在哪个进程容器中，就有了要求了。因而就产生了组件容器和组件。组件容器来管理组件的全生命周期(安全、创建、并发访问控制、休眠、激活唤醒、计数、摧毁释放内存)，组件管理器就来管理组件的注册、发现等。

所以《COM 本质论》的作者 Don Box 说.NET 就是更好的 COM，我一下子明白了：对啊，微软的意思是，以后所有的应用都应该运行在组件容器中，不管是单机应用，还是 C/S 应用，还是 C/S/S 应用，每个应用都要运行在组件容器中，由组件容器来屏蔽和管理内存的创建与回收，不要把内存的创建与释放直接袒露给开发者，否则开发者技术能力水平不一，有的烂的程序员管理不好内存，很容易就会使应用占满内存并导致操作系统崩溃。

五、面向 WebService

哈哈哈，大家好像都没听说过面向 WebService，大家好像就听过面向服务。

Web 互联网兴盛起来，HTML(UI 元素定义)+CSS(UI 元素风格定义)+JavaScript(UI 元素操作)构成了前端技术。人们又从前端里分离出来 XML，成为数据容器。可以用 HTTP+80 端口进行传输纯文本的 XML 数据，也可以用 UDP、TCP/IP 等各种传输协议进行传输。当然，XML 还可以被压缩以便更小尺寸在互联网上传输(尤其过去互联网速度很慢)，还可以被加密不让人中间截获看到。这些就构成了 WebService 的一个技术族。

我们现在要把局域网版本的 C/SS/三层技术架构，升级到 Web/S/S 三层技术架构，那怎么办呢?

所以我们需要在我们的组件基础上再包装一层 WebService，客户端的 AJAX 技术就好调用了。所以当时.NET 组件技术、EJB 技术、.NET 组件容器、EJB 组件容器中间件，都纷纷原生内嵌支持 WebService 技术族，让从开发到运行到调用，直接就是 WebService 技术。这就是 SOA：面向服务架构。

(2)微服务

一、物极必反

当时是多么理想啊：一整套 J2EE 体系，WebService + EJB 完美组件模型 +WebLogic SOA 组件容器/ESB 组件管理器中间件，包括技术架构师。当年是多么多么大的市场啊。

但程序员是实用主义者，怎么简单怎么来。随着第二波互联网创业热崛起(2004 年)，大干快上才是王道，没钱用开源开干才是王道。

于是，WebService 换成了 REST、XML 换成了 JSON、EJB 换成了普通的 JAVA Class、WebLogic 换成了开源的 Spring。尤其在 2004-2006 年，SSH 这三驾马车(Structs 前端、Spring 中间层、Hibernate 数据层)真是横行世界。

尤其 2004-2006，Google 崛起如日中天，Google 统一开放了自己的 Open API，轻的很。这已经是微服务流行的启动了。但这时候还不能称作微服务，可以称作简化服务(WebSerivce)。

二、亚马逊的天条

贝索斯从 2002 年就亲自制定了亚马逊分布式系统架构六条原则：

所有团队的程序模块都要通过 WebService 接口将其数据与功能开放出来 团队间程序模块的信息通信，只能通过这些接口进行。其他形式一概不允许：不能用动态链接库、不能读取其他团队数据库、不能试用共享内存、不能试用别人模块的后门，唯一允许的通信方式只有调用 WebService。 所有的 Web Service，毫无例外，都必须从骨子里到表面上都设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外 不这样做的人会被炒鱿鱼 一个服务由一个小团队(两张披萨喂饱)负责，从前端到数据，从需求分销到上线运维，全权负责 逆向工作法：先定义未来，然后发布新闻稿进行客户探索与交互，再进行实现执行

我看到这六条原则，我也就明白了为啥亚马逊能做成公有云计算领头羊了，我也就明白了在现在 Cloud 大行其道的时候，亚马逊还一直坚持使用 AWS 这个品牌(Amazon Web Service)。

我个人认为，从亚马逊全职能小团队、内外一体化原则开放 WebSevice 开始，服务才真正变小，成为微服务。如果你是个 100 人的团队，你是一个按专业职能划分的团队，你是一个一年就发布 2 次的团队，你是一个区分内部调用和外部调用的团队，我相信，你是成不了真正的微服务的。你充其量来说，只能说，你是一个用了微服务技术却没有实现微服务的团队。

这很好理解。很多程序员用了一辈子面向对象的开发语言，但从未自己定义过真正的类。这就是中国。

(3)云时代

一、移动时代来了

90 年代我们用 C/S，用 C/S/S Corba、DCOM/COM+，2000 年以后我们用.NET、EJB/WebLogic，后来我们又用 REST、JSON、Spring。这都是业务逻辑层技术的演进变化历史。

在客户端，倒是互联网访问速度越来越快费用越来越低、屏幕越来越大、性能越来越高、内存越来越大，给客户呈现出来的功能越来越多、UI 界面越来越复杂。你这个时候想做微服务，其实蛮难的，你受不了诱惑，总想给它添加更多的功能，反正客户端性能高、屏幕大，能承载，没坏处。

但是移动时代从 2011 年在中国开始了。手机网速慢资费高、性能慢、内存小、屏幕小、没有键盘和鼠标只能手指头划屏幕，所以微信从语音消息而非文字消息崛起了(打字输入实在不好打啊)。

小屏幕，无键盘无鼠标，不好输入也不好输出，那么功能就必须简化再简化。这就倒逼业务逻辑层也不能做的太复杂。因此即使没有亚马逊开除人的六大天条轰顶，微服务在移动时代也算真正被大规模流行起来。现在小程序技术依托微信平台(统一客户、IM、支付)，让开发、部署、发布更加简化。

因为人人都有了随时随地可访问的智能设备，所以企业比以往任何一个时代都能更容易连接、触达、交互到最终消费者。所以企业应用开始从企业内部管控建设重心转移到连接消费者、与消费者交互、消费者直接下单交易的业务重心。一个软件的应用的使用主体从可以管控炒鱿鱼的员工，转移到了给企业进行买单交易的衣食父母。

衣食父母不能得罪啊，这是要影响销售业绩的啊，所以需要抓住黏住、快速改进。所以为了快，而不要跨专业职能部门协作，所以各个研发团队也都自行改组，从专业职能部门组织形式改造成为亚马逊式的全职能小团队，这更加助推了微服务的实质化落地。

所以，移动化限制倒逼、衣食父母倒逼，这是移动时代才让大规模万金油程序员学会落地微团队、微项目、微功能、微服务。

二、云时代来了

因为企业应用重心已经从可数的企业员工用户转移到了大规模外界的消费者用户，所以高性能并发、海量数据的技术要求立马上来了。但企业应用开发者一直面对企业内部用户规模，不是互联网企业啊，怎么应对啊，没经验啊。

正好，云时代来了。

提供了分布式对象系统、分布式数据库、分布式大数据技术平台、分布式消息队列中间件。当然，Spring 升级成了 Spring Cloud，成了分布式微服务中间件。噢耶，终于跨过这个技术门槛了。

别高兴太早了。因为是分布式的，因为是面对海量最终消费者的，所以部署工作成了复杂的了。不像过去做企业内部管理应用，最多也就十来台服务器，人手工都能升级得过来，而且企业员工一下班就能开干。现在都是消费者应用了，消费者都是行为习惯各异需要 24×7 运行，而且这还是交易型应用，你还不敢断掉，你还不敢一下子全升级了你怕出个交易闪失赔不起钱，所以你还需要灰度发布。

这就需要工具了。

所以 DevOps 在互联网时代、云计算时代才真正流行开。就是因为：海量用户、在线 24×7 实时运行、交易型、大规模服务器、快速迭代开发发布上线，不得不开发运维一体化。过去运维人员的技术要求性不高，现在运维人员也得有开发技术能力了。

为了更快捷地打包、分发、部署、升级、维护，人们发明了 Docker 和 K8S。Docker 可以打包为一个镜像文件、Docker 让微服务的版本环境隔离、Docker 让微服务在开发期和运行期一致，这让分发、安装部署、升级、运维变更极为简化。

(4)云原生应用

一、微服务不微是因为什么

微服务不微，是很多人的困惑。

虽然有了全职能微团队(2 张披萨饼)、微 UI(移动 APP 和小程序技术)、微项目(每两周迭代发布一次)，但微服务仍然不微。

虽然有了满足海量用户高并发的 Spring Cloud 分布式微服务中间件、有了满足分布式部署和运维的 DevOps(Jakins/Docker/k8s)，但微服务仍然不微。

问题到底出哪里了?

咱们从开发流程再捋一捋。

软件公司嘛，软件代码是我们的核心资产。所以我们肯定有我们私有的 Git 源代码库，部署在我们公司的 IDC 机房里面，而且做层层的安全防护以及代码备份机制。

我们要开发的时候，需要在我们本地安装部署需要的各种框架，才能做本地开发、本地调试。但是现在为了应对高并发分布式中间件、海量大数据存储与计算、人工智能训练、物联网接入，我们需要安装的依赖的技术框架高达 40 多种以上。光部署调正常这堆框架已经把我们累的精疲力尽，而且这些框架之间随便出点参数变更或版本不兼容问题就搞死人。

好，总算调正常这一堆框架，我们开发完具体业务应用，我们就开始应用 DevOps 工具和 Docker，进行打包、分发、部署。这么多依赖性的框架，你的微服务能微的了吗?

二、云原生应用

正确的打开方式是什么呢?让我们描绘一下。

第一步：你的代码放在云代码平台而非你公司内部私有部署的 Git 平台上。这就是微软要花大价钱并购 Git 的原因。这是第一步。为什么要这样做，你接下来就明白了。反正你现在基于云计算、大数据、人工智能、IOT 开发具体业务应用的时候，你大量依赖的都是开源平台，就你那点具体业务应用能有多高技术门槛。而且微软接手后的 git，对于企业代码的安全保护、备份，比你自己的管理员和运维技术高多了。

第二步：使用云开发平台。这个开发平台可以基于 Web 浏览器，也可以基于本地 VS Code IDE，但云开发平台的核心本质是：你根本不需要在本地安装那么多依赖框架，你在 IDE 里面写应用，你打开云上 Git 平台上面的某个源代码文件，import 进一个包，然后在 IDE 里直接调用 API，这个云开发平台会自动补全 API，你可以保存代码、你可以编译代码、你可以调试代码、你可以运行代码，和你本地一样，但其实是应用运行在云端，应用也是在云端进行打包、安装部署的。

这才是真正的云开发平台，比如 AWS 的 Cloud9。现在有很多李鬼，把 20 多年前雅奇 MIS 的那套玩法又拿了出来，快速可视化设计输入表单，图形化进行审批工作流设置，快速可视化设计报表图表，这个东西在全世界也没有独立市场存在过，而且也不是今天我们谈到的云原生应用开发路径上的东西，或者换句话说，那根本不是给开发人员用的。

第三步：使用云服务 OpenAPI。云计算厂商把所有的云服务都开放出来 Open API(你想想 Amazon 的六个天条)，你可以在这个云开发平台上直接调用这个云计算厂商的所有 Open API 开放平台里面的 API。这些云服务会自己负责自己的安装部署升级、监控、备份、迁移等等。

三、终极：Serverless

最终极的方式是：Serverless。那个时代的 IaaS、技术 PaaS、应用 PaaS、具体业务应用 SaaS 很丰富，大家都开放 Open api，也有 Slack、企业微信、钉钉这样的统一门户平台，也有小程序 UI 前端技术，你打开 Web IDE，New 一个函数，里面直接调用 Open API，你的应用功能就串联起来了。

你也不用在意什么打包、安装部署等细节。当你要运行时，在云端后台，会自动启用一整套 DevOps/Docker 工具集给你打包，会根据自己的云计算资源给你具体进行安装与部署，你根本不用管是部署到哪个服务器上了。随着你的应用性能，他会去给你自动迁移扩展到更高性能的计算环境中。这一切对于你来说都无感。你每月只需要缴纳一笔总费用即可。

不这样推，开发人员的效率提不上去;不这样推，软件公司只使用云厂商的云硬件资源，其他软件中间件都自行开源部署而不使用云中间件，那样云计算厂商也不容易挣大钱啊，毕竟硬件都是刚性成本，只有软件才是高利润的，尤其是云上部署的分布式中间件服务，更是大规模高利润的。

【凡本网注明来源非中国IDC圈的作品，均转载自其它媒体，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。】