很多人說：微服務的價值是復用、方便靈活組合

很多人說：PaaS平臺的價值是方便定制開發

我想說，這都什么人傳出來的謠言。

這都是白日做夢。從來沒有一種技術是為了方便修改和定制開發

（1）微服務是怎么來的

一、面向函數和面向對象

1946年產生了計算機以后，由于計算能力和存儲能力限制，人們寫的代碼有限，所以當時都是流水代碼，一邊讀卡器讀入，另一邊電傳打字機打印出來結果。

后來計算能力（晶體管與硅芯片）和存儲能力（磁芯與磁盤）提升了，人們寫的代碼可以更長了。為了更好地閱讀代碼，人們把代碼分割成了函數。

后來，大規模集成電路產生了，計算能力和存儲能力更進一步，函數也變的更多了，需要把函數也分分堆兒，于是物以類聚，面向對象編程產生了。

所以說：面向函數和面向對象，主要目的是為了解決代碼有組織性。

至于所謂的復用？你如果設計的輸入參數、輸出參數、返回值沒有精心設計好，根本不可能達到復用。

二、面向組件和面向服務

RPC，局域網中跨服務器的遠程過程調用，在1987年就由Sun公司和HP公司領導創立了。

面向組件產生于1990年。主要是為了解決跨開發語言、跨操作系統進程、跨服務器的應用程序之間互相調用的問題。這里以IBM為領導的CORBA組件體系、微軟的COM組件體系為代表。1997年，Sun公司集大家之所長，制定了J2EE標準，這也是一種面向組件的技術體系。因此有了大家熟悉的EJB。

但是，1997年也是互聯網最狂熱的時代。1999年，WebService技術產生。這樣，應用程序之間互相調用就不限于局域網了，更可以延伸到互聯網。因此出現了面向服務，意思就是for WebService。所謂的服務，其實特指的就是WebService。

所以說：面向組件和面向服務，主要是為了解決應用程序之間互相調用的問題。

三、面向微服務和面向函數服務

但是大家都知道，不管是組件技術棧，還是WebService技術棧，都日益復雜。

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

不要組件（直接JAVA類就OK）、不要組件服務器（直接Spring編程框架就好），不要WebService（直接RESTful就好）。于是這就演變到了面向微服務。

2014年，AWS更提出Serverless無服務器編程（函數服務），直接在云上編程云上運行，不需要操心下面的一切。

所以說：面向微服務和面向函數服務，主要是為了簡化面向服務編程的復雜性。

所以，從1946年計算機技術產生，自古以來，就沒有一種技術是為了解決所謂：復用、方便靈活組合。如果你沒有高級程序員（技術架構師），不精心設計你的應用程序的每個接口，光靠這些函數、對象、組件、服務、微服務技術，根本不可能做到復用、方便靈活組合。

但是，恰恰的是，我國應用軟件編程人員，就是萬金油編程人員，就懂得996加班把產品經理的功能趕快實現了，根本沒有足夠多的高級程序員（技術架構師）去負責精心設計應用程序的每個接口。

（2）PaaS平臺

一、低代碼開發平臺

不知道什么原因，低代碼開發平臺突然火起來了。而且不少人想拿低代碼開發平臺去解決大型客戶個性化定制開發的需求。

我想這不是南轅北轍了么？

低代碼開發平臺，能解決的是：擴展開發。也就是說：新的功能模塊的代碼快速生成與編寫。

至于你老的代碼，如何滿足一家家客戶的定制開發修改，尤其還是在現在公有云、SaaS多租戶的未來趨勢下。我想真是癡人說夢。

Salesforce都做不到現有的產品功能可以滿足一家家客戶的定制開發修改。

二、Open API開放平臺

Open API開放平臺主要解決的是：集成開發。

也就是說：你的系統，需要和客戶的系統集成在一起，如和客戶的CRM系統、財務系統、OA系統集成在一起，Open API開放平臺是必須的。

三、大數據平臺

至于查詢、搜索、數據挖掘、數據倉庫統計，以及報表、圖表可視化展示，用大數據平臺即可。

至于主數據服務、主數據訂閱/發布推送，用主數據管理系統即可。數據層面的集成，也主要是在主數據這塊。

也就是說，從來沒有一種平臺技術的發明，是主要為了解決大客戶個性化定制開發的問題。從1946年計算機技術產生，自古以來，就從來沒有。

總結

以上是生活随笔為你收集整理的从来没有一种技术是为了解决复用、灵活组合、定制开发的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。