【乾貨】微服務技術棧選型手冊2.0

来源:https://www.cnblogs.com/lfs2640666960/archive/2018/05/28/9102681.html
-Advertisement-
Play Games

一、前言 2014年可以認為是微服務1.0的元年，當年有幾個標誌性事件，一是Martin Fowler在其博客上發表了“Microservices”一文，正式提出微服務架構風格；二是Netflix微服務架構經過多年大規模生產驗證，最終抽象落地形成一整套開源的微服務基礎組件，統稱NetflixOSS， ...


一、前言

2014年可以認為是微服務1.0的元年，當年有幾個標誌性事件，一是Martin Fowler在其博客上發表了“Microservices”一文，正式提出微服務架構風格；二是Netflix微服務架構經過多年大規模生產驗證，最終抽象落地形成一整套開源的微服務基礎組件，統稱NetflixOSS，Netflix的成功經驗開始被業界認可並推崇；三是Pivotal將NetflixOSS開源微服務組件集成到其Spring體系，推出Spring Cloud微服務開發技術棧。

一晃三四年過去，微服務技術生態又發生了巨大變化，容器，PaaS，Cloud Native，gRPC，ServiceMesh，Serverless等新技術新理念你方唱罷我登場，不知不覺我們又來到了微服務2.0時代。基於近年在微服務基礎架構方面的實戰經驗和平時的學習積累，我想總結並提出一些構建微服務2.0技術棧的選型思路，供各位在一線實戰的架構師、工程師參考借鑒。對於一些暫時還沒有成熟開源產品的微服務支撐模塊，我也會給出一些定製自研的設計思路。

二、選型準側

對於技術選型，我個人有很多標準，其中下麵三項是最重要的:

1. 生產級

我們選擇的技術棧是要解決實際業務問題和上生產抗流量的（選擇不慎可能造成生產級事故），而不是簡單做個POC或者Demo展示，所以生產級（Production Ready），可運維（Ops Ready），可治理，成熟穩定的技術才是我們的首選；

2. 一線互聯網公司落地產品

我們會儘量採用在一線互聯網公司落地並且開源的，且在社區內形成良好口碑的產品，它們已經在這些公司經過流量衝擊，坑已經基本被填平，且被社區接受形成一個良好的社區生態（本文附錄部分會給出所有推薦使用或參考的開源項目的github鏈接。）。

3. 開源社區活躍度

Github上的stars的數量是一個重要指標，同時會參考其代碼和文檔更新頻率（尤其是近年），這些指標直接反應開源產品的社區活躍度或者說生命力。

另外，對於不同業務體量和團隊規模的公司，技術選型標準往往是不同的，創業公司的技術選型和BAT級別公司的技術選型標準可能完全不同。本文主要針對日流量千萬以上，研發團隊規模不少於50人的公司，如果小於這個規模我建議認真評估是否真的需要採用微服務架構。考慮到Java語言在國內的流行度和我個人的背景經驗，本文主要針對採用Java技術棧的企業。本文也假定自建微服務基礎架構，有些產品其實有對應的雲服務可以直接使用，自建和採用雲服務各有利弊，架構師需要根據場景上下文綜合權衡。

三、微服務基礎架構核心關註點

下麵腦圖中芒果色標註的七個模塊，我認為是構建微服務2.0技術棧的核心模塊，本文後面的選型會分別基於這些模塊展開。對於每個模塊我也列出一些核心架構關註點，在選擇具體產品時，需要儘可能覆蓋到這些關註點。

下圖是在參考過華為技術專家王磊的《微服務的設計與生態系統》的基礎上，結合作者自身的實踐調整而來，其中粉紅色標註的模塊是和微服務關係最密切的模塊，大家在做技術選型時，可以同時對照這個體系。

四、服務框架選型

