微服務技術框架有哪些

㈠ 主流的微服務架構有哪些

微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

中文名

微服務架構

外文名

microservice

服務平台

Imixs-Workflow

屬性

Seneca是構建微服務框架的工具

現狀

當下最新的熱門話題

快速
導航

現狀 特點 服務平台 工具開發

概念

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。[1]

現狀

微服務作為一項在雲中部署應用和服務的新技術已成為當下最新的熱門話題。但大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

企業和服務提供商正在尋找更好的方法將應用程序部署在雲環境中，微服務被認為是未來的方向。通過將應用和服務分解成更小的、鬆散耦合的組件，它們可以更加容易升級和擴展，理論上是這樣。

㈡ 什麼是微服務架構主流的微服務如何實現

簡單地說，微服務架構就是以業務域或業務功能為邊界，將一個大而全的應用拆分為可以獨立開發，獨立部署，獨立測試，獨立運行的一組小的應用，並且使用輕量級，通用的機制在這組應用間進行通信。
主流的微服務包括：
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）的策略執行；

- 深度遙測和報告。

㈢ 目前比較流程的微服務開發框架是

1.Spring Boot

Spring Boot的設計目的是簡化新Spring應用初始搭建以及開發過程，2017年有64.4%的受訪者決定使用Spring Boot，可以說是最受歡迎的微服務開發框架。利用Spring Boot開發的便捷度簡化分布式系統基礎設施的開發，比如像配置中心、注冊、負載均衡等方面都可以做到一鍵啟動和一鍵部署。

2.Spring Cloud

Spring Cloud是一個系列框架的合計，基於HTTP（s）的RETS服務構建服務體系，Spring Cloud能夠幫助架構師構建一整套完整的微服務架構技術生態鏈。



3.Dubbo

Dubbo是由阿里巴巴開源的分布式服務化治理框架，通過RPC請求方式訪問。Dubbo是在阿里巴巴的電商平台中逐漸探索演進所形成的，經歷過復雜業務的高並發挑戰，比Spring Cloud的開源時間還要早。目前阿里、京東、當當、攜程、去哪等一些企業都在使用Dubbo。

4.Dropwizard

Dropwizard將Java生態系統中各個問題域里最好的組建集成於一身，能夠快速打造一個Rest風格的後台，還可以整合Dropwizard核心以外的項目。國內現在使用Dropwizard還很少，資源也不多，但是與SpringBoot相比，Dropwizard在輕量化上更有優勢，同時如果用過Spring，那麼基本也會使用SpringBoot。

5.Akka

Akka是一個用Scala編寫的庫，可以用在有簡化編寫容錯、高可伸縮性的Java和Scala的Actor模型，使用Akka能夠實現微服務集群。

6.Vert.x/ Lagom/ ReactiveX/Spring 5

這四種框架主要用於響應式微服務開發，響應式本身和微服務沒有關系，更多用於提升性能上，但是可以和微服務相結合，也可以提升性能。



.Net相關微服務框架

1. .NET Core

.NET Core是專門針對模塊化微服務架構設計的，是跨平台應用程序開發框架，是微軟開發的第一個官方版本。

2.Service Fabric

Service Fabric是微軟開發的一個微服務框架，基於Service Fabric構建的很多雲服務被用在了Azure上。

3.Surging

Surging是基於RPC協議的分布式微服務技術框架，基於.NET Core而來。

4.Microdot Framework

Microdot Framework用於編寫定義服務邏輯代碼，不需要解決開發分布式系統的挑戰，能夠很方便的進行MicrosoftOrleans集成。

㈣ 微服務框架之Spring Cloud簡介

在了解 Spring Cloud 之前先了解一下微服務架構需要考量的核心關鍵點，如下圖：

對於以上等核心關鍵點的處理，不需要我們重復造車輪， Spring Cloud 已經幫我們集成了，它使用 Spring Boot 風格將一些比較成熟的微服務框架組合起來，屏蔽掉了復雜的配置和實現原理，為快速構建微服務架構的應用提供了一套基礎設施工具和開發支持。

Spring Cloud 所提供的核心功能包含：

Spring Cloud架構圖

Spring Cloud子項目

Spring Cloud 旗下的子項目大致可以分為兩類：

如下：

1. Spring Cloud 與 Spring Boot

