不依賴

Dubbo是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案
主要核心部件
Remoting: 網路通訊框架，實現了sync-over-async 和 request-response 訊息機制.
RPC: 一個遠端過程呼叫的抽象，支援負載均衡、容災和叢集功能
Registry: 服務目錄框架用於服務的註冊和服務事件釋出和訂閱。
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring載入Dubbo的配置即可，Dubbo基於Spring的Schema擴充套件進行載入。

二者無法相提並論好嗎？dubbo僅是rpc通訊解決方案，spring cloud是微服務全棧解決方案，

不能用轎車和車輪子對比孰優孰劣！不在一個層次，阿里系對應的是spring cloud alibaba

springcloud 和 spring cloud alibaba二者誰會被淘汰？

1，就技術本身，二者差異不大，選擇a和b技術都可以解決業務問題，各個微服務元件實現優劣不是特別明顯，只是alibaba版本更貼近“本地生活”，本地佈道者（di tui）優勢

2，使用範圍，spring cloud面向全球，地球人使用最多，也就意味著不易消亡

比如rust語言比c++有更多優勢，但除非有變態級優勢，短期代替可能性很小

3，但從開源的態度上，alibaba版本更傾向服務於自家雲生態，政治任務濃重，著眼比較侷限

Spring cloud應該和spring，springboot類似，是真正的開源產品，

它們都淘汰也是早晚的事畢竟是java閉源。隨著service mesh的興起，isito的落地並於k8s的無縫融合，一切像基礎設施下沉

現在兩個都在維護之中，各有所長，dubbo開源的比較早，但是當年的停更，讓大多人有點不敢使用，好像記得當年有個dubbox，是噹噹網對dubbo的一個維護分支。

感覺當年阿里如果繼續維護和完善這個dubbo，今天微服務的市場都是它的，但是人生木有如果，停更了幾年，後來都轉到springcloud上了，後面dubbo才重新恢復更新，在銀行或者電信某些系統還用著dubbo，我曾經也用過也去維護過dubbo的系統，生態上與springcloud差太遠了，人家一整套元件都完善了。

不過springcloud的元件大多是依賴第三方的，這些年也發生了一些變化，停更，閉源等等操作，逼得spring組織不得不自己去開發這些元件，但是阿里後面也加入springcloud大家庭，當下springcloud選元件都以阿里係為主，nacos，seata，sentinel等，將來哪個會被淘汰真不好說，因為阿里釋出的這些元件都可以應用到dubbo中，自家產品自己可用，得看市場選擇。

其實分散式架構有對應的概念和思維，剩下的都是看怎麼去實現而已，我們應該關注思維而不是具體的框架。

事實上，很多系統根本就沒必要用什麼所謂微服務。目前過度設計已經氾濫，明明是一個使用者數量有限，功能並不複雜的系統，也要套用所謂的微服務架構，或者要大搞所謂中臺，既浪費時間，又浪費金錢，最後系統運維還比較複雜，需要持續投入運維。

以服務呼叫的方式，固然可以有更好的複用性，也可以解耦複雜系統。但實際上，我認為微服務也僅僅是元件化的一種實現方式。對於元件化，廣義的講，有多種實現方式：

第一種，最原始的方式就是以靜態函式庫或者包的形式存在。這種形式優點是開發方式簡單，呼叫效率高，資料以引數方式進行傳遞，但耦合度也高，底層元件函式一旦發生變化，則需要重新編譯整個工程。通常對於不經常發生變化的基礎函式庫，可以用這種形式進行開發，形成所謂的公共函式庫，供大家使用。

第二種，稱之為動態函式庫，在windows環境下以dll形式存在，linux環境下以so形式存在。動態函式庫相對於靜態函式庫，優勢在於可以在執行時動態載入，可以在不用重新啟動整個應用的情況下進行更新。缺點是動態函式不能共享原應用程式的儲存空間，導致動態函式呼叫有時需要傳遞大量引數，導致一些不便。動態函式庫也具有一定耦合度，函式名和引數必須嚴格按照約定呼叫，否則會報錯。在早期單體架構下，動態函式庫還是有大量使用的。

