⑴ 微服務有哪些設計原則
微服務應用4個設計原則：
作為一個原則來講本來應該是個「無狀態通信原則」，在這里我們直接推薦一個實踐優選的Restful 通信風格 ，因為他有很多好處：
無狀態協議HTTP，具備先天優勢，擴展能力很強。例如需要安全加密是，有現成的成熟方案HTTPS可用。
JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好。
語言無關，各大熱門語言都提供成熟的Restful API框架，相對其他的一些RPC框架生態更完善。
當然在有些特殊業務場景下，也需要採用其他的RPC框架，如thrift、avro-rpc、grpc。但絕大多數情況下Restful就足夠用了。
⑵ 微服務和前端的關系
微服務是後端架構，前端如vue框架使用微服務和其他語言類似，分為前端團隊和後端開發相互開發對接即可。
推薦一個開源項目。採用vue3作為前端框架。
MateCloud 基於Spring Cloud Alibaba推出的微服務快速開發平台，集成Nacos 2.0.3、Sentinel 1.8.2、Jetcache等諸多中間件。前端採用Vue3.2.4、Vite 2.5.1、Ant-Design-Vue 2.2.6、TypeScript的大型中後台解決方案。 其中前端4.0.8-M2版本正在發布，實現了系統管理的基礎功能，主要包括菜單管理、用戶管理、角色管理、部門管理、日誌管理、客戶端管理等功能。正持續更新中，歡迎體驗。
網路搜索MateCloud即可。
⑶ Kubernetes的部署策略，你常用哪種
確定哪種Kubernetes部署方法最適合不斷的推出，而不會影響用戶的更新。當今開發雲原生應用的最大挑戰之一是加快部署的速度。通過微服務方法，開發人員已經開始使用並設計完全模塊化的應用，允許多個團隊同時編寫和部署更改到應用去。
更短和更頻繁的部署提供了以下優勢：
但隨著更頻繁的發布，對應用可靠性或客戶體驗產生負面影響的可能性也會增加。這就是為什麼DevOps團隊必須開發流程和管理部署策略，以最大限度地降低產品和客戶風險的原因。
以下，一起討論Kubernetes的部署策略，包括滾動部署和更高級的方法，如金絲雀及其變體。
根據你的目標，可以利用幾種不同類型的部署策略。例如，可能需要將更改推廣到特定環境以進行更多測試，或者是用戶/客戶的子集，或者你可能需要在創建「一般可用」功能之前進行一些用戶測試。
滾動部署是Kubernetes的標准默認部署。它逐個緩慢地工作，使用新版本的pod替換以前版本的應用的pod，而不會導致任何集群停機。
在開始縮小舊容器之前，滾動更新會通過准備探針等待新的pod就緒。如果出現問題，可以中止滾動更新或部署，而無需關閉整個集群。在此類部署的YAML定義文件中，新鏡像將替換舊鏡像。
通過調整清單文件中的參數，可以進一步細化滾動更新：
在這種非常簡單的部署中，所有舊的pod都被一次性殺死，並且用新的pod一次全部替換。
這個清單看起來像這樣：
在藍/綠部署策略（有時稱為紅/黑）中，舊版本的應用（綠色）和新版本（藍色）同時部署。當部署這兩個用戶時，用戶只能訪問綠色，而藍色可供QA團隊在單獨的服務上進行測試自動化或通過直接埠轉發。
在測試新版本並簽署發布後，該服務將切換為藍色版本，舊版綠色版本將按比例縮小：
金絲雀部署有點像藍/綠部署，但更受控制並使用更「 漸進式交付 」的分階段方法。有許多策略屬於金絲雀的保護范圍，包括灰度發布或A/B測試。
當你想要測試一些新功能時，通常在應用程序的後端使用金絲雀。傳統上，你可能擁有兩個幾乎完全相同的伺服器：一個用於所有用戶，另一個用新功能推送到一部分用戶然後進行比較。如果未報告任何錯誤，則新版本可逐漸推廣到基礎架構的其餘部分。
雖然可以通過替換舊的和新的pod來使用Kubernetes資源來完成此策略，但使用像Istio這樣的服務網格實現此策略會更方便，更容易。
例如，你可以在Git中檢查兩個不同的清單：GA標記為0.1.0，金絲雀標記為0.2.0。通過更改Istio虛擬網關清單中的權重，可以管理這兩個部署的流量百分比。
管理金絲雀部署的一種簡單有效的方法是使用Weaveworks Flagger。
使用Flagger，金絲雀部署的推廣是自動化的。它使用Istio或App Mesh來路由和轉移流量，使用Prometheus指標進行金絲雀分析。金絲雀分析還可以通過webhook進行擴展，以運行驗收測試，負載測試或任何其他類型的自定義驗證。
Flagger採用Kubernetes部署和可選的水平pod自動縮放器（HPA）來創建一系列對象（Kubernetes部署，ClusterIP服務和Istio或App Mesh虛擬服務），以推動金絲雀分析和推廣。
通過實施控制迴路，Flagger逐漸將流量轉移到金絲雀，同時測量關鍵性能指標，如HTTP請求成功率，請求平均持續時間和pod 健康 狀況。根據對KPI的分析，金絲雀被提升或中止，分析結果發布給Slack。
灰度部署是金絲雀的另一種變體（順便提一下，也可以由Flagger處理）。灰度部署和金絲雀之間的區別在於，灰度部署處理前端而不是後端的功能。
灰度部署的另一個名稱是A/B測試。你可以將其發布給少數用戶，而不是為所有用戶啟動新功能。用戶通常不知道他們被用作新功能的測試人員，因此稱為「灰度」部署。
通過使用功能切換和其他工具，你可以監控用戶與新功能的交互方式，以及是否正在轉換用戶，或者他們是否發現新的UI令人困惑以及其他類型的指標。
除了加權路由，Flagger還可以根據HTTP匹配條件將流量路由到金絲雀。在A/B測試場景中，你將使用HTTP標頭或Cookie來定位用戶的特定部分。這對需要會話關聯的前端應用特別有用。
⑷ 如何快速搭建一個微服務架構
什麼是微服務？
微服務(Microservices Architecture)是一種架構風格，一個大型復雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。
微服務的概念源於2014年3月Martin Fowler所寫的文章「Microservices」 martinfowler.com/articles/mi…
單體架構(Monolithic Architecture )
企業級的應用一般都會面臨各種各樣的業務需求，而常見的方式是把大量功能堆積到同一個單體架構中去。比如：常見的ERP、CRM等系統都以單體架構的方式運行，同時由於提供了大量的業務功能，隨著功能的升級，整個研發、發布、定位問題，擴展，升級這樣一個「怪物」系統會變得越來越困難。
這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用採用的語言，如果採用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用伺服器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包
上圖：單體架構
大部分企業通過SOA來解決上述問題，SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去。因此基於SOA架構的應用可以理解為一批服務的組合。SOA帶來的問題是，引入了大量的服務、消息格式定義和規范。
多數情況下，SOA的服務直接相互獨立，但是部署在同一個運行環境中（類似於一個Tomcat實例下，運行了很多web應用）。和單體架構類似，隨著業務功能的增多SOA的服務會變得越來越復雜，本質上看沒有因為使用SOA而變的更好。圖1，是一個包含多種服務的在線零售網站，所有的服務部署在一個運行環境中，是一個典型的單體架構。
單體架構的應用一般有以下特點：
微服務架構（Microservices Architecture）
微服務架構的核心思想是，一個應用是由多個小的、相互獨立的、微服務組成，這些服務運行在自己的進程中，開發和發布都沒有依賴。不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。簡單的來說，一個系統的不同模塊轉變成不同的服務！而且服務可以使用不同的技術加以實現！
上圖：微服務架構
微服務設計
那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：
微服務消息
在單體架構中，不同功能之間通信通過方法調用，或者跨語言通信。SOA降低了這種語言直接的耦合度，採用基於SOAP協議的web服務。這種web服務的功能和消息體定義都十分復雜，微服務需要更輕量的機制。
同步消息 REST
同步消息就是客戶端需要保持等待，直到伺服器返回應答。REST是微服務中默認的同步消息方式，它提供了基於HTTP協議和資源API風格的簡單消息格式，多數微服務都採用這種方式（每個功能代表了一個資源和對應的操作）
非同步消息 – AMQP, STOMP, MQTT
非同步消息就是客戶端不需要一直等待服務應答，有應到後會得到通知。某些微服務需要用到非同步消息，一般採用AMQP, STOMP, MQTT 這三種通訊協議
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服務中另外一個很重要的因素。SOA的web服務一般採用文本消息，基於復雜的消息格式（SOAP）和消息定義（xsd）。微服務採用簡單的文本協議JSON和XML，基於HTTP的資源API風格。如果需要二進制，通過用到Thrift, ProtoBuf, Avro。
服務約定 – 定義介面 – Swagger, RAML, Thrift IDL
如果把功能實現為服務，並發布，需要定義一套約定。單體架構中，SOA採用WSDL，WSDL過於復雜並且和SOAP緊耦合，不適合微服務。
REST設計的微服務，通常採用Swagger和RAML定義約定。
對於不是基於REST設計的微服務，比如Thrift，通常採用IDL（Interface Definition Languages），比如Thrift IDL。
微服務集成 (服務間通信)
大部分微服務基於RPC、HTTP、JSON這樣的標准協議，集成不同標准和格式變的不再重要。另外一個選擇是採用輕量級的消息匯流排或者網關，有路由功能，沒有復雜的業務邏輯。下面就介紹幾種常見的架構方式。
點對點方式
點對點方式中，服務之間直接用。每個微服務都開放REST API，並且調用其它微服務的介面。
上圖：通過點對點方式通信
很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨著應用復雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，盡量不採用點對點的集成方式。
API-網關方式
API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。
上圖：通過API-網關暴露微服務
所有的業務介面通過API網關暴露，是所有客戶端介面的唯一入口。微服務之間的通信也通過API網關。
採用網關方式有如下優勢：
目前，API網關方式應該是微服務架構中應用最廣泛的設計模式。
消息代理方式
微服務也可以集成在非同步的場景下，通過隊列和訂閱主題，實現消息的發布和訂閱。一個微服務可以是消息的發布者，把消息通過非同步的方式發送到隊列或者訂閱主題下。作為消費者的微服務可以從隊列或者主題共獲取消息。通過消息中間件把服務之間的直接調用解耦。
上圖：非同步通信方式
通常非同步的生產者/消費者模式，通過AMQP, STOMP, MQTT 等非同步消息通訊協議規范。
數據的去中心化
單體架構中，不同功能的服務模塊都把數據存儲在某個中心資料庫中。
每個微服務有自己私有的資料庫，其它微服務不能直接訪問。單體架構，用一個資料庫存儲所有數據
微服務方式，多個服務之間的設計相互獨立，數據也應該相互獨立（比如，某個微服務的資料庫結構定義方式改變，可能會中斷其它服務）。因此，每個微服務都應該有自己的資料庫。
每個微服務有自己私有的資料庫，其它微服務不能直接訪問。每個微服務有自己私有的資料庫，其它微服務不能直接訪問。
數據去中心話的核心要點：
數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的資料庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。
微服務架構的優點：
微服務架構的缺點：
微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其復雜性。
關於微服務架構的取捨
⑸ 微服務架構下，進行前後端分離，前端怎麼寫
分離後的前端，不再是一個簡單的HTML文件，已經是一個獨立的應用系統。除了要考慮頁面的數據渲染展示，還要用工程化的思想來考慮前端的架構，前後端的交互和數據安全等事情。
RESTful介面交互
前後端分離之後，更多的是採用RESTful風格的介面與後端進行數據交互。
REST是「呈現狀態轉移（REpresentational State Transfer）」的縮寫，一種API的架構風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。
在 REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。
RESTful的API設計，使得後端通過介面向前端傳遞數據，數據的格式通常是JSON這種通用的格式。對前端來說，只要後端返回過來的是RESTful的數據就行，不管後端是用Java寫，還是用python或PHP，拜託對後端的依賴，做到前端系統的獨立。
工程化構建
Nodejs不止可以用來做前端伺服器，在開發階段，它也能發揮很大的作用。
前端生態的發展，是圍繞著Nodejs進行的。用npm來管理項目依賴，可以很好的維護和運行在Nodejs環境上。
打包工具grunt、gulp、webpack和rollup等，都是運行在nodejs上，再結合語法編譯、打包部署等插件，將應用輸入成一個完整的應用。
如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時還不兼容的ES6語法，還需要在應用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。
SPA
SPA是單頁Web應用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應用，是載入單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
像Angular、React或Vue就是為了SPA而設計的，結合前端路由庫（react-router、vue-router）和狀態熱存儲（rex、vuex）等，可以開發出一個媲美Native APP的Web APP，用戶體驗得到了很大的提升。
當然，SPA也不是完美的，也不是適合所有的web應用，需要結合項目和場景來選擇。
SPA有如下缺點：
初次載入耗時增加。可以通過代碼拆分、懶載入來提升性能，減少初次載入耗時。
SEO不友好，現在可以通過Prerender或Server render來解決一部分。
頁面的前進和後端需要開發者自己寫，不過現在一些路由庫已經幫助我們基本解決了。
對開發者要求高，由於做SPA需要了解一整套技術棧，所以，要考慮後期是否有合適的人選進行維護。
⑹ 如何設計實現真正的響應式微服務系統
一、清晰輕量的產品邏輯
奧卡姆剃須刀法則同樣在產品架構設計中適用，越簡單的架構越有利於產品的生長。清晰輕量的產品邏輯，會減少用戶的負擔感，從而提高交互上的效率和愉悅感。
分析Material Design，會發現Google歸納了兩類復雜內容信息的層級關系，分別是Card和Tile（List
以及其他相似定義屬於同類的內容信息層級），其他定義多用於UI結構及細節。其中，Google定義Card是一種多功能信息的聚合入口，信息層級應較
高，體現在Z軸應高於其他信息，視覺上有陰影表現並加以圓角處理。而tile（或同類信息列表）則是（同類或相關）信息的模塊展現，信息層級應較低，體現
在Z軸應略低於其他信息，視覺上應無陰影表現不加圓角處理。其結果是從視覺層面讓產品對象更高效、更簡單，同時也更具物理世界的「真實感」。
最近接手的項目是Gekec.com的全站改版。Gekec（革客）是Geek和Maker交集，喜歡革新，喜歡技術范兒、新潮的科技消費品，喜歡
自己動手創造產品，Gekec.com也就是這類人的聚集地，整個產品囊括電商、資訊（或h5宣傳）、拆機、以及社區討論等各種功能，改版前邏輯復雜，功
能繁多。改版開始之初，筆者了解到革客群體時，便認為理性加濃重Geek味道的Google風格或許是最適合Gekec.com的視覺體系，然而復雜的產
品邏輯不能給用戶帶來高效的交互體驗和愉悅的使用感受，視覺上也並不能很好的通過Material
Design推演並且變化，所以梳理出清晰、輕量且方便視覺統一的產品邏輯成為第一任務。
Gekec.com的產品全功能在此並不贅述，Proct Feature全部為達成宜家式的體驗式設計，經過梳理可以歸納成三層，首層為體驗層（多入口的首頁封面）、第二層為貨架層（包括商城模塊、拆機模塊、體驗模塊）、第三層為詳細、操作層；
如上圖，輕量的產品結構即可方便設計的推演。例如其中第一層可以通過H5靈活排版做產品全方位體驗，第二層與第三層的關系即可利用Material
Card和Tile表現。Card表達了全部信息的聚合和入口，tile則表現同類信息的羅列。從card跳轉到最終頁應有一種卡片展開的體驗。
二、適宜UI推演的響應辦法
在產品邏輯清晰簡潔的基礎上，一套適宜Material Design變化的全尺寸響應辦法就成為復雜響應式網頁設計的核心內容，響應辦法能夠直接決定功能模塊的響應邏輯以及UI的變化。實際操作中，響應辦法的確定主要就是確定柵格和佔比。
1）柵格
網頁柵格系統是從平面柵格系統中發展而來。對於網頁設計來說，柵格系統的使用，不僅可以讓網頁的信息呈現更加美觀易讀，更具可用性。而且，對於前端
開發來說，網頁將更加的靈活與規范。柵格系統的具體含義以及使用方法在此不再贅述，感興趣的朋友可以參考淘寶UED的一些文章：
網頁柵格系統研究（1）：960的秘密
網頁柵格系統研究（2）：蛋糕的切法
網頁柵格系統研究（3）：粒度問題
網頁柵格系統研究（4）：技術實現
在Gekec.com的項目中，經歷產品功能模塊的梳理，筆者使用了12柵格系統，目的是能夠滿足2、3、4、6的頁面等分。註：具體柵格系統的建立應因產品和設計所決定，柵格系統並不是萬能的，而確定的柵格系統可以為整個響應式設計做規范性參考。
2）佔比
A.佔比
如上文說，12柵格約束網頁的內容區，而網頁的內容往往並不佔據屏幕的全部寬度，而是在兩側留有間隙，營造空間感。由於屏幕的限制，這種空間感在移動端設備顯得更加重要，如圖，然而強加固定的margin pixel會使得12柵格佔比不定，難以控制設計效果。
所以佔比應是12柵格寬度對應屏幕的比值，即：
12柵格寬度X佔比=屏幕寬（臨界點）
優秀而巧妙的佔比確定可以讓網頁設計呈現在各個主流屏幕上均是100%像素。
這里簡單解釋一下，若一個200px寬的元素在1200px寬的屏幕上，其佔比為16.67%，同樣的邏輯，到1024px的屏幕上這個佔比
16.67%的元素即占據了170.67px，這樣的情況下，某一個物理像素無法佔據100%，在完美主義的設計師眼裡，是無法接受的事情。而巧妙的占
比，可以讓元素在各個主流屏幕占據100%像素，完美展現設計意圖。
B.臨界點
臨界點（breakpoint）是指響應式網頁發生布局變化的關鍵點，如「當屏幕寬度小於480px時載入...樣式，當寬度在480px-
600px之間時載入…樣式」。響應式網頁理論上有無數種尺寸，我們不可能也沒有必要為每個尺寸都去做設計，需要做的是選定幾個臨界點做設計，在兩個臨界
點之間是延續上一個臨界點的布局。
臨界點確認總體目的就是為了保證頁面在手機（屏幕很小）、平板（屏幕中等）、PC（屏幕大）上載入相應的樣式，然而經驗較少的設計師往往會苦惱一個
問題，那就是高像素的手機屏幕和低像素的平板屏幕應如何處理。例如設計師會擔心1080p的手機載入大屏幕頁面，或者720p的平板載入小屏幕頁面。
但需要注意的是，響應式網頁不同於APP的屏幕適配。網頁是沉浸於瀏覽器的產品，瀏覽器所啟動的屏幕像素才可以被認為是臨界點的參考點，為此，筆者
做了一些測試，如下表，可以看出不少1080p手機在瀏覽器中僅啟動360px，而神奇的ipad無論是不是retina屏幕，無論是不是mini，均顯
示1024x768px 。
⑺ 微服務架構 如何影響傳統的軟體架構設計
ThoughtWorks首席咨詢師王磊通過一個互聯網門戶案例為大家解釋了微服務架構的概念，以及它如何影響傳統的軟體架構設計。
一年前，該門戶每簽一個10萬的合同所耗費的成本是3.5天。他們當時的CRM結構是典型的三層架構，整個應用程序由一個40萬行的代碼庫組成，後端有一個主動的資料庫。雖然使用三層架構的成本比較小，但隨著代碼和功能的增加，代碼庫不斷膨脹，修改代碼存在的風險很大，整個維護成本也變得越來越高。
每當開發人員提交代碼後，所需的數據集成和構建需要50分鍾，意味著每天8小時工作時間最多能有9次代碼提交。但為了系統的穩定性，持續集成過程中要盡量避免提交代碼，因此，整個團隊的交付能力受到了限制。此外，從准備部署包到上線需要3天，3天後才能讓用戶真正用到部署包，才能實現價值。而如果增加新人，要開發新的環境，包括測試和產品環境，培養周期會很長。針對以上難題，ThoughtWorks制定了如何在團隊中對系統進行改造從而滿足業務需求的策略。
將現有的系統保護起來，把所有開發新功能的優先順序都降下來，只需對系統做最緊急的修改，其他和部門進行協商，讓團隊保持新的精力和時間在重要的業務上。
功能剝離。通過定義新服務，在前端用一些代碼的機制讓用戶逐漸訪問新服務，可以達到從原有系統抽出小功能，讓客戶訪問小功能。
數據解耦。對於龐大的系統，因為無法很快將所有系統換掉，所以為了保證系統仍然可用，要啟用數據同步機制，讓服務里的數據同步到原有資料庫。
漸進替換。通過不斷地運行以上策略，將原有系統的復雜功能抽離出來用新的方式來做。
目前，每簽一個10萬的合同所耗費的成本由3.5天變為1天，持續集成構建從50鍾降低到18分鍾，團隊成員從10人降到7人，部署周期由3天降到2小時。
對於每個應用程序，可能有一組小的服務組成，每個服務運行在自己的進程中，服務與服務之間通過輕量級的機制進行交互。那麼，如何使用微服務做系統改造呢?
為每個服務建立獨立的環境，包括基礎設施、持續集成環境、運維、監控、日誌聚合、報警。
不斷演進的微服務開發模板，發現問題及時修改，讓模板更高效。
輕量級的通信協議。
消費者的契約測試，解決隨著服務增多帶來集成測試效率低的問題。
基礎設施自管理，幫助管理自己需要的資源。
⑻ 《微服務設計中文版》pdf下載在線閱讀全文，求百度網盤雲資源
《微服務設計中文版》網路網盤pdf最新全集下載:
鏈接: https://pan..com/s/1KYbkPkfUtirjguQnxVpdFA
簡介：全面介紹了微服務的建模、集成、測試、部署和監控，通過一個虛構的公司講解了如何建立微服務架構。主要內容包括認識微服務在保證系統設計與組織目標統一上的重要性，學會把服務集成到已有系統中，採用遞增手段拆分單塊大型應用，通過持續集成部署微服務。
⑼ 什麼是微服務架構主流的微服務如何實現
簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
1、SpringCloud
Spring Cloud , 來自Spring，具有Spring 社區的強大支撐，還有Netflix強大的後盾與技術輸出。Netflix作為一家成功實踐微服務架構的互聯網公司在幾年前就把幾乎整個微服務框架棧開源貢獻給了社區，這些框架開源的整套服務架構套件是Spring Cloud的核心。
- Eureka:服務注冊發現框架；
- Zuul:服務網關；
- Karyon：服務端框架；
- Ribbon：客戶端框架；
- Hystrix：服務容錯組件；
- Archaius：服務配置組件；
- Servo：Metrics組件；
- Blitz4j：日誌組件；
2、Dubbo
Dobbo是一個分布式服務框架，是阿里開放的微服務化治理框架，致力於提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。其核心部分(官網)
- 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式；
- 集群容錯: 提供基於介面方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持；
- 自動發現: 基於注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
Dubbo 也是採用全 Spring 配置方式，透明化接入應用，對應用沒有任何 API 侵入，只需用 Spring 載入 Dubbo的配置即可，Dubbo 基於 Spring 的 Schema 擴展進行載入。當然也支持官方不推薦的 API 調用方式。
3、lstio
lstio 作為用於微服務聚合層管理的新銳項目，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵），首個共同聯合開源的項目，提供了統一的連接，安全，管理和監控微服務的方案。
目前首個測試版是針對Kubernetes環境的，社區宣稱在未來幾個月內會為虛擬機和Cloud Foundry 等其他環境增加支持。lstio將 流量管理添加到微服務中，並為增值功能（如安全性、監控、路由、連接管理和策略）創造了基礎。
- HTTP、gRPC 和 TCP 網路流量自動負載均衡；
- 提供了豐富的路由規則，實現細顆粒度的網路流量行為控制；
- 流量加密、服務件認證，以及強身份聲明；
- 全范圍（Fleet-wide）的策略執行；
- 深度遙測和報告。