Spring Boot 可以說是微服務架構的核心技術之一。通過在 Spring Boot 應用中添加 Spring MVC 依賴，就可以快速實現基於 REST 架構的服務介面，並且可以提供對 HTTP 標准動作的支持。而且 Spring Boot 默認提供 JackJson 序列化支持，可以讓服務介面輸入、輸出支持 JSON 等。因此，當使用 Spring Cloud 進行微服務架構開發時，使用 Spring Boot 是一條必經之路。

2. Spring Cloud 與服務治理( Eureka )

服務治理是 Spring Cloud 的核心，在實現上其提供了兩個選擇，即 Consul 和 Netflix 的 Eureka 。

Eureka 提供了服務注冊中心、服務發現客戶端，以及注冊服務的 UI 界面應用。

在 Eureka 的實現中，節點之間相互平等，有部分注冊中心「掛掉」也不會對整個應用造成影響，即使集群只剩一個節點存活，也可以正常地治理服務。即使所有服務注冊節點都宕機， Eureka 客戶端中所緩存的服務實例列表信息，也可讓服務消費者能夠正常工作，從而保障微服務之間互相調用的健壯性和應用的彈性。

3. Spring Cloud 與客戶端負載均衡( Ribbon )

Ribbon 默認與 Eureak 進行無縫整合，當客戶端啟動的時候，從 Eureka 伺服器中獲取一份服務注冊列表並維護在本地，當服務消費者需要調用服務時， Ribbon 就會根據負載均衡策略選擇一個合適的服務提供者實例並進行訪問。

Spring Cloud 通過集成 Netflix 的 Feign 項目，為開發者提供了聲明式服務調用，從而簡化了微服務之間的調用處理方式。並且默認 Feign 項目集成了 Ribbon ，使得聲明式調用也支持客戶端負載均衡功能。

4. Spring Cloud 與微服務容錯、降級( Hystrix )

為了給微服務架構提供更大的彈性，在 Spring Cloud 中，通過集成 Netflix 下子項目 Hystrix ，通過所提供的 @HystrixCommand 註解可以輕松為我們所開發的微服務提供容錯、回退、降級等功能。此外， Hystrix 也默認集成到 Feign 子項目中。

Hystrix 是根據「斷路器」模式而創建。當 Hystrix 監控到某服務單元發生故障之後，就會進入服務熔斷處理，並向調用方返回一個符合預期的服務降級處理（ fallback ），而不是長時間的等待或者拋出調用異常，從而保障服務調用方的線程不會被長時間、不必要地佔用，避免故障在應用中的蔓延造成的雪崩效應。

而 Hystrix 的儀表盤項目（ Dashboard ）可以監控各個服務調用所消耗的時間、請求數、成功率等，通過這種近乎實時的監控和告警，可以及時發現系統中潛在問題並進行處理。

5. Spring Cloud 與服務網關( Zuul )

Spring Cloud 通過集成 Netflix 中的 Zuul 實現 API 服務網關功能，提供對請求的路由和過濾兩個功能

路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎。

過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎。

通過 Zuul ，可以將細粒度的服務組合起來提供一個粗粒度的服務，所有請求都導入一個統一的入口，對外整個服務只需要暴露一個 API 介面，屏蔽了服務端的實現細節。通過 Zuul 的反向代理功能，可以實現路由定址，將請求轉發到後端的粗粒度服務上，並做一些通用的邏輯處理。此外， Zuul 默認會與 Eureka 伺服器進行整合，自動從 Eureka 伺服器中獲取所有注冊的服務並進行路由映射，實現 API 服務網關自動配置。

6. Spring Cloud 與消息中間件( Stream )

Spring Cloud 為簡化基於消息的開發，提供了 Stream 子項目，通過建立消息應用抽象層，構建了消息收發、分組消費和消息分片等功能處理，將業務應用中的消息收發與具體消息中間件進行解耦，使微服務應用開發中可以非常方便地與 Kafka 和 RabbitMQ 等消息中間件進行集成。

Spring Cloud Bus 基於 Stream 進行擴展，可以作為微服務之間的事件、消息匯流排，用於服務集群中狀態變化的傳播。

比如 Spring Cloud Config 藉助 Bus ，可以實現配置的動態刷新處理。

7. Spring Cloud 與分布式配置中心( Config )