服務框架是一個比較成熟的領域，有太多可選項。 Spring Boot/Cloud [附錄12.1]由於Spring社區的影響力和Netflix的背書，目前可以認為是構建Java微服務的一個社區標準，Spring Boot目前在github上有超過20k星。基於Spring的框架本質上可以認為是一種RESTful框架（不是RPC框架），序列化協議主要採用基於文本的JSON，通訊協議一般基於HTTP。RESTful框架天然支持跨語言，任何語言只要有HTTP客戶端都可以接入調用，但是客戶端一般需要自己解析payload。目前Spring框架也支持Swagger契約編程模型，能夠基於契約生成各種語言的強類型客戶端，極大方便不同語言棧的應用接入，但是因為RESTful框架和Swagger規範的弱契約特性，生成的各種語言客戶端的互操作性還是有不少坑的。

Dubbo[附錄12.2]是阿裡多年構建生產級分散式微服務的技術結晶，服務治理能力非常豐富，在國內技術社區具有很大影響力，目前github上有超過16k星。Dubbo本質上是一套基於Java的RPC框架，噹噹Dubbox擴展了Dubbo支持RESTful介面暴露能力。Dubbo主要面向Java 技術棧，跨語言支持不足是它的一個弱項，另外因為治理能力太豐富，以至於這個框架比較重，完全用好這個框架的門檻比較高，但是如果你的企業基本上投資在Java技術棧上，選Dubbo可以讓你在服務框架一塊站在較高的起點上，不管是性能還是企業級的服務治理能力，Dubbo都做的很出色。新浪微博開源的Motan（github 4k stars）也不錯，功能和Dubbo類似，可以認為是一個輕量裁剪版的Dubbo。

gRPC[附錄12.3]是谷歌近年新推的一套RPC框架，基於protobuf的強契約編程模型，能自動生成各種語言客戶端，且保證互操作。支持HTTP2是gRPC的一大亮點，通訊層性能比HTTP有很大改進。Protobuf是在社區具有悠久歷史和良好口碑的高性能序列化協議，加上Google公司的背書和社區影響力，目前gRPC也比較火，github上有超過13.4k星。目前看gRPC更適合內部服務相互調用場景，對外暴露HTTP RESTful介面可以實現，但是比較麻煩（需要gRPC Gateway配合），所以對於對外暴露API場景可能還需要引入第二套HTTP RESTful框架作為補充。總體上gRPC這個東西還比較新，社區對於HTTP2帶來的好處還未形成一致認同，建議謹慎投入，可以做一些試點。

五、運行時支撐服務選型

運行時支撐服務主要包括服務註冊中心，服務路由網關和集中式配置中心三個產品。

服務註冊中心，如果採用Spring Cloud體系，則選擇 Eureka [附錄12.4]是最佳搭配，Eureka在Netflix經過大規模生產驗證，支持跨數據中心，客戶端配合Ribbon可以實現靈活的客戶端軟負載，Eureka目前在github上有超過4.7k星； Consul [附錄12.5]也是不錯選擇，天然支持跨數據中心，還支持KV模型存儲和靈活健康檢查能力，目前在github上有超過11k星。

服務網關也是一個比較成熟的領域，有很多可選項。如果採用Spring Cloud體系，則選擇 Zuul[附錄12.6]是最佳搭配，Zuul在Netflix經過大規模生產驗證，支持靈活的動態過濾器腳本機制，非同步性能不足（基於Netty的非同步Zuul遲遲未能推出正式版）。Zuul網關目前在github上有超過3.7k星。基於Nginx/OpenResty的API網關 Kong [附錄12.7]目前在github上比較火，有超過14.1k星。因為採用Nginx內核，Kong的非同步性能較強，另外基於lua的插件機制比較靈活，社區插件也比較豐富，從安全到限流熔斷都有，還有不少開源的管理界面，能夠集中管理Kong集群。

配置中心，Spring Cloud自帶 Spring Cloud Config [附錄12.8]（github 0.75k stars），個人認為算不上生產級，很多治理能力缺失，小規模場景可以試用。個人比較推薦攜程的 Apollo [附錄12.9]配置中心，在攜程經過生產級驗證，具備高可用，配置實時生效（推拉結合），配置審計和版本化，多環境多集群支持等生產級特性，建議中大規模需要對配置集中進行治理的企業採用。Apollo目前在github上有超過3.4k星。

六、服務監控選型

主要包括日誌監控，調用鏈監控，Metrics監控，健康檢查和告警通知等產品。

