做爲微服務架構的忠心擁躉,雖然有時也會對其感到不爽。使用微服務時,我時常能感覺到「小中見大」、「穩中有快」等理念,另外一方面也會警戒「廚子太多燒壞了湯」。數據庫
回顧 2014 年,公司正在經過採用微服務架構實施數字化轉型。那時數字化、轉型和微服務這些詞對我就是天籟之音。編程
做爲一名解決方案架構師,我很是但願能瞭解這種新模式。爲了跟上技術前沿趨勢,我閱讀了大量微服務架構相關的文章,與個人網絡技術負責人交流,並研究了一些適用的用例。後端
那時我發自心裏地相信微服務架構,確信單體應用將會消亡。設計模式
此後,我服務過的每家公司都已採用或正在採用微服務架構。雖然其中一些公司的領導團隊並沒能說服組織爲何要選擇微服務,一個廣泛的回答是:「其餘公司都在這樣作,在每次會議上你們都說微服務是一種改變遊戲規則的方式,因此咱們也這樣作吧。」api
經過爲各個業務領域中的多家公司提供體系結構和設計支持,我發現將現有的單體應用從新架構爲微服務架構須要付出大量的耐心、時間和經驗。安全
在給出我在採用微服務中的五點切身體會以前,首先從新審視一下什麼是微服務?微信
有說法提出,這種架構樣式事實並無一個的標準定義,只是存在一些「圍繞組織和業務能力、自動部署,端點智能、對語言和數據分散控制」的特徵。網絡
在我看來,若是一個組織必須具有上述全部特徵才能去使用微服務,那麼咱們就不只是在談論技術變革,而是在推進組織內的重大文化變革。架構
下面給出我在實踐微服務中的五點主要體會。編程語言
1
跳出項目,擁抱產品
傳統的軟件開發方式中,開發團隊一塊兒構建一個單體應用軟件,進而由生產支持團隊管理該軟件。在這種方式中,生產支持團隊做爲軟件的新全部者,一般並不徹底瞭解組件的構建過程,例如代碼的邏輯,所使用的技術等。
他們的核心工做是確保知足業務需求的生產系統能正常地運行,團隊之間一般也沒有定義有效的溝通途徑。生產系統中出現的問題將致使開發回滾到某個還原點,或是給出快速的短時間修補。有時,生產代碼中的一個微小問題將觸發整個過程所有從新開始。而問題一般必須由原始開發團隊解決,這致使總體延遲。
若是以瀑布式開發方式(即前期設計、集中式的版本發佈流程、構建和部署)處理微服務,則存在巨大的風險。最終獲得的多是一個更復雜的系統,沒法享受微服務所承諾的任何好處。
在微服務中,常常說起的是「產品」,而非「項目」。使用微服務方法,利益相關者(包括用戶、程序、產品和技術人員)致力於產品這一共同目標。在投資、軟件交付到維護的整個過程上,產品模式都不一樣於項目模式。
產品直接影響所提供的業務功能。不一樣於傳統方法中構建單體應用須要多個團隊參與,微服務模式支持單個團隊徹底負責構建和管理某一小部分軟件。團隊在產品模式下是穩定的、跨職能的,並以結果爲導向的,獨立完成「設計 - 構建 - 運行」全過程。
每一個團隊都是遵循統一報告層級的獨立部門,根據路線圖去分塊構建獨立的軟件單元。某一層上的團隊可將另外一層上的團隊視爲他們的(內部)客戶,相互協做去解決業務問題,而不是以權責交付的方式工做。
因爲工程團隊以產品模式工做,他們瞭解軟件在生產中的行爲,所以能夠當即解決全部問題,避免產生延誤。
CapitalOne 秉持 YBYO(You Build You Own,本身構建)理念,團隊全權負責設計、構建、測試和部署生產環境中的軟件。工程團隊直接參與產品,並與用戶互動。用戶不斷提供反饋,幫助團隊構建高質量的產品。
要點:控制範圍使團隊能夠更好地構建和管理微服務。產品模式支持與終端用戶創建更緊密的合做、管理和構建關係。
2
思考宏觀服務「微」構建
我在加入 CapitalOne 以前曾任職另外一家公司的團隊,爲公司的電子商務網站創建產品目錄服務。該公司採用了微服務方法,產品目錄服務以請求爲準則,向最終用戶提供產品列表。
因爲個人團隊控制着數據和目錄數據庫,所以選擇 Java 和 SpringBoot 構建服務。這些編程語言支持豐富的軟件庫,咱們對此很是滿意。服務最終公開提供在面向最終用戶的 API 網關上。
公司中一樣還有其餘幾個團隊,使用各自的技術來構建本身的服務。從產品的角度來看,每一個功能都受到構建在異構平臺上的各個服務的支持。這樣的模型解決了一個重要的問題,那就是在招募和培訓團隊中,沒必要使用相同的技術堆棧構建單體應用。在微服務模型中,每一個團隊均可以選擇適合自身業務需求的工具,據此招聘新的團隊成員。
微服務是一種經過服務構建其中業務應用組件的體系架構。每一個服務都是業務流程中的一個獨立於其餘服務的邏輯軟件單元。這種不依賴於其餘服務和技術選擇的自由度,打開了探索新技術、構建本地軟件組件以及基於服務定義範圍進行設計的大門。
在 CapitalOne,軟件產品與業務功能是保持一致的。各個業務線(lines of businesses,LOB)構建和管理本身的產品。跨職能的業務線主要是用於構建和管理企業產品的,例如知足全部 LOB 需求的數據湖和平臺。
要點:鬆耦合和緊關聯的原則,支持團隊構建各類解決更大業務問題的產品。
3
關鍵在於實現:RESTful一勞永逸
微服務架構其實是一種微組件架構。「微」指組件的粒度細,而不是指所暴露接口的粒度。微服務是以 API 爲接口的組件,但並不是全部的微服務組件都暴露 API。在從單體應用向微服務架構過渡中,咱們能夠保持暴露的 API 數量不變。
在這一過渡過程當中,肯定初始計劃將須要幾天甚至幾個月的時間,反過來增長了初始階段的前期成本。大型應用分解爲微服務,可能須要更多團隊的協做。其中持續存在着過分工程的風險,致使建立了比需求更多的微服務,增長了體系結構的複雜性。
我在加入 CapitalOne 以前曾任職的一個公司,肯定了一些可遷移到微服務架構的單體業務應用。產品的願景並無發生改變,由於總體的業務功能沒有改變。
公司招聘了更多的團隊,指望這些團隊擔當起服務的全部者。公司根據發佈時間表部署服務,但基礎架構團隊並未受到計劃的影響,仍然掌控着生產系統。計劃在啓動兩年後的進展不大,花光了預算。
如上的許多實例代表,公司內部團隊應對微服務的實現作更好的溝通。實現數字化轉型的不只僅是應用的開發和新的技術,還須要在產品分析、預算估算、架構、部署程序的從新設計、基礎架構擴展等過程上作大量的工做。過渡到微服務,須要時間、金錢,以及對業務問題見解上的重大轉變。
要點:微服務並不是只是一種架構方式,而是一種會影響到組織中每一個團隊的文化變遷。
4
收益是長期的
採用微服務須要創建多個產品、服務和團隊。在採用這種複雜的體系結構以前,組織必須確立一個紮實的路線圖。
企業須要採用強大的企業級產品,支持各個團隊以微服務方式工做,凝聚在一塊兒。其中包括支持 API 文檔的工具,以及源代碼管理、問題追蹤器和實現自動部署的工具等協做工具。
服務由工程團隊構建,以 API 方式暴露在 API 網關上。API 網關相似於一個 REST API 的市場,是組織平常業務運營的骨幹。一旦組織步入微服務方法的正軌,持續的服務流就能得以建立、升級、替換等。工程師可能並不知道每一個服務的確切位置,由服務發現系統支持服務的自動檢測,使得服務之間能夠互相發現。
爲了得到更好的性能和故障隔離,微服務組件須要一個專門的基礎架構。每一個微服務應具備本身的發佈時間表,無需依賴於其餘服務而隨時部署到生產環境。所以,選擇有效工具持續並實時監視和分析微服務的是相當重要的。
API 是微服務世界的接口,所以 API 的日誌記錄、性能監視和安全性也是組織中 IT 服務過程的關鍵。
構建有彈性的微服務,可遵循多種設計模式,例如,「重試模式」(Retry Pattern)經過透明地重試失敗操做嘗試鏈接到服務或網絡資源,支持應用處理瞬態故障;「斷路器模式」(Circuit Breaker pattern)支持應用在鏈接遠程服務或資源時發生錯誤時能很好地處理故障。
這樣避免了微服務生態系統中出現級聯故障,進而提升應用的穩定性和彈性。在微服務中,每一個服務都是獨立的組件,每一個功能和服務均可以擴展,而沒必要擴展整個應用。關鍵服務可部署多個實例,實現高可用性和更好的性能,而不會影響其餘服務的性能。
要點:儘管過渡到微服務需在前期需投入大量的資源和工做,但隨着時間和工做上的付出,以及自動化工具的使用,業務將從中受益,可快速向市場交付有質量產品。
5
微服務並不普適
並不是全部的業務和用例都適用微服務。例如,團隊必須構建具備不多功能的簡單應用,或是大型單體應用沒法拆分紅較小的模塊,或是不瞭解微服務體架構所帶來的權衡。
此外,某些企業可能還沒有具有快速開發和部署應用的能力,或是不須要持續監視應用或業務,由於發生故障的恢復時間較長對業務影響不大。
和全部其餘工具同樣,微服務只是一種工具,並不是普適於全部業務問題的解決方案。業務優先於一切,底層系統則能夠適應任何體系架構模式,不管是單體應用仍是微服務。
在決定使用微服務以前,每家企業必須首先了解自身的業務需求,權衡利弊後再決定是否轉向微服務。
CapitalOne 在徹底採用雲和微服務架構以前,投入了大量時間和精力研究微服務應用。有能力的領導、富有遠見的產品團隊和技術精湛的工程團隊通力合做,使得 CapitalOne 實現了銀行技術領導者這一目標。
要點:使用微服務並不是免費的午飯。
使用微服務架構將致使基礎架構的需求、成本和複雜性激增,那麼企業爲何要採用微服務?具備大客戶羣的大公司,將經過在短期內向客戶提供優質的產品而蓬勃發展。他們的系統須要始終保持運行的狀態,爲分佈在各個地區的客戶提供服務。
微服務是一種有助於實現此目標的解決方案。在當今的世界中,隨着雲原生基礎架構的出現、DevOps 交付管道的自動化以及容器的採用,公司應該研究一下微服務的優點。
須要指出的是,企業決定選用某種技術,並不是徹底由於別人用着很酷。相反,在採用微服務以前,咱們須要花費時間和精力去了解這種架構模式,該架構與企業自身的相關性。但願個人切身體會能有助於讀者深刻了解微服務。
- END -
往期回顧
點一下在看再走吧
本文分享自微信公衆號 - 互聯網後端架構(fullstack888)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。