針對微服務架構下的配置文件管理需求， Spring Cloud 提供了一個 Config 子項目。 Spring Cloud Config 具有中心化、版本控制、支持動態更新和語言獨立等特性。

在 Config 子項目中將微服務應用分為兩種角色：配置伺服器（ Config Server ）和配置客戶端（ Config Client ）。使用配置伺服器集中地管理所有配置屬性文件，配置服務中心可以將配置屬性文件存儲到 Git 、 SVN 等具有版本管理倉庫中，也可以存放在文件系統中。默認採用 Git 的方式進行存儲，因此可以很容易地對配置文件進行修改，並實現版本控制。

8. Spring Cloud 與微服務鏈路追蹤( Sleuth )

Spring Cloud 中的 Sleuth 子項目為開發者提供了微服務之間調用的鏈路追蹤。

Sleuth 核心思想就是通過一個全局的 ID 將分布在各微服務服務節點上的請求處理串聯起來，還原了調用關系，並藉助數據埋點，實現對微服務調用鏈路上的性能數據的採集。

因此，通過 Sleuth 可以很清楚地了解到一個用戶請求經過了哪些服務、每個服務處理花費了多長時間，從而可以對用戶的請求進行分析。此外，通過將採集的數據發送給 Zipkin 進行存儲、統計和分析，從而可以實現可視化的分析和展示，幫助開發者對微服務實施優化處理。

9. Spring Cloud 與微服務安全( Security )

Spring Cloud Security 為我們提供了一個認證和鑒權的安全框架，實現了資源授權、令牌管理等功能，同時結合 Zuul 可以將認證信息在微服務調用過程中直接傳遞，簡化了我們進行安全管控的開發。

Spring Cloud Security 默認支持 OAuth 2.0 認證協議，因此單點登錄也可以非常容易實現，並且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，進一步簡化了微服務中的安全管理。

10. Spring Cloud 的其他子項目

㈤ 微服務架構是什麼

微服務架構是一項在雲中部署應用和服務的新技術。

大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務架構相關介紹：

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。

在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。

如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。

服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

㈥ 主流微服務框架有哪些

分享13個可靠的Java微服務架構
1、Spring Boot
2、Eclipse MicroProfile
3、Dropwizard
4、WildFly Thorntail
5、Helidon
6、Cricket
7、Jersey
8、Play
9、Swagger
10、Restlet
11、Squash
12、Telepresence
13、Zipkin

㈦ 開源推薦-C++開發的微服務框架Tars

Tars致力於建設微服務技術生態，在底層基礎設施、服務框架、上層應用以及DevOps等方面，都做了較為深入的研發。

2020年3月10日，Linux基金會正式宣布旗下的TARS開源項目成立TARS子基金會。這是一個 專注於微服務領域 的開源基金會，致力於幫助企業擁抱微服務體系架構，解決在使用微服務方面可能出現的問題。這是首個 起源於中國開源項目 的國際開源基金會，也是Linux基金會下 唯一聚焦微服務技術生態 的子基金會。

Tars基金會里目前收錄了9個項目，分為5部分：工具集（Tars Lab）、服務治理（Service Governance）、微服務開發框架（Development Framwork）、存儲（DCache）和基礎設施（Infrustructure）。

1、Tars Lab

Tars Lab項目提供了壓力測試TarsJMeter，基準測試集TarsBenchmark和一些開發工具包。TarsJavaStart，可以生成服務端和客戶端的TarsJava腳手架，快速開始Tars服務的開發。TarsTools，是一款支持多種IDE的JetBrains插件，為實現編輯Jce/Tars文件使用的（支持Intellij IDEA、Android Studio、PhpStorm、WebStorm、GoLand、CLion等）。

2、服務治理

服務治理包含了2個項目：TSeer專注於處理服務注冊與發現；TarsGateway是基於Tars框架開發的微服務網關，除具備網關的基礎功能外，還可以自動將HTTP轉換成Tars-RPC協議。

3、微服務開發框架

這部分只包含Tars一個項目，核心模塊由C++開發，提供了多語言開發框架，默認rpc調用，是Tars基金會的核心項目。其他項目都是圍繞這個項目研發的。

4、微服務存儲