ELK目前可以認為是日誌監控的標配，功能完善開箱即用， Elasticsearch [附錄12.10]目前在github上有超過28.4k星。 Elastalert [附錄12.11] (github 4k stars)是Yelp開源的針對ELK的告警通知模塊。

調用鏈監控目前社區主流是點評 CAT [附錄12.12]（github 4.3k stars），Twitter之前開源現在由OpenZipkin社區維護的 Zipkin [附錄12.13]（github 7.5k stars）和Naver開源的 Pinpoint [附錄12.14]（github 5.3k stars）。個人比較推薦點評開源的CAT，在點評和國內多家互聯網公司有落地案例，生產級特性和治理能力較完善，另外CAT自帶告警模塊。下麵是我之前對三款產品的評估表，供參考。

Metrics監控主要依賴於時間序列資料庫(TSDB)，目前較成熟的產品是StumbleUpon公司開源的基於HBase的 OpenTSDB [附錄12.15]（基於Cassandra的 KariosDB [附錄12.16]也是一個選擇，github 1.1k stars，它基本上是OpenTSDB針對Cassandra的一個改造版），OpenTSDB具有分散式能力可以橫向擴展，但是相對較重，適用於中大規模企業，OpenTSDB目前在github上有近2.9k星。OpenTSDB 本身不提供告警模塊， Argus [附錄12.17]（github 0.29k星）是Salesforce開源的基於OpenTSDB的統一監控告警平臺，支持豐富的告警函數和靈活的告警配置，可以作為OpenTSDB的告警補充。近年也出現一些輕量級的TSDB，如 InfluxDB [附錄12.18]（github 12.4k stars）和 Prometheus [附錄12.19]（github 14.3k stars），這些產品函數報表能力豐富，自帶告警模塊，但是分散式能力不足，適用於中小規模企業。 Grafana [附錄12.20]（github 19.9k stars）是Metrics報表展示的社區標配。

社區還有一些通用的健康檢查和告警產品，例如 Sensu [附錄12.21]（github 2.7k stars），能夠對各種服務（例如spring boot暴露的健康檢查端點，時間序列資料庫中的metrics，ELK中的錯誤日誌等）定製靈活的健康檢查(check)，然後用戶可以針對check結果設置靈活的告警通知策略。Sensu在Yelp等公司有落地案例。其它類似產品還有Esty開源的 411 [附錄12.22]（github 0.74k星）和Zalando的 ZMon [附錄12.23] (github 0.15k星)，它們是分別在Esty和Zalando落地的產品，但是定製check和告警配置的使用門檻比較高，社區不熱，建議有定製自研能力的團隊試用。ZMon後臺採用KairosDB存儲，如果企業已經採用KariosDB作為時間序列資料庫，則可以考慮ZMon作為告警通知模塊。

七、服務容錯選型

針對Java技術棧，Netflix的 Hystrix [附錄12.24]（github 12.4k stars）把熔斷、隔離、限流和降級等能力封裝成組件，任何依賴調用（資料庫，服務，緩存）都可以封裝在Hystrix Command之內，封裝後自動具備容錯能力。Hystrix起源於Netflix的彈性工程項目，經過Netflix大規模生產驗證，目前是容錯組件的社區標準，github上有超12k星。其它語言棧也有類似Hystrix的簡化版本組件。

Hystrix一般需要在應用端或者框架內埋點，有一定的使用門檻。對於採用集中式反向代理（邊界和內部）做服務路由的公司，則可以集中在反向代理上做熔斷限流，例如採用 nginx [附錄12.25]（github 5.1k stars）或者 Kong [附錄12.7]（github 11.4k stars）這類反向代理，它們都有插件支持靈活的限流容錯配置。Zuul網關也可以集成Hystrix實現網關層集中式限流容錯。集中式反向代理需要有一定的研發和運維能力，但是可以對限流容錯進行集中治理，可以簡化客戶端。

八、後臺服務選型

後臺服務主要包括消息系統，分散式緩存，分散式數據訪問層和任務調度系統。後臺服務是一個相對比較成熟的領域，很多開源產品基本可以開箱即用。

