單一構建系統發布與部署的業界現狀研究

【引言】

微服務是一種軟件開發技術，是面向服務架構(SOA)風格的變體，將應用程序安排成松散耦合的服務集合，在微服務架構中，每個服務都應該是精細的的，輕量級的。

【簡介】

對于微服務，沒有一個單一的定義。隨著時間的推移，業界已經形成了一個共識的觀點。經常被引用的一些定義特征包括：

l??微服務架構（MSA）中的服務通常是通過網絡進行通信的，通常使用HTTP等協議來進行。

l??微服務體系結構中的服務是可以獨立部署的。

l??服務是以具體業務需求來創建的。

l??服務可以利用不同的程序設計語言、數據庫、硬件和軟件環境，根據不同的需求，使用不同的編程語言、數據庫、硬件和軟件環境來實現。

l??服務的規模很小，支持消息傳遞，受語境約束，自主開發，可獨立部署，去中心化，并通過自動化流程構建和發布。

微服務并不是單體應用中的一個層（例如，web控制器，后端，前端），相反，它是一個自成一體的業務功能，具有明確的接口，可以通過自己的內部組件實現分層架構。從策略的角度來看，微服務架構本質上遵循了Unix的?"做一件事，做好一件事?"的理念，Martin Fowler將基于微服務的架構描述為：

l??適用于持續交付的軟件開發過程。改變應用程序的一小部分只需要重建和重新部署一個或少量的服務即可。

l??堅持使用可直達獨立部署服務的精細化接口、業務驅動開發（如領域驅動設計）等原則。

微服務架構普遍被采用于云原生應用、無服務器計算、以及使用輕量級容器部署的應用等。根據Fowler的觀點，由于服務數量眾多（與單體應用實現相比），為了有效地開發、維護和運營這類應用，去中心化的持續交付和帶有整體服務監控的DevOps是必要的。?遵循這種方法的一個合理性結果是，單獨的微服務可以單獨擴展。在單體應用架構方法中，一個支持三個功能的應用，即使只有其中一個功能需要添加資源約束，也需要對其進行整體的擴展。微服務則不同，只需要對有資源約束需求的微服務進行擴展，?這樣就帶來了資源和成本的優化。

如下為一個微服務系統設計圖：

（圖1）

【歷史與前景】

早在2005年，Peter Rodgers在Web服務邊界會議的一次演講中就提出了?"Micro-Web-Service "這個詞。他反對傳統思維，在SOAP SOA架構炒作的高峰期，他主張?"REST-服務"，并在會議演講的第4頁幻燈片上討論了?"軟件組件就是微服務"，他接著說："微服務是使用類似Unix的管道技術（Web+Unix=真正的松耦合）。服務可以調用服務（支持多語言運行）。復雜的服務組件被抽象到簡單的URI接口后面。任何服務，在任何粒度上都可以暴露出來。"?他描述了一個精心設計的微服務平臺是如何?"將Web和REST服務的底層架構原則與類似Unix的調度和管道一起應用于面向服務的架構中，以提供徹底的靈活性和改進的簡單性。"

羅杰斯的工作起源于1999年惠普實驗室的Dexter研究項目，其目的是讓代碼不那么脆弱，并使大規模復雜的軟件系統能夠穩健地應對變化。?最終，這條研究之路導致了面向資源的計算（ROC）的發展，這是一種廣義的計算抽象，其中REST是一個特殊的子集。

2007年，Juval L?wy在他的著作和演講中呼吁構建每個類都是服務的系統。L?wy意識到這就需要使用一種能夠支持這種細粒度使用服務的技術，他擴展了Windows Communication Foundation (WCF)來做到這一點，在保留傳統的類編程模型的同時，把每一個類都當作服務來對待。

2011年5月，在威尼斯附近舉辦的一個軟件架構師研討會上，與會者用?"微服務?"這個詞來描述這種常見的架構風格，他們中的許多人當時都在探索這種風格。2012年5月，同一個小組決定用?"微服務?"作為最合適的名稱。2012年3月，James Lewis在克拉科夫的第33屆學位大會上，以?"微服務--Java，Unix之道"為例，介紹了其中的一些想法，Fred George也是在同一時間做了介紹。Adrian Cockcroft，前Netflix公司云系統總監，將這種方法描述為?"細粒度的SOA"，在Web規模上開創了這種風格，當然其他許多人如Joe Walnes、Dan North、Evan Bottcher和Graham Tackley也是此種風格的推動者。

微服務是面向服務架構（SOA）的一種專門化的實現方式，用于構建靈活的、可獨立部署的軟件系統，微服務方式是SOA的第一個實現方式，它是隨著DevOps的引入而出現的，在構建連續部署的系統中越來越流行。

2020年2月，《云微服務市場研究報告》預測，2019年至2026年，全球微服務架構市場規模將以21.37%的年復合增長率增長，到2026年將達到31億美元?。

【服務粒度】