這部分只包含DCache一個項目，它是基於Tars框架開發的 分布式共享內存存儲系統 ，支持常用的kv數據結構、支持二級索引、支持在線擴縮容、支持自動持久化到後端db等特性。DCache依賴Tars框架的運行，但也得益於Tars，使得存儲服務的運維成本幾乎為0。

5、微服務基礎設施

這是一個將Tars與K8S融合使用的項目，致力於將Tars融入到K8S生態中。

在這方面還有一個更優秀的項目K8SFramework，致力於將Tars與K8S深度融合，相信未來會納入到基金會中。

| Tars的前世今生

Tars的前身是騰訊內部的TAF框架，已經經過了10年的驗證，穩定運行與1.6w+伺服器，100多個業務線中。

據統計， Tars已在超過 120 家公司、 261200 台伺服器上穩定運行。

在分布式環境下，所有的微服務（包括DCache的服務）都可以通過框架自帶的控制台-TarsWeb進行管理， 可以做到所有服務狀態可監控，可以在控制台上進行啟停、修改配置、執行運維指令等操作。

在分布式部署的情況下，可以通過Web控制台實現一鍵升級、回退。

Tars自帶配置中心，分級配置，可以統一修改配置，做到「一點修改，全局生效」。

在服務部署時，可以在界面上填寫要發布的節點，一鍵部署、擴容。

框架提供了狀態監控的能力，可以監控服務的調用質量，如流量情況，平均耗時、超時率和異常率。

框架狀態可以在控制台上一鍵核查。

Tars提供配套的性能測試工具，這也是Tars基金會的子項目。性能測試工作不再依賴專業的測試人員。

| Tars優勢

1、原生RPC調用

Tars使用自研的RPC協議通信，服務之間建立長連接，在通信頻繁的場景下具備顯著的性能優勢。

2、多語言支持

除C++和Java外，Tars還支持NodeJs，PHP，Go等語言，提供了相應的SDK。當團隊技術棧多樣化時，可以多語言協同開發，無縫對接，開發者可以選擇自己熟悉的語言進行開發，提升團隊整體效率。

在這方面，Spring Cloud想要支持異構語言，需要藉助SideCar構建Service Mesh。 業界現在有一些比較流行的服務網格解決方案，但是 並沒有形成統一的標准 ， 可移植性不高 。比較常見的像Istio，由於是代理模式，而且非長連接，會存在 更大的延遲 。另一方面，Istio的部署和運維都非常 復雜 ，需要更多的學習成本和運維成本。

3、內置服務治理功能

Tars框架內嵌了豐富的服務治理功能，包括熔斷、限流、負載均衡、認證、加密等。同時，在服務監控、數據採集，以及灰度部署、跨機房部署等方面，都原生支持，集成度高。

Spring Cloud要支持這些功能，要麼需要集成其他組件，要麼需要設計開發來實現。都需要付出額外的學習成本和研發成本。

4、運維監控

Tars為使用者提供了一體化的運維管理控制台，我們可以在Web上進行一鍵部署、擴容、升級、回退等運維操作。

Spring Cloud並沒有配套的工具。要實現Web管控， 需要藉助K8S和容器，同樣需要付出額外的成本。

5、國產化

Tars是國內公司主導的開源項目，這一點就不多說什麼了。

6、「套裝」優勢

Tars框架提供了微服務相關的一體化解決方案，常規情況下不需要再去集成其他組件，不存在兼容性問題。這就好比MacBook和兼容機的區別，兼容機你可能需要付出更多的試錯成本才能達到想要的效果。

| 劣勢

1、項目熱度

Tars開源較晚，到目前只有5年多時間，項目熱度不如Spring Cloud，應用也沒Spring Cloud廣泛。

2、Tars的雲原生之路

Tars和K8s的深度融合也開源不久（2020年7月，K8SFramework），還有待落地驗證。這個項目現在的更新頻率較高，不建議在生產中使用。但是從這一點也可以看到社區工作者對Tars與K8S融合的高漲熱情，相信未來這個項目一定會大放異彩！

Tars在微服務開發、運維、監控等方面提供了一體化的解決方案，可以幫助我們低成本構建企業級微服務。適用於各種規模的團隊，各種規模的系統。

在做技術選型時，如果團隊中有C++開發人員，或者有多語言開發的情況，而且團隊規模、資源有限的情況下，建議選擇Tars。它在運維、監控、測試等方面會為我們節約大量成本。

