微服务和PaaS到底有什么价值？

本文来自微信公众号：阿朱说（ID：azhushuo），作者：吕建伟，原标题《从来没有一种技术是为了解决复用、灵活组合、定制开发的问题》头图来自：视觉中国

很多人说：微服务的价值是复用、方便灵活组合。

很多人说：PaaS平台的价值是方便定制开发。

我想说，这都什么人传出来的谣言。

这都是白日做梦。从来没有一种技术是为了方便修改和定制开发。

一、微服务是怎么来的

（1）面向函数和面向对象

1946年产生了计算机以后，由于计算能力和存储能力限制，人们写的代码有限，所以当时都是流水代码，一边读卡器读入，另一边电传打字机打印出来结果。

后来计算能力（晶体管与硅芯片）和存储能力（磁芯与磁盘）提升了，人们写的代码可以更长了。为了更好地阅读代码，人们把代码分割成了函数。

后来，大规模集成电路产生了，计算能力和存储能力更进一步，函数也变的更多了，需要把函数也分分堆儿，于是物以类聚，面向对象编程产生了。

所以说：面向函数和面向对象，主要目的是为了解决代码有组织性。

至于所谓的复用？你如果设计的输入参数、输出参数、返回值没有精心设计好，根本不可能达到复用。

（2）面向组件和面向服务

RPC，局域网中跨服务器的远程过程调用，在1987年就由Sun公司和HP公司领导创立了。

面向组件产生于1990年。主要是为了解决跨开发语言、跨操作系统进程、跨服务器的应用程序之间互相调用的问题。这里以IBM为领导的CORBA组件体系、微软的COM组件体系为代表。1997年，Sun公司集大家之所长，制定了J2EE标准，这也是一种面向组件的技术体系。因此有了大家熟悉的EJB。

但是，1997年也是互联网最狂热的时代。1999年，WebService技术产生。这样，应用程序之间互相调用就不限于局域网了，更可以延伸到互联网。因此出现了面向服务，意思就是for WebService。所谓的服务，其实特指的就是WebService。

所以说：面向组件和面向服务，主要是为了解决应用程序之间互相调用的问题。

（3）面向微服务和面向函数服务

但是大家都知道，不管是组件技术栈，还是WebService技术栈，都日益复杂。

所以Spring公司创立的时候，提出的是EJB已死。

不要组件（直接JAVA类就OK）、不要组件服务器（直接Spring编程框架就好），不要WebService（直接RESTful就好）。于是这就演变到了面向微服务。

2014年，AWS更提出Serverless无服务器编程（函数服务），直接在云上编程云上运行，不需要操心下面的一切。

所以说：面向微服务和面向函数服务，主要是为了简化面向服务编程的复杂性。

所以，从1946年计算机技术产生，自古以来，就没有一种技术是为了解决所谓：复用、方便灵活组合。如果你没有高级程序员（技术架构师），不精心设计你的应用程序的每个接口，光靠这些函数、对象、组件、服务、微服务技术，根本不可能做到复用、方便灵活组合。

但是，恰恰的是，我国应用软件编程人员，就是万金油编程人员，就懂得996加班把产品经理的功能赶快实现了，根本没有足够多的高级程序员（技术架构师）去负责精心设计应用程序的每个接口。

二、PaaS平台

（1）低代码开发平台

不知道什么原因，低代码开发平台突然火起来了。而且不少人想拿低代码开发平台去解决大型客户个性化定制开发的需求。

我想这不是南辕北辙了么？

低代码开发平台，能解决的是：扩展开发。也就是说：新的功能模块的代码快速生成与编写。

至于你老的代码，如何满足一家家客户的定制开发修改，尤其还是在现在公有云、SaaS多租户的未来趋势下。我想真是痴人说梦。

Salesforce都做不到现有的产品功能可以满足一家家客户的定制开发修改。

（2）Open API开放平台

Open API开放平台主要解决的是：集成开发。

也就是说：你的系统，需要和客户的系统集成在一起，如和客户的CRM系统、财务系统、OA系统集成在一起，Open API开放平台是必须的。

（3）大数据平台

至于查询、搜索、数据挖掘、数据仓库统计，以及报表、图表可视化展示，用大数据平台即可。

至于主数据服务、主数据订阅/发布推送，用主数据管理系统即可。数据层面的集成，也主要是在主数据这块。

也就是说，从来没有一种平台技术的发明，是主要为了解决大客户个性化定制开发的问题。从1946年计算机技术产生，自古以来，就从来没有。

本文来自微信公众号：阿朱说（ID：azhushuo），作者：吕建伟