定義微服務架構的一個關鍵步驟是弄清楚單個微服務需要有多大。對此，沒有共識或可借鑒的經驗，因為正確的答案取決于業務背景和需求，例如，亞馬遜使用的是面向服務的架構，一個服務通常是一個由3到10個工程師組成的團隊實現的。

將服務做得太小被認為是不好的做法，因為那樣的話，運行時的開銷和操作復雜性會抵消這種方法的好處。當事情變得過于細化時，必須考慮其他的方法：比如把函數打包成庫，再移到其他微服務中。

如果在為系統構建的領域建模時采用了領域驅動設計，那么微服務可以小到作為一個聚合體，大到成為一個綁定的上下文環境平臺。

【好處】

將一個應用程序分解成不同的小服務的好處是很多的。

l??模塊化。這使得應用程序更容易理解、開發、測試，并變得更容易抵御架構的侵蝕。與單體應用架構的復雜度相比，這經常被認為是一種優勢。

l??可擴展性。由于微服務是獨立實現和部署的，即在獨立的進程內運行，因此可以獨立監控和擴展。

l??異構系統和遺留系統的集成：微服務被認為是對現有的單體軟件應用進行現代化改造的可行手段。有一些公司已經成功地用微服務取代了全部或者部分的現有軟件，或者正在進行中。遺留系統的軟件現代化改造過程中，一般采用增量的方法。

l??分布式開發：它使小型的自主團隊能夠獨立地開發、部署和擴展各自的服務，從而實現了開發的并行化，它還可以通過不斷的重構，使單個服務的架構更加優良。基于微服務的架構有利于連續集成、連續交付和部署。

【批評】

微服務的設計理念因為下面的一些問題而受到批評：

l??各自獨立的服務形成信息壁壘。

l??在網絡上進行的業務間呼叫在網絡延遲和報文處理時間方面的成本要高于單體服務流程內的進程內呼叫。

l??測試和部署比較復雜。

l??在服務之間功能遷移是比較困難的，這主要是因為可能涉及到不同團隊之間的溝通，用另一種語言重寫功能，或者是將其適配到不同的基礎架構中。微服務可以獨立于應用程序的其他部分進行部署，而在單體應用上的各團隊工作需要同步部署到一起。

l??將服務的大小視為主要的結構化機制，可能會導致過多的服務，而內部模塊化的替代方案可能會導致更簡單的設計，這就需要更好的理解應用的整體架構和組件之間的相互依賴關系。

l??在基于微服務的架構中，分階段提交被認為是一種反模式，因為這導致了事務中所有參與者之間的緊密耦合。然而，由于缺乏某種技術，導致了尷尬的情況，為了保持數據的一致性，所有的事務參與者都必須等待或者實現這項技術。

l??如果使用不同的工具和技術來構建許多服務，那么開發和支持這些服務就更具有挑戰性。尤其是如果工程師在項目之間頻繁地移動時，問題就尤為突出。

l??微服務通常使用的協議（HTTP）是為面向公共服務設計的，因此不適合用在內部調用的微服務之間。

l??分解方法通常采用的是功能分解的方法，在處理需求變化的同時，增加了服務的復雜度。

l??微服務這個概念本身就有誤導性，對于服務何時開始或停止稱為微服務，并沒有一個合理的定義。

【復雜度的提高】

該架構引入了額外的復雜度和需要處理的新問題，如網絡延遲、消息格式設計、備份/可用性/一致性、負載平衡和容錯等，所有這些問題都必須能夠適應規模的變化。根據《微服務2020狀態報告》的研究結果，維護和調試仍然是構建微服務的開發團隊面臨的最大問題之一。

如果一個單一的應用程序被重新實現為一組微服務應用程序，那么它的復雜度會增加。這些新的復雜度有些來自于操作復雜度，還有些復雜度表現在網絡流量的增加以及由此帶來的性能變慢。

而且，一個由任意數量的微服務組成的應用程序有更多的接口點來訪問其各自的生態系統，這也增加了架構的復雜度。

各種組織原則（如HATEOAS、通過Swagger捕獲的接口和數據模型文檔等）已經被應用到實踐中以減少這些額外的復雜度的影響。

【服務網格】

在服務網格中，每個服務實例都與一個反向代理服務器的實例配對，稱為服務代理。服務實例和服務代理共享一個容器，容器由容器協調工具（如?Kubernetes、Nomad、Docker Swarm?或?DC/OS）管理。服務代理負責與其他服務實例進行通信，可以支持服務（實例）發現、負載均衡、認證和授權、安全通信等功能。

在服務網格中，服務實例和它們的代理構成了所謂的數據平面，它不僅包括數據管理，還包括請求處理和響應。服務網格還包括一個控制平面，用于通過服務代理管理服務之間的交互。服務網狀結構有幾種選擇：Istio(Google、IBM和Lyft的聯合項目)、Linkerd(Buoyant領導的CNCF項目)、Consul(HashiCorp的產品))等。

【平臺的比較】

實施微服務架構是非常困難的。任何微服務架構都需要解決很多問題。