未來，隨著 K8SFramework 項目的日漸成熟，相信Tars生態會被更多的團隊熟知和使用。

㈧ 六種常用的微服務架構設計模式（建議收藏）

簡單地說，API主導的連接方法可以被看作是API設計的一種分層方法（至少在本文中是這樣）。其中，系統API公開系統的資產數據信息；中間的是流程API，與系統API一起進行編排和組合；頂端的體驗API公開來自後端數據源的數據，提供最終用戶體驗。這種API分層方法與細粒度SOA模式很好地結合在一起，通常，這兩者要麼可以共存，要麼細粒度SOA模式演化成基於細粒度SOA的分層API模式。

API主導的連接方法為細粒度SOA模式提供了一些層次結構，這些層次結構允許對API或微服務進行一致的管理和治理。然而，基於細粒度SOA的分層API模式也存在一些與細粒度SOA 模式類似的深層問題（這很直觀）：

在細粒度SOA模式執行單個API調用的地方，基於細粒度SOA的分層API模式現在必須通過層執行多個調用。從「網路跳數」的角度來看，這種模式可能是低效的。但是，基於細粒度SOA的分層API模式中，層次結構的存在並不強制跨越網路來調用每個API。直接的跨層調用，而不是通過網路調用是完全有效的；分層的目的是為了增加靈活性，同時以一種很好地分離關注點的方式構建體系架構。

在細粒度SOA模式管理大量服務的地方，使用分層API將會管理來自多個層次的大量細粒度服務。您的管理工具可能不再像以前那樣有效，因為它們可能無法可視化復雜的微服務視圖。

最終應用程序的數據存儲一致性在分層API模式下實際上得到了改善，因為訪問數據的服務都是有組織，且集中地查詢或修改應用程序的狀態。（例如：系統API）

實際上，對於大多數企業來說，基於細粒度SOA的分層API模式是一個很好的模式，但是，就像細粒度SOA模式一樣，在實踐過程中會出現困難。然而，這種困難通常在大范圍使用時才會顯現出來。因此，只有在預期或正在經歷大規模的使用時，我們才應該准備其他的模式。

問題：

沒有一定層次結構的微服務架構是很難進行合理解釋的，因為沒有明顯的方法來對每個微服務的用途進行分類和可視化。

解決方案：

通過創建按用途分組的分層API（系統層、流程及領域模型層，以及體驗層），您可以更容易地管理微服務架構的復雜性。

應用：

將微服務架構分為多個層。通常情況下，可以使用標准化，並具有類似用途的一組微服務以類似的方式工作，從而進一步使微服務架構的復雜性合理化。

影響：

1.通過標准化和進一步分解微服務架構，可以提高快速變更的能力。

2.由於更專門化的層次結構，進程間服務調用的數量可能增加。

3.需要對服務監控和可視化工具進行檢查，以確定它們是否能夠正確地與分層架構一起工作。

目標：

1.快速的敏捷變更。

2.可伸縮性：理論上通過基於細粒度SOA的分層API模式可以提高可伸縮性，但實際上，除非有支持自動化的基礎設施，否則可伸縮性往往會降低。

主要特點：

1.為了實現快速變更，可能存在低效的IPC（Inter-Process Communication，進程間通信）。

2.數據一致性和狀態管理能力較差，但允許高度重用。重用本身會抵消變更的速度。

3.由於與現存模式的相似性，已有的問題往往同樣會出現。

4.基於細粒度SOA的分層API模式在小范圍內使用效果很好，在大規模情況下會出現困難。

5.由於採用了結構化的體系架構方法，所以具有很高的內聚性。

6.重點放在服務顆粒度要細，但通常沒有考慮其能力。

7.基於細粒度SOA的分層API模式以集成為導向，每個微服務依賴於外部系統。這將會降低變更的速度。

基於細粒度SOA的分層API模式如何與SOA或API等現有系統共存？

基於細粒度SOA的分層API模式往往是與現有IT資產共存的最佳方式。由於分層減少了每個微服務的范圍，並約束了其用途，因此該模式能夠在不明顯降低變更速度的情況下，最好地連接和利用現有IT系統。然而，通過細粒度和分層的設計來協調變更可能是一個挑戰。您可能需要使用一定的技術手段來管理所有不同微服務之間的契約，或者使用完全自動化的測試技術來確保變更不會造成破壞。