消息系統，對於日誌等可靠性要求不高的場景，則Apache頂級項目 Kafka [附錄12.26]（github 7.2k stars）是社區標配。對於可靠性要求較高的業務場景，kafka其實也是可以勝任，但企業需要根據具體場景，對 Kafka的監控和治理能力進行適當定製完善，Allegro公司開源的 hermes [附錄12.27]（github 0.3k stars）是一個可參考項目，它在Kafka基礎上封裝了適合業務場景的企業級治理能力。阿裡開源的 RocketMQ [附錄12.28]（github 3.5k星）也是一個不錯選擇，具備更多適用於業務場景的特性，目前也是Apache頂級項目。 RabbitMQ [附錄12.29]（github 3.6k星）是老牌經典的MQ，隊列特性和文檔都很豐富，性能和分散式能力稍弱，中小規模場景可選。

對於 緩存治理 ，如果傾向於採用客戶端直連模式（個人認為緩存直連更簡單輕量），則SohuTv開源的 cachecloud [附錄12.30]（github 2.5k stars）是一款不錯的Redis緩存治理平臺，提供諸如監控統計，一鍵開啟，自動故障轉移，線上伸縮，自動化運維等生產級治理能力，另外其文檔也比較豐富。如果傾向採用中間層Proxy模式，則Twitter開源的 twemproxy [附錄12.31]（github 7.5k stars）和CodisLab開源的 codis [附錄12.32]（github 6.9k stars）是社區比較熱的選項。

對於 分散式數據訪問層 ，如果採用Java技術棧，則噹噹開源的 shardingjdbc [附錄12.33]（github 3.5k stars）是一個不錯的選項，分庫分表邏輯做在客戶端jdbc driver中，客戶端直連資料庫比較簡單輕量，建議中小規模場景採用。如果傾向採用資料庫訪問中間層proxy模式，則從阿裡Cobar演化出來的社區開源分庫分表中間件 MyCAT [附錄12.34]（github 3.6k stars）是一個不錯選擇 。proxy模式運維成本較高，建議中大規模場景，有一定框架自研和運維能力的團隊採用。

任務調度系統，個人推薦徐雪裡開源的 xxl-job [附錄12.35]（github 3.4k stars），部署簡單輕量，大部分場景夠用。噹噹開源的 elastic-job [附錄12.36]（github 3.2k stars）也是一個不錯選擇，相比xxl-job功能更強一些也更複雜。

九、服務安全選型

對於微服務安全認證授權機制一塊，目前業界雖然有OAuth和OpenID connect等標準協議，但是各傢具體實現的做法都不太一樣，企業一般有很多特殊的定製需求，整個社區還沒有形成通用生產級開箱即用的產品。有一些開源授權伺服器產品，比較知名的如 Apereo CAS [附錄12.37]（github 3.6k stars），JBoss開源的 keycloak [附錄12.38]（github 1.9 stars）， spring cloud security [附錄12.39]等，大都是opinionated（一家觀點和做法）的產品，同時因支持太多協議造成產品複雜，也缺乏足夠靈活性。個人建議基於OAuth和OpenID connect標準，在參考一些開源產品的基礎上（例如Mitre開源的 OpenID-Connect-Java-Spring-Server [附錄12.40]，github 0.62k stars），定製自研輕量級授權伺服器。Wso2提出了一種微服務安全的參考方案[附錄12.45]，建議參考，該方案的關鍵步驟如下：

  1. 使用支持OAuth 2.0和OpenID Connect標準協議的授權伺服器（個人建議定製自研）；

  2. 使用API網關作為單一訪問入口，統一實現安全治理；

  3. 客戶在訪問微服務之前，先通過授權伺服器登錄獲取access token，然後將access token和請求一起發送到網關；

  4. 網關獲取access token，通過授權伺服器校驗token，同時做token轉換獲取JWT token。

  5. 網關將JWT Token和請求一起轉發到後臺微服務；

  6. JWT中可以存儲用戶會話信息，該信息可以傳遞給後臺的微服務，也可以在微服務之間傳遞，用作認證授權等用途；

  7. 每個微服務包含JWT客戶端，能夠解密JWT並獲取其中的用戶會話信息。

  8. 整個方案中，access token是一種by reference token，不包含用戶信息可以直接暴露在公網上；JWT token是一種by value token，可以包含用戶信息但不暴露在公網上。

 