Netflix開發了一個微服務框架來支持他們的內部應用，然后開源了該框架的許多部分。這些工具中的很多都是通過Spring框架普及的--它們在Spring Cloud項目的佑護下被重新實現為基于Spring的工具。

下表顯示了Kubernetes生態系統中的一個實現功能與Spring Cloud世界中的等價物的比較，Spring Cloud生態系統的一個值得注意的方面是，它們都是基于Java的技術，而Kubernetes是一個多技術運行的平臺。

微服務相關考量

Spring Cloud & Netflix OSS

Kubernetes

配置管理：微服務應用的配置需要從代碼中接口化，并通過一個簡單的服務調用來進行使用。

Spring Config Server、Netflix Archaius都支持基于Git-repository的配置。Archaius支持數據類型配置。

Kubernetes ConfigMaps通過服務公開了存儲在etcd中的配置。Kubernetes Secrets支持基于服務的安全部署和使用敏感配置信息（如密碼、證書等）。

服務發現：維護一個微服務域內可工作的服務實例列表。

Spring Cloud Eureka允許客戶注冊，并與注冊的客戶保持關聯，將服務名映射到主機名上，通過服務名查詢服務。

Kubernetes服務提供部署時注冊服務實例，這些服務實例在集群內部可用。Ingress是一種機制，通過這種機制，服務可以向集群外的客戶端暴露接口調用。

負載平衡：擴展分布式系統的關鍵在于能夠運行一個組件的多個實例，隨后通過負載平衡器將負載分配到這些實例中。

Spring Cloud Ribbon為服務客戶端提供了跨服務實例的負載平衡能力。

Kubernetes服務提供了跨服務實例的負載平衡能力。

API網關：微服務提供的API的粒度往往與服務客戶端的需求不同。API網關實現門面，并提供額外的服務，如代理、協議翻譯等管理功能。

Spring Cloud Zuul提供了基于配置的API門面。

Kubernetes服務和Ingress資源、Istio、Ambassador等解決方案，既提供了南北向（流量進出數據中心），也提供了東西向（流量跨數據中心或云或區域）的API網關功能。

安全方面的考量：許多安全問題被推送到API網關實現中。對于分布式微服務應用，不重復造安全輪子，允許在所有服務共享的組件中進行策略定義和安全實現。

Spring Cloud通過Spring Cloud Zuul解決了許多安全問題。

Kubernetes生態系統提供了像Istio這樣的服務網格，能夠通過其API網關機制提供安全保障。

集中化的日志記錄：有一個集中的日志收集和分析基礎設施來管理大量的服務----其中許多服務是以分布式的方式運行的，因此，擁有一個集中的日志收集和分析基礎設施非常重要。

ELK Stack (Elasticsearch, LogStash,?Kibana)

EFK Stack (Elasticsearch,?Fluentd,?Kibana)

集中的指標：一個集中的區域，可以監測各項服務和整個系統的健康狀況和性能，這對于正常運作至關重要。

Spring Spectator & Atlas

Heapster, Prometheus, &?Grafana

分布式追蹤：每個進程日志和指標監控都有自己的作用，但兩者都無法重構事務在分布式系統中傳播的復雜路徑。分布式追蹤是微服務平臺的重要工具。

Spring Cloud Sleuth

Hawkular,?Jaeger

復原力和容錯能力：分布式系統必須能夠圍繞故障自動路由，并能夠將請求路由到能夠提供最佳響應的服務實例。

Spring Hystrix, Turbine, & Ribbon

健康檢查，服務網格(例如：Istio)

自動擴展和自愈：分布式系統通過水平擴展來應對更高的負載：平臺必須檢測并自動響應。此外，系統需要檢測故障并嘗試自動重啟，而無需操作員介入。

-

健康檢查、自我修復和自動擴展功能

包裝、部署和調度：大型系統需要強大的封裝管理，用部署系統來管理滾動部署或藍綠部署，必要時還可以回滾。調度器根據當前條件決定新的服務集可以部署到哪個特定的執行節點。

Spring Boot、Apache Maven。Spring Cloud沒有真正的調度器。

Docker, Rkt, Kubernetes調度和部署, Helm

作業管理：預定的計算與任何單個用戶的請求斷開連接。

Spring Batch

Kubernetes Jobs?和 Scheduled Jobs

Singleton應用程序：指定特定服務作為整個系統中唯一的服務實例運行。

Spring Cloud Cluster

Kubernetes Pods

【小結】

構建復雜的應用的確是很有挑戰性的工作。單體應用架構更適合簡單、輕量級的應用，它是微服務架構的基礎，每個微服務本身就是按照單體架構來實現的。對于復雜的、不斷發展的應用，微服務架構模式當然是更好的選擇，在具體的開發實踐中，應該實事求是的緊貼業務需求，循序漸進的增加新的服務。

總之，我們的目標是：既要能夠利用微服務架構設計帶來的橫向擴展便利，又要盡可能的規避由這種方法所帶來的一系列復雜度的提升和挑戰。

微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。