㈨ 目前比較流程的微服務開發框架是

1、首先你的問題應該寫錯了，應該是目前比較流行的微服務開發框架，而不是比較流程的微服務開發框架。

2、目前比較流行的微服務框架是springBoot，Spring Boot是JAVA平台的微服務框架，是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。通過這種方式，Spring Boot致力於在蓬勃發展的快速應用開發領域(rapid application development)成為領導者。

㈩ 微服務架構：基於微服務和Docker容器技術的PaaS雲平台架構設計

基於微服務架構和Docker容器技術的PaaS雲平台建設目標是給我們的開發人員提供一套服務快速開發、部署、運維管理、持續開發持續集成的流程。平台提供基礎設施、中間件、數據服務、雲伺服器等資源，開發人員只需要開發業務代碼並提交到平台代碼庫，做一些必要的配置，系統會自動構建、部署，實現應用的敏捷開發、快速迭代。在系統架構上，PaaS雲平台主要分為微服務架構、Docker容器技術、DveOps三部分，這篇文章重點介紹微服務架構的實施。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

實施微服務需要投入大量的技術力量來開發基礎設施，這對很多公司來說顯然是不現實的，別擔心，業界已經有非常優秀的開源框架供我們參考使用。目前業界比較成熟的微服務框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基於Spring Boot的一整套實現微服務的框架，它提供了開發微服務所需的組件，跟Spring Boot一起使用的話開發微服務架構的雲服務會變的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我們的微服務架構設計中，就使用了很多Spring Cloud Netflix框架的組件。Spring Cloud Netflix項目的時間還不長，相關的文檔資料很少，博主當時研究這套框架啃了很多英文文檔，簡直痛苦不堪。對於剛開始接觸這套框架的同學，要搭建一套微服務應用架構，可能會不知道如何下手，接下來介紹我們的微服務架構搭建過程以及 需要那些 框架或組件來支持微服務架構。

為了直接明了的展示微服務架構的組成及原理，畫了一張系統架構圖，如下：

從上圖可以看出，微服務訪問大致路徑為：外部請求 → 負載均衡 → 服務網關（GateWay）→ 微服務 → 數據服務/消息服務。服務網關和微服務都會用到服務注冊和發現來調用依賴的其他服務，各服務集群都能通過配置中心服務來獲得配置信息。

服務網關（GateWay）

網關是外界系統（如：客戶端瀏覽器、移動設備等）和企業內部系統之間的一道門，所有的客戶端請求通過網關訪問後台服務。為了應對高並發訪問，服務網關以集群形式部署，這就意味著需要做負載均衡，我們採用了亞馬遜EC2作為虛擬雲伺服器，採用ELB(Elastic Load Balancing)做負載均衡。EC2具有自動配置容量功能，當用戶流量達到尖峰，EC2可以自動增加更多的容量以維持虛擬主機的性能。ELB彈性負載均衡，在多個實例間自動分配應用的傳入流量。為了保證安全性，客戶端請求需要使用https加密保護，這就需要我們進行SSL卸載,使用Nginx對加密請求進行卸載處理。外部請求經過ELB負載均衡後路由到GateWay集群中的某個GateWay服務，由GateWay服務轉發到微服務。服務網關作為內部系統的邊界，它有以下基本能力：

1、動態路由：動態的將請求路由到所需要的後端服務集群。雖然內部是復雜的分布式微服務網狀結構，但是外部系統從網關看就像是一個整體服務，網關屏蔽了後端服務的復雜性。

2、限流和容錯：為每種類型的請求分配容量，當請求數量超過閥值時拋掉外部請求，限制流量，保護後台服務不被大流量沖垮；黨內部服務出現故障時直接在邊界創建一些響應，集中做容錯處理，而不是將請求轉發到內部集群，保證用戶良好的體驗。

3、身份認證和安全性控制：對每個外部請求進行用戶認證，拒絕沒有通過認證的請求，還能通過訪問模式分析，實現反爬蟲功能。

4、監控：網關可以收集有意義的數據和統計，為後台服務優化提供數據支持。