第三種，就是目前所謂的微服務架構了。微服務事實上也是可以看作是一種函式呼叫方式，提供基於RPC和restful遠端呼叫方式。呼叫時需要傳遞呼叫的服務名稱及資料報文。這種方式耦合度自然是比較低一些的，但是呼叫效率肯定低於函式呼叫方式，主要是資料傳輸和報文解析方面消耗的時間。此外還需要考慮通訊流量控制，超時機制，服務定址，服務可用性等方面的問題。因而降低耦合度，事實上是以增加了系統的整體複雜度和降低呼叫效率為代價的。個人認為不應該過度解耦，或者僅僅強調可複用性。要知道，任何事情都是有代價的，必須要充分評估這種代價是否值得。

第四種，就更進一步，即以獨立的系統存在，該系統具有獨立性和完備性，可以不過於依賴其他外部系統獨立執行，對外部以服務或api的形式進行互動。例如，單點登入系統，信貸系統，核心系統等。

因而，在系統架構設計和建設過程中，必須認真進行評估，不應該過分側重於某一方面特性的實現，否則就是過猶不及，最後導致整體出現問題。

個人認為，目前大部分所謂基於微服務的中臺系統就是陷入了過於強調解耦的誤區，導致過度的解耦設計，而忽略了由此帶來的弊端，最後陷入了泥潭。

spring cloud和dubbo哪個會被淘汰？

首先談到微服務我們不難想象到從單體架構 → 分散式架構 → SOA架構 → 微服務架構 →雲服務架構 → 低程式碼架構平臺

我們來細化一下分類：

單體架構：

分散式架構：

分散式架構就是將傳統結構按照模組進行拆分，根據業務進行模組化拆分。

SOA架構：

SOA架構就是將業務邏輯層提取出來，將相似的業務邏輯形成一個服務，提供外部訪問介面，服務之間訪問透過RPC呼叫實現。就像我們的webservice一樣，提供報文引數，定義指定格式進行配置讀取，資料推送，比如我們的資料採集，涉及到硬體互動的我們一般都採用scoket進行通訊，因為我們要保持一個長連結，並且基於c/s架構模式，從而更加穩定。

微服務架構：

微服務架構產生的場景，我們的業務發展到很大的規模的時候，我們的架構不足以支撐我們的產品，並且做業務拓展的時候，我們就要選擇微服務架構進行服務之間的業務分離，並且做服務拓展，服務移植，最常見的微服務架構就是springcloud 基於國外的Netflix公司研發的微服務架構，但是仔細去看springcloud其實你會發現有很多元件，並且springcloud是基於spring架構去升級的一版微服務架構。

微服務架構確實是一種全新的技術解決方案，並且是微服務裡面的佼佼者，大型網際網路首選架構，具體是因為業務需求要使用微服務架構，比如我們的教育，金融，電商，醫療都會採用微服務架構去提升我們程式的穩定性和高可用性，那有人會說了那我單體不也一樣可以提高程式的高可用性，並且提高程式的維護性，答案自然就是錯的？因為所有的業務都寫在單體裡面特別難維護，更不用說移植和拓展，程式碼的層級架構太深，也許你一天都找不到幾個實現類在哪裡，所以專案的架構的過渡是很有必要的。

雲服務架構：

雲服務架構？什麼是雲服務架構，雲服務我們常見的國內，阿里雲，騰訊雲，火山引擎，第三方雲，七牛雲等，都是為了幫我們解決實際性業務需求。

低程式碼架構平臺：什麼是低程式碼平臺？

低程式碼平臺的概念就是透過不會程式設計的人來操作，從而實現我們程式的自動化和部署，聽起來是不是很高大上，百分之60的人不知道低程式碼平臺是什麼？

國內的程式碼平臺：

1、釘釘宜搭（低程式碼開發平臺），阿里雲公司旗下產品，於2019年3月上線，流程較簡單，阿里生態圈。宜搭是一種面向業務開發者的零程式碼業務應用搭建平臺。開發者可以在視覺化介面上以拖拉拽的方式編輯和配置頁面，表單和流程，並一鍵釋出到PC和手機端。2020年1月23日-6月30日，疫情期間，阿里巴巴旗下產品宜搭向全社會免費開放，僅供防疫相關用途（包括但不限於疫情統計，健康上報、返工統計等）。

