本文来自微信民众号：阿朱说（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），作者：吕建伟