微服務是繼SOA以後流行起來的一種系統架構模式。因它緊隨SOA以後,因此有必要對他們先做個比較。react
關於兩者的比較表格,我在谷歌上搜索的一篇文章分析的挺好,現引用以下。git
面向服務架構 | 微服務架構 |
---|---|
出現於1990's年代 | 出現於2000's年代 |
最大化應用服務的重用性 | 關注解耦 |
系統變化須要修改總體 | 系統變化是建立新服務 |
DevOps和持續發佈開始變得流行但不是主流 | 重點關注DevOps和持續發佈 |
聚焦於業務系統重用 | 「邊界上下文」愈加重要 |
使用ESB通訊 | 使用簡單消息系統通訊 |
支持多種消息協議 | 使用輕量級協議諸如:HTTP, REST等 |
對部署在其上的全部服務使用通用平臺 | 一般使用雲平臺而非應用服務器 |
Docker不太流行 | 容器與微服務工做的很是協調 |
SOA服務共享數據存儲 | 每一個微服務能夠擁有獨立的存儲服務 |
通用的治理和標準 | 鬆散治理,關注團隊協做與自由選擇 |
<!--more-->github
微服務這麼流行,確定有其優點所在。不過也不能不看到它的劣勢噢。spring
如何揚長避短,更好更方便地利用微服務呢。數據庫
統一配置中心。編程
服務發現後端
一個事件總線,利用分佈式消息系統將服務和服務實例連到一塊兒。可用於在集羣內傳播狀態變化(如配置變化事件)api
集成你的應用到Pivotal Cloud Foundry,提供而且讓實現SSO和OAuth2來保護資源變得更加容易。服務器
提供一個用於構建實現了Open Service Broker API的服務的Broker的起始點架構
Open Service Broker API鏈接開發者到一個全球的服務生態環境,該項目給開發者、ISVs、SaaS廠商提供一個單一的、簡單的和完美的方式去發佈服務到原生雲平臺上(諸如Cloud Foundry, OpenShift, Kubernetes)
提供基於Zookeeper、Redis、Hazelcast、Consul的領頭選舉、通用狀態機模式的抽象及實現。
基於Hashicorp Consul的服務發現及配置管理。
提供對基於負載均衡的OAuth2 rest client和authentication header的支持,依賴了Zuul proxy。
應用於Spring Cloud的分佈式追蹤功能,與Zipkin, HTrace and log-based (e.g. ELK) tracing 相兼容。
一個cloud-native的服務編排,易用的DSL、drag-and-drop GUI,REST-APIs 一塊兒全面簡化了基於服務編排的數據管道。
一個輕量級的事件驅動微服務框架,便於快速構建鏈接到外部系統的應用。簡單的聲明模型可使用Apache Kafka或RabbitMQ在Spring Boot應用間收發消息。
一系列基於Spring Boot的Spring集成應用程序,提供與外部應用的集成。
一個短時間的微服務框架,快速構建執行有限數量的數據處理的應用。簡單的聲明就能夠增長功能性或非功能性特性到Spring Boot中。
一系列單機版的可執行應用程序,能夠擁有按需用例:好比數據庫遷移、機器學習、定時操做。這些應用能夠運行於各類獨立平臺,好比:Cloud Foundry、Apache Yarn、 ApacheMesos、Kubernetes、Docker甚至你的筆記本上。
基於Apache Zookeeper的服務發現及配置管理。
使得運行於各類平臺上的PaaS應用可以方便地鏈接到後端服務,好比數據庫、消息Broker。(這個項目原先叫做Spring Cloud)
Spring Boot風格的啓動項目,簡化服務消費方Spring Cloud的依賴管理。
Spring Boot CLI插件,用來快速使用Groovy語言建立Spring Cloud組件應用
是一攬子有關幫助用戶成功地實現「消費端驅動契約」方式解決方案
是一款基於智能的、可編程的路由的Project Reactor
爲Spring Boot應用提供經過自動化配置和綁定到Spring Environment和其它編程模型風格的集成。
原文發表於http://www.yesdata.net/2018/03/15/microservice-and-spring-cloud/
·