十、技術詳解

 

微服務技術是程式員繞不開的話題，在這裡給大家推薦一個架構交流學習群：650385180，裡面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分散式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多，以上的知識體系圖也是在群里獲取。相信對於已經工作和遇到技術瓶頸的碼友，在這個群里會有有你需要的內容。

為解決單體架構下的各種問題，微服務架構應運而生。與其構建一個臃腫龐大、難以馴服的怪獸，還不如及早將服務拆分。微服務的核心思想便是服務拆分與解耦，降低複雜性。微服務強調將功能合理拆解，儘可能保證每個服務的功能單一，按照單一責任原則（Single Responsibility Principle）明確角色。 將各個服務做輕，從而做到靈活、可復用，亦可根據各個服務自身資源需求，單獨佈署，單獨作橫向擴展。

 

十一、服務部署平臺選型

 

容器已經被社區接受為交付微服務的一種理想手段，可以實現不可變（immutable）發佈模式。一個輕量級的基於容器的服務部署平臺主要包括容器資源調度，發佈系統，鏡像治理，資源治理和IAM等模塊。

集群資源調度系統：屏蔽容器細節，將整個集群抽象成容器資源池，支持按需申請和釋放容器資源，物理機發生故障時能夠實現自動故障遷移(fail over)。目前Google開源的 kubernetes [附錄12.41]，在Google背書和社區的強力推動下，基本已經形成市場領導者地位，github上有31.8k星，社區的活躍度已經遠遠超過了 mesos [附錄12.42]（github 3.5k stars）和swarm等競爭產品，所以容器資源調度建議首選k8s。當然如果你的團隊有足夠定製自研能力，想深度把控底層調度演算法，也可以基於mesos做定製自研。

鏡像治理：基於docker registry，封裝一些輕量級的治理功能。vmware開源的harbor[附錄12.43] (github 3.5k stars)是目前社區比較成熟的企業級產品，在docker registry基礎上擴展了許可權控制，審計，鏡像同步，管理界面等治理能力，可以考慮採用。

資源治理：類似於CMDB思路，在容器雲環境中，企業仍然需要對應用app，組織org，容器配額和數量等相關信息進行輕量級的治理。目前這塊還沒有生產級的開源產品，一般企業需要根據自己的場景定製自研。

發佈平臺：面向用戶的發佈管理控制台，支持發佈流程編排。它和其它子系統對接交互，實現基本的應用發佈能力，也實現如藍綠，金絲雀和灰度等高級發佈機制。目前這塊生產級的開源產品很少，Netflix開源的 spinnaker [附錄12.44]（github 4.2k stars）是一個，但是這個產品比較複雜重量（因為它既要支持適配對接各種CI系統，同時還要適配對接各種公有雲和容器雲，使得整個系統異常複雜），一般企業建議根據自己的場景定製自研輕量級的解決方案。

IAM：是identity & access management的簡稱，對發佈平臺各個組件進行身份認證和安全訪問控制。社區有不少開源的IAM產品，比較知名的有 Apereo CAS （github 3.6k stars），JBoss開源的 keycloak（github 1.9 stars） 等。但是這些產品一般都比較複雜重量，很多企業考慮到內部各種系統靈活對接的需求，都會考慮定製自研輕量級的解決方案。

考慮到服務部署平臺目前還沒有端到端生產級解決方案，企業一般需要定製集成，下麵給出一個可以參考的具備輕量級治理能努力的發佈體系：

簡化發佈流程如下：

  1. 應用通過CI集成後生成鏡像，用戶將鏡像推到鏡像治理中心；

  2. 用戶在資產治理中心申請發佈，填報應用，發佈和配額相關信息，然後等待審批通過；

  3. 發佈審批通過，開發人員通過發佈控制台發佈應用；

  4. 發佈系統通過查詢資產治理中心獲取發佈規格信息；

  5. 發佈系統向容器雲發出啟動容器實例指令；

  6. 容器雲從鏡像治理中心拉取鏡像並啟動容器；

  7. 容器內服務啟動後自註冊到服務註冊中心，並保持定期心跳；

  8. 用戶通過發佈系統調用服務註冊中心調撥流量，實現藍綠，金絲雀或灰度發佈等機制；

  9. 網關和內部微服務客戶端定期同步服務註冊中心上的服務路由表，將流量按負載均衡策略分發到新的服務實例上。