5、訪問日誌：網關可以收集訪問日誌信息，比如訪問的是哪個服務？處理過程（出現什麼異常）和結果？花費多少時間？通過分析日誌內容，對後台系統做進一步優化。

我們採用Spring Cloud Netflix框架的開源組件Zuul來實現網關服務。Zuul使用一系列不同類型的過濾器（Filter），通過重寫過濾器，使我們能夠靈活的實現網關（GateWay）的各種功能。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。

服務注冊與發現

由於微服務架構是由一系列職責單一的細粒度服務構成的網狀結構，服務之間通過輕量機制進行通信，這就引入了服務注冊與發現的問題，服務的提供方要注冊報告服務地址，服務調用放要能發現目標服務。我們的微服務架構中使用了Eureka組件來實現服務的注冊與發現。所有的微服務（通過配置Eureka服務信息）到Eureka伺服器中進行注冊，並定時發送心跳進行 健康 檢查，Eureka默認配置是30秒發送一次心跳，表明服務仍然處於存活狀態，發送心跳的時間間隔可以通過Eureka的配置參數自行配置，Eureka伺服器在接收到服務實例的最後一次心跳後，需要等待90秒（默認配置90秒，可以通過配置參數進行修改）後，才認定服務已經死亡（即連續3次沒有接收到心跳），在Eureka自我保護模式關閉的情況下會清除該服務的注冊信息。所謂的自我保護模式是指，出現網路分區、Eureka在短時間內丟失過多的服務時，會進入自我保護模式，即一個服務長時間沒有發送心跳，Eureka也不會將其刪除。自我保護模式默認為開啟，可以通過配置參數將其設置為關閉狀態。

Eureka服務以集群的方式部署（在博主的另一篇文章中詳細介紹了Eureka集群的部署方式），集群內的所有Eureka節點會定時自動同步微服務的注冊信息，這樣就能保證所有的Eureka服務注冊信息保持一致。那麼在Eureka集群里，Eureka節點是如何發現其他節點的呢？我們通過DNS伺服器來建立所有Eureka節點的關聯，在部署Eureka集群之外還需要搭建DNS伺服器。

當網關服務轉發外部請求或者是後台微服務之間相互調用時，會去Eureka伺服器上查找目標服務的注冊信息，發現目標服務並進行調用，這樣就形成了服務注冊與發現的整個流程。Eureka的配置參數數量很多，多達上百個，博主會在另外的文章里詳細說明。

微服務部署

微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務（也叫邊緣服務）和後端服務（也叫中間服務），前端服務是對後端服務做必要的聚合和剪裁後暴露給外部不同的設備（PC、Phone等），所有的服務啟動時都會到Eureka伺服器進行注冊，服務之間會有錯綜復雜的依賴關系。當網關服務轉發外部請求調用前端服務時，通過查詢服務注冊表就可以發現目標服務進行調用，前端服務調用後端服務時也是同樣的道理，一次請求可能涉及到多個服務之間的相互調用。由於每個微服務都是以集群的形式部署，服務之間相互調用的時候需要做負載均衡，因此每個服務中都有一個LB組件用來實現負載均衡。

微服務以鏡像的形式，運行在Docker容器中。Docker容器技術讓我們的服務部署變得簡單、高效。傳統的部署方式，需要在每台伺服器上安裝運行環境，如果我們的伺服器數量龐大，在每台伺服器上安裝運行環境將是一項無比繁重的工作，一旦運行環境發生改變，就不得不重新安裝，這簡直是災難性的。而使用Docker容器技術，我們只需要將所需的基礎鏡像（jdk等）和微服務生成一個新的鏡像，將這個最終的鏡像部署在Docker容器中運行，這種方式簡單、高效，能夠快速部署服務。每個Docker容器中可以運行多個微服務，Docker容器以集群的方式部署，使用Docker Swarm對這些容器進行管理。我們創建一個鏡像倉庫用來存放所有的基礎鏡像以及生成的最終交付鏡像，在鏡像倉庫中對所有鏡像進行管理。

服務容錯

微服務之間存在錯綜復雜的依賴關系，一次請求可能會依賴多個後端服務，在實際生產中這些服務可能會產生故障或者延遲，在一個高流量的系統中，一旦某個服務產生延遲，可能會在短時間內耗盡系統資源，將整個系統拖垮，因此一個服務如果不能對其故障進行隔離和容錯，這本身就是災難性的。我們的微服務架構中使用了Hystrix組件來進行容錯處理。Hystrix是Netflix的一款開源組件，它通過熔斷模式、隔離模式、回退（fallback）和限流等機制對服務進行彈性容錯保護，保證系統的穩定性。

