從來沒有一種技術是為了解決複用、靈活組合、定製開發的問題

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

很多人說：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年計算機技術產生，自古以來，就從來沒有。