另外，持續交付流水線（CD Pipeline）也是微服務發佈重要環節，這塊主要和研發流程相關，一般需要企業定製，下麵是一個可供參考的流水線模型，在鏡像治理中心上封裝一些輕量級的治理流程，例如只有通過測試環境測試的鏡像才能升級發佈到UAT環境，只有通過UAT環境測試的鏡像才能升級發佈到生產環境，通過在流水線上設置一些質量門，保障應用高質量交付到生產。

十二、寫在最後

註意，本文限於篇幅，對測試和CI等環節沒有涉及，但它們同樣是構建微服務架構的重要環節，也有眾多成熟的開源成熟產品可選。

技術選型雖然重要，但還只是微服務建設的一小部分工作，選型後的產品要在企業內部真正落地，形成完整的微服務技術棧體系，則後續還有大量集成、定製、治理、運維和推廣等工作。

本文僅限個人經驗視角，選型思路僅供參考借鑒。每個企業的具體上下文（業務場景，團隊組織，技術架構等）各不相同，每個架構師的背景經驗也各不相同，大家要結合實際自己做出選型，沒有最好的技術棧，只有相對較合適的技術棧。另外，好的技術選型是相互借鑒甚至PK出來的，歡迎大家討論，給出自己的微服務2.0技術棧選型意見。