2、織信Informat（低/零程式碼開發平臺），由深圳基石協作科技有限公司自主研發，公司成立於2019年，團隊99人，註冊資本2000萬，法人郭閆閆，開發是程式語言是Java，簡單易上手，介面較友好舒適，關鍵還免費。

3、奧哲（低程式碼開發平臺），由深圳奧哲網路科技有限公司自主研發，公司成立於2010年，團隊285人，註冊資本2000萬，法人徐平俊，釘釘參股，深度整合。

4、思泉雲（低程式碼開發平臺），由深圳市思泉軟體有限公司研發，公司成立於2004年，團隊26人，註冊資本500萬，法人雷文成，.Net平臺，工作流功能強大。

5、JEPaas（低程式碼開發平臺），由北京凱特偉業科技有限公司研發，公司成立於2008年成立，團隊45人，註冊資本1000萬，公司法人閆建偉，開發是程式語言是Java，有開源版。

6、炎黃盈動（低程式碼開發平臺），由北京炎黃盈動科技發展有限責任公司研發，公司成立於2003年，團隊136人，註冊資本2105萬，法人劉金柱，文件詳細，老闆Java大牛。

8、JEECG（低程式碼開發平臺），由北京國炬資訊科技有限公司研發，公司成立於2015年，團隊8人，註冊資金100萬，法人張代浩，人氣開源軟體，功能較簡單。

9、明道雲（低/零程式碼開發平臺），由上海萬企明道軟體有限公司研發，公司成立於2013年，團隊38人，註冊資金64萬，法人任向暉，docker釋出，用到程式技術比較多，react、java、C#、nodejs。基於B/S架構，快速搭建工作流+表單的SaaS產品，開放一些API介面，工作流強大，而且是網際網路產品直接使用無需下載，從產品角度講非常出色，適合業務人員使用，同時還支援釘釘、企業微信，桌面系統使用。

10、簡道雲（低程式碼開發平臺），由帆軟軟體有限公司研發，公司成立於2018年成立，團隊883人，註冊5000萬，法人薛愛華，屬於是釘釘整合，主營業務BI報表。

11、ApiConfig（低/零程式碼開發平臺），ApiConfig是一款支援分散式的視覺化的的微服務的API配置化開發平臺；透過該平臺可以無需任何編碼的快速釋出各種API服務。

13、牛刀（低程式碼開發平臺），牛刀Low-Code低程式碼開發雲，高效全棧開發、跨端App開發，自由釋出，靈活部署提供開發、測試、部署、運維的一體化支援，真正低程式碼、高效率的DevOps開發運維一體化平臺。

14、氚雲（低程式碼開發平臺），一款面向管理者或業務人員的線上管理工具，與阿里釘釘深度整合,透過視覺化表單、流程設計、智慧報表和模板化應用，幫助企業輕鬆快速構建專屬應用。

15、搭搭雲（低程式碼開發平臺），企業前後臺打通的的低程式碼超級應用平臺，在一個雲端賬戶內可以定製和使用各種企業應用，並可線上實時調整，即改即用，移動端免開發實時同步。開發者還可以透過程式碼自由開發。

16、APICloud（低程式碼開發平臺），領先的移動應用雲服務平臺,為開發者提供多樣化的APP開發工具,如Sublime、Webstorm、Eclipse、Atom、CLI工具等。APICloud專注於手機APP開發、手機APP製作等。

國內的低程式碼平臺確實做得還行，畢竟我們在偷懶的這件事就做得特別好，開源上遠不能和國外相比。用友apicloud在雲服務上多端開發確實做得比較好，當然別的都可以，畢竟也是花錢的東西。

國外的低程式碼平臺：

1、Power Apps

微軟團隊開發的一款SaaS產品，提供應用程式開發環境，協助無程式碼快速自定義應用開發；同時提供開發擴充套件功能，專業的技術開發人員可建立資料和元資料，實現自主開發，擴充套件應用邏輯、建立自定義聯結器或實現資料整合。