1、熔斷模式：熔斷模式原理類似於電路熔斷器，當電路發生短路時，熔斷器熔斷，保護電路避免遭受災難性損失。當服務異常或者大量延時，滿足熔斷條件時服務調用方會主動啟動熔斷，執行fallback邏輯直接返回，不會繼續調用服務進一步拖垮系統。熔斷器默認配置服務調用錯誤率閥值為50%，超過閥值將自動啟動熔斷模式。服務隔離一段時間以後，熔斷器會進入半熔斷狀態，即允許少量請求進行嘗試，如果仍然調用失敗，則回到熔斷狀態，如果調用成功，則關閉熔斷模式。

2、隔離模式：Hystrix默認採用線程隔離，不同的服務使用不同的線程池，彼此之間不受影響，當一個服務出現故障耗盡它的線程池資源，其他的服務正常運行不受影響，達到隔離的效果。例如我們通過andThreadPoolKey配置某個服務使用命名為TestThreadPool的線程池，實現與其他命名的線程池隔離。

3、回退（fallback）：fallback機制其實是一種服務故障時的容錯方式，原理類似Java中的異常處理。只需要繼承HystixCommand並重寫getFallBack()方法，在此方法中編寫處理邏輯，比如可以直接拋異常（快速失敗），可以返回空值或預設值，也可以返回備份數據等。當服務調用出現異常時，會轉向執行getFallBack()。有以下幾種情況會觸發fallback：

1）程序拋出非HystrixBadRequestExcepption異常，當拋出HystrixBadRequestExcepption異常時，調用程序可以捕獲異常，沒有觸發fallback，當拋出其他異常時，會觸發fallback；

2）程序運行超時；

3）熔斷啟動；

4）線程池已滿。

4、限流： 限流是指對服務的並發訪問量進行限制，設置單位時間內的並發數，超出限制的請求拒絕並fallback，防止後台服務被沖垮。

Hystix使用命令模式HystrixCommand包裝依賴調用邏輯，這樣相關的調用就自動處於Hystrix的彈性容錯保護之下。調用程序需要繼承HystrixCommand並將調用邏輯寫在run()中，使用execute()（同步阻塞）或queue()（非同步非阻塞）來觸發執行run()。

動態配置中心

微服務有很多依賴配置，某些配置參數在服務運行期間可能還要動態修改，比如：根據訪問流量動態調整熔斷閥值。傳統的實現信息配置的方法，比如放在xml、yml等配置文件中，和應用一起打包，每次修改都要重新提交代碼、打包構建、生成新的鏡像、重新啟動服務，效率太低，這樣顯然是不合理的，因此我們需要搭建一個動態配置中心服務支持微服務動態配置。我們使用Spring Cloud的configserver服務幫我們實現動態配置中心的搭建。我們開發的微服務代碼都存放在git伺服器私有倉庫裡面，所有需要動態配置的配置文件存放在git伺服器下的configserver（配置中心，也是一個微服務）服務中，部署到Docker容器中的微服務從git伺服器動態讀取配置文件的信息。當本地git倉庫修改代碼後push到git伺服器倉庫，git服務端hooks(post-receive，在服務端完成代碼更新後會自動調用)自動檢測是否有配置文件更新，如果有，git服務端通過消息隊列給配置中心（configserver，一個部署在容器中的微服務）發消息，通知配置中心刷新對應的配置文件。這樣微服務就能獲取到最新的配置文件信息，實現動態配置。

以上這些框架或組件是支撐實施微服務架構的核心，在實際生產中，我們還會用到很多其他的組件，比如日誌服務組件、消息服務組件等等，根據業務需要自行選擇使用。在我們的微服務架構實施案例中，參考使用了很多Spring Cloud Netflix框架的開源組件，主要包括Zuul（服務網關）、Eureka（服務注冊與發現）、Hystrix（服務容錯）、Ribbon（客戶端負載均衡）等。這些優秀的開源組件，為我們實施微服務架構提供了捷徑。

如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java高級交流：854630135，群里有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。