十三、附錄

  1. Spring Boot

    https://github.com/spring-projects/spring-boot

  2. Alibaba Dubbo

    https://github.com/alibaba/dubbo

  3. Google gRPC

    https://github.com/grpc/grpc

  4. NetflixOSS Eureka

    https://github.com/Netflix/eureka

  5. Hashicorp Consul

    https://github.com/hashicorp/consul

  6. NetflixOSS Zuul

    https://github.com/Netflix/zuul

  7. Kong

    https://github.com/Kong/kong

  8. Spring Cloud Config

    https://github.com/spring-cloud/spring-cloud-config

  9. CTrip Apollo

    https://github.com/ctripcorp/apollo

  10. ElasticSearch

    https://github.com/elastic/elasticsearch

  11. Yelp Elastalert

    https://github.com/Yelp/elastalert

  12. Dianping CAT

    https://github.com/dianping/cat

  13. Zipkin

    https://github.com/openzipkin/zipkin

  14. Naver Pinpoint

    https://github.com/naver/pinpoint

  15. OpenTSDB

    https://github.com/OpenTSDB/opentsdb

  16. KairosDB

    https://github.com/kairosdb/kairosdb

  17. Argus

    https://github.com/salesforce/Argus

  18. InfluxDB

    https://github.com/influxdata/influxdb

  19. Prometheus

    https://github.com/prometheus/prometheus

  20. Grafana

    https://github.com/grafana/grafana

  21. Sensu

    https://github.com/sensu/sensu

  22. Esty 411

    https://github.com/etsy/411

  23. Zalando ZMon

    https://github.com/zalando/zmon

  24. NetflixOSS Hystrix

    https://github.com/Netflix/Hystrix

  25. Nginx

    https://github.com/nginx/nginx

  26. Apache Kafka

    https://github.com/apache/kafka

  27. Allegro Hermes

    https://github.com/allegro/hermes

  28. Apache Rocketmq

    https://github.com/apache/rocketmq

  29. Rabbitmq

    https://github.com/rabbitmq/rabbitmq-server

  30. Sohutv CacheCloud

    https://github.com/sohutv/cachecloud

  31. Twitter twemproxy

    https://github.com/twitter/twemproxy

  32. CodisLab codis

    https://github.com/CodisLabs/codis

  33. Dangdang Sharding-jdbc

    https://github.com/shardingjdbc/sharding-jdbc

  34. MyCAT

    https://github.com/MyCATApache/Mycat-Server

  35. Xxl-job

    https://github.com/xuxueli/xxl-job

  36. Dangdang elastic-job

    https://github.com/elasticjob/elastic-job-lite

  37. Apereo CAS

    https://github.com/apereo/cas

  38. JBoss keycloak

    https://github.com/keycloak/keycloak

  39. Spring cloud security

    https://github.com/spring-cloud/spring-cloud-security

  40. OpenID-Connect-Java-Spring-Server

    https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server

  41. Google Kubernetes

    https://github.com/kubernetes/kubernetes

  42. Apache Mesos

    https://github.com/apache/mesos

  43. Vmware Harbor

    https://github.com/vmware/harbor

  44. Netflix Spinnaker

    https://github.com/spinnaker/spinnaker

  45. Microservices in Practice – Key Architecture Concepts of an MSA

    https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 迭代器、比較器、文件過濾器
    Java類庫中有為滿足不同需求而設計的不同的器，實際上就是不同的介面。最近學習了比較器、迭代器和文件過濾器這三個介面，我根據自己的理解做了一個不成熟的總結，假如有很多不准確甚至是錯誤的地方，希望大家多多賜教！ 這三個介面在設計的時候，並不是只是聲明一個介面以及它裡面的方法，也在需要特定類“配合”這些 ...
  • 流暢的Python PDF下載高清完整掃描原版
    書名：流暢的Python作者：[巴西] Luciano Ramalho譯者：安道　吳珂ISBN：978-7-115-45415-7 需要學習的朋友可以通過網盤下載pdf版 http://tadown.com/fs/cyibbebnsahu08034/ 目標讀者本書的目標讀者是那些正在使用 Pytho ...
  • Django Rest Framework源碼剖析(二)-----許可權
    在上一篇博客中已經介紹了django rest framework 對於認證的源碼流程，以及實現過程，當用戶經過認證之後下一步就是涉及到許可權的問題。比如訂單的業務只能VIP才能查看，所以這時候需要對許可權進行控制。下麵將介紹DRF的許可權控制源碼剖析。 這裡繼續使用之前的示例，加入相應的許可權，這裡先介紹 ...
  • SpringBoot
    一個功能瀏覽器發送hello請求，伺服器接受請求並處理,響應Hello World字元串.1.創建一個maven工程；(jar)2.導入依賴Spring Boot相關的依賴 3.編寫一個主程式；啟動Spring Boot應用4.編寫相關Controller、Service 5.運行主程式測試6.簡化 ...
  • Java基礎知識回顧之五 ----- 多線程
    前言 在 "上一篇" 文章中，回顧了Java的集合。而在本篇文章中主要介紹 多線程 的相關知識。主要介紹的知識點為線程的介紹、多線程的使用、以及在多線程中使用的一些方法。 線程和進程 線程 表示進程中負責程式執行的執行單元，依靠程式進行運行。線程是程式中的順序控制流，只能使用分配給程式的資源和環境。 ...
  • 如何用input標簽上傳多個圖片並回顯
    本文主要記錄如何用input標簽和jquery實現多圖片的上傳和回顯，不會涉及後端的交互，大概的效果看圖 我們從零來做一個這樣的demo 第一步： 我們先完善一下我們的頁面，預設的input file標簽非常醜，我們美化一下它，不會的可以百度一下，就是外面套個盒子，設置input的opacity為0 ...
  • [python] python常用函數
    urlencode與urldecode 當url中包含中文或者參數包含中文，需要對中文或者特殊字元（/、&）做編碼轉換。 urlencode的本質：把字元串轉為gbk編碼，再把\x替換成%。如果終端是utf8編碼的，需要把結果再轉成utf8輸出，否則會亂碼。 urlencode urllib庫裡面的 ...
  • python中繼承和多態
    繼承和多態 繼承 引入繼承 我們有這樣一個需求 那我們實現的代碼是這樣的 我們仔細看代碼可以發現，在兩個類中有很多的重覆代碼，初始化方法和attack方法，那麼我們學習面向對象就是來較少代碼重覆量的，有沒有辦法解決呢？答案是肯定有的 初識繼承 繼承，指的是 類與類之間的關係 ，是一種 xx是xx的關 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類