功能點：

利用Power Apps可建立畫布、模型驅動應用和門戶設計三類應用。

儲存於Dataverse的資料型別和關係可以直接在Power Apps中使用，無需整合即可構建應用程式。

相容性強，內建豐富資料介面，可與Microsoft365、Dynamics CRM等平臺相連。

可在Web或移動端執行。

Microsoft已形成了良好的應用開發生態，跨平臺應用及聯動效能強，但虛擬機器用起來較緩慢，使用感欠佳。介面配置邏輯主要遵循excel的公式，前端程式碼視覺化，實現UI互動還是需要懂一些程式碼。

2、App Maker

谷歌旗下的一款低程式碼應用平臺，開發的初衷是為解決通用軟體開發無法解決的應用程式開發問題，2018年正式上線，對外開放。

功能點：

網頁端即可建立應用

拖拽UI完成介面開發，透過元件設定資料來源完成後端資料連線

提供定製開發服務

提供API介面

提供擴充套件功能，可與專案管理Asana、進銷存管理Zoho Invoice等第三方應用整合。

無程式碼應用開發、應用整合擴充套件，基於Google雲環境，國內開發者適用性較弱。

3、Mendix

簡介：美國原生代低程式碼應用開發廠商，2018年被西門子收購，被Gartner評為低程式碼應用開發平臺的全球領導者之一。

功能點：

提供“所見即所得”的介面和適用於所有人員的無程式碼應用開發環境，賦能業務人員開發；

同時向專業開發人員提供高階應用處理的低程式碼開發服務。

提供資料庫及核心系統的連線元件，可以實現CRM、ERP等獨立應用資料的聯通。

以Mendix為核心，可搭建各種開放性生態系統，2019年西門子將低程式碼Mendix與工業網際網路MindSphere平臺結合，推出了Xcelerator軟體產品，試圖用低程式碼賦能，利用Mendix實現個性化應用的配置，加速工業網際網路的落地，實現資料的互聯互通。

不只專注於工業領域，可賦能各種個性化應用場景。落地騰訊雲，目前正在向中國市場進發，上汽、富士康旗下的雲智匯科技服務有限公司均運用Mendix平臺開發了應用。

4、OutSystems

OutSystems2015年開始轉型，專注提供雲服務；2017年釋出低程式碼新版本，引入新DevOps功能；2018年獲KKR和高盛融資，發展勢頭強勁。Gartner曾評價：OutSystems是將低程式碼功能與高階移動功能相結合的唯一解決方案。估值超10億美元，OutSystems或許有望跑贏Mendix，成為低程式碼界的獨角獸。

功能點：

打破傳統程式碼編寫方式，提供圖形化控制元件，實現應用程式的視覺化開發。

同時支援編寫程式碼，可輕鬆實現系統整合。

提供雲、本地部署和混合部署模式，部署可以基於容器。

AWS和Azure版本均支援接入IoT、AI等基礎雲服務。

提供CRM/ERP等應用場景的解決方案及各類移動應用程式的搭建服務。

面向專業的開發者，程式碼能力要求高，工具控制元件不夠豐富；IDE介面古老，操作不友好。

得出結論：

低程式碼是企業數字化發展的強大助力，特別是對中小企業使用者而言，能為這些企業降本增效、發展加成。但國外低程式碼平臺發展路徑整體不同於國內零/低程式碼產品的發展，中國低程式碼產商雖湧入了諸多玩家，但仍然處於市場增量環節。

從目前的發展看，低程式碼平臺在功能上，也有望從邊緣的、流程性業務向核心功能開發轉變。未來可期啊，畢竟數字化轉型這一階段已經到來了，再談微服務貌似有點潛移默化了。

兩個都會被淘汰，Java 在容器時代落伍了，隨著K8s 的不斷流行，Java 的使用率正在急劇下降，可以看每個月的程式語言排行榜就可以預知。

dubbo明顯會小眾話，畢竟兩種框架的側重不同。加上sc的生態和元件更完整，節約出的架構成本是很明顯的。至於淘汰，三五年內都不會，以後就不知道了，畢竟Java新東西的生